Answer-first summary: The industry sells SGP.32 as the end of operator lock-in. That claim is half true, which is what makes it dangerous. SGP.32 genuinely dissolves the lock that lived in the physical SIM and the operator contract. But lock-in is not destroyed by a standard, it is relocated: to the eIM that now holds your control plane, to the eUICC supplier whose card operating system is fixed for the life of the device, to the bootstrap profile that owns every cold start in your estate, and to the specific certified-but-tested component combination that actually works in the field. This piece names each relocation, explains why several are harder to exit than the operator lock they replace, and sets out what genuine independence actually requires.
The promise, stated plainly
Read almost any vendor page on SGP.32 and you will find some version of the same sentence: true provider independence across a device’s lifetime. It is the headline benefit, and at one layer it is entirely real. Under earlier arrangements, changing operator across a fleet meant changing SIMs, which for a headless estate in the field meant truck rolls, site access and logistics that quietly wrecked the economics of the whole deployment. SGP.32 removes that. Switching the operator profile on thousands of devices becomes a set of instructions from a platform rather than a fleet of vans. That is a genuine and large advance, and it deserves its due before anyone picks at it.
But independence at the operator layer is not the same thing as independence. And the difference is where a decade-long deployment either keeps its freedom or quietly loses it.
The claim that does not survive contact with a real estate
Lock-in in cellular connectivity has never been a single object you can delete. It is a position, and the position is always wherever control and value concentrate. Take it out of the SIM and it does not vanish. It reappears at the next chokepoint, wherever the next point of leverage sits. SGP.32 moves the lock in four directions at once, and three of the four are harder to see than a SIM contract, because they never appear as a line on an invoice.
The uncomfortable observation this site is willing to make, and that no operator or platform vendor will put in a slide deck, is that in several of those directions the new lock is stickier than the one it replaced.
Relocation one: the eIM becomes the control plane
The eIM is not a SIM manager. It is the control plane for your entire connected estate. Your orchestration, your profile-lifecycle policies, your bulk operations and, crucially, your integrations into ERP, provisioning, ticketing and network monitoring all live against its API. Switching an operator profile is now a few calls. Switching eIM is the thing that is quietly hard. Once your business systems are wired to one platform’s interface, moving to another means re-integrating all of it, re-registering eUICCs and re-establishing the SM-DP+ relationships underneath, and the industry has no mandated eIM-portability standard to make that clean.
So the lock did not disappear. It moved one layer up the stack, to a layer whose switching costs are higher than the SIM’s ever were, because a SIM contract was a commercial relationship and an eIM integration is an engineering dependency. We treat this as its own subject in the eIM portability analysis, because it is the single most underpriced risk in the model.
Relocation two: the eUICC supplier is a ten-year decision
The eUICC operating system is fixed at manufacture. You cannot upgrade it, and you cannot migrate it over the air. The card vendor you choose in 2026 is soldered, sometimes literally in MFF2, into the device for its entire working life, which for metering and infrastructure means ten to fifteen years. You have traded a router-vendor or operator dependency, each of which you could once escape with a site visit and a new SIM, for a card-and-eIM dependency you cannot escape without replacing hardware.
That is not automatically a worse deal. A carrier-independent eUICC is a better thing to depend on than a single operator’s roadmap. But it is a longer and more physical lock than the one it replaces, and it is almost never presented that way. The decision that feels like a component-selection detail at procurement is in fact the longest-duration commitment in the whole architecture.
Relocation three: the bootstrap profile owns your cold start
Every SGP.32 device ships with a bootstrap profile: the minimal connectivity that lets it reach the eIM and pull its first operational profile. Whoever provides that bootstrap owns the single moment every device in the estate depends on. First power-on, at every site. Every recovery from a failed switch. Every cold start after an outage. It is simultaneously a control point and a failure mode, and it is the least-scrutinised line in most procurement documents.
If the bootstrap is tied to one provider’s connectivity and one eIM endpoint, you have concentrated your entire estate’s day-one dependency into a single relationship before a single operational profile is ever downloaded. The flexibility you bought applies to the profiles you switch between later. It does not necessarily apply to the profile that gets you connected in the first place. The bootstrap issues deep dive covers why this layer deserves far more attention than it gets.
Relocation four: “certified” is not “interoperable”
The certification badge implies openness. The field says something more careful. Cross-vendor combinations of eUICC, eIM and SM-DP+ still fail in practice even when each component is individually certified against the specification. What actually provisions reliably is the specific triplet that has been tested together. Certification is a floor for each part, not a guarantee that any certified part works with any other.
Which means that in operational reality you are not locked to an open standard. You are locked to the one validated combination of eUICC, eIM and SM-DP+ that has been proven to work at your sites, on your modem and firmware. Until interoperability is routinely demonstrated across vendor pairings rather than asserted by badge, the openness of the standard is partly theoretical, and the practical lock sits on the tested stack. The full architecture guide sets out how the interfaces are supposed to interoperate, and where the seams are in practice.
The pattern: conservation of lock-in
Put the four relocations side by side and a law emerges. In connectivity, lock-in is conserved. It is never destroyed by a new standard, only moved to wherever control and value next concentrate. SGP.32 makes the one lock everyone hated, the operator lock, dramatically easier to exit, and in the same motion creates four new dependencies, three of which are harder to exit than what they replaced.
| Where the lock lives | Under the physical SIM | Under SGP.32 | Easier or harder to exit? |
|---|---|---|---|
| Operator credentials | SIM swap or new contract | Profile switch via eIM | Much easier |
| Control plane | Operator portal | The eIM and its API | Harder |
| Hardware standard | Swappable SIM or router | eUICC OS, fixed at manufacture | Harder |
| Day-one connectivity | Any SIM at install | Bootstrap profile and endpoint | Harder, and less visible |
| The working combination | Any compliant SIM | The tested eUICC / eIM / SM-DP+ triplet | Harder, interop-gated |
Read the right-hand column on its own. SGP.32 takes the lock everyone could see and made it easy to leave. It then created four dependencies, three of which are harder to leave than the one it removed, and made them nearly invisible in the process. This is not an argument against the standard. It is the nature of lock-in. It is conserved, and it migrates. Today it has migrated to the eIM.
Why this matters more than it sounds
The danger in the “end of lock-in” framing is not that it is false. It is that it is true in the one place buyers are looking, and false in the four places they are not. A procurement that celebrates operator independence while signing a single-vendor eIM, a single-source eUICC, a single-provider bootstrap and an untested component stack has not escaped lock-in at all. It has swapped a visible, invoiced, escapable lock for an invisible, architectural, hardware-bound one, and congratulated itself on the trade.
The tell is simple. If your SGP.32 business case quantifies the freedom you gain at the operator layer but says nothing about eIM exit terms, eUICC second-sourcing, bootstrap ownership or tested-combination interoperability, you have not removed your lock-in. You have relocated it to the parts of the stack your business case does not measure.
What genuine independence actually requires
None of this is a reason to avoid SGP.32. It remains the right architecture for headless IoT, and the alternative of managing physical SIMs at scale is worse on every axis. But independence is an architectural and contractual discipline, not a property that arrives with the badge. Five decisions keep the flexibility real:
- Insist on a carrier-independent eIM, and get portability in writing. Data portability for eUICC registrations, a defined exit process, and no proprietary lock on the profile-management API. The eIM is the new control plane, so the exit terms on the eIM are the real measure of your independence.
- Treat the eUICC vendor as a ten-year commitment. Second-source where the form factor allows, and choose a supplier you would be comfortable depending on for the full device lifetime, because you will be.
- Scrutinise the bootstrap. Who owns it, what network it uses, whether it is tied to a single eIM endpoint, and what your recovery path is if that provider fails or changes terms.
- Demand a tested-combination list, not a pile of certificates. Ask exactly which eUICC, eIM and SM-DP+ have been proven together on your router, modem and firmware. Certification of each part is table stakes; the proven triplet is what you actually run.
- Keep a physical-SIM fallback slot where you sensibly can. So the standard’s promise is not your only route home.
These are the same questions we set out for buyers in what to ask your eSIM provider. Get the five right and the flexibility SGP.32 sells you is genuine. Skip them and you have paid for independence and received relocation.
The honest conclusion
SGP.32 is the most important development in IoT connectivity in a decade, and this site exists precisely because it matters. But the market’s favourite sentence about it, that it ends operator lock-in, is the sentence a buyer should trust least. The operators selling eIM platforms, the vendors selling eUICCs, the providers selling bootstrap connectivity: each has an interest in you believing the lock is gone, because each is where it went.
The independent question, the one no operator or platform vendor will put in their deck, is simply this: once the operator lock is gone, who holds the next one? Ask it before you deploy, and you keep your freedom. Leave it unasked, and SGP.32 will have moved your lock-in to somewhere you cannot see it, and cannot easily leave.
Published by SGP32.co.uk as independent editorial analysis. It names commercial roles and products only to describe the market, and reflects the standards and vendor landscape at the time of writing. Verify current terms directly with suppliers before any procurement decision.