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:

1. The user scans a QR code, enters an activation code, or opens a carrier app.
2. The device contacts the SM-DP+ server referenced in the activation data.
3. A secure channel is established with the eUICC.
4. The profile is downloaded and installed.
5. 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.

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.