How eSIM provisioning works: eUICC, SM-DP+, QR codes, and security

eSIM provisioning is the process that installs a carrier profile onto the secure chip already built into a phone. With a physical SIM, the carrier credentials arrive on a plastic card. With an eSIM, the phone downloads those credentials over the internet and stores them inside the device’s eUICC. That sounds simple from the user side: you scan a QR code, approve a mobile plan, and a new line appears in settings. But the technical flow underneath is way more interesting: the phone reads an activation code, contacts a carrier server, checks certificates, downloads an encrypted profile package, installs it inside the eUICC, and then authenticates to the mobile network. The consumer version of this system is defined by the GSMA’s Remote SIM Provisioning specification , mainly SGP.22 . For a QR-based activation, you need only a few boxes in your head: the eUICC chip, the LPA software on the phone, the SM-DP+ server that holds the profile, and sometimes the SM-DS discovery server. What is an eSIM The chip inside an eSIM-supporting phone is called an eUICC , short for embedded Universal Integrated Circuit Card . It is the secure element that stores one or more SIM profiles. The profile is the important part. It contains the data and applications needed to connect to a mobile network: the network access application, IMSI, authentication keys, and operator files. On a physical SIM, those credentials are written onto the card before it reaches you. On an eUICC, they can be downloaded later. That does not mean the SIM has moved into normal phone storage. The carrier credentials still live inside a tamper-resistant secure element. ==The big change is not that the SIM became “software” in the casual sense. The change is that profiles can be downloaded, switched, disabled, and removed without swapping hardware.== Each eUICC also has a permanent identifier called the EID. It is a 32-digit number assigned to the chip. Unlike an ICCID, which belongs to a specific SIM profile, the EID stays with the eUICC itself. A provisioning server can use it to bind a profile to the right chip. The parts involved in eSIM provisioning For consumer eSIM provisioning, two parts live on the device, and two sit on the network side. On the phone, the first part is the eUICC . That is the chip where the profile ends up. The second part is the LPA , or Local Profile Assistant . The LPA is the phone-side software that manages profile discovery, download, installation, and user interaction. On most phones, the LPA is part of the operating system or tightly integrated with it. Android’s platform documentation describes the eUICC APIs and the system role around profile management in detail. On the network side, the main server is the SM-DP+ . The name stands for Subscription Manager Data Preparation . It prepares, protects, stores, and delivers the eSIM profile. The plus sign matters: SM-DP+ is the consumer eSIM version, different from the older machine-to-machine architecture. The other network-side component is the SM-DS , or Subscription Manager Discovery Server . It is optional. You can think of it as a discovery directory. If a carrier has assigned a profile to a device but the phone does not already have the SM-DP+ address, the SM-DS can help point the LPA to the right place. The full specification has formal interface names: ES9+ between the LPA and the SM-DP+. You’ll need these for implementing the system, but not so much if you are just trying to understand what happens when someone scans a QR code. What the QR code contains ==The QR code does not contain the SIM profile.== It contains a short text string called an activation code . The QR is only a convenient wrapper around that text, using the same basic QR-code idea used for links, tickets, and Wi-Fi passwords. In the common consumer flow, the activation code tells the phone where to go and which prepared profile to ask for. The format is defined in SGP.22 . It starts with LPA:1, then includes the SM-DP+ address, then a matching ID. A confirmation code can also be required. A simplified example looks like this: LPA:1$smdp.example.com$K2-1A3B-9XYZ The first part tells the phone that this is an LPA activation code . The second part is the SM-DP+ server address . The third part is the matching ID , which points to one prepared profile on that server. This is also why scanning a QR code and typing the details manually are not different security models. There are two ways to give the LPA the same information. If your phone asks for manual details, the field usually called the SM-DP+ address is the server address that would otherwise have been read from the QR code. Activation codes are often single-use. That is not because QR codes are special. It is because the SM-DP+ and carrier backend decide what should happen after a profile has been downloaded. Some providers allow reinstall or reissue flows. Others require a fresh activation code after deletion. What happens between the scan and the signal From the scan to working mobile data, the provisioning flow is mostly authentication and profile handling. The download itself is only one part of it. Here is the consumer QR flow in plain English: The carrier or provider prepares a profile on the SM-DP+ server. The profile is associated with a matching ID, and sometimes with a specific EID. The user receives an activation code, usually as a QR code. At this point, nothing has been installed on the phone. The LPA reads the activation code and extracts the SM-DP+ address and matching ID. The phone opens a TLS connection to the SM-DP+ and starts the authentication flow. The eUICC and the server check each other through certificates and protocol messages before sensitive material moves. The SM-DP+ finds the prepared profile and creates a Bound Profile Package. This package is protected so it can be installed by the intended eUICC, not by any random device that intercepted the traffic. The package is delivered to the phone and installed inside the eUICC. The secure element handles the profile installation, then reports the result. The user enables the profile. The phone can then use the installed network access application to authenticate to the mobile network, like a physical SIM would. For the user, all of this is hidden behind a much shorter interface. Travel eSIM providers like Airalo, Nomad, Saily, and Ohayu may have different checkout screens and app flows, but the underlying consumer provisioning idea is similar: a profile is prepared on the server side, the phone retrieves it during installation, and the line connects after the profile is enabled. Why downloading a SIM profile can be secure The obvious question is whether it is safe to download something as sensitive as a SIM profile over the internet. ==The short answer is that the profile is not just sent as a normal file.== The consumer RSP system uses certificates, mutual authentication, TLS, and profile-package encryption. The eUICC and the SM-DP+ do not simply trust each other because a QR code was scanned. The trust model uses a public key infrastructure. Legitimate eUICCs and legitimate SM-DP+ servers have certificates that chain back through the GSMA Certificate Issuer. During the provisioning flow, the parties check those certificates. A fake server should not be able to impersonate an accredited SM-DP+, and a random chip should not be able to pretend it is a certified eUICC. The cryptography in SGP.22 uses elliptic-curve signatures and key agreement, with profile download carried over TLS. The important point for a non-cryptographer is this: the profile package is prepared for the target eUICC. Copying the network transfer should not give an attacker a reusable SIM profile. That does not make the whole ecosystem magic. A 2022 formal analysis of consumer RSP found that the protocol protects against a network attacker when the intended participants are honest, but also flagged weaker spots in partial-compromise cases. In particular, the paper pointed out that the protocol leans on TLS and that compromised legitimate participants can create harder problems. So the conclusion is not “eSIM is unbreakable.” It is more precise than that. The download flow is designed to stop simple interception and replay. The remaining risks are more likely to come from implementation mistakes, compromised infrastructure, weak operational controls, or physical access to the secure element. The 2025 Kigen case is a good example. Security Explorations found a vulnerability involving Kigen eUICC technology and older GSMA TS.48 Generic Test Profile behavior. Public reporting described conditions such as physical access, test-mode activation, and legacy test profiles. Kigen and the GSMA moved to mitigate the issue through patching and TS.48 version 7.0 changes. That is not the same as saying a normal QR activation can be cloned remotely. It shows something narrower and more realistic: the protocol matters, but chip implementation and test-profile handling matter too. How Android exposes eSIM provisioning Android treats eSIM management as a platform feature. Starting with Android 9, the Android framework provides standard APIs for accessing eSIM and managing subscription profiles on the eUICC. The main class is EuiccManager , in the android.telephony.euicc package. Android’s documentation describes high-level operations such as downloadSubscription() , switchToSubscription() , and deleteSubscription() . A carrier app can work with an activation code and ask the system to download a profile, but the app does not become a full unrestricted LPA. A full LPA is a privileged system component. Ordinary carrier apps operate through the Android eUICC APIs and carrier-privilege checks. That keeps the user-facing setup flow possible without giving every app raw control over the secure element. Android has also moved toward more flexible active-profile support. With Android 13, devices that support Multiple Enabled Profiles can use one eUICC with multiple ports, allowing two active subscriptions on a single eSIM chip. Android 14 added support for the MEP-A1 and MEP-B models aligned with GSMA SGP.22 version 3.0. This still depends on the device, modem, eUICC, and OEM implementation. Android support in the OS does not mean every Android phone can run two active eSIM profiles. How iPhone exposes eSIM provisioning Apple exposes less of the provisioning machinery to third-party apps. On iPhone, Apple provides the LPA experience through iOS. Users see setup paths such as eSIM Carrier Activation, eSIM Quick Transfer, QR-code setup, carrier links, carrier apps, manual entry, and, with supported carriers and devices, transfer flows involving Android or another non-Apple device. The first eSIM-capable iPhones were the iPhone XS, XS Max, and XR. In the United States, Apple moved to eSIM-only iPhones starting with the iPhone 14 generation. The iPhone Air goes further: Apple’s technical specifications list dual active eSIMs, storage for eight or more eSIMs, and no physical SIM-card compatibility. The important difference for developers is control. Android gives carriers a public platform API surface for some eSIM operations. iOS gives users several activation paths, but Apple does not expose a general public API that lets any third-party app download arbitrary eSIM profiles. Common provisioning questions How many eSIMs can a phone store? It depends on the device. Many current phones can store several profiles, and some store eight or more. Storage is not the same as active use, though. A phone might store many profiles while only one or two are active at the same time. Can a phone run two eSIMs at once? Some can. Older devices generally allowed only one active profile per eUICC. Newer devices may support two active eSIMs, depending on hardware and OS support. On Android, Multiple Enabled Profiles became part of the platform from Android 13 for compatible devices. Apple’s iPhone Air specs list two active eSIMs. Why can’t I always reinstall an eSIM from the same QR code? Because the matching ID inside the activation code is often spent after the first download. The QR code is only text, but the server behind it tracks profile state. If the profile was downloaded, deleted, expired, or tied to another device, the provider may need to issue a new code. Is scanning the QR code less secure than typing the code manually? No. Scanning and typing are just two input methods. The QR code carries the activation-code text. Once the LPA has the SM-DP+ address and matching ID, the same provisioning flow runs underneath. Is it safe to give a provider my EID? The EID is an identifier, not a password. It lets the provider or SM-DP+ target the right eUICC. Providers may ask for it when a profile must be assigned to a specific device. On most phones, you can find the EID in settings under the eSIM, cellular, SIM, or about-device screens. You can also dial *#06#. That is not a phone call. It opens a device information screen, so it dials no one and costs nothing. Can an eSIM be cloned? Not by copying the download in transit. The downloaded profile package is protected for the target eUICC. A realistic attack would be more likely to involve physical access, a vulnerable chip implementation, compromised infrastructure, or weak account recovery at the provider or carrier. That last part matters. A secure provisioning protocol does not fix every operational weakness around a mobile account. If someone can socially engineer a carrier into transferring your number, that is a different problem from breaking the eSIM download cryptography. Where this is going The next phase is less about teaching users to scan QR codes and more about ==pushing remote provisioning into new devices and stricter markets==. China is one example. In October 2025, China’s three major operators received approval to offer trial smartphone eSIM services, a shift tied closely to the delayed launch of Apple’s eSIM-only iPhone Air in mainland China. That did not instantly make eSIM universal in China, but it did move one of the largest smartphone markets away from its long resistance to phone eSIM support. IoT is the other direction. GSMA SGP.32 brings remote provisioning closer to devices that may not have a screen, camera, or a person standing next to them. In that world, a server-side management component can trigger provisioning actions because a sensor in the field cannot scan a QR code. Whether the device is a phone, watch, tablet, or sensor, the system still has to answer the same questions before a profile is installed: ==is this the right chip, is it talking to the right server, and is the profile protected for that chip only?==