SGP.32 is the eSIM specification written for IoT devices rather than smartphones, and its main practical effect is simple: a SIM's network identity can be changed over the air, after deployment, on a device you may never physically touch again. If you run trackers, meters or terminals in the field on ten-year lifecycles, that changes what a connectivity plan has to look like before the device ships. This post explains the standard in plain English and what it means for an estate of devices already in the field.
The problem SGP.32 was written to solve
eSIM stands for embedded SIM: a soldered chip whose network subscription can be rewritten in software instead of swapped physically. The first eSIM specifications were built around consumer devices, where a person holds the device, scans a QR code and accepts prompts on a screen.
IoT devices do not work that way. They sit on remote sites, sometimes behind panels or seals, and are expected to run for ten to fifteen years. There is no screen, no user to tap through, and no realistic plan for someone visiting each unit when the connectivity model needs to change.
Under older specifications, the compromise was a familiar one. Fleets shipped with fixed identities: a SIM locked to one network, or to one roaming arrangement, chosen at the factory and frozen until someone climbed a ladder. When a network changed its commercial terms, or a border crossing made roaming uneconomic, the fix was a site visit. At scale, those site visits are the single largest hidden cost of IoT connectivity.
What the standard actually enables
SGP.32 separates two things that older eSIM approaches bundled together: the SIM profile that holds a device's network identity, and the remote server that decides which profile the device should use. Because that decision is made over the air, three things become possible.
- Remote lifecycle management. A profile can be installed, updated or replaced without physical access to the device, through a management layer rather than an on-device prompt.
- Planned change instead of reactive change. A switch of network identity can be scheduled, tested on a subset of devices, then rolled out, rather than forced by an outage.
- Long-life deployment logic. A connectivity model can be designed to survive fifteen years of commercial and regulatory change, not just today's conditions.
None of this replaces good coverage planning. What it removes is the assumption that the first network choice must be the last one.
Multi-IMSI as a design choice, not a workaround
An IMSI is the number inside a SIM that identifies it to a mobile network. Multi-IMSI means a device can hold and switch between several identities, so the same hardware can present itself as a local subscription on more than one network.
Under older approaches, multi-IMSI was often bolted on later, as a workaround after a roaming arrangement proved fragile or a network became uneconomic. The newer specification makes multi-IMSI a designed-in capability: profiles are expected to be managed remotely, so switching identities becomes a normal, planned operation rather than a patch.
For a fleet operator, the practical difference shows up in three situations.
| Situation | Fixed-identity SIM | Multi-IMSI under SGP.32 |
|---|---|---|
| Network commercial terms change mid-life | Site visit or hardware swap | Profile replaced over the air |
| Permanent roaming rules tighten in a market | Dependence on roaming approval | Local profile provisioned remotely |
| Weak coverage in a deployment region | Stuck on the contracted network | Identity moved to the network with signal |
Roaming still matters, and a well-built roaming arrangement is the right answer for many cross-border fleets. The point is that with a multi-IMSI design, roaming becomes one option among several rather than the single load-bearing dependency.
Disruption is the real cost
The recurring pattern in long-life IoT is that connectivity itself is rarely the expensive part. The expensive part is intervention: the engineer dispatched to a substation, the asset pulled from service, the ticket that sits open for a fortnight while a part ships.
A remote-provisioning approach cuts that class of cost directly. Profiles are managed from a platform, network strategy evolves without touching the device, and lifecycle changes are scheduled rather than reactive. When a fleet numbers in the thousands, the difference between a planned profile change and a truck roll is the difference between an afternoon and a quarter.
What the platform side has to carry
The specification covers the SIM and the provisioning interface. It does not run your estate. Somebody still has to answer the operational questions: which SIM is on which network, which one has dropped off, which tariff it is consuming, and what happens at the billing boundary when a device moves country.
That management layer is where the standard either pays off or gathers dust. The profile change itself is one API call. The value comes from seeing it in context: the same view that shows a meter's last reading should show its SIM's network and signal, so a device that goes quiet is diagnosed once, in one place, rather than argued about across two dashboards.
Under this model, SIMs sit in the same estate as everything else they are fitted to. Each SIM is one asset among thousands, visible beside the cameras, meters and trackers it connects, with its activation state, its tariff and its alert history attached to the device rather than to a spreadsheet nobody trusts.
Common questions
Does SGP.32 mean I no longer need roaming agreements?
No. Roaming remains a core tool, especially for cross-border fleets. The change is that a multi-network identity can be provisioned locally where commercial or regulatory conditions call for it, so a single roaming dependency stops being a single point of failure.
Do my existing devices need replacing to benefit?
Devices already deployed with fixed-identity SIMs cannot be retrofitted with remote provisioning. The standard benefits new hardware and planned refreshes. Existing estates can still gain resilience through multi-network SIMs that move between operators without a profile change.
Who can trigger a profile change?
The connectivity provider operating the management layer triggers it, on your instruction or automatically under agreed rules. The device owner does not need physical access, and the end user of the device is never asked to accept anything.
How Cloud-IQ approaches this
Cloud-IQ is the DigitalSom group's global IoT connectivity business. We keep devices online across 190+ countries and 800+ mobile networks, and we sell, deploy and support RAAD, the DigitalSom IoT platform.
The lesson of remote provisioning is the one we build around: a SIM's job is to stay useful for the life of the device it is fitted to. A Cloud-IQ SIM works across 800+ networks without being steered off the strongest signal, and moves between tariffs freely as your estate changes shape. Tariffs are built around the countries and data your fleet actually uses, with data pooled across the estate. Every SIM sits in RAAD™ alongside the devices it powers, so a drop-off shows up as signal loss or SIM fault, not as silence, and our engineers are on call 24/7 to tell the two apart. If your fleet is outgrowing fixed connectivity, Request a quote and we will shape it around your deployments.