SGP.22 vs SGP.32 — what the eSIM standard shift means for travel connectivity

Goal: Give travel eSIM buyers and travel/MVNO operators a standards-literate map of consumer vs IoT Remote SIM Provisioning—so industry talk about “the next eSIM standard” does not blur two different roads.

Audience: Practitioners who ship or buy consumer travel connectivity (and anyone evaluating adjacent IoT/travel hardware), not GSMA committee members.

If you buy a travel eSIM, scan a QR code, and land with data, you are already inside a GSMA Remote SIM Provisioning (RSP) architecture—even if you never see the specification numbers. Those numbers matter. SGP.22 is the consumer RSP technical standard behind smartphone and travel eSIM flows. SGP.32 is the IoT RSP technical standard for headless, constrained, and fleet-scale devices. They share some building blocks. They solve different problems.

That distinction is easy to blur in marketing decks. It is also the difference between a traveler installing a temporary profile on a phone and an enterprise orchestrating connectivity across thousands of sensors that will never see a screen. For travel brands, MVNOs, and anyone building on consumer eSIM stacks, knowing where SGP.22 ends and SGP.32 begins is table stakes—not because travelers need GSMA PDFs, but because the industry conversation often mixes consumer and IoT roads.

This piece maps architecture, actors, lifecycle differences, and practical implications for travel connectivity—without treating SGP.32 as a drop-in upgrade for consumer roaming.

Why the industry needed more than one eSIM “standard” #

eSIM is not one protocol. It is a family of GSMA specifications that define how operator profiles are securely prepared, delivered, installed, enabled, disabled, and deleted on an eUICC (the embedded SIM platform).

GSMA’s public specification index makes the split explicit: consumer RSP sits under SGP.21 (architecture) and SGP.22 (technical); IoT RSP sits under SGP.31 (architecture and requirements) and SGP.32 (technical). Active consumer releases continue through SGP.22 v2.x and v3.x; IoT releases continue through SGP.31/SGP.32 v1.x, including newer 2024–2026 revisions on GSMA’s eSIM specification page (GSMA eSIM Consumer and IoT Specifications).

Before SGP.32, IoT and M2M remote provisioning largely lived in an earlier machine-to-machine model (SGP.02), with a dual-server split of SM-DP (data preparation) and SM-SR (secure routing). That model enabled remote profile management for industrial and automotive use cases, but it also brought operational friction: SMS-oriented triggers, tighter SM-SR/SM-DP commercial coupling, and a poor fit for highly constrained LPWAN devices. Operator and IoT-platform explainers consistently cite those constraints as the reason GSMA built a dedicated IoT architecture rather than forcing consumer RSP onto every modem (Eseye on SGP.31/32; 1oT on SGP.02 vs SGP.22 vs SGP.32).

Short version: one physical form factor (eSIM/eUICC), multiple provisioning philosophies.

SGP.22 in plain terms: consumer RSP for devices with a human in the loop #

SGP.22 is GSMA’s technical description of Remote SIM Provisioning for consumer devices. Its purpose is unambiguous: a technical solution for remote provisioning and management of the eUICC in consumer devices, aimed at interoperability across operator deployments—including SM-DP+ platforms and eUICC vendors.

Core actors in the consumer model #

Actor roles #

• eUICC: Secure platform that stores profiles (operator credentials and related components)
• LPA (Local Profile Assistant): On-device (or partly on-eUICC) assistant that drives download, local enable/disable/delete, and user-facing profile management
• SM-DP+: Subscription Manager – Data Preparation +: prepares, protects, and delivers Bound Profile Packages
• SM-DS: Subscription Manager – Discovery Service: optional discovery path when the device needs to find the right SM-DP+ without a QR/activation code
• Operator / profile issuer: Owns the commercial subscription behind the profile

In the flow travelers recognize:

1. Purchase a travel plan and receive an activation code (often as a QR).
2. The device LPA contacts the SM-DP+.
3. The encrypted profile package is downloaded and installed on the eUICC.
4. The user enables the profile (and can later disable or delete it).

This is a user-initiated / pull-oriented model. A person is present, the device has a UI, and consent is an explicit install action. That is why travel eSIM checkout, airline/fintech partnerships, and app-based activation all map to SGP.22-class consumer RSP—not IoT fleet orchestration.

HTTPS/TLS transport fits smartphones. It is heavier than many IoT duty cycles can afford, but reasonable for a handset that already maintains IP connectivity and a full security stack.

SGP.32 in plain terms: IoT RSP for devices that cannot tap “Add eSIM” #

SGP.32 is the technical specification for GSMA’s eSIM IoT architecture defined in SGP.31. GSMA describes it as covering remote provisioning and management of the eUICC in IoT devices that are network constrained and/or user-interface constrained, plus the eUICC architecture, interfaces, and security functions for that model.

Core actors in the IoT model #

Actor roles #

• eUICC: IoT-capable eUICC that stores profiles and supports IoT remote-management associations
• IPA (IoT Profile Assistant): Device- or eUICC-side assistant that executes provisioning/management work without a consumer UI; may be IPAd (on device) or IPAe (on eUICC)
• eIM (eSIM IoT Remote Manager): Cloud/orchestration entity that issues profile lifecycle operations for a device or a fleet
• SM-DP+: Reused from the consumer ecosystem for profile preparation and protected delivery
• SM-DS: Discovery role retained where relevant
• Operator: Profile source, as in consumer RSP

The architectural intent is consistent across GSMA materials and industry walkthroughs: keep what already worked in consumer RSP (notably SM-DP+), and replace the human/LPA assumption with a remote manager plus an IoT-native assistant (Velocity IoT standards explainer; 1oT comparison).

Why IoT needed a different model #

Consumer RSP assumes:

• a screen or companion UX,
• a person who can start the download,
• relatively stable IP connectivity for TLS sessions,
• per-device, user-driven lifecycle decisions.

IoT fleets often assume the opposite:

• no UI,
• intermittent or low-bandwidth connectivity (including LPWAN scenarios),
• asynchronous check-ins rather than always-on sessions,
• policy-driven enable/disable/delete across many EIDs at once.

SGP.31/32 therefore introduces fleet-oriented profile state management and an eIM that can trigger or proxy downloads. Industry analyses also emphasize lightweight protocol options (for example CoAP/DTLS as an alternative path for constrained devices), removal of SMS as a hard dependency for modern IoT RSP, and support for direct vs. indirect profile delivery depending on whether the device can speak comfortably to the SM-DP+ itself (Eseye; 1oT).

Critically, SGP.32 is not a backwards-compatible “software upgrade” for every SGP.02 eUICC already in the field. Eseye and other IoT specialists note that M2M-standard deployments typically remain on that model through end of life; greenfield IoT is where SGP.32 is designed to become the default.

SGP.22 vs SGP.32: structured comparison #

Dimension-by-dimension comparison #

Primary GSMA pair

• SGP.22 (consumer RSP): SGP.21 architecture + SGP.22 technical
• SGP.32 (IoT RSP): SGP.31 architecture/requirements + SGP.32 technical

Designed for

• SGP.22 (consumer RSP): Smartphones, tablets, wearables, consumer devices with UI
• SGP.32 (IoT RSP): Headless / UI-constrained / network-constrained IoT devices and fleets

Human in the loop?

• SGP.22 (consumer RSP): Yes — user initiates or confirms install/switch
• SGP.32 (IoT RSP): No — eIM/IPA orchestrate operations remotely

Local assistant

• SGP.22 (consumer RSP): LPA
• SGP.32 (IoT RSP): IPA (IPAd or IPAe)

Remote orchestration

• SGP.22 (consumer RSP): Limited / not the design center
• SGP.32 (IoT RSP): eIM as first-class remote manager

Profile server

• SGP.22 (consumer RSP): SM-DP+
• SGP.32 (IoT RSP): SM-DP+ (reused)

Discovery

• SGP.22 (consumer RSP): SM-DS (optional in many flows)
• SGP.32 (IoT RSP): SM-DS retained in the architecture

Trigger model

• SGP.22 (consumer RSP): Predominantly pull (QR / activation code / app)
• SGP.32 (IoT RSP): Push and/or pull via eIM and device check-in patterns

Transport posture

• SGP.22 (consumer RSP): HTTPS/TLS-centric consumer IP stack
• SGP.32 (IoT RSP): IP-based; constrained-device options emphasized (e.g., CoAP/DTLS paths in industry summaries of the spec)

Predecessor pain it addresses

• SGP.22 (consumer RSP): Physical SIM swaps and operator lock-in on consumer hardware
• SGP.32 (IoT RSP): SGP.02 operational lock-in, SMS dependency, and poor constrained-device fit

Travel eSIM relevance

• SGP.22 (consumer RSP): Direct — this is the stack behind typical phone travel eSIM installs
• SGP.32 (IoT RSP): Indirect — shapes adjacent IoT/travel-hardware ecosystems, not phone QR flows

Profile lifecycle: same verbs, different grammar #

Both worlds talk about download, install, enable, disable, and delete. The grammar differs:

• SGP.22 lifecycle is local and user-centric. Once installed, the traveler (or LPA UI) decides when a profile is enabled for roaming data, when it is paused, and when it is removed.
• SGP.32 lifecycle is remote and policy-centric. The eIM can issue profile state management operations across one EID or many, and the IPA executes them when the device is reachable—important for devices that sleep most of the day.

That is why “profile switching” means different commercial things in each world. In consumer travel, switching is often a new purchase or a second installed profile the user selects. In IoT, switching is an estate operation: change connectivity provider, respond to coverage, or rotate profiles without a truck roll.

Where earlier IoT specs fit: SGP.02 and SGP.31 #

A clean mental model:

1. SGP.02 — original M2M RSP with SM-DP + SM-SR. Foundational, still present in long-lifecycle estates (notably automotive and other factory-bound deployments), but increasingly treated as legacy for new constrained IoT projects (1oT).
2. SGP.22 — consumer RSP that simplified provisioning around SM-DP+ and LPA; the mass-market path for phones and travel eSIM.
3. SGP.31 / SGP.32 — IoT RSP that reuses SM-DP+ while adding eIM + IPA for headless fleet management.

SGP.32 did not appear because consumer eSIM “failed.” It appeared because consumer eSIM succeeded for humans—and that success still does not solve a sensor bolted inside a shipping container.

Implications for travel eSIM, consumer roaming, and MVNO stacks #

Travel connectivity remains a consumer RSP story #

For phones and most traveler devices, the operative standard remains SGP.22-class consumer RSP. The product experience travelers care about—buy before departure, install via QR or app, land connected—maps to LPA ↔ SM-DP+ flows, not eIM fleet commands.

GSMA’s own 2026 industry commentary frames travel connectivity as a structural shift in international roaming: app-based eSIM travel offers are more transparent and flexible, and distribution moves closer to the end user before the trip starts (GSMA: eSIM mass market deployment moves from forecast to fact). That commercial shift rides on consumer RSP maturity and handset support, not on IoT eIM rollout.

What SGP.32 *does* change for travel-adjacent ecosystems #

Even if travelers never touch SGP.32, the standard matters at the edges of travel:

• Connected luggage trackers, fleet vehicles, logistics sensors, and venue IoT increasingly need remote profile management without a QR ceremony.
• Travel routers and some “eSIM hardware” can sit in a messy middle: consumer-style activation for a human owner, but operational needs that look more fleet-like at scale.
• Operators and MVNOs may run both consumer SM-DP+ estates and IoT eIM estates. Sharing SM-DP+ DNA between SGP.22 and SGP.32 is intentional; it does not mean the two device classes share the same UX or certification path.

Multi-IMSI, MVNO stacks, and truthful boundaries #

Multi-IMSI (multiple identities selectable within or alongside a connectivity product) and eUICC profile download are often discussed together, but they are not the same mechanism. Multi-IMSI can improve network attachment behavior inside a commercial offering; eUICC RSP (SGP.22 or SGP.32) is about securely installing and managing full operator profiles on the eUICC. Travel brands and MVNOs may combine both techniques commercially, but architecture clarity still matters: consumer travel installs on phones are judged by SGP.22 interoperability and activation UX; IoT estates are judged by eIM/IPA operability and constrained-network resilience.

A useful caution from the IoT side also applies commercially: technical portability in a specification does not automatically equal commercial portability in a contract. SGP.32 reduces certain architectural lock-in patterns associated with SGP.02, but provider commercial terms still determine how freely fleets can move eIM associations or external SM-DP+ relationships (1oT). Consumer travel buyers face an analogous lesson at smaller scale—interoperable RSP does not, by itself, guarantee identical coverage quality, fair-use policy, or support experience across providers.

Market timing and adoption signals (public, 2025–2026) #

Public GSMA materials in 2026 describe consumer eSIM entering operational scale rather than proof-of-concept. According to GSMA’s May 2026 summary of GSMA Intelligence figures, global eSIM smartphone penetration was about 5% at end-2025, with a stated path to about 10% by end-2026, and further growth thereafter; the same piece cites roughly three in four / 73% of mobile network operators offering commercial smartphone eSIM, while noting the remaining gap between availability and active consumer activation (GSMA mass-market eSIM article).

On the IoT side, the same GSMA commentary highlights SGP.32 as a structural enabler for global product variants and in-field profile switching—language that matches how IoT platforms position the standard. Specification maturity is also visible in GSMA’s public tables: SGP.31/SGP.32 continue to advance through active v1.2 and newer v1.3 listings in 2024–2026, alongside associated test specifications (GSMA specification index).

Interpretation without overclaiming: consumer travel eSIM is already a scaled commercial use case on SGP.22 rails; SGP.32 is the parallel industrialization of IoT RSP. They reinforce the broader eSIM story without substituting for each other.

What travelers and brands should take away #

For travelers #

You do not need to choose between SGP.22 and SGP.32 when you buy a travel plan. If you are installing an eSIM on a phone via QR code or app, you are in the consumer RSP world. What you should care about is practical: device compatibility, install reliability before departure, destination coverage, transparent fair-use terms, and support when something fails at the gate.

Providers such as Roamify sit in that consumer travel layer—destination plans, digital install, and stay-online-abroad utility—rather than in industrial eIM fleet management. The standards story behind the QR is still SGP.22-shaped.

For travel brands, OTAs, fintechs, and consumer MVNOs #

• Treat SGP.22 interoperability and activation UX as the product foundation.
• Do not market “SGP.32” as a traveler-facing upgrade unless your actual hardware/fleet architecture uses IoT RSP.
• If you sell or white-label connectivity for trackers, routers, or B2B travel hardware, separately evaluate whether the device class needs consumer LPA flows, IoT eIM flows, or a staged hybrid.
• Invest in education: GSMA’s own market commentary still points to a gap between eSIM availability and consumer understanding/activation. Clear install guidance remains a competitive differentiator.

For operators and connectivity platforms #

Running consumer and IoT RSP side by side is increasingly normal. Shared SM-DP+ heritage helps, but certification, security accreditation, device agents (LPA vs IPA), and commercial operating models remain distinct. Mixing the vocabularies in public messaging creates false expectations for both travelers and enterprise buyers.

Conclusion: two standards, one eSIM narrative—keep the lanes clear #

SGP.22 and SGP.32 are not rivals on a single leaderboard. They are answers to two device realities:

• SGP.22 assumes a person is present and can pull a profile onto a consumer device. That is the architecture behind modern travel eSIM on phones.
• SGP.32 assumes the device is alone—or asleep—and needs remote, fleet-capable management through eIM and IPA, while still reusing SM-DP+ profile delivery. That is the architecture GSMA built for constrained IoT after SGP.02’s limits became obvious.

For travel connectivity, the strategic lesson is precision. The consumer RSP path is already reshaping how people buy roaming. The IoT RSP path is reshaping how machines stay connected for years. Brands that keep those lanes clear will explain eSIM more credibly—and build products that match the standard they are actually shipping.

Soft brand note: Roamify is a travel eSIM provider offering plans across many destinations with digital activation for compatible phones. This article is standards education, not a claim that Roamify implements IoT SGP.32 fleet management.