eSIM (embedded SIM) and Remote SIM Provisioning (RSP)
1. Overview
Definition: An eSIM is a subscriber identity module in the form of an eUICC (embedded Universal Integrated Circuit Card) that is soldered onto a device mainboard or integrated into the application processor (AP), and Remote SIM Provisioning (RSP) is the GSMA standard framework for securely downloading, installing, activating, switching, and deleting a carrier subscription (Profile) over the network without physical card replacement.
The subscriber identity module is the root of trust that authenticates a mobile subscriber and attaches the device to the network. For a long time this role was played by a plastic card (UICC) that users inserted and removed by hand. However, as devices became smaller and waterproof and as cars, wearables, and sensors that people cannot easily reach proliferated, the cost of inserting, distributing, and replacing physical cards became a bottleneck to service rollout. Buying a local SIM and swapping it on every overseas trip, or pre-loading carrier-specific SIMs into millions of IoT devices and shipping them worldwide, was no longer sustainable.
eSIM and RSP solve this by turning "changing hardware" into "downloading software (a profile)." Once subscription data is treated as data, switching carriers becomes a few-second procedure of scanning a QR code in an app, and a finished product built in a factory can have the profile for its sales country/carrier injected remotely at shipment or in the field. However, because subscription data is itself the means of authentication and the basis for billing, this shift can be safely realized only on top of a strong cryptographic and authentication framework.
This answer provides an essay-style treatment of the eSIM hardware/software structure (eUICC, profile, LPA), the RSP architecture and the profile download procedure, the differences among the consumer, M2M, and IoT standard families and their reasons, the security structure, industrial application cases, and considerations from a Professional Engineer's perspective.
2. Concept and Structure of eSIM
graph TD
subgraph EVO["Evolution of SIM form factors"]
A["Physical UICC(removable card)"] --> B["eUICC(embedded eSIM chip, MFF2)"]
B --> C["iSIM(secure area inside AP/SoC)"]
end
subgraph EUICC["Logical structure inside the eUICC"]
OS["eUICC OS + ISD-R(issuer security domain)"]
P1["Profile A(carrier 1)"]
P2["Profile B(carrier 2)"]
OS --> P1
OS --> P2
ACT["One active profile(single-SIM basis)"]
P1 -.active.-> ACT
end
C --> OS
The figure shows the path by which the subscriber module moves from a removable card to an embedded chip and then into the AP, together with the internal structure in which a single eUICC holds multiple carrier profiles but, in principle, activates only one at a time.
A. From UICC to eUICC
A traditional UICC is a secure smart card on which a carrier records subscription data in advance and distributes it. Because the IMSI, Ki (authentication key), and carrier file system are fixed at manufacturing time, changing carriers requires physically receiving and swapping a new card. The card itself provided strong security as tamper-resistant hardware, but the physical constraints of supply chain, inventory, and field replacement reduced service agility.
The eUICC uses the same security hardware, soldered into the device (as MFF2 and similar), but its decisive difference is that its "contents"—the profile—can be changed remotely even after shipment. In other words, the hardware is fixed while the subscription data becomes mutable. To this end, the eUICC contains an Issuer Security Domain Root (ISD-R) that safely accommodates, isolates, and manages profiles, as well as a per-profile security domain.
Here it is important to distinguish "eSIM" from "eUICC." The eUICC refers to the hardware (chip), the profile refers to the carrier subscription data (software) it holds, and eSIM is generally the popular umbrella term for both. Thus "changing the eSIM" actually means "switching profiles on the same eUICC."
B. The Relationship Among eUICC, Profile, and LPA
A profile is a bundle of files, applets, and authentication keys that make up a specific carrier subscription—encapsulating as data what a plastic card used to hold. A single eUICC can host multiple profiles, but on a single-SIM basis the enabled profile is, in principle, one at a time. For this reason, a "dual-SIM" experience becomes possible either by using one physical SIM together with one eSIM, or when the device supports Multiple Enabled Profiles (MEP).
The LPA (Local Profile Assistant) is the software on the user's device that mediates the download, installation, activation, and deletion of profiles. The LPA is divided into the LPAd (LPA in Device), loaded in the device OS, and the LPAe (LPA in eUICC), embedded inside the eUICC; consumer smartphones generally use the LPAd form. The LPA interprets QR codes/activation codes, finds the appropriate server and directs the profile download, and provides the user with the installation consent and switching UI—serving as the "control window" for operations.
The relationship among these three is clearest understood as a division of roles. The eUICC is the vault holding the root of trust, the profile is each carrier's key ring stored in the vault, and the LPA is the handle that helps the user operate the vault. RSP specifies the entire procedure for securely inserting and removing keys (profiles) into this vault remotely, but only through legitimate paths.
C. Evolution into iSIM
An iSIM (integrated SIM) is a form in which the eUICC function is integrated not into a separate chip but into a secure area (Secure Enclave, iUICC) inside the AP/SoC. By eliminating a separate component and mounting process, it can further reduce board area, power, and cost, and is especially advantageous for large-scale IoT and wearables that require extreme miniaturization and low power. However, since the logical structure of RSP (profile, LPA, remote servers) is maintained identically to the eUICC, the iSIM is a form-factor innovation, not a replacement of the provisioning paradigm.
In terms of commercial expansion, the industry's general assessment is that iSIM is still at an earlier stage than mainstream consumer eSIM. This is because the security certification (such as Common Criteria) and the SoC supply chain/IP (e.g., design-asset licensing) ecosystem must mature. Therefore, for the time being, eUICC-based eSIM and iSIM will coexist by use case, with iSIM adoption expanding mainly in small, high-volume IoT.
| Category | Physical UICC | eUICC (eSIM) | iSIM |
|---|---|---|---|
| Form | Removable card | Board-mounted chip (MFF2, etc.) | Integrated inside AP/SoC |
| Carrier change | Physical card swap | Remote profile download | Remote profile download |
| Space/power | Large | Small | Smallest |
| Typical use | Legacy phones | Smartphones, wearables, IoT | Ultra-small, high-volume IoT |
| Maturity | Mature | Commercially expanding | Relatively early |
The table alone does not reveal "why" the differences arise. The key point is that even when the physical location of the security hardware changes, the RSP principle of treating subscription data as data is maintained; thanks to this, the form factor shrinks while the operating model from the carrier's and user's standpoint retains continuity.
3. Remote SIM Provisioning (RSP) Architecture and Operation
sequenceDiagram
participant U as "User/Device(LPA)"
participant E as eUICC
participant DS as "SM-DS(discovery)"
participant DP as "SM-DP+(profile prep/delivery)"
participant MNO as "Carrier(MNO)"
MNO->>DP: Subscription activation request, instruct profile creation
U->>DS: After scanning activation code/QR, query server address
DS-->>U: Return SM-DP+ address
U->>DP: Request profile download(mutual authentication)
DP->>E: Verify eUICC certificate, deliver encrypted profile
E->>E: Decrypt, install(create ISD-P)
U->>E: Activate profile(enable)
E-->>MNO: Network attach, subscriber authentication success
This sequence depicts, in the consumer model, the flow from the user entering an activation code, through the discovery server, to receiving an encrypted profile from the profile-preparation server and installing/activating it on the eUICC. Every segment is protected by mutual authentication and encryption.
A. Components of the Consumer Model (SGP.21/22)
GSMA's consumer RSP consists of an architecture specification (SGP.21) and a technical specification (SGP.22), and adopts a pull model in which the user drives the switch. There are four core components. The SM-DP+ (Subscription Manager–Data Preparation+) is the central server that, at the carrier's request, creates, encrypts, and stores profiles and delivers them securely to devices. The SM-DS (Subscription Manager–Discovery Server) helps the device find which SM-DP+ holds the profile awaiting it.
The LPA is the device-side mediation software described earlier, and the eUICC is the security hardware that safely installs, isolates, and runs profiles. The structure in which these four elements divide the responsibilities of creation, discovery, operation, and storage is a design to secure interoperability without lock-in to a particular carrier or device maker. That is, a profile prepared by any carrier's SM-DP+ should be installable by the same procedure on any standard-compliant LPA/eUICC—this is the core goal of the consumer model.
The reason for adopting the pull model is to put user consent and control front and center. On consumer devices, the final authority over subscription, cancellation, and switching should rest with the user, so instead of the server arbitrarily pushing a profile, the user initiates with a QR/activation code and consents at each installation step.
B. Profile Download and Activation Procedure
The standard procedure generally follows these steps. First, once the carrier accepts activation, it creates and reserves the subscriber's profile on the SM-DP+. Second, the user scans or manually enters the QR code (activation code) provided by the carrier on the device. The activation code contains the SM-DP+ address to connect to and a matching identifier. Third, the LPA (via the SM-DS if necessary) finds and connects to the correct SM-DP+.
Fourth, the eUICC and SM-DP+ perform mutual authentication with their respective certificates. The eUICC presents a certificate issued by the GSMA certification framework to prove it is "legitimate security hardware," and the SM-DP+ likewise proves itself. Fifth, once mutual trust is established, the SM-DP+ delivers a profile encrypted so that only that eUICC can decrypt it, and the eUICC decrypts and installs it into a dedicated security domain (ISD-P). Sixth, when the user activates the profile, the device attaches to the network with that subscription data, is authenticated, and begins communication.
An important premise in this process is that receiving the first profile requires a network connection of some form (Wi-Fi or a pre-installed bootstrap profile). That is, to resolve the circular problem that "communication requires a profile, but receiving a profile requires communication," a design that embeds an initial-access bootstrap profile at shipment is commonly used in IoT devices.
C. The M2M Model and the IoT Model
Before the consumer model, the M2M model (SGP.01 architecture, SGP.02 technical specification) was standardized first for devices not operated by people, such as cars and smart meters. The M2M model is a push scheme in which the server, not the user, drives profile changes, and the SM-SR (Subscription Manager–Secure Routing) handles remote management of the eUICC. Server-driven management is reasonable for devices where there is no person to operate them.
However, the M2M approach had constraints in inter-carrier interworking and scalability, and the IoT model (SGP.31 architecture, SGP.32 technical specification) was introduced to address them. According to recent material, SGP.32 v1.2 was published in June 2024 and is presented as the technical baseline for IoT RSP (the exact version/timing should be verified against GSMA's original text); it reuses the consumer model's SM-DP+, replaces the legacy SM-SR with the eIM (eSIM IoT Remote Manager), and aims to apply the consumer model's flexibility to large-scale IoT devices that have no or limited operating UI. In addition, IFPP-family work (SGP.41/42) covering in-factory injection is also under way.
| Standard family | Target | Change driver | Remote manager | Characteristics |
|---|---|---|---|---|
| SGP.01/02 | M2M | Server (push) | SM-SR | Early industrial, scalability constraints |
| SGP.21/22 | Consumer | User (pull) | SM-DP+ · SM-DS | QR/user-consent centric |
| SGP.31/32 | IoT | Server/remote mgmt (eIM) | SM-DP+ · eIM | Large-scale, UI-constrained devices |
The divergence of the three models stems from two axes: "who operates" and "how many devices are handled." Devices used by people suit the pull model for consent and control; a small number of industrial devices without people suit server-driven management; and large-volume IoT without people suit the IoT model, which combines consumer flexibility with server-managed automation. However, since version lineages and naming interpretations may differ by vendor, actual design/procurement should verify against GSMA's original text and certification status.
4. Security Structure
The safety of eSIM/RSP stands on the principle of delivering "only between legitimate parties, an encrypted profile, only to the designated hardware." The first axis is mutual authentication. GSMA operates a certification authority (GSMA CI, Certificate Issuer) as the anchor point of trust and issues certificates to participants such as the eUICC and the SM-DP+. During download, the eUICC and SM-DP+ verify this certificate chain to confirm that the counterpart is a legitimate, standard-compliant entity; a forged server or cloned chip cannot pass this verification.
The second axis is confidentiality and hardware-bound encryption. The profile is encrypted in transit and, in particular, is bound so that only the target eUICC can decrypt it, so even if intercepted midway it cannot be installed on another device. The third axis is the eUICC's own tamper-resistant hardware. The eUICC obtains a high assurance level based on Common Criteria (CC) (e.g., EAL4+ or higher) and industry certifications such as GSMA eUICC Security Assurance (eSA), protecting authentication keys and profiles from physical and side-channel attacks.
Thanks to this multi-layer structure, eSIM is not weaker in security than physical cards. Rather, the risks of card loss, cloning, and physical skimming are reduced, and remote immediate deactivation/deletion becomes possible, speeding response to a lost device. On the other hand, since the server (SM-DP+) and certification framework are added as attack surfaces, the operator newly bears responsibility for server security, key management, and certificate lifecycle management. In other words, the trust boundary has expanded from "a plastic card" to "a distributed server/certification ecosystem," and managing this entire expanded boundary is the essence of eSIM security.
5. Effects Versus Physical SIM and Industrial Application Cases
The benefits of adoption appear from the perspectives of three parties. From the user's perspective, switching carriers and subscribing to overseas roaming plans become possible within minutes without a store visit, and using a physical SIM and eSIM together as dual SIM allows running work/personal numbers or domestic/overseas lines on one device. From the carrier's perspective, SIM manufacturing, distribution, and inventory costs are reduced, and online activation improves subscription conversion and the contactless subscription experience. From the maker's perspective, removing the card slot enables waterproofing, miniaturization, and internal space savings.
Industrial cases are distinct by field. First, in smartphones/wearables, cellular smartwatches use eSIM to share a phone number with the main unit, and global flagship devices are increasingly launching eSIM-only models. Second, in connected cars, an eUICC is mounted in the vehicle telematics control unit (TCU) so that after the car is built, the profile for the sales country/carrier is injected remotely and carriers are changed/renewed over the vehicle's lifetime. It becomes possible to build vehicles for the whole world on a single production line while localizing the communications.
Third, in large-scale IoT, hundreds of thousands to millions of smart meters, logistics trackers, and industrial sensors are manufactured to a single specification and deployed, after which carriers/plans are switched remotely in the field. For example, when a given country's carrier withdraws from the business or changes pricing, the profiles of the entire device fleet can be reconfigured without a physical visit, greatly reducing operating expense (OPEX). This flexibility of "one hardware, many carriers" leads to the concrete value of supply-chain simplification and global deployment speed.
6. Deep Dive — Latest Trends and Ecosystem Changes
First, the maturation of the IoT RSP standard. The SGP.32-family IoT model reuses the consumer SM-DP+ and performs remote management with the eIM, evolving in a direction that mitigates the inter-carrier interworking and scalability limits of the past M2M (SGP.02). This reflects the industry demand to enable "flexible carrier switching at consumer level without human intervention" in large-scale IoT. However, commercial deployment timing/progress should be viewed as market trends distinct from the completion of the standard itself.
Second, accelerating integration into the iSIM. When the subscriber module is absorbed into the AP/SoC secure area, BOM, area, and power are further reduced, which is advantageous for ultra-small, low-power, high-volume IoT. However, since maturity of the SoC supply chain, security certification, and design-asset (IP) ecosystem is a precondition, eUICC-based eSIM and iSIM are expected to coexist by use case for the time being.
Third, domestic trends. In Korea too, major makers and carriers support smartphone eSIM and dual SIM (physical SIM + eSIM), and on the regulatory/terms side, identity-verification procedures to prevent identity theft in contactless activation are being established alongside. As subscription data turns into data, procedures for identity verification, prevention of illegal activation, and loss response emerge as core tasks for service trust.
Fourth, expected exam directions. From a Professional Engineer's perspective, an effective composition links ① the role distinction among eUICC/profile/LPA and the RSP download procedure, ② the differences among the consumer/M2M/IoT models and their causes, ③ the security mechanisms of GSMA CI-based authentication/encryption, and ④ the application value and operational considerations in connected cars and large-scale IoT. Related similar topics such as UICC/USIM, connected-car security, IoT device management, and the linkage with PKI/certificate lifecycle may be examined together.
7. Considerations and Implications (Professional Engineer's Perspective)
- Interoperability/lock-in strategy: The value of eSIM comes from interoperability through standards compliance. To avoid lock-in to a particular SM-DP+/LPA/device combination, procurement should require GSMA certification status and supported features (whether multi-profile, MEP, and IoT model are supported) as specifications, and verify vendor-by-vendor differences in version/naming interpretation against the original text.
- Managing the expanded security boundary: Since the trust boundary expands from a plastic card to a server/certification ecosystem, SM-DP+ security, the certificate lifecycle (issuance, renewal, revocation), key management, and logging/audit trails must be designed in an integrated way. The speed of remote deactivation/deletion upon loss/theft is a strength, but conversely one must assume the two-sidedness that the impact scope upon a server breach is also larger.
- Bootstrap/offline recovery design: To resolve the circular dependency in which profile download requires an initial network, IoT devices must be designed with a bootstrap profile and a fallback/recovery procedure for failures. Especially on devices without a UI, remote management (eIM) and monitoring/retry policies govern availability.
- Regulation/privacy/consumer protection: One must jointly consider identity verification and identity-theft prevention for contactless activation, roaming/billing/data-sovereignty issues when profiles move across borders, and the market-competition/lock-in-mitigation effects that ease of carrier switching may induce. Technology adoption is sustainable only when it proceeds alongside terms, legislation, and user-protection procedures.
- Total cost of ownership (TCO) and transition strategy: Initially there are costs to build the server/interworking/certification framework, but in large-scale, global deployment the TCO advantage grows through savings in SIM distribution, field replacement, and supply-chain costs. It is realistic to establish a period of parallel operation with physical SIM, legacy-device compatibility, and a phased transition roadmap.
References
- GSMA, "eSIM Specifications (SGP.21/22/31/32, etc.)": https://www.gsma.com/esim/esim-specification/
- GSMA, "eSIM for consumer devices": https://www.gsma.com/esim/
- Onomondo, "SGP.02 vs SGP.22 vs SGP.32": https://onomondo.com/blog/sgp-02-vs-sgp-22-vs-sgp-32/
- Kigen, "LPA (Local Profile Assistant) glossary": https://kigen.com/resources/glossary/lpa/
In one line: eSIM/RSP converts the telecom subscription from a removable card into data (a profile) on an eUICC/iSIM, and uses a GSMA-certification- and encryption-based SM-DP+/SM-DS/LPA architecture to perform remote installation, switching, and deletion securely, providing supply-chain simplification and operational flexibility from consumer devices to connected cars and large-scale IoT.