Onomondo Launches an Independent SGP.32 eIM — but Does It Really End IoT Connectivity Lock-In?

Onomondo has launched its own SGP.32 eSIM IoT Remote Manager, or eIM, with a deliberately provocative promise: an IoT business should be able to use the management platform without being forced to buy Onomondo connectivity.

Announced on 16 September 2026, the new eIM completes Onomondo’s own end-to-end SGP.32 offer. The Danish IoT connectivity company can now supply the eUICC, downloadable operator profiles, cellular connectivity and the remote management layer used to install, enable, disable and delete those profiles.

The more interesting part, however, is that Onomondo says the eIM can also be bought and operated independently. A customer should be able to use the Onomondo eIM while obtaining connectivity profiles from other providers and SM-DP+ platforms.

That matters because SGP.32 was created to make IoT connectivity more flexible, but technical compatibility alone does not guarantee commercial freedom. If the first eIM controlling a device estate cannot be replaced, or cannot be used to add another eIM, the customer may discover that the old SIM lock-in has simply moved from the plastic card to the management platform.

Onomondo is aiming directly at that problem.

What has Onomondo actually launched?

Onomondo’s eSIM IoT Remote Manager is the fleet-level control system for SGP.32 eSIMs. It gives an enterprise a web and API-based method of issuing profile management instructions to compatible eUICCs deployed in connected products.

According to Onomondo, the platform supports the principal remote profile operations expected from an eIM:

• downloading a new operator profile;
• listing the profiles held on an eUICC;
• enabling a selected profile;
• disabling an existing profile;
• deleting a profile to release storage;
• managing operations in bulk across a distributed fleet; and
• integrating profile-management workflows into an enterprise’s own systems through an API.

The company says the eIM can communicate with any compatible SM-DP+ and is not limited to profiles supplied by Onomondo. In practical terms, that could allow a manufacturer to deploy one hardware product and later add a local operator profile, a specialist roaming profile or an alternative global IoT provider without recovering the device or replacing its SIM.

Onomondo also describes the eIM as configurable and portable. This is crucial. The customer is not merely being offered a choice of operator profiles within Onomondo’s environment; the proposition is that the remote-management relationship itself should not become an irreversible dependency.

There is an important qualification: these are Onomondo’s product and interoperability claims at launch. Buyers should still validate them against their chosen eUICC, IoT Profile Assistant, SM-DP+, bootstrap profile, device firmware and commercial contracts before committing a production fleet.

“Works with SGP.32” is the start of due diligence, not the end of it.

A quick explanation: what is an eIM?

The eIM is the eSIM IoT Remote Manager introduced by the GSMA’s SGP.31 and SGP.32 architecture for IoT.

It is easiest to think of it as the remote control for a fleet of IoT eSIMs, although that description hides some important plumbing.

An SGP.32 deployment normally involves four key elements:

The eIM does not itself provide radio coverage. It does not magically turn one operator into another, and it is not the mobile network core carrying the application data. Its job is to orchestrate the profile lifecycle.

A simplified sequence looks like this:

1. The device starts with working bootstrap or operational connectivity.
2. The enterprise creates a profile-management instruction in the eIM.
3. The eIM communicates the authorised operation to the device’s IPA.
4. For a new profile, the eUICC securely obtains it from the appropriate SM-DP+.
5. The eUICC installs the profile and, when instructed, enables it.
6. The device registers using the newly active operator profile.

This architecture is designed for devices that may have no screen, keyboard, camera or human operator. A smart meter cannot conveniently scan a QR code. A tracker attached to a shipping container should not need an engineer to open it and exchange a SIM. An environmental sensor expected to remain in service for a decade needs a way to change connectivity after deployment.

That is the job SGP.32 was designed to perform.

Why the eIM can become the new lock-in point

The eSIM industry often uses interoperability and choice as though they mean the same thing. They do not.

Interoperability is a technical property. It means components implement recognised interfaces and can, under the right conditions, work together.

Choice is an operational and commercial property. It means the customer can actually select, add, change or remove suppliers without an unreasonable technical obstacle, punitive contract or hidden dependency.

An SGP.32 eUICC may technically support multiple operator profiles and eIM configurations. That does not automatically mean the service wrapped around it will let the enterprise exercise those options.

Onomondo highlights an awkward detail within the SGP.32 model. The eUICC must support operations for managing eIM configurations, but an eIM is not necessarily required to expose every corresponding operation to the customer. If the initial eIM does not allow another eIM to be added or its own configuration to be changed, the fleet owner can remain dependent on that first management provider.

The SIM is programmable. The profiles may be portable. Yet the keys to the programming layer remain in somebody else’s pocket.

That is not theoretical nit-picking. IoT products frequently remain in service for five, ten or even fifteen years. During that time:

• data tariffs change;
• roaming agreements are renegotiated;
• local permanent-roaming restrictions emerge;
• a provider may withdraw from a market;
• corporate ownership changes;
• security requirements tighten;
• a customer enters a country where a local profile is preferable or legally required; and
• the original connectivity supplier may simply stop being competitive.

If changing the eIM requires a physical visit to every device, the business has lost much of the economic value SGP.32 was supposed to create.

Onomondo’s answer: separate the manager from the connectivity

Onomondo says customers can use its eIM in three broad ways.

The first is as part of the complete Onomondo SGP.32 environment: Onomondo eUICC, Onomondo connectivity profiles and Onomondo eIM. This is the simplest procurement route because one supplier is responsible for the working chain.

The second is to use the Onomondo eIM while bringing connectivity profiles from other operators or IoT connectivity providers. This is the most strategically interesting option. It treats the eIM as enterprise infrastructure rather than an accessory attached to a particular airtime agreement.

The third is a modular approach in which an enterprise selects different components for different roles and integrates the Onomondo eIM through its API. This could suit device manufacturers, larger fleet operators and connectivity specialists that want to build profile decisions into an existing operations platform.

The API-first element deserves attention. At scale, nobody wants an employee manually clicking through thousands of SIM records. Profile changes may need to be triggered by country, device status, contract date, network performance, data cost or a customer-specific policy. An API makes those workflows possible, although the enterprise still needs governance to stop a clever automation becoming a very efficient way of disconnecting an entire fleet.

What “independent” should mean in practice

The word independent is doing a great deal of work in this announcement. A serious buyer should break it into testable requirements.

An independent eIM should allow an enterprise to obtain a compatible profile from a third-party provider, download it from that provider’s SM-DP+, manage its state and verify the outcome without requiring Onomondo to be the connectivity provider.

It should also support the management of eIM configuration, including the ability to introduce or replace management relationships where the deployment design permits it. Onomondo specifically presents configurability as the defence against eIM lock-in.

But genuine independence also has commercial dimensions that no protocol can settle:

• Who owns the eUICC and its identifiers?
• Who controls the initial eIM configuration?
• Can the customer export the EID inventory and complete audit history?
• Are the addEim, updateEim, deleteEim and listEim capabilities available to the customer, and under what permissions?
• Can profiles from another provider be added without a professional-services project?
• What happens to management access when the connectivity contract ends?
• Is there a documented exit process, and has it been tested on a live device?
• Are API access, bulk operations and audit logs included or separately charged?
• What happens if a profile change fails halfway through?
• Is there a safe rollback path and working fallback connectivity?

These questions are not an argument against Onomondo’s platform. They are how a buyer confirms that the promise has survived contact with the contract.

Why this launch is significant

The launch matters for more than Onomondo’s own customers because it nudges the SGP.32 market towards separation of concerns.

In the traditional IoT connectivity sale, several layers are commonly bundled together: the physical SIM, operator identity, roaming footprint, core network, management portal, private networking and support contract. Bundling can be useful. It gives the customer one supplier to call and reduces integration work.

The downside is that the bundle may be difficult to unpick. A customer wanting a better tariff or a local profile can discover that changing one layer means replacing all of them.

SGP.32 creates the technical possibility of separating the permanent hardware from the replaceable connectivity profile. An independently available eIM takes the idea one step further by separating profile orchestration from the connectivity supplier.

If it works cleanly across vendors, the enterprise gains a more credible negotiating position. It can choose a connectivity provider because that provider currently offers the best coverage, commercial terms, network controls or regulatory fit — not because switching away would require engineers with ladders, screwdrivers and several thousand replacement SIMs.

That is particularly relevant to international products. A device manufacturer could install a common SGP.32-capable eUICC during production, use a bootstrap profile for first connection and download the appropriate operational profile after the destination or customer is known. The same hardware SKU could therefore serve multiple countries while connectivity decisions remain flexible later in the device’s life.

What the announcement does not mean

It would be easy to read “no vendor lock-in” and assume that IoT connectivity has finally become as interchangeable as changing an electricity tariff. It has not.

It does not make every existing eSIM compatible

SGP.32 is not a software label that can be applied retrospectively to every eUICC estate. Existing SGP.02, proprietary or consumer-style deployments do not automatically become SGP.32 fleets. Hardware, IPA support, certificates, firmware and the complete provisioning chain all matter.

It does not remove the need for initial connectivity

The device still needs a working route to receive provisioning instructions and download a new profile. That usually means a bootstrap or already enabled operational profile. If the device has no usable network coverage, remote provisioning cannot manufacture a radio link out of thin air.

It does not guarantee that every profile can be bought

An eIM may technically interoperate with an SM-DP+, but the enterprise still needs a commercial agreement with a provider willing and able to issue suitable profiles. Local regulation, minimum volumes, identity requirements, certification policy and operator onboarding processes remain real.

It does not eliminate switching risk

Changing the active operator profile can affect the APN, IP addressing, private network route, firewall rules, VPN path, DNS behaviour, SMS capability and access to the application cloud. The profile may switch correctly while the device application remains unreachable.

It does not prove multi-vendor operation at production scale

Standards reduce integration uncertainty; they do not abolish it. A prudent deployment should test the chosen eUICC, IPA implementation, device firmware, eIM, SM-DP+, bootstrap profile and target operator profiles as one system. Testing should include interrupted downloads, lost coverage, low battery, roaming restrictions, rollback and device recovery.

The industry has spent years discovering that a standards-compliant component can still have an unexpectedly creative relationship with another standards-compliant component. SGP.32 will not repeal that tradition overnight.

The eIM is only one part of provider independence

There is a second trap worth avoiding: profile choice does not necessarily equal complete service portability.

A connectivity provider may also supply private APNs, fixed private IP addresses, VPNs, cloud connectors, traffic filtering, analytics, security policies and application integrations. Changing the SIM profile may move the device to a different mobile core, but the application architecture may still depend heavily on services operated by the previous provider.

For some deployments that is perfectly reasonable. A well-integrated managed service can be more valuable than theoretical portability. The mistake is believing the estate is supplier-independent when several operational dependencies have not been documented.

Enterprises evaluating the Onomondo eIM — or any competing SGP.32 platform — should map the full dependency chain:

The product announcement addresses the eIM row convincingly on paper. The buyer must still prove the rest.

Who is likely to care most?

An independent eIM is unlikely to be essential for a small, short-lived deployment where replacing the complete service would be cheap. Its value grows with fleet size, geographic spread, device lifetime and physical inaccessibility.

The strongest use cases include:

• smart meters expected to remain installed for a decade or more;
• vehicle and trailer telematics operating across changing markets;
• asset trackers moving between countries and networks;
• EV chargers and payment terminals where site visits are costly;
• industrial machinery exported through distributors;
• healthcare or safety devices with demanding lifecycle controls; and
• manufacturers seeking one connectivity-ready product SKU for several regions.

For these deployments, connectivity is not a one-off purchasing decision. It is part of the product lifecycle. The ability to change profile provider later can function as insurance against commercial, regulatory and operational change.

Questions eUICC.co.uk would ask before buying

Onomondo’s announcement is directionally strong. It openly recognises that an eIM can become the new control point and says its platform is designed not to trap the customer there. That is exactly the conversation the SGP.32 market needs.

Before a large deployment, however, we would ask for practical answers and a witnessed proof of operation:

1. Which SGP.32 and related specification versions are supported at launch?
2. Which eUICCs and IPAe or IPAd implementations have been tested?
3. Can a customer independently execute all relevant eIM configuration operations?
4. Can the platform demonstrate a third-party profile download from a separately contracted SM-DP+?
5. Can a second eIM be added and the original eIM later removed?
6. What bootstrap profile is used, and what happens if it has no coverage?
7. How are failed, interrupted or partially completed operations recovered?
8. What role-based access, approval, audit and API security controls are provided?
9. What data and configuration can the customer export?
10. What is the documented technical and commercial exit procedure?
11. Which capabilities require Onomondo connectivity and which remain available without it?
12. How are pricing, minimum fleet sizes and third-party profile operations structured?

The fifth question is the one that separates a good presentation from a meaningful portability demonstration. Do not settle for a slide showing that migration is possible. Ask to see a device move through the process.

Our verdict

Onomondo’s eSIM IoT Remote Manager is a significant SGP.32 launch because it focuses on the control layer, not merely the availability of another downloadable profile.

The company’s argument is sound: SGP.32 will not deliver genuine provider choice if the first eIM becomes a permanent gatekeeper. Making the eIM configurable, API-driven and available separately from Onomondo connectivity is a credible response.

It also fits Onomondo’s broader positioning. The company has long sold flexibility and what it calls the “freedom to leave”. The independent eIM turns that idea into a more concrete architectural claim: customers should be able to retain the management layer while changing connectivity providers, or change the management relationship itself as their requirements develop.

The caveat is that openness must be demonstrated across the whole chain. An open eIM cannot compensate for an unsuitable eUICC, a closed device implementation, unavailable third-party profiles, a weak bootstrap design or an application tied to one provider’s private network.

For IoT buyers, the real lesson is bigger than this single launch. SGP.32 procurement should no longer stop at asking whether a product supports remote profile switching. The sharper question is: who controls the mechanism that allows the provider to be changed?

Onomondo has given a clear answer for its new platform. Now the market needs the live deployments, interoperability evidence and contractual detail to show that the answer holds up over the ten-year life of an IoT estate.

Sources

• Onomondo — “Onomondo launches its own SGP.32 eSIM IoT Remote Manager to prevent vendor lock-in undermining cellular IoT”, 16 September 2026
• Onomondo — eSIM IoT Remote Manager product information
• Onomondo — “What is GSMA SGP.32? Diving into the eSIM IoT standard”
• GSMA — SGP.31 eSIM IoT Architecture and Requirements Specification
• GSMA — SGP.32 eSIM IoT Technical Specification