IoT eSIM SGP.32 Remote Provisioning and Constrained Device Rollouts

Definition: GSMA SGP.32 is the eSIM IoT technical specification for downloading, enabling, disabling and deleting operator profiles on IoT devices that have no screen or user, under the control of an eSIM IoT remote Manager (eIM).

If you are sourcing eSIM for meters, trackers, sensors or gateways that ship sealed and run unattended, SGP.32 is the specification to ask suppliers about. It replaces the person-driven consumer model (SGP.22) and the operator-pushed M2M model (SGP.02) with a fleet-managed one: an enterprise-controlled eIM tells the device which profile to fetch or switch to, and no one has to scan a QR code on site. What the specification does not do is give you commercial access to operators. Moving a fleet from one profile to another still depends on profile agreements, module firmware and on who runs the eIM.

Three eSIM models, three different buying questions

GSMA has published three remote SIM provisioning architectures over the years, and suppliers sometimes blur them in sales material. SGP.32 v1.0 appeared in 2023 and v1.1 in 2024; it implements the requirements GSMA set out in SGP.31 and reuses large parts of the consumer specification, including the SM-DP+ profile server and its security model. The practical differences look like this:

The components you will hear about

eIM: the fleet controller

The eSIM IoT remote Manager prepares signed eIM Packages. A package can carry Profile State Management Operations (enable, disable, delete a profile), eIM configuration changes, requests for eUICC data, or a trigger to download a new profile using an activation code. The eUICC verifies the signature before it executes anything, so whoever holds the eIM signing keys effectively controls the fleet. Toward the SM-DP+, the eIM takes the role that the LPA plays in a phone.

IPA: the on-device helper

The IoT Profile Assistant moves packages between the eIM and the eUICC. It can live in device or module firmware (IPAd) or inside the eUICC itself (IPAe). SGP.32 makes IPAe optional and leaves its implementation to the eUICC manufacturer. For a buyer this decides who must support the feature: with IPAd, your module vendor and firmware team; with IPAe, your eUICC supplier.

ESipa: the link that crosses the cellular network

ESipa can be bound to HTTP over TCP or to CoAP, and the specification requires TLS 1.2 or DTLS 1.2 as the floor. Packages reach the device in one of two ways. With eIM Package Retrieval the IPA polls the eIM for pending work; with eIM Package Injection the eIM sends it directly. Each side must support at least one mode, and both ends of a given link must use the same one. Devices that sleep for hours under power saving usually suit retrieval, because they check in when they wake rather than waiting to be reached.

Planning a constrained-device rollout

Most SGP.32 problems in the field are planning problems, not specification problems. Four topics deserve time before the first production batch.

First connectivity. A device can only talk to its eIM if it already has a working profile. That bootstrap profile is loaded at manufacture, so its coverage and commercial terms matter as much as anything you plan to download later.

Fallback. SGP.32 defines a Fallback Mechanism: a profile marked with the Fallback Attribute can be re-enabled by the eUICC if a newly enabled profile fails to attach. SGP.31 also describes a rollback mechanism. Test both in the lab with your real module. A profile switch that strands a device on a dead profile turns into a truck roll, and for remote meters or pipeline sensors one field visit can exceed the hardware cost.

Roaming policy. Switching to a local operator profile is one way to handle markets that restrict permanent roaming, but only where a local profile is actually available to your eUICC. Treat any country-by-country plan as something to confirm during project validation, not as a feature of the standard.

Staged switching. Move profiles in waves. Confirm attach, data sessions and application traffic on a small batch through your CMP before releasing the next group.

For the detailed difference between the rollback and fallback mechanisms, and the conditions under which the eUICC refuses each one, see SGP.32 eIM deployment: multi-carrier fallback and rollback.

Questions to put to every supplier

1. Which SGP.32 version do the eUICC, the IPA and the eIM implement, and have they been tested together?
2. Is the IPA in the module firmware or in the eUICC?
3. Who operates the eIM and holds its signing keys? The specification includes procedures to add, update and delete eIM configuration on the eUICC, so ask whether a change of eIM is contractually possible.
4. Which operators have agreed to issue profiles for this eUICC, in which countries, and on what terms?
5. Does the IPA use retrieval or injection, and how often does it poll? That figure feeds directly into battery and data budgets.
6. How will profile state appear in the CMP next to data usage and SIM status?

A supplier that answers the first three clearly is usually ready for a pilot. Compliance with the specification does not guarantee profile availability, coverage or operator authorization in a given market, and buyers should get those in writing separately.

How this maps to Quanqiu IoT

For pilots and single-region deployments on physical or soldered SIM, catalog pricing is usually enough: pick a Global IoT SIM plan and test. If the deciding factor is eSIM format versus removable SIM, start with the comparison of eSIM and physical SIM for IoT, and for factory and replacement logistics see eSIM versus physical SIM in OEM manufacturing.

SGP.32 programs are different. The eUICC type, IPA location, eIM ownership, target countries and device count all have to line up, and the answers change the commercial model. Lifecycle visibility through a CMP is covered in how CMP platforms manage global IoT SIM deployments, and this guide to catalog pricing versus project quotes explains where the line usually falls. When you have a module shortlist and a country list, request a project quote and we will work through eSIM scope and integration with you.

FAQ

Is SGP.32 the same as the consumer eSIM standard?

No. SGP.32 reuses the SGP.22 profile server (SM-DP+) and security framework, but replaces the user-operated LPA with an IoT Profile Assistant and puts profile decisions in the hands of an eIM controlled by the enterprise or its service provider.

Can existing SGP.02 M2M eSIM devices be upgraded to SGP.32?

Not by changing a setting. SGP.32 needs an eUICC and an IPA built for it. Ask the module and eUICC suppliers whether the specific part numbers in your bill of materials can support it, and plan for a hardware change if they cannot.

Does an NB-IoT or LTE-M device have enough bandwidth for profile downloads?

SGP.32 was written with network-constrained devices in mind, which is why ESipa can run over CoAP and DTLS. Download time and data cost still depend on profile size, radio conditions and the polling design, so measure them on your target network during the pilot.

Who should run the eIM?

It can be the OEM, the enterprise, or a connectivity provider. The right answer depends on who carries long-term responsibility for the fleet. Whoever runs it controls profile changes, so tie eIM operation and key custody to your contract and exit terms.

Does SGP.32 remove the need for physical SIM swaps entirely?

It removes the routine reason for them. A device can still need a site visit if both the new profile and the fallback profile cannot attach, which is why lab testing of fallback behavior is worth the effort.

Official References

• GSMA SGP.32 eSIM IoT Technical Specification v1.1
• GSMA SGP.32 eSIM IoT Technical Specification v1.0