Reality check: Do you even need eSIM IoT?

eSIM IoT has been on the sidelines of connectivity for a few years now. At Onomondo, we’ve picked up the discussion early, we’ve explored eSIM IoT from specs to ongoing market development for years.

And over these years, we’ve consulted hundreds of IoT executives about eSIM IoT – from slim interest as a potential solution to profound determination. In these consultations, definitive patterns have emerged on the motivations for building with eSIM IoT.

The 7 most frequently cited drivers that send IoT fleet managers in a quest for eSIM IoT are all legitimate, operational costs and blockers, a real lived experience for years. And eSIM IoT has a top place in the narrative as The Solution. But, more interestingly, it’s not the only solution.

So from our conversations with IoT fleet managers, we look at:
a) The main drivers for eSIM IoT
b) How eSIM IoT solves each
c) What other solutions address each driver

At the end, we invite you to inquire: Is eSIM IoT the only, the simplest, or the most cost-effective solution for your pain point?

Let’s take a look.

1. Escaping vendor lock-in

Onomondo has been a fierce advocate of no vendor lock in because over the years, we have seen and heard the unnecessary pain it has caused IoT fleet managers. Cited as the undisputed #1 driver in almost every discussion, the biggest pain point fleet managers are looking to solve is vendor lock-in.

After years of not having other options than time commitments and technology that allowed profile –and provider– changes only in theory, eSIM IoT and its promise of flexibility was in high demand from the get go. Fleet managers could finally conceptualize the freedom to switch operators mid-life.

“If [our connectivity provider] decides to triple the cost, I can just leave. That’s the reason why we would like to move to the eSIM.”

Does eSIM IoT solve vendor lock-in?

In theory, yes – in practice, not always. In an eSIM IoT ecosystem, the lock-in moves from your connectivity vendor to your eSIM IoT Remote Manager vendor. How can this happen? In simple terms, it is not uncommon for the SIM hardware to be connected to one eSIM IoT Remote Manager only. This is possible with IPAe, the profile assistant when embedded in the eUICC (=e). If this eSIM IoT Remote Manager is not configurable, then you are locked in to that eSIM IoT Remote Manager for as long as the devices carry this SIM hardware.

Considering that the eSIM IoT Remote Manager is a simple tool with a simple job to do –add, change, remove profiles– using one eSIM IoT Remote Manager for the lifetime of the devices wouldn’t be a huge issue. There’s always the commercial risk that the eSIM IoT Remote Manager provider will spike the price of the product in the years to come and leave you with little choice but having to pay.

Additionally, not every profile has been tested as available and downloadable with every single eSIM IoT Remote Manager. In an emerging market of a new technology, this is completely normal. However, there’s still no evidence that any profile is available via any eSIM IoT Remote Manager. 

What else solves vendor lock-in?

In theory, no vendor can lock you in when you own the SIM keys and the commercial terms of the contract. When you own the SIM keys, you can simply transfer them to another provider, even if the SIM is UICC; when you have no time commitments on your contract, you are free to switch providers without financial consequences. Lock-in is broken outside the SIM standard entirely, through two levers most buyers underuse: 

1. The key ownership: Whoever holds the SIM’s cryptographic keys controls whether the fleet can ever move. When the customer holds them, the fleet can be re-provisioned onto another network without touching a single device, so leaving becomes a real option rather than a favor granted by the provider.
2. The contract: Most of the lock-in is commercial, not technical (minimum volume commitments, multi-year terms, exit penalties, and usage data you cannot export). Negotiate those out, no minimum term, portable data, a defined exit path, and the switching cost collapses no matter what hardware sits underneath. 

While these two are possible in theory, in practice few connectivity providers make them available. But this has been the philosophy of Onomondo from the beginning: The fleet manager owns everything and they have freedom to leave whenever – no point in tying them to a service that doesn’t fit them. So, at Onomondo we provide the SIM Keys and adapt the contract to make sure it aligns with your company’s real context, needs, and vision.

2. Global deployments

Fleet managers see the flexibility and ease of profile swapping as a gateway for independence and a tool to simplify fleet operations. They frequently mention the difficulty of managing multiple providers in different countries and regions and the complexity that comes with it: Different invoices, different ways to troubleshoot, different terms and conditions to manage.

And this comes from the ones that have attempted multi-operator deployments; other fleet managers mention the exact same complexity of managing different providers as a blocker to launching to new markets. In parallel, they see eSIM IoT as a way to unlock new markets with ease.

“We managed one operator in that country, another operator in another country and it’s very difficult. We think with SGP.32, it will be easier for us.”

Does eSIM IoT solve global deployments?

Yes, eSIM IoT makes global deployments simpler and gives fleet managers more control over their connectivity choices. You can simply choose a local profile depending on where the devices are deployed; logistics and manufacturing becomes significantly simpler.

However, deploying eSIM IoT may add more complexity and potentially costs. Complexity because, fleet managers now have several connectivity providers to manage, each with their own charges, invoices, and workflows. Moreover, fleet managers need to be very proactive to leverage the cost savings from swapping profiles depending on the location. Cost because, in addition to the connectivity/data costs, fleet managers need to also account for the cost of the eSIM IoT Remote Manager.

What else solves global deployments?

In simple words, a single global network. One profile that works everywhere by default: one APN, one invoice, one relationship. There is nothing to provision per market, nothing to swap, and no management layer to run. Expanding into a new country adds no setup, because the SIMs connect there automatically the day they arrive. The whole deployment collapses to a single decision made once, and the operational overhead of running connectivity across dozens of markets never appears.

The only limit is coverage. A market with permanent roaming restrictions still needs a local profile. Everywhere else, reach is a solved problem rather than a project.

3. Roaming restrictions

Certain countries, with the most frequently cited examples of Brazil and Turkey, have permanent roaming restrictions, which prohibits devices and foreign network operators from roaming on their infrastructure. Simply, this means that fleet managers who want to deploy in these markets must use a local connectivity provider for that segment of their fleet.

eSIM IoT removes this prohibition with a simple flick of a switch. Fleet managers can simply swap the profile of the devices deployed in countries with permanent roaming restrictions –either permanently or just passing by– to a local operator via the eSIM IoT Remote Manager.

“We can bring our own operator to the system so we can localize the SIMs. Is it going to Canada? Okay, we choose that profile. This is to Turkey – maybe it’s a [Turkish MNO].”

Does eSIM IoT solve roaming restrictions?

Yes – and this is one of the cleanest cases for eSIM IoT. A permanent roaming restriction is a hard regulatory wall. In the markets it applies, a foreign SIM simply doesn’t work. Traditionally the only fix was fitting a physical local SIM to the slice of your fleet headed for that market – with all the SKU and logistics overhead that implies. eSIM IoT collapses that into a profile switch: you provision a local profile over the air via the eSIM IoT Remote Manager, either permanently for devices that live there or temporarily for devices passing through.

The catch is availability and what “local” actually means. The switch only works if a compliant local profile for that specific market is available and tested on your eSIM IoT Remote Manager/eUICC combination – and whether every profile is downloadable via every eSIM IoT Remote Manager hasn’t been tested enough. Just as important, confirm the profile is a genuine local subscription and not a repackaged roaming arrangement that trips the very restriction you’re trying to clear.

What else solves roaming restrictions?

A truly local subscription. Permanent roaming restrictions create a regulatory barrier that only a genuine local presence can overcome. There are two proven ways to establish that presence:

1. A multi-IMSI SIM: It carries a local IMSI for the restricted market, so the device registers on the local network as a local subscriber rather than a roamer, with nothing to download.
2. Provider-side localization: Your connectivity provider holds the local agreement and terminates traffic in-country, so your single global profile is already compliant there with nothing for you to provision.

The caveat is that both depend on a compliant local subscription actually existing in the specific market you need. So the real question is which markets a provider has localized, and whether each one is a true local plan rather than a repackaged roaming arrangement that trips the very restriction you are trying to clear.

4. Future-proofing

As SGP.32 has enjoyed much of the spotlight since its initial release, eSIM IoT is solidifying as the new standard in the minds of fleet managers. There is no way to know if SGP.32 will be ubiquitous but fleet managers express that they prefer to build for where the industry is going than deploy on legacy tech that may require a redo sooner than later.

However, there’s another perceived advantage in eSIM IoT: fleet managers are acutely aware that drastic changes may take place during the long lifetime of their fleets – even they don’t know yet what these changes will be per se. Some historical examples include 2G and 3G sunsets or more commercially, large spikes in data billing. They see eSIM IoT as added flexibility for the future, and are keen to deploy their next generation with the SGP.32 functionality embedded, even without the intention to use it right away.

“A meter works for 10-15 years. During this lifetime, maybe even three operator agreements will appear – you never know. So, we need the possibility to just switch from one to another”

Does eSIM IoT solve future-proofing?

Yes, for the specific futures it’s built to handle – and the discipline here is to name them, because future-proofing is the driver most easily sold on hand-waving. 

eSIM IoT covers a defined set of lifetime risks: a network sunset , an operator that hikes its price or exits the market, or a new market you didn’t plan for at deployment. All of these resolve to the same action: swap the profile remotely instead of recalling the fleet. The bankable value is that you deploy the capability now and activate it if and when one of these hits, even years down the line. In few words, this driver materializes more than any other the promise of eSIM IoT, to put users in the driver’s seat of connectivity.

But there are two caveats. First, this is optionality you pay for whether or not you ever use it – the eUICC carries a premium over a fixed SIM, and managing profiles means carrying the eSIM IoT Remote Manager.

Second, deploying now is a bet that the ecosystem matures around you: SGP.32 is young, “the standard” is a direction of travel rather than a settled fact. At its current market state, eSIM IoT is a relatively safe bet – albeit still a bet.

As always, watch for the quiet lock-in possibilities: future-proofing the hardware while pairing it with a non-configurable eSIM IoT Remote Manager locks your management layer for the fleet’s lifetime.

What else solves future-proofing?

The best way of future-proofing your infrastructure is having a provider with a clear path to carry your connectivity across your product’s entire lifecycle, no matter how the industry shifts. That path takes two concrete forms: a single network that reaches many operators in every market, and a catalog of products you can move across when a risk shows up.

The most obvious is that a single global network makes future-proofing continuous rather than a one-time bet. Because your one profile already reaches every operator in a country, the lifetime risks that strand a fleet get absorbed as they happen. An operator that raises its price, degrades, or exits the market simply stops being the one the device uses; it attaches to another live network on its own and the problem is solved. There is no activation event to get right under pressure, and no separate layer to maintain for years on the chance you might need it.

Onomondo, for example, provides both: a single global core spanning 180+ countries and more than 680 networks, plus the ability to move your connectivity across a catalog of products when the unexpected happens.

5. Redundancy, insurance, fallback 

Not every reason for eSIM IoT is about commercial freedom – some are simply about staying online no matter what. Fleet managers increasingly treat a second profile as an insurance policy: a secondary operator sitting ready on the device, so that if the primary network degrades, gets congested, or goes down entirely, the device fails over instead of falling silent. For mission-critical fleets –security systems, payment terminals, connected infrastructure– multiple points of failure at the network layer are a requirement, and often a regulated one. 

eSIM IoT lets them provision a primary and a backup profile and switch between them remotely, turning what used to be a truck roll (or a dead device) into a non-event. Additionally, devices with an embedded chip/MFF2 form factor that can run the SGP.32 functionality remove the need for two SIM slots on the board. And even the fleet managers who aren’t ready to switch operators today often want SGP.32 on board purely as a hedge – insurance against being stranded tomorrow.

“We’ll need at least two profiles – the first one primary, the second secondary. It won’t be used often, but it’s important for the cases where you lose connection for some reason.”

Does eSIM IoT solve redundancy?

Yes, for provisioning the backup. One distinction decides whether it actually saves you: eSIM IoT gives you a second profile sitting on the device and a remote switch between them; it does not, by itself, give you instant automatic failover. Those are different things, and mission-critical buyers are the ones most likely to conflate them. 

The remote swap is a pull: the user queues the switch in the eSIM IoT Remote Manager, and the device picks it up on its next polling cycle. That’s excellent for the failures you can see and decide on – congestion, a degrading network, a planned cutover. On the hardware side, an MFF2 chip running SGP.32 carries primary and backup on a single embedded component, so you meet a two-profile redundancy requirement without a second SIM slot on the board.

The caveat is the one buyers skip past: a remote swap needs a live path to the eSIM IoT Remote Manager. If the primary network is the device’s only connectivity and it goes fully dark, the device can’t reach the eSIM IoT Remote Manager to pull the swap command in the first place – the very moment you need failover is the moment the mechanism can’t run. True “primary drops, device is back online on its own in seconds” behavior lives in device- and modem-side fallback logic, not in the remote management layer. 

So treat eSIM IoT as managed redundancy you direct, not as autonomous hot-standby – and if regulated real-time failover is the requirement, confirm where that logic actually sits before you count SGP.32 as the answer.

What else solves redundancy?

Failover built into the SIM and the network. The most reliable redundancy is the kind that needs no instruction and no management layer to be reachable when things go wrong.

A multi-network SIM carries access to every network in a country on one profile, so when the serving network degrades the modem reselects another on its own, with nothing to command and no platform to reach.

Again, the limits are physical. Reselection runs on modem timers rather than instantly, and no SIM helps at a site where only one operator has coverage or where the radio path is fully gone. But for the common failure, one network wobbling while others in the country are up, service is restored with no human in the loop.

6. Simplified logistics and SIM provisioning

For many fleet managers, simplifying manufacturing for global deployments is reason enough on its own – the flexibility benefits are almost a bonus. And for others, while it may not be the primary driver mentioned in every single discussion, it is an evergreen secondary benefit. 

The global deployment-SIM provisioning combo is a notorious logistical headache that not only delays fleet managers from leveraging the value of their fleets, but –let’s be honest– sucks the joy and excitement out of product releases. Fleet managers describe warehouses full of region-specific variants: a different SKU, and often a different SIM, for every market they ship to. All of thid has to be forecasted, stocked, picked, and provisioned correctly. And let’s not forget – if it’s plastic SIM cards, there’s also the step of inserting the plastic chip onto every single device. 

eSIM IoT collapses that complexity into a single global SKU: one device, one embedded SIM, provisioned to whatever operator the destination requires at the moment it leaves the warehouse. The manufacturing line gets simpler, the parts catalog shrinks, and there are no glued-in SIMs to swap or vehicles to recall down the line.

“What we’re trying to do is simplify the SKU in the warehouse. We want fewer articles, easier to deploy – one SIM for the whole group, and we deploy different operators from one place.”

Does eSIM IoT solve complex logistics and SIM provisioning?

Yes, from day one. It’s also two levels of simplification, depending on how much you know at build time.

The first level is a single global SKU: one device, one embedded eUICC, operator decided as it leaves the warehouse. This is a huge improvement compared to the previous provisioning status quo of region-specific variants, often a different SIM, forecasted and provisioned separately for every market. The parts catalog shrinks to one line, physical SIM insertion value chain step disappears, and there’s nothing glued in to swap or recall later.

The second level is the bootstrap profile – an initial profile programmed at manufacturing that activates as soon as the device turns on. The benefit here is that it gives you even more leeway to control profiles: the device comes online out of the box, reaches the eSIM IoT Remote Manager, and pulls its target profile in the field. That lets you ship into inventory without knowing a unit’s final destination and provisioning moves from the factory to activation.

The caveat: complexity relocates to the orchestration layer, and each level adds dependency. The bootstrap adds one link – it only works if there’s coverage where the device first powers on and the pull completes. And the single SKU only holds where profiles are available and tested; where they aren’t, that market falls back to a physical SIM.

What else solves complex logistics and SIM provisioning?

A single global profile, preloaded at the factory. One device, one profile that works in every market the moment it powers on. The parts catalog is a single line, the SIM-insertion step disappears, and there is nothing glued in to swap or recall later. Because the profile is committed at manufacture and works everywhere, provisioning is finished when the device leaves the line: no field step, no orchestration layer, no activation decision waiting to be made. It is zero touch in the most literal sense, the device ships, powers on, and is online.

The second option is a pure software SIM. The reason SIMs come in a physical form is because they need some processing power to run their coded capabilities – but if that processing is taken over by the device module, then no physical SIM is needed – ergo, no logistics nor deliveries. A SoftSIM can be provisioned OTA so the process is equally easy to SGP.32’s remote SIM provisioning.

The limit here is coverage, not logistics. The single SKU holds across your provider’s footprint, and a market with permanent roaming restrictions still needs a local profile.

7. SIM margin savings

There’s a more commercial reason that surfaces, particularly in large fleet deployments: money. At scale, any margins saved add up to significant amounts and the directness of eSIM IoT allows for marginal cost savings.

At the volumes a large fleet ships, those saved cents per SIM add up fast – and the same pass-through logic lets fleet managers bring their own operator commercials rather than paying someone else’s retail rate on top.

“We can get zero price for the profile if we work with [the SIM vendor] and [the connectivity provider] together.”

Does eSIM IoT solve SIM costs?

Yes as a line-item saving. eSIM IoT decouples the SIM hardware from the connectivity, so instead of buying SIMs bundled from an operator with their margin baked in and a reseller or two stacked on top, you buy certified eUICC chips straight from a SIM manufacturer at hardware cost and source connectivity separately. That strips out the reseller markup, the MNO’s margin on the card, and the logistics overhead of sourcing SIMs through a connectivity contract. The same pass-through lets you bring your own operator commercials rather than paying a retail rate on top.

The saving is per-SIM and small – its whole logic is scale. At a few devices it’s noise; across a large fleet, cents per SIM compound into real money. So this is a driver that matters to high-volume deployments and barely registers for small ones.

What else solves SIM costs?

Go after the two costs that dwarf the card. A SIM chip is the smallest line in a connectivity bill, so squeezing its margin saves cents while the real costs sit elsewhere. Two moves capture it.

1. Remove the SIM hardware entirely: A SoftSIM runs the SIM inside the module’s existing processor, so there is no card, no slot, and no separate component to source, certify, or solder. That is not a cheaper SIM, it is no SIM to buy at all, and it drops a step from both the board and the supply chain.
2. Negotiate for operational connectivity savings before the physical SIM costs: Most connectivity waste comes from resellers’ retail margins and costs for inactive SIMs rather than the hardware. Buying from a provider that owns its core network removes the reseller and operator retail markup structurally, and a pay-as-you-go model means idle SIMs, whether warehoused, seasonal, or in transit, cost nothing until they transmit. Across a large fleet that saves far more than shaving cents off each card. And if we are talking scale, the margins applied to operational connectivity compound over time, compared to the one-off savings from the physical component.

Onomondo does both: SoftSIM that runs natively on modules from Nordic Semiconductor, SIMCom, and others with no SIM hardware at all, and Magic Mode pricing so you only pay for a SIM when it is actually online.

Many alternatives, one key takeaway

eSIM IoT shouldn’t be an imposed solution but a deliberate decision. Run your own history and your roadmap through the drivers and possible solution. Look back at the connectivity headaches you’ve actually hit and look forward to the ideal state of your next fleet.

Where would eSIM IoT have made the product better or your life easier? If the honest answer is “here and there, a little,” you’re likely looking at a nice-to-have whose operational cost isn’t so nice to carry. But if a specific pain keeps coming back to the same answer, eSIM IoT is the must-have you’ve been waiting for. And if you want help weighing that tradeoff for your own situation, jump into our next blog post on questions for internal alignment on eSIM IoT, that will guide you with more specificity.