eSIM/eUICC Provisioning Architecture: RSP, SM-DP+, and LPA Integration
Overview
eSIM is routinely described as a feature. It is an infrastructure system.
The GSMA Remote SIM Provisioning (RSP) architecture — defined under SGP.02 for M2M deployments and SGP.22 for consumer and IoT devices — involves a set of interoperating platform components that most product teams only partially understand when they begin integration. Misunderstanding the architecture leads to integration failures that are difficult to diagnose and expensive to remediate at scale.
This article documents how the RSP architecture fits together: the role and behaviour of each platform component, the provisioning sequence at protocol level, and the failure modes most commonly encountered in production deployments.
Definitions
eUICC (Embedded Universal Integrated Circuit Card)
An embedded SIM that conforms to the GSMA eUICC specification. Unlike a removable SIM, an eUICC is soldered to the device PCB. Its credential content — operator profiles — can be remotely provisioned, switched, and deleted over the air, without physical access to the device.
EID (eUICC Identifier)
A 32-digit globally unique identifier assigned to an eUICC at manufacturing time. The EID is analogous to a hardware serial number for the eUICC — it identifies the specific physical chip, not any particular operator subscription. Profile packages are cryptographically bound to a specific EID.
RSP (Remote SIM Provisioning)
The GSMA-specified architecture and protocol set for remotely managing profiles on an eUICC. Two variants exist: SGP.02 (M2M RSP, operator-initiated, no LPA) and SGP.22 (Consumer/IoT RSP, device-initiated via LPA).
SM-DP+ (Subscription Manager Data Preparation Plus)
The operator-side platform component responsible for preparing, encrypting, and delivering operator profiles to eUICCs. The SM-DP+ holds profiles in encrypted form; it binds each profile package to a specific EID before delivery.
SM-DS (Subscription Manager Discovery Server)
A GSMA-operated or operator-operated discovery service that stores pending event records. When an SM-DP+ has a profile ready for a device, it registers an event with the SM-DS. The device LPA queries the SM-DS to discover which SM-DP+ has a pending notification for its EID.
LPA (Local Profile Assistant)
The on-device software component that orchestrates the RSP provisioning flow. The LPA handles SM-DS queries, manages the HTTPS session to the SM-DP+, passes APDU command sequences to the eUICC over the ISO 7816 interface, and surfaces profile management to the user or device management system.
GSMA CI (Certificate Issuer)
The GSMA-operated PKI that issues certificates to SM-DP+ operators and eUICC manufacturers. Mutual TLS authentication between the LPA/eUICC and the SM-DP+ uses certificates anchored in the GSMA CI trust hierarchy.
Platform Architecture
SM-DP+
The SM-DP+ is the profile preparation and delivery server. Its core functions are:
- Profile preparation: Encrypting operator profile packages against the target eUICC's public key, which was established at eUICC manufacturing time and is registered with the SM-DP+ during the profile binding process.
- EID binding: Associating a prepared profile with a specific eUICC EID. A profile package bound to EID-A cannot be installed on EID-B — the binding is cryptographic, not merely administrative.
- Delivery lifecycle management: Tracking profile download status (prepared, downloaded, installed, enabled, disabled, deleted) and managing re-download eligibility.
- Event notification to SM-DS: Registering a pending event record with the appropriate SM-DS when a profile is ready for delivery.
The SM-DP+ communicates with the device LPA over HTTPS with mutual TLS authentication. Both parties present certificates issued by the GSMA CI. The SM-DP+ does not communicate directly with the eUICC — it delivers encrypted profile packages to the LPA, which passes them to the eUICC over the local APDU interface.
SM-DS
The SM-DS is a discovery and routing service. Its role is architecturally narrow but operationally essential: it decouples the device's activation from prior knowledge of which operator will provision it.
At activation, the device LPA queries the SM-DS using the eUICC's EID. The SM-DS returns any pending event records registered against that EID — including the address of the SM-DP+ that holds a profile for the device. The device then connects directly to that SM-DP+.
This architecture means a device does not need to be pre-configured with an operator's SM-DP+ address at manufacture time. It discovers its provisioning server at activation, enabling flexible operator selection and post-sale operator assignment.
LPA
The LPA is the on-device RSP orchestration layer. On consumer devices, the LPA surfaces a profile management UI. On M2M and IoT devices operating in machine-managed mode, the LPA responds to device management commands rather than user input.
The LPA's responsibilities include:
- Querying the SM-DS for pending event records
- Establishing and managing the HTTPS session to the SM-DP+
- Passing the profile package to the eUICC as a sequence of APDU commands over the ISO 7816 interface
- Returning download confirmation to the SM-DP+
- Surfacing profile management operations (enable, disable, delete) to the management layer
On constrained embedded devices, the LPA is typically implemented as a firmware component. Its interaction with the eUICC is via the local ISO 7816 interface — not over any network path.
Provisioning Sequence
The SGP.22 profile download sequence proceeds as follows:
Step 1 — SM-DS query.
The device LPA initiates a connection to the SM-DS, presenting the eUICC's EID. The SM-DS returns any pending event records registered for that EID, including the SM-DP+ address.
Step 2 — Mutual TLS authentication.
The LPA initiates an HTTPS session to the SM-DP+. Both the LPA/eUICC and the SM-DP+ present certificates issued by the GSMA CI. Mutual authentication is established before any profile data is exchanged.
Step 3 — AuthenticateClient.
The LPA sends an AuthenticateClient request to the SM-DP+, including the eUICC's EID and a signed challenge. The SM-DP+ validates the eUICC's credentials against its registered EID and the GSMA CI trust chain.
Step 4 — Profile package delivery.
The SM-DP+ prepares and delivers the encrypted profile package. The package is encrypted against the eUICC's public key — a key established at eUICC manufacturing time and not accessible to the SM-DP+, the LPA, or any other party. Only the target eUICC can decrypt it.
Step 5 — APDU delivery to eUICC.
The LPA passes the encrypted profile package to the eUICC as a sequence of APDU commands over the ISO 7816 interface. This is a local operation — no network path is involved at this stage.
Step 6 — eUICC decryption and installation.
The eUICC decrypts the profile package using its private key, validates the package integrity, and installs the profile into its profile storage. The decrypted profile content never leaves the eUICC.
Step 7 — Installation confirmation.
The eUICC returns an APDU response confirming successful installation. The LPA sends a HandleNotification confirmation to the SM-DP+, updating the profile lifecycle state.
Step 8 — Profile enablement.
The newly installed profile can be enabled via the LPA profile management interface or via device management command, replacing the previously active profile.
Production Failure Modes
LPA treated as a generic HTTP client
The SM-DP+ interface is more constrained than a standard REST API. The APDU command sequences to the eUICC have timing and sequencing requirements that generic HTTP retry logic does not accommodate. A dropped TLS session mid-profile-download leaves the eUICC in a partial installation state that requires a specific recovery sequence — not a simple retry of the download request.
Mitigation: Implement session state tracking in the LPA. Distinguish between pre-installation failure (safe to retry from Step 3) and mid-installation failure (requires eUICC state interrogation before retry).
EID management breakdown at fleet scale
In a fleet deployment, the mapping between EID, SM-DP+ profile binding, and device identity record must be maintained across the provisioning infrastructure. If EID-to-device-identity mapping breaks — due to a provisioning pipeline failure, a factory reset, or an incorrectly issued profile — recovery requires re-provisioning through the full SGP flow. There is no administrative shortcut.
Mitigation: Treat EID-to-identity mapping as a first-class data integrity requirement. Write EID records transactionally with the device identity record at manufacturing time. Maintain the mapping in a system that supports audit history.
SM-DS event record accumulation
SM-DS event records that are not successfully consumed by the LPA (due to device offline periods, LPA failures, or network issues) accumulate. On devices that go offline for extended periods and then reconnect, a backlog of pending event records can cause unexpected provisioning sequences.
Mitigation: Implement event record processing logic in the LPA that handles multiple pending records gracefully — processing them in order, with appropriate state validation between records.
Certificate chain validation failure at SM-DP+ connection
GSMA CI certificate chains have defined validity periods. Devices with incorrect RTC state (clock drift, factory reset of time) may fail GSMA CI certificate validation at the TLS mutual authentication step. This manifests as a TLS handshake failure that can be misdiagnosed as a network connectivity issue.
Mitigation: Ensure device clock synchronisation prior to SM-DP+ connection attempts. Implement clock validation as a pre-condition in the LPA provisioning flow.
M2M vs Consumer RSP: Key Differences
| Dimension | SGP.02 M2M | SGP.22 Consumer/IoT |
|---|---|---|
| Initiation | Operator-initiated | Device-initiated via LPA |
| LPA | Not present | Required on device |
| Profile switching | Operator-controlled | User or DM-controlled |
| SM-DS | Not used | Required |
| Primary use case | Industrial IoT, metering | Smartphones, connected devices |
Summary
The eSIM/eUICC RSP architecture is well-specified. The difficulty is not in reading the specification — it is in deploying it against real hardware constraints, real network conditions, and real fleet management requirements that the specification does not address.
The SM-DP+ is not a REST API. The LPA is not a generic HTTP client. The eUICC provisioning sequence has state that must be tracked and recovered correctly. And EID management at fleet scale is a first-class infrastructure problem, not an afterthought.
Understanding these points before integration begins is the difference between a provisioning infrastructure that operates reliably at scale and one that requires ongoing firefighting.
Related Articles
- Trust Chain Architecture: From Manufacturing HSM to Deployed Device
- Hardware-Backed Authentication: SE vs TEE vs TPM
- Telecom Authentication and Enterprise Identity: Where LTE and PKI Meet
- Device Identity at Manufacturing Scale: Fleet Provisioning Architecture
Related capability: eSIM / eUICC capability · Telecom Integration