What SGP.32 changes for IoT
Before SGP.32, IoT devices had two imperfect eSIM options. SGP.02, the original M2M standard, put remote management in the hands of an operator-controlled platform, so changing provider usually depended on the incumbent operator’s co-operation. SGP.22, the consumer standard, gave control to the user, but expected a person to scan a QR code or confirm on a screen, which doesn’t work for an unattended sensor or router.
SGP.32 was written for IoT from the start. It lets the device owner manage operator profiles remotely, at scale, with no user interaction and no dependence on the original operator to release the device. It is also designed to work with constrained devices that only connect occasionally on NB-IoT and LTE-M.
What the standard actually defines
SGP.32 is built around four roles. Everything else marketed under the SGP.32 banner sits outside the specification.
| Role | Where it sits | What it does |
|---|---|---|
| eUICC | In the device, soldered or as a removable card | The secure chip that stores operator profiles. Its spec version is fixed at manufacture. |
| IPA (IoT Profile Assistant) | In device firmware (IPAd) or on the eUICC (IPAe) | Collects instructions from the eIM and downloads profiles to the eUICC. |
| eIM (eSIM IoT Manager) | Cloud | Manages profiles on the eUICC on behalf of the device owner: download, enable, disable, delete. |
| SM-DP+ | Cloud, one per operator or provider | Prepares and delivers each operator’s profiles. |
The standard also includes a fallback mechanism, so a device whose newly enabled profile can’t connect can return to a designated profile rather than going offline.
Where orchestration platforms come in
An eIM manages eUICCs. A real fleet, though, may span several connectivity providers, more than one eIM, a mix of SGP.32 and older devices, and business rules that change over time. Vendors have built platforms to sit above all of that, sold under names such as eSIM orchestrator (eSO), connectivity management platform, or simply the provider’s portal.
These platforms usually add a single view across providers, policy rules, bulk operations, billing and usage data, and APIs into the customer’s own systems. At scale they can be genuinely useful.
The key point: the eSO is not a GSMA-defined role and isn’t part of SGP.32. The eIM is standardised; the platform above it is a product. Treat its features as proprietary, because they are.
Orchestration also can’t change what the device underneath can do. No platform can upgrade an SGP.22 eUICC to SGP.32, add profile memory or radio bands, or reach a device with no coverage. Profile switches take minutes, so they suit planned changes of provider rather than moment-to-moment network selection.
Why the market is moving to the management layer
SGP.32 has moved from specification to commercial service during 2026. Telenor IoT began shipping standardised SGP.32 in April, Tele2 IoT has demonstrated end-to-end SGP.32 with partners, and Soracom has reached general availability. In September, Onomondo launched its own eIM, explicitly positioned against vendor lock-in.
The pattern is clear. Once switching profiles becomes a standard capability, it stops being a differentiator, and providers compete instead on the management layer: who runs the eIM, how open it is, and what the platform on top can do. That makes the eIM and orchestration choice one of the most consequential decisions in an SGP.32 deployment.
Where lock-in now sits
SGP.32 removes the operator lock-in that was common under SGP.02. But control has to live somewhere, and it now lives in the eIM and the platform above it. If either is closed or tied to a single provider, the lock-in hasn’t disappeared. It has moved up the stack.
Before committing a fleet, ask:
- Can the eUICCs be moved to a different eIM, and what does that involve?
- Will the platform manage profiles from providers other than its owner?
- Can device, profile and policy data be exported in a usable form?
- What happens if the platform is sold, changes strategy or shuts down?
- Which eUICC spec version, and which IPA model (IPAd or IPAe), does the provider support?
The answers belong in the contract, not just the sales conversation.
The IoTPortal view
SGP.32 does what it set out to do: it gives device owners control over connectivity. The commercial battle has shifted to who provides that control, and on what terms. Buyers who separate the standardised parts from the proprietary ones, and secure portability at the eIM level, will keep the flexibility SGP.32 was designed to deliver.
For the full technical breakdown of the SGP.32 roles, including a diagram of where orchestration sits, see euicc.co.uk’s guide to SGP.32 orchestration.
First published October 2025. Rewritten October 2026 to separate what SGP.32 defines from vendor orchestration platforms, and to reflect commercial SGP.32 deployment.
