Everyone explains what SGP.32 is. Far fewer explain what you actually have to buy and build to run it, and how that choice shapes who controls your fleet. Here is how operators package and deliver SGP.32, with Vodafone’s published process as the worked example.
SGP.32 is operator-independent by design, but every deployment is still bought from a supplier who packages it. Operators offer two broad models: migrate onto their profile and platform, or take a full managed stack. Vodafone’s published seven-step process is a clear worked example, and the way it is framed reveals as much as it explains.
What delivering SGP.32 actually means
SGP.32 is the GSMA specification for remote SIM provisioning built for IoT. It was written for devices that have no screen, no keypad and often very little power, sitting somewhere nobody wants to visit for a decade. The headline promise is familiar: change a device’s mobile network profile over the air, without sending an engineer to swap a card. The detail that matters for buyers is how that promise is actually assembled and sold.
A working SGP.32 deployment is a chain of parts, not a single product. An eSIM (eUICC) holds one or more operator profiles. An IoT Profile Assistant (IPA), running either on the cellular module or on the eUICC itself, carries out profile operations on the device. An eSIM IoT Remote Manager (eIM) is the server-side orchestrator that decides which device should hold which profile and when to switch. A Subscription Manager Data Preparation server (SM-DP+) stores and delivers the encrypted operator profiles. And underneath it all sits the connectivity itself. For a deeper look at how these layers interact, see our explainer on SGP.32 orchestration and the eIM.
The three things every buyer must have
Strip away the marketing and operators are broadly consistent about the minimum. In Vodafone’s own account of implementation, an organisation needs three core components to run SGP.32, whatever else is optional.
The first is SGP.32-compliant devices. This is the point most often glossed over: legacy hardware generally cannot be upgraded to SGP.32 over the air. The support has to be designed in, in the module and the eUICC, before the device ships. The second is an SM-DP+ platform, which hosts the operator profile templates and performs the encrypted, authenticated download when the eIM requests it. The third is an eIM, the orchestration layer that lets a buyer manage SIM identities, authorise profile downloads and coordinate changes across one or more SM-DP+ platforms.
The important word in that list is the eIM. It is the component that decides who is really in control of a fleet over its life, and it does not have to be the same company that sells the connectivity. More on that below.
Two ways operators package it
Operators tend to present SGP.32 in one of two commercial shapes, and Vodafone is a useful example because it offers both.
The first is a migrate-in model. The customer owns SGP.32-capable devices and, potentially, their own eUICC and eIM bought from a third party, and the operator simply supplies its profile. Activation codes let the device download the operator’s profile over the air, after which it runs on the operator’s managed connectivity platform. The customer keeps ownership of the hardware and the management layer, and the operator competes as one profile among others that the eUICC could hold.
The second is a full managed stack. Here the operator supplies the whole chain: a compliant eUICC, its own eIM, its SM-DP+, the connectivity, and professional services to bring it together. This is the one-stop-shop pitch, and for a team without eSIM expertise it is genuinely the faster route to a working deployment. The trade-off is that more of the chain, and more of the control, sits with a single supplier.
| Component | Migrate-in model | Full managed stack |
|---|---|---|
| Device and eUICC | Customer owned, third-party sourced | Operator supplied |
| eIM (orchestration) | Customer or third party | Operator supplied |
| SM-DP+ (profiles) | Operator, for its own profile | Operator |
| Connectivity | Operator profile, alongside others | Operator |
| Who holds control | The buyer | Mostly the operator |
| Best fit | Teams wanting independence and multi-vendor freedom | Teams wanting speed and a single throat to choke |
The seven-step sequence, in practice
Vodafone sets out implementation as a concrete sequence, and it is a fair map of what any SGP.32 rollout involves regardless of the operator. Reproduced here in plain terms:
- Select a connectivity supplier that supports SGP.32. The operator designs the profiles for the markets you operate in, sends them to the SIM manufacturer and loads them into its SM-DP+ for allocation through the eIM.
- Purchase, license or use a recommended eIM. Make sure it gives you the SIM management you need and can connect securely to the operator’s SM-DP+.
- Select SGP.32-compliant devices. The manufactured SIMs go to the device factory and are pre-loaded with the chosen network profile.
- Configure device access to the eSIM ecosystem. Devices need to reach the eIM and SM-DP+ using an initial connectivity profile, APN and security settings before remote management can work.
- Request activation codes and load them into the eIM. The eIM then instructs devices to download, install and activate the new profile from the target SM-DP+.
- Validate service, then retire the old profile. Confirm network registration and application connectivity, then disable or remove the previous profile for continuity and clean lifecycle management.
- Review compliance and update firmware regularly. Provisioning software and device firmware need to keep pace as the standard and certification programmes evolve.
Step four is where deployments most often stall. A device cannot pull connectivity out of thin air; it needs working bootstrap connectivity to reach the eIM and SM-DP+ in the first place. Plan the initial profile and APN as carefully as the target one.
Roam, localise or transform
One reason SGP.32 gets oversold is that it is presented as a single answer when it is really a choice between three. A device can roam, using a global profile that reaches many networks. It can localise, switching over the air to a profile from a local operator. Or its identity can be transformed from a global to a local SIM, a lifecycle state operators define explicitly for exactly this purpose.
The choice is not academic. In highly regulated markets, permanent roaming can be restricted, so a local profile may be the only compliant option. Vodafone names Brazil, China and Saudi Arabia as examples where localisation, rather than roaming, keeps devices both connected and compliant. Elsewhere, roaming may be simpler and cheaper and localisation may be needless effort. Deciding this per market, up front, is most of the real work. We will unpack the roaming versus localisation trade-off in detail in a separate piece on global IoT eSIM.
What the operator framing reveals
Read the operator material as an independent buyer and three things stand out, two of them to the operators’ credit.
SGP.32 adds to roaming, it does not replace it
Vodafone is explicit that SGP.32 does not replace permanent roaming but adds a capability alongside it. That is accurate, and it is also the natural position of an operator whose IoT business rests heavily on global roaming agreements. The framing is fair; it is worth noticing whose interests it happens to align with.
Operators will tell you when you do not need it
To its credit, Vodafone states plainly that SGP.32 is not right for every deployment. It can add cost, time, resources and operational complexity, and if a buyer’s current connectivity already meets their coverage, commercial and operational needs, that existing setup is likely the simpler and cheaper choice. An operator advising customers that they may not need its newest product is rare, and worth crediting.
The part that gets played down
The architecture’s most consequential property is the one operator marketing understandably underlines least: buying an operator’s connectivity does not mean that operator owns your eUICC, your eIM or your future profile choice. By the standard’s design, an eUICC can be re-associated with a different eIM, and pulling a profile from another operator does not require the current operator to agree to the move. That is the clean break from the older M2M eSIM world, where the provisioning provider was the control point and switching meant hardware changes or bilateral deals. The dedicated SGP.32 reference on eIM portability covers the migration mechanics in full.
Not “whose SIM is this?” but “who controls this estate in five years?” If the honest answer is that your supplier does, because the eUICC, the eIM and the profile choice all sit with them, then SGP.32’s independence is a feature you have paid for but not actually taken.
Who really controls the estate
SGP.32 makes operator-independence technically possible. It does not make it automatic. A buyer who takes a full managed stack from one operator gets speed and simplicity, and there is nothing wrong with that choice made deliberately. A buyer who wants genuine portability has to insist on it: own or independently source the eUICC, choose an eIM that supports migration to another provider, and get the contractual terms for a fleet move in writing before signing, not after.
The hardware side of that decision, which modules and eUICCs actually support SGP.32 today and where the IPA should live, deserves its own treatment. That is the subject of the next piece in this series on SGP.32 hardware. For where the standard and the market stand right now, our mid-2026 state of play is the place to start.
Frequently asked questions
Is SGP.32 available to buy now, or still coming?
It is shipping. Through the first half of 2026, certified hardware, commercial operator services and orchestration platforms all moved from trials to general availability, with the strongest commercial acceleration expected from the second half of 2026.
Do I have to use my connectivity provider’s eIM?
No. The eIM can be operated by the enterprise itself, by an IoT platform partner, or by a connectivity provider. A buyer can bring their own eIM and use an operator only for its profile, which is the essence of the migrate-in model.
Can I move to another operator without the current one’s permission?
By the standard’s design, yes. SGP.32 removes the requirement for the current operator to agree to a migration to another provider. In practice, portability also depends on the eIM you chose and the contractual terms you agreed, so confirm both before you commit.
Does SGP.32 replace roaming?
No. Operators position it as a complement to roaming, not a substitute. The sensible model is to roam where roaming works well and to localise with a local profile where regulation, economics or performance make that the better option.
Can I upgrade my existing devices to SGP.32 over the air?
Generally not. Legacy hardware cannot usually be upgraded to SGP.32 over the air; the support has to be built into the module and eUICC before the device ships. Plan for SGP.32 in new hardware and run existing estates until their natural refresh.
