Not All eSIM Is the Same: A Business Guide to M2M, Consumer, and IoT Standards

TL;DR

• “eSIM” strictly describes where a chip physically sits, embedded versus removable, which is a separate question from whether it supports GSMA’s remote provisioning standards, a distinction the market blurs constantly.
• The GSMA has published three separate generations of eSIM remote provisioning standards: M2M (2014), Consumer (2017), and IoT (2023), and they are not interchangeable.
• Choosing the wrong generation for a fleet usually shows up later, as a scaling problem, not an initial failure, which is why it’s worth understanding the differences before committing.

---

There is a tendency to toss around the word “eSIM” as if it’s a singular, unified technology. It isn’t. It’s a label for three distinct GSMA standards (built roughly a decade apart) for three different situations: machines being remotely reconfigured by a carrier, people activating a plan on their own phone, and unattended IoT devices that will never see a human being in the field. Vendors don’t always specify to which generation their “eSIM support” actually refers, and the differences matter more than they might first appear, especially for a device that’s expected to stay in the field for years.

First, a necessary clarification

“eSIM” and “remotely provisionable” get treated as the same claim. They aren’t, and mixing them up is a real source of confusion in sales conversations, not just a technicality.

“eSIM” strictly means embedded SIM: a chip soldered onto the device board, typically in the MFF2 package, rather than a swappable card. That’s a statement about physical form. Whether a SIM can be reprogrammed with a new profile over the air is a separate question, of whether the chip is a plain UICC (one fixed profile) or an eUICC (multiple profiles, managed remotely under SGP.02, SGP.22, or SGP.32). The two are independent: an embedded MFF2 chip can be a plain UICC with no remote provisioning at all, and a fully SGP.32-compliant eUICC can just as easily live on an ordinary, removable plastic SIM card, which isn’t an eSIM by the strict definition.

From here on, “M2M eSIM,” “Consumer eSIM,” and “IoT eSIM” follow the GSMA’s own naming for these specs: shorthand for provisioning capability, not a form-factor claim.

---

M2M eSIM: the original, operator-driven standard

The GSMA’s first remote SIM provisioning specification, SGP.02 (built on the SGP.01 architecture), was completed in 2014 and designed for machine-to-machine and industrial connections: things like fleet telematics units and vending machines. It lets operators download, change, and manage eSIM profiles over the air, without a technician physically swapping a card.

The mechanism is a “push” model, meaning a profile change is triggered by the operator (not the device or a person) and delivered over the air via SMS or HTTPS. The architecture behind it splits the job into two components, an SM-DP (Subscription Manager, Data Preparation) that prepares profiles and an SM-SR (Subscription Manager, Secure Routing) that delivers them. It was a real advance for its time, but it has aged in specific ways: an eUICC is typically bound to a single SM-SR at manufacturing, which limits flexibility, and reliance on SMS doesn’t map well onto newer low-power networks like NB-IoT or LoRaWAN.

---

Consumer eSIM: the standard behind your phone’s “add a plan” screen

The GSMA evolved the model in 2017 with SGP.21 and SGP.22, purpose-built for smartphones, tablets, and wearables. This is the eSIM most people are probably most familiar with: scan a QR code, tap “confirm” in a settings menu, and a new mobile plan downloads and activates.

That’s a “pull” model, meaning the action originates with a person, through an interface, who triggers the download. The architecture combines the earlier SM-DP and SM-SR roles into a single SM-DP+ server, and adds an LPA (Local Profile Assistant), the software running on the device that talks to that server on the user’s behalf. It’s a well-built standard for its intended use case, but the intended use case is the constraint: it assumes a screen, an interface, and someone present to approve the change. None of that exists on a shipping container tracker or a utility meter.

---

IoT eSIM: automating the pull model for devices with no one home

The GSMA published SGP.31 and SGP.32 in 2023, purpose-built to close that gap. IoT eSIM keeps the flexibility of the consumer “pull” model but replaces the human step with automated, server-driven commands, which is the specific adaptation that makes it usable for large-scale, low-power IoT fleets.

Under SGP.32, a device can pull a profile in one of two ways: directly from an SM-DP+ server, or indirectly through an eIM (eSIM IoT Remote Manager), a lightweight server-side coordinator that acts as a proxy for profile routing. On the device side, an IPA (IoT Profile Assistant) plays the role the LPA plays for phones, and it can run either on the device’s application processor (IPAd) or resident on the eUICC itself (IPAe), which matters for genuinely constrained hardware. SGP.32 also supports lightweight protocols like CoAP over DTLS, instead of assuming a full HTTPS connection, since that assumption doesn’t hold for battery- and bandwidth-constrained LPWAN devices.

---

How to actually choose

For most organizations building or operating connected devices today, the practical question isn’t which standard is “best” in the abstract – it’s which one matches how a specific fleet actually operates.

A few questions tend to clarify it quickly: 

• Does the device have a screen and a person who will ever interact with it directly, or is it headless? 
• Does it run on a network like NB-IoT or LoRaWAN where SMS and full HTTPS overhead are impractical? 
• Is it being deployed at a scale where per-device manual activation isn’t realistic? 
• Is it expected to stay in the field for five, ten, or more years, long enough that “we’ll deal with connectivity later” becomes an expensive assumption?

If most of those answers point toward scale, remoteness, and a long field life, IoT eSIM under SGP.32 is the standard built for that situation specifically, not adapted from something else after the fact. Organizations still running fleets on legacy M2M eSIM aren’t necessarily wrong to have built on SGP.02, since it was the standard available at the time, but a migration path toward SGP.32 is worth planning for deliberately rather than inheriting by default.

---

Where this fits with Soracom

Soracom’s Connectivity Hypervisor is built as an SGP.32-compatible orchestration layer, letting organizations add, activate, and switch between operator profiles on a Soracom IoT SIM remotely, without touching the device. If you’re evaluating whether IoT eSIM is the right fit for a fleet you’re planning, Soracom and Kigen also offer a hands-on Starter Kit to test SGP.32 directly with production-grade hardware and connectivity before committing to it.

Understanding which generation of eSIM standard a device actually runs on isn’t a technicality. It determines whether a fleet can be managed remotely at scale or whether it inherits the constraints of a standard built for a different problem a decade or more ago.

---

Curious about experimenting with eSIM? Contact us today to learn how Soracom puts users in control of their data.