# SGP.22 vs SGP.32: who activates

SGP.22 is the consumer eSIM specification: a person activates a profile on a device with a screen. SGP.32 is the IoT specification: an eSIM IoT manager in the backend activates profiles across a fleet with no person at the device. SGP.02 is the earlier M2M generation, and its hardware cannot move to SGP.32 over the air.

- SGP.22 (v3.0, 19 October 2022) is the consumer specification; SGP.32 (v1.2, 27 June 2024) is the IoT specification.

- SGP.22 uses an SM-DP+ and an SM-DS with a local profile assistant; SGP.32 adds an eIM and an IoT profile assistant on top of the SM-DP+.

- SGP.02 is the earlier M2M generation; installed SGP.02 hardware cannot become SGP.32 over the air.

- Every first profile needs a bootstrap connection or local connectivity.

## The person at the device decides the specification

The difference between SGP.22 and SGP.32 is not the radio or the SIM shape. It is who is present when a profile is activated. SGP.22 assumes a user with a screen who can scan a code, read a prompt and confirm a download. SGP.32 assumes a fleet manager in a backend who activates a device that has no screen and no one standing next to it.
That assumption decides the architecture, the failure path and the team that operates it. A consumer device needs an activation flow a person can finish. An unattended fleet needs a management system that can select, download, enable, suspend and retire profiles without sending anyone to the site.

### Two tracks through activation

Both tracks end with an enabled profile. The difference is who starts the download and who can fix it.

Alt: Two four-step tracks. Consumer: order, scan the QR code, download the profile, enable it on the device. IoT: order, the eIM selects a profile, download, no person at the device.

The consumer track runs order, QR scan, profile download and enable, with the user confirming on the device. The IoT track runs order, eIM selection, profile download and completion with no person at the device. The consumer track assumes someone can retry a failed scan. The IoT track assumes the eIM and the device can recover without a visit.

| Item | Value | Note |
| --- | --- | --- |
| SGP.22 (consumer) · 1 | Order |  |
| SGP.22 (consumer) · 2 | Scan the QR code |  |
| SGP.22 (consumer) · 3 | Profile downloads |  |
| SGP.22 (consumer) · 4 | Enable on the device |  |
| SGP.32 (IoT) · 1 | Order |  |
| SGP.32 (IoT) · 2 | eIM selects a profile |  |
| SGP.32 (IoT) · 3 | Profile downloads |  |
| SGP.32 (IoT) · 4 | No person at the device |  |

Source: GSMA SGP.22 v3.0 and SGP.32 v1.2 (https://www.gsma.com/solutions-and-impact/technologies/esim/gsma_resources/sgp-32-v1-2/)

## SGP.22 in one minute

An operator or profile provider prepares a profile on an SM-DP+, and a discovery server, the SM-DS, can tell the device that a profile is available. A local profile assistant on the device downloads the profile, installs it and enables it after the user consents. The trigger is usually a QR code, an activation code or an app. The flow assumes an app store, a settings menu and a user who can troubleshoot a failed download.

## SGP.32 in one minute

An eSIM IoT manager, the eIM, sits in the enterprise or provider backend and orchestrates profile downloads, swaps and deletions across a fleet, working with an SM-DP+ that prepares the profile and an optional SM-DS. An IoT profile assistant, the IPA, runs on the device or the eUICC and executes the commands. The device needs some connectivity for its first profile: a bootstrap profile, a local network or another temporary path. The model is built for scale, for hardware that is already installed and for changes that must not wait for a site visit.

### Three generations, three activation models

|  | SGP.02 | SGP.22 | SGP.32 |
| --- | --- | --- | --- |
| Who starts activation | The operator's M2M platform | The user, with a code or an app | The eIM in the backend |
| Backend component | A subscription manager with secure routing | An SM-DP+ and an optional SM-DS | An eIM plus an SM-DP+ (and optional SM-DS) |
| Device side | An M2M eUICC | A local profile assistant | An IoT profile assistant (IPA) |
| Typical device | Installed M2M equipment | Phone, tablet, laptop, travel eSIM | Tracker, meter, sensor fleet |
| Upgrade path | Hardware replacement | Profile download or device change | Profile download; module and eUICC must support it |

A device implements one flow. The module, the eUICC and the management platform have to agree.

## What changed from SGP.02

SGP.02 was the M2M remote provisioning specification. It used a subscription manager with a secure routing role between the profile provider and the device, before the consumer eSIM ecosystem matured. SGP.32 separates the orchestration from the operator: the eIM selects and manages profiles, the IPA executes on the device, and the download uses standard IP connectivity. The result is fewer operator-specific parts and a management model that fits an enterprise fleet.
SGP.02 estates were often built around operator-specific platforms. SGP.32 puts orchestration in the enterprise or the connectivity provider, which makes multi-operator fleets easier to manage but makes the choice of eIM and profile owner more important. Ask who runs the eIM, who holds the profile inventory and how the handover works at the end of the contract.

## Migration is a hardware plan

Installed SGP.02 devices do not migrate with a software flag. The eUICC, the module and the management platform all have to support SGP.32, so the move happens when the hardware is replaced. Plan the estate in two groups: devices that will reach end of life on SGP.02, and devices whose replacement can carry the new flow.
For the second group, test the new flow before the first replacement ships. Confirm the bootstrap path, the eIM handover and the profile inventory. Keep the old platform able to read the installed base until the last device is gone, because a mixed estate needs two records that reconcile.

## The profile has a life

A profile is ordered, downloaded, installed, enabled, used, suspended, swapped and deleted. Each step needs an owner and a record. The order ties the profile to an EID and an ICCID. The download needs connectivity and a trigger. The enable step makes the profile active and disables the previous one. The swap repeats download and enable for a new profile. The delete removes the profile from the eUICC and frees the space.
Record the EID, the ICCID and the IMSI at every step. The EID identifies the chip, the ICCID identifies the profile and the IMSI identifies the subscription the network authenticates. Without that record, a swap becomes a guess about which profile sits on which device. Test the full cycle, including a failed download and a rollback, before you scale.

### What to check before you buy

- [ ] The module and the eUICC are certified for the specification, not only described as eSIM-capable.
- [ ] How the first profile arrives, and what happens if the bootstrap connection fails.
- [ ] Who runs the eIM, and whether you can use your own.
- [ ] Who owns the profiles, and what the exit terms are.
- [ ] How a swap is triggered, how long it takes and what the device does during the change.
- [ ] How much profile memory the eUICC has, and how often the fleet will swap.

Ask for test evidence in the markets you will launch, on the real firmware.

### Check what you learned

**A tracker has no screen and must be provisioned from the office. Which specification fits?**

SGP.32, if the module and eUICC support it and an eIM manages the fleet. SGP.22 assumes a person at the device.

**Can SGP.02 hardware be upgraded to SGP.32 over the air?**

No. The device and the eUICC have to support the newer specification, so migration follows the hardware cycle.

**What does a profile download need before it can start?**

A bootstrap profile, a local network or another temporary connection, plus a trigger from the user or the eIM.

## FAQ

**Can a phone use SGP.32?**

Phones follow SGP.22. SGP.32 targets fleets without screens or hands at the device.

**Do we need new hardware for SGP.32?**

SGP.32-capable modules and eUICCs, yes. Anything installed has to be assessed module by module.

**Is SGP.32 backwards compatible with SGP.22?**

No, not as a drop-in replacement. SGP.32 reuses the SGP.22 SM-DP+ and profile format, but replaces the user-driven LPA flow with the eIM and IPA. A device implements one flow, and the management platform has to match it.

**What is an eIM?**

The eSIM IoT manager: the backend component that orchestrates profile downloads, swaps and deletions for an IoT fleet under SGP.32.

**Can we switch providers later?**

It depends on who owns the profiles and what the eUICC policy allows. Ask for the exit terms and a tested migration path before you sign.

## Sources

- [GSMA SGP.22 v3.0: Remote SIM Provisioning for consumer devices](https://www.gsma.com/solutions-and-impact/technologies/esim/gsma_resources/sgp-22-v3-0/) — Accessed: 2026-10-19
- [GSMA SGP.32 v1.2: eSIM IoT remote provisioning and management](https://www.gsma.com/solutions-and-impact/technologies/esim/gsma_resources/sgp-32-v1-2/) — Accessed: 2026-10-19
- [GSMA eSIM specifications: the SGP.02, SGP.22 and SGP.32 family](https://www.gsma.com/solutions-and-impact/technologies/esim/) — Accessed: 2026-10-19

Updated: 2026-10-19