What is SGP.32?
SGP.32 is a GSMA technical specification that defines how eSIM profiles can be managed remotely on IoT devices – particularly those with no user interface, limited processing power, and constrained network connectivity. Published in May 2023 with v1.2 as the current version, it is the first eSIM standard designed specifically for the realities of modern IoT deployment.
In plain terms: SGP.32 lets you change, add, or remove the mobile network operator on a device without touching it. No SIM card swap. No physical visit. No user interaction. The change is initiated from a server and delivered over the air to the device, wherever it is in the world.
Why Does SGP.32 Exist?
The GSMA had two eSIM standards before SGP.32. SGP.02 was built for M2M and automotive – useful for connected cars, but heavy on infrastructure requirements and prone to operator lock-in. SGP.22 was built for consumer devices like smartphones – elegant for users with QR codes and apps, but impractical for a remote sensor with no screen.
Neither standard was fit for IoT at scale. Billions of devices deployed in utility cabinets, shipping containers, agricultural fields, and industrial machinery cannot have their SIMs managed by either a user with a QR code or a complex M2M SM-SR infrastructure.
SGP.32 fills that gap. It takes the best infrastructure elements from SGP.22 (the SM-DP+ server, widely deployed by operators) and combines them with a new server-initiated management model that works on the constrained networks real IoT devices actually run on.
Key fact: The GSMA estimates 195 million SGP.32 profile downloads by 2029, representing 70% of all IoT eSIM activity. The transition from SGP.02 and SGP.22 to SGP.32 in IoT deployments is well underway.
What Does SGP.32 Actually Do?
SGP.32 enables five core capabilities that earlier standards could not deliver for IoT:
- Remote profile management without user interaction – profiles are downloaded, enabled, disabled or deleted by the server, not the user
- Server-initiated provisioning – the eIM pushes changes to devices rather than waiting for devices to pull them
- Operation on constrained networks – using CoAP over UDP rather than HTTPS, profile management works on NB-IoT and LTE-M with kilobyte data budgets
- Asynchronous operations – devices in deep sleep receive management instructions when they next wake, no persistent connection required
- Multi-operator flexibility – enterprises are not locked to a single network operator for the lifetime of a device
The Three Key Components
eIM – eSIM IoT Manager
The server-side orchestration layer. The eIM manages the complete profile lifecycle – downloading, enabling, disabling and deleting profiles across individual devices or entire fleets. It replaces the SM-SR from SGP.02 and removes the user-initiated pull model of SGP.22.
IPA – IoT Profile Assistant
The device-side agent. The IPA replaces the LPA used in SGP.22 consumer devices. Unlike the LPA, the IPA has no user-facing functions – it exists purely to receive instructions from the eIM and manage profile operations on the eUICC.
SM-DP+ – Subscription Manager Data Preparation Plus
The profile preparation and delivery server. Deliberately reused from SGP.22 – operators who already run SGP.22 infrastructure can serve SGP.32 devices without rebuilding their backend systems from scratch.
SGP.32 vs SGP.31
SGP.31 is the architecture and requirements document that defines what the IoT eSIM system must do. SGP.32 is the technical specification that defines how it must do it. When you read about SGP.32, the underlying requirements come from SGP.31.
Who Needs to Understand SGP.32?
- IoT hardware designers and OEMs – choosing the right eSIM chipset and module for new device designs
- Enterprise IoT operators – understanding what remote SIM management looks like for existing and future fleets
- Network operators and MVNOs – building the eIM and SM-DP+ infrastructure to serve SGP.32 devices
- Systems integrators – specifying connectivity for deployments that will last 10 to 20 years
For a technical deep dive into how these components work together, see the SGP.32 Architecture guide. For a direct comparison with earlier standards, see SGP.32 vs SGP.02 and SGP.22.