SGP.32 v1.3: What Changed, and Why You Should Still Design Against v1.2

On 28 May 2026 the GSMA published SGP.32 v1.3, alongside a matching SGP.31 v1.3 architecture update and, the day before, an updated eUICC PKI Certificate Policy v2.3. If you track the IoT eSIM standard closely, that raises an obvious question: what changed, and does it affect what you should be building and buying? The short and practical answer is that v1.3 is a refinement of the standard, not a reset, and for now it should not change your certification plans. Here is what we can determine from the specification itself, and what it means in practice.

The short version

SGP.32 v1.3 is a maintenance and refinement release. It realigns the IoT eSIM specification to the latest companion documents, tightens several existing mechanisms, and formalises some behaviour that earlier versions left ambiguous. Importantly, formal GSMA certification is still issued against v1.2, which remains the version to design hardware around and to certify against today. Treat v1.3 as the direction of travel rather than the version your procurement questions should reference, at least until test specifications and certification catch up. For the version you should still be working to, see our guide to the current SGP.32 v1.2 specification.

Where v1.3 sits in the version history

Version numbers in GSMA specifications move in a deliberate cadence, because a published spec is only the starting point for test specification work, conformance programmes and interoperability testing before it becomes something you can certify against.

v1.3 did not arrive on its own. The GSMA published SGP.31 v1.3, the architecture and requirements document that sits above SGP.32, on the same day. That pairing matters, because the two are meant to move together.

What v1.3 realigns

The clearest structural change in v1.3 is in its references. The specification now points to SGP.31 v1.3 for architecture and to SGP.22 v2.7 as its consumer RSP baseline. Because SGP.32 deliberately reuses large parts of the consumer eSIM standard (the SM-DP+, the profile package format, much of the security model), pulling the reference up to SGP.22 v2.7 keeps the IoT specification in step with the wider eSIM ecosystem rather than drifting from it. Alongside this, the refreshed eUICC PKI Certificate Policy v2.3 points to continued tightening of the certificate and trust framework that underpins the whole system. If you want the background on how these pieces fit together, our architecture guide covers the eIM, IPA, eUICC and SM-DP+ relationship.

A concrete change: Emergency Profile handling

One specific, verifiable change in v1.3 concerns Emergency Profiles, the profiles associated with eCall and emergency connectivity. The v1.3 text notes that implementations built to versions prior to v1.3 could reject the download of an Emergency Profile, treating the emergency indicator in the profile metadata as a metadata mismatch. v1.3 formalises the correct handling of these profiles instead, and the specification carries a full set of emergency-related functions and error states around enabling, disabling and protecting the emergency mechanism.

For most telemetry and monitoring deployments this is academic. For automotive and any safety-related use case where eCall or a guaranteed emergency connection matters, it is exactly the kind of detail that separates a specification that works on paper from one that works in a vehicle. It is also a good illustration of what a point release like v1.3 is for: closing the gaps that only show up once people start building against the standard in earnest.

Where v1.3 focuses

Beyond that, v1.3 is best understood as consolidating and tightening the mechanisms that make SGP.32 workable at fleet scale. The areas the specification gives detailed attention to include:

• Fallback and rollback. A fallback profile can be enabled automatically if a device suffers a permanent loss of connectivity, and a freshly enabled profile can be rolled back if it fails to connect. This is the safety net that makes remote profile switching survivable on a device you cannot physically reach.
• Immediate profile enabling. A device can download from a default SM-DP+ and enable the new profile immediately, provided the eUICC is configured to allow it, which streamlines zero-touch bootstrap.
• Multi-eIM portability. The rules for associating, updating, listing and removing multiple eIMs on one eUICC, with association tokens for replay protection, remain central to avoiding lock-in across a device’s life.
• Transport and security options. TLS 1.2 and DTLS 1.2 remain the baseline, with TLS 1.3 and DTLS 1.3 permitted, Server Name Indication supported for eIM certificate selection, and DTLS Connection ID available for reliability on constrained links. The security model is unchanged in principle but refined in detail.
• Real-world transport mappings. The specification includes informative mappings showing how its procedures run over LwM2M and MQTT, which is useful if you are folding eSIM management into an existing device-management stack rather than building from scratch.

A fair caveat: the GSMA has not published a plain-English changelog for v1.3, and the definitive line-by-line delta lives in the specification’s own document history. Expect vendor documentation and analysis to catch up over the coming months rather than overnight, so some of the finer detail on exactly what moved between v1.2 and v1.3 will firm up as the ecosystem digests it.

Why you should still design and certify against v1.2

This is the part that matters for anyone making decisions now. Formal GSMA certification for eUICC chips, eIM platforms and SM-DP+ servers is still issued against v1.2. That makes v1.2 the version that guarantees interoperability between certified components and the version enterprises can design against with confidence. A hardware design or an eIM selection made against v1.2 today is production-grade; one made against an uncertified reading of v1.3 is not.

So the sensible posture is unchanged from our July market round-up: specify v1.2-certified components, ask vendors which version they are certified against rather than merely compatible with, and treat v1.3 as the roadmap. The thing to watch is the test specification and certification framework catching up to v1.3, because that, not the publication date, is the moment v1.3 becomes the version to build to. Our hardware guide and the questions to ask your eSIM provider both cover how to pin a vendor down on exactly this.

Frequently asked questions

Is SGP.32 v1.3 the current version?

v1.3 is the latest published version of the SGP.32 specification, released on 28 May 2026. However, formal GSMA certification is still issued against v1.2, so v1.2 remains the version to design and certify against in practice.

Should I certify my hardware against v1.2 or v1.3?

Against v1.2. Certification for eUICC, eIM and SM-DP+ components is issued against v1.2, and that is what guarantees interoperability today. Treat v1.3 as the direction of travel and watch for the certification framework to catch up before building to it.

What actually changed in SGP.32 v1.3?

v1.3 realigns SGP.32 to the newer SGP.31 v1.3 architecture and SGP.22 v2.7 baseline, refines mechanisms such as fallback, rollback and immediate enabling, and formalises handling of Emergency Profiles that earlier versions could reject. The GSMA has not published a plain-English changelog, so finer detail will surface as vendor documentation catches up.

Written by Peter Green. This analysis is based on the GSMA SGP.32 v1.3 specification published 28 May 2026 and reflects the position at the time of writing. Certification status will be updated as GSMA test specifications and conformance programmes evolve. Source: GSMA eSIM specification pages (SGP.32 v1.3, SGP.31 v1.3, eUICC PKI Certificate Policy v2.3).