SGP.22 vs SGP.32: who activates

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.

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.

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.