eSIM standards SGP.02, SGP.22 and SGP.32

An eSIM lets a device take a new operator profile over the air. The GSMA has written three sets of rules for how that happens. Each was designed for a different kind of device, and they differ in one main way: who decides when the profile changes.

SGP.02 for machines

The first standard, SGP.02, was written for machines that nobody is standing next to, such as meters and car systems. A central server pushes profiles to the SIM and switches between them. The device does not need to take part beyond passing the messages on.

This suits devices with no screen and no user. The drawback is that the SIM is tied to one management server at a time. Moving it to another server needs the current one to cooperate, so the choice of provider matters.

SGP.22 for phones and tablets

SGP.22 is the system most people meet on a phone. The device pulls the profile itself. Software on the phone reads an activation code, often from a QR code, fetches the profile and asks the user to confirm. The user is in control.

That works well when a person is holding the device. It needs software on the device and someone to confirm each change, which a sensor in a field cannot do.

SGP.32 for IoT

SGP.32 is the newer standard for IoT devices. The GSMA published version 1.0 on 26 May 2023. It keeps the profile servers from SGP.22 and adds a remote manager, which can change profiles on one device or a whole fleet without anyone touching them. A small piece of software in the device or on the SIM carries out the changes. It was designed for devices with little or no user interface, and for low-power networks where data rates are low and devices sleep for long periods.

What this means when you choose

Ask which standard the SIMs and your devices support. Ask who controls profile changes: you, your connectivity provider or the SIM maker. And ask whether you could move that control to someone else later. With SGP.32, the device may need software for it too, unless the SIM carries that software itself, so check this early in the design. The eSIM, eUICC and MFF2 article explains the terms used here.

Three architectures

The GSMA publishes each remote SIM provisioning architecture as a pair: an architecture and requirements document, and a technical specification that implements it.

SGP.32 is at v1.0.1 (4 July 2023) and v1.1 (26 April 2024), both expired, and v1.2 (27 June 2024) and v1.3 (22 May 2026), both current, so ask for v1.2 or later. The first certified IoT eUICC came in April 2025 (G+D, 29 April 2025), and the first eUICC certified with an eIM in August 2025 (IDEMIA, 18 August 2025). All three architectures manage the same kind of chip, the eUICC, described in eSIM, eUICC and MFF2. They differ in who starts a profile change and which components take part.

SGP.02, the push model

SGP.01 was written for devices that are not easy to reach for provisioning. It uses two servers, and reaches the eUICC over SMS or HTTPS.

• SM-DP (Subscription Manager Data Preparation) prepares and encrypts the operator’s profile for a specific eUICC.
• SM-SR (Subscription Manager Secure Routing) is the only entity allowed to open a secure channel to the eUICC’s platform (SGP.01 SMSR1). It delivers profiles, and enables, disables and deletes them under the operator’s policy rules (SMSR2).

Every operation starts at the server side and is pushed over the air to the eUICC. The device only provides the transport. SGP.01 sets out to have minimal impact on the device and places no new certification requirement on it (DEV1 to DEV3). Only one profile is enabled at a time, and a Fall-Back Mechanism re-enables a designated profile if the enabled one loses network connectivity.

Only one SM-SR can be associated with an eUICC at a time (SMSR4). It can be changed, but the change procedure has the current SM-SR hand the eUICC’s data to the new one, so it depends on the incumbent’s cooperation. This is where lock-in arises with SGP.02.

SGP.22, the pull model

SGP.21 and SGP.22 were written for devices with a user, such as phones, tablets and watches. The device starts each change.

• SM-DP+ combines profile preparation and delivery, and talks to the device directly.
• SM-DS (Discovery Server) holds event records that tell a device a profile is waiting for it.
• LPA (Local Profile Assistant), in the device (LPAd) or the eUICC (LPAe), downloads profiles, queries the SM-DS and provides the user interface.

The user starts a download with an activation code, often a QR code, or through discovery from the SM-DS. SGP.21 requires Simple Confirmation by the end user for a profile download, and at least User Intent for local operations such as enable, disable and delete. That model does not suit a device with no screen, no user and a constrained link.

SGP.32, the IoT model

SGP.31 and SGP.32 reuse the SM-DP+, SM-DS and profile format from the consumer system and add two components.

• eIM (eSIM IoT Remote Manager) performs Profile State Management Operations (enable, disable, delete) on one device or a fleet (SGP.31 4.2.1). It can be a stand-alone server or part of a device management platform.
• IPA (IoT Profile Assistant) is the device-side agent, in the device (IPAd) or in the eUICC (IPAe). Only one is active per eUICC at a time. The IPA talks to the eIM over the ESipa interface. An IPAe means the device needs little or no provisioning code of its own.

The eIM signs its operations and the eUICC verifies them end to end (the ESep interface), so the IPA cannot alter them. Profiles can be downloaded directly by the IPA from the SM-DP+, or indirectly with the eIM fetching the profile and passing it on. A Rollback Mechanism re-enables the previous profile if the device cannot reach the eIM after a switch.

The architecture is designed for constrained devices. SGP.31’s basic principles call for provisioning to work without SMS and without TCP, over CoAP (for example LwM2M), including over non-IP data delivery, and to tolerate devices that are unreachable for long periods in PSM or eDRX.

Control follows the eIM. Once an eIM is associated with an eUICC, the eUICC accepts further configuration changes only when signed by that eIM, and adding another eIM is the responsibility of the one already associated (SGP.31 EUICCF5).

What is the difference between SGP.22 and SGP.32?

Choosing between them

• Check the whole chain. An eUICC, device and server must all support the same specification. An eUICC built only for SGP.02 cannot be managed by an eIM, and an SGP.32 deployment with an IPAd needs that agent in the module or application firmware.
• Ask who holds control. With SGP.02 it is whoever runs the SM-SR. With SGP.32 it is whoever runs the associated eIM. Ask whether you can run your own eIM, or move the association to another one, before you commit.
• Plan for the sleeping device. Under any of the three, a profile change happens only when the device is reachable. Allow for PSM and eDRX cycles in rollout plans.
• A profile change is a change of operator. Each profile brings its own operator’s networks and agreements, and a new profile may also need new APN settings. See roaming and steering for what then decides the network a device uses.