eSIM Cybersecurity in M2M/IoT Environments (4G/5G)

Executive Summary

Embedded SIM (eSIM) technology has rapidly gained traction as a flexible connectivity solution for the Internet of Things (IoT) and machine-to-machine (M2M) deployments in 4G and 5G networks. Unlike traditional removable SIMs, eSIMs (embedded Universal Integrated Circuit Cards, or eUICCs) are soldered or integrated into devices and support remote SIM provisioning (RSP) to download or switch operator profiles over the airthehackernews.com 1nce.com. This white paper provides a comprehensive vendor-agnostic analysis of eSIM cybersecurity in M2M/IoT contexts, with a focus on the European landscape. It is intended for Chief Information Security Officers (CISOs), IoT architects, mobile network operators, and regulators who require both high-level insights and technical depth on this emerging area.

We begin with a technical overview of eSIM and RSP architectures, highlighting how eSIMs function within IoT devices and how profiles are remotely managed. Next, we explore the evolving threat landscape – from recent vulnerabilities in eSIM platforms (such as the GSMA TS.48 test profile flaw that enabled rogue applet installationkigen.com) to underlying Java Card issues that could undermine SIM securitythehackernews.com. We examine notable incidents and attack vectors including SIM card exploits via SMS (e.g., the Simjacker attackcert.europa.eu cert.europa.eu) and sophisticated nation-state breaches (e.g., theft of SIM encryption keys from manufacturerssecurityweek.com).

The paper then reviews key security standards, frameworks, and regulations shaping eSIM security. Industry specifications from the GSMA – such as SGP.24 (the eSIM compliance process)1nce.com and protection profiles for eUICC security – alongside European initiatives like EN 17927 (Security Evaluation Standard for IoT Platforms, SESIP)globalplatform.org and the EU Cyber Resilience Act are discussed in context. We analyze how these frameworks set requirements for secure eSIM hardware, software, and lifecycle management, and where gaps remain.

Building on this, we outline risk mitigation strategies and best practices. These include technical measures (secure element hardware hardening, Java Card OS patching, disabling of test/maintenance functions in productionkigen.com), secure RSP and over-the-air (OTA) safeguards, and rigorous supply chain vetting via GSMA Security Accreditation Scheme (SAS) certificationiotforall.com. Governance models are proposed to ensure accountability across stakeholders – manufacturers, network operators, and regulators – emphasizing continuous monitoring and incident response, not just one-off certificationfreemindtronic.com freemindtronic.com.

Real-world case studies illustrate the stakes: from the 2013 SIM key cracking that affected millions of SIMssecurityweek.com, to the 2019 Simjacker spyware exploit targeting SIM toolkitscert.europa.eu, to the recent 2025 discovery of a critical eSIM vulnerability enabling profile cloning on IoT devicesthehackernews.com thehackernews.com. Each case is analyzed for root causes and lessons learned.

Finally, we look ahead to future challenges and research gaps. As eSIM and now integrated SIM (iSIM) technologies proliferate in critical infrastructures, new efforts are needed in areas like runtime attestation of eSIM integrity, post-quantum resistant SIM authentication, and improved post-deployment visibility to detect compromises. The white paper concludes with a summary table of recommendations for securing eSIM-enabled IoT deployments and a call to action for stronger collaboration between industry and regulators in Europe and globally.

Technical Overview of eSIM and Remote SIM Provisioning

What is an eSIM (eUICC)?

An embedded SIM (eSIM) refers to a SIM function embedded directly into a device as a eUICC (Embedded Universal Integrated Circuit Card) chip, rather than a removable cardthehackernews.com. The eUICC hardware is a tamper-resistant secure element that can host one or multiple operator profiles, which are essentially the digital credentials (IMSI, authentication keys, network configurations) that traditional SIM cards containthehackernews.com. In practical terms, an eSIM allows a device to connect to cellular networks without needing a physical SIM swap; new operator profiles can be downloaded to the eUICC over-the-air.

From a form-factor perspective, eUICCs can be soldered onto circuit boards (MFF2 format) or even integrated at the silicon level (integrated SIM, or iSIM) rather than a removable plastic cardiotforall.com iotforall.com. eSIM functionality is defined by a combination of hardware (the secure chip) and software (the operating system, often Java Card-based, running on the secure element). Because the eSIM is not physically accessible once deployed, all profile management must occur via secure remote provisioning protocols.

Remote SIM Provisioning (RSP) is the standardized mechanism defined by the GSMA for managing operator profiles on eUICCs after manufacturing. Each eSIM has a unique digital identifier and cryptographic keys established by the manufacturer and the mobile operator ecosystem, which are used to authenticate and secure the provisioning processenisa.europa.eu enisa.europa.eu.

eSIM in M2M vs. Consumer IoT Scenarios

The GSMA has specified two primary architectures for eSIM remote provisioning, reflecting different use cases:

Consumer eSIM solution: This model is user-driven and is prevalent in smartphones, tablets, and other consumer devices. It involves the end-user initiating profile downloads (typically by scanning a QR code or using an app provided by the operator or device manufacturer). The architecture includes components like the SM-DP+ (Subscription Manager Data Preparation) server operated by the operator to prepare and encrypt profiles, the SM-DS (Discovery Service) to help devices find available profiles, and the device’s LPA (Local Profile Assistant) which is the software on the device that handles downloading and installing the profile onto the eUICCenisa.europa.eu enisa.europa.eu. In the consumer model, the eUICC is often pre-provisioned with an initial bootstrap and relies on the end-user’s consent to download new profiles.
M2M (Machine-to-Machine) eSIM solution: Aimed at IoT modules, connected vehicles, smart meters, and other industrial or enterprise devices, the M2M architecture is typically operator-driven or enterprise-driven with little to no user interaction. Instead of an LPA on the device, M2M eSIM uses a server-centric approach with SM-DP (Subscription Manager Data Preparation) and SM-SR (Subscription Manager Secure Routing) servers. The SM-DP securely packages the operator profile, and the SM-SR (often operated by a connectivity provider or operator) delivers and manages profiles on the eUICC over the air1nce.com 1nce.com. The M2M RSP procedure is usually triggered by backend systems (for example, a fleet management platform can trigger a swap of the operator across thousands of deployed devices remotely). The device itself typically doesn’t require user input to switch profiles, making this model suitable for IoT deployments where devices are unattended.

The key differences between the consumer and M2M models lie in how profiles are discovered and who initiates the download. Consumer eSIM downloads are initiated by the user, often mediated through a smartphone interface, whereas M2M eSIM downloads are initiated by a remote management platform or operator without user involvement. Despite these differences, both models use strong security: profiles are packaged and encrypted by the SM-DP/SM-DP+ and can only be installed on the target eUICC identified by unique keys and certificates, ensuring profiles cannot be hijacked in transit or loaded onto unauthorized devicesarxiv.org arxiv.org.

Emerging “IoT eSIM” specification: In 2023, GSMA introduced a new set of specifications (notably SGP.31/32) aimed at IoT deployments, sometimes described as a convergence of consumer and M2M eSIM approaches1nce.com 1nce.com. The goal is to simplify remote provisioning for IoT devices that may have constraints like no user interface or limited power/network availability. This new IoT specification streamlines the architecture (for example, simplifying discovery and allowing more lightweight provisioning suitable for LPWAN or constrained devices)1nce.com. For the purposes of this paper, the security considerations of the IoT specification are similar in spirit to the existing models – ensuring only authorized entities can manage profiles, and that the eUICC remains a trustworthy anchor in the device.

eSIM Adoption in 4G/5G IoT

With the rollout of 4G LTE and now 5G, eSIM technology has become increasingly important for IoT connectivity. The ability to remotely switch network providers or update subscriptions is invaluable for devices deployed at scale, especially across different regions or where physical access is difficult. Recent market data shows a sharp growth in eSIM uptake: over 500 million eSIMs were shipped in 2024 alone, reflecting a 35% year-over-year increasetrustedconnectivityalliance.org. This growth is not only driven by smartphones, but also significant adoption in M2M/IoT sectors. According to industry associations, “TCA members also reported significant M2M eSIM adoption”, and the trend is expected to accelerate with new IoT-focused eSIM standardstrustedconnectivityalliance.org. Europe, in particular, is seeing robust eSIM uptake both in consumer devices and IoT, coinciding with the expansion of 5G standalone networks and digital-first strategies by operatorstrustedconnectivityalliance.org.

For IoT solution architects, the integration of eSIM means device connectivity can be managed throughout the product lifecycle. For example, a connected vehicle may initially ship with one mobile network profile, but if the vehicle is sold or moved to a different country, a new local profile can be provisioned without swapping hardware. Similarly, industrial sensors can have their connectivity optimized (or carrier changed for cost/network quality reasons) entirely through backend operations.

Security is a foundation of the eSIM system – profiles are cryptographically tied to the target eUICC, and mutual authentication is required at each provisioning steparxiv.org. However, as we will discuss, this very flexibility and complexity introduces new potential attack surfaces. The following sections delve into the threat landscape specific to eSIM-enabled IoT deployments and how the industry is responding with standards and countermeasures.

Threat Landscape for eSIM in IoT

Modern eSIM-enabled IoT devices inherit many of the traditional security threats of SIM cards and mobile networks, while also presenting new challenges due to remote programmability and software-based profile management. Below we outline key elements of the threat landscape, including recent high-profile vulnerabilities and attack vectors targeting eSIMs, eUICC software, remote provisioning protocols, and the surrounding ecosystem. Real incidents are highlighted to illustrate each threat.

Vulnerabilities in eSIM Platforms and Java Card

GSMA TS.48 Test Profile Vulnerability (2025): A recent discovery revealed a serious weakness in the GSMA TS.48 generic test profile specification (versions 6.0 and earlier) used widely for eSIM device testing. In mid-2025, researchers found that when the test profile was active, an attacker with certain knowledge could install unverified (potentially malicious) Java Card applets on the eUICCkigen.com. This essentially meant the security protections that normally restrict loading of code to a SIM could be bypassed under specific conditions. According to Kigen (an eSIM OS provider), the vulnerability “allows installation of non-verified, and potentially malicious applets” across eSIM products that implemented the affected test profilekigen.com.

Exploiting this flaw was non-trivial – it required physical access to the target eUICC and knowledge of default or publicly-known test keyskigen.com. In practice, an independent security researcher did demonstrate an exploit by obtaining eSIMs and using fixed test keys left in the product, taking months to meticulously load a rogue applet9esim.com 9esim.com. Once loaded, the malicious applet was used to extract secret data from the eSIM over time9esim.com 9esim.com. The impact of such an exploit is severe: the attacker could retrieve the eSIM’s operator profiles or credentials, clone them, or tamper with them without detectionthehackernews.com thehackernews.com. In effect, this opens the door to cloning eSIM profiles, intercepting communications, or inserting a backdoor on the SIM card itself.

It’s important to note that the TS.48 test profiles are not meant for normal operation – they exist for regulatory compliance testing of radio modules. In theory, production devices should not be left in a state where a test profile is active. However, the fact that a common test mechanism had an ambiguous specification that “may allow post-issuance applet installation and misuse of Remote Applet Management (RAM) functions” shows how even isolated test features can become security loopholes9esim.com kigen.com. In response, GSMA released TS.48 v7.0 in June 2025 to mitigate the issue by disabling the risky functionality (blocking remote applet loading when in test mode, using randomized keys, etc.)thehackernews.com kigen.com. Furthermore, eSIM vendors like Kigen issued patches to their OS, and strongly advised that test profiles never be present or used on deployed eSIMskigen.com. As a result of these fixes, the specific exploit path has been closed: “TS.48 v7 restricts the use of test profiles… updated versions of Kigen OS block applet installation in these profiles”kigen.com. This incident underscored that built-in test functionalities must be rigorously secured or disabled, as attackers will scour even niche features for weaknesses.

Java Card OS Vulnerabilities: eSIMs and traditional SIMs typically run a Java Card operating system – a streamlined Java Virtual Machine tailored for smart cards. While Java Card is designed with security in mind (strong typing, applet isolation, etc.), research by Security Explorations in 2019 demonstrated that the Java Card platform is not immune to critical bugs. The researchers uncovered 18 vulnerabilities in Oracle’s reference Java Card implementation, plus additional issues on specific SIM products, that could “break memory safety of the underlying Java Card VM and gain full access to the card’s memory, break the applet firewall, and possibly even achieve native code execution”securityweek.com. In other words, by loading a specially crafted malicious applet (which in some scenarios could be done if one obtains the necessary keys or exploits another entry point), an attacker could escape the normal sandboxing on the SIM and take complete control of the secure element. This is analogous to a jailbreak of the SIM card, allowing extraction or manipulation of any data (subscription keys, stored SMS, etc.) on it.

Exploiting these Java Card flaws in the wild often requires a chain of events (such as obtaining the ability to load an applet). As one example, “in 2013, Karsten Nohl discovered a crypto flaw affecting a wide range of SIM cards that made it possible to remotely discover keys required to load Java applets” onto SIMssecurityweek.com. That 2013 attack used a vulnerability in the SIM’s Over-The-Air (OTA) update authentication (a weakness in DES encryption and error handling) to glean the OTA keys, which then allowed an attacker to install a rogue applet via SMSsecurityweek.com. Combined with the Java Card VM vulnerabilities, such an applet could fully compromise the SIM’s security. Oracle, the maintainer of Java Card, initially downplayed some of these issues, implying they might be difficult to exploit in practicethehackernews.com. However, the proof-of-concept exploits and later real-world developments (such as the TS.48 test profile attack building on Java Card weaknesses) have “proven these concerns to be real bugs” that sophisticated adversaries (particularly nation-state actors) could exploitthehackernews.com.

The consequence of a successful low-level compromise of an eSIM’s OS are far-reaching. An attacker could extract the Ki (subscriber key) or operator certificates, allowing them to clone the SIM or eavesdrop on communication by impersonating the network. They could also modify the SIM toolkit applets or network profiles to create a stealthy backdoor, all while the SIM continues to appear “normal” to both the device and the networkthehackernews.com. For instance, an attacker with full SIM control could report a false network status to the carrier or disable the carrier’s ability to remotely revoke the profilethehackernews.com. In essence, the SIM – normally the hardware root of trust in a device – becomes an attacker-controlled spy node. Security Explorations ominously noted that “the ability for a single broken eUICC / single eUICC GSMA cert theft to peek into (download in plaintext) eSIMs of arbitrary MNO constitutes a significant eSIM architecture weak point”thehackernews.com.

These findings make it clear that rigorous security evaluation of the eSIM OS is critical. Many eUICC products undergo Common Criteria evaluation (e.g., EAL4+ certification) to validate their security, but the discovery of exploitable flaws even in certified products shows that certification needs to be complemented by ongoing vulnerability research and patching. We will later discuss how the industry is responding with updated protection profiles and requiring more dynamic security measures.

Remote Attacks: SIM Toolkit Exploits and OTA Attacks

Not all attacks require physical possession of the SIM/eSIM or insider keys. Some can be carried out remotely over the air, targeting either the SIM’s software interfaces or the provisioning infrastructure:

SIM Toolkit and SMS Attacks (Simjacker): In 2019, a cybersecurity firm uncovered a spying campaign using a technique dubbed Simjacker, which involved sending malicious SMS messages to target phones to control the SIM cardcert.europa.eu. The attack leveraged the SIM Application Toolkit (STK) – a set of instructions that SIM cards can carry out, often used for services like menus, over-the-air updates, or value-added services. In Simjacker’s case, a particular STK app called the S@T Browser (SIMalliance Toolbox Browser) was targetedcert.europa.eu. The attacker would send an SMS containing spyware-like STK commands; if the SIM had the S@T Browser installed (and not secured against such messages), the SIM would execute the commands on the device without any user awarenesscert.europa.eu cert.europa.eu.

The Simjacker payload could instruct the SIM to retrieve device information (like the IMEI and location data) and send it back via an SMS from the device itself to the attacker’s numbercert.europa.eu. Because this was all triggered at the SIM level, the user would not see any indication of an SMS or process – the messages are silent/hidden. Beyond just location tracking, researchers demonstrated that the STK commands could be used for a variety of nefarious purposes: making the device call premium numbers, sending texts (which could be used to spread malware or false information), opening browser links (potentially to exploit the phone), or even denial-of-service by disabling the SIM or overwhelming with commandscert.europa.eu cert.europa.eu. Essentially, Simjacker turned the SIM into a remote control malware that could hijack the phone’s modem and some OS functions.

What makes Simjacker particularly concerning for IoT is that it was not limited to smartphones. The attack depends on the presence of the vulnerable SIM app, not on the handset type. It was reported that “devices from nearly every manufacturer… and even IoT devices with SIM cards” were successfully targeted to retrieve location datacert.europa.eu. Many IoT devices (such as telematics units, vehicles, or smart trackers) use SIM cards and some may have STK applets installed by carriers for remote management. If those applets (like S@T or similar) are not locked down, an IoT device could be covertly forced to send its coordinates or perform other actions via something as simple as an SMS from an attacker. Unlike consumer phones, IoT devices often lack interfaces where a user might notice odd behaviors, making such attacks potentially stealthy for long periods.

Mobile operators responded to Simjacker by deploying SMS firewall rules to detect and block messages containing the known malicious patterns (e.g., specific binary SMS headers indicating S@T commands)cert.europa.eu. The GSMA and SIM manufacturers also pushed updates or guidance: for example, remotely disabling or removing the S@T Browser applet from SIMs where possible, or updating its security settings to ignore unauthenticated commandscert.europa.eu. The Simjacker case underscores the importance of minimizing the attack surface on SIM/eSIM – any built-in applet that is not strictly necessary, especially ones that accept network-triggered instructions, can become a liability. In eSIMs for IoT, often there is less need for things like a browsing toolkit, so a best practice is to exclude such components entirely from IoT SIM profiles or at least ensure they are secured (e.g. require secure SMS with cryptographic signatures).

SIM Swap and Profile Misuse: A more social-engineering type of threat that has carried over into the eSIM era is SIM swapping – where an attacker fraudulently convinces a mobile operator to transfer a victim’s phone number (and service) to a SIM the attacker controls. With physical SIMs, this typically involves tricking customer support. With eSIMs, one might assume the process is different (involving QR codes or activation codes delivered to the user). However, the risk remains: if an attacker can gather enough personal data and compromise a user’s operator account or trick the operator, they can initiate an eSIM profile download to their own device, effectively stealing the victim’s phone lineenisa.europa.eu. ENISA notes that an attacker could “claim the device is damaged and gain access to the subscriber’s account on the MNO’s portal, initiate an eSIM swap, and then scan the displayed QR code to activate the profile”, thus performing a SIM swap without needing physical possession of the victim’s SIMenisa.europa.eu.

For consumers, the result is identity theft and potential account takeover (intercepting calls/SMS, including two-factor authentication codes). In IoT, a variant of this threat could be an insider or adversary deliberately mis-provisioning devices. For example, in a factory setting, if eSIM profiles are managed via a console, an attacker with access might assign a batch of devices to their own network or rogue profiles. ENISA highlights that in industrial IoT environments, profile updates could be abused: “when these eSIMs are in IoT devices used in factory environments, they can be updated with a new configuration to make them join an attacker’s remote network, where data can be manipulated or added to the device”enisa.europa.eu enisa.europa.eu. In such a scenario, a hacker who gained control of the provisioning platform (or a malicious insider at the service provider) might redirect a group of sensors to send their data to a hostile server by swapping their profile to one controlled by the attacker. This is effectively a man-in-the-middle attack via profile provisioning – the devices remain connected, but not to the intended legitimate networks.

Mitigating SIM swap and provisioning misuse involves both process and technical controls: strong user identity verification for any profile changes, multi-factor authentication for carrier account access, and in IoT contexts, possibly locking profiles or using whitelisted networks (e.g., a device should normally only accept profiles from a predetermined operator or partner). We will discuss some protective measures in the mitigation section.

Supply Chain and State-Level Threats

The security of eSIMs cannot be looked at in isolation; it extends to the entire supply chain and ecosystem that produces and manages these secure elements. A number of past incidents show that adversaries – including well-resourced nation-state actors – may target SIM/eSIM infrastructure at scale:

The 2015 Gemalto Hack (NSA/GCHQ): In 2015, news reports (based on leaked documents) alleged that the U.S. NSA and U.K. GCHQ conducted a cyber-espionage operation against Gemalto – one of the world’s largest SIM card manufacturers – to steal SIM Ki keys and encryption key material in bulksecurityweek.com. By compromising the manufacturer or its suppliers, the attackers could obtain the secret keys that are pre-loaded onto SIM cards (including those later embedded as eSIM profiles). With those keys, an intelligence agency could potentially decrypt the cellular communications of millions of subscribers (since the SIM’s Ki is what’s used in the authentication algorithm to derive encryption keys for voice/SMS/data on 3G/4G networks). The Gemalto incident highlighted that the confidentiality of SIM/eSIM credentials is a juicy target – if you “hack the SIM company,” you bypass the need to hack individual devices.

While Gemalto (and governments) later gave statements downplaying the impact or claiming the attack was not fully successful, the incident spurred a reevaluation of SIM supply chain security. It demonstrated the risk of a single point of failure: if a single company makes a large share of SIMs or eSIM operating systems and that company is breached, the fallout can affect many mobile networks globally. In IoT, where a few module vendors or eSIM service providers might be used across fleets of millions of devices, a similar central compromise could be devastating. For instance, an attacker with access to an eSIM Subscription Manager system could potentially steal operator profiles or clone them.

Subscription Manager (SM) Compromise: Even without nation-state actors, the compromise of servers like SM-DP or SM-SR in the RSP ecosystem is a serious threat. These servers handle sensitive data – they have the “master copy” of operator profiles and often the keys to control eSIMs. ENISA warns that “a compromised or malicious SM-SR component can prevent MNOs and SM-DPs from installing subscribers’ profiles on eUICCs”enisa.europa.eu. In other words, a hacker in control of an SM-SR could perform a denial-of-service, blocking updates or new profile downloads to devices – effectively freezing connectivity management. Worse, if not properly secured, an attacker could use an SM platform to issue unauthorized profiles or commands. For example, a malicious SM-DP could intentionally create an “inflated profile” that consumes excessive memory on the eSIM (we’ll explain this concept next), or push profiles with malicious STK applets.

Profile and Policy Abuse: Research has identified some potential abuses of the profile management process itself. One such concept is the “inflated profile attack.” In this scenario, a malicious profile (possibly created by a compromised SM-DP or a rogue operator) is crafted to use up most of the eSIM’s storage memory, leaving little room for additional profilesenisa.europa.eu enisa.europa.eu. For instance, if an eUICC has space for, say, five profiles, an attacker could load a profile that intentionally fills ninety percent of that space with dummy data. The goal might be to lock a device to a single operator by preventing competitors’ profiles from being downloaded (a form of sabotage or anti-competitive lock-in). A related threat is setting malicious profile policies. Profiles have policy rules (often called Profile Policy or “POL1” rules) that can specify whether a profile can be disabled or deleted by the device user. A hostile actor could provision a profile with a policy that it “Cannot Be Disabled or Deleted,” thus making it permanent on the eSIM until a full reset is done. If that profile is also malign or tied to a specific network, it again locks the device’s connectivity. These kinds of abuses require either a breach of the profile issuance system or collusion by an unscrupulous service provider, but they highlight that not all threats are about cryptographic breakage – some are about abusing the legitimate management features of eSIMs.

In summary, the threat landscape for eSIM in IoT is broad:

Low-level vulnerabilities in eSIM software/hardware that enable deep compromise (e.g., TS.48 flaw, Java Card bugs).
Remote exploits through cellular interfaces (e.g., Simjacker via SMS, OTA key cracking).
Social-engineering and procedural attacks (eSIM swaps through fraud, misconfiguration).
Supply chain compromises (breach of eSIM manufacturers or provisioning servers).
Abuse of features (profile inflation, locking, or using test credentials inappropriately).

Each of these threat vectors must be countered by a combination of robust technical controls and governance measures. The next sections delve into the standards and frameworks that define how security should be achieved, and the concrete strategies to mitigate these risks in practice.

Security and Privacy Standards and Frameworks

Securing eSIM technology in IoT is not only a matter of individual best practices; it is guided by a comprehensive set of industry standards, certification schemes, and regulatory frameworks. In this section, we outline the key standards and frameworks relevant to eSIM and IoT security, with a focus on those particularly pertinent in Europe. These include GSMA’s eSIM specifications and security accreditation programs, international security evaluation standards like Common Criteria and SESIP (now an EU standard), as well as European Union regulations such as the Cyber Resilience Act and NIS2 directive. Understanding this landscape is crucial for stakeholders to ensure their deployments comply with state-of-the-art security requirements and are aligned with governance expectations.

GSMA eSIM Specifications and Compliance Programs

The GSMA (Global System for Mobile Communications Association) develops and maintains the core specifications for eSIM technology, covering technical architecture, security, and compliance. Key GSMA publications include:

SGP.01/02 and SGP.21/22: These define the M2M and Consumer eSIM architecture and technical specifications, respectively, as discussed earlier (covering how RSP works, interfaces, protocols, etc.).
SGP.11/23: Test specifications for eSIM to ensure interoperability.
SGP.05 & SGP.25: Security Protection Profiles for eUICCs. SGP.05 is for M2M eUICC and SGP.25 is for eUICC in consumer/IoT devices1nce.com 1nce.com. A Protection Profile is a document used typically in the Common Criteria certification context, describing the security objectives and requirements the product must meet. For example, SGP.25 (version 2.0) lays out the security and privacy features an eUICC must have – such as tamper resistance, secure key storage, resistance to side-channel attacks, etc., in order to protect profiles and credentials1nce.com.
SGP.14: eUICC PKI Certificate Policy, governing the public-key infrastructure that issues certificates to eSIM components (e.g., each eUICC has a certificate from a GSMA-trusted Certificate Issuer that is used to authenticate it in the RSP process)1nce.com 1nce.com.

Perhaps most importantly for ensuring security in practice, GSMA has defined an eSIM Compliance and Assurance framework:

SGP.24 – RSP Compliance Process: This document outlines the common compliance requirements and the process by which eSIM products (eUICC chips, device LPA implementations, and backend servers like SM-DP+) can be declared compliant with GSMA specificationsgsma.com 1nce.com. In essence, SGP.24 acts as a checklist and governance process – vendors run through specified test cases and security evaluations and then can self-declare or certify compliance. For instance, compliance ensures that an eUICC correctly enforces profile policy rules, that the RSP messages are implemented as specified, and that all security measures (like mutual authentication, secure channel protocols) are correctly in place. According to one reference, “SGP.24 outlines the compliance process for eUICC-capable devices and the basic requirements to reach this compliance”1nce.com. This includes meeting the relevant Protection Profile (SGP.25 or SGP.05) and passing interoperability tests. By following SGP.24, manufacturers signal that their product meets the baseline GSMA functionality and security expectations. Many MNOs and IoT service providers will require that the eSIM technology they use is SGP.24-compliant as a de-facto quality mark.
SGP.26 – eSIM Test Certificate: Complementing compliance, SGP.26 provides a scheme for eUICC providers to obtain test certificates indicating they passed interoperability and basic security testing1nce.com. This ensures, for example, that a given eSIM can download profiles from different SM-DP+ vendors, or that a device’s LPA works with multiple carriers’ QR codes, etc. While not a direct security certification, interoperability testing is crucial to security too – any lack of interoperability could be exploited (or cause fallbacks that create vulnerabilities).
GSMA Security Assurance Scheme (SAS): The GSMA runs the Security Accreditation Scheme (SAS) for both UICC production (SAS-UP) and Subscription Management (SAS-SM). SAS is not about the technical design of eSIM, but rather the security of the processes and facilities that handle sensitive eSIM assets (like SIM personalization centers, eSIM management data centers, etc.). As described in a GSMA-certified eSIM solution overview: “The GSMA established the Security Accreditation Scheme (SAS) to enable mobile operators to assess the security of their UICC/eUICC suppliers and their subscription management service providers. The GSMA SAS certification is the required security accreditation for eSIM entities handling sensitive assets, including MNO profile information and digital certificates.”iotforall.com iotforall.com. In other words, if a company is programming operator profiles or operating an SM-DP+ server that downloads profiles, they must be audited and certified under SAS to ensure proper physical and logical security controls are in place (background checks for staff, HSM usage for key storage, network security, etc.). European MNOs essentially mandate SAS certification for any partner providing eSIM services, making it a cornerstone of supply chain trust.
GSMA Certification for eUICC Security: In addition to SAS, GSMA coordinates security evaluations of eUICC products, often leveraging Common Criteria. For example, GSMA NESAS is a security assurance scheme for network equipment; similarly, for SIM/eSIM, GSMA works with accredited labs to evaluate chips against the aforementioned protection profiles (SGP.25, etc.). We can see references to specific GSMA security docs like SGP.08 and SGP.18 in the IoT context1nce.com – these likely relate to evaluation methodologies and requirements (PP-0117 referenced is probably a Common Criteria PP for SIMs). In practice, many eUICC chips advertise CC EAL4+ certification against a GSMA/GlobalPlatform PP, which gives confidence they have been independently tested for resistance to attacks. For instance, the Kigen eUICC that had the TS.48 issue was EAL4+ certified, yet still had the vulnerability – pointing to the need for continuous updates to these security requirements.

Why GSMA compliance matters: Following GSMA’s specifications and certification schemes is crucial for interoperability and baseline security. It helps ensure that an eSIM can securely switch carriers, that only authorized parties can manage profiles, and that known threats are mitigated. GSMA’s frameworks are global, but are highly relevant in Europe given European operators and IoT deployments predominantly adhere to them. Using a non-certified eSIM solution would pose significant risks; as one IoT industry publication put it, choosing a GSMA-certified eSIM solution means “it meets the highest quality and security requirements” and that it has been “vetted and certified by the GSMA”iotforall.com iotforall.com. Therefore, through GSMA’s standards, the industry has a common language and baseline for eSIM security. However, as we’ve seen with the TS.48 example, industry standards sometimes need to evolve after new findings – thus compliance is a necessary starting point, but not sufficient alone.

European Security Standards: EN 17927 (SESIP) and Common Criteria

Given the global nature of eSIM, much of the technical standardization is global (GSMA, ISO/IEC, etc.). However, Europe has been active in adopting and promoting certain security frameworks to support IoT and ICT product security, aligning with its regulatory needs. One prominent development is the adoption of SESIP (Security Evaluation Standard for IoT Platforms) as a European Norm (EN):

EN 17927 – SESIP: The Security Evaluation Standard for IoT Platforms (SESIP) was originally developed by GlobalPlatform as a simplified and optimized variant of Common Criteria specifically tailored for IoT components. In 2023, SESIP was adopted by CEN/CENELEC as EN 17927:2023, making it an official European standardglobalplatform.org appluslaboratories.com. SESIP provides a modular and flexible evaluation methodology, where a platform (like an IoT module or a secure element) can be certified for certain security features and resistance levels, and those certifications can be re-used or composed when building larger systems. The significance for eSIM is that a secure element implementing eSIM functionality could be evaluated under SESIP to provide assurance of its security properties, potentially in a more streamlined way than a full Common Criteria evaluation. SESIP is gaining traction as the EU’s preferred approach for IoT security certification because it maps well to the upcoming regulatory requirements. A GlobalPlatform press release notes: “GlobalPlatform’s SESIP methodology (EN 17927) offers a streamlined, cost-effective security framework for connected devices and components to conform to the EU’s new Cyber Resilience Act”, highlighting that SESIP is seen as a key enabler for meeting the EU law’s demandsglobalplatform.org globalplatform.org. By using SESIP, manufacturers can conduct rigorous security evaluations on IoT hardware/software (including eSIMs) that align with European laws and can lead to the CE marking for cybersecurity. In practical terms, if an eUICC chip has been certified with SESIP, it means it was evaluated for threats like physical tampering, side-channel attacks, fault injection, software exploitation, etc., and that it achieved a certain assurance level. The modularity means if the chip uses a certified crypto library or OS, those components’ certs can contribute. This can reduce cost and time for manufacturers aiming to demonstrate compliance with EU requirements.
Common Criteria and Protection Profiles: Prior to SESIP, Common Criteria (CC) was the main route for certifying SIM/eSIM security. Many eUICC products have CC certificates (e.g., against a SIM PP such as BSI-PP-0084 or GSMA’s PP). Common Criteria provides internationally recognized assurance levels (EAL1 through EAL7) and involves rigorous lab testing. For example, a CC EAL4+ certified eSIM means evaluators tried penetration attacks up to a certain sophistication and found the device met the security claims. Europe’s Cybersecurity Act of 2019 introduced an EU-wide framework for cybersecurity certification; one of the first candidate schemes under it is the EUCC scheme, basically aligning with Common Criteria for EU needs. So CC remains relevant, especially for high assurance needs. It’s worth noting a nuance: The recent vulnerabilities (like the Java Card issues) sometimes affected even CC-certified products, meaning that the protection profiles and evaluation methodologies need to be continuously updated. If a vulnerability is found, the PP should be revised so future certifications cover that aspect. For instance, after the 2019 Java Card flaws, the industry presumably updated requirements around applet isolation and bytecode verification.
Trusted Connectivity Alliance (TCA) and SIM standards: In Europe, industry associations like TCA (formerly SIMalliance) also contribute by publishing technical guidelines. For example, SIMalliance had published “Security Guidelines for S@T Push” to mitigate attacks like Simjackercert.europa.eu. While not formal standards, such documents often feed into the standards process or operator policies.

In sum, Europe leverages both global standards (GSMA, ISO Common Criteria) and European-specific standards (EN 17927/SESIP) to ensure eSIMs in IoT meet high security benchmarks. An IoT device maker in Europe might use an eSIM module that is GSMA-compliant, CC/PP certified and/or SESIP certified, thereby covering all bases. As regulations tighten, having these certifications will likely move from optional to mandatory.

Regulatory Frameworks: EU Cybersecurity and Privacy

The regulatory environment in Europe is increasingly demanding when it comes to cybersecurity of network-connected products. For stakeholders deploying eSIM-based IoT solutions, several EU-level regulations and directives come into play:

Cyber Resilience Act (CRA): This is a new EU regulation (formally adopted in late 2024) that sets forth cybersecurity requirements for products with digital elements, which certainly includes IoT devices. The CRA introduces mandatory baseline security requirements for hardware and software throughout the product lifecycle – from design and development to post-market supportglobalplatform.org. Manufacturers will need to self-certify and CE-mark their products for cybersecurity, or in some cases undergo third-party certification, to sell in the EU. The CRA specifically calls for measures like secure by design, protection of sensitive data, vulnerability handling processes, and more. For eSIM-enabled IoT devices, compliance with the CRA means that the eSIM component cannot be ignored – it’s part of the product’s security. If a vulnerability in the eSIM could compromise the device’s connectivity or data, the manufacturer is expected to have mitigations or a plan to address it (e.g., ability to update the eSIM firmware or profiles). The CRA is technology-neutral in wording but implicitly expects things like unique credentials, strong cryptography, and securing update mechanisms – all relevant to eSIMs. As noted earlier, EN 17927 (SESIP) is viewed as a key method to meet CRA requirements, meaning an eSIM platform with SESIP certification would ease demonstrating complianceglobalplatform.org. The CRA also mandates vulnerability disclosure and fixing obligations. If an eSIM vulnerability is discovered (like the TS.48 issue), under CRA the manufacturers and operators would have to coordinate disclosure (possibly via ENISA or national CSIRTs) and ensure patches are made available to users. This pushes for a more transparent approach compared to the past, where SIM vulnerabilities were often handled quietly within the telecom industry.
NIS2 Directive: The Directive on Security of Network and Information Systems (NIS2), effective from 2023/2024, updates Europe’s cybersecurity requirements for critical infrastructure and essential services. Telecommunications (including mobile network operators) are within its scope. NIS2 requires organizations to implement risk management measures, including supply chain security, and to report incidents. In the context of eSIM, this means telecom operators must consider eSIM infrastructure as part of their critical supply chain. A compromise in the eSIM ecosystem (e.g., a breach of an SM-DP provider, or a widespread vulnerability in eUICCs) could be an incident with reporting obligationsfreemindtronic.com freemindtronic.com. Operators and IoT service providers will need to ensure that their eSIM vendors adhere to strong security – likely by requiring GSMA certifications and keeping tabs on any vulnerabilities. NIS2 also emphasizes continuous risk management and monitoringfreemindtronic.com. This aligns with the earlier discussion that one-time certification (like GSMA’s) isn’t enough; runtime monitoring and the ability to respond to new threats is necessary. However, as an analysis pointed out, there’s a potential gap: MNOs might “remain blind to eSIM runtime behavior due to opaque OEM integrations”, meaning operators often trust that the eSIM inside devices is secure but they have little visibility into what’s happening inside itfreemindtronic.com. NIS2 pushes them to question that blind trust and possibly demand more transparency or controls.
GDPR (General Data Protection Regulation): While GDPR is primarily about personal data protection, it can come into play with eSIMs in two ways. First, eSIM profiles and identifiers (like IMSI, EID) could be considered personal data in some IoT use cases (e.g., if tied to individuals). Ensuring those are secure and not leaking is part of protecting privacy. Second, if an eSIM vulnerability leads to a breach of personal data (e.g., an attacker cloning SIMs to intercept communications), that could trigger GDPR breach notification requirements. The security measures on SIMs are partly to ensure confidentiality of communications (as per the EU ePrivacy directive too). In general, adherence to strong security standards for eSIM helps meet the GDPR’s requirement for “appropriate technical and organizational measures” to protect data.
Other relevant EU initiatives: The EU has a 5G Security Toolbox addressing the security of 5G networks, including potentially looking at supply chain of SIMs (since SIMs are part of the 5G ecosystem security, though the toolbox mostly focuses on network equipment). Also, the proposed eIDAS 2.0 regulation (for digital identity wallets) might indirectly relate if eSIM secure elements are considered for storing credentials (some proposals exist to use SIM/eSIM as secure storage for government-issued digital IDs – that would add a whole new dimension of security requirements).

In summary, Europe’s regulatory stance is reinforcing what the technical standards prescribe: secure development, thorough evaluation, continuous monitoring, and accountability. The combination of GSMA’s industry standards with EU’s legal requirements means that any weakness in eSIM security is not just a technical issue, but could have legal consequences (e.g., product recall under CRA, fines under NIS2/GDPR, etc.).

For example, the Freemindtronic analysis of the Kigen breach put it starkly: the incident “exposes a legal grey zone where sovereignty, industry self-regulation, and supranational cybersecurity policies intersect”, questioning whether relying solely on GSMA certification is enough under EU lawfreemindtronic.com freemindtronic.com. With CRA and NIS2, regulators may demand more robust assurances (like runtime security monitoring, or state actors might want national certification in addition to GSMA’s). There is an ongoing balancing act between global industry frameworks and local regulatory oversight.

IoT and Privacy Frameworks

Beyond pure security, privacy considerations in IoT connectivity are also addressed by standards and guidelines:

GSMA IoT Security Guidelines: GSMA has published general IoT security best practices (not specific to eSIM, but including network elements). Ensuring the confidentiality of communication (often via network encryption which SIMs facilitate) and avoiding hardcoded credentials are part of those guidelines. eSIM helps some privacy aspects by, for instance, eliminating the need for transmitting SIMs physically (which could be intercepted).
ISO/IEC 27001/ISO 27701 for IoT services: IoT connectivity providers handling eSIM profiles might get certified in these management standards to show they properly manage security and privacy.
Privacy by Design in SIM: Modern SIM standards ensure that data like phonebook or usage profiles can be kept secure. In an IoT context, one might consider that an eSIM could hold sensitive application credentials (in some cases eSIM can host applets like secure key storage for applications). Ensuring that personal or sensitive data on the SIM is protected by the same tamper-resistance as network credentials is part of privacy protection.

In conclusion, the framework of standards and regulations influencing eSIM security in IoT is multi-layered. At the core are GSMA’s technical standards and security certifications (GSMA compliance, SAS, Protection Profiles), which provide the blueprint and baseline assurances. Wrapping around that are broader security evaluation standards like CC and SESIP, which ensure the devices meet high assurance levels recognized by regulators. And on top of all are the EU regulations (CRA, NIS2, GDPR, etc.) that mandate the implementation of these best practices and create legal accountability. Stakeholders should track both the technical standards evolution (e.g., new GSMA specs like SGP.32 or updates in PP requirements) and the regulatory changes (e.g., CRA’s timeline for mandatory compliance by 2027) to remain compliant and secure.

Risk Mitigation Strategies

Addressing the threats identified in the eSIM/IoT landscape requires a multi-faceted approach. Technical hardening must go hand in hand with procedural controls and oversight. In this section, we outline concrete strategies for mitigating risks, organized into key areas: device-level (hardware/software) hardening, network/OTA protection measures, supply chain security, and operational governance. The goal is to provide actionable guidance for each stakeholder – whether you are an eSIM manufacturer, an IoT device OEM, a mobile operator, or a company deploying IoT solutions – to bolster the security of eSIM-enabled systems.

1. Secure Hardware and OS Design

Use High-Security eUICC Hardware: The foundation of eSIM security is the secure element chip. Organizations should procure eUICCs that come with strong tamper-resistant designs and relevant security certifications (Common Criteria EAL4+ or above, SESIP evaluation, etc.). These certifications ensure the chip has countermeasures against physical attacks like voltage manipulation, fault injection, side-channel (power or electromagnetic analysis) attacks, and so on. While certification is not a guarantee of perfection, it significantly raises the bar for attackers. Prefer chips that meet the latest Protection Profiles (e.g., GSMA SGP.25 v2 or BSI PP0084), as these profiles incorporate lessons learned from recent vulnerabilities. For instance, after the 2019 Java Card issues, ensure the eUICC’s OS version has fixes or mitigations for those underlying problems (some vendors enhanced runtime checks in Java Card, etc.). If using integrated SIM (iSIM) solutions, verify that the secure enclave in the system-on-chip is isolated and evaluated to similar standards.

Disable or Restrict Test/Debug Functions in Production: As the TS.48 vulnerability showed, leaving test mechanisms enabled in a deployed device can be dangerous. Manufacturers must ensure that any test profiles or default test keys are completely removed or disabled on eSIMs before they are shipped. The GSMA TS.48 v7 update basically enforces this by designkigen.com. Additionally, development backdoors or debug interfaces on the eUICC should be locked. Many secure elements have a lifecycle state (e.g., “production” or “operation” state) which, once set, permanently turns off debug ports or test commands. This state should be irreversibly set before the device is in the field. The device OEM should confirm with the eSIM supplier that no known test credentials or shared keys remain active. As Kigen recommended, “the GSMA Generic Test Profile is not recommended for use in any production environment”kigen.com – a principle that can be generalized: no test mode in production.

Java Card Hardening: For eSIM operating systems based on Java Card, apply defense-in-depth at the VM level. Vendors should incorporate runtime checks to prevent abnormal applet behavior. For example, Kigen’s post-incident patch “prohibits JavaCard Applet installation on any Test Profile” and includes “further security hardening”kigen.com kigen.com. This presumably might involve additional bytecode verification or memory bounds checks. Because some vulnerabilities exploited the Java Card firewall and memory management, having an updated Java Card VM (the latest spec version, with known issues patched) is vital. If possible, use eSIM OS that supports applet bytecode verification either at load-time or run-time, to catch any malicious code that somehow slips through signing checks.

Minimalist SIM Toolkit and Applets: Many eSIMs, especially for IoT, do not require the full suite of SIM Toolkit applications that legacy SIMs carried. If your IoT deployment does not need SIM Toolkit (which is often the case, since there’s no user to interact with menus or run value-added services), request eSIM profiles with no SIM Toolkit applets beyond what’s strictly necessary (for instance, perhaps a basic network handshake applet, if any). In particular, functionalities like the S@T Browser or obsolete proactive command interfaces should be excluded. By reducing the on-card software, you reduce attack surface. For necessary toolkit apps, ensure they are configured securely: for example, set them to only accept network commands that are secured (with cryptographic signatures via SMS-PP data download keys, etc.)cert.europa.eu. Operators can send OTA updates to configure STK applets’ security domains – as recommended after Simjacker, “mobile operators could change the security settings of UICCs remotely, or even uninstall S@T Browser technology completely”cert.europa.eu. IoT manufacturers should coordinate with carriers to apply those settings on any devices in the field.

Memory and Profile Management Protections: Implement logic to prevent profile misuse attacks like “inflated profiles” or “profile locking.” An eUICC’s OS could, for example, refuse to install a profile that declares an unreasonably large memory footprint or that has conflicting policy flags. Some eSIM OSes might enforce that at least X% of memory is kept free, or that the user (or M2M controller) must explicitly approve if a new profile installation will disable others. While the primary mitigation is at process (only allow trusted SM-DPs), having technical stops helps in case those processes fail. Additionally, ensure robust memory management – e.g., garbage collection or defragmentation on the eUICC should handle attempts to fill memory gracefully (not crash or deadlock).

Regular Security Updates Capability: Traditionally, SIM cards were not field-updatable except for operator-controlled applets. However, with eSIM, there is an opportunity to apply updates if the architecture allows it. Some eUICCs can receive OTA firmware updates (this is still not very common, but conceptually supported in newer designs). If your eSIM platform supports secure firmware updates, have a maintenance plan to deploy them when vulnerabilities are discovered. If not, consider using the eSIM’s ability to load security patch applets. For example, a special “security patch” Java Card applet could potentially be loaded (with operator authorization) to monitor or override a vulnerable function on the SIM. This is advanced and would require coordination with the eSIM vendor. At minimum, ensure the device OS can monitor the eSIM’s behavior to detect anomalies (this crosses into runtime monitoring, discussed later).

2. Secure Remote Provisioning and OTA Channels

The remote aspect of eSIM – delivering profiles and sending commands over-the-air – introduces network-based risk, but these can be managed with strong cryptographic protocols and vigilant network security:

Strictly Enforce Profile Provisioning Security (SM-DP+): The entire RSP procedure is normally protected by multiple layers: TLS tunnels, ASN.1 cryptographic messages, certificates, etc. Ensure that your SM-DP+ (for consumer eSIM) or SM-DP/SM-SR (for M2M) implementations follow GSMA specs to the letter and use up-to-date cipher suites. As the formal analysis by academia indicated, the security depends on these layers working properly – “the security of RSP depends unnecessarily on it being encapsulated in a TLS tunnel”arxiv.org, and they identified weaknesses if any participant is compromised. So use modern TLS (1.2+ with strong ciphers, ideally TLS 1.3) for all communications between device, SM-DS, SM-DP+. Also, consider pinning certificates or using private APNs/VPNs for connecting IoT devices to the provisioning servers, to reduce MITM risk beyond TLS.

Authenticate All Network Instructions to eSIM: Whether it’s an SMS carrying an order (as in M2M case, SM-SR can send SMS to trigger profile download) or an HTTP exchange for consumer devices, ensure messages are authenticated. For instance, M2M SM-SR messages should use HTTPS or SMS-PP data with 3DES/AES cryptographic OTAs as per GSMA security guidelinesenisa.europa.eu enisa.europa.eu. If any OTA keys use older algorithms (e.g., DES), those should be rotated out – recall that Karsten Nohl’s 2013 attack targeted SIMs still using DES OTA keys. Operators should by now use AES-128 or stronger for OTA encryption and signing.

For consumer eSIM, the LPA should validate that any profile it’s about to download is coming from a trusted SM-DP+ (this is done via the matching of activation codes and the root certificate chain). Systematically reject any unsolicited or unexpected profile download prompts.

Monitor and Filter SMS to SIM (Home Network Protection): Mobile operators can deploy network filters for suspicious messages targeting SIM toolkits. As recommended in response to Simjacker, “analyse and block suspicious messages that contain S@T Browser commands” at the network levelcert.europa.eu. Extending that, operators can filter or rate-limit binary SMS that go to IoT SIMs which shouldn’t normally receive them. For example, if an IoT device is not expected to ever receive SIM OTA messages except from a specific operator source, then any such message from elsewhere could be dropped. Many carriers have deployed SMS firewalls that can detect known attack signatures (like those of Simjacker, WIB attack, etc.). Ensure your connectivity provider has such protections, and for private IoT networks, consider an MVNO arrangement where you have visibility into SMS traffic.

Two-Factor or User Confirmation for Profile Downloads (Consumer devices): For consumer-oriented eSIM, one mitigation against SIM swaps is to require an extra confirmation step. For example, some carriers send a one-time code to the old SIM or registered email/phone of the user when an eSIM download is requested. The user must confirm that code to proceed. This can thwart attackers who rely on just account password compromise. Device-side, OSes (iOS, Android) have started showing notifications like “A new cellular plan is being added – allow or reject.” Encourage users to keep these notifications on and educate them. In enterprise scenarios, an admin portal could list all eSIM provisioning events for audit.

Profile Policy Controls: Leverage the eSIM’s own policy settings smartly. If you as an enterprise issue devices that should never have a second profile from another operator, you might intentionally set a policy to disallow additional profiles (or to lock the profile to always enabled). Conversely, if you want flexibility, allow multiple profiles but ensure the primary connectivity cannot be easily disabled remotely (for instance, require a device management command to approve disabling the main profile). Some M2M profiles support a “profiling” where only authorized SM-SRs can remove them. Utilize that: register your devices to only accept profile management from your designated SM-SR, rejecting others.

Rapid Deactivation and Revocation: In case of suspected compromise, having the ability to quickly deactivate a profile or revoke an eSIM’s certificate is crucial. Mobile operators can send a management command to disable a profile or even wipe it if needed (this is part of RSP functionality). Develop an incident response playbook: e.g., if an IoT device is stolen or tampered, command it to erase its profile to prevent misuse. Similarly, if an eUICC’s certificate is known to be compromised (as feared in the Kigen case), GSMA can revoke that certificate in the root CI system – network operators should then refuse to download profiles to that eUICC. Currently, one critique was the lack of clear post-compromise revocation in GSMA’s schemefreemindtronic.com freemindtronic.com. Pushing for such mechanisms (and using them if available) will limit damage from one rogue card.

3. Supply Chain and Provider Security

Choose GSMA SAS-Certified Providers: As highlighted earlier, GSMA SAS certification is effectively mandatory for trust in eSIM servicesiotforall.com. When selecting eSIM vendors (whether it’s the card manufacturer, the OS provider, or the subscription management service), ensure they are SAS accredited for their respective roles (SAS-UP for production, SAS-SM for SM-DP/SM-SR operation). SAS audits cover physical security (e.g., guarded facilities, background checks), logical security (access controls, network segmentation), and process security (key management procedures, etc.). This dramatically reduces the risk of insider threats or external breaches. The Gemalto hack, for instance, likely spurred even tighter SAS requirements in subsequent years, such as better intrusion detection at these facilities.

Vetting and Contracts: Perform due diligence on eSIM suppliers beyond their certifications. Assess their track record: have they had security incidents before? How did they handle them? Ensure contracts include clauses about security obligations – e.g., the provider must notify you within X days of any breach or vulnerability affecting their product, they must support patching or replacing compromised eSIMs, etc. Where possible, diversify critical dependencies: for a large IoT rollout, you might source eSIM profiles from two different SM-DP vendors so that a failure or breach in one doesn’t cripple your entire service (this can be complex, but some IoT connectivity platforms allow multi-IMSI or multi-profile redundancy).

Secure Manufacturing and Personalization: If you are an OEM embedding eSIMs into your devices, secure the supply chain from the factory. eUICCs are often delivered in bulk with initial bootstrap profiles. Ensure the transport of those (both physical shipment and digital profile files) is encrypted and insured. Use tamper-evident packaging for eSIM modules. Implement incoming inspection to verify that the chips you received match what was ordered (to avoid any “man-in-the-middle” hardware swap, albeit unlikely). For personalization of profiles (if done by a third party), require that they follow secure procedures, like destroying any plaintext copies of profiles after they are installed and using HSMs to handle the keys.

Operator Coordination and NDAs: Telecommunication operators and IoT service providers should strengthen coordination on eSIM security. For instance, have NDA-backed info sharing where an eSIM vendor can quickly inform all its operator customers about a newly found vulnerability (as Kigen did in July 2025 with its bulletinkigen.com). Operators should also share any strange behavior observed (e.g., an unusual pattern of authentication failures that might indicate cloned SIMs) with the vendor and possibly with industry groups or authorities.

Independent Security Testing: In addition to trusting vendor certifications, large-scale deployers might commission independent pentesting or code review of eSIM components where feasible. While the eUICC itself is a closed system, one can test the surrounding parts: for example, have experts attempt to abuse the RSP server’s API (are there logic flaws, like issuing a profile without proper auth?), or fuzz the LPA interface on devices for any weakness. Some researchers already do public analysis (like the formal verification of RSParxiv.org); engaging with the security research community through bug bounty programs or partnerships can bring to light issues before adversaries do.

Incident Response Readiness: Secure supply chain also means preparing for the worst-case: If a batch of eSIMs is found faulty or compromised, how quickly can they be replaced or their profiles migrated to new secure eSIMs? This might involve having an inventory of spare eSIMs or the ability to remotely swap credentials to a new SIM if needed (e.g., in some IoT designs, you might have dual SIM slots or an internal backup). Develop contingency plans with your suppliers for recall scenarios.

4. Best Practices in Operations and Governance

Continuous Monitoring and Anomaly Detection: One of the challenges with eSIM (and SIMs in general) is that once deployed, they are somewhat of a black box – telcos assume they’re working as intended. However, as nation-state threats and advanced cybercriminals eye SIMs, it’s prudent to monitor for signs of compromise. This could include:

Monitoring unusual location update patterns or simultaneous usage of what should be a unique profile (which could indicate cloning).
Monitoring the network for any eSIM profiles that have unknown or out-of-policy certificates.
Using the device’s telemetry: If a device’s baseband can report how many profiles are present or any error conditions, analyze that centrally. For example, if a device suddenly has an extra profile you didn’t provision, that’s a red flag.
In critical IoT deployments (like smart grids), you might implement an attestation challenge: the device and SIM could occasionally be challenged to prove they’re running known firmware. This is more speculative, but research is pushing toward runtime attestation for trusted execution environments – similar concepts might be applied to SIMs in the future (some proposals exist to have the eSIM prove it hasn’t been tampered by using secure counters or signing a nonce with an internal private key).

Align with NIS2 and CRA Compliance: Map the technical measures to the requirements in these regulations. For example, NIS2 requires “secure development and vulnerability handling” – ensure you have a formal process to accept vulnerability reports for your IoT devices (maybe via a vulnerability disclosure policy) that would include eSIM issues, and that you can distribute patches or mitigations (as we discussed). The CRA requires manufacturers to provide security support and updates for the expected product lifetime – if your device uses eSIM, that implies working with eSIM vendors so that they will also support security for that period. This may influence vendor selection (choose one that has a good support lifecycle).

Privacy Considerations: Implement privacy by design with eSIM data. For instance, avoid using static identifiers like ICCIDs or EIDs in ways that could leak user identity or device identity unnecessarily. If you log eSIM events, protect those logs as they might contain IMSIs. Also, consider that eSIM allows devices to have multiple profiles – separating personal and work profiles can enhance privacy (work can’t monitor personal usage, etc.). Encourage policies that use that capability ethically.

Governance Models – Roles and Accountability: Establish clear governance for eSIM management in your organization. Who is allowed to initiate a profile swap or an eSIM provisioning event? Use Role-Based Access Control for any eSIM management console – only specific admin users or API accounts should have that ability, and require MFA and logging of those actions. If working with a telecom operator’s platform, ensure that they provide audit logs of all profile management operations on your IoT SIMs.

From a broader perspective, consider an internal “eSIM security champion” – someone or a team that stays current on eSIM security news and ensures the organization adapts. They would liaise with operators and manufacturers, track GSMA working groups if possible, and influence product design to be secure.

Sovereign Security Concerns: For governments or critical infrastructure in Europe, the notion of digital sovereignty comes in – trusting a non-European private consortium (GSMA) wholly for security might be uncomfortable. We see suggestions of augmenting that with sovereign oversightfreemindtronic.com freemindtronic.com. For instance, EU agencies (ENISA or others) might set up their own evaluation of eSIM technologies used in power grids or defense communications. If you operate in these sectors, be prepared for additional compliance checks or certification requirements mandated by national authorities on top of GSMA’s.

User and Administrator Education: Though eSIM is low-level tech, people are still part of the system. Educate your operations team about threats like SIM swap and social engineering. For example, they should be wary if they get an email claiming to be from the carrier asking for eSIM identifiers or activation codes unexpectedly. Likewise, if you have consumer-facing products, educate end-users: e.g., “If you get a notification of a new eSIM profile being downloaded that you did not initiate, contact support immediately.” Awareness can catch attacks in progress.

Update Agreements and SLAs: Include security performance in service level agreements with providers. For instance, an SLA could specify that if a vulnerability is found in the eSIM or SM platform, the vendor must provide a remediation plan within X days. Also include regular test results – perhaps ask for a yearly pen-test summary of their SM platform or a re-certification letter.

Plan for Future Crypto Upgrades: Looking ahead, plan for how you will handle cryptographic agility. SIMs currently use algorithms like MILENAGE or TUAK for authentication, which are symmetric key based and considered secure. But with the advent of quantum computing (still likely years away for breaking symmetric keys), there may be a need to update authentication methods or key lengths. Ensuring eSIM and network components can support newer algorithms (for example, 5G allows EAP based methods and could potentially allow post-quantum algorithms in the AKA procedure in the future) is a future-proofing step. Also, eSIM certificates (the ones from the Certificate Issuer) might migrate to post-quantum cryptography in coming years – be ready to handle that transition (for example, support dual-certificates or firmware updates to add PQC algorithm support on the eSIM).

Collectively, these mitigation strategies form a defense in depth. By securing the eSIM at the hardware level, locking down the software features, protecting the communication channels, vetting the ecosystem participants, and actively monitoring and governing the use of eSIMs, stakeholders can significantly reduce the risk of both mass-scale attacks and targeted intrusions. In the next section, we will illustrate how some of these measures could have prevented or limited damage in real-world incidents via case studies.

Case Studies of Real-World Incidents

To ground the discussion in reality, we examine several case studies of security incidents and vulnerabilities involving SIM/eSIM technology. These cases span from well-documented historical attacks on traditional SIM cards to the most recent exploits targeting modern eSIM platforms in IoT devices. Each case provides insight into the tactics used by attackers and the weaknesses they exploited, as well as lessons learned and how the industry responded. Understanding these incidents helps in appreciating why the mitigations described above are necessary.

Case Study 1: SIM OTA Encryption Hack (Karsten Nohl’s 2013 Attack)

Background: In 2013, security researcher Karsten Nohl revealed a vulnerability affecting a large number of SIM cards that used outdated cryptography for carrier OTA (Over-the-Air) updates. At the time, many SIMs used the DES (56-bit key) cipher to authenticate OTA messages (which are used by operators to remotely provision SMS updates, change settings, etc.). Nohl discovered a flaw where he could send a SIM an OTA SMS with an invalid signature. The SIM would respond with an error message containing data that leaked information about the signing key (a form of padding oracle attack). By analyzing these responses, Nohl was able to recover the OTA key for the SIM within minutes in some casessecurityweek.com.

With the OTA key (and since some SIMs also still used default keys or predictable values), he then was able to send a fully authenticated malicious SMS to the SIM, for example, to install a Java applet on the SIM card. Essentially, this was a remote code execution on the SIM via SMS. The payload applet could perform actions like cloning the SIM’s identity or sending premium messages, etc. This attack was sensational because it didn’t require physical access and could be done at scale with just knowledge of the phone number or IMSI of targets.

Impact: It was estimated that up to 750 million SIM cards might have been vulnerable at the time of disclosure, particularly those using older 56-bit DES for OTA and not implementing newer security measures. The attack showed that a determined hacker could potentially impersonate a mobile network operator to a SIM card, and thereby remove the fundamental trust barrier. They could steal credentials or sign malicious SIM Toolkit commands.

For example, Nohl demonstrated he could send an OTA command to have the SIM send premium SMS (thus stealing money from the victim by charging those texts), or even to activate certain SIM toolkit menus that could be used for phishing. In principle, once he had code running on the SIM, he could perform cryptographic operations with the SIM’s keys or redirect communications.

Response: The industry responded by accelerating the phase-out of DES OTA keys in favor of Triple DES or AES, which are not susceptible to the same cracking (and have longer keys making brute force impractical). Also, additional integrity checks were introduced in standards for OTA message handling to not divulge info in error messages. Many operators did silent updates or card replacements for affected SIMs. It highlighted the need for cryptographic agility and not relying on obscurity (many telcos assumed the OTA channel was not known or targetable by hackers – Nohl proved otherwise).

Lessons: This case underscores a few points:

Weak or legacy cryptography in SIM infrastructure can be a glaring hole – and once broken, it threatens all devices using those SIMs. Thus, continuous review of cryptographic algorithms in use is vital.
It showed that SIM cards, despite being “secure”, could be compromised by a purely remote, radio-based attack. This was a wake-up call that SIMs needed to be part of the threat model, not taken for granted.
The attack also foreshadowed the Java Card vulnerabilities discussion: it was a scenario where, if you can load a Java Card applet (by tricking the SIM to think you are the operator), you can then exploit any Java Card-level flaws to take complete control. It’s likely Nohl’s work in 2013 inspired deeper research like Security Explorations’ 2019 worksecurityweek.com.

For IoT, many of which rolled out after 2013, presumably their SIMs used better security from the start (e.g., no DES). But the general principle – always deprecate outdated crypto and protocols in SIM management – remains relevant, especially as we look toward potential quantum threats.

Case Study 2: Theft of SIM Keys – The 2015 Gemalto Breach

Background: In 2015, investigative journalists citing Edward Snowden’s documents reported that the U.S. NSA and U.K. GCHQ had, in a joint operation, hacked into internal networks of Gemalto, a major SIM card manufacturer, and other telcos to steal Ki keys (the subscriber identity keys) in bulk. If true, this operation (“DAPINO GAMMA” as a codename in some documents) would have given the agencies the ability to decrypt a huge amount of cellular communications without needing to obtain a warrant per target – simply by having the SIM’s Ki, they can compute the encryption keys used in 3G voice/SMS or even derive LTE keys (though LTE has some network protections).

Gemalto, headquartered in the Netherlands, produces SIM cards for many operators worldwide, including in Europe. The breach was said to have occurred around 2010, targeting Gemalto’s office networks and possibly the systems where encryption keys were transferred between the company and mobile network operators.

Impact: The full impact remains somewhat unclear (Gemalto claimed that while their office network was compromised, highly sensitive data like Ki keys were on segregated secure networks not breached). However, if keys were stolen, the adversaries could effectively clone SIMs or more easily perform passive eavesdropping on mobile communications. With the Ki, one can impersonate the subscriber to the network or derive session keys if the network doesn’t enforce additional checks.

Even if only a portion of keys were taken, the sheer scale – Gemalto has produced billions of SIMs – meant potentially millions of users were affected. For IoT, if the same happened to an M2M SIM supplier, an attacker could impersonate or listen in on, say, a fleet of smart meters or cars. Given that many IoT devices were just coming online then, it’s not known if IoT-specific eSIM keys were part of any theft, but certainly possible for M2M SIMs.

Response: The revelation caused a stir in Europe. There were calls for investigations. Gemalto conducted an internal audit and announced that while some data was breached, their SIM production processes remained secure. Regardless, mobile operators began to consider implementing additional network security: for example, using LTE encryption with network-provided random challenges (which make having just Ki insufficient to decrypt without also compromising network equipment). Some operators in sensitive sectors explored IMSI encryption solutions (to avoid passive IMSI catching and tracking). The incident also emphasized adopting Over-the-Air key rotation – some SIMs can receive updated keys or use algorithms like MILENAGE which incorporate operator-specific root keys beyond the Ki.

On the governance side, it highlighted the need for strict security in SIM personalization centers (which GSMA’s SAS already covered) and perhaps to reduce centralized repositories of keys. If keys are generated inside a secure module and never leave, it’s safer than transferring them over networks.

Lessons: The Gemalto case serves as a stark reminder that the supply chain is a target for the most advanced adversaries:

Even if your device or network is perfectly secure, if the secret keys were stolen at birth (in the factory), your security is illusory. This justifies the extensive supply chain controls (SAS audits, HSM usage) now standard.
It also suggests that diversification might be wise: not having a single supplier for all SIMs in critical systems can limit damage (though it introduces complexity).
For national security, it raised the question of whether relying on foreign or commercial entities for critical crypto keys is prudent. Post-Snowden, some countries considered developing indigenous SIM technology or at least demanded better oversight.
For IoT projects, one extrapolation is to ensure that if you use eSIM profiles, the generation and handling of those profiles by the SM-DP is done in a zero-trust manner. Some new techniques involve eSIM profiles that are generated on the fly and immediately pushed, rather than stored – minimizing windows of exposure.

Case Study 3: Simjacker – SIM-based Spyware in the Wild (2019)

Background: Discussed earlier, Simjacker was a real-world attack observed in the wild (believed to be used by a private company working with government clients, possibly for surveillance in certain countries). The attackers used the S@T Browser toolkit on SIM cards by sending specially crafted SMS messages. The main observable effect was covert location tracking of mobile phones over an extended period. AdaptiveMobile Security, which discovered it, found that hundreds of messages were sent to target numbers, fetching their location and IMEI, and sending it to a control number via SMScert.europa.eu cert.europa.eu.

What made Simjacker particularly notable is that it was actively exploited across at least 30 countries and over potentially 1 billion SIMs were at risk if they had the S@T appletcert.europa.eu. It was not just a lab attack; it was an intelligence operation tool.

Impact: The confirmed impact was espionage – individuals were being tracked without their knowledge by a hidden capability of their SIM. Additionally, the potential for other misuse (which the researchers demoed) meant that those with knowledge of the method could do more harmful things (like the misinfo, fraud, etc., listed in the CERT-EU advisorycert.europa.eu). Even IoT devices could be impacted if they had the vulnerable toolkit: for example, imagine a connected car’s SIM receiving a command to send an SMS – it could potentially be tricked to send an SMS to premium number, incurring cost to the fleet owner.

Operators who learned of this had to act quickly to implement SMS filtering and to work with SIM vendors on remediation. It’s worth noting that the vulnerability wasn’t a bug in code per se, but an overlooked legacy feature being abused. S@T was an older standard not widely used legitimately by then, which is why many operators weren’t monitoring it.

Response: The immediate mitigations were network-based: block or tarpitted messages containing the S@T Browser binary SMS address. SIMalliance (now TCA) issued security guidelines specifically advising turning off S@T or setting it such that any incoming command requires confirmation (which would defeat silent exploitation)cert.europa.eu. They likely also advised on removing the applet via OTA where possible.

Longer term, it prompted a review of SIM Toolkit security. Many operators decided to not include optional toolkits like S@T or WIB in future SIM profiles, or to at least configure them with high security (requiring encryption or disabling sensitive commands like SEND SMS from those apps). There was also a push to make sure all SIM toolkit activities would be logged or rate-limited by the SIM OS – e.g., a SIM could have internal limits like “don’t send more than X SMS per minute via toolkit” to stop abuse.

Lessons: Simjacker’s saga emphasizes:

Legacy functionality can be low-hanging fruit for attackers. Just because something was old and assumed obscure doesn’t mean it’s safe. Security by obscurity utterly failed here.
Visibility is crucial. Victims had no way to know their SIM was doing these things. Perhaps user-facing OSes could have given clues (some phone firmware do log STK events, but none surfaced silent ones). It calls for better transparency – maybe an idea is for mobile OS to show an icon if the SIM sends a message or performs a significant action.
For IoT, which often lacks any UI, the device owner must rely on network monitoring. If an IoT SIM started sending data SMS to unknown numbers, that should trigger an alert in the IoT management system.
It demonstrates the potential for mass-scale attacks on SIMs – one SMS could potentially be sent to millions of devices (like a worm) if not filtered. This is akin to network-based worms in IT systems, but for telecom.
Another takeaway: When deploying new SIM or eSIM profiles, one should consider what toolkit and extra apps are loaded by default. The minimal profile principle comes back – if the profiles in target devices lacked S@T entirely, they’d be immune.

Case Study 4: eSIM Profile Cloning Vulnerability (Kigen 2025)

Background: The most recent case is the GSMA TS.48 test profile vulnerability discovered and disclosed in 2025 (detailed in earlier sections). To recap, the issue lay in the eSIM operating system’s handling of a test profile that had known keys and allowed a form of remote applet management. A security research firm (AG Security/Security Explorations) exploited this to install a malicious applet on a Kigen eUICC, which then could extract the eSIM’s unique identity certificate and private data over time9esim.com thehackernews.com. Armed with that certificate, the researchers demonstrated they could impersonate that eSIM to mobile operators, even downloading profiles in plaintext that should have been encryptedthehackernews.com. It effectively broke the trust model of eSIM provisioning: a compromised eUICC could fool operators and violate the expectation that profiles remain encrypted and controlled.

Impact: Kigen indicated over 2 billion IoT devices used their SIM OS as of 2020thehackernews.com, which suggests a huge scope of potential impact. Now, not all those devices would be vulnerable – as they said, many eUICCs cannot be forced into test mode or don’t have known keyskigen.com. However, even a fraction being vulnerable could mean millions of devices at risk of compromise or cloning.

If attackers in the wild managed to do this (even though physical access is needed initially), it could be weaponized by state actors who might, for example, intercept devices in transit, exploit the SIM, then let them be deployed “backdoored.” Once compromised, that eSIM could act as a mole, letting the attacker clone its profile or monitor traffic. For IoT, if an energy grid sensor’s eSIM is cloned, the attacker could create a twin device on the network to feed false data or snoop on network traffic. Moreover, because the flaw potentially allowed disabling operator control (the operator might think the profile is fine while the attacker manipulates it)thehackernews.com, it undermines the ability to trust eSIM management.

Response: The discovery was handled responsibly. GSMA fast-tracked an update to the TS.48 spec (v7.0) to eliminate the risky behaviorthehackernews.com. Kigen released a security bulletin and patches: they “issued an OS patch, and contributed to the GSMA TS.48 v7.0 specification”kigen.com. The patch included blocking of any applet installation in test profiles and removing default test keys unless explicitly needed in a labkigen.com. They also introduced a notion of “safer test profiles” that would only be loaded with random one-time keys, so even if such a profile were left on a device, an attacker couldn’t know the keys to abuse itkigen.com.

Furthermore, Kigen’s bulletin provides good advice that others likely follow: “Most eUICCs are not vulnerable – many cannot be forced into test mode or lack exposed known keys”kigen.com – essentially encouraging manufacturers to ensure exactly that, and “updated Kigen OS now prohibits JavaCard applet installation on any Test Profile.”kigen.com In addition, the incident sparked discussion on the industry’s incident response. It involved coordination between a private lab, the vendor, and GSMA’s eSIM Working Groupkigen.com, showing a positive example of handling a 0-day in telecom space transparently (even a public blog by The Hacker News covered it widely, which is more open than older SIM issues that stayed within telecom circles).

Lessons: This case synthesizes many issues:

Even highly secure, certified devices can have corner-case vulnerabilities. It reinforces that “security is a process, not a product.” Continual review and updates are needed; certification processes like GSMA SGP.24 must evolve to cover new insights (likely now including checks for test profile misuse).
The importance of responsible disclosure and patch distribution in IoT. Kigen had to get patches to potentially millions of SIMs – they mention an “Over the Air (OTA) Remote File Management” mechanism for distributing the fixkigen.com. This implies they could send an OTA SMS to those eSIMs to patch them. Having that infrastructure ready is crucial; not all eSIM vendors have such direct lines, so planning it in from design (like a patch SMS applet) is wise.
It highlights a weak link in certification – TS.48 was an industry certification profile. Attackers find what you don’t test. Here, the test profile wasn’t intended for production, so maybe evaluators didn’t consider it, but hackers did. That’s why in risk assessment, one should consider even those “should never happen” scenarios and either make them impossible or tested.
On a higher level, it raised strategic concerns: Freemindtronic called it a “eSIM sovereignty failure” meaning governments entrust billions of devices to a scheme that had a single point of failure (the GSMA test standard) without a way to monitor or revoke widelyfreemindtronic.com freemindtronic.com. This might lead to pushing for mandated runtime attestation or audit logs in future eSIM designs – e.g., an idea could be an eSIM that can report a signed log of what applets are on it, which an MNO or regulator could query if needed (privacy considerations aside). Such transparency might catch unauthorized applets if implemented.

In summary, from SIM card hacks of the 2010s to eSIM exploits in the 2020s, we see an evolutionary trajectory: attacks are growing more complex, but so are defenses. The case studies reinforced many recommendations: use strong cryptography, eliminate legacy weaknesses, lock down SIM toolkits, tightly manage keys, and have a plan to respond to vulnerabilities. In the next section, we will use these lessons to compile a concrete set of recommendations.

Summary Table of Recommendations

The following table summarizes key recommendations discussed throughout this white paper, mapping them to specific risk areas. This serves as a quick-reference checklist for stakeholders to ensure comprehensive coverage of eSIM and IoT cybersecurity measures.

Category	Recommendation
Hardware Security	Use certified secure eUICC hardware (CC EAL4+ or EN 17927/SESIP-certified). Select eSIM chips with proven tamper resistance and up-to-date protection profiles to withstand physical and side-channel attacksiotforall.com 1nce.com.
	Disable test and debug interfaces on eUICCs in production. Ensure no generic test profile or default keys remain enabled on deployed eSIMskigen.com. Lock eSIM to operational mode to prevent unauthorized mode switching.
Software (OS) Security	Keep eSIM OS firmware updated to patch known vulnerabilities (e.g., Java Card bugs). If OTA updates are supported, have a mechanism to deploy security patches to eSIMs in the fieldkigen.com.
	Minimize on-card apps & toolkits. Exclude legacy SIM Toolkit applets (e.g., S@T, WIB) unless absolutely required. For needed STK apps, enforce strict security (cryptographic authentication of OTA commands)cert.europa.eu.
	Enforce runtime checks in eSIM OS. Block installation of any applets outside authorized provisioning flowskigen.com. Use memory bounds checks and robust applet isolation to prevent rogue code executionsecurityweek.com.
Remote Provisioning & OTA	Use strong encryption & auth for RSP. All communications for profile download or management must occur over TLS with modern ciphersarxiv.org. Use mutual authentication (certificates) between eSIM and SM servers to prevent MITM.
	Filter and secure OTA SMS. Mobile operators should filter suspicious binary SMS (e.g., block known Simjacker patterns)cert.europa.eu. Use encrypted SMS for any SIM management commands; deprecate legacy DES OTA keys in favor of AES.
	Multifactor for profile activation (Consumer). Implement user verification (one-time codes or on-device confirmation) for eSIM profile downloads to thwart SIM swapsenisa.europa.eu.
	Profile policy control. Avoid profiles that lock the device to a single operator unless intended. Conversely, use profile policies to prevent unauthorized addition/removal of profiles in IoT devices except via approved platforms.
	Rapid revocation capability. Ensure the ability to remotely disable or delete eSIM profiles in case of compromise. Push for certificate revocation procedures for compromised eUICCs at the GSMA levelfreemindtronic.com.
Supply Chain Security	Use GSMA SAS-certified suppliers. Only source eSIM hardware and subscription management services from GSMA SAS-UP / SAS-SM accredited vendors to ensure rigorous security handling of SIM credentialsiotforall.com.
	Contractual security clauses. Include requirements for vulnerability disclosure, incident notification, and patch support in supplier contracts. Vet suppliers for past security track records and redundancy (avoid single points of failure).
	Secure personalization & transport. Use tamper-evident methods for shipping eSIMs. Ensure profile files and keys are transferred via HSMs or encrypted links. Prefer profiles generated and injected in secure environments so that Ki never leaves hardware security modules.
	Independent audits. Periodically audit your eSIM supply chain (or require audit reports). This can include penetration testing of SM platforms and code review of eSIM management software by third parties.
Operational Measures	Continuous monitoring & logging. Implement systems to detect anomalies such as unusual eSIM profile changes, duplicate SIM usage (clones), or atypical SIM toolkit usage on the network. Carriers should provide IoT customers with visibility into SIM events.
	Incident response plan. Develop and drill an incident response playbook specific to SIM/eSIM breaches (e.g., procedure if a batch of eSIMs is found vulnerable). Include steps to coordinate with operators, inform regulators (NIS2), and roll out mitigations (like OTA updates or device recalls) swiftly.
	Align with EU regulations. Ensure compliance with EU Cyber Resilience Act by integrating security from design through post-deploymentglobalplatform.org. Implement vulnerability handling processes that meet NIS2 (continuous risk management, reporting)freemindtronic.com.
	Governance and training. Establish clear roles for eSIM management in your team. Train staff about threats like SIM swapping social engineering and secure handling of eSIM activation info. Conduct regular reviews of eSIM security posture as part of overall cyber risk assessments.
	Privacy protection. Treat IMSIs, profiles, and eSIM identifiers as sensitive data. Implement access controls and encryption for any stored data related to SIM credentials. Use eSIM features (like multiple profiles or network segregation) to enhance user privacy as appropriate.
Future-Proofing	Crypto agility. Stay prepared for future algorithm updates (e.g., post-quantum cryptography for SIM authentication and eSIM certificates). Design systems that can upgrade cryptographic components on eSIMs or fall back to software updates on devices if needed.
	Emerging tech evaluation. As iSIM (Integrated SIM) becomes more common, scrutinize its security isolation. Keep an eye on new standards (SGP.31/.32) and participate in industry forums to anticipate security challenges in next-gen IoT eSIM deploymentstrustedconnectivityalliance.org.
	Runtime attestation research. Consider adopting new solutions (when available) that can remotely attest to the integrity of an eSIM’s software. This could involve the eSIM providing a signed proof of what version and apps it’s running, to detect unauthorized changes.

This table encapsulates a comprehensive approach: starting from choosing the right secure hardware, through using best practices in provisioning, to maintaining vigilant operations and preparing for the future. Stakeholders should review each item and ensure it is addressed in their eSIM/IoT deployment strategy. By following these recommendations, the risk of both common and advanced attacks can be substantially reduced.

Best Practices and Governance Models

Implementing the above technical measures effectively often requires organizational best practices and governance frameworks. This section discusses how organizations can structure their policies and responsibilities to manage eSIM security proactively. It also examines models for collaboration between different stakeholders – device manufacturers, mobile operators, service providers, and regulators – to create a robust security ecosystem.

Internal Best Practices for Organizations

Incorporate eSIM Security in Threat Modeling: IoT solution architects and product security teams should treat the eSIM as a critical component in the device’s threat model, not a black box given by operators. During design, ask “what if the eSIM is compromised?” and plan controls accordingly (e.g., application-layer encryption of sensitive data as a failsafe, so that even if connectivity is subverted, the data is safe). Consider the eSIM in abuse case scenarios too – e.g., could someone abuse the eSIM to spam the network or incur costs? By integrating these questions early, security measures become part of the system architecture.

Cross-Functional Security Team Involvement: Managing eSIM security spans hardware, software, and telecom domains. Establish cross-functional teams (or at least communication channels) between your hardware engineers, software developers, and the networking/operations teams. For example, if a carrier notifies of a SIM vulnerability, your operations team can inform developers to issue a firmware update that perhaps disables a feature or adds logging as a temporary countermeasure while a permanent SIM fix is arranged.

Lifecycle Management: Manage eSIMs through their entire lifecycle just like you manage devices. Maintain an inventory of eSIM IDs (EIDs, ICCIDs) in your devices and track their profile status. When decommissioning devices, ensure eSIM profiles are securely deactivated to prevent abuse of leftover connectivity. If reusing devices, consider resetting the eSIM (some eUICCs allow returning to factory state) so that new owners cannot access old profiles.

Network Usage Policies: For enterprise/industrial IoT, work with your mobile operator to set appropriate network policies. For instance, if your sensors should only communicate within country X, maybe geofencing at the network level can block it if it suddenly appears in another country (indicating possible SIM theft). Or use private APNs with IP whitelisting, so even if someone cloned a SIM, they couldn’t easily use it outside your platform because the backend would reject unknown device IDs.

SIM/eSIM Access Control: In any management systems, treat SIM management functions with the highest privilege level. For example, in an IoT device management portal, perhaps not every support engineer should be able to download or terminate an eSIM profile – limit that to a small team and require a change management process. Use multi-signature approval if the action is high-impact (two admins must approve generating a new eSIM profile for a device, for instance).

Testing and Staging: When rolling out eSIM-related updates (like switching all devices from one operator to another), test in a staging environment. Use a few devices to simulate the profile swap, observe for any issues (like devices failing to download the new profile due to network conditions), before mass rollout. This prevents accidental bricking of connectivity due to unforeseen errors.

Regular Security Drills: Just like IT teams do incident response drills, do a drill for an eSIM incident. For example, simulate the scenario: “A batch of our IoT trackers was stolen. Assume the attacker cloned the eSIMs. What do we do?” Go through the motions of requesting the operator to disable those profiles, pushing an update to remaining devices to use new profiles or shut off until further notice, etc. This will expose any weaknesses in your preparedness (maybe you realize you don’t have a direct line to a carrier’s 24/7 security contact – which you then establish).

Collaboration and Governance in the Ecosystem

Operator-Enterprise Security Partnership: As enterprises embed connectivity deeper, the relationship with mobile operators on security matters should become closer. Telcos traditionally handle network security, but now enterprise customers need visibility too. Establish an arrangement with your operator to receive security advisories related to SIM/eSIM. The operator’s GSMA contacts might get wind of an issue before public disclosure – you want to ensure you’re looped in (under NDA if needed). Additionally, define a process to work together in case of an incident: e.g., if you suspect SIM compromise, who in the operator’s security team will you call, and vice versa.

Regulator and Industry Collaboration: European regulators (like national telecom regulators or ENISA) may start requesting more information or even audits of how eSIM security is being handled, especially for critical sectors (energy, transport, health). Engage proactively: participate in consultations, share non-sensitive information, and help shape guidelines that are practical. Industry consortiums in Europe, such as the Trusted Connectivity Alliance (TCA) or GSMA Europe, often interface with regulators – being active there can ensure your organization’s concerns are heard and you stay ahead of compliance obligations.

Security Certification Schemes: With the EU Cybersecurity Act’s certification schemes emerging, consider certifying your IoT product (including its connectivity aspect) under an appropriate scheme when available. For instance, if an EUCC scheme for IoT or a specific vertical is launched, getting that certification will likely cover a lot of eSIM security by reference to standards. Also watch for any EU-wide eSIM profile certification or auditing requirement – it’s not here yet, but future legislation might say, for example, IoT devices in critical infrastructure must use eSIMs certified by an EU-designated lab. Positioning your products to meet such criteria (e.g., using EN 17927 certified components) can be a market differentiator and future-proofing.

Information Sharing and Threat Intel: Join telecom and IoT security information sharing groups. In Europe, there are forums like the GSMA’s T-ISAC (Threat Intelligence SIG) or national telecom ISACs. While those are usually for operators, large IoT enterprises might be invited or can get relevant outputs. Also, general IoT ISACs and CERTs (like CERT-EU) publish advisories – as seen, CERT-EU published Simjacker detailscert.europa.eu. Make sure your security operations or risk management gets those feeds and can act on them.

Sovereign Controls and Export Considerations: Be mindful if you operate in regulated industries – governments might impose their own conditions, like requiring local profiles (to avoid foreign profiles on critical IoT) or banning certain eSIM suppliers. This is part of governance: ensuring compliance with such local mandates. It may involve having a strategy for “localization” of eSIM – e.g., downloading a profile from a local carrier when in a certain country for security/regulatory reasons.

User Transparency and Control (for Consumer devices): If your product is consumer-facing (e.g., a smartwatch with eSIM), consider giving the user some insight or control over the eSIM security. For example, provide a simple toggle to disable remote profile management on their device if they want (like a “lock my eSIM” feature that would require a device PIN to add new profiles). While operators can initiate downloads, an extra user-side lock can add security. Apple, for instance, has a feature to require the device passcode when transferring an eSIM to a new iPhone – that’s a user-centric security measure. Aligning with such trends improves trust.

Ensuring Privacy Compliance: With eSIM data, also ensure governance for privacy. For instance, if your IoT platform collects SIM identifiers or location, apply GDPR principles – data minimization, purpose limitation, and consent if needed. Also, be cautious with eSIM profile switching in consumer devices: if profiles contain personal info, deleting profiles should be done in a way that respects user’s intent and privacy (maybe warn them to back up contacts stored on SIM, etc., before deletion).

Documentation and User Education: Maintain clear documentation about the eSIM functionality and any security features for your solution. This includes internal docs (like runbooks for operations, integration guides covering security) and potentially public-facing ones (if you expose eSIM management to customers, provide guidelines on secure usage). Given that eSIM is relatively new to many, well-documented processes help prevent accidental security lapses.

In governance terms, think of eSIM security management as analogous to identity and access management in IT. The eSIM profile is an identity (for the device on network). It needs lifecycle governance, role management, and audit trails just like a user identity would in an enterprise IAM system.

Towards a Resilient eSIM Ecosystem

The ultimate goal of good governance and best practices is a resilient ecosystem where no single vulnerability or breach in one component leads to catastrophe. In an ideal model:

Manufacturers produce eUICCs that are independently certified secure.
Operators and SM providers run audited systems with strong SLAs for security.
Enterprises deploying IoT have full visibility and control into the connectivity of their devices and work hand-in-hand with providers.
Regulators set baseline requirements and facilitate threat intel sharing without imposing impractical rules.
And all parties plan for failure – assuming things will go wrong and rehearsing the response.

Europe, with initiatives like NIS2 and CRA, is nudging towards that model by forcing communication of incidents and requiring security by design. Industry cooperation via GSMA ensures that when something is discovered, it can be fixed across the board (e.g., the coordinated action on TS.48 involved many companiesthehackernews.com).

One interesting governance concept from the Freemindtronic analysis was the need for “post-certification runtime verifiability”freemindtronic.com freemindtronic.com – essentially continuous assurance. In practice, this could mean regulators might ask for random sample testing of eSIMs in the field or requiring operators to have systems that detect anomalies in SIM behavior. We may see in the future something like a “cybersecurity dashboard” where an operator can see security status of all eSIMs (e.g., which ones are out-of-date OS, which ones have unusual toolkit activity). Building the groundwork for that now (through logs, monitoring hooks, and collaboration) will pay off if such requirements become formal.

Business Continuity and fallback plans: Another governance aspect – ensure you have a business continuity plan if a connectivity provider has a major incident. For example, if your eSIM profiles are all with Operator A and Operator A’s SM-DP+ goes down or is hacked and taken offline for a week, can your devices still function or fail gracefully? Multi-IMSI eSIMs (with multiple carrier profiles pre-loaded) is one approach some IoT firms use to ensure redundancy. It complicates management but can be a lifesaver if one operator is compromised or its service disrupted (natural disaster, etc.). Governance should weigh these trade-offs (cost/complexity vs. resilience).

Finally, human governance: an often overlooked point is the insider threat. Make sure the people who have access to eSIM management (in operators or your own org) are trustworthy – background checks for those roles, principle of least privilege, and monitoring of their actions. Cases like a rogue employee issuing SIM swaps illicitly have happened in telecoms; extending protections to eSIM management portals (like logging admin actions, using ephemeral access tokens, etc.) is part of good governance.

By implementing these governance practices and fostering a cooperative security culture around eSIM, organizations will be much better positioned to utilize the flexibility of eSIM and IoT connectivity without compromising on security or privacy. The effort spent in preparation and structured management is far less than the cost of reacting to an incident without a plan.

Future Outlook and Research Gaps

As eSIM technology and IoT ecosystems continue to evolve, so too will the security challenges. In this section, we look ahead to emerging trends, potential new threats, and areas where further research and development are needed. The aim is to anticipate what the eSIM cybersecurity landscape might look like in the coming years – particularly in the context of 5G Advanced/6G networks, widespread IoT deployment, and regulatory changes – and identify how industry and academia can address open questions.

Proliferation of eSIM and iSIM in IoT

Mass deployment scale: The number of eSIM/iSIM-enabled IoT devices is projected to surge dramatically. Market analyses predict billions of IoT devices with eSIM by the end of the decadeomdia.tech.informa.com iot-analytics.com. This scaling up means that even very rare security events (like a vulnerability that only one in a million devices can be exploited) can have noticeable impact when you have a billion devices (translating to potentially thousand devices breached). Security techniques will need to emphasize automation and cloud-side management to handle such scale – manual reissuance of SIMs or one-by-one fixes won’t be feasible. This is driving interest in remote attestation and health checks for devices, where a central system can periodically verify that devices (including their eSIMs) are in a known good state.

Integrated SIM (iSIM) adoption: iSIM takes the concept of eSIM further by integrating the SIM functionality into the system-on-chip of the device’s processor. This has advantages in cost and power, but security-wise, it raises the stakes on chipset security. If earlier an eSIM was a separate chip hardened against attacks, an iSIM shares resources with the main CPU (albeit isolated logically). The industry is working on standards to ensure iSIM security is as strong as discrete eSIM (GP’s Integrated Secure Element specs, etc.). However, one research gap is evaluating side-channel leakage in multi-tenant environments – if the SIM is inside a chipset that also handles other tasks, could a malware on the main CPU glean information about the SIM’s operations (like power signatures or cache timing)? Ensuring a robust partition (using technologies like ARM TrustZone or dedicated secure cores) is key. Independent certification for iSIM (possibly via SESIP or CC) is going to be crucial to instill confidence.

Another aspect: iSIM potentially allows more dynamic SIM identity – for instance, conceivably downloading an iSIM as software to a device (some vendors talk about “soft SIM”). This blurs the line between hardware and software SIM, possibly opening new avenues for attack if not carefully managed (imagine SIM malware that tries to emulate an iSIM).

Multi-profile and Localized IoT connectivity: We’ll likely see IoT devices routinely carrying multiple profiles (to remain always best connected or to comply with local regulations by using a local profile in each country). This complexity could introduce synchronization issues or new attack surfaces (like a logic error that activates two profiles at once leading to unexpected behavior). Research could help by developing formal verification models for profile management logic to ensure no insecure state can arise (some formal analysis has been done on consumer RSParxiv.org, similar could be done for multi-profile scenarios).

5G Standalone, 6G and Network Security Implications

5G SA (Standalone) and 5G Core Security: As 5G networks (and eventually 6G) roll out, they bring new security features (e.g., SUPI instead of IMSI, home network public key encryption of subscriber ID, etc.). eSIM profiles and infrastructure will need to incorporate these. For example, 5G allows the SIM (USIM application) to perform Subscription Permanent Identifier (SUPI) encryption so that the device’s permanent ID is not sent in clear – future eSIMs should ensure robust implementation of that to protect privacy. Also, 5G introduces network slicing and private networks: an IoT eSIM might be configured to only attach to a specific slice or enterprise network. Ensuring that slicing information is correctly provisioned and cannot be manipulated is a new area (an attacker who compromises an eSIM might try to get it onto an unauthorized slice to access restricted resources).

Edge Computing and Local Profiles: With MEC (multi-access edge computing), devices might authenticate to local breakout networks. There’s discussion of scenarios like network exposure functions (NEF) that could interface with SIM capabilities for IoT. One forward-looking question: could eSIMs be used to store keys for end-to-end encryption between device and cloud (bypassing operator)? If so, securing that usage and standardizing it (so eSIM truly becomes a root of trust for general IoT security, not just network access) is an area for innovation. Some projects (like using SIM/eSIM for IoT device authentication to cloud services) are in early stages – such methods could reduce the need for separate secure elements for application-layer security by leveraging the eSIM’s.

6G and enhanced subscriber identity: It’s too early to say what 6G authentication will look like, but likely evolution will address known weaknesses (like eliminating trust in long-term keys being stored in many places). Possibly, distributed identity concepts might emerge, where eSIM could play a role in a decentralized ID system for IoT devices. Security research can preemptively explore how eSIM could integrate with blockchain-based identity or other decentralized schemes, ensuring privacy and security.

Advanced Threats and National Security

Nation-state adversaries: The case studies already show nation-states are interested in SIM/eSIM (Gemalto hack by NSA/GCHQ, likely other silent operations not public). As eSIM becomes standard in critical systems (e.g., smart grid, connected cars, even military IoT comms), advanced persistent threats (APT) will invest in finding vulnerabilities. We might see more supply chain attacks like interdictions – e.g., compromising a distributor’s systems to upload a malicious profile to eSIMs before they’re deployed, or malware that specifically looks for eSIM management software on an enterprise network. Security teams in high-security environments should consider threat models where the SIM/eSIM is directly targeted by state-sponsored hackers.

In Europe, there could be moves to declare eSIM tech from certain origins as untrusted (similar to how 5G equipment from certain countries was scrutinized). This might drive “sovereign eSIM” initiatives – e.g., European secure element manufacturers might get preference for government or critical infrastructure projects. The EU’s push for digital sovereignty could lead to an ecosystem of EU-based eSIM provisioning services that meet EU certification, reducing reliance on external providers.

Quantum Computing threat: Though likely a decade away, it’s relevant to mention that when quantum computers become powerful enough, they could break current public-key cryptography (like RSA/ECC) which is used in some SIM authentication schemes (for example, the certificate-based authentication of eSIM to SM-DP+ uses ECC/RSA certs). They could also brute force weaker symmetric keys if any still linger. The industry will need to migrate to post-quantum cryptography (PQC) for these aspects. Research is needed on integrating PQC algorithms into the constrained environment of SIM/eSIM (Java Card has limitations like CPU and memory). Early adoption may involve hybrid approaches (classical + PQC). Standard bodies like 3GPP and GSMA will eventually specify new algorithms – staying involved in those discussions will be important to ensure smooth transition. One could foresee a future where a new profile is required that supports a PQC-based AKA protocol, and we might even need remote updates of SIM applications to handle that.

Persistent Malware and SIM-based Attacks: An open question: could malware on a device leverage the eSIM in new ways? For instance, a smartphone malware might hijack the eSIM provisioning process (maybe trick the user into downloading the attacker’s profile which is free but forces traffic through a hostile proxy). Or malware could use SIM toolkit commands to silently perform actions (similar to Simjacker but initiated from device software rather than SMS). Platform developers (Android, iOS) have to carefully sandbox their eSIM management APIs to avoid such scenarios. As more mid-tier phones adopt eSIM, and carriers allow multiple profiles, attackers might attempt to socially engineer users to install a malicious profile (e.g., a phishing message: “Scan this QR for a free data plan,” which actually gives them a profile that snoops or MITMs their data via some rogue MVNO). Education and possibly platform restrictions (like only allowing profiles from known carriers unless user explicitly bypasses a warning) could mitigate this.

Research and Standardization Gaps

Runtime Attestation & Monitoring: As mentioned, one gap is verifying the integrity of an eSIM after deployment. Research could explore lightweight attestation protocols where an eSIM signs a heartbeat with a device-unique private key attesting to its firmware version and that no unknown applets are present. There are challenges: SIM OS are not designed to expose such info normally, and you’d need carriers to accept whatever overhead that entails. But given calls for post-cert runtime checksfreemindtronic.com, it’s an area worth investigating. Perhaps EU-funded research projects might prototype “eSIM health check” systems.

Secure Multi-Tenant SIMs: In IoT, there may be scenarios where you want a third party to run an applet on the SIM (for example, for secure IoT device authentication, a cloud provider might want to use the SIM’s secure element). GlobalPlatform has concepts of secure element partitioning (multiple security domains, each controlled by different authority). Implementing that in eSIM for IoT, and doing it securely, is complex. Further work is needed to allow one SIM to safely serve multiple masters (operator and application providers) without introducing new vulnerabilities.

Energy and DoS Considerations: IoT devices often run on battery, and eSIM operations consume power (especially radio communication for profile download). A malicious actor could potentially trigger frequent profile swaps or downloads to drain a device’s battery as a denial-of-service. Standards might need to address rate limiting of such operations or ways for a device to signal “do not disturb” for provisioning during critical operation. This hasn’t been much explored; as eSIM enters extremely power-sensitive IoT like sensors on coin-cell batteries, this becomes relevant.

User-friendly Security for eSIM: How to convey eSIM security status to end users is an UX research question. E.g., is there a need for an indicator that “your eSIM is up to date and secure” akin to an antivirus green check? Or a warning “your eSIM profile is from an unverified source.” Currently, users trust carriers blindly for that. But if we imagine a future where more entities (e.g., local MVNOs, private networks) issue profiles, a user might need to differentiate trusted from potentially shady profiles. Creating an ecosystem of trust marks or digital signatures that user devices can display meaningfully could help.

Testing tools and fuzzing: We will likely see more open-source or commercial tools to fuzz eSIM interfaces (like testing the profile download protocol for edge cases, fuzzing SIM toolkit commands, etc.). Encouraging such tools and using them proactively (in labs and certification) will catch issues earlier. For example, a fuzzer might have caught the ambiguous TS.48 behavior by randomly playing with those functions. The community should develop a suite of eSIM security test cases beyond the official GSMA ones, as a collaborative effort.

Impact of new regulations: The EU Cyber Resilience Act will push manufacturers to pay closer attention to vulnerability disclosure and patchability. One gap it might highlight: how do you update something as low-level as an eSIM if needed? It might drive innovation in making eSIM OS more modular or updatable. Researchers might explore methods to patch a running Java Card applet securely without full OS swap.

Security Economics and Incentives: Lastly, a softer area is ensuring that all players have incentive to prioritize security. Right now, an IoT device maker might say “security of the SIM is the operator’s job” and vice versa. Regulators like NIS2 remove some ambiguity by making both responsible for risk. But further incentive, like insurance implications or liability assignment, could come into play. If, say, a major breach occurs because an operator failed to patch SIMs, who bears the cost? Clear answers to that might not exist yet, but as far as outlook, we expect contracts and insurance policies to increasingly address such scenarios, indirectly forcing better security.

In conclusion, the future of eSIM in IoT is bright in terms of adoption and capabilities, but it also means an expanded attack surface and more attractive target for adversaries. Ongoing research, standards evolution, and cross-sector collaboration (telecom, IT security, academic) will be essential to keep security a step ahead. The European context, with its strong regulatory push and concentration of IoT innovation, will likely be at the forefront of both deployment and securing of these technologies. By staying vigilant and investing in the areas highlighted – from post-quantum readiness to attestation and user awareness – we can harness the benefits of eSIM and advanced connectivity with confidence in their security.

Conclusion

The advent of eSIM technology has undeniably transformed the connectivity landscape for IoT and M2M applications, offering unparalleled flexibility, scalability, and streamlined logistics for deploying connected devices across the globe. However, as this white paper has detailed, with great flexibility comes great responsibility – specifically, the responsibility to address a complex array of cybersecurity challenges that accompany the eSIM revolution.

In 4G/5G IoT environments, the eSIM/eUICC serves as a cornerstone of device identity and network access. It effectively becomes the hardware root of trust for IoT devices. Ensuring its security is therefore not just an option but a necessity for the reliability and safety of IoT services ranging from smart utilities and industrial automation to connected vehicles and healthcare devices. The discussion herein has highlighted that while the fundamentals of SIM security remain strong, the threat landscape is evolving: attackers have demonstrated sophisticated methods to exploit ambiguities in standards (GSMA TS.48 test profiles), weaknesses in underlying platforms (Java Card bugs), and even operational oversights (like legacy toolkit applets or social engineering gaps).

On a positive note, the industry response has been robust. The GSMA, device manufacturers, and security researchers are increasingly proactive in identifying and mitigating risks. The introduction of comprehensive standards (such as GSMA’s SGP.24 compliance process and SGP.25 protection profile for security) and the integration of security certification schemes (SAS, Common Criteria, SESIP) provide a solid foundation1nce.com iotforall.com. At the same time, European regulatory frameworks like the Cyber Resilience Act and NIS2 Directive are propelling stakeholders to maintain vigilance throughout the product lifecycleglobalplatform.org freemindtronic.com. This dual approach – industry-led best practices supported by regulatory oversight – creates a powerful incentive to “build security in” from the start and continuously monitor and improve it.

For CISOs and IoT architects, a key takeaway is the importance of a layered defense strategy. There is no silver bullet to eSIM security; rather, it’s the sum of many measures: selecting secure hardware, hardening software, securing communications, vetting your supply chain, and having strong governance. Implementing the recommendations summarized in the table – from cryptography updates to incident response planning – will significantly lower the risk of both common and advanced threats. It’s evident that organizations that approach eSIM security holistically, breaking down silos between telco teams and IT security teams, will be better prepared to prevent and respond to incidents.

Telecom operators, too, have a pivotal role. They must not only secure their own backend systems (SM-DP/SM-DS/SM-SR) but also act as security enablers for their IoT customers. This means providing transparency, rapid communication about threats, and possibly value-added services like anomaly detection on SIM usage for enterprise clients. As IoT deployments become more mission-critical, operators that distinguish themselves in security assurance will have a competitive edge.

From a regulatory and standards perspective, Europe is leading in trying to bridge the gap between certification and real-world assurance. Ideas such as mandating post-compromise eUICC revocation procedures or requiring demonstrable risk management aligned with NIS2 ensure that security isn’t a one-time checkbox but an ongoing processfreemindtronic.com freemindtronic.com. We can expect that in the near future, demonstrating compliance with standards like EN 17927 (SESIP) for IoT platforms will become not just a bonus but a requirement in many sectorsglobalplatform.org.

Looking ahead, the convergence of telecommunications and information technology domains (for instance, eSIMs being used to secure device application credentials, or network slicing blurring network boundaries) will create both opportunities and new security questions. The community should encourage research into these intersections – for example, can eSIMs be leveraged to improve end-to-end IoT security beyond connectivity? How do we securely manage identities when devices have multiple network personalities (profiles)? Solving these will likely involve cross-industry collaboration, something Europe, with initiatives like Horizon research programs and ENISA workshops, is well-positioned to foster.

In conclusion, eSIM technology is maturing against a backdrop of increasing cybersecurity consciousness. The case studies of past incidents have illuminated where our defenses needed strengthening, and the industry has responded in many of those areas. By continuing on this path – adhering to rigorous standards, sharing knowledge of emerging threats, and cultivating a culture of security from device inception to deployment – we can ensure that the massive IoT expansion enabled by eSIM and 5G is not derailed by security setbacks. Instead, we will have networks and devices that are resilient by design, capable of withstanding attacks, and worthy of users’ and regulators’ trust.

The European focus of this paper underscores that we have the policy support and market alignment in our region to make eSIM security a success story. The task now for all stakeholders is to implement, educate, and continuously improve. If we do so, eSIM can truly fulfill its promise – delivering connectivity that is not only seamless and interoperable, but also secure and robust, thereby unlocking the full potential of IoT in the 4G/5G era and beyond.

References

(Cited references from the connected sources are listed below, using the numbering throughout the text for clarity.)

Security issues with Test profiles (e.g. GSMA TS.48) – 9eSIM – Simlink Ltd. blog post describing an exploitation of GSMA TS.48 test profile to load unauthorized applets and extract secrets9esim.com 9esim.com
Ravie Lakshmanan, “eSIM Vulnerability in eUICC Cards Exposes Billions of IoT Devices to Malicious Attacks,” The Hacker News, Jul. 14, 2025. – News article on the Kigen eSIM vulnerability leveraging GSMA TS.48 test profiles and Java Card flawsthehackernews.com thehackernews.com
Eduard Kovacs, “Many Vulnerabilities Found in Oracle’s Java Card Technology,” SecurityWeek, Mar. 21, 2019. – Report on Security Explorations’ findings of 18 Java Card vulnerabilities breaking applet isolation and allowing SIM compromisesecurityweek.com securityweek.com
CERT-EU Security Advisory 2019-020, “Simjacker Vulnerability Impacting up to 1 Billion Phone Users,” Sep. 2019. – Technical description of the Simjacker attack via S@T Browser SIM toolkit exploitation and its potential uses (espionage, fraud, etc.)cert.europa.eu cert.europa.eu
ENISA, Embedded SIM Ecosystem, Security Risks and Measures, Mar. 2023. – ENISA report outlining eSIM architecture, security challenges (e.g., eSIM swapping, memory attacks, profile inflation) and recommendationsenisa.europa.eu enisa.europa.eu
IoT For All (Teal), “The Importance of Choosing a GSMA Certified eSIM Solution,” Dec. 2, 2024. – Industry article emphasizing GSMA’s SAS certification and security requirements for eSIM providers handling operator profilesiotforall.com iotforall.com
GlobalPlatform Press Release, “SESIP Paves the Way for IoT Manufacturers to Meet New European Cybersecurity Rules,” Dec. 12, 2024. – Announcement of EN 17927 adoption (SESIP) and its alignment with the EU Cyber Resilience Act for IoT device complianceglobalplatform.org globalplatform.org
Trusted Connectivity Alliance, “Half a Billion eSIM Shipments in 2024 as Consumer Adoption Surges,” Mar. 3, 2025. – Market data indicating 2024 eSIM shipments (503 million+) and noting significant M2M eSIM adoption and new GSMA IoT specification (SGP.32) releasetrustedconnectivityalliance.org trustedconnectivityalliance.org
Kigen Security Bulletin KGNSB-07-2025, Jul. 9, 2025. – Kigen’s official advisory on the GSMA TS.48 test profile vulnerability, detailing the issue, patches (OS update, safer test profiles), and recommendations to not use test profiles in productionkigen.com kigen.com
Freemindtronic, “eSIM Sovereignty Failure: Certified Mobile Identity at Risk,” Jul. 30, 2025. – Analysis of the strategic implications of the Kigen eSIM exploit, calling out gaps in GSMA certification (TS.48) and need for runtime telemetry and sovereign oversight (mentions NIS2, CRA conflicts)freemindtronic.com freemindtronic.com

IoTiniX