What Is SGP.22?
A Practical Guide for Industrial IoT Deployments
As more IoT devices ship with embedded eUICCs, teams are evaluating how different eSIM standards affect activation, provisioning, and long-term scalability. One of the most referenced specifications is SGP.22, the consumer eSIM architecture used by smartphones, wearables, tablets, laptops, and certain categories of IoT devices.
While SGP.22 was designed for the consumer world, it increasingly intersects with IoT deployments as industrial hardware adopts eSIM-ready chipsets that support the same workflows. For teams building connected products at scale, understanding how SGP.22 compares to IoT-specific provisioning standards is essential.
What SGP.22 Means
SGP.22 is the GSMA’s consumer Remote SIM Provisioning specification. It describes the workflow for downloading, installing, enabling, disabling, and deleting eSIM profiles using the SM-DP+ architecture.
The specification outlines:
- How devices communicate with the SM-DP+
- How activation codes trigger profile downloads
- How secure channels are established with the eUICC
- How multiple profiles are stored and managed
- How devices initiate carrier switching
SGP.22 is a device-driven process. A user or technician must trigger the activation either through a QR code, an activation string, or a carrier or OEM app. This works well for consumer devices and IoT hardware with a user interface.
How SGP.22 Works on Smartphones and Consumer Devices
In phones, tablets, and laptops, SGP.22 supports the familiar eSIM experience.
Typical steps include:
- The user scans a QR code, enters an activation code, or opens a carrier app.
- The device contacts the SM-DP+ server referenced in the activation data.
- A secure channel is established with the eUICC.
- The profile is downloaded and installed.
- The new profile becomes active and the device connects to the selected network.
This workflow provides a standardized and user-friendly provisioning model that many IoT OEMs leverage when their devices include a screen or OS-level components capable of the same interaction.
Where SGP.22 Makes Sense in IoT
Consumer-style provisioning can be highly effective for IoT when the device can display activation steps or run OS components that interact with an SM-DP+.
Examples include:
- Payment terminals and kiosks
- Connected handhelds and industrial tablets
- Smart meters or industrial devices with embedded screens
- Diagnostic equipment or portable devices used in the field
- Any IoT hardware where technicians complete activation on-site

In these scenarios, SGP.22 helps reduce manufacturing steps and gives field technicians more flexibility, especially when deploying across multiple regions or carriers.
Limitations of SGP.22 for Industrial IoT
Key limitations that matter for industrial environments:
- Devices must be able to initiate provisioning
- An initial WAN connection (not from the SIM card itself) is required before downloading the primary profile
- A user or technician must trigger the workflow
- Device firmware must support SGP.22 provisioning
For fully headless or remotely deployed devices, operator-controlled provisioning is a better fit. These deployments typically use the M2M or IoT RSP architecture instead.
SGP.22 Compared to SGP.02 and SGP.32
Consumer eSIM provisioning differs significantly from the IoT standards. The chart below summarizes the distinctions.
eSIM Specification Comparison
| Feature | SGP.22 | SGP.02 (M2M) | SGP.32 (IoT) |
| Designed For | Consumer devices and interactive IoT | Traditional M2M | Modern IoT at global scale |
| Provisioning Model | User-initiated | Operator-initiated | Operator-initiated with simpler architecture |
| Device Integration | Requires a UI or technician | Headless | Headless |
| Activation | QR code, activation code, app | SM-SR controlled | Streamlined SM-DP+ and SM-DS |
| Scalability | Moderate | High | Very high |
The right standard depends on whether the device can start the activation and whether the deployment requires automated, large-scale provisioning.
Why SGP.22 Matters for Industrial IoT
SGP.22 is becoming more relevant as IoT hardware evolves. Many modern modules now support both consumer and IoT provisioning workflows, giving manufacturers more flexibility in how devices are shipped and activated.
Benefits for IoT teams include:
- Less manufacturing complexity because profiles do not need to be preloaded
- Easier localization when devices are deployed in multiple regions
- Simplified activation for devices that move between carriers or ownership
- Support for mixed fleets where some devices have screens and others do not
- Alignment with the provisioning model used across major mobile OEM ecosystems
For IoT devices with a user interface or technician workflow, SGP.22 can significantly simplify deployment.
When SGP.22 Is Not the Right Fit
SGP.22 should be avoided when:
- Devices are fully remote or inaccessible
- No display or input method exists
- Provisioning must be automated at scale
- Bootstrap connectivity cannot reliably reach the SM-DP+
- Operator-controlled profile swaps are required across a fleet
In these environments, SGP.02 or SGP.32 are the appropriate standards for IoT.
What This Means for Solve Customers
Choosing the right provisioning model affects how reliably devices come online and how easily you can scale deployments across regions and carriers. Solve helps teams understand which eSIM architecture aligns with their hardware, manufacturing workflow, and long-term connectivity strategy.
To explore how SGP.22, SGP.02, and SGP.32 fit into your project, learn more about:
- Solve eSIM Support
- Multi-Network SIMs
- Our Connectivity Management Platform
- Industrial IoT Connectivity Trends
Bottom Line
SGP.22 plays an important role in the eSIM ecosystem, especially for IoT devices that benefit from user-driven activation. But it is not a universal solution. Matching the right provisioning standard to the right device architecture is what keeps deployments online, manageable, and scalable.
Solve helps teams navigate these standards so every device activates reliably, switches cleanly, and stays connected throughout its lifecycle. Whether you are evaluating SGP.22, SGP.02, or SGP.32, our goal is the same: simplify the complexity behind IoT connectivity so your fleet performs the way it should in the field.