What is SGP.32?
SGP.32 is the GSMA’s eSIM IoT Technical Specification. It defines how eSIM profiles are provisioned and managed remotely on Internet of Things devices that have no screen, no keypad and often only a thin, intermittent connection. It is the piece of Remote SIM Provisioning (RSP) built specifically for constrained IoT hardware, and it lets you manage the SIM profile on a single sensor – or a fleet of a hundred thousand of them – without anyone ever touching the device.
SGP.31, SGP.32 and SGP.33: the eSIM IoT family
SGP.32 does not stand alone. It is the middle document in a set of three that together define eSIM for IoT. If you only remember one distinction, remember this: SGP.31 says what the system must do, SGP.32 says how to build it, and SGP.33 proves it works across vendors.
| Specification | Full title | Role |
|---|---|---|
| SGP.31 | eSIM IoT Architecture and Requirements | The blueprint. Sets out the eUICC architecture for IoT, the roles (including the eIM), the interfaces and the high-level requirements. |
| SGP.32 | eSIM IoT Technical Specification | The build. Turns SGP.31’s requirements into concrete data structures, commands and procedures. |
| SGP.33 | eSIM IoT Test Specification | The proof. Defines the test cases that confirm eUICCs and platforms from different vendors interoperate correctly and securely. |
This mirrors the structure of the older families: the Consumer specifications (SGP.21 / SGP.22 / SGP.23) and the M2M specifications (SGP.01 / SGP.02) follow the same architecture, technical and test pattern.
What are the key components?
SGP.32 reuses the internal eUICC architecture from the consumer specification (the ISD-R, ISD-P and ECASD security domains, and the Profile Package Interpreter all come from SGP.22) and adds the pieces that IoT actually needs.
| Component | What it does |
|---|---|
| eIM (eSIM IoT Remote Manager) | The orchestrator. Sends profile operations (download, enable, disable, delete) to one device or a whole fleet, tracks their state, and can talk to any SM-DP+ without pre-agreements. Crucially, eIM associations can be removed, which is what breaks the M2M-style lock-in. |
| IPA (IoT Profile Assistant) | The agent that carries out the eIM’s instructions on the eUICC. It replaces the consumer LPA and comes in two forms (below). |
| IPAd / IPAe | IPAd runs inside the device firmware. IPAe runs in the eUICC itself and is optional (its implementation is chip-maker specific). The eIM and SM-DP+ behave the same way regardless of which is used. |
| SM-DP+ | Prepares and delivers the bound profile package. Reused unchanged from the consumer specification, so existing platforms carry straight over. |
| eUICC | The embedded SIM chip that holds the downloaded profiles. Note the SIM can be any form factor – it does not have to be soldered down. |
How the architecture fits together
How does it differ from M2M and consumer eSIM?
The older M2M standard (SGP.02) leans on operator-hosted infrastructure (SM-DP and SM-SR) and push messaging over SMS, and it has a reputation for provider lock-in. The Consumer standard (SGP.22) assumes a person is present to scan a QR code and tap through a phone. Neither suits a solar tracker on a shipping container or a gas meter in a basement. SGP.32 takes the best of both and adds unattended, en-masse management.
| SGP.02 (M2M) | SGP.22 (Consumer) | SGP.32 (IoT) | |
|---|---|---|---|
| Triggered by | Operator push | End user | eIM, unattended |
| On-device agent | – | LPA | IPA (IPAd or IPAe) |
| Profile store | SM-DP + SM-SR | SM-DP+ | SM-DP+ (reused) |
| Transport | SMS | HTTPS | Adds CoAP and DTLS for constrained devices |
| Best for | Operator-managed M2M | Phones, wearables | Constrained IoT fleets |
| Provider switching | Prone to lock-in | User-driven | Designed to be flexible, en masse |
Lightweight by design
Many IoT devices cannot afford the overhead of HTTPS, and some spend most of their life asleep. SGP.32 accounts for that. It adds the Constrained Application Protocol (CoAP) as an alternative to HTTPS and DTLS as an alternative to TLS, and it supports asynchronous operations so a profile download or switch can be queued and completed when a power-constrained device next wakes and connects.
Where the specification stands
GSMA published SGP.32 v1.0 in May 2023, followed by v1.0.1 (which corrected some ASN.1 errors) and v1.1 in 2024, with the specification continuing to be refined to v1.3 by 2026. Silicon, eIM platforms and IPA implementations have followed, and SGP.32 is now the reference point for anyone deploying eSIM across an unattended device estate. The current status of every eSIM document is tracked on the GSMA eSIM specifications page.