Onomondo has launched its own eSlM IoT Remote Manager, or eIM, adding the missing control layer to its SGP.32 stack and making a fairly pointed argument in the process: adopting an open eSIM standard does not automatically mean an enterprise has escaped vendor lock-in. That is the more interesting part of this announcement.

The Danish IoT connectivity company now offers an end-to-end SGP.32 setup covering eUICC SIMs, downloadable eSIM profiles, cellular connectivity and the eIM used to manage those profiles remotely. But Onomondo is also offering the eIM independently of its own connectivity, allowing enterprises to use it with profiles and connectivity from other providers.

In other words, Onomondo does not just want customers to be able to switch operator profiles. It wants them to be able to change the party controlling that switching layer too.

The new control point

For anyone outside the eSIM plumbing business, the eIM sounds like another acronym the industry invented because it had not quite reached its quota.

It is more important than that.

Under the GSMA’s SGP.32 architecture, the eSIM IoT Remote Manager helps manage profiles on deployed IoT eUICCs. Profiles can be downloaded, enabled, disabled or deleted remotely rather than requiring someone to physically retrieve a device and replace its SIM.

READ MORE: SGP.32 Explained: IoT eSIM Fleet Operations in 2026

That matters enormously once “device” means a meter in a basement, a payment terminal in another country, an industrial sensor inside machinery or a connected vehicle expected to remain operational for a decade.

The GSMA designed SGP.32 specifically for IoT devices, including network- and user-interface-constrained hardware, and the specification has continued to evolve. Version 1.3 was published in May 2026.

“SGP.32 is the industry’s opportunity to finally put IoT companies in control of their cellular connectivity,” says Henrik Aagaard, CTO at Onomondo. “But that promise only works if customers have a practical ability to change providers, not simply a theoretical ability defined by a technical standard. An eIM shouldn’t become the new lock-in point. We have built ours so customers can use it with Onomondo connectivity or without us. That’s SGP.32 implemented the way we believe the standard is intended. If their requirements change five or ten years from now, they should still be able to make the connectivity decision that’s right for their business”.

That is the tension behind the launch.

SGP.32 can move the lock-in

Legacy IoT connectivity created a familiar problem: choose a SIM and operator architecture when the product is manufactured, then live with that decision long after the commercial, regulatory or technical assumptions behind it have changed.

Remote SIM provisioning was supposed to loosen that relationship.

SGP.32 does this much better for IoT than earlier models because it was designed around large fleets and constrained devices. But standards define interfaces and procedures. They do not automatically make every commercial implementation equally portable.

If an enterprise can remotely switch profiles but remains dependent on one management environment to do it, the lock-in has not disappeared. It has moved upstairs.

Onomondo says its eIM is configurable and can work independently of Onomondo connectivity. Its product documentation also says the platform can work with any SM-DP+ and profiles from other operators, with profile operations exposed through APIs. Those are Onomondo’s interoperability claims; the more important proof will come from real multi-provider deployments.

READ MORE: STMicroelectronics and COMPRION Tackle SGP.32 Interoperability

For large deployments, that distinction is not academic. A fleet of 500,000 connected devices may outlive pricing agreements, roaming arrangements, network technologies and even suppliers themselves.

The real test of an SGP.32 architecture is therefore not simply whether a second profile can be downloaded today. It is whether the enterprise still retains meaningful control over its connectivity choices five or ten years later.

A market moving toward orchestration

Onomondo is not alone in building around SGP.32, and that context matters.

Kigen already offers an eIM aligned with SGP.32, including APIs, multiple deployment models and compatibility with SM-DP+ services. 1GLOBAL has its own eIM proposition, while IDEMIA has commercialised a GSMA-certified end-to-end SGP.32 ecosystem. FLOLIVE, meanwhile, delivers SGP.32 with Kigen’s eIM and eSIM technology, combining it with its own global connectivity stack.

Eseye takes the story another step toward orchestration, positioning SGP.32 alongside multi-IMSI, lifecycle management and support for multiple remote-SIM-provisioning generations. Thales has made a similar broader point: SGP.32 provides the provisioning foundation, but enterprises still need orchestration, automation and unified operational visibility to control large estates effectively.

That is where this market is heading.

The competitive question is shifting from “Do you support SGP.32?” to “What exactly can the customer control once SGP.32 is deployed?”

Those are very different questions.

A provider can support the standard and still bundle the eUICC, bootstrap connectivity, eIM, orchestration layer and commercial relationships so tightly that moving one component becomes painful.

READ MORE: eSIM Orchestration: Open, Closed or Somewhere Between?

Conversely, maximum modularity can create its own headache: more integrations, more suppliers and more responsibility for an enterprise that may simply want someone else to run the whole thing.

That is why Onomondo’s approach will not suit every IoT buyer. A company with a relatively small domestic fleet, stable connectivity requirements and no desire to manage multiple profiles may gain little from designing for provider interchangeability. A fully managed single-provider platform may be simpler.

But for OEMs and enterprises shipping the same hardware into many countries, navigating permanent-roaming restrictions or operating devices with ten-year lifecycles, the ability to separate the management layer from the connectivity contract becomes much more valuable.

What Onomondo still has to prove

The architecture is compelling. The next questions are operational.

Enterprises will want evidence of interoperability across a broad range of third-party profiles, SM-DP+ environments, eUICCs and device configurations — not just standards compliance on paper.

Migration procedures between eIM environments will matter too, particularly if Onomondo’s existing “freedom to leave” philosophy is supposed to extend beyond marketing language.

Scale, automation, auditability, access controls and policy tooling will also become differentiators as fleets grow. An API for switching profiles is useful; governing when hundreds of thousands of devices should switch, why they switched and what happens when something fails is the harder enterprise problem.

READ MORE: BICS launches eSIM Hub to simplify global enterprise IoT deployments

There is another issue hiding here as well. More choice does not necessarily mean less complexity.

Eseye, FLOLIVE and other managed-connectivity players are effectively betting that enterprises will value abstraction: let the platform deal with operators, profiles, regulations and connectivity policy. Onomondo’s proposition pushes more visibly toward modular control.

Neither model automatically wins. Different enterprises will want different amounts of ownership.

And that is precisely why SGP.32 is increasingly becoming an orchestration story rather than merely an eSIM story.

Conclusion

Onomondo’s launch is less important because the market needed another SGP.32 eIM. It already has several.

What it does usefully is expose the next argument the IoT connectivity industry will have to settle: whether interoperability at the standards layer produces genuine buyer control at the commercial and operational layers.

Kigen is pushing an ecosystem model. IDEMIA is emphasizing certified end-to-end infrastructure. FLOLIVE combines SGP.32 with a managed global network. Eseye is leaning into orchestration across provisioning generations. Onomondo is making portability itself part of the proposition.

That competition is healthy because SGP.32 should not become a checkbox.

The interesting metric will eventually be much more practical: how difficult is it for an enterprise to replace one connectivity provider, profile source or management component without touching the devices already in the field?

That is where claims about openness become measurable.

The companies that get SGP.32 right will therefore not necessarily be those with the longest list of supported profiles or the neatest “single pane of glass.” They will be the ones that can prove changing connectivity after deployment is routine, safe and economically realistic.

If that happens, SGP.32 will do more than make IoT SIMs remotely programmable.

It will change who holds leverage over the connectivity decision for the lifetime of the device.

And that is a much bigger shift.