If you have ever tried to explain eSIM standards to a normal human at a dinner table, you already know the pain.

They ask, “So it is just a digital SIM, right?”
And you are like, “Yes, but also no, because the way it gets onto a device depends on which GSMA spec we are talking about.”

This is where SGP.22 and SGP.32 come in. They are both “remote SIM provisioning” standards from the GSMA universe, but they were built for very different realities.

SGP.22 is the consumer play. Think smartphones, tablets, wearables, and anything with a screen and a person nearby who can tap buttons. It is designed around a user-driven flow (you initiate the download, usually by scanning a QR code).

SGP.32 is the IoT play. Think smart meters bolted to a wall for 10 years, asset trackers inside containers, sensors in basements, cars shipped across borders, and devices that have no screen, no camera, and no patience. SGP.32 adds the missing “fleet-scale control layer” so profiles can be managed remotely without relying on a user interface, and it introduces new components to make that realistic.

SGP.22 in plain English

SGP.22 is the GSMA consumer Remote SIM Provisioning (RSP) architecture used widely in travel eSIM and consumer activation flows. The mental model is simple: the device pulls a profile when you tell it to.

In practical terms, SGP.22 is typically associated with:

• SM-DP+ (the server that prepares and delivers the eSIM profile)
• SM-DS (a discovery service used in some flows)
• An on-device “assistant” that drives the process (often discussed as the Local Profile Assistant, LPA)

You have seen this in real life a thousand times:

• Buy an eSIM
• Get a QR code or activation code
• Scan it on your phonePprofile downloads and installs
• You switch it on

That “pull model” is not a bug, it is the whole point. It keeps user consent and user interaction at the center, which makes sense for consumer devices.

Why SGP.22 starts to break in IoT

Now take that exact flow and try to apply it to 50,000 sensors.

Who scans the QR codes?

Who clicks “Add eSIM” in a settings menu that does not exist?
What happens when the device is asleep most of the day to save power?
What happens when coverage is intermittent and the download fails halfway?

This is why so much IoT eSIM provisioning historically either:

• leaned on the older M2M spec (SGP.02) with heavier operational plumbing, or
• went semi-proprietary with custom bootstrap and orchestration approaches, because the consumer flow was not built for headless fleet operations.

SGP.32 is the “IoT control layer” spec

SGP.32 is GSMA’s eSIM IoT architecture designed for constrained or headless devices and, crucially, for fleet-scale remote management. The headline difference is not “it can download an eSIM.” SGP.22 can do that too.

The difference is: SGP.32 is designed so that remote provisioning and lifecycle management can happen without a user poking the device.

The Trusted Connectivity Alliance (TCA) summary is one of the cleanest ways to see what changed, because it spells out the new moving parts:

• eIM (eSIM IoT Remote Manager): a standardized remote provisioning and management tool that can manage single devices or fleets, and can communicate across IoT devices and SM-DP+ without bespoke integrations.
• IPA (IoT Profile Assistant): replaces the consumer LPA concept in the IoT model. It can live on the device (IPAd) or on the eUICC (IPAe), depending on what the manufacturer chooses.

And importantly, SGP.32 still leverages familiar infrastructure like SM-DP+ and SM-DS, rather than throwing everything away. It is more like “upgrade the architecture so it actually works for IoT” than “invent a new universe.”

The features that matter (and why IoT people care)

A lot of the excitement around SGP.32 comes from the fact it addresses boring operational pain. The kind of pain that does not trend on LinkedIn, but costs real money.

Here are the practical upgrades that show up in the TCA breakdown of SGP.32:

Lightweight protocols for constrained networks

SGP.32 adds support for lighter protocols suited for constrained devices and networks, including CoAP as an alternative to HTTPS and DTLS as an alternative to TLS, explicitly to better fit power and bandwidth constraints (think NB-IoT, Cat-M scenarios).

Rollback and fallback behavior

If a device enables a new profile and then has no connectivity, SGP.32 includes mechanisms to revert to the previous working profile (rollback) and to activate a fallback profile when connectivity is lost. In IoT terms: fewer truck rolls, fewer “dead devices in the field” nightmares.

Connectivity parameter handling

SGP.32 includes procedures for retrieving connectivity parameters from the eUICC, useful when a constrained device cannot realistically store or maintain a full catalog of APN settings for every operator it might encounter.

Security and compliance continuity

SGP.32 reuses much of the established security approach and introduces security protocols around the new eIM element, including authorization and authentication expectations. The TCA paper also points to GSMA security accreditation expectations for components like SM-DP+ (SAS) and references related specs around device protection profiles.

So yes, SGP.32 is “a standard.” But what it really is, commercially, is a path away from fragile provisioning workflows and one-off integration spaghetti.

So which one should you use?

Here is the decision logic I use when someone asks this in a meeting and everyone pretends it is not a big question.

Use SGP.22 when a human is part of the workflow

If your device has a screen, a UI, or a user who can intentionally install and switch profiles, SGP.22 is still the natural fit. It is optimized for the user-driven pull flow and consumer operations.

Use SGP.32 when the device is “headless” or the deployment is fleet-scale

If your device is deployed at scale, has limited UI, runs on tight power budgets, or needs automated lifecycle management across regions and operators, SGP.32 is designed for that reality. This is the core framing you will see repeated by IoT-focused players discussing SGP.32’s intent and constraints.

The messy middle is real

A lot of “IoT” is actually user-adjacent (dashcams, payment terminals, handheld industrial devices). Some of these can limp along on consumer-style flows, especially in early stages. But as soon as you care about ongoing remote control, governance, and resilience, you start drifting toward the SGP.32 mindset, even if your first deployment did not.

Where SGP.22 and SGP.32 sit in the wider market shift

This is the part that matters for anyone watching the business of connectivity.

The market is separating into two layers:

• convenience distribution layers (great onboarding, QR flows, app UX, travel checkout conversions)
• control layers (policy, orchestration, resilience, fleet operations, lifecycle governance)

SGP.22 sits comfortably in the first world. It is the standard behind a huge amount of consumer eSIM activation logic.

SGP.32 is the spec that makes the second world more standardized and interoperable, because it introduces a more scalable orchestration model (eIM + IPA) and acknowledges constrained networking realities (protocols, rollback, fallback).

That is why you see IoT connectivity providers, module makers, and operator IoT divisions talking about SGP.32 as a step toward “deploy anywhere, switch networks later” without reinventing the wheel for every project.

Conclusion: SGP.32 is not “better” than SGP.22, it is a bet on how devices behave

Here is the cleanest way to think about it: SGP.22 assumes a user is present. SGP.32 assumes the device is alone in the world.

And that difference changes everything.

In 2026, the interesting story is not whether eSIM adoption continues. It will. The question is whether connectivity becomes programmable infrastructure across fleets, not just a consumer onboarding flow. SGP.32 is a real attempt to standardize that control layer: remote management via eIM, an IoT-native profile assistant model (IPAd or IPAe), resilience mechanisms like rollback and fallback, and support for constrained protocols that match how many IoT devices actually live.

Meanwhile, SGP.22 is not going anywhere, because consumer eSIM activation is still the most visible part of the market, and it is still the right tool when a person is in the loop.

So the real conclusion is strategic: if you are building for travelers, phones, and user-driven switching, keep your SGP.22 worldview. If you are building for fleets, industrial deployments, and long-lived devices, start thinking in SGP.32 terms now, even if your first rollout is still messy. The winners will be the players who can bridge both worlds: consumer-grade simplicity on the surface, IoT-grade control underneath, with interoperability and compliance strong enough to survive real deployments.