Top Questions on eSIM, Explained

eSIM technology is hitting a new inflection point for both consumer eSIM and IoT eSIM. In the past six months, analysts have highlighted sharp growth signals: ABI Research forecasts 403 million consumer eSIM devices and 140 million IoT eSIM-enabled devices shipping in 2025, with eSIM-enabled device shipments exceeding 633 million in 2026. At the same time, travel eSIM demand is accelerating, with Juniper Research (via industry reporting) projecting travel eSIM revenues reaching $1.8B by the end of 2025—up 85% from 2024. And crucially for global scale, China has begun opening domestic eSIM support, including carrier pilots that unlock the last major smartphone market still constrained by eSIM adoption.

As travel eSIM, eSIM-only smartphones, and eSIM-first smartwatches reach new peaks, the industrial world is also moving forward with an IoT-ready standard: SGP.32, the GSMA “eSIM for IoT” specification for Remote SIM Provisioning (RSP) across diverse, often headless, long-life devices.

Developing with SGP.32 eSIMs for IoT

Here are the top questions spanning SGP.32 IoT eSIMs and consumer eSIMs—answered in one place, starting with a clear definition of SGP.32 IoT eSIM.

Quick level-setting with the definition:

SGP.32 is the GSMA’s new “eSIM for IoT” specification, designed to make remote provisioning work better for real-world IoT constraints: limited UI, intermittent coverage, tight power budgets, and fleets that must run for years with minimal touch. Kigen’s view is simple: if you want IoT connectivity that scales, you need a standards-based path that is secure by design, interoperable across vendors, and practical to integrate on devices that do not behave like smartphones.

“For SGP.32, the focus was on interoperability and simplicity without compromising the main function of the eUICC: security.” – Said Gharout, chair of GSMA eSIM Working group.

This collaborative foundation led to SGP.32 becoming the first truly neutral standard in the eSIM space.

So, let’s dive into your questions:

1) What exactly is SGP.32, and how is it different from SGP.02 (M2M) and consumer eSIM?

Think of SGP.32 as the specification that brings the best parts of “consumer-like” user experience to IoT operations, without pretending your device has a screen, a user, or reliable power.

• SGP.02 (M2M) was built around older operational assumptions and relies on mechanisms that can be awkward for low-power networks. Kigen calls out one practical blocker: SGP.02’s reliance on SMS for profile management, which creates real friction for NB-IoT-class devices.
• Consumer eSIM (often discussed as SGP.22 in industry conversations) fits phones and connected devices in car infotainment, etc, that depend on user-driven setup flows – i.e., the user elects via a UI to accept profile updates. In contrast, SGP.32 targets fleets and “headless” devices.
• SGP.32 (IoT eSIM) focuses on interoperability and scalability for IoT deployments, including support for constrained devices and modern provisioning flows. This is typically for devices that may be headless or without a UI such that profile updates or transitions have to be pushed by the manufacturer or provider.

2) What problem is SGP.32 solving for headless/UI-constrained devices, and what changes operationally?

Two big shifts matter in practice:

1. Provisioning without SMS, which widens what you can reliably support across NB-IoT/LTE-M-type environments and power-saving modes.
2. A more IoT-suitable architecture where remote provisioning and lifecycle operations can be handled efficiently at fleet scale, with the right server-side “source of truth” and device-side assistant.

The point is not “more features.” It is less operational pain: fewer bespoke integrations, fewer edge-case failures in the field, and a clearer standards path from prototype to certification.

3) What are the key new roles/components (eIM and IPA), and what do they do?

SGP.32 introduces a clearer split between fleet-side orchestration and device-side execution:

• eIM (eSIM IoT Manager): the standardized remote manager that coordinates profile lifecycle operations (download, enable/disable, and more) across a device or an entire fleet.
• IPA (IoT Profile Assistant): the device-side component that performs the secure “do the work” functions in an IoT-friendly way. IPA can run on the device (IPAd) or be embedded in the eUICC (IPAe), depending on design constraints.

Kigen’s practical framing: eIM + IPA is what makes standards-based IoT eSIM manageable at scale, especially on constrained devices.

4) How do I migrate from SGP.02 to SGP.32 without disrupting service, especially in mixed fleets?

The safest approach is to treat migration as an operational program, not a “flash cut” rewrite:

• Design for coexistence (SGP.02 devices continue as-is while new SKUs adopt SGP.32).
• Separate “bootstrap connectivity” from long-term operator choice so devices stay reachable while you introduce new provisioning flows.
• Invest early in backend integration (eIM alignment with your connectivity management platform matters, because it is where lifecycle visibility and control lives).

Kigen’s broader guidance is consistent across LPWAN and long-life deployments: minimize in-field heavy operations and plan for lifecycle continuity, especially where battery life and uptime are non-negotiable.

5) What’s the status of SGP.32 adoption, and what should I design to today?

The practical answer: start testing now, design for certification-ready architecture, and validate ecosystem readiness early. Kigen highlights that enterprises that begin testing can align certification timelines with product validation cycles and that certification was anticipated around Q2 2025 in the rollout narrative.

Also, do not assume a provider saying “SGP.32” means full remote profile download and lifecycle support. Kigen explicitly recommends verifying whether your MNO supports true SGP.32 provisioning, versus only preloaded profile options.

6) How can IoT eSIM adoption help with CRA compliance?

The EU Cyber Resilience Act (CRA) expects manufacturers to provide security updates for a support period that is generally at least five years (unless the product is expected to be used for less). It also introduces vulnerability/severe-incident reporting from 11 September 2026, with broader obligations applying from 11 December 2027.

The most authoritative, practical advice: choose an IoT eSIM and hosted eIM that are security-assured and proven in operations—specifically a GSMA SAS-accredited subscription management environment—so you have a credible foundation for long-term, auditable “patch-to-patching” practices. And because SGP.32 supports eIM portability (“eIM swap”), you can retain the option to switch eIMs if you ever need a faster security response or different operational controls without being locked into a single backend.

7) Which consumer devices are eSIM-capable, and are there regional differences?

In consumer products, eSIM support is both device and region/carrier dependent. Apple, for example, notes country and regional differences in eSIM and SIM-tray behavior, and that eSIM availability varies by market.

Practical guidance for end users: check (1) your exact model variant, (2) your carrier’s eSIM support, and (3) local market constraints before you rely on eSIM as your only option.

8) Can I transfer my eSIM from one phone to another?

Yes, in many cases, but the method depends on platform and carrier support:

• On iPhone, carriers may support eSIM Carrier Activation or eSIM Quick Transfer during setup or afterward.
• On Android (including Pixel), Google documents transferring a SIM (physical or eSIM) to a new phone during onboarding, with carrier-dependent flows.
• Samsung also describes “eSIM Instant Transfer” on supported Galaxy devices, again depending on carrier and device state.

You can discuss specific needs for migration of fleets with our experts.

9) How many eSIM profiles can I store, and can I use dual SIM reliably for travel or work/personal?

Most modern phones allow multiple stored eSIM profiles, and many support Dual SIM (e.g., one physical SIM + one eSIM, or in some models two eSIMs). Apple documents Dual SIM configurations and notes that iPhone 13 models and later support Dual SIM with two eSIMs.

Apple also states you can manage “up to eight or more eSIMs” on iPhone, which is a helpful mental model for frequent travelers who keep plans ready-to-switch.