Learn
SGP.32 vs SGP.22 vs SGP.02: the three eSIM specifications compared
SGP.32 vs SGP.22 vs SGP.02 side by side: target devices, architecture, who triggers downloads, push vs pull, compatibility and when to use each.
By SimCheck.ai team · Updated · 8 min read
SGP.02, SGP.22 and SGP.32 are the GSMA’s three eSIM remote provisioning specifications, and they differ mainly in who controls the profile. In SGP.02 (M2M), an operator-run SM-SR pushes profiles to the device. In SGP.22 (consumer), the user pulls a profile onto a phone through the LPA. In SGP.32 (IoT), a remote manager called the eIM tells unattended devices which profile to pull from the same SM-DP+ servers that SGP.22 uses. For new IoT products SGP.32 is the default choice, SGP.22 remains right for anything with a user, and SGP.02 lives on mainly in installed fleets.
The rest of this page compares the three side by side, explains the differences that matter in practice, and covers what to plan for when migrating.
Side-by-side comparison
| SGP.02 (M2M) | SGP.22 (Consumer) | SGP.32 (IoT) | |
|---|---|---|---|
| Target devices | M2M modules, early connected cars, meters | Phones, tablets, laptops, wearables | Headless and network-constrained IoT: meters, trackers, sensors, gateways |
| First published | December 2013 | January 2016 | May 2023 |
| Requirements document | SGP.01 | SGP.21 | SGP.31 |
| Remote management entity | SM-SR, usually tied to one operator | None; the user is in control | eIM, run by any party (OEM, enterprise, MVNO, vendor) |
| Profile server | SM-DP | SM-DP+ | SM-DP+ (same role as SGP.22) |
| Discovery server | None | SM-DS | SM-DS (optional) |
| On-device agent | None; the SM-SR talks to the eUICC over the air | LPA in the device or eUICC | IPA in the device (IPAd) or eUICC (IPAe) |
| Who triggers a download | Operator, through its SM-SR | End user (QR code, activation code, carrier app) | eIM, or the IPA for a pre-configured default SM-DP+ |
| Push or pull | Push from SM-SR to eUICC | Pull by the device | Pull from the SM-DP+; eIM commands either polled by the device or pushed by the eIM |
| Transport to the device | SMS, CAT_TP, SMS-triggered HTTPS | HTTPS over IP | HTTPS, CoAP/DTLS, or the device’s own protocol (e.g. LwM2M, MQTT) |
| User interaction | None | Required (user confirms the download) | None |
| Switching operator | “SM-SR change” between platforms | User downloads another profile | eIM triggers a download from the new operator’s SM-DP+ |
| Changing the manager | SM-SR change procedure | Not applicable | eIM configuration operations (add, update, delete eIM) |
| Compatibility | Standalone | Not compatible with SGP.02 | Not compatible with SGP.02; reuses SGP.22 SM-DP+, authentication and profile format |
| Functional test specification | SGP.11 | SGP.23 | SGP.33-1, -2, -3 |
Sources: SGP.02 v4.0, SGP.31 v1.0, SGP.32 v1.2, GSMA eSIM specifications.
SGP.02: operator-driven push for M2M
SGP.02 splits the server side into two roles. The SM-DP prepares and encrypts the profile. The SM-SR holds the secure channel keys to the eUICC’s root security domain and routes the profile to the chip. Communication with the device runs over SMS, CAT_TP or HTTPS sessions that are woken up by SMS, so the SM-SR can push to a device at any time, provided SMS works.
This model is robust for a single-operator deployment. It becomes painful when the device needs a different operator: control of the eUICC must move from one SM-SR to another through an “SM-SR change”, which needs both platform operators to cooperate. In practice, many SGP.02 fleets stayed with the operator whose SM-SR they started on.
SGP.22: user-driven pull for consumer devices
SGP.22 removes the SM-SR. The device’s Local Profile Assistant connects to the operator’s SM-DP+, the eUICC and SM-DP+ authenticate each other with GSMA-issued certificates, and the profile is downloaded over HTTPS, encrypted end to end for that eUICC. The trigger is a person: they scan an activation code or use a carrier app, and the LPA asks them to confirm. The user also decides when to enable, disable or delete profiles.
That design gives open, operator-neutral provisioning for phones. It does not fit an unattended device, because nothing in the standard allows a remote party to manage the profiles on behalf of a user who does not exist.
SGP.32: managed pull for IoT
SGP.32 keeps the SGP.22 SM-DP+ and its security model and adds a remote manager, the eIM. The eIM sends signed instructions to the device’s IoT Profile Assistant: download this profile, enable that one, delete the old one. The eUICC verifies the eIM’s signature and a replay counter before acting, and returns a signed result.
Because the eIM is not tied to an operator, the party that owns the device (an OEM, an enterprise, an MVNO or a connectivity provider) can choose and change operators by handing the eIM a new activation code. The eIM-to-device link can use HTTPS, CoAP over DTLS for constrained devices, or ride on a protocol the device already uses. For a full walkthrough, see What is SGP.32?.
The four differences that matter most
Who is in control
The operator controls an SGP.02 device. The user controls an SGP.22 device. Whoever operates the associated eIM controls an SGP.32 device. That shift is the commercial point of SGP.32: profile choice moves from the network owner to the device owner.
Push vs pull
SGP.02 is push: the SM-SR initiates. SGP.22 is pull: the device initiates. SGP.32 is mostly pull with an optional push. The profile is always fetched from the SM-DP+ in an SGP.22-style session, but the eIM’s instructions can reach the device in two ways. In eIM Package Retrieval the device polls the eIM, for example on a timer or after a wake-up message. In eIM Package Injection the eIM sends the package directly when the device is reachable. SGP.32 leaves the wake-up mechanism to the implementation, which is one of the first things to check in a real deployment.
Which servers you need
| Deployment | Servers required |
|---|---|
| SGP.02 | SM-DP and SM-SR per operator, plus SM-SR change agreements |
| SGP.22 | Operator’s SM-DP+; SM-DS optional |
| SGP.32 | Operator’s SM-DP+; one eIM for your fleet; SM-DS optional |
For operators, SGP.32 is mostly reuse: an SM-DP+ that already serves phones can serve IoT devices. For device owners, the new component to select is the eIM. See What is an eIM? for how to evaluate one.
How commands are secured and confirmed
In SGP.02, commands reach the eUICC through a secure channel whose keys the SM-SR holds, so trust is placed in whoever operates that server. In SGP.22, the user’s confirmation on the device is the authorisation, and profile changes are local actions. In SGP.32, every remote command is an eUICC Package signed by the eIM and checked against a replay counter, and the eUICC answers with a result it signs itself. That gives the device owner cryptographic confirmation that an operation really happened on the chip, which matters when thousands of unattended devices are switched at once and nobody can look at a screen to check. It also means the IPA in the device is only a messenger: it cannot alter the commands it carries.
Which specification should you use?
| Your situation | Recommended specification | Why |
|---|---|---|
| New device with a screen and a user (phone, tablet, laptop, smartwatch) | SGP.22 | User consent and control are built in |
| New unattended IoT device (meter, tracker, sensor, gateway) | SGP.32 | Remote, operator-neutral management without a user |
| NB-IoT or LTE-M device with limited bandwidth or no TCP | SGP.32 | CoAP/DTLS transport, indirect download and asynchronous operation |
| Existing SGP.02 fleet with years of service life left | Keep SGP.02; plan SGP.32 for the next hardware revision | SGP.02 eUICCs cannot be managed by an eIM |
| Single-operator, single-country deployment with no plan to switch | Any; SGP.32 for future flexibility | Lock-in costs only appear when you need to switch |
| Mixed fleet (consumer-style devices plus headless devices) | Both SGP.22 and SGP.32 | Same SM-DP+ infrastructure supports both |
Migration considerations
Moving a product line from SGP.02, or from an improvised SGP.22 setup, to SGP.32 touches hardware, software and contracts.
- The eUICC must be an SGP.32 product. The eIM association, signed eUICC Packages and IPA services live in the eUICC operating system. Some vendors offer eUICCs that support more than one specification, so check the product’s declared GSMA compliance rather than its marketing name.
- Decide where the IPA runs. An IPA in the device or module needs firmware support; an IPA in the eUICC needs the device to support the right SIM toolkit commands. See IPAd vs IPAe.
- Choose the eIM and plan its association. The eUICC is usually associated with an eIM at manufacturing or on first boot. Make sure the eUICC and eIM support adding and deleting eIMs later, so you can change providers without recalling devices.
- Confirm operator support per market. Each target operator needs to issue profiles from an SM-DP+ and accept your device in its eligibility checks. Profiles that existed only on an SGP.02 SM-DP may need to be re-created.
- Plan initial connectivity. The device needs a working bootstrap profile or initial operational profile that can reach the eIM and SM-DP+ in every country where it might be switched on.
- Expect a mixed fleet. SGP.02 devices in the field will usually stay on SGP.02 until they are replaced, so back-office systems need to handle both models for years.
What this means for testing
Each specification fails in different places. SGP.02 problems tend to sit in SMS delivery and SM-SR routing. SGP.22 problems tend to sit in activation codes, SM-DP+ reachability and user flows. SGP.32 adds new failure points: eIM association, package delivery to sleeping devices, signature and counter checks, the switch from bootstrap to operational profile, rollback, and then the familiar network attach and data path for the new profile. A migration is not finished until the new chain has been proven on live networks in every target market. Our SGP.32 testing guide lists the checks in order.
SimCheck.ai installs profiles on real modems either through SGP.32 via a cloud eIM or through an SGP.22-style LPA, chosen per modem, so both models can be validated with the same attach, data and SMS tests. Learn more on the eSIM testing page.