SIM, eSIM, multi-IMSI: which one actually fits your IoT deployment?

Let me start with something nobody in this industry wants to admit.

Most people treat a SIM like a postage stamp. You stick it in, you forget about it, and you move on with your life. The problem is that a postage stamp does not cost you thousands of euros in roaming fees three years later. It does not lock you into a provider you hate. And it definitely does not leave a parking lot full of cars sitting free for an entire weekend because nobody planned for a network failure.

But we will get to that story.

The point is this: choosing between a standard SIM, a multi-IMSI SIM, and an eSIM is not a procurement task. It is an architecture decision. One that will follow you for the lifetime of your product. Get it right and connectivity becomes invisible, which is exactly what you want. Get it wrong and you will be the person explaining to your CFO why you are paying for 4,000 SIMs that have not been used since the previous team deployed them and forgot to deactivate them.

I have seen both scenarios. More of the second one than I would like to admit.

So here is a proper breakdown of each architecture: what it does, where it breaks, and how to choose based on your actual situation rather than whatever the last sales rep told you.

Standard SIM (UICC)

This is the SIM card everyone pictures. A physical card in one of four sizes: 2FF (mini), 3FF (micro), 4FF (nano), or MFF2, which is the industrial soldered version that goes directly onto the PCB and does not fall out when your device spends three years in the back of a truck driving across the Alps.

One SIM, one operator, one profile. The IMSI (International Mobile Subscriber Identity) on the card tells the network who you are and who is paying the bill. Simple. Proven. Inflexible.

It works well when your deployment is in a single country, your operator is reliable, your volumes are stable, and you are not planning to grow beyond your current geography. In that scenario a standard SIM with an MFF2 form factor is honestly the right answer. Do not over-engineer it.

It stops working the moment any of those conditions change. Multi-country deployments mean either permanent roaming costs or the logistical nightmare of managing multiple SIM SKUs by country. Long product lifecycles mean you are betting that today's operator will still be the right choice in 2031. Remote or hard-to-access devices mean a SIM swap requires a human being getting in a van, which at scale costs more than anyone budgeted for.

The real issue with standard SIM is not that it is bad. It is that the decision you make today is very hard to reverse once devices are in the field. You own it, for better or worse.

Multi-IMSI SIM

Same physical form factors as a standard SIM, but with multiple operator profiles stored on the card. The SIM can switch between those profiles depending on which network is available, either automatically based on signal quality or triggered by a command from your connectivity management platform.

This is what most IoT MVNOs are selling when they talk about a "global SIM." It is by far the most common solution for multi-country deployments today, and for good reason. One part number, ships everywhere, covers most of Europe without a roaming nightmare. For a lot of use cases it does exactly what it says on the tin.

But here is where it gets interesting. And where I want to tell you about a conversation I had with the CTO of a large parking solutions company.

His company had deployed multi-IMSI SIMs across dozens of major European cities. The pitch they had received was the usual: multiple IMSIs, seamless switching, full redundancy. The problem was that their contract only gave them commercial access to one primary IMSI. The secondary IMSI existed on the card but the switching logic was controlled by their MVNO, not by them. And when the primary IMSI provider had a major outage, the MVNO could not switch fast enough because nobody had pre-configured the event triggers that would tell the SIMs to move to the backup IMSI automatically.

The devices went offline. It was a weekend. Parking meters across multiple cities stopped working. Parking ended up being free for an entire weekend and the revenue loss was significant.

When they went back to the MVNO the answer was essentially: you should have written event-triggered scripts into your devices in advance to handle this scenario.

Which is technically correct. And also deeply unhelpful to hear after the fact.

The lesson here is not that multi-IMSI is bad. It is that IMSI switching in production is not as seamless as it sounds in a sales presentation. You cannot always trigger a switch on demand in real time (some MNO can). You need to define the conditions in advance: signal threshold, network failure event, geographic trigger. You need to confirm that your platform and the SIM firmware actually support those triggers. And you need to understand clearly who controls the switching logic: you, or your MVNO.

Always ask which operators are behind the profiles, not just how many. And always ask: in a failure scenario, who can trigger the switch and how fast?

eSIM (eUICC)

This is where the architecture changes fundamentally. An eSIM, or eUICC (Embedded Universal Integrated Circuit Card), is a SIM that can download, store, and switch between operator profiles over the air. No physical swap required, no van, no field visit.

There are three standards that matter, and most people in the industry only talk about two of them.

SGP.02 is the original M2M eSIM standard, defined by the GSMA before SGP.22 and SGP.32 existed. It was built for large-scale machine-to-machine deployments in utilities, automotive, and industrial applications, and it introduced the concept of remote SIM provisioning for M2M use cases. SGP.02 uses a push model: the platform initiates profile changes remotely without any action required on the device. There is no LPA. Profile management goes through an SM-SR (Subscription Manager Secure Routing) and SM-DP (Subscription Manager Data Preparation), which is a different architecture from the SM-DP+ used in SGP.22 and SGP.32.

If you are dealing with deployments from five or more years ago, particularly in automotive or smart metering, you will encounter SGP.02. It is not obsolete. It is still doing its job in millions of devices. But for new IoT designs it is being replaced by SGP.32, which is lighter, more scalable, and better suited to constrained hardware.

SGP.22 is the consumer eSIM standard. It is what is in your iPhone. It is built around a Local Profile Assistant (LPA) that handles profile download and provisioning. Now here is a detail that matters specifically for IoT: the LPA does not have to live in the device. It can sit in two different places.

LPAd means the LPA runs inside the device, typically in the application processor or modem. Full control over profile operations, but it requires processing power and energy to run.

LPAe means the LPA runs inside the eUICC chip itself, not on the device. The device does not need to implement the full LPA stack. It just passes commands through to the SIM. This reduces the load on the host device and works on more constrained hardware.

Both options share the same core problem for battery-powered IoT: energy. Every profile operation requires the device to be awake, connected, and processing. For a POS terminal or a smart building gateway running on mains power, fine. For a battery-powered asset tracker sitting on a shipping container somewhere outside Rotterdam, you are burning battery on connectivity management instead of on the thing you actually built the device to do.

There is also an operational point that does not get enough attention. Without LPAd properly implemented on the device side, managing SGP.22 profiles remotely becomes significantly harder. You lose direct control over when and how profile switches happen. Some implementations work around this but it adds engineering overhead that teams consistently underestimate, especially when they discover it six months into a deployment.

SGP.32 is the IoT eSIM standard, ratified by the GSMA in 2023. One terminology point worth knowing before you read further: SGP.32 does not use the term LPA. The spec officially replaces it with IPA (IoT Profile Assistant). So what SGP.22 calls LPAd and LPAe, SGP.32 calls IPAd and IPAe. Same concept, different name, different spec. You will see both terms depending on which standard the vendor is referencing.

In SGP.32, profile management is handled remotely through an eIM (eSIM IoT Remote Manager, the SGP.32 equivalent of a platform) with a minimal device-side footprint. The IPA handles communication between the device and the eIM. And critically, the IPAe (the variant where the IPA lives inside the eUICC chip rather than in the device), is explicitly marked as optional in the SGP.32 spec. Not every chip implements it. Always check the module datasheet before you assume it is available.

The intelligence moves off the device and into the platform. It was designed specifically for constrained IoT devices and long-lifecycle deployments.

Now I need to say something that might get me uninvited from a few industry events.

SGP.32 is not ready for most companies to deploy at scale right now. The ecosystem is still maturing. Not all modules support it. Not all operators have certified SM-DP+ infrastructure in place. The tooling is still limited. The number of vendors who can deliver a complete, production-ready SGP.32 deployment from chip to platform to operator is still small. Growing fast, but small.

I hear people talking about SGP.32 like it is already the default. Like you can just decide tomorrow to go full eSIM SGP.32 and be done with it. You cannot. Not unless you want to spend the next year debugging your provisioning flow instead of shipping product.

SGP.32 is the right direction and where the industry is heading. But the gap between "this standard exists" and "I can reliably deploy 50,000 devices using this" is real, and you should account for it when planning your roadmap.

Form factor versus architecture: two decisions people keep mixing up

Form factor is the physical shape of the SIM: plastic removable card in 2FF, 3FF, or 4FF, or a soldered MFF2 chip. This is a hardware decision driven by the physical environment. MFF2 soldered chips handle vibration, temperature extremes, and humidity that would kill a plastic card. They are standard for anything deployed outdoors, in vehicles, or in industrial conditions.

Architecture is what lives on the SIM: single-IMSI, multi-IMSI, SGP.02, SGP.22, or SGP.32.

These combine independently. A soldered MFF2 chip can be single-IMSI, multi-IMSI, or eUICC with any standard. A standard nano SIM card can carry an SGP.22 profile. The form factor tells you nothing about the architecture.

Teams constantly say things like "we are using MFF2 so we are locked in" or "we want eSIM so we need a removable card." Neither is automatically true. Choose your form factor based on the physical environment your device will live in. Choose your architecture based on your operational requirements. Two separate decisions that happen to end up on the same chip.

Profile provisioning management: the part that actually bites you in production

Choosing an architecture is step one. Managing it once devices are in the field is where things get hard, and where most guides stop talking.

Every SIM type requires some form of connectivity profile management. At minimum this means controlling which network your device connects to and configuring the APN (Access Point Name) that routes your data to the right destination. Get the APN wrong and your device connects to the network but cannot reach your platform. It looks connected. It is not working. This is one of the most common silent failure modes in IoT deployments and it is genuinely unpleasant to debug at 11pm.

For standard and multi-IMSI SIMs, APN configuration is typically pushed at provisioning or managed through your CMP. If you ever need to change it remotely, because you migrated platforms, moved to a private APN, or changed your routing architecture, you need OTA capability or a device-side mechanism. Without that, changing the APN means physically touching every device. At 10,000 units in the field, that is not a project. That is a crisis.

For SGP.22 with LPAd properly implemented, profile and APN management is more controllable. You can embed APN configuration in the profile itself and push it remotely. But this only works if LPAd is actually implemented correctly. If it is not, you are back to the same problem with an extra layer of complexity sitting on top of it.

For SGP.32, profile management including APN is handled through the eIM and SM-DP+. It is the cleanest architecture for remote fleet management at scale. But it requires your platform to support this integration, your operator to have the right infrastructure, and your team to understand the provisioning flow before something breaks. Not after.

The honest conclusion: eSIM does not make things simpler. It trades one set of problems for a different set. Whether that trade makes sense depends on your scale, your product lifecycle, and your team's actual capacity to manage the operational layer.

A company running 500 devices in a single country with a solid operator does not need any of this complexity. A standard SIM, a properly configured APN, and a CMP for basic diagnostics is entirely sufficient. The goal is not the most sophisticated architecture. The goal is one that fits your actual situation without creating problems you do not have yet.

The bootstrap profile: a detail with real commercial implications

Every eUICC ships with at least one pre-installed profile that lets the device reach a network on first boot so it can contact the SM-DP+ and download its operational profile. The GSMA specs officially call this a Provisioning Profile. In the field everyone calls it a bootstrap profile. Both terms refer to the same thing and you will encounter both, so now you know.

In practice, this creates constraints worth understanding before you commit to anything.

eUICC memory is finite. Typically enough for two to five profiles depending on the chip specification. The bootstrap occupies one of those slots until you explicitly delete it after the operational profile is active. If you need multiple operator profiles across different regions, you will hit the memory ceiling faster than expected.

The bootstrap operator matters commercially. The bootstrap profile is tied to a specific operator or MVNO, whoever pre-installed it at the factory. Your device must connect to that operator's network first, even if your actual operational profile uses a completely different provider. In regions where the bootstrap operator has poor or no coverage, your device cannot bootstrap and cannot receive its real profile. It is dead on arrival, which is a much worse problem than a device failing six months into deployment, because at least in the second scenario you have already shipped.

When you buy eUICC chips or modules with a pre-installed bootstrap profile, you are implicitly choosing the first network your devices will ever connect to. Some vendors bundle this with a commercial offer. The bootstrap is tied to a connectivity contract. Others offer flexibility. Ask the question explicitly before you commit: who provides the bootstrap, what network does it use, and is there flexibility to change it?

Once the operational profile is live and stable, best practice is to delete the bootstrap profile to free the memory slot. This should be handled automatically by your CMP or eIM as part of the provisioning flow. If it is not, you are carrying a dead profile consuming space on every device indefinitely. At scale, unmanaged profile slots become an operational problem that is embarrassing to explain.

How to choose

Single country, stable volumes, reliable operator: use a standard SIM with an MFF2 form factor if the physical environment demands it. Keep it simple. Do not let anyone sell you complexity you do not need.

Multi-country deployment, one SKU across markets: multi-IMSI from an MVNO with solid operator relationships in your target countries. Verify which operators are behind the profiles. Understand who controls the switching logic and how fast they can act in a failure scenario. Define your event triggers before deployment, not after your first outage.

Long product lifecycle, hard-to-access devices, need to switch operators without touching hardware: plan for eSIM SGP.32. If the ecosystem supports your module and your operator today, go for it. If not, start with multi-IMSI, design your hardware to accommodate an eUICC later, and migrate when the ecosystem is ready for your specific use case.

Hardware startup still in development: design for flexibility from the start. Do not lock yourself into a form factor that blocks future migration. Test with multi-IMSI. Keep your options open.

The question worth asking every provider before you sign

Whatever you choose, ask this: what happens to my devices if I want to leave?

Standard SIM: you order new SIMs and do a field swap. Painful, expensive, possible.

Multi-IMSI: you are dependent on your MVNO. Switching means new SIMs, field visits, or a migration plan that your current provider has limited motivation to help you execute quickly.

eSIM done properly: you push a new operator profile over the air and migrate the fleet without touching a single device. This is the promise. It only works if your eUICC supports the target operator's profile format and your platform has the right integrations already in place.

The architecture with the most long-term flexibility is eSIM. The architecture that gets most deployments live fastest with the least friction is multi-IMSI. Standard SIM is the right answer for simple, stable, single-market deployments where you have no plans to change anything.

Know which situation you are actually in. Then decide accordingly.

Summary

One last thing. Whatever you deploy: track your SIMs. Set up deactivation alerts. It sounds obvious. And yet every company I have spoken to has a graveyard of active SIMs sitting in devices that were retired two years ago, quietly billing every month, because no one set up a process and the person who knew about the deployment has long since moved on.

The most expensive mistake in IoT connectivity is not always the architecture decision. Sometimes it is just nobody checking the invoice.

Have a specific deployment question? Check the Buyer Guide section for the full discovery framework, or find me on LinkedIn.