Reference

SGP.32 FAQ: 20 Questions Answered

The most common questions about SGP.32 – from what it is and how it works to UK operator support, NB-IoT compatibility, eIM portability and what v1.2 means in practice. Each answer links to the relevant deep-dive page where you need more detail.

What is SGP.32?

SGP.32 is the GSMA 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 without physical access, without a user interface, and without a QR code. Published in May 2023 with v1.2 as the current stable version, it is the first eSIM standard designed specifically for the realities of modern IoT: headless devices, constrained networks, long lifecycles and global fleet deployments.

Full guide: What is SGP.32? The complete explainer

What does SGP stand for in SGP.32?

SGP stands for SIM Group Protocol – the naming convention the GSMA uses for its eSIM technical specifications. The number identifies the specific document in the series. SGP.02 covers M2M eSIM. SGP.22 covers consumer eSIM. SGP.31 defines the IoT eSIM architecture and requirements. SGP.32 is the IoT eSIM technical specification that implements those requirements. SGP.33 is the test specification used for certification against SGP.32.

See also: SGP.32 Glossary – every term explained

What is the difference between SGP.32 and SGP.22?

SGP.22 is the GSMA consumer eSIM standard, designed for smartphones where a user scans a QR code or uses an app to initiate profile changes. SGP.32 is designed for IoT devices with no user interface – profile changes are initiated server-side by an eIM rather than by a user. SGP.32 also adds CoAP over UDP transport for constrained NB-IoT and LTE-M devices, where SGP.22’s HTTPS dependency is impractical. Both standards reuse the same SM-DP+ profile delivery infrastructure.

Full comparison: SGP.32 vs SGP.02 vs SGP.22: Standards Compared

What is the difference between SGP.32 and SGP.02?

SGP.02 is the GSMA M2M eSIM standard built for automotive, using an SM-SR (Subscription Manager Secure Routing) configured at eUICC manufacture – locking the device to a single operator ecosystem for its lifetime. SGP.32 replaces the SM-SR with the eIM, which can be associated with a device at any point in its lifecycle. This eliminates the operator lock-in problem SGP.02 created. SGP.32 also supports constrained network protocols SGP.02 cannot handle.

Full comparison: SGP.32 vs SGP.02 vs SGP.22: Standards Compared

What is an eIM in SGP.32?

The eIM – eSIM IoT Remote Manager – is the server-side orchestration layer in SGP.32. It manages the complete eSIM profile lifecycle across individual devices or entire fleets: deciding which profile goes to which device, coordinating downloads with the SM-DP+, and instructing the device-side IPA to install, enable, disable or delete profiles. The eIM communicates via HTTPS for well-connected devices and CoAP over UDP for constrained NB-IoT and LTE-M devices. It can be operated by the enterprise, an IoT platform, or a connectivity provider.

Full guide: SGP.32 Architecture: eIM, IPA and eUICC Explained | eIM Portability

What is an IPA in SGP.32?

The IPA – IoT Profile Assistant – is the device-side agent in SGP.32. It replaces the LPA used in SGP.22 consumer devices. The LPA was designed for users – QR code scanning, manual profile activation, screen interaction. The IPA has no user-facing functions at all. It exists purely to receive instructions from the eIM and execute profile operations on the eUICC: downloading, installing, enabling, disabling and deleting profiles on command.

Full guide: SGP.32 Architecture: eIM, IPA and eUICC Explained | IPA-e vs IPA-d

What is the difference between IPA-e and IPA-d?

IPA-e (eUICC-hosted) runs the IoT Profile Assistant inside the secure element itself, removing the SGP.32 software stack from the device firmware team’s responsibility. It requires a certified eUICC that includes the embedded IPA. IPA-d (device-hosted) runs on the device’s host processor, giving firmware teams direct control but adding to their software maintenance burden. IPA-e generally suits volume deployments and fast integration; IPA-d suits applications needing fine-grained power management or the ability to download profiles over Wi-Fi rather than cellular.

Full guide: IPA-e vs IPA-d: The Architecture That Defines Your Deployment

What is the difference between SGP.31 and SGP.32?

SGP.31 is the architecture and requirements document – it defines what the IoT eSIM system must do: which components are needed, what interfaces exist between them, what security functions are required. SGP.32 is the technical specification that defines how those requirements are implemented – the exact protocols, message formats, cryptographic procedures and operational flows. When people talk about the IoT eSIM standard, they generally mean SGP.32 – but a fully compliant implementation requires both documents.

See also: SGP.32 Glossary

What is SGP.32 v1.2?

SGP.32 v1.2 is the current stable, certifiable version of the specification and the one driving all commercial deployments in 2025 and 2026. The initial SGP.32 specification was published as v1.0 in May 2023. Version 1.2 reached its stable form in late 2024 and is the version against which formal GSMA certification is now being issued for eUICC chips, eIM platforms and SM-DP+ servers. Any component claiming SGP.32 compliance should be certified against v1.2.

Full guide: SGP.32 v1.2: The Current Specification Explained

Is SGP.32 commercially available now?

Yes. Telenor IoT began commercial delivery of SGP.32 SIM cards in April 2026 – the first major operator to go fully live. Certified eIM platforms from Kigen, Simplex Wireless and others are available. SGP.32-certified eUICC hardware is shipping from Kigen and Thales. Module manufacturers including Quectel and Fibocom are producing certified hardware. The ecosystem is still maturing – particularly cross-vendor interoperability – but production deployments are running.

Full guide: SGP.32 v1.2: The Current Specification Explained | Who Went First?

Which operators support SGP.32 in the UK?

Telenor IoT is the most advanced with production-ready SGP.32 SIM delivery as of April 2026. Tele2 IoT supports SGP.32 bootstrap connectivity with an established hardware partnership with Teltonika. The four UK MNOs – EE, Vodafone, Three and O2 – provide the underlying 4G and 5G network infrastructure and are all working on SGP.32-native commercial offerings at various stages. Several specialist MVNOs and eSIM platform providers are also building SGP.32 eIM and SM-DP+ capabilities.

Full guide: SGP.32 Network Landscape: MNO, MVNO and eSIM Resellers | Teltonika and Tele2 Bootstrap Partnership

Does SGP.32 work on NB-IoT and LTE-M?

Yes – this is one of the most important design differences from earlier eSIM standards. SGP.22 uses HTTPS over TCP, which requires too much data and battery for NB-IoT and LTE-M devices with kilobyte monthly budgets. SGP.32 specifies CoAP over UDP with DTLS as a lightweight transport that makes profile management viable on constrained LPWAN connections. Devices on broadband connections can use HTTPS; NB-IoT and LTE-M devices use CoAP. Both work against the same eIM infrastructure simultaneously.

See also: SGP.32 Architecture | What is SGP.32?

What is a bootstrap profile in SGP.32?

A bootstrap profile is the initial connectivity profile loaded onto an SGP.32 device at manufacture, used to establish the first network connection to the eIM before an operational profile is downloaded. Without a bootstrap profile, the device has no connectivity and cannot reach the eIM to request one – a catch-22 that is one of the most practically important challenges in SGP.32 deployment. The bootstrap profile is typically provided by a specialist connectivity partner with broad multi-network roaming coverage and a long validity period.

Full guide: How to Choose an SGP.32 Bootstrap Provider | eSIM Bootstrap: The Connectivity Catch-22

What is eIM portability in SGP.32?

eIM portability is SGP.32’s anti-lock-in mechanism. Unlike SGP.02, where the SM-SR was fixed at eUICC manufacture, SGP.32 allows an eIM to be associated with a device at any point in its lifecycle – no factory configuration required. Multiple eIMs can be associated with a single eUICC simultaneously. Adding a new eIM only requires the new eIM’s configuration data to be sent by an existing associated eIM. This means enterprises can change eSIM management platform providers without replacing any hardware.

Full guide: SGP.32 eIM Portability: The Anti-Lock-In Feature Nobody Talks About

What is the difference between eSIM and eUICC?

eUICC (Embedded Universal Integrated Circuit Card) is the physical secure element – the chip soldered to the device PCB that stores SIM profiles. eSIM is the broader term covering both the physical form factor and the software architecture enabling remote provisioning. All eUICCs are eSIMs. But eSIM as a term also encompasses the standards, protocols and platforms – like SGP.32 – that define how the eUICC is managed. In practice the terms are often used interchangeably; eUICC is more precise when referring specifically to the hardware component.

Full guide: SGP.32 Glossary: Every eSIM Term Explained

Can SGP.32 use existing SGP.22 SM-DP+ infrastructure?

Yes – this was a deliberate GSMA design decision to accelerate operator adoption. SGP.32 reuses the SM-DP+ (Subscription Manager Data Preparation) server from SGP.22 for profile delivery. Operators who already support SGP.22 can serve SGP.32 devices by adding eIM capability to their existing stack, without rebuilding their profile preparation and delivery infrastructure. The eIM handles the new SGP.32-specific orchestration while the SM-DP+ handles profile packaging and delivery as before.

Full guide: SGP.32 Architecture: eIM, IPA and eUICC Explained

How many profiles can an SGP.32 eUICC hold?

The number of profiles an eUICC can store depends on its memory capacity and the eUICC OS implementation. Typical implementations support between 5 and 24 profiles, though only one profile is active at a time on a single radio interface. The profile count matters for deployments planning to pre-load profiles from multiple operators before deployment. Confirm the specific profile capacity with the eUICC or module manufacturer – it varies significantly between products and is not specified in the SGP.32 standard itself.

See also: SGP.32 eSIM Hardware: Routers, Modules and Manufacturers

What is CoAP and why does SGP.32 use it?

CoAP (Constrained Application Protocol) is defined in RFC 7252 as a lightweight alternative to HTTP, designed for machine-to-machine communication over low-bandwidth, high-latency networks. SGP.32 uses CoAP over UDP with DTLS encryption for devices on NB-IoT and LTE-M, where a full HTTPS handshake with its certificate chain would consume too much data and battery. CoAP strips the overhead from HTTP while preserving request-response semantics, making profile management operations viable on devices with monthly data budgets measured in kilobytes.

See also: SGP.32 Architecture | SGP.32 Glossary

Do I need to replace my existing IoT hardware to use SGP.32?

Yes, if your existing hardware uses physical SIM cards or an earlier eSIM standard without SGP.32 support. SGP.32 requires a certified eUICC and an IPA implementation. There is no migration path from SGP.02 to SGP.32 within the same physical device. Devices already in the field on physical SIMs or SGP.02 will operate on those standards for their remaining field life. The right approach for new designs is to specify SGP.32-certified eUICC modules from the start, with the lifecycle and TCO benefits justifying the switch.

Full guide: SGP.32 TCO: The Real Cost of Physical SIM Management | The eSIM Lifecycle

What is an iSIM and how does it relate to SGP.32?

An iSIM (integrated SIM) integrates the eUICC directly into the device SoC (System on Chip) rather than as a separate component. SGP.32 is fully compatible with both traditional discrete eUICC form factors and iSIM implementations – the RSP orchestration is identical regardless. iSIM reduces device size, cost and power consumption further than a discrete eUICC. For SGP.32 deployments, the IPA-e vs IPA-d choice applies equally to both eUICC and iSIM hardware. iSIM is a hardware evolution; SGP.32 is the management standard that sits above the hardware.

Full guide: SGP.32 and the Future of eSIM: iSIM, Edge Computing and Beyond

Ask an expert

Question not answered here?

Leave your details and your question. We respond to every genuine enquiry – no sales pitch, just a straight answer from someone who works in this space every day.