SGP.32 vs SGP.22: why the new eSIM standard matters for IoT

If you deploy cellular-connected devices at any meaningful scale, you will have run into the awkward truth that eSIM was not really designed for you. The standard most of the industry has leaned on, SGP.22, was built for smartphones and wearables. It assumes a person, a screen, and a QR code. None of those things exist in a smart meter, an EV charger, or an asset tracker.

SGP.32 changes that. Published by the GSMA in 2023 and now at version 1.2 (June 2024), it is the first eSIM remote provisioning standard written specifically for IoT. Here is what is different, and why it matters when you are specifying connectivity for a fleet.

The short version

SGP.22 is the consumer eSIM standard. A user pulls a profile onto a device by scanning a QR code or tapping through an app.

SGP.32 is the IoT eSIM standard. A server pushes a profile to the device without any user interaction, using an architecture designed for headless, constrained hardware.

Both use the same underlying profile delivery infrastructure (the SM-DP+). The difference is in how the device and the network talk to each other around that infrastructure.

Why SGP.22 struggled in IoT

The consumer model works fine when there is a human in the loop. In IoT there usually is not. Devices are sealed inside enclosures, buried in cabinets, or scattered across geographies nobody wants to drive to.

The typical workarounds became familiar:

• QR codes printed on stickers inside equipment boxes, scanned during commissioning
• Bootstrap profiles loaded at the factory, with manual re-provisioning if the bootstrap carrier falls over
• Companion apps that exist purely to simulate a user tapping "accept"

These approaches work for tens or hundreds of devices. They do not scale cleanly to tens of thousands, and they add cost and fragility at every step. There was also a protocol problem: SGP.22 runs HTTPS over TCP, which is heavier than is ideal for NB-IoT or LTE-M devices operating on tight power budgets.

What SGP.32 actually introduces

SGP.32 keeps the proven back end of SGP.22 and replaces the front end with two new components designed for IoT:

• eIM (eSIM IoT Remote Manager): a server-side "virtual user" that issues profile management commands on behalf of the enterprise. This is what replaces the human with a smartphone.
• IPA (IoT Profile Assistant): the on-device or on-eUICC component that receives those commands and handles the profile download. It can live in the device (IPAd) or on the eUICC itself (IPAe), which matters for constrained hardware.

It also adds support for lighter-weight protocols like CoAP over DTLS as an alternative to HTTPS over TLS, which is a meaningful change for power-constrained devices.

The practical consequence is that profile management moves from pull to push. Instead of each device waiting for a user to trigger something, the eIM orchestrates profile downloads, swaps, and deletions across an entire fleet from a single control point.

The differences that affect buying decisions

Initiation model. SGP.22 is user-initiated. SGP.32 is server-initiated. If your device has no user, SGP.32 removes the need to engineer one.

Scale. SGP.22 was not built for bulk operations. SGP.32 is. Changing carrier across 20,000 trackers stops being a logistics problem and becomes a configuration change.

Resource footprint. SGP.32 is designed for devices with limited memory, processing power, and battery. SGP.22 was not a bad fit for a phone. It is a poor fit for a battery-powered sensor expected to last ten years on a single cell.

Backwards compatibility. SGP.32 reuses the SM-DP+ from SGP.22. Operators and SM-DP+ providers that already support consumer eSIM have a sensible migration path rather than a forklift replacement. This was a deliberate design choice to accelerate adoption.

Ecosystem maturity. This is where honesty matters. SGP.32 is real, certified solutions are coming through, and the Trusted Connectivity Alliance has forecast that over half of active IoT eSIMs will be SGP.32-compliant by 2028 (see TCA's whitepaper Realising the Benefits of GSMA's eSIM IoT Specification (SGP.32)). But today, the installed base is still overwhelmingly SGP.22 with bootstrap-profile workarounds. If you are specifying hardware now, ask suppliers directly what they support, what their eIM story is, and when their roadmap brings full SGP.32 certification.

What this means for your next deployment

For devices going into the ground or onto a wall for ten years, the specification your eUICC supports will determine how painful the next carrier switch is. If your fleet might ever need to change connectivity provider (for commercial reasons, coverage reasons, or regulatory reasons in a new market), SGP.32 makes that a remote operation rather than a truck roll.

For devices with a short refresh cycle or a simple deployment, SGP.22 with a well-chosen bootstrap profile is still a perfectly reasonable choice, and is what most of the market runs on today.

The right answer depends on fleet size, device lifespan, power budget, and geographic spread. If you want to talk through where your deployment sits on that spectrum, and what hardware and SIM combinations make sense, we are happy to work through it with you.

Millbeck. IoT Connectivity.

‍