eSIM, eUICC and iSIM Standards FAQ

These are the questions we hear most often about eSIM, eUICC and iSIM: what the terms actually mean, which GSMA specification applies to which deployment, and what is and isn’t ready to build on today. Each answer is short by design, with a link to the relevant section of our white paper for the longer technical treatment. For the underlying detail and references, follow the white-paper links.

Companion to: The Current State and Future Direction of eSIM, eUICC and iSIM, a CSL Group technical guide to the standards, security models and deployment choices shaping embedded connectivity.

What is the difference between eSIM and eUICC?

The terms are often used interchangeably, but they describe different things. In everyday usage, eSIM often refers to an embedded SIM soldered into a device, typically the MFF2 package; that is the form factor. eUICC is the capability within a SIM’s secure element that lets operator profiles be downloaded, enabled, disabled and deleted remotely. The eUICC is what makes GSMA Remote SIM Provisioning possible, and it can be implemented in any SIM form factor, though it is most often associated with soldered embedded SIMs.

Is iSIM the same as eSIM?

No. iSIM integrates eUICC functionality directly into the device’s System-on-Chip, housed in an Integrated Tamper-Resistant Element (TRE) within the processor’s secure hardware. Where eSIM describes a soldered form factor and eUICC the remote-provisioning capability, iSIM moves that capability into the SoC itself, removing the need for a separate SIM package or discrete eUICC component. Under the GSMA integrated-eUICC model it is evaluated through SGP.08 or SGP.18, rather than a software-only approach.

What is an Integrated TRE?

An Integrated Tamper-Resistant Element is a hardened hardware security boundary built into the silicon of a System-on-Chip, designed to resist physical and logical attacks such as fault injection, side-channel analysis and memory probing. It is the hardware anchor for an integrated eUICC. GSMA integrated-eUICC compliance requires a certified TRE, evaluated under SGP.08 (the PP-0084 path) or SGP.18 (the PP-0117 path). The effective security posture should be assessed against the target protection profile and certified implementation, not inferred from the form factor alone.

Which GSMA specifications matter for eSIM and IoT?

The landscape divides into a few families. Consumer RSP is covered by SGP.21 and SGP.22; IoT RSP by SGP.31 and SGP.32; and In-Factory Profile Provisioning is currently defined by SGP.41, with SGP.42 expected to provide the accompanying technical specification once released. Around those sit the supporting specifications: SGP.24 (RSP compliance for Consumer and IoT), SGP.25 (the eUICC protection profile for Consumer and IoT), SGP.33-1/-2/-3 (IoT eUICC, IPA and eIM testing), SGP.08 and SGP.18 (integrated-eUICC security evaluation), SGP.29 (EID definition and assignment) and SGP.14 (the eUICC PKI Certificate Policy). Which ones apply depends on the product and the role being declared.

What is the difference between Consumer RSP and IoT RSP?

Consumer RSP (SGP.21/22) assumes a device with a user interface and a Local Profile Assistant, where the user initiates profile downloads, for example by scanning a QR code. IoT RSP (SGP.31/32) is built for headless, network-constrained or UI-constrained devices that have none of that, introducing the eIM and IPA model so profiles can be managed remotely without consumer-style interaction. The legacy M2M model (SGP.01/02) preceded both and relied on SMS transport, which is limiting for modern constrained IoT. The right model depends on the device and how it is deployed.

My devices run on M2M or SGP.02. Do I have to migrate now?

No, not on any fixed timeline. Existing M2M deployments using SGP.01/02, Multi-IMSI or proven proprietary connectivity models continue to operate reliably and remain supported throughout their operational lifecycle. The industry direction for new greenfield designs is toward IoT RSP (SGP.31/32), and designing new hardware for SGP.32 readiness can reduce future migration and interoperability risk. But that is a forward-looking choice for new products, not a reason to retire deployments that are working well today.

What is SGP.32?

SGP.32 is the GSMA technical specification for IoT Remote SIM Provisioning. It provides the procedures, data structures, interface bindings and security mechanisms that implement the SGP.31 IoT RSP architecture, and supports constrained and UI-limited devices through the eIM and IPA model rather than a consumer-style user interface. First published in May 2023, it reached v1.2 in June 2024, which is the current GSMA IoT RSP technical baseline. Commercial rollout timing is best treated as ecosystem and market commentary rather than a standards-defined milestone.

What are the eIM and IPA in SGP.32?

The eSIM IoT Remote Manager (eIM) is the server-side platform that orchestrates remote profile-management operations and supports decisions about which profile should be enabled, disabled, downloaded or deleted for a given device. The IoT Profile Assistant (IPA) is the device-side component that manages profiles; it can run in the eUICC (IPAe) or in the device application processor (IPAd). Together they replace the consumer-centric Local Profile Assistant with a server-orchestrated model suited to headless devices. Profile delivery still reuses the established SM-DP+ infrastructure from Consumer RSP.

What transport protocols does SGP.32 support?

SGP.32 uses IP-based communication rather than SMS, with transport options chosen for constrained IoT, including devices using NB-IoT and LTE-M. It defines HTTP/TLS over TCP for gateway-class devices and CoAP/DTLS over UDP for tightly constrained ones, with block-wise transfers (RFC 7959) and Connection ID (RFC 9146). Depending on implementation and device class, ESipa messaging may also be carried through IoT application-layer protocols such as LwM2M or MQTT where supported. V1.2 defines eIM support for both ASN.1 and JSON bindings on the ESipa interface. The choice of transport follows the device class and the network.

Does every IoT deployment need SGP.32?

Not necessarily. The right architecture depends on the deployment model, device lifecycle, installer workflow, target markets and operator requirements. Devices provisioned through managed installer channels, operating in stable operator environments, or deployed into estates with established connectivity workflows do not necessarily need the full OTA remote-provisioning stack today. New long-life or globally distributed deployments are where designing for SGP.32 readiness tends to earn its place. The useful question is not “do we need eSIM?” but which provisioning model fits the device, the workflow and the lifecycle.

What is IFPP?

In-Factory Profile Provisioning is a way of loading bound profile packages onto eUICCs during device manufacturing or order fulfilment, rather than over the air after deployment. Profiles can be loaded according to characteristics such as device capabilities or the region the device will ship to. This lets devices arrive pre-provisioned and ready for first network attach on power-up, subject to activation state and coverage, and can reduce first-boot OTA overhead, which matters most for battery-powered devices with long lifetimes. The IFPP architecture is defined by SGP.41 (v1.0, February 2025) and provides a common framework for provisioning Bound Profile Packages onto eUICCs in a device factory environment across Consumer and IoT scenarios.

When will SGP.42 be released?

SGP.42, the IFPP technical specification that accompanies the SGP.41 architecture, has not yet appeared in the current GSMA released specification set; industry sources describe it as under development. Because the technical specification is not yet released, implementation planning should be based on currently published GSMA documents, notably the SGP.41 architecture, together with vendor-specific readiness and interoperability evidence. Current in-factory provisioning approaches are best treated as implementation options rather than a substitute for the formal SGP.42 baseline once it is published.

How is iSIM security evaluated: TEE or TRE?

The two are not equivalent under the GSMA model. A Trusted Execution Environment (TEE) is a software-defined secure zone within the main processor; it provides logical isolation and is used for SIM-like functionality in some parts of the wider industry, but it is not the certification path described by GSMA for integrated eUICC. A Tamper-Resistant Element (TRE) is a dedicated, hardened hardware boundary, and GSMA integrated-eUICC compliance requires a certified TRE, evaluated under SGP.08 (PP-0084) or SGP.18 (PP-0117). Both of those methodologies are TRE-centric.

Is there a GSMA compliance process for IoT eSIM?

Yes. SGP.24 is the GSMA RSP compliance process, with v3.2.1 applying to Consumer eSIM under SGP.21/SGP.22 v3.x, and v2.6.1 applying to Consumer eSIM under SGP.21/SGP.22 v2.x and IoT RSP under SGP.31/SGP.32 v1.x. The IoT branch defines declaration templates for the IoT eUICC, the IoT Device/IPA and the eIM, with functional testing via SGP.33-1 (eUICC), SGP.33-2 (IPA) and SGP.33-3 (eIM). PKI certificates are issued for the eUICC, SM-DP+ and SM-DS, while the IPA and eIM receive a Confirmation of Compliance. The remaining variable is ecosystem maturity rather than the absence of a framework: for example, GCF IoT device certification is still rolling out. Organisations deploying SGP.32 should confirm the applicable SGP.24 branch and Annex C, and track interoperability and certified-product availability.

CSL helps organisations choose and apply the right eSIM, eUICC and iSIM standards for new connected products, from the GSMA provisioning model through to integrated-eUICC security and factory provisioning, while continuing to support existing deployed estates. Talk to us about your device roadmap, your target markets, and the standards questions you are working through.

Contact CSL: https://www.csl-group.com/contact-us/

eSIM, eUICC and iSIM Standards FAQ. CSL Group, April 2026. Companion to the white paper The Current State and Future Direction of eSIM, eUICC and iSIM.

About CSL: a UK connectivity provider for critical IoT and alarm applications, including critical IoT connectivity, eSIM and eUICC provisioning, fire, security, healthcare and assisted living.