Comprehensive technical knowledge base covering 12 GSMA eSIM specifications. 84+ articles on Remote SIM Provisioning — SGP.02, SGP.22, SGP.32, SGP.41, SGP.29, SGP.23, SGP.25, SGP.26 and more.
🏠 eUICC.tech > SGP.22 Consumer RSP > The eSIM RSP Architecture: Players and Interfaces
💡 Why this matters: Every eSIM interaction: scanning a QR code, switching carriers, provisioning a factory-fresh IoT device: flows through this architecture. Knowing the five players and thirteen interfaces is the map you need before diving into any protocol detail.
Key takeaways:
- SGP.22 defines five roles: eUICC, SM-DP+, SM-DS, LPA, and Operator (MNO)
- Thirteen standardised interfaces connect these players, each with a specific security model
- The LPA is not cryptographically trusted : it’s a messenger between authenticated endpoints
- There are two deployment models: LPAd (LPA in device) and LPAe (LPA in eUICC)
- Trust flows strictly through the GSMA CI root, with clear separation between availability and confidentiality
A physical SIM card is straightforward: the operator programs a chip, you insert it, done. The GSMA’s Remote SIM Provisioning (RSP) specification for consumer devices (SGP.22) replaces that physical step with a cryptographic protocol that delivers operator credentials over the internet into a chip that was manufactured months earlier, by a different company, in a different country.
The architecture defines five key roles and thirteen interfaces between them. Understanding who does what: and who trusts whom: is the foundation for understanding the entire system.
The chip itself. A tamper-resistant secure element running a Java Card operating system, soldered into the device (or removable in some implementations). It hosts multiple isolated Profiles: each one the equivalent of a physical SIM card. The eUICC is manufactured and personalised by the EUM (eUICC Manufacturer) in a GSMA-certified secure facility.
The profile factory. This server builds, encrypts, and delivers Profiles to eUICCs. It generates the cryptographic binding that ties a specific Profile to a specific chip, ensuring a Profile downloaded from the SM-DP+ is useless on any other eUICC. Operators either run their own SM-DP+ or use a third-party provider.
The notification service. When an SM-DP+ has a Profile waiting for a specific eUICC, it registers an “Event” on the SM-DS. The device polls the SM-DS periodically to discover pending downloads. Crucially, the SM-DS only stores pointers (Event ID, EID, SM-DP+ address) : never the Profile itself. Multiple SM-DS instances can be cascaded for global scale.
The on-device orchestrator. This is the software that runs on your phone or device, managing everything eSIM-related. It has three sub-components:
The LPA can run either in the Device (LPAd) or inside the eUICC itself (LPAe) : both architectures are valid under SGP.22.
The mobile network operator. Orders Profiles from the SM-DP+, manages them post-install via OTA (Over-The-Air) through the ES6 interface, and handles the business relationship with the end user.
| Interface | Between | Purpose |
|---|---|---|
ES2+ |
Operator → SM-DP+ | Profile ordering, confirmation, cancellation |
ES6 |
Operator → eUICC | Post-install OTA management of Operator services |
ES8+ |
SM-DP+ ↔ eUICC (via LPA) | Secure end-to-end channel for profile installation (Perfect Forward Secrecy) |
ES9+ |
SM-DP+ → LPA (LPD) | Secure transport for the Bound Profile Package |
ES10a |
LPA (LDS) → eUICC | eUICC info retrieval, SM-DS/DP address config, and discovery queries |
ES10b |
LPA (LPD) → eUICC | Profile transfer, authentication, challenge generation |
ES10c |
LPA (LUI) → eUICC | Local profile management: enable, disable, delete, rename |
ES11 |
LPA (LDS) → SM-DS | Event retrieval for the respective eUICC |
ES12 |
SM-DP+ → SM-DS | Event registration and deletion |
ES15 |
SM-DS → SM-DS | Cascading between discovery servers |
ESop |
Operator → End User | Business interface (out of scope for SGP.22) |
ESeu |
End User → LUI | User-initiated local profile management (out of scope) |
ESci |
CI → SM-DP+/SM-DS/EUM | Certificate issuance and CRL retrieval |
The architecture establishes clear trust boundaries:
ES8+ channel provides end-to-end encryption that the LPA cannot decrypt.SGP.22 supports two architectural models for where the LPA lives:
LPAd (LPA in Device): The LPA runs as software on the device’s application processor. This is how smartphones, tablets, and laptops implement eSIM today. The device handles all user interaction and profile management.
LPAe (LPA in eUICC): The LPA runs inside the eUICC itself, using either CAT (Card Application Toolkit) or SCWS (Smart Card Web Server). This model is used in constrained devices where the host device has limited capability: think IoT sensors, automotive modules, or wearables.
A device that supports a non-removable eUICC without an LPAe must provide an LPAd. An eUICC compliant with this specification must implement the LPA Services and may optionally implement the LPAe.
ES8+ providing the cryptographically critical end-to-end secure channelLPAd and LPAe) cover everything from smartphones to headless IoT devicesBased on GSMA SGP.22 v2.7 (24 April 2026), Section 2: General Architecture
| ← Previous: eSIM Remote SIM Provisioning (RSP) : How It Works | Section Index | Next: Inside the eUICC: The Secure Element That Powers Your eSIM → |