SGP.32 Explained
SGP.32 is the GSMA specification for remote SIM provisioning on IoT devices. It solves the problem that stalled eSIM adoption in IoT for a decade: how to manage millions of headless, low-power, unattended devices without physical SIM swaps, QR codes, or user interfaces. The key change is the introduction of the eIM – the eSIM IoT Remote Manager – which replaces the human activation step with server-driven orchestration at any scale.
Why SGP.32 exists
Earlier eSIM approaches were built around assumptions that don’t fit IoT. eUICC hardware was already mature – the problem was the provisioning architecture sitting above it. Consumer eSIM (SGP.22) requires a human to scan a QR code or tap a UI. Classic M2M (SGP.02) requires deep bilateral integration between the operator and the subscription manager. Neither standard was designed for a sensor buried in a field, a meter sealed inside a cabinet, or a tracker bolted to a vehicle.
SGP.32 fills that gap by introducing a lightweight, server-driven model that works on constrained networks – including NB-IoT and LTE-M – without requiring any local user action.
How we got here: the standards evolution
SGP.02 – the first M2M standard
Designed for automotive and industrial M2M. Server-push provisioning, operator-controlled, deep SM-SR integration required. Worked for high-value connected cars. Impractical for large-scale low-cost IoT due to switching costs and operator lock-in.
SGP.22 – the consumer eSIM standard
Transformed connectivity for smartphones and wearables. Pull-based, QR code or activation code triggered. Elegant for devices in human hands – a dead end for IoT. The entire architecture assumed a user was present to initiate every profile change.
The IoT gap – neither standard fits
IoT deployments were scaling fast. Two billion connected devices. Yet eSIM adoption outside automotive remained near zero. SGP.02 demanded complex infrastructure and operator lock-in. SGP.22 demanded a user. The industry needed a new standard.
SGP.32 – the IoT-native standard
GSMA published SGP.31 (architecture spec) followed by SGP.32 (technical spec). The eIM replaced the SM-SR. The IPA replaced the LPA. Profile management became server-driven, lightweight, and designed for NB-IoT and LTE-M via CoAP over UDP. v1.2 is the current version.
Adoption begins – hardware catches up
Certified modules are reaching the market. The GSMA estimates 195 million SGP.32 profile downloads by 2029 – 70% of all IoT eSIM activity. Most devices in field still run SGP.02 or SGP.22, but the transition is real and accelerating.
SGP.32 architecture: eIM, IPA and eUICC
SGP.32 introduces three new components that sit above the eUICC hardware and replace the human-facing elements of earlier standards.
eIM – eSIM IoT Remote Manager
The central orchestration platform. Enterprise teams use the eIM to remotely trigger profile downloads, activations, suspensions and deletions across entire device fleets via API. This is what replaces the human at the point of activation – the eIM is the new operator of the SIM lifecycle. eSIM IoT Manager is a platform built for this role.
IPA – IoT Profile Assistant
The execution layer on or near the device. Receives instructions from the eIM and translates them into actions on the eUICC – installing, enabling, disabling or deleting profiles. Can reside on the eSIM itself (IPAe) or in device firmware (IPAd). Replaces the LPA from SGP.22.
eUICC – the chip
The certified secure element that physically stores and executes operator profiles. Must be certified for SGP.32 – not all existing eUICC chips are compatible. The eUICC is permanent; what changes over the air are the profiles it holds.
CoAP / DTLS over UDP
SGP.32 replaces HTTPS/TCP with CoAP over UDP secured by DTLS. This dramatically reduces signalling overhead and power consumption – making SGP.32 viable on NB-IoT and LTE-M networks where TCP overhead would be prohibitive.
For a detailed breakdown of the full architecture including eIM portability and SM-DS roles, see the SGP.32 architecture guide at SGP32.co.uk.
IPAe vs IPAd: the key hardware decision
One of the most important choices in an SGP.32 deployment is where the IPA lives. This is set at hardware design time and has long-term operational implications.
IPAe – IPA embedded on the eSIM
- Profile management logic lives on the eUICC itself
- Independent of device firmware and module OS
- Consistent behaviour across firmware updates
- Easier to change modules without affecting provisioning
- Lower long-term maintenance complexity
- Better for multi-vendor, large-scale deployments
IPAd – IPA in device firmware
- Profile management logic lives in the device OS or modem firmware
- Tighter integration with application logic possible
- Can enable conditional provisioning based on device state
- Firmware dependencies increase testing and maintenance
- Provisioning logic may need updating after firmware changes
- Stronger coupling between hardware and connectivity strategy
Full IPAe vs IPAd trade-off analysis including certification and interoperability considerations is covered at SGP32.co.uk – IPA-e vs IPA-d.
Bootstrap connectivity
Every SGP.32 device still needs an initial bootstrap profile to establish first contact with the eIM. This profile is active at power-on and enables the provisioning transaction that loads the operational profile.
The bootstrap dependency is one of the most overlooked risks in SGP.32 planning. If the bootstrap profile lacks coverage at the deployment site, or carries commercial restrictions that prevent the provisioning transaction completing, the device cannot activate remotely – defeating the purpose of SGP.32 entirely. A device shipped to a rural UK site with a bootstrap SIM limited to a single network may simply never provision.
Best-practice deployments use neutral, globally roaming bootstrap profiles with limited data allowances and clear exit conditions. Once the operational profile is downloaded, the bootstrap profile is disabled or removed. Evaluating bootstrap providers is a critical procurement step – not an afterthought. See the bootstrap provider selection guide at SGP32.co.uk.
What changes for IoT deployments
SGP.32 shifts how connectivity is managed across the device lifecycle in four practical ways:
| Property | SGP.02 (legacy M2M) | SGP.22 (consumer) | SGP.32 (IoT) |
|---|---|---|---|
| Published | 2012 | 2016 | 2023 (v1.2 current) |
| Target | Industrial M2M, automotive | Smartphones, wearables | Headless IoT at scale |
| Provisioning model | Server-push, operator-driven | Pull-based, QR / activation code | eIM server-driven, automated |
| Human required | No | Yes – always | No – zero-touch |
| NB-IoT / LTE-M | No | No | Yes – CoAP/DTLS |
| Enterprise control | Operator-mediated | User-initiated | Direct via eIM API |
| Operator switching | Complex, bilateral | Manual re-scan | Remote, API-driven |
| Single SKU manufacturing | Difficult | No | Yes |
| Status | Legacy / active | Consumer only | Current IoT standard |
What SGP.32 does not solve
SGP.32 is not a substitute for good physical infrastructure. It does not improve signal strength, fix antenna placement, resolve coverage gaps, or make a poorly managed network estate reliable. If the device cannot get online at all, remote provisioning is constrained by the same physical reality as any other cellular service.
Interoperability between certified components also remains imperfect in practice. A certified eUICC from one vendor may behave unexpectedly when paired with a module from another and managed by a third-party eIM – even when all three claim SGP.32 compliance. Production-scale validation before mass rollout is essential, not optional.
SGP.32 and existing deployments
Most current industrial eSIM router deployments still use SGP.22-style mechanisms combined with vendor cloud platforms – Teltonika RMS, Cradlepoint NetCloud, and similar. That delivers useful operational functionality today and will continue to do so for years. SGP.32 should be viewed as the direction of travel for IoT eSIM control, not a switch that makes every existing deployment obsolete overnight.
Migration from SGP.02 or SGP.22 to SGP.32 cannot be done over the air – it requires hardware replacement. Enterprises managing large estates should plan for 3-5 years of parallel operation as natural device refresh cycles allow gradual transition. For planning a migration, the questions to ask your eSIM provider guide at SGP32.co.uk is a useful procurement reference.
Frequently asked questions
What does SGP.32 stand for?
SGP.32 is a GSMA specification number – SGP stands for SIM Group Protocol, and 32 is the document version in the series. The companion architecture document is SGP.31. The current version is SGP.32 v1.2, published May 2023.
What is the eIM in SGP.32?
The eIM (eSIM IoT Remote Manager) is the management platform that orchestrates profile changes across a device fleet. It replaces the human activation step in consumer eSIM with server-driven instructions sent remotely to each device’s eUICC. eSIM IoT Manager is an enterprise eIM platform built for SGP.32 deployments.
Does SGP.32 replace SGP.02?
SGP.32 is the strategic successor for new IoT deployments. SGP.02 will remain operational in existing estates for many years due to long device lifecycles. New hardware procurement should default to SGP.32. SGP.02 devices cannot be upgraded to SGP.32 over the air.
Can SGP.32 work on NB-IoT and LTE-M?
Yes – this is one of the primary design goals of SGP.32. It uses CoAP over UDP secured by DTLS rather than HTTPS/TCP, which dramatically reduces signalling overhead and power consumption. This makes it viable on constrained low-power networks where TCP stack overhead would be prohibitive.
Do I need special hardware for SGP.32?
Yes. Devices need an eUICC certified for SGP.32, a compatible cellular module, and firmware supporting IPA functionality. Not all existing IoT hardware platforms are compatible. Confirming SGP.32 certification on both the eUICC and the module is an essential procurement step. See the eSIM hardware guide at SGP32.co.uk for module-level detail.
What is the difference between IPAe and IPAd?
IPAe places the IoT Profile Assistant on the eUICC itself, making provisioning logic independent of device firmware. IPAd places it in the device OS or modem firmware, allowing deeper integration but creating firmware dependencies. IPAe is generally recommended for large-scale deployments. Full comparison at SGP32.co.uk.
What is a bootstrap profile and why does it matter?
A bootstrap profile is the initial operator profile loaded on the eUICC at manufacture. It provides the first cellular connection that allows the device to reach the eIM and download the operational profile. If the bootstrap profile lacks coverage at the deployment site, remote provisioning cannot happen. Selecting a bootstrap provider with genuine multi-network UK and EU coverage is a critical planning step.
Is SGP.32 secure?
SGP.32 complies with GSMA SAS-SM security requirements. Profile delivery is encrypted and authenticated. Enterprises should also secure eIM APIs, enforce role-based access controls, and audit provisioning activity. Certification covers the protocol – operational security depends on how the platform is configured and managed. See the SGP.32 security deep dive at SGP32.co.uk.
How long does SGP.32 migration take from SGP.02?
Migration requires hardware replacement – it cannot be done over the air. Enterprises managing large estates should plan for 3-5 years of parallel operation, running SGP.02 and SGP.32 infrastructure side by side as devices are refreshed. Some connectivity platforms can manage both standards through a single interface to reduce operational burden during transition.