New eSIM standards explained: in 2026 the two active GSMA specifications for remote SIM provisioning are SGP.22 (consumer) and SGP.32 (IoT, the next-generation replacement for the older SGP.02 M2M architecture). The new eSIM standards introduce the eIM (eSIM IoT Manager) and IPA (IoT Profile Assistant) actors for IoT devices, retain the consumer LPA model for smartphones and wearables, and continue to use the GSMA Discovery Service as the root directory of the public eSIM ecosystem. This page explains the standards stack — SGP.21 architecture, SGP.22 consumer, SGP.31 IoT architecture, SGP.32 IoT technical, and the Discovery Service — and what changes for handset OEMs, MVNOs, and IoT integrators.
Key takeaways
- SGP.22 is the consumer eSIM technical spec; SGP.21 is the matching architecture spec.
- SGP.32 is the new IoT eSIM technical spec (2023), replacing the SGP.02 M2M architecture; SGP.31 is the matching architecture spec.
- SGP.32 introduces eIM (eSIM IoT Manager) and IPA (IoT Profile Assistant) actors, removing the SM-SR push model used by SGP.02.
- The GSMA Discovery Service (SM-DS) is the root directory of pending eSIM profile events for the public ecosystem.
- For greenfield IoT in 2026, SGP.32 is the default; in-production SGP.02 deployments continue without forced migration.
- The consumer LPA model in SGP.22 is unchanged; new eSIM standards work for consumer is mostly incremental.
SGP.21 and SGP.22 — the consumer eSIM stack
GSMA SGP.21 is the architecture specification for consumer remote SIM provisioning. It defines the actors involved in a consumer eSIM activation — the eUICC chip in the device, the Local Profile Assistant (LPA) on the device, the SM-DP+ (Subscription Manager Data Preparation) server operated by or on behalf of the operator, the SM-DS (Subscription Manager Discovery Service) for activation-code-free enrolment, and the end user. SGP.22 is the technical specification that implements SGP.21 — the on-the-wire interface definitions, the eUICC profile format, the certificate trust chain, and the procedures the LPA must follow. The two together are the consumer eSIM standard set; vendors and integrators typically reference SGP.22 as the implementation-level document.
The consumer flow that SGP.22 specifies is the familiar one: the user receives an activation code (typically encoded as a QR code), the LPA contacts the SM-DP+ at the address embedded in the activation code, the SM-DP+ authenticates the eUICC against the GSMA root certificate hierarchy, and the eUICC downloads and installs the profile. The user then enables the profile through the LPA UI. The Discovery Service path is the same except that instead of an activation code the eUICC queries the SM-DS to find which SM-DP+ has events waiting for it. The SGP.22 specification has been incrementally revised since 2016; the architecture remains stable and most 2026 work is at the operator deployment and OEM integration layer rather than the spec itself.
SGP.31 and SGP.32 — the new IoT stack
GSMA SGP.31 (architecture) and SGP.32 (technical) are the new IoT eSIM standards published by the GSMA in 2023 as the next-generation replacement for the SGP.01/SGP.02 M2M architecture. The fundamental change from SGP.02 is the replacement of the SM-SR (Subscription Manager Secure Routing) push-based architecture — which required the SM-SR to maintain reachable connectivity to every managed eUICC — with an eIM (eSIM IoT Manager) plus IPA (IoT Profile Assistant) pull-or-push model that is more appropriate for IoT devices that are intermittently connected, battery-constrained, or behind NAT and firewall infrastructure that breaks SM-SR reachability. The underlying eUICC profile format and SM-DP+ provisioning remain similar to SGP.22, but the management plane is new.
The eIM is the IoT-platform-side actor that issues signed commands to manage profiles across a fleet of devices — download, enable, disable, delete. The IPA runs on the device and is the SGP.32 equivalent of the consumer LPA, except that the IPA does not require user interaction and is designed for headless devices. The eIM’s commands are signed and the IPA validates them against the eIM’s certificate, so a compromised intermediate connection cannot impersonate the eIM. SGP.32 is the strategic direction for new IoT eSIM deployments and has broader operator, vendor, and IoT-platform roadmap support than continued SGP.02 work, which is in maintenance.
Specification comparison
| Spec | Domain | Architecture | Device-side actor | Platform-side actor | Status |
|---|---|---|---|---|---|
| SGP.21 / SGP.22 | Consumer | LPA-driven, user-interactive | LPA | SM-DP+, SM-DS | In production, incremental revisions |
| SGP.31 / SGP.32 | IoT | eIM-driven, headless | IPA | SM-DP+, eIM, SM-DS | 2023 publication, active deployment |
| SGP.01 / SGP.02 | M2M (legacy) | SM-SR push | (eUICC only) | SM-SR, SM-DP | Maintenance, no new architecture work |
| Discovery Service (SM-DS) | All | Directory of pending events | (LPA / IPA queries it) | GSMA root SM-DS | In production |
The GSMA Discovery Service
The GSMA Discovery Service (SM-DS) is the directory mechanism that lets an eUICC find out which SM-DP+ has profile events waiting for it, without the user or device having to know the SM-DP+ address in advance. The flow is: the device queries the Discovery Service at activation (or periodically); the Discovery Service returns the SM-DP+ address(es) with pending events for that eUICC; the device then connects to the SM-DP+ and downloads the profile. The GSMA operates the root Discovery Service for the public eSIM ecosystem; operators and SM-DP+ providers register pending events against it. The Discovery Service is the mechanism that makes activation-code-free eSIM enrolment possible and is fundamental to OEM-led flows where the user activates eSIM through the device’s built-in carrier-discovery UI rather than through a QR code.
What changes for handset OEMs
For handset OEMs the SGP.22 specification is mature and most 2026 work is incremental — profile-policy refinements, transfer-between-devices flows, and revisions to the certificate-hierarchy management. The most material area of evolution is OEM-led enrolment using the Discovery Service: rather than the user receiving a QR code from the operator, the user picks an operator from a carrier-discovery UI built into the device, and the device queries the Discovery Service to enrol. This shifts the activation experience from operator-led to OEM-led and is one of the structural changes that has fuelled the broader eSIM adoption story over the past several iPhone and Android device cycles. OEMs participating in this ecosystem need certified eUICC implementations, integration with the GSMA Discovery Service, and operator-side SM-DP+ registration agreements.
What changes for MVNOs
For MVNOs the principal change is access to SM-DP+ infrastructure. MVNOs either operate their own SM-DP+ (rare, because of the GSMA SAS-SM certification cost and operational complexity), partner with their host operator’s SM-DP+, or use a third-party SM-DP+ service from vendors such as IDEMIA, G+D, Thales, Kigen, or Workz. For travel-SIM MVNOs in particular (Holafly, Airalo, Maya Mobile, Ubigi), the SM-DP+ partner choice is a strategic decision because it determines the profile-issuance latency, the supported eUICC vendor list, and the operational reliability of new-customer onboarding. For SGP.32 IoT MVNOs the additional decision is eIM provider choice — the eIM can be operated by the MVNO, by the connectivity provider, or by an IoT-platform partner.
What changes for IoT integrators
For IoT integrators SGP.32 is the most consequential standards change of the past several years. The eIM-plus-IPA architecture removes the SM-SR reachability requirement that made SGP.02 difficult to operate at scale across firewalls, NAT, and intermittent-connectivity device populations. Greenfield IoT designs in 2026 should default to SGP.32 if the eUICC vendor, operator partner, and IoT-platform support it; in-production SGP.02 deployments continue to work and there is no GSMA-mandated migration. The integrator decisions are: eUICC vendor and certification status, eIM provider (operator-supplied, third-party, or self-operated), IPA implementation (vendor-provided in eUICC OS or open-source reference), and operator coverage for SGP.32 profile issuance in the target geographies.
How DROAM News reads it
The new eSIM standards in 2026 are best understood as two parallel tracks: a mature, incrementally evolving consumer track (SGP.21 / SGP.22) where the architecture is stable and the work is at the integration and OEM-enrolment layer, and a newly published IoT track (SGP.31 / SGP.32 from 2023) where active deployment is underway and the eIM-plus-IPA model is a structural improvement over the older SGP.02 M2M architecture. For handset OEMs and consumer MVNOs the story is incremental; for IoT integrators the story is a generational architecture upgrade. Editorial disclosure: Droam BV, the publisher of DROAM News, operates in the enterprise roaming and IoT connectivity market and has direct commercial interest in both consumer eSIM (SGP.22) and IoT eSIM (SGP.32) ecosystems; that overlap is handled per our editorial policy.
Related DROAM News pages
- Mobile & wireless news — consumer eSIM, SGP.22, and OEM-led enrolment coverage.
- IoT & M2M news — SGP.32, eIM, IPA, and IoT eSIM deployment coverage.
- Editorial policy — how we select stories, disclose commercial overlap, and handle corrections.
Sources and references
Specification descriptions are drawn from the published GSMA SGP series and from publicly documented vendor implementations. GSMA specifications are revised periodically; verify against the current published version before implementation decisions.
- GSMA eSIM specifications portal (SGP.21, SGP.22, SGP.31, SGP.32, SGP.02): gsma.com/esim/esim-specification.
- GSMA eSIM overview: gsma.com/esim.
- GSMA SAS-SM (security accreditation for SM-DP+ / eIM providers): gsma.com/security.
- ETSI TS 103 383 (eUICC architecture base specification): etsi.org.
- 3GPP TS 31.102 (USIM characteristics): 3gpp.org.
- GSMA IoT eSIM (SGP.31 / SGP.32) overview: gsma.com/iot/esim-iot.
FAQ
What are the new eSIM standards in 2026?
The two consumer- and IoT-relevant eSIM standards in active deployment are GSMA SGP.22 (consumer remote SIM provisioning, in production since 2016 and successively revised) and GSMA SGP.32 (IoT remote SIM provisioning, published in 2023 as the next-generation replacement for the M2M architecture in SGP.02). SGP.22 covers the consumer eSIM flow used by smartphones, tablets, and wearables — the user scans a QR code or downloads a profile through an LPA. SGP.32 introduces a new IoT-specific architecture with an eIM (eSIM IoT Manager) issuing remote commands and an IPA (IoT Profile Assistant) running on the device, removing the consumer-style LPA requirement and the M2M-style SM-SR push model.
What is the difference between SGP.22 and SGP.32?
SGP.22 is the consumer eSIM architecture: a Local Profile Assistant (LPA) on the device handles profile download from an SM-DP+ server, with the user actively triggering the download (typically by scanning a QR code containing an activation code). SGP.32 is the IoT architecture: an eIM (eSIM IoT Manager) issues remote profile-management commands to a fleet of devices, and an IPA (IoT Profile Assistant) running on each device executes the eIM’s instructions against the device’s eUICC. SGP.32 replaces the older SGP.02 M2M architecture, removes the SM-SR push model, and is designed for headless devices that cannot offer a user-interactive QR scan. The two architectures share the underlying eUICC profile format and SM-DP+ provisioning model.
What is SGP.21 and how does it relate to SGP.22 and SGP.32?
GSMA SGP.21 is the architecture specification for consumer remote SIM provisioning — it defines the actors (eUICC, LPA, SM-DP+, SM-DS, end user), the trust model, and the interactions. SGP.22 is the technical specification that implements SGP.21 — it is the on-the-wire and on-the-card detail. The pair (SGP.21 architecture + SGP.22 technical) is the consumer eSIM standard set. For IoT, the equivalent pair is SGP.31 (architecture) and SGP.32 (technical). Vendors and integrators typically reference SGP.22 and SGP.32 because those are the implementation-level specifications, but the architecture documents (SGP.21 and SGP.31) define the system design that the technical specs realise.
What is the GSMA Discovery Service and why does it matter?
The GSMA Discovery Service (formally the SM-DS, Subscription Manager Discovery Service) is the directory mechanism that lets an eUICC find out which SM-DP+ server has profiles waiting for it, without the user having to manually enter the SM-DP+ address. The eUICC queries the Discovery Service at activation or periodically; the Discovery Service returns the SM-DP+ address(es) with pending events; the eUICC then connects to the SM-DP+ to download the profile. The GSMA operates the root Discovery Service for the public eSIM ecosystem, and operators / SM-DP+ providers register their pending events against it. The Discovery Service is what makes activation-code-free eSIM activation possible and is fundamental to OEM-led eSIM enrolment flows.
What is the eIM in SGP.32 and how does it work?
The eIM (eSIM IoT Manager) is the new SGP.32 actor that issues remote profile-management commands to IoT devices. It sits at the platform layer (operator IoT platform, MVNO platform, or enterprise IoT-management platform) and signs commands that instruct devices to download, enable, disable, or delete profiles. The IPA (IoT Profile Assistant) on the device receives and executes the eIM’s commands, replacing the consumer-style LPA. The eIM model removes the push-based SM-SR architecture of SGP.02 (which required the SM-SR to maintain reachable connectivity to every managed eUICC) and replaces it with a pull-or-push model where the IPA polls or accepts commands from the eIM. The eIM is the SGP.32 mechanism that makes IoT-scale eSIM management commercially viable.
When should an IoT integrator use SGP.32 versus SGP.02?
SGP.32 is the strategic direction for new IoT eSIM deployments — it is the GSMA’s designated next-generation IoT architecture and has broader operator and vendor support roadmaps than continued SGP.02 work. For greenfield IoT deployments designing in 2026 with deployment in 2026-2027, SGP.32 is the default choice if your eUICC vendor, operator, and IoT-platform partners support it. For ongoing deployments already in production on SGP.02, SGP.02 continues to work and there is no GSMA-mandated migration; the SGP.02 ecosystem is in maintenance rather than active development. The pragmatic rule is: greenfield should be SGP.32, in-production SGP.02 stays on SGP.02 unless there is a specific feature pull (e.g. headless devices that benefit from the eIM architecture).