SGP.32 v1.2 Is the Live Standard: What IoT Teams Need to Know
The GSMA specification that changes how IoT connectivity is managed at scale has reached its stable, commercially deployable version. Here is what that means in practice.
SGP.32 has been talked about in the IoT industry since the GSMA published v1.0 in May 2023. For most of the time since then, it has been a specification in progress – real, technically complete, but waiting on the downstream work that turns a document into something enterprises can actually deploy against: test specifications, conformance programmes, certification, and interoperability validation between different vendors’ components.
That period is now over. SGP.32 v1.2 is the current, stable, certifiable version of the specification. Certified eIM platforms, eUICC chips, and SM-DP+ servers are commercially available. Live production deployments are running. The question for IoT teams is no longer whether to take SGP.32 seriously – it is how quickly to get moving.
Why v1.2 is the version that matters
In GSMA specification terms, v1.2 is significant because it is the version against which formal certification is being issued. An eIM platform certified against v1.2, a module with a v1.2-certified eUICC, and a v1.2-compliant SM-DP+ from a third vendor can be expected to interoperate. That is the basic promise of a standardised ecosystem, and it is only now becoming reliably true for SGP.32.
Kigen announced the first market-ready eIM compliant with SGP.32 v1.2 in October 2024. Hardware from Quectel and Thales (Cinterion) has followed. On the network side, Telenor IoT began commercial delivery of SGP.32 SIM cards in April 2026, and KORE announced a joint SGP.32-compliant portfolio with Kigen the same month, with commercial availability planned for later in 2026.
The clearest commercial signal: Telenor IoT – with 30 million connected devices under management and customers including Volvo and Scania – is not running a pilot. It is shipping SGP.32 SIM cards commercially. When an operator at that scale commits, the standard has crossed a threshold.
What SGP.32 actually changes
The core problem SGP.32 solves is remote profile management on devices that have no user interface, limited connectivity, and no one standing next to them. Previous GSMA standards – SGP.02 for M2M and SGP.22 for consumer eSIM – both assumed conditions that most IoT devices cannot meet. SGP.02 locked enterprises to a single operator through SM-SR dependencies configured at manufacture. SGP.22 assumed a user was present to initiate every profile change, which is plainly useless for a sensor sealed into infrastructure for a ten-year deployment.
SGP.32 introduces a push-based architecture. The eIM – the server-side manager – pushes profile operations to devices rather than waiting for devices to initiate them. It specifies CoAP over UDP as a lightweight protocol path for NB-IoT and other constrained devices, making profile management viable on connections where a full HTTPS handshake would be impractical. And it removes the operator lock-in problem by allowing eIM associations to be established at any point in the device lifecycle, with genuine multi-operator flexibility across the device’s lifetime.
For a full technical breakdown of the v1.2 specification – including the architecture, component roles, protocol stack, and what the current commercial ecosystem looks like – the detailed guide is at SGP.32 v1.2: The Current Specification Explained on sgp32.co.uk.
Where the gaps still are
Cross-vendor interoperability – mixing eUICC, eIM, and SM-DP+ from different vendors – is still in early validation stages. Not every cellular module vendor has certified v1.2 hardware in production volumes yet. Enterprise tooling for integrating eIM management into existing device management workflows is still maturing. ABI Research’s earliest forecasts put 2.9 million SGP.32 profile downloads in 2025; the actual figure is lower, with the commercial acceleration now firmly pointing at H2 2026 and into 2027.
None of this changes the direction. It adjusts the timeline. For enterprises designing new IoT hardware or evaluating connectivity strategy for deployments that will be in the field for a decade, designing for SGP.32 readiness now is the correct posture regardless of whether you are deploying against v1.2 certified components on day one.
What to do with this
If your IoT connectivity strategy still treats eSIM as a nice-to-have rather than a design requirement, SGP.32 v1.2 is the prompt to revisit that. The question to ask your module vendor is not whether they support SGP.32 in principle – it is whether their product has v1.2 certification or a stated v1.2 certification roadmap. The question to ask a connectivity provider claiming SGP.32 support is which version of the specification, whether formal GSMA certification has been achieved, and what cross-vendor interoperability testing they have completed.
For background on what SGP.32 is and the full ecosystem picture, sgp32.co.uk is the UK reference site for the standard. The post on who went first with SGP.32 commercial deployments covers the competitive race among operators and platform providers in detail.
SGP.32 v1.2: The Current Specification Explained – architecture, protocol choices, commercial status, and what it means for OEMs, operators, and enterprise buyers.
What is SGP.32? – the full reference guide to the standard, from the background to the eIM and IPA components.