The Rise of eSO Platforms: How SGP.32 eSIM Is Redefining IoT SIM Connectivity
SGP.32 is the GSMA’s eSIM standard for IoT, and it is often described alongside a layer called the eSIM Orchestrator, or eSO. The two are frequently presented as one architecture. They aren’t. SGP.32 defines a specific set of roles and interfaces. Orchestration platforms are products that vendors build on top of it. Knowing where the line sits matters when you are choosing suppliers, because it tells you which parts are standardised and portable and which parts are proprietary.
SGP.32 orchestration at a glance
- What SGP.32 defines: the eUICC, the IoT Profile Assistant (IPA), the eSIM IoT Manager (eIM), and how they work with each operator’s SM-DP+.
- What it doesn’t define: orchestration platforms, dashboards, policy engines or “eSO” products. Those are vendor layers.
- Who controls profile changes: the device owner, through the eIM, rather than the incumbent operator.
- Where orchestration helps: managing several providers, eIMs and policies from one place at fleet scale.
- The risk: lock-in can move from the operator to the platform unless portability is agreed up front.
Why IoT needed a new eSIM standard
Two earlier GSMA specifications came first. SGP.02, the original M2M standard, put remote management in the hands of an operator-controlled platform (the SM-SR) and relied heavily on SMS. It worked, but changing operator depended on the original operator’s co-operation, which made lock-in common in practice. SGP.22, the consumer standard, gave control to the user through an on-device assistant, built around someone scanning a QR code or confirming on a screen. That suits phones, not unattended sensors and routers.
SGP.32 was designed to give IoT devices the flexibility of the consumer model without needing a person, and to put control with whoever owns and operates the device.
What SGP.32 actually defines
The standard is built around four roles. Two sit in or on the device, and two sit in the cloud.
| 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 operating system and spec version are fixed at manufacture. |
| IPA (IoT Profile Assistant) | In device firmware (IPAd) or on the eUICC itself (IPAe) | Fetches instructions from the eIM, downloads profiles from the SM-DP+, and passes them to the eUICC. Replaces the user-facing assistant of SGP.22. |
| eIM (eSIM IoT Manager) | Cloud | Manages the eUICC on behalf of the device owner: which profile to download, enable, disable or delete. Takes over the remote-management job the operator-run SM-SR did under SGP.02. |
| SM-DP+ | Cloud, run by or for each operator | Prepares and delivers operator profiles, as in the consumer model. |
Two design choices make this work for IoT. First, the IPA can contact the eIM to collect pending operations, so devices that only connect occasionally don’t depend on the network pushing messages to them. Second, the eIM interface supports lightweight transport such as CoAP over DTLS alongside HTTPS, which suits constrained devices on NB-IoT and LTE-M. SGP.32 also includes a fallback mechanism, so a device whose newly enabled profile can’t connect can return to a designated profile instead of going dark.
Where orchestration platforms fit
An eIM manages eUICCs. In a real deployment, though, a fleet may use 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, under various names: eSIM orchestrator or eSO, connectivity management platform, or simply the provider’s portal.
These platforms typically offer a single view across providers and eIMs, policy rules (for example, move devices in a country to a local profile once a contract is signed), bulk operations, billing and usage analytics, and APIs into the customer’s own systems. They can be genuinely useful at scale.
The key point: the “eSO” is not a GSMA role and isn’t part of SGP.32. If a supplier presents it as part of the standard, treat its features as proprietary, because they are.
What orchestration can and can’t do
An orchestration layer can automate decisions and make a large fleet manageable. It can’t change what the device underneath is capable of. No platform can upgrade an SGP.22 eUICC to SGP.32, add profile memory, give a module radio bands it doesn’t have, or reach a device that has lost all coverage. Profile switches also take minutes rather than milliseconds, so policies built on switching are suited to planned changes of provider, not to moment-by-moment network selection. That job belongs to roaming and multi-network services.
The device-level limits are covered in detail in our guide to future-proof IoT eSIM.
The lock-in question moves up the stack
SGP.32’s main promise is that the device owner, not the operator, decides which profile a device uses. That breaks the operator lock-in that was common under SGP.02. But control has to live somewhere, and it now lives in the eIM and whatever platform sits above it.
If that eIM or platform is proprietary, closed, or tied to one connectivity provider, the lock-in hasn’t gone away. It has moved. Before committing a fleet, it is worth asking:
- Can the eUICC be moved to a different eIM, and what does that process 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 to the fleet if the platform is sold, changes strategy or shuts down?
Answers to those questions belong in the contract, not just the sales conversation.
What to do now
- Specify SGP.32 eUICCs for new IoT designs, and confirm which spec version they are certified to.
- Decide whether the IPA will sit in the device (IPAd) or on the eUICC (IPAe). IPAe needs less from device firmware; IPAd needs a firmware team prepared to maintain it.
- Confirm the module supports the SIM toolkit and BIP functions profile management relies on.
- Choose an eIM on openness and portability, not only on features.
- Treat any orchestration platform as an optional, replaceable layer, and keep your policies documented outside it.
- Test fallback and bulk switching on a pilot group before any fleet-wide change.
Frequently asked questions
Is an eSO part of the SGP.32 standard?
No. SGP.32 defines the eUICC, IPA and eIM and how they work with the SM-DP+. “eSO” and similar terms describe vendor platforms built on top of the standard.
What is the difference between an eIM and an orchestration platform?
The eIM is the standardised role that manages profiles on the eUICC for the device owner. An orchestration platform is a commercial product that may include an eIM, connect to several eIMs, and add policy, billing and analytics features on top.
Does SGP.32 end operator lock-in?
It removes the dependence on the incumbent operator that was common under SGP.02. Lock-in can reappear at the eIM or platform level unless portability is agreed in advance.
Do I need an orchestration platform to use SGP.32?
No. You need an eIM, which may be offered by your connectivity provider, a specialist vendor or run yourself. An orchestration platform becomes useful mainly with several providers, large fleets or complex policies.
Related reading
First published October 2025. Rewritten October 2026 to separate what SGP.32 defines from vendor orchestration platforms, and to reflect commercial SGP.32 deployment.