What Is GSMA SGP.32? The Definitive Guide to the Next-Gen eSIM IoT Standard
12.03.2026 –
Knowledge Hub
Table of contents Introduction How does SGP.32 compare to SGP.02 and SGP.22? How SGP.32 Works: Key Components Explained IoT eSIM Architecture – SGP.32 Compliance & Standards: What You Need to Know Challenges & Implementation Considerations How emnify Supports SGP.32-Ready IoT Deployments Conclusion: Why SGP.32 Matters Introduction GSMA’s SGP.32 is the newest global SIM technology standard for IoT which finally makes remote profile management and profile switching a reality. It enables connected devices to securely download, manage, and switch SIM profiles over the air without requiring a user interface, QR codes, or physical SIM replacements. Unlike earlier GSMA standards designed for traditional machine-to-machine deployments, SGP.32 was defined specifically for modern IoT deployments, where physical SIM logistics and vendor lock-in have caused operational headaches for far too long. At its core, SGP.32 introduces a streamlined architecture that allows enterprises and connectivity providers to manage SIM profiles from any number of connectivity providers from one unified platform. At scale, this means, businesses are not locked into a single provider for their device’s full lifecycle and therefore are not burdened with costly SIM swaps when switching or adding new operators. Typical use cases for which this becomes extremely helpful to businesses deploying connected devices include: For manufacturers of connected devices (OEMs) that need devices to connect directly from the factory but don’t want the device to be locked to that specific network for their customers. Here SGP.32 enables that enables devices to be deployed with a bootstrap profile that gets the device online and SGP.32 enables any number of additional operator profiles to be added based on the device's deployment area. Providers of connected devices now have a built-in resiliency plan. In the past, if a business wanted to leave their connectivity provider it added complexity as it meant leaving their already deployed devices connected with their original operator (SIM swaps are too costly) and adding another provider for future deployments. This management of multiple operators added complexity and operational overheads. With GSP.32. For providers of connected devices, SGP.32 also integrates a level of resiliancy that wasn’t available before. The fact that it is now possible to have multiple profiles on a single SIM means that a true ‘fallback’ option is available. What this means in reality? If the primary profile fails, the device can simply be switched to the backup operator. Not only does this protect uptime, but it also protects operations from unexpected events such as, outages, the operator switching off coverage in your deployment zone or even if the operator goes out of business. How does SGP.32 compare to SGP.02 and SGP.22? SGP.02 SGP.02 was designed for traditional M2M deployments. In theory, it enabled remote profile to download and switching. In practice, however, the architecture was complex, costly to integrate, and not well suited to low-power or bandwidth-constrained IoT devices. For most deployments, large-scale remote profile swapping simply wasn’t commercially feasible. SGP.22 SGP.22 was built for consumer devices like smartphones and tablets. It assumes a user interface, QR code scanning, and user-driven profile downloads. That works perfectly for phones, but not for 'screenless’ devices. SGP.32 SGP.32 is the first standard designed specifically for IoT fleets. It removes the need for user interaction, supports constrained environments like NB-IoT and LTE-M, and enables fully server-orchestrated profile lifecycle management at scale. How SGP.32 Works: Key Components Explained eUICC (Embedded Universal Integrated Circuit Card) Although not new or specific to SGP.32, the eUICC is crucial to enable remote profile management. The eUICC is the secure chip inside the SIM that can store multiple operator profiles. SM-DP+ (Subscription Manager Data Preparation+) The SM-DP+ is the secure server where eSIM profiles are stored, prepared, and encrypted for download to devices. Each profile has a unique identifier called an activation code, which is what devices use to retrieve the profile. The QR code used in consumer eSIM downloads is simply a graphical representation of that activation code. SM-DS (Subscription Manager Discovery Server) The SM-DS is a discovery service that devices can query to check if new eSIM profiles are available. If a profile is ready, it tells the device which SM-DP+ server hosts it so the profile can be downloaded. While commonly used in consumer eSIM deployments, it is often optional in IoT architectures where the platform already orchestrates the profile download. EID (eUICC Identifier) The unique ID assigned to every eUICC. It’s how the SIM is securely identified during remote provisioning. eIM (eSIM IoT Manager) The control layer introduced with SGP.32. It lets you remotely download, enable, disable, delete, and switch profiles across devices and fleets. The eIM can be a standalone platform or part of a traditional CMP like it is for emnify. Connectivity Management Portal Not new but as the name implies this is where you manage connectivity such as, adding removing coverage zones and changing plans. It is in the CMP that the eIM can be integrated so that SGP.32 functionality such as, adding or removing profiles can be managed from the same interface. IPA (IoT Profile Assistant) The IoT-native replacement for the consumer LPA. It runs on the device and handles profile discovery and downloads without needing a screen or user input. Activation Code Are required to activate the SIM by inputting them into the CMP/eIM. Bootstrap Profile A minimal connectivity profile that gets the device online for the first time so it can download its operational profile. Operational Profile The main operator profile used during normal device operation. Multiple operational profiles can live on the same SIM. Fallback Profile A secondary operator profile stored on the same SIM that can be activated if the primary one fails, protecting uptime and continuity. Polling Interval Is the frequency a device tries to connect to the eIM to understand if there is a new profile. IoT eSIM Architecture – SGP.32 SGP.32 Remote Profile Management Flow Explained The device connects using its existing profile The device is already online, typically via a bootstrap or operational profile. A profile download is scheduled on the eIM An operator profile is registered on the eIM using its activation code, preparing it for download to the device. The device checks the eIM for pending operations At its polling interval, the device contacts the eIM and discovers that a new profile is available, including which SM-DP+ server hosts it and which activation code to use. The IPA prepares the device The IPA establishes the secure session required to download the profile. The profile is retrieved from the SM-DP+ The encrypted operator profile is securely delivered from the SM-DP+ to the device. The eUICC securely stores the new profile The profile is installed on the eUICC but not necessarily activated yet. Profile activation is scheduled on the eIM A user or automated process configures the new profile to be activated. The device activates the profile During the next polling cycle, the device learns about the activation instruction from the eIM and the IPA activates the profile on the eUICC. The device switches connectivity The device begins operating on the new operator profile without any physical SIM change. Compliance & Standards: What You Need to Know SGP.32 is not just a new orchestration model. It is a GSMA-defined standard built on strict security, interoperability, and transport requirements. These compliance elements are embedded directly into the specification and are critical for secure, large-scale IoT deployments. Security All profile lifecycle operations between the eIM and the eUICC are cryptographically authenticated and integrity-protected. This ensures profiles cannot be downloaded, modified, or switched without proper authorization. Transport Protocols SGP.32 supports standard TCP/IP communication as well as lightweight protocols such as CoAP over UDP with DTLS encryption. This allows it to operate efficiently across a wide range of IoT environments, including low-power and bandwidth-constrained networks like NB-IoT and LTE-M. Challenges & Implementation Considerations Evolving Ecosystem SGP.32 adoption is still in progress across vendors, platforms, and standards bodies. Interpretations and support may vary as the ecosystem matures. Platform Maturity Not all IoT platforms will initially provide full eIM functionality, IPA support, or large-scale orchestration tooling. The depth of implementation will differ between vendors. Open Ecosystem vs. Closed Implementations While SGP.32 technically enables multi-operator profile management, not every provider will support open third-party profile orchestration. Some implementations may limit profile management to their own network ecosystem. Enterprises evaluating SGP.32 solutions should carefully assess whether cross-operator flexibility is genuinely supported in practice, not just in theory. Backward Compatibility Migration from older standards such as SGP.02 or SGP.22 is not possible. How emnify Supports SGP.32-Ready IoT Deployments As SGP.32 moves from specification to real-world deployment, the key question is not just compliance. It is implementation. The standard enables multi-profile, multi-operator orchestration. But whether that flexibility is truly available in practice depends on the platform operating the eIM layer. emnify’s cloud-native architecture was built around centralized, API-driven profile lifecycle management. Through its integrated eIM capabilities, enterprises can download, enable, disable, and switch both emnify and third-party operator profiles across fleets from a single control plane. This approach aligns directly with the architectural intent of SGP.32: operator independence at the profile level, not just at the hardware level. Rather than binding deployments to a single network ecosystem, emnify enables organizations to design IoT architectures where connectivity can evolve over time, whether adding new operators, localizing in new regions, or introducing fallback profiles for resilience. In practice, this means SGP.32 is not just supported, it is operationalized in a way that preserves long-term flexibility. Check our unique SGP.32 offer, the emnify Advanced eSIM. Conclusion: Why SGP.32 Matters GSMA SGP.32 marks a structural shift in how IoT connectivity is designed and operated. It moves the industry beyond hardware-bound SIM logistics and toward software-driven profile orchestration built specifically for headless, large-scale device fleets. By enabling secure, server-orchestrated lifecycle management, SGP.32 allows enterprises to add, change, and manage operator profiles remotely without physical intervention. Devices can ship connected from the factory with a bootstrap profile, reducing the need for multiple regional SKUs and eliminating much of the traditional SIM logistics associated with global deployments. At the same time, SGP.32 introduces the possibility of true provider independence. Enterprises can localize connectivity as deployments expand into new regions, add new operators over time, and avoid being locked into a single connectivity provider for the lifetime of a device. It also strengthens operational resilience. With the ability to store and manage multiple profiles on a single eSIM, organizations can introduce fallback connectivity options that protect uptime and reduce the operational risk of network outages or coverage changes. For organizations building global IoT deployments, understanding SGP.32 is no longer optional. It is foundational to designing connectivity architectures that remain flexible, scalable, and commercially adaptable over the full device lifecycle.
