GSMA SGP.32 IoT eSIM Reference
The IoT-specific eSIM Remote SIM Provisioning architecture. Replaces SGP.22's user-driven activation flow with an unattended IoT Profile Assistant (IPA) and a Profile Provisioning Discovery service. The structural lessons from SGP.32 inform every other unattended fleet-credential lifecycle — V2X EC/PC included.
Scope & status
What SGP.32 defines
The eSIM Remote SIM Provisioning architecture for IoT devices that cannot drive a user-interactive profile-download UI. Introduces IPA, the eIM (eSIM IoT Manager), and the variant SM-DP+ / SM-DS interactions tailored for headless devices.
How it differs from SGP.22
SGP.22 (consumer) assumes a device with a screen and a user. The profile download is triggered by a QR-code scan or activation code entered by the user. SGP.32 (IoT) assumes neither — profile pull happens autonomously based on device identity and policy.
Hardware root
The eUICC is a tamper-resistant secure-element that holds the long-term eUICC identity and the downloaded operational profiles. CC EAL5+ is the typical certification level for eUICC silicon. The eUICC private key never leaves the boundary.
Architecture entities
eUICC
The hardware secure element — embedded, removable, or integrated (iSIM). Holds the eUICC certificate (EUM-issued), profile metadata, and the active operational profile. Speaks SGP.32 over the host IPA.
IPA (IoT Profile Assistant)
Host-side software (on the device's application processor) that intermediates between the eUICC and the network. Drives the profile-download HTTP exchange that a consumer-device UI would otherwise drive.
eIM (eSIM IoT Manager)
Optional remote management entity. Coordinates profile lifecycle across fleets: which device gets which profile, when to switch, when to delete. The fleet-operator-side authority for eSIM lifecycle.
SM-DP+ (Subscription Manager — Data Preparation+)
The operator-side credential preparation service. Holds operational profiles, packages them into the BPP (Bound Profile Package), encrypts to the target eUICC, serves them on request.
SM-DS (Subscription Manager — Discovery Service)
Indexes pending profile events by eUICC identity. Lets a device find which SM-DP+ has a profile waiting for it without the device knowing the SM-DP+ address in advance.
EUM (eUICC Manufacturer)
Manufactures the eUICC and signs its certificate. Trust anchor for the eUICC identity. Equivalent to the V2X manufacturer attestation step that precedes EA enrolment.
IoT profile-download flow
1. Discovery
IPA queries SM-DS with the eUICC identity. SM-DS returns the SM-DP+ address(es) holding pending profile events for this eUICC, or empty if none.
2. Mutual authentication
IPA establishes a TLS connection to SM-DP+. eUICC and SM-DP+ perform certificate-based mutual authentication: eUICC certificate signed by EUM, SM-DP+ certificate signed by the GSMA CI Root CA. Both validate against trust anchors.
3. BPP delivery
SM-DP+ packages the operational profile as a Bound Profile Package (BPP), encrypted to the eUICC's ephemeral session key established during authentication. IPA forwards the BPP to the eUICC.
4. Profile install
eUICC decrypts the BPP, validates its integrity, installs the profile as the active or pending profile. Acknowledges back through IPA → SM-DP+. The download event is then complete on both sides.
Operational lifecycle
Profile enable / disable
An eUICC may hold multiple profiles but only one active at a time. Enable / disable is managed locally by IPA or remotely by eIM. Disabled profiles remain installed and can be re-enabled without re-download.
Profile delete
Permanent removal of a profile from the eUICC. Frees eUICC memory; the profile must be re-downloaded if needed again. Triggered by IPA or eIM.
Profile swap
Sequential disable-of-current + enable-of-target. The eUICC enforces atomicity so the device is never left in an "active but unconfigured" state.
eIM-driven fleet operations
The eIM can orchestrate profile changes across a fleet without per-device user interaction. The eSIM IoT lifecycle scales structurally because the orchestration layer is built into the architecture.
SGP.32 ↔ V2X EA / AA structural parallel
The two architectures solve different problems — eSIM provides telecom credentials, V2X provides signed-message credentials — but the architectural patterns rhyme. Designing one informs the other.
| Concept | SGP.32 (eSIM IoT) | V2X (ETSI TS 102 941) |
|---|---|---|
| Hardware root | eUICC + EUM cert chain | Secure element + manufacturer attestation |
| Identity authority | EUM (manufacturer-issued eUICC cert) | Manufacturer attestation → EA (Enrolment Authority) |
| Credential authority | SM-DP+ (operator-credential preparation) | AA (Authorisation Authority) |
| Discovery service | SM-DS | (no direct equivalent; AA discovery is out-of-band) |
| Host-side intermediary | IPA (IoT Profile Assistant) | V2X stack on OBU host MCU |
| Operational credential | Operator profile (long-lived) | Pseudonymous Certificate (short-lived) |
| Fleet orchestration | eIM (eSIM IoT Manager) | Operator-side PKI orchestration |
| Privacy property | N/A (telecom requires identification) | Privacy-preserving via EA/AA split |
Implementation implications
eUICC vs discrete SE
An eUICC is a secure element with the SGP.32 application stack pre-loaded. A discrete SE used for V2X EC/PC management runs a different applet set (a JavaCard applet for 1609.2 certificate management). Same silicon class, different applications.
Provisioning convergence
A single SE can host both a V2X EC/PC applet and an eUICC profile, allowing one piece of silicon to anchor both the connectivity identity and the V2X identity. This is an architectural option, not a requirement.
Lifecycle lessons
The patterns proven at telecom scale (unattended rotation, mutual-auth profile pull, fleet orchestration via a remote manager) transpose almost directly into V2X PC lifecycle. The differences (PC rotation cadence is minutes, profile rotation cadence is months) are operational, not architectural.
India context
SGP.32 IoT eSIM deployment and TRAI-CP-30/04/2026 V2X security framework address overlapping device populations: connected vehicles, smart-meter endpoints, fleet trackers. A coherent national approach treats them as related architectures rather than separate problems.
Companion AmbiSecure pages
Ecosystem
AmbiSecure eSIM Initiative — sister-initiative within the Ambimat Group focused on eSIM lifecycle. The page that operationalises the architecture covered here.
Architecture
Adjacent references
ETSI TS 102 941 V2X PKI architecture · IEEE 1609.2 certificate format
Hardware
IoT Security Co-Processor — the secure-element platform that can host eUICC profiles and V2X applets in tandem.
External references
Standards bodies
GSMA · GSMA SGP.32 (IoT eSIM Technical Specification) · GSMA SGP.22 (Consumer eSIM RSP) · GSMA SGP.21 (Architecture)
Aligned standards
ETSI TS 103 666 (eUICC profile package) · ITU-T X.509 (certificate format for SM-DP+ / SM-DS)
Disclaimer
This page is a structural reference summary derived from the publicly available GSMA SGP.32 framework. For implementation conformance, consult the published GSMA specifications directly.