Last Updated: September 30, 2026 09:02 PM
GSMA SGP.32 is the technical specification for remotely provisioning and managing eSIM profiles on IoT devices, including devices with no screen or constrained network access. It standardizes how connectivity profiles are managed across IoT fleets without physically replacing SIM cards or asking a person to scan a QR code.
That answer is the short version. The more important question is why the IoT market needed another eSIM specification in the first place.
Connected products may stay in service for five, ten, or even fifteen years. During that time, coverage changes, carrier agreements expire, devices cross borders, and regulations evolve. A SIM strategy that looked sensible at launch can become an expensive constraint once thousands of devices are in the field.
SGP.32 is designed to give IoT manufacturers and fleet operators a more standardized way to adapt connectivity over the device lifecycle. But it is not a magic “connect to any network” button. Successful deployment still depends on compatible hardware, supported operator profiles, an eSIM management architecture, commercial agreements, security controls, and careful implementation.
Here is what SGP.32 does, how its architecture works, where the ecosystem currently stands, and what buyers should evaluate before putting it on an IoT roadmap.
SGP.32 is the GSMA’s eSIM IoT Technical Specification. First published in May 2023, it defines the detailed procedures and interfaces for remotely downloading and managing operator profiles on an eUICC in an IoT device. The GSMA has continued to update it as the ecosystem matures; the current published version is available on the GSMA eSIM specifications page.
The standard is intended for devices that may be user-interface-constrained, network-constrained, or both. Examples include smart meters, asset trackers, industrial sensors, medical devices, security systems, and other connected products that operate remotely with little or no human interaction.
SGP.32 does not stand alone. It implements the architecture defined by SGP.31, and a separate test and certification track supports both. Four document numbers are worth knowing:
When a vendor says it supports SGP.32, the useful follow-up is which versions of SGP.31, SGP.32, and SGP.33 it has actually tested against, and what has been certified under SGP.24.
The terms eSIM and eUICC are often used interchangeably, but they refer to different aspects of the technology.
If you want a deeper primer, read Kajeet’s guide to eSIM and eUICC technology.
The promise of RSP is straightforward: change connectivity without opening a device and replacing a physical SIM. The hard part is making that process work securely and consistently across large, unattended IoT fleets. That is the problem SGP.32 was created to address.
Before SGP.32, most eSIM deployments followed one of two GSMA models: SGP.02 for machine-to-machine deployments or SGP.22 for consumer devices.
SGP.02 established a server-driven model for remote provisioning in machine-to-machine deployments. It does not require a person to interact with the device, which made it suitable for connected cars and other high-value assets.
Its architecture, however, may require complex integrations among subscription management systems. It also often relies on SMS for management functions, which is not ideal for every low-power or resource-constrained IoT network. Moving a deployment between providers can create technical and commercial friction.
SGP.22 simplified eSIM provisioning for smartphones, tablets, and wearables. A consumer can scan a QR code or use a device interface to download a carrier profile from an SM-DP+ server.
That model works well when a person is holding the device. It is a poor match for a meter in a basement, a tracker inside a shipping container, or thousands of sensors with no screen or keyboard.
SGP.32 combines remote, server-initiated fleet management with infrastructure derived from the consumer eSIM ecosystem. It replaces the assumption that a person will initiate every profile download with components designed for automated IoT operations, and it adds transport options suited to constrained networks.
Four components are central to understanding SGP.32, with a fifth that appears in some deployment models.
The eUICC securely stores operator profiles and executes authorized profile-management operations. It is the trust anchor inside the device.
The Subscription Manager Data Preparation Plus, or SM-DP+, securely prepares and delivers operator profiles. SGP.32 reuses SM-DP+ infrastructure from the consumer eSIM architecture, which can reduce the need for entirely new profile-delivery systems.
The eIM provides the remote orchestration layer. It can instruct an IoT device or an entire fleet to perform profile actions such as downloading, enabling, disabling, or deleting a profile, using signed instructions that the eUICC can verify.
The eIM does not eliminate the need for supported profiles or provider agreements. It standardizes how authorized profile-management instructions are delivered and managed.
The IPA carries out the device-side work. It communicates with the eIM, the eUICC, and the SM-DP+ as required to execute authorized profile operations. It can be implemented in two ways:
That choice affects device firmware, processing requirements, certification, update strategy, and who owns each part of the integration. It is one of the most consequential architectural decisions in an SGP.32 design and is often made by the module vendor rather than the device maker.
SGP.32 also accommodates discovery-server flows. Where an SM-DS is used, the IPA can discover that a profile download is pending rather than relying solely on a direct instruction from the eIM. Whether that path is used depends on the deployment model and the platforms involved.
Communication between the eIM and the IPA is not tied to a single transport. The specification accommodates HTTPS, CoAP over UDP with DTLS security, and SMS so that an implementation can suit the device and the network rather than the reverse. The lightweight options matter for devices on NB-IoT or LTE-M, where bandwidth, power, memory, or session availability may be limited.
| Standard | Published | Provisioning model | Key components | User interaction | Typical devices |
|---|---|---|---|---|---|
| SGP.02 (M2M) | 2013 | Server-driven | SM-DP, SM-SR, eUICC | Not required | Connected vehicles and M2M |
| SGP.22 (Consumer) | 2016 | User-initiated | SM-DP+, SM-DS, LPA, eUICC | Usually required | Smartphones, tablets, and wearables |
| SGP.32 (IoT) | May 2023 | Remotely orchestrated | SM-DP+, eIM, IPA, eUICC (SM-DS optional) | Not required | Headless, constrained, remotely managed IoT |
The standards are not simply newer editions of the same architecture. An existing SGP.02 or SGP.22 deployment does not automatically become SGP.32-compatible through a software setting. Migration depends on the eUICC, device or module, firmware, management platform, operator profiles, and commercial model.
Organizations can coordinate profile actions across device groups without sending technicians to replace SIMs physically. This can reduce truck rolls, manual handling, and the operational risk of managing dispersed assets.
When compatible profiles and agreements are available, SGP.32 can make it easier to change connectivity providers after deployment. That can help organizations respond to coverage gaps, contract changes, permanent-roaming restrictions, or new market requirements.
Because no user interaction is required, SGP.32 suits devices that have no screen, no keyboard, and no one nearby. Its architecture and transport options are designed around limited interfaces, power, bandwidth, memory, and processing capacity.
Device manufacturers may be able to produce fewer regional hardware variants and provision appropriate connectivity profiles later in the supply chain or after deployment. The often-discussed “single global SKU” is possible only when radio bands, certifications, profiles, regulations, and commercial agreements also support it.
By defining standardized roles for the eIM, IPA, eUICC, SM-DP+, and SGP. 32, SGP.32 is intended to reduce dependence on proprietary point-to-point integrations. Implementation choices still matter: a poorly designed commercial model can move lock-in from the carrier to a platform provider rather than eliminate it.
SGP.32 is a remote provisioning standard. It does not, by itself, guarantee:
This distinction matters. Remote profile management, multi-IMSI roaming, network steering, multi-core resilience, and automatic failover can all contribute to a connectivity strategy, but they are not the same capability.
The specification is published, the test specification exists, and certification runs through the GSMA compliance process. What varies is commercial readiness across the pieces an actual deployment needs:
For most organizations, the realistic near-term question is not whether to adopt SGP.32 instead of their current model, but how to keep future SGP.32 options open while deploying on something available today.
Trackers may cross carrier and national boundaries for years. SGP.32 can support remote profile changes when coverage, cost, or local connectivity requirements change.
Meters are often difficult to access and remain deployed for long periods. Remote profile management can reduce the need for site visits when connectivity requirements evolve.
Sensors, controllers, and remote monitoring equipment may operate in harsh or inaccessible environments. SGP.32 can help manufacturers and operators plan connectivity changes without physical SIM replacement.
Connected medical and remote-patient-monitoring devices require carefully governed connectivity. SGP.32 can provide another lifecycle management option, but device certification, security, privacy, and service continuity requirements remain critical.
Digital signage, kiosks, cameras, alarms, and other distributed devices may outlive the original carrier contract. Remote profile management can make long-term connectivity planning more flexible across a large site footprint.
If you are weighing these scenarios against your current setup, Kajeet’s multi-network IoT connectivity team can walk you through the trade-offs.
Ask providers and device partners these questions before treating “SGP.32-ready” as a buying criterion:
SGP.32 is on the Kajeet roadmap. Kajeet is building SGP.32 capabilities into Kajeet SmartSIM and is working through the same ecosystem dependencies described above: eUICC and module support, eIM architecture, and operator profile availability. Because that work is still in progress, this article is a guide to the standard rather than an availability announcement — Kajeet can share current status and expected timing directly.
Today, Kajeet SmartSIM provides managed, multi-network IoT connectivity with centralized visibility and control through the Kajeet Sentinel® platform. Kajeet’s SGP.32 development is intended to extend that managed-connectivity foundation as the eSIM IoT ecosystem, device support, and operator-profile availability mature.
Organizations evaluating SGP.32 should discuss their device architecture, deployment regions, carrier requirements, lifecycle, and timeline with Kajeet. Those details determine whether an existing connectivity model, a staged migration plan, or a future SGP.32 implementation is the right approach.
Talk to Kajeet about your IoT connectivity requirements.
SGP.31 defines the architecture and requirements for eSIM IoT. SGP.32 provides the detailed technical specification for implementing that architecture. SGP.33 is the related test specification.
No. eSIM is the broader technology for digitally provisioning operator profiles on an eUICC. SGP.32 is a specific GSMA technical specification designed for remote eSIM management in IoT devices.
The eIM is the eSIM IoT Remote Manager that orchestrates profile-management instructions. The IPA is the IoT Profile Assistant that executes the device-side portion of those instructions and coordinates with the eUICC and SM-DP+.
IPAd runs the IoT Profile Assistant in the device; IPAe runs it inside the eUICC. The choice affects firmware responsibility, processing requirements, certification scope, and how updates are delivered, so it is worth confirming early with your module vendor.
Yes. SGP.32 is designed for user-interface-constrained devices and does not require a person to scan a QR code or use a device settings screen for every profile operation.
Not by itself. SGP.32 standardizes remote operator-profile management. Automatic network selection, failover, policy logic, and service continuity depend on the broader connectivity solution, device, profiles, and implementation.
Possibly, but migration is not automatic. Compatibility depends on the deployed eUICC, module, firmware, operator profiles, management systems, and provider roadmap. Some fleets may require hardware changes.
SGP.41 addresses provisioning profiles during manufacturing rather than over-the-air after deployment. The two are complementary: in-factory provisioning can simplify how a device leaves the production line, while SGP.32 governs how profiles are managed once it is in the field.
The specification, test specification, and certification process are published and in use. Practical readiness depends on your specific eUICC and module support, eIM platform, and — most often the limiting factor — which operator profiles you can commercially obtain in your target markets.
No. Kajeet is developing SGP.32 capabilities for SmartSIM, but they are not currently commercially available. Availability, compatibility, and migration details should be confirmed directly with Kajeet as development progresses.
.png)
