SGP.22 vs SGP.32
SGP.22 and SGP.32 are both GSMA standards for remote SIM provisioning: getting an operator profile onto an eUICC without posting anyone a plastic SIM. They do the same job for very different devices. One assumes a person holding a phone. The other assumes a box bolted to a wall in a field, with no screen, no keyboard and nobody about.
Quick answer: SGP.22 is the consumer eSIM standard, where the device (usually prompted by a user scanning a QR code) pulls a profile down. SGP.32 is the IoT eSIM standard, where a server-side eSIM IoT Remote Manager (eIM) pushes profile changes to whole fleets with no human involved. Both download profiles from the same SM-DP+ servers, but an SGP.22 eUICC cannot be upgraded to SGP.32 over the air.
SGP.22 vs SGP.32 at a glance
| Area | SGP.22 (consumer eSIM) | SGP.32 (IoT eSIM) |
|---|---|---|
| Built for | Phones, tablets, watches, laptops | Headless IoT devices and large fleets |
| Who starts a profile change | The user, on the device | The enterprise, through the eIM |
| On-device agent | LPA (Local Profile Assistant) | IPA (IoT Profile Assistant), in the device (IPAd) or on the eUICC (IPAe) |
| Remote control point | None in the standard | eIM (eSIM IoT Remote Manager) |
| Profile server | SM-DP+ | SM-DP+ (the same infrastructure) |
| Transport | HTTPS over TCP/TLS | HTTPS, plus CoAP over DTLS for constrained devices |
| Bulk operations | Not designed for it | A core design goal |
| NB-IoT and LTE-M | A poor fit | Designed for them |
| Architecture / test specs | SGP.21 / SGP.23 | SGP.31 / SGP.33 |
| Latest version | v2.7 (April 2026) and v3.1 | v1.3 (May 2026); certification tracks v1.2 |
| Typical use today | Consumer devices, and many eSIM routers wrapped in vendor tooling | New IoT designs, rolling out through 2026 |
Where SGP.02 fits
There are actually three GSMA eSIM standards, and most IoT estates contain at least two of them. SGP.02 was the original machine-to-machine standard. It was server-driven, which suited IoT, but control sat with the operator: profile management ran through an SM-SR tied to the operator relationship, activation often relied on SMS, and changing provider meant a bilateral integration project. That is why eSIM barely moved outside automotive for years.
| SGP.02 (M2M) | SGP.22 (consumer) | SGP.32 (IoT) | |
|---|---|---|---|
| Control sits with | The operator | The user | The enterprise |
| Model | Push, via SM-SR | Pull, via LPA | Push, via eIM and IPA |
| Changing provider | Slow, bilateral integration | Easy, but needs a user | Remote and scriptable |
| Status | Legacy, still in the field | Active, consumer mainstream | Current IoT standard |
SGP.32 takes the best of both: server-driven control from SGP.02, without the operator lock-in, and the shared SM-DP+ infrastructure from SGP.22, without the need for a human.
How the two standards actually work
SGP.22: the device pulls
- The user gets an activation code, usually as a QR code.
- The LPA on the device reads it and contacts the SM-DP+ named in the code (or finds it through a discovery server, the SM-DS).
- The profile downloads to the eUICC, and the user enables it.
Every step assumes someone is there to start it and confirm it. On a phone that is fine. On a smart meter it means a sticker, a commissioning engineer and a van.
SGP.32: the server pushes
- The enterprise (or its connectivity provider) tells the eIM what each device should be doing.
- The eIM sends instructions to the IPA on the device, in bulk if needed.
- The IPA fetches the profile from the SM-DP+ and carries out the change on the eUICC: download, enable, disable or delete.
Nobody touches the device. Changing operator across 20,000 trackers becomes a job for an API call rather than a fleet of vans.
Why SGP.22 is still important for IoT
SGP.22 is not dead, and it is not only for phones. A large share of today’s “eSIM” industrial routers use SGP.22 eUICCs, with the router maker’s cloud platform doing the job a human would do on a phone. Teltonika (with RMS) and Robustel are the obvious examples: the platform handles profile workflows, fallbacks and visibility, so the deployment feels closer to SGP.32 than the standard underneath it.
That works, and for a deployment you need running this quarter it may well be the right choice. The catch is that the management layer is proprietary. Move away from that vendor’s platform and the convenience goes with it. SGP.32 standardises that layer so it is not tied to one hardware brand.
Which one does my device use?
Datasheets that say “eSIM ready” or “supports eSIM” tell you almost nothing. Ask, or check, these:
- Which standard is the eUICC certified against? SGP.02, SGP.22 or SGP.32, and which version.
- Is there an eIM in the picture? If profiles are managed through the router maker’s own cloud with no eIM, you are almost certainly on SGP.22.
- Where does the profile assistant live? An IPA (on the device or the eUICC) means SGP.32. An LPA means SGP.22.
- Is there a SIM slot? A device with a standard SIM slot can often be moved to SGP.32 with a removable SGP.32 card that carries its own IPA (IPAe), regardless of what the router itself supports.
Can you upgrade from SGP.22 to SGP.32?
Not over the air. The standard is part of the eUICC operating system, which is fixed when the chip is made. Your options are:
- Replace the hardware at its natural refresh point, with native SGP.32 parts.
- Use a removable SGP.32 card in devices that have a SIM slot.
- Run both side by side. Most estates will manage SGP.02, SGP.22 and SGP.32 devices in parallel for several years, so a platform that can see all three is worth having.
Procurement risk: “supports eSIM”
The most dangerous phrase in IoT procurement is “supports eSIM”. Before you sign, get written answers to these:
- Which GSMA standard and version is the eUICC certified to?
- Who operates the eIM, and can I move to a different one if I change provider?
- What is the bootstrap profile, and which networks does it reach in my target markets?
- Can profiles be changed in bulk, and what happens if a switch fails?
- Can the device still be reached during a failed provisioning attempt?
- Can your platform manage my existing SGP.02 and SGP.22 devices alongside SGP.32 ones?
Decision guide
| Your situation | Sensible choice |
|---|---|
| Device has a screen or a user, or sits under an MDM platform | SGP.22 is fine |
| Need routers deployed now, short refresh cycle, happy with one vendor’s cloud | SGP.22 eUICC with the vendor’s management platform |
| Long-life, headless device (meters, chargers, trackers, sensors) | Specify SGP.32 at build |
| Fleet across several countries, or likely to change provider | SGP.32, with eIM portability in the contract |
| Existing slot-based devices you want on SGP.32 | Removable SGP.32 card with IPAe |
| NB-IoT or LTE-M, battery powered | SGP.32 (it was designed for these networks) |
A real provider’s journey
To see how this plays out commercially, we followed one global IoT connectivity provider through all three standards: a decade of working around SGP.02 and SGP.22 with multi-IMSI technology, then a 2026 rebuild around SGP.32 with Kigen. Read the full case study: SGP.32 vs SGP.22: what floLIVE’s journey tells us about IoT eSIM.
Frequently asked questions
What is the difference between SGP.22 and SGP.32?
SGP.22 is for consumer devices, where a user starts profile downloads through a Local Profile Assistant. SGP.32 is for IoT, where a server-side eIM manages profiles across whole fleets with no user involved.
Is SGP.32 replacing SGP.22?
No. SGP.22 remains the consumer standard and is still being updated (v2.7 was published in April 2026). SGP.32 is the replacement for SGP.02 in IoT, and the better default for new headless devices.
Can an SGP.22 eSIM be upgraded to SGP.32?
Not over the air. It needs new hardware, or a removable SGP.32 card where the device has a SIM slot.
Do SGP.22 and SGP.32 use the same servers?
Both download profiles from an SM-DP+, which is why operators can support IoT eSIM without building a separate provisioning platform. SGP.32 adds the eIM on top.
What is the latest version of SGP.32?
SGP.32 v1.3, published in May 2026. Current test specifications apply to v1.2, so most certified products today reference v1.2.
Are eSIM routers SGP.22 or SGP.32?
Most eSIM routers on sale today use SGP.22 eUICCs managed through the maker’s own cloud platform. Native SGP.32 routers are starting to appear. Always ask which standard and version the eUICC is certified to.
Related reading
- SGP.32 vs SGP.22: the floLIVE case study
- SGP.32 explained: eIM, IPA and eUICC
- What is SGP.32?
- Future-proof IoT eSIM: what the eUICC can and can’t protect
- IPAe vs IPAd explained (sgp32.co.uk)
- Where SGP.32 moves lock-in (sgp32.co.uk)
Source for specification versions and dates: GSMA eSIM consumer and IoT specifications register.