How SGP.32 enables remote profile management
The architecture introduces two important components: the eIM (eSIM IoT Remote Manager), which provides the remote management capability, and the IPA (IoT Profile Assistant), which enables communication between the eUICC and the wider remote provisioning infrastructure. Together, they allow profiles to be downloaded and their state to be managed remotely, including enabling, disabling and deleting profiles.
SGP.32 works alongside SGP.31. SGP.31 defines the architecture and requirements for the GSMA’s IoT eSIM model, while SGP.32 defines the technical specification used to implement it. The current SGP.31 and SGP.32 specifications are both version 1.3, dated 22 May 2026 and published on the GSMA website on 28 May 2026.
For IoT businesses, the significance is straightforward: connectivity can be provisioned and changed after a device has been manufactured, shipped and deployed, without depending on a person being physically present with the device.
This page looks at how SGP.32 works, what the specification standardises, what remains the responsibility of device manufacturers and connectivity providers, and what suppliers really mean when they claim to support SGP.32.
Why SGP.32 exists
The GSMA has defined three eSIM architectures, each designed for a different deployment model. SGP.02 and SGP.22 each depend on a resource that may not be available across an IoT estate.
- SGP.02for machine-to-machine estates: the operator’s subscription manager pushes the profile to the SIM, and the trigger travels as an SMS
- SGP.22for consumer devices: the standard profile download begins when a person scans a QR code or enters an activation code, after which the device’s Local Profile Assistant retrieves the profile
- SGP.32for IoT: a server, the eIM, triggers the operation, and the device’s IPA carries it out over an IP connection
A constrained sensor with no usable interface, limited communications capacity and no planned site visit may not be able to rely on either a person at the device or SMS delivery. SGP.32 removes the need for both from the remote-provisioning process.
The five components, and who runs each
An SGP.32 deployment has five components. A buyer specifying one should be able to name the organisation responsible for each. These definitions match five of the six terms defined in our blog on eSIM management and rSIM resilience, which adds a sixth entry for eSIM itself. The first FAQ below covers that distinction.
The IPA can be implemented in the device (IPAd) or within the eUICC (IPAe), and the GSMA compliance process assesses the two separately.
How a profile operation reaches the device
The eIM can initiate four profile operations: downloading a new profile, or enabling, disabling or deleting a profile that is already installed. It can also retrieve information about which profiles are present and which one is enabled.
For a change to an installed profile, the eIM prepares a signed eUICC Package. The IPA transfers that package to the eUICC over an IP connection and returns the result. The eUICC verifies the eIM’s signature before it executes anything inside, and rejects a package it cannot match to an eIM it recognises.
A download follows a different path. The eIM sends the IPA an activation code, and the profile then arrives in one of two ways: a direct download from the operator’s SM-DP+ server, or an indirect download with the eIM acting as a proxy. Either way the sequence needs no person at the device and no SMS.
The specification does not mandate a protocol between the eIM and the IPA. It requires integrity and confidentiality from whatever protocol is used, and suggests HTTP secured with TLS where TCP is available, or the constrained application protocol, CoAP, secured with DTLS for network-constrained devices. This transport flexibility supports implementations over constrained cellular technologies such as NB-IoT and LTE-M, where sessions may be short and bandwidth or data usage tightly controlled.
What SGP.32 leaves to the buyer
SGP.32 provides the architecture for remote profile provisioning and management. A complete deployment must also address three wider areas: operator and subscription management, local connectivity and roaming requirements, and continuity when the active network becomes unavailable.
SGP.32 does not choose the operator or create the subscription. The eIM triggers the download of a profile that exists because an operator has issued it under a commercial agreement. The rate plan, the access point name, the activation and the invoice belong to the operator or the connectivity provider. An eIM operation completed without the corresponding subscription action may therefore leave a profile enabled but unable to pass traffic as intended.
SGP.32 does not make a roaming fleet compliant with local requirements. It can enable a local profile once one has been provisioned to the eUICC. Whether a local profile is required in a given market, which operator may supply it and on what terms remains a regulatory and commercial question.
SGP.32 does not, by itself, keep a device connected when its active network becomes unavailable. It manages profiles over a working communications path. Where the loss of the active network also stops the device reaching the eIM, the eIM cannot use that path to instruct a change of profile.
Since v1.2 the specification has defined an optional Fallback Mechanism, in which the IPA may enable a designated fallback profile when the device detects a permanent loss of connectivity. The detection logic and the timing are left to the device maker, and the eUICC need not support the function. rSIM® technology holds two distinct multi-network roaming profiles and places the connectivity test and profile-selection decision in SIM-resident logic. If the active path remains unavailable under the configured switching policy, that logic can select the alternative profile already present on the SIM without requiring the eIM or remote management platform to reach the device at that moment.
What supplier claims mean
Suppliers may use three different terms when describing support for SGP.32. Buyers should establish precisely what each term means and what evidence supports it.
Under the GSMA compliance process, SGP.24, the IoT eUICC, the IoT device with an IPA and the eIM are separate product types. Each can receive a GSMA Compliance Confirmation, and only the eUICC becomes eligible for a certificate under the GSMA’s public key infrastructure. Any compliance or certification claim must therefore identify the product type it covers rather than being applied to the SGP.32 deployment as a whole.
How CSL applies SGP.32
CSL Group supplies managed IoT connectivity that can bring together SIMs or eSIMs, equipment, private routing, monitoring and support according to the requirements of the deployment. Within this service, the CSL IoTM platform provides the management and orchestration layer across supported mobile operator portals, connectivity management platforms and remote SIM provisioning systems, while rSIM provides local, SIM-level resilience. The platform prepares, manages and governs connectivity across the life of the estate. rSIM acts locally during a connectivity incident, using profiles and switching policies already present on the SIM.
Of the three terms above, aligned is the one that applies. rSIM technology and the eSIM management capabilities of the CSL IoTM platform are built to the SGP.32 architecture. Certification under SGP.24 is held by individual eUICC, IPA and eIM products, so CSL identifies those products and their evidence for the deployment in question.
SGP.32 FAQs
These are the questions buyers ask most often when SGP.32 appears on a datasheet or in a tender. Our blog on eSIM management and rSIM resilience covers eIM portability, including what a change of eIM provider depends on.
Is SGP.32 the same as eSIM?
No. eSIM commonly refers to the technology that allows operator profiles to be downloaded and managed on an eUICC, although the term is also often used for a soldered SIM form factor. The eUICC is the secure hardware and software that stores and manages those profiles. SGP.32 is the GSMA specification for remotely provisioning and managing an eUICC in an IoT device. A device can contain an eUICC without supporting SGP.32.
What is the difference between SGP.32 and SGP.22?
Does SGP.32 replace SGP.02?
What are the eIM and the IPA?
Which version of SGP.32 is current?
Do existing IoT devices support SGP.32?
Is SGP.32 mandatory for IoT devices?
Is SGP.32 certified, and is CSL certified against it?
Does SGP.32 make a device resilient to a network outage?
Where can I find the relevant GSMA sources?
The Latest Industry News: Network Changes
