eSIM technology has evolved through three GSMA standards, each designed to solve different problems as the market grew. Starting with early machine-to-machine devices and moving to today’s large-scale IoT deployments, SGP.02, SGP.22, and SGP.32, refined use case limitations of a prior standard or designed the implementation for a broader SIM use case.
If you’re working with IoT devices, knowing the differences between these standards matters. SGP.02, SGP.22, and SGP.32 were developed in dialogue with each other, building on the novelty and improving on the previous standard.
This guide explains how these standards evolved, informed by the limitations of the previous version, and how the newest version, SGP.32, fixes the IoT-specific limitations found in earlier ones.
Table of Contents
SGP.02 – eSIM for M2M
SGP.02 was the first implementation of the eUICC and remote SIM provisioning. Focused on M2M devices, the SGP.02 standard emerged from the needs of the automotive industry to remotely provision profiles on the SIM. Remote SIM provisioning remains the main point of focus for every subsequent eSIM standard.
Key components of SGP.02
The technical components introduced in SGP.02 that enable its then-novel functionalities are:
- SM-DP (Subscription Manager-Data Preparation): The SM-DP prepares the network profile for remote provisioning.
- SM-SR (Subscription Manager-Secure Routing): The SM-SR is the control center for profile management commands. It controls which profiles are active.
How RSP works in SGP.02
eSIM M2M works with a push mechanism, where the user proactively seeks out the device. The device is authenticated and the eSIM profile is then pushed on the device – all via SMS and the use of the SM-DP and SM-SR complex architecture.
Complex as it was, the novelty of SGP.02 lies in the fact that it was the first standard to allow users to change operator profiles remotely without swapping a physical SIM card. However, once the profile is pushed to the device, that’s pretty much the end of the flexibility SGP.02 allows.
SGP.02 Limitations – for consumers and IoT alike
eSIM M2M is vendor-locked
Each eSIM is bound to one SM-SR at manufacturing. This means that once a network profile is pushed to the device, there is little possibility to change it. As a result, companies deploying with eSIM M2M had to agree on network connectivity with their vendor of choice pre-deployment.
A connectivity vendor lock-in, whether in eSIM or otherwise, proves to be unsuitable for most IoT use cases, where scaled global operations are the norm.
eSIM M2M is SMS-based
Profile management in M2M requires SMS capabilities or TCP/IP to perform the basic functionalities of updating and managing profiles. However, SMS isn’t supported by all networks, which renders the SGP.02 standard implementation obsolete for devices operating with NB-IoT and LoRaWAN.
eSIM M2M is complex
The push model is limiting for several use cases beyond the original needs of the automotive use case. To change operators, the remote SIM provisioning of the eUICC must be integrated with every operator the user wants to get connectivity from. In technical terms, SM-SR needs to be configured at manufacturing and then integrated with the SM-DP. This integration process between components is highly complex, both technically and commercially.
While SGP.02 broke new ground in eSIM technology and pioneered remote SIM provisioning, time revealed its limitations and the industry was ready for expanded capabilities. Enter 2017 and SGP.22: the eSIM consumer standard.
SGP.22 – eSIM consumer
Enticed by the idea of remote SIM provisioning, SGP.22 was introduced in 2017 to cater to consumer devices like smartphones and wearables. SGP.22 enables remote SIM provisioning via a pull model.
The user/consumer personally interacts with the device via a user interface, usually a QR code scan with the phone camera that initiates the SIM profile switch. eSIM consumer differs from eSIM M2M in its client-driven methodology (pull instead of push) and in the streamlined technology, designed to avoid the technical and commercial integration complexities of SGP.02.
Key components of SGP.22
eSIM consumer consists primarily of an eUICC SIM and a Local Provisioning Assistant (LPA), either in the device or the eUICC.
- SM-DP+ (Subscription Manager-Data Preparation+): The SM-DP and SM-SR components of SGP.02 are combined into this single server in SGP.22 – a combination highlighted by the + sign.
- LPA (Local Profile Assistant): The LPA is software that runs on the device and allows users to download and manage the profiles.
- SM-DS (Subscription Manager-Discovery Server): The SM-DS provides the address of the SM-DP+ to the Local Discovery Services of the LPA and enables the pull function.
How RSP works for SGP.22
The users typically initiate the SIM profile swap themselves on the device via a user interface and the novel pull mechanism. With an interface-assisted action, users locate a network profile from the SM-DS, that acts as a central registry, and download the profile from the corresponding SM-DP+. In this process, users activate the LPA to inform the eSIM.
With the introduction of the simplified SM-DP+ architecture, the integration process became simpler compared to eSIM M2M and more flexible for users, as the SIM is no longer bound to a single SM-SR at manufacturing. Simply put, any SM-DP+ can work with any eUICC.
SGP.22 limitations for IoT
eSIM consumer is designed for accessible devices with a user interface
The name eSIM consumer gives away its limitations. A standard that works wonderfully for consumer use cases has limited applications in IoT use cases where the devices are often remote, inaccessible, usually lack a user interface, and come in fleets.
Even though SGP.22 is implemented today in many IoT use cases, the absence of a standardized platform for remote SIM provisioning at scale forces IoT managers to construct custom solutions for the LPA.
eSIM consumer uses heavy certificates
SGP.22 requires HTTPS over TCP – a heavy protocol that requires a lot of energy, rendering it suboptimal for low-power IoT devices.
Nevertheless, the pull model and the simplicity of SGP.22 were appealing to the IoT industry and revealed the need for these functions to be introduced and applied to the context of IoT. As such, the well-advocated-for SGP.32, or eSIM IoT, is a different flavor of the consumer eSIM, designed for an IoT-appropriate architecture that provides the same benefits as SGP.22.
SGP.32 – eSIM IoT
Nevertheless, the pull model and the simplicity of SGP.22 were appealing to the IoT industry and revealed the need for these functions to be introduced and applied to the context of IoT.
As such, the well-advocated-for SGP.32, or eSIM IoT, is a different flavor of the consumer eSIM, designed for an IoT-appropriate architecture that provides the same benefits as SGP.22.
Key components of SGP.32
SGP.32 builds upon proven elements of both the consumer and M2M specifications. The key key components introduced or reused in SGP.32 are:
- SM-DP+: The same component as in eSIM consumer, SM-DP+ is the combination of SM-DP and SM-SR from SGP.02 – a single server profile.
- eIM (eUICC IoT Manager): An architectural pillar of eSIM IoT, the eIM is the SIM control panel for IoT fleets. Via the eIM, users initiate the SIM profile changes remotely, making remote SIM provisioning suited for and possible at scale.
- IPA (IoT Profile Assistant): The IPA comes in the place of eSIM consumer’s LPA and can live in the device (IPAd) or the eUICC (IPAe).
- SM-DS: Identical to the SGP.22 architecture, the SM-DS, provides the address of the SM-DP+ to the IPA in this case and enables the pull function.
How RSP works for SGP.32
The eSIM IoT implementation combines the technical elements outlined in the SGP.32 standard to deliver the pull function of remote SIM provisioning at scale for the IoT use case. It uses the SGP.22 infrastructure and the SM-DP+ component and introduces the eIM, the control panel that communicates with the eUICCs under a single SKU and remotely triggers profile downloads and management without a device interface or contact with the device.
What’s new with SGP.32
The novelty of SGP.32 centers around alterations and updates to elements of the previous standards to optimize for IoT.
- Lightweight protocols
SGP.32 supports a wider range of protocols, such as CoAP (Constrained Application Protocol) as an alternative to HTTPS of SGP.22; and DTLS (Datagram Transport Layer Security) as an addition and alternative to TLS (Transport Layer Security) from SGP.02 and SGP.22. These protocols were introduced to address the IoT-specific limitations of heavy protocols designed for consumer devices in SGP.22. These protocols require less energy and data and establish a connection faster and with fewer interactions. - eIM: A new component for IoT
- Removes the limiting SMS function
As the SMS function of SGP.02 was not operative for all IoT connectivity like NB-IoT, the introduction of the eIM improves on this. The eIM architecture is compatible with all networks and can remotely trigger operator profile changes on SIMs regardless of the connectivity of the devices or the fleet. - Profile management from the device to the cloud/server
The eIM also addresses the SGP.22 IoT-specific limitation of requiring an interaction with the device to manage operator profiles. This interaction is now remotely centralized in the eIM, making remote profile management possible, even without a user interface on the device. - Zero touch provisioning
As the eIM is the centralized panel for all the SIMs, it enables users to manage SIM profiles in bulk. This is an improvement from SGP.22 where the profile swap is happening on a device level and requires custom solutions to scale profile management to several devices. - Configurability
In SGP.02, the SM-SR needs to be configured during the eUICC manufacturing thus leading to a connectivity vendor lock-in, i.e., the user is stuck with the operator they started with. In SGP.32 the eIM can be configurable, which means that the user can change the eIM or add a new eIM to swap operator profiles.
Limitations of SGP.32
It is critical to note that a configurable eIM is an optional feature per the technical specification. What this means is that there is a possibility of vendor lock-in even within the interoperable realm of SGP.32 if the eIM and SIMs are not configurable.
As a result, a configurable eIM should be scoped during the commercial discussions with the vendor to ensure that your implementation of SGP.32 is indeed as flexible and interoperable as the standard promises.
The cost of a non-configurable eIM in practice
A SIM supplier ships a batch of 20,000 eSIMs to a customer. This batch comes with a pre-configured eIM to get the connectivity started, as the standard requires. This preinstalled eIM offers a range of profiles to the customer but not every profile available. The customer deploys and can initially change among the selected profiles the preinstalled eIM offers.
Some time after deployment, the customer may find better pricing for another connectivity provider; they may experience service quality issues; they may simply want to download profiles that their preinstalled eIM does not support.
If this preinstalled eIM is not configurable, it means that the customer cannot add another eIM that supports a different range of profiles, without physically recalling the deployed devices. In few words, the customer is stuck with the first, preinstalled eIM and its range of profiles until the end of life of their fleet.
Read more: Why your first eIM might be your last
Wrapping up
SGP.02 laid the groundwork. SGP.22 simplified the architecture. SGP.32 combines the best of both and refines them for IoT. This isn’t a revolutionary new technology, but merely an evolution. SGP.32 takes the remote provisioning from SGP.02 and the pull model from SGP.22, then adapts both for modern IoT needs. As Saïd Gharout, Chair of the SGP.32 working group, points out to Onomondo, developers built the eSIM IoT specifications in direct conversation with the earlier standards; they kept what worked and fixed what didn’t.
Understanding all three standards helps you make better decisions. Look at your specific use case and ask: What new benefits does eSIM IoT bring? What do you already have in place? What’s missing? What new components do you actually need?
These questions matter because SGP.32 offers real advantages, but only if the implementation is tailored to your use case. Make sure to discuss eIM configurability with your vendor upfront. This feature determines whether you can switch providers later or get locked in. SGP.32 was designed to solve vendor lock-in problems – look for a commercial implementation that does exactly that.
