After a Decade of Lock-In, the IoT SIM Is Finally Free

The Day the Carrier Raises the Price

Imagine you have 50,000 water meters in the field across five countries. Each one carries an SGP.02 eUICC loaded at the factory with an Operator A profile. Three years later your contract with A becomes untenable — they raise the price, retire a band you need, or shut down the M2M service altogether. You want to move the entire fleet to Operator B.

With SGP.02 this migration is an operational nightmare. The eUICC depends on an SM-SR (Subscription Manager — Secure Routing) that is almost always owned by Operator A or its partner. Moving the devices to a new SM-SR — the infamous change-of-ownership — requires active cooperation between the two SM-SRs. In practice, that cooperation rarely happens: the outgoing SM-SR has no incentive to release the fleet, contracts do not force it, and the operation stalls into a bilateral negotiation that drags on for months.

The problem is not theoretical. The IoT industry has spent a decade shipping devices designed for 7-15 years of life with a connectivity choice that is, in practice, irreversible. That is what SGP.32 breaks.

What we had before and why it was not enough

SGP.02 — the M2M standard of the last decade

Published by GSMA in 2014, SGP.02 was the first serious answer to the eSIM problem for machines. It defines two server platforms — SM-DP prepares encrypted profiles and SM-SR delivers and remotely manages them over OTA — and the SM-SR pushes commands over the active profile's channel.

This has two structural problems. First, the SM-SR lock-in already mentioned: the SM-SR usually belongs to the carrier, and switching SM-SR is a slow contractual negotiation when it is possible at all. Second, more subtly: if the active profile loses coverage, the SM-SR cannot reach the device, and since the only channel for pushing a new profile is OTA over the broken one, you have to physically retrieve the equipment. On a fleet of buried meters, that destroys the business model.

SGP.22 — the consumer standard that assumes a person

SGP.22 (2016, current and very mature) is the model behind the eSIM in your phone. It replaces SM-DP + SM-SR with a single SM-DP+ and adds a local component on the device — the LPA (Local Profile Assistant) — that downloads and manages profiles from a UI. The model is pull: the device fetches the profile when someone scans a QR code or enters an activation code.

SGP.22 works perfectly for phones. It does not work for meters. It assumes there is a screen displaying the QR, a finger confirming the download, and a user who knows which carrier they want. A pressure sensor in a pipeline has none of those three. Forcing SGP.22 into IoT meant orchestrating the LPA with proprietary scripts — workable, but it broke interoperability and was never standardized.

The three pains SGP.32 fixes

1. Real carrier portability

In SGP.32, the SM-SR disappears as the single point of control. The device owner picks the remote management platform regardless of who manufactured the chip and which carrier was loaded at the factory. No consent is needed from the outgoing carrier: if you have cryptographic access to the eUICC, you can point it at your own manager.

The commercial consequence is direct: for the first time in a decade, an IoT eUICC behaves like any other BOM component — something you can swap suppliers on without throwing away the device. Until SGP.32, the M2M eUICC was, de facto, a supplier-for-life decision.

2. Recovery without depending on the current carrier

Because the management channel is no longer OTA over the active profile but an IP connection initiated by the device, the local agent can use any available IP network — Wi-Fi, another cellular carrier, a mesh network — to download a new profile. The device stops being trapped on the wrong side of a band shutdown or a regulatory change.

This changes the guarantees you can offer in an RFP. The phrase "the device survives a carrier-A outage if the site has carrier-B coverage" becomes verifiable, not aspirational.

3. Bulk operations that actually scale

In SGP.02, changing the carrier on 10,000 devices required 10,000 OTA commands routed through the outgoing carrier's SM-SR, on negotiated windows, with success rates around 70% and a couple of months of project time. In SGP.32, the manager emits a profile-change package and delivers it whenever each device connects, with built-in retries and per-device traceability. The operation stops being a project and becomes a configuration change.

The two new roles: IPA and eIM

To solve all of the above without breaking the role separation GSMA has built over three specifications, SGP.32 introduces two new roles. Part 2 goes into detail; here it is enough to know who is who.

• IPA (IoT Profile Assistant): the equivalent of SGP.22's LPA, but designed for devices without a UI. It lives either inside the device firmware (modem or application), or as an applet inside the eUICC itself. It is the component that receives instructions from the remote manager, downloads the profile from the SM-DP+ and activates it.
• eIM (eSIM IoT remote Manager): the remote platform that commands the IPA. The critical point is that the eIM no longer belongs to the carrier or to the eUICC vendor: it is operated by whoever the device owner picks. It can be the OEM, an integrator, an MVNO, or the end customer. That freedom is what breaks the historical lock-in.
• SM-DP+: the same as in SGP.22. Still the component that prepares and cryptographically signs the profile. Any GSMA-certified SM-DP+ will do.

What this unlocks commercially

The practical consequences go beyond "you can switch carriers now." Three changes actually shift the conversation with an IoT customer:

• One SKU for multiple markets. The same device, with the same eUICC, can carry a generic bootstrap profile and receive the local-carrier profile when it powers on in the destination country. Before SGP.32, that required country-specific hardware or SGP.02 eUICCs with cooperative SM-SR — neither of which scales.
• OEM-controlled fleets, not carrier-controlled.The maker of an agricultural robot can run its own eIM and treat connectivity as a product capability, not a service bought from the carrier. That reshapes the value chain and, in some cases, the P&L.
• Native rollback to the previous profile. If a profile change leaves a device unreachable, the IPA can roll back to the previous profile in a standardized way. Until now this was a mix of local heuristics and prayers. Part 2 covers the technical detail.

Where we are on the adoption curve

The spec has three public milestones: v1.0 published by GSMA in May 2023 (with the v1.0.1 correction in July 2023), v1.1 in April 2024 — the version GSMA currently treats as the stable normative reference — and v1.2 finalized in December 2024. More important for a buying decision: GSMA test specifications and certification programs for eUICC, SM-DP+, and the IPA itself became available through 2025. That certification milestone is the practical "go signal" that unblocks serious enterprise purchasing.

On silicon, Qualcomm is the most visible vendor with IPA-capable modem firmware, and industry materials (Kigen, Trusted Connectivity Alliance) commonly name Telit and Fibocom as integration partners. Support is uneven module by module: ask the vendor for the exact support matrix and minimum firmware version before committing.

On the eUICC side, Kigen has moved fastest — SGP.32 eUICCs in production through 2024 and a v1.2-compliant eIM announced in October 2024. IDEMIA earned its GSMA SGP.32 certification in April 2025. Thales and other major eSIM vendors are at various stages of the certification process. The catalog of independent eIM platforms is growing through 2025-2026, but the market is still young.

Frequently asked questions

What is coming in the next two parts

Part 2 covers the technical architecture. The two physical variants (IPA in the device vs. IPA inside the eUICC) and why you would pick one or the other. The ESipa interface between IPA and eIM, with its CoAP and HTTPS bindings. The eIM packages that carry download and profile-change instructions. Certificate chains and mutual authentication. And the full flows: direct download, indirect download, and rollback.

Part 3 is the deployment guide. What to buy and from whom, how to decide between running your own eIM or outsourcing it, what to include in your RFP, how to manage the fleet in bulk without losing track, and the actual state of interoperability between eUICC and SM-DP+ vendors today.

If you came to SGP.32 in a hurry, the short 5-minute briefing is still the executive summary. This series is for when you have decided you want to actually understand it.