What is SGP.32? The GSMA eSIM IoT standard explained

SGP.32 is the GSMA’s eSIM IoT Technical Specification: it defines how IoT devices with no screen or user, such as meters, trackers, sensors and industrial gateways, download, switch and manage mobile operator profiles over the air. It replaces the operator-controlled push model of the older M2M standard (SGP.02) with a new remote manager, the eIM, while reusing the SM-DP+ servers built for consumer eSIM (SGP.22). The result is a single, interoperable way to change an IoT device’s connectivity provider without touching the device.

This guide explains why SGP.32 exists, how its architecture works, what happens step by step during a profile download, how the versions evolved, and what adoption looks like in 2026.

Why SGP.32 exists

Before SGP.32, IoT manufacturers had two imperfect options.

The limits of SGP.02 (M2M eSIM)

SGP.02, first released in December 2013, was built for machine-to-machine devices. Profiles are pushed to the eUICC by an SM-SR (Subscription Manager Secure Routing) server that holds the keys to the chip and is typically run by, or on behalf of, a single operator. Transport relies on SMS, CAT_TP or SMS-triggered HTTPS sessions. Moving a device to a different operator’s platform requires an “SM-SR change” between two server operators, which in practice meant bilateral integration projects and a high degree of lock-in.

The limits of SGP.22 (consumer eSIM)

SGP.22 solved interoperability for phones, tablets and wearables with a common SM-DP+ infrastructure, but it assumes a person is present. The LPA on the device asks the user to scan an activation code and confirm the download. An unattended device in a smart meter cabinet or a shipping container has nobody to tap “Install”, and SGP.22 has no standard entity for managing thousands of devices remotely.

What SGP.31 asked for

The GSMA captured IoT requirements first in SGP.31, the eSIM IoT Architecture and Requirements (v1.0, April 2022). It targets network-constrained devices (low bandwidth, possibly no TCP or even IP) and user-interface-constrained devices. Among its basic principles: provisioning must be possible without SMS, without connection-oriented protocols, over lightweight CoAP-based protocols such as LwM2M, and asynchronously for devices that sleep for long periods in PSM or eDRX. SGP.32 is the technical specification that implements those requirements.

SGP.32 architecture

SGP.32 keeps most of the consumer remote SIM provisioning (RSP) architecture and adds two IoT-specific elements: the eIM and the IoT Profile Assistant (IPA).

Entity	Role in SGP.32	Inherited from
eUICC	Secure element that stores profiles, verifies eIM signatures and executes commands	SGP.22 (with IoT extensions)
IPA	Device-side agent that talks to the eIM and SM-DP+ and passes commands to the eUICC. Lives in the device (IPAd) or inside the eUICC (IPAe)	New; equivalent of the LPA
eIM (eSIM IoT remote Manager)	Server that decides which profile each device downloads, enables, disables or deletes, and signs those commands	New
SM-DP+	Operator’s server that prepares, encrypts and delivers profiles	SGP.22, unchanged in role
SM-DS	Optional discovery server that tells a device or eIM a profile is waiting	SGP.22
Operator	Orders profiles from the SM-DP+ and issues activation codes	SGP.22

The specification defines the interfaces between these entities. The ones that matter most in practice are:

Interface	Between	Purpose
ESipa	eIM and IPA	Delivers eIM Packages (download triggers, signed commands) and returns results
ESep	eIM and eUICC	Logical end-to-end link for signed eUICC Packages (state changes, eIM configuration)
ES9+	IPA and SM-DP+	Profile download when the device connects to the SM-DP+ directly
ES9+’	eIM and SM-DP+	Profile download when the eIM acts as a proxy for the device
ES10a / ES10b	IPA and eUICC	Local commands: get eUICC info, load packages, install profiles
ES8+	SM-DP+ and eUICC	End-to-end encrypted channel that protects the profile itself
ES11 / ES11’	IPA or eIM and SM-DS	Retrieve event records for pending downloads

Source: SGP.32 v1.2, section 2.3.

Two design choices stand out. First, the profile is always protected end to end between the SM-DP+ and the eUICC over ES8+, so neither the eIM nor the IPA can read it. Second, ESipa is transport-agnostic: the specification suggests HTTPS over TCP for devices that can afford it and CoAP over UDP with DTLS for constrained devices, and it also allows ESipa messages to ride inside an existing device protocol. Informative annexes map ESipa onto LwM2M (an “eSIM IoT” object, ID 3443, is registered in the OMA LwM2M registry) and onto MQTT.

How an SGP.32 profile download works, step by step

Here is the typical flow for moving a device onto a new operator profile, simplified from sections 3.1 to 3.4 of SGP.32 v1.2:

1. The operator prepares the profile. The operator orders a profile on its SM-DP+ (over ES2+) and receives an activation code that encodes the SM-DP+ address and a matching ID.
2. The device owner hands the activation code to the eIM. The eIM builds an eIM Package containing a profile download trigger for the target device, identified by its EID, and queues it.
3. The IPA collects the package. Using its current connectivity, often a bootstrap profile, the IPA either polls the eIM (“eIM Package Retrieval”) or the eIM pushes the package to it (“eIM Package Injection”). How the device is woken up to poll is left to the implementation.
4. The eUICC and SM-DP+ authenticate each other. This step reuses the SGP.22 common mutual authentication procedure, so the SM-DP+ treats the IoT device much like a phone.
5. The SM-DP+ checks eligibility and delivers the Bound Profile Package. The package is encrypted for that specific eUICC. It travels either directly from the SM-DP+ to the IPA or through the eIM acting as a proxy.
6. The eUICC installs the profile and generates notifications, which the IPA forwards to the SM-DP+ and to the eIM.
7. The eIM sends a signed command to enable the profile. This is an eUICC Package containing an “enable” Profile State Management Operation (PSMO). The eUICC checks the eIM’s signature and a replay-protection counter before acting.
8. The device switches and reconnects. The eUICC enables the new profile, the device re-attaches to the network, and the IPA returns a signed eUICC Package Result to the eIM. If the new profile cannot reach the eIM and the eIM granted rollback in the enable command, the IPA can roll back to the previous profile.

Step 8 is where most real-world problems surface: the profile installed correctly, but the device cannot register on the network, the APN is wrong, or the new operator does not allow the visited network.

Three ways to point the device at an SM-DP+

SGP.32 supports three options for locating the profile:

• Activation code, parsed by either the eIM or the IPA.
• SM-DS event, retrieved by the IPA (ES11) or by the eIM on the device’s behalf (ES11’).
• Default SM-DP+, an address pre-configured in the eUICC, optionally combined with “immediate enabling” so the profile is enabled right after download.

Direct vs indirect download

In a direct download the IPA opens its own TLS session to the SM-DP+ over ES9+. In an indirect download the IPA talks only to the eIM, and the eIM relays the SM-DP+ exchange over ES9+’. Indirect download suits devices that cannot run a full HTTPS/TLS stack to an arbitrary server, for example an NB-IoT device using CoAP. The IPA advertises which options it supports in its IPA Capabilities, and the eIM advertises its own support in its configuration data.

Managing profiles after download

The eIM’s signed eUICC Packages carry two kinds of operations:

• PSMOs (Profile State Management Operations): enable, disable, delete, list profile info, get the Rules Authorisation Table, configure immediate enable, set or unset the fallback attribute, and set the default SM-DP+ address.
• eCOs (eIM Configuration Operations): add, update, delete or list the eIMs associated with the eUICC.

Two safety nets protect devices from being stranded:

• Rollback. An enable command can grant permission to roll back. If the newly enabled profile fails to provide connectivity, the IPA asks the eUICC to re-enable the previous profile.
• Fallback. Since version 1.1, an eIM can mark one profile with a Fallback Attribute. If the device loses connectivity, the IPA can trigger the Fallback Mechanism to switch to that profile. Support for this is optional on the eUICC.

Version 1.1 also added handling for an Emergency Profile used for eCall in vehicles.

SGP.32 versions and timeline

Date	Milestone
Dec 2013	SGP.02 v1.0, the M2M eSIM architecture
Apr 2022	SGP.31 v1.0: eSIM IoT architecture and requirements
May 2023	SGP.32 v1.0: first eSIM IoT technical specification
Apr 2024	SGP.32 v1.1: Profile Fallback Mechanism, eCall Emergency Profile, JSON binding for ESipa, eIM TLS certificate profile
Jun 2024	SGP.32 v1.2: consolidation and corrections; the baseline for certification
Jan 2025	SGP.33 v1.2 test specifications: SGP.33-1 (IoT eUICC), SGP.33-2 (IPA), SGP.33-3 (eIM)
Apr 2025	First GSMA-certified SGP.32 IoT eUICC (Giesecke+Devrient)
Feb–Apr 2026	Commercial SGP.32 SIMs, e.g. Telenor IoT orderable in February, shipping from April
May 2026	SGP.32 v1.3 published alongside SGP.31 v1.3

Certification uses three tracks, listed in the GSMA’s eSIM certification applicability annex. IoT eUICCs are tested against SGP.33-1 and need eUICC Security Assurance (eSA). eIMs demonstrate functional compliance with third-party test tools. IoT device (IPA) certification through GCF was still listed as “ongoing” in the February 2026 revision of that annex.

SGP.32 adoption in 2026

By late 2026 SGP.32 has moved from pilot to early commercial deployment:

• eUICCs certified against SGP.32 v1.2 have been available since 2025, and connectivity providers have started shipping commercial SGP.32 SIMs.
• Modules are gaining built-in IPA support. For example, SIMCom announced in March 2025 that its LTE Cat 1 bis modules were being prepared with SGP.32 firmware.
• eIMs are offered as cloud services by eUICC vendors and connectivity providers, and the specification also allows device owners to run their own.
• Forecasts remain steep: a Kaleido Intelligence forecast reported by RCR Wireless put SGP.32 profile downloads at about 2.89 million in 2025, rising to about 194 million in 2029.

What lags behind is cross-vendor proof. Many eUICC, IPA, eIM and SM-DP+ combinations have never been run together on a live network, and optional features such as fallback, indirect download or CoAP transport may be supported by one side and not the other.

Benefits and challenges

Benefits	Challenges
One device SKU for global markets; the operator profile is chosen after manufacture	Device and module support is still uneven; IPA certification is newer than eUICC certification
Operator switching without SM-SR integration projects	Interoperability depends on matching optional features across eUICC, IPA and eIM
Reuses existing SM-DP+ infrastructure, so any operator with an SGP.22 SM-DP+ can supply profiles	Not backward compatible with SGP.02 eUICCs already in the field
Works over constrained transports (CoAP/DTLS, LwM2M, MQTT)	Large profile downloads over NB-IoT can be slow and sensitive to coverage
Signed, replay-protected commands; profiles encrypted end to end	Operator acceptance of a profile on a given device and roaming network still has to be verified per market

What this means for testing

SGP.32 conformance proves each component follows the specification. It does not prove that your device, with your eUICC, your eIM and your operator’s profile, will attach and pass traffic in Brazil, Germany or Indonesia. Field validation should cover the full chain: eIM association, profile download through the eIM, enable and rollback, network attach on the target radio technology (LTE-M or NB-IoT), and an application-level data round trip, repeated for every target market. Our guide on how to test SGP.32 devices turns that into a step-by-step plan.

SimCheck.ai runs these checks on real cellular modems with real eSIM profiles on live networks. Profiles can be installed through SGP.32 via a cloud eIM, then verified with attach, data and MQTT tests on LTE-M, NB-IoT or LTE. To see how this works for IoT eSIM programmes, visit SGP.32 IoT eSIM testing.