Blog

What Is IoT Vendor Lock In for Connectivity Buyers

Written by IXT | 11. aug. 2026, 09:53:30

Lock-in is not a clause you negotiate out. It is an architecture you inherit. Here is where it hides and what to ask before you sign.

You avoid vendor lock-in inIoT connectivity by separating four things that providers prefer to sell as one: the SIM hardware, the subscriber identity on it, the management platform you operate it from, and the commercial term. Lock-in happens when changing any one of those forces you to change the other three. The practical test before you sign is whether you are able to move identities to another operator, export your operational data through an API, and replace the platform without touching a single device in the field.

 

 

Where lock-in actually comes from

Buyers look for it in the contract. It lives in the architecture.

 

The SIM is the first lock. A SIM welded to one operator profile means the only way to change operator is to change the SIM. For a fleet of wall-mounted meters or roadside cabinets, that is a truck roll per device. The cost of switching is not a fee, it is a field engineering project.

 

The identity is the second. Even with an eUICC-capable SIM, someone controls the subscription manager that decides which profiles get loaded. If your provider holds those keys and will not hand over the profile, the hardware flexibility you paid for does nothing.

 

The platform is the third. Years of SIM groupings, IMEI locks, usage baselines, alert thresholds and audit history accumulate inside a portal. If the only route out is a CSV export, you rebuild that operational knowledge from scratch with the next provider.

 

The commercial term is the fourth and the most visible. Volume commitments, minimum spend, and a data pool sized to a three-year forecast all raise the cost of leaving. That is normal in wholesale telecoms. It turns into lock-in when it sits on top of the other three.

 

 

What the open standards give you, and what they do not

GSMA SGP.32 defines remote SIM provisioning for IoT devices with no user interface. It matters because profile management moves into a defined interface rather than a private one. A device built to it accepts a profile from a different operator without a site visit.

 

Read the limits into your evaluation. A standard describes an interface. It does not oblige a provider to give you access to that interface, and it says nothing about who holds the subscription manager. Ask both questions directly and get the answer in writing.

 

Multi-network design does similar work at the radio layer. A SIM that reaches several networks in each country removes the single-operator dependency an outage exposes. It also removes the argument that you have to stay because nobody else covers the sites where your devices sit.

 

 

Five questions that separate providers

Who holds the subscription manager for the eUICC profiles on my SIMs, and what is the written process for moving a profile to another operator?

 

Which APIs give me SIM status, usage and session data, and are they the same APIs your own portal runs on?

 

If I terminate, what do I get back, in what format, and how long do you keep serving devices while I migrate?

 

How many networks does the SIM reach in each of my deployment countries, and what happens when the primary one is unavailable?

 

Which parts of the stack do you own and operate, and which do you buy from a partner?

 

The last question tells you more than the other four. A provider running its own mobile core answers it in one sentence. A provider built on someone else's platform has a dependency it inherits and passes to you.

 

 

What good looks like in practice

Your devices reach several networks per country. Your identities are portable and you hold a written path to move them. Your operational data leaves through an API your systems already read, not through a support ticket. Your contract length reflects the discount you wanted, not the difficulty of leaving.

 

None of that removes switching cost. It keeps switching cost proportionate to the decision instead of to the installed base.

 

 

Where IXT fits

IXT owns and operates its own mobile core, built for IoT from the ground up rather than virtualised on shared infrastructure. Routing, policy and identity sit with IXT, which is why the answer to who controls the network is one company rather than a chain of them.

 

The IXT CMP exposes SIM status, usage and diagnostics through the same API IXT uses, so your systems read live data rather than a nightly file. IXT SIMs ship as physical SIM, eSIM or iSIM, and reach 600+ mobile networks across 190+ countries.