eSIM gets talked about as though it’s one thing.
It isn’t.
The term covers a form factor, a software specification, a provisioning architecture, and a commercial model – all at once. Conflate them and you’ll make bad decisions. Separate them and the picture becomes much clearer.
This article is for people deploying IoT at scale, evaluating connectivity platforms, or trying to understand why two products both called “eSIM” behave completely differently in the field.
Start here: eUICC is not the same as eSIM
The hardware is called an eUICC – embedded Universal Integrated Circuit Card.
It’s a secure element. A tamper-resistant chip that can store one or more network profiles and switch between them under software control. That’s it. That’s the hardware side sorted.
What most people call “eSIM” is actually the combination of eUICC hardware and the remote SIM provisioning (RSP) software stack that manages it. The GSMA defines that stack. There are three main specifications. They are not interchangeable.
The reason this matters: a device can have an eUICC fitted and still be completely inflexible if it’s only provisioned with a single profile and locked to one network. The chip is a necessary condition. It’s not a sufficient one.
Form factor: less important than you think
eUICC comes in several physical forms.
Removable (2FF, 3FF, 4FF) – standard SIM card sizes. Removable. Can be reflowed in a phone or tablet tray. Can also be eUICC-capable if the chip inside supports it. Most people don’t realise a standard-looking SIM card can be part of an eSIM deployment.
MFF2 – a soldered chip, typically 5mm x 6mm, designed for industrial and automotive use. No slot. No user-accessible component. Goes directly onto the PCB.
SON-8 – a newer industrial form factor, smaller footprint than MFF2.
The form factor choice is mostly driven by environment and lifecycle expectations:
- Consumer devices and tablets: removable is fine, easier to handle returns and replacements
- Industrial IoT, outdoor sensors, vehicle-mounted hardware: MFF2 is the right call – no slot to corrode, no SIM tray to fail, vibration-resistant, rated for wider temperature ranges
- High-volume production lines: MFF2 simplifies manufacturing, no manual SIM insertion
MFF2 is not inherently “better” eSIM. It’s better for certain deployments. A removable eUICC-capable SIM is a perfectly valid eSIM implementation for the right use case.
The mistake is choosing MFF2 because it sounds more serious without accounting for what happens when you need to replace the device or recover from a provisioning failure. There’s no slot to pull. You’re relying entirely on the RSP stack working.
The three specifications you need to know
SGP.02 – M2M (legacy push)
The original GSMA M2M eSIM specification. Ratified in 2014.
It works on a push model – profiles are prepared by a subscription manager and pushed to the device. The process requires coordination between the SM-SR (Subscription Manager Secure Routing) and SM-DP (Subscription Manager Data Preparation) components, plus the MNO.
In practice, SGP.02 was slow and operationally heavy. Profile switching typically required a support ticket, coordination between multiple parties, and days of lead time. It was designed when “remote provisioning” meant anything better than physically swapping a SIM. The bar was low.
Large automotive and utility deployments used SGP.02 because they had the scale to justify the operational overhead, and the device lifecycles were long enough that switching networks mid-life was rare.
For new IoT deployments, SGP.02 is effectively legacy. But a significant installed base is still running it, particularly in energy, transport, and industrial automation. If you’re inheriting or integrating with existing deployments, you may well encounter it. Migration to SGP.32 is possible but requires device-side eUICC support – not all older chips can be reflashed.
SGP.22 – Consumer (pull-based)
The consumer eSIM specification, ratified in 2016 and updated since. This is what powers eSIM in iPhones, Android handsets, laptops, tablets, and smartwatches.
It’s pull-based. The device initiates the profile download, usually triggered by the user scanning a QR code or entering an activation code. The profile is then pulled from the SM-DP+ (the “plus” version replaced the older SM-DP for both consumer and, later, IoT).
SGP.22 works well for anything with a user in the loop. ePOS terminals, tablets, body-worn cameras, handheld scanners – any device where someone is present at commissioning can work cleanly with SGP.22.
The limitation is that “pull” requires a trigger. In most implementations that trigger is manual. You can automate it under controlled conditions, but SGP.22 was not designed for zero-touch deployment at scale. Trying to force it into headless IoT deployment at volume introduces operational friction you don’t want.
One important point: SGP.22 is by far the most mature and widely supported specification. The platform ecosystem, the device chipset support, the tooling – all of it is further developed than SGP.32. If your deployment model allows for it, SGP.22 is the path of least resistance right now.
SGP.32 – IoT (push-based, automated)
The GSMA’s IoT-specific eSIM specification, finalised in 2023.
Designed from the ground up for zero-touch deployment. No user interaction required. Profiles are pushed to the device over the air, managed via an IoT Profile Assistant (IPA) function that can run on the device or in the network. The architecture is leaner than SGP.02 and doesn’t require the full SM-SR/SM-DP split.
SGP.32 solves the core problem with deploying connected devices at scale: you cannot send an engineer to every site to scan a QR code or interact with a device. Routers in remote infrastructure, sensors in locked enclosures, meters in subterranean chambers – none of these have users at commissioning. SGP.32 is built for that reality.
The catch is that SGP.32 device support is still maturing. Chipset availability is improving but the ecosystem is behind SGP.22 by several years. If you’re specifying new hardware for a deployment that doesn’t ship until 2026 or beyond, SGP.32 support is worth mandating in your device requirements. If you’re working with existing hardware, check what’s actually certified rather than what the spec sheet implies.
ABI Research forecasts SGP.32 profile downloads growing from around 2.9 million in 2025 to 194 million by 2029. That trajectory is not surprising given the IoT deployment volumes involved. It does not mean the ecosystem is ready today for every use case.
SM-DP+: where control actually lives
This is the part most articles skim over. It’s the part that matters most commercially.
SM-DP+ (Subscription Manager Data Preparation Plus) is the server-side platform that stores eSIM profiles and delivers them to devices. Think of it as a secure profile repository with a delivery and management layer on top.
When a device downloads a new network profile, it comes from an SM-DP+. When you switch a device from one MNO to another, that switch is orchestrated via SM-DP+. When you need to delete a profile, disable a device, or audit what’s deployed where – SM-DP+ is where that happens.
The key question for any eSIM deployment is not “does this SIM support eUICC?” It’s: whose SM-DP+ platform is managing it, and what can you actually do through it?
Several platform architectures exist in the market:
MNO-operated SM-DP+: the mobile network operator runs the platform and hosts only their own profiles. You get eSIM, but you’re locked to that operator’s network estate. Switching to a different MNO means moving to a different platform entirely. The flexibility is superficial.
MVNO/aggregator-operated SM-DP+: companies like Eseye, Transatel (Cisco), iBASIS, and others operate SM-DP+ platforms that can host profiles from multiple MNOs. This is where genuine multi-network flexibility comes from. You’re not tied to one network’s coverage or commercial terms.
Device manufacturer-operated: some OEMs operate their own SM-DP+ for devices they ship – particularly in consumer electronics. Relevant if you’re managing mixed fleets.
Independent platform providers: companies building pure-play eSIM management platforms, often with API-first architectures designed for integration into wider IoT management systems.
What you’re evaluating when you choose an eSIM provider is largely the SM-DP+ platform behind the product. Questions worth asking:
- How many MNO profiles can be hosted on the platform?
- What does the profile switching process look like operationally – portal, API, both?
- What’s the latency on a profile switch in practice, not in the brochure?
- Is there an SLA on SM-DP+ availability? What happens to connected devices if the platform goes down?
- What audit and reporting visibility do you get at the device level?
- Can you integrate the platform with your own management systems via API?
The answers will separate genuine multi-network flexibility from eSIM in name only.
Roaming and multi-operator deployments
eSIM does not automatically solve roaming. It changes where the control sits.
With a traditional roaming SIM, the SIM itself is provisioned to roam across multiple networks under a fixed commercial arrangement. The device finds the best available network in a given country and connects. Simple, but inflexible – the roaming agreements are baked in at the SIM level.
With eUICC and remote provisioning, you have a different option: provision a local MNO profile for each country or region where the device operates. A device deployed in Germany gets a German MNO profile. The same device moved to Japan can receive a Japanese profile. No roaming charges, local network performance, local compliance where that matters.
The operational requirement is that your SM-DP+ platform has the MNO relationships and profile inventory to support this. Most don’t, or not globally.
The practical position for most IoT deployments right now is a hybrid: a multi-IMSI or roaming SIM as the baseline connectivity layer, with eUICC providing the option to lock to a specific local network where performance or cost justifies it. Pure eSIM-only multi-region deployment is achievable but requires more platform maturity than most providers currently offer.
What “eSIM ready” actually means for a deployment
Checklist framing tends to oversimplify this, but the key questions are:
Device side: Does the hardware have a certified eUICC? Which specifications does it support – SGP.22, SGP.32, or both? Is the IPA implementation on SGP.32 devices in firmware or hardware?
Platform side: Who operates the SM-DP+? What MNOs are available through it? What does the management interface actually look like at scale?
Operational side: How does your provisioning workflow change? Who handles failed profile downloads? What’s the recovery path if a device loses connectivity mid-switch?
Commercial side: How is the platform priced? Per-device, per-profile-download, per-switch? The economics of eSIM management can erode the cost benefits of remote provisioning if the platform commercial model isn’t matched to your deployment scale.
None of these are reasons to avoid eSIM. They’re reasons to evaluate it properly rather than take a provider’s readiness narrative at face value.
The honest summary
eUICC is a genuinely enabling technology for IoT connectivity. The ability to change network profiles remotely, without physical access, without SIM replacement, across multi-region deployments – that’s a real operational improvement over the alternative.
SGP.32 is the right specification for scale IoT. The ecosystem is maturing faster than most people realise.
But the value is almost entirely in the SM-DP+ platform layer and the MNO relationships behind it. The chip in the device is the entry ticket. What you can actually do with it depends entirely on the platform you’re connected to.
Choose the platform before you choose the SIM.
Read the next article in this series: iSIM: The End of the SIM as a Component