SGP.32 v1.2 is the current GSMA specification for IoT eSIM remote provisioning. It has been driving every commercial deployment, certification programme, and hardware design happening in 2025 and 2026. If you have been researching what SGP.32 is and why it matters right now, this is the version you need to understand.
The GSMA published SGP.32 v1.0 in May 2023. The specification reached its stable, commercially deployable form in v1.2, and that is the version underpinning everything happening in the market today – from Telenor IoT’s commercial launch in April 2026 to the first certified eIM platforms from Kigen, Simplex Wireless, and others. This post explains what SGP.32 is, what the v1.2 specification covers, and what the commercial landscape looks like in mid-2026.
What is SGP.32?
SGP.32 is the GSMA’s technical specification for remote SIM provisioning on IoT devices. It defines how eSIM profiles are securely downloaded, enabled, disabled, and deleted on a device’s eUICC – the embedded SIM chip – without any physical access to the device, without a user interface, and without a QR code.
The short version: it is how you manage the mobile connectivity on a device that is bolted to a telegraph pole in rural Aberdeenshire, buried inside a smart meter, or sealed into a logistics tracker somewhere between Rotterdam and Singapore.
Previous GSMA standards – SGP.02 for M2M and SGP.22 for consumer eSIM – left a gap that became increasingly obvious as IoT deployments scaled. SGP.02 required heavyweight server infrastructure and locked enterprises to a single operator. SGP.22 assumed a user was present to initiate every profile change, which is useless when your device has no screen, no internet browser, and no one standing next to it. SGP.32 was designed from the ground up to close that gap.
New to the standard?
If this is your first encounter with SGP.32, the full explainer on what SGP.32 is covers the background, the architecture, and why it matters in more depth. This post assumes basic familiarity and focuses on the v1.2 specification and its current commercial status. The SGP.32 glossary has definitions for every term used here.
The path from v1.0 to v1.2
Version numbers in GSMA specifications matter more than they might appear to. A published specification is the starting point, not the finish line. What follows is months of test specification work, conformance programme development, and interoperability testing between different vendors’ implementations. Only once that downstream work is complete can manufacturers achieve meaningful certification and enterprises plan deployments with confidence.
Initial publication. The specification defined the core architecture: eIM, IPA, CoAP/UDP transport, and the push-based provisioning model. Vendor research and early implementation work begins.
SGP.33 (test specification) and conformance extensions are worked through. Without this layer, certification is not possible. Several vendors build pre-standard implementations to stay ahead of the curve.
The stable, certifiable version of the specification is published. Kigen announces the first market-ready eIM platform compliant with v1.2. The commercial race begins in earnest.
Certified eUICC chips, eIM platforms, and SM-DP+ servers begin appearing from Kigen, Thales, Quectel, and others. Pilot programmes expand. Telenor IoT, Eseye, and Webbing are among operators and platforms building live v1.2-based infrastructure.
Telenor IoT begins commercial SGP.32 SIM delivery. KORE and Kigen announce a joint SGP.32-compliant portfolio with commercial availability planned for later in 2026. The race to be first to market is settled.
The practical significance of v1.2 being the current specification is that it is the version enterprises can design against with confidence. Certifications are being achieved against v1.2. Hardware designs targeting v1.2 will be interoperable with other v1.2-certified components. Anything built against earlier pre-standard implementations needs to be validated against v1.2 before it can be considered production-grade.
What SGP.32 v1.2 actually specifies
The full specification runs to several hundred pages. For most people evaluating or planning IoT deployments, the relevant parts come down to five things: the architecture, the components, the protocol choices, the security model, and the eIM portability rules.
The architecture: push, not pull
Every eSIM standard before SGP.32 was pull-based. The device or the user initiated profile changes. SGP.32 inverts this. The eIM – the server-side manager – pushes changes to the device. The device does not need to be awake, connected to a management portal, or responding to user input. The eIM tells the device’s IPA to fetch a profile from the SM-DP+, and the IPA handles the download and installation. This is the architectural shift that makes fleet-scale management of headless devices practical for the first time.
A full breakdown of how the components fit together is in the SGP.32 architecture guide.
The four key components
eSIM IoT Remote Manager. The orchestration layer. It coordinates profile operations across the fleet, instructs devices, and communicates with the SM-DP+. This is where fleet-level policy lives.
IoT Profile Assistant. Lives either on the device (IPA-d) or embedded in the eUICC itself (IPA-e). Receives instructions from the eIM and manages profile downloads and state changes on the eUICC.
Subscription Manager Data Preparation. Reused from SGP.22. Securely packages and delivers operator profiles. SGP.32 reuses the existing SM-DP+ infrastructure rather than replacing it.
The embedded SIM chip that physically stores and executes profiles. In SGP.32, it holds the IPA-e in the IPA-e variant. Certified eUICCs from Kigen, Thales, and others are commercially available.
The IPA-e versus IPA-d choice has significant implications for device OEMs. The IPA-e vs IPA-d guide covers the tradeoffs in detail – but the short version is that IPA-e offloads the SGP.32 software stack onto the eUICC, reducing the development burden on the device firmware team.
Protocol choices: built for constrained networks
One of the most important practical differences between SGP.32 and its predecessors is the protocol stack. SGP.22 uses HTTPS over TCP, which is reasonable for a smartphone on a good 4G connection. For a device on NB-IoT with a data budget measured in kilobytes per month, it is not viable.
SGP.32 specifies CoAP over UDP with DTLS security as the lightweight protocol path for constrained devices. CoAP strips most of the overhead out of HTTP while preserving a request-response model. DTLS provides the equivalent of TLS security for UDP transport. The result is that profile management operations can be conducted on devices that have no practical hope of running a full TLS handshake with a large certificate chain on a narrow LPWAN connection.
For devices with more capable connectivity – 4G/LTE-M routers, industrial gateways – HTTPS over TCP remains supported. The specification accommodates both.
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 must be cryptographically signed and verified. Enterprises receive verifiable confirmation from the eUICC that each operation completed successfully. This was not present in SGP.02 in the same form, and it matters for fleet audit trails, compliance requirements, and operational confidence at scale.
The wider SGP.32 security model is covered separately, including how the eUICC trust chain is established at manufacture and how rogue profile operations are prevented.
eIM portability: solving the lock-in problem
One of the structural problems with SGP.02 was SM-SR lock-in. The SM-SR had to be configured at eUICC manufacture, which effectively locked the device to a single operator’s provisioning infrastructure for life. Switching operators meant either replacing the hardware or navigating a complex, non-standardised migration process.
SGP.32 solves this. An eIM can be associated with an eUICC at any point in its lifecycle – it does not need to be configured at manufacture. Multiple eIMs can be associated with a single eUICC simultaneously. Adding a new eIM only requires the configuration data to be sent by an already-associated eIM, with no direct technical integration required between eIM providers. The result is genuine multi-operator flexibility across the device’s lifetime.
The eIM portability guide covers how this works in practice, including the scenarios where portability is most valuable.
The commercial picture in mid-2026
v1.2 is no longer a theoretical specification. It is being deployed commercially right now, with a growing list of certified components and live production traffic.
Who has certified and deployed
Kigen announced the first market-ready eIM compliant with SGP.32 v1.2 in October 2024. Simplex Wireless, Webbing, and others have followed with their own eIM platforms. On the hardware side, certified modules from Quectel and Thales (Cinterion) are entering production designs. The SM-DP+ layer has been extended by multiple providers to support SGP.32-native profile delivery.
At the operator level, Telenor IoT began commercial delivery of SGP.32 SIM cards in April 2026 – the clearest signal yet that the standard has crossed from pilot into production. With 30 million connected devices under management and customers including Volvo and Scania, Telenor’s commitment carries weight. Teltonika and Tele2 have also moved on SGP.32 bootstrap connectivity for router-based deployments.
In April 2026, KORE and Kigen announced a joint portfolio of SGP.32-compliant connectivity solutions with commercial availability planned for later in the year. A full breakdown of who went first with SGP.32 commercial deployments is covered in a separate post.
Where the ecosystem still has gaps
Honest assessment: the certified ecosystem in mid-2026 is real but not yet comprehensive. Cross-vendor interoperability – a different eUICC OS from one vendor, an eIM from a second vendor, and an SM-DP+ from a third – is still in early stages of validation. Not every major cellular module vendor has certified SGP.32-native hardware in production volumes. Enterprise tooling for integrating eIM management with existing device management platforms is still developing.
ABI Research initially forecast 2.9 million SGP.32 profile downloads in 2025. Due to the time it took to complete the certification framework, the commercial acceleration shifted to H2 2026 and into 2027. The trajectory is real; the timing was slower than the earliest projections.
For enterprises designing new IoT deployments now, the right posture is to design for SGP.32 readiness – choose hardware with v1.2-certified eUICC, evaluate eIM providers who have demonstrated real deployments, and understand your bootstrap connectivity options. The TCO analysis comparing SGP.32 against physical SIM management is worth working through before making procurement decisions.
What v1.2 means for different stakeholders
Device OEMs and module vendors
v1.2 is the specification to certify against. Designing hardware against earlier pre-standard implementations is a risk, because those implementations may not pass conformance testing against v1.2. The eSIM hardware guide covers which module vendors have certified or announced certification timelines. If you are specifying a new hardware design today, the question to ask your module vendor is not whether they support SGP.32 in principle – it is whether their product is v1.2 certified or on a stated v1.2 certification roadmap.
Network operators and MVNOs
SGP.32 changes the competitive dynamics of IoT connectivity. The SM-SR lock-in that gave operators structural control over their M2M base no longer exists in the same form. Operators who move early on eIM infrastructure and SGP.32-native SIM delivery will be able to compete on service quality and commercial terms rather than on switching friction. Those who wait will find their IoT customer base increasingly aware that the lock-in they relied on is no longer technically necessary.
Enterprise IoT buyers
The practical benefits are covered in detail on the what is SGP.32 page, but the v1.2 context matters for procurement. When a connectivity provider says they support SGP.32, the right follow-up question is which version of the specification, whether they have completed formal GSMA certification, and what cross-vendor interoperability testing they have done. The standard is real; not every vendor claiming compliance is at the same stage.
Go deeper
The SGP.32 full explainer is the best starting point if you are new to the standard. For architecture detail, the eIM, IPA and eUICC architecture guide covers how the components interact. If you are evaluating connectivity options, how to choose a bootstrap provider covers the first decision most enterprise IoT teams face.
For a comparison of all three GSMA eSIM standards and where SGP.32 sits relative to SGP.02 and SGP.22, see SGP.32 vs SGP.02 vs SGP.22.