SGP.32 V1.2

SGP.32 v1.2 matters because it is the first version of the specification that can be fully relied upon for production IoT deployments. Earlier versions were published, but the test specification (SGP.33) and conformance programmes needed to validate those earlier versions across competing vendor implementations were not complete until v1.2 was stable. The version number is not just administrative – it is the difference between a specification that exists on paper and one that can be certified, shipped and operated at fleet scale.

The comprehensive technical reference for SGP.32 v1.2 – including architecture deep-dives, IPA-e vs IPA-d tradeoffs, eIM portability mechanics, and bootstrap provider selection – is at sgp32.co.uk. This page covers what changed in v1.2, the key technical features that matter for IoT device designers, and what it means specifically for eRedCap deployments.

From v1.0 to v1.2 – What Changed

GSMA specifications follow a predictable maturation path. The initial publication defines the architecture. What follows is months of test specification work (SGP.33 in this case), conformance programme development, and interoperability testing between independent vendor implementations. Only once that downstream work closes can manufacturers achieve meaningful certification and enterprises plan production deployments with confidence.

The v1.2 Architecture – Push, Not Pull

The most consequential architectural decision in SGP.32 v1.2 is the inversion of the provisioning model. Every eSIM standard before SGP.32 was pull-based – the device or the user initiated profile changes. The device had to be awake, connected, and in a state to request an operation.

SGP.32 v1.2 is push-based. The eIM – the server-side fleet manager – pushes instructions to the device. The device does not need to initiate anything. The eIM tells the device’s IPA (IoT Profile Assistant) to fetch a profile from the SM-DP+, and the IPA handles the download and installation, confirming completion back to the eIM with cryptographic verification.

For headless IoT devices – the exact device class that eRedCap targets – this is the enabling shift. A smart meter with no user interface cannot initiate a QR code scan. A logistics tracker sealed inside a container cannot respond to a UI prompt. Push-based provisioning from the eIM means the operator or enterprise can execute connectivity changes across millions of such devices from a single management platform, on a schedule, without any device-side human action.

Protocol Choices – Built for Constrained IoT

One of the most important practical differences between SGP.32 v1.2 and previous eSIM standards is the protocol stack. SGP.22 uses HTTPS over TCP – appropriate for a smartphone on a reliable 4G connection, but not viable for a device on NB-IoT with a data budget measured in kilobytes per month, or an early eRedCap device in a location where 5G SA coverage is limited and LTE fallback means genuinely constrained bandwidth.

CoAP (Constrained Application Protocol) strips most of the overhead from HTTP while preserving a request-response model. DTLS (Datagram Transport Layer Security) provides the equivalent of TLS security for UDP transport. The result is that SGP.32 profile management operations can execute on devices that have no practical chance of completing a full TLS handshake with a large certificate chain on a narrow LPWAN connection.

For eRedCap devices specifically: the protocol stack matters during deployment phases when 5G SA coverage is not yet available and LTE fallback is the operative connection. A v1.2-compliant device using CoAP/DTLS can complete profile management operations on a constrained LTE-M or NB-IoT connection, maintaining connectivity management capability throughout the transition period.

Security Model – Cryptographic Authentication for Every Operation

SGP.32 v1.2 mandates cryptographic authentication for all Profile State Management Operations (PSMOs) – every profile download, enable, disable, or delete. Each operation must be cryptographically signed and verified end-to-end, and enterprises receive verifiable confirmation from the eUICC that each operation completed successfully.

This matters for three reasons in the IoT context:

• Audit trails – Fleet operators can demonstrate cryptographically that specific profile changes occurred on specific devices at specific times. For regulated industries (utilities, healthcare, financial services), this is a compliance requirement, not a nice-to-have.
• Rogue operation prevention – The authentication model prevents unauthorised parties from pushing profile changes to devices, even if they have network access. Each operation must originate from an authenticated eIM with the correct credentials for that eUICC.
• EU Cyber Resilience Act alignment – The CRA’s IoT security requirements, applying from 2027, effectively mandate the kind of authenticated, auditable update mechanism that SGP.32 v1.2 provides at the SIM layer. Device designs incorporating v1.2-compliant eUICC hardware are substantially further along the CRA compliance path than those relying on SGP.02 or physical SIM management.

The full SGP.32 security model – including how the eUICC trust chain is established at manufacture, how credentials are provisioned, and how the security architecture maps to common IoT security frameworks – is covered at euicc.co.uk and in the SGP.32 security deep-dive on sgp32.co.uk.

eIM Portability – Solving Lock-In

One of the structural problems with SGP.02 was SM-SR lock-in. The SM-SR (Subscription Manager Secure Routing) had to be configured at eUICC manufacture, which effectively locked the device to a single operator’s infrastructure for life. Changing connectivity providers meant either replacing hardware or navigating a complex, non-standardised migration.

SGP.32 v1.2 solves this. An eIM can be associated with an eUICC at any point in the device lifecycle – it does not need to be configured at manufacture. Multiple eIMs can be associated with a single eUICC simultaneously. Transferring management from one eIM to another requires only that the existing eIM authorises the new one – no direct operator-to-operator technical integration is needed.

For enterprise IoT buyers evaluating eRedCap-based deployments, this is commercially significant. A device fleet designed around SGP.32 v1.2 can change connectivity providers – whether for commercial reasons, coverage improvements, or network sunset response – without hardware replacement. For devices expected to operate for 15 years across a changing operator landscape, that flexibility has measurable value. The TCO analysis on sgp32.co.uk quantifies this against the ongoing cost of physical SIM management at fleet scale.

The v1.2 Ecosystem in Mid-2026

The SGP.32 v1.2 ecosystem is commercially real but not yet fully mature. The honest assessment of where things stand:

• Telenor IoT began commercial SGP.32 SIM delivery in April 2026 – the first major operator in production. With 30 million connected devices under management and automotive customers including Volvo and Scania, this is a credible production signal.
• Certified eIM platforms from Kigen, Simplex Wireless and Webbing are available. KORE and Kigen announced a joint SGP.32-compliant portfolio in April 2026 with commercial availability planned later in the year.
• Certified eUICC hardware from Kigen and Thales. Certified cellular modules from Quectel and Fibocom entering production designs.
• UK operators (EE, Vodafone, Three, O2) are building SGP.32-native commercial offerings. 5gredcap.co.uk covers 5G SA deployment status across UK operators – the same networks that will carry SGP.32-managed eRedCap devices.
• Cross-vendor interoperability is still in early validation stages. Different eUICC OS vendors, eIM platforms and SM-DP+ servers from different suppliers do not yet have comprehensively validated interoperability across all combinations.

SGP.32 v1.2 and eRedCap Device Design

For anyone designing or specifying eRedCap devices, the practical implications of SGP.32 v1.2 are straightforward:

1. Design for v1.2 readiness now. eRedCap hardware expected to ship in 2026-2027 will operate for a decade or more. Specify eUICC hardware that is v1.2 certified or on a stated v1.2 certification roadmap. The incremental cost of v1.2-capable eUICC vs an older M2M SIM socket is modest relative to the operational cost of physical SIM management at fleet scale over a 15-year lifespan.
2. Choose IPA-e where possible. For eRedCap module designs where firmware resource is constrained, IPA-e offloads the SGP.32 software stack onto the eUICC, reducing integration burden and certifying the SGP.32 behaviour at the chip level.
3. Plan bootstrap connectivity. Every SGP.32 device needs bootstrap connectivity – the initial connection used to download the operational profile. This is a separate procurement decision from the long-term operator. How to choose a bootstrap provider is covered on sgp32.co.uk.
4. Validate against 5G SA deployment plans. SGP.32 profile management works over NB-IoT, LTE-M, LTE, and 5G SA. For eRedCap devices specifically, confirm 5G SA availability in target deployment areas – 5gredcap.co.uk covers UK operator 5G SA deployment status in detail.

Technical reference: SGP.32 v1.2 specification explained – sgp32.co.uk | eUICC architecture – euicc.co.uk | UK 5G SA coverage – 5gredcap.co.uk | GSMA eSIM Hub