eSIM Fragmentation: Why Carriers Still Can't Agree on a Standard

💡 TL;DR (Too Long; Didn't Read)

Key takeaways in 60 seconds:

Standards Fragmentation: The GSMA has published three distinct eSIM provisioning standards (SGP.22, SGP.32, TS.43). In practice, none are universally supported, creating incompatible configuration requirements across carriers.

The Activation Gap: While 73% of mobile operators claim eSIM support, fewer than half have the backend entitlement or IoT remote management servers needed to activate headless devices without manual intervention.

Regulatory Barriers: Bans on permanent roaming in key growth markets like Brazil (ANATEL's 90-day rule), India, and China require software-driven local profile switching (eIM) to ensure compliance.

Engineering Strategy: Teams must decouple global hardware SKUs from carrier contracts, prioritizing SGP.32-ready eUICC hardware and partnering with compliant MVNOs to navigate carrier-specific gaps.

The Standard That Ate Itself

The GSMA has a fragmentation problem, and it is entirely self-inflicted.

Between 2016 and 2025, the organization published three separate eSIM provisioning specifications: SGP.22 for consumer devices, SGP.02 for M2M IoT, and SGP.32 as the next-generation IoT replacement. It then layered GSMA TS.43 on top for cross-device profile transfers. Each spec solved a real problem. Each spec also created new incompatibilities with the others.

Verified SourceGSMA eSIM Standards

GSMA — eSIM Technology Overview and Standards. The authoritative source for SGP.21, SGP.22, SGP.32, and TS.43 specification documents, including conformance test plans and the GSMA Certificate Issuer (CI) infrastructure.

Today, Juniper Research counts approximately 1.5 billion eSIM-capable devices active globally in 2026. GSMA Intelligence projects that eSIM smartphone penetration will hit 10% of the global installed base by year end, with 4.9 billion eSIM smartphone connections expected by 2030. The market is enormous, growing fast, and operationally fractured in ways that most engineering teams discover only after their first production deployment fails.

Verified SourceGSMA Intelligence

GSMA Intelligence — eSIM Smartphone Forecast to 2030. Primary source for 10% 2026 penetration projection and 4.9 billion 2030 connection forecast.

ReportedJuniper Research

Juniper Research — eSIM Connections to Exceed 1.5 Billion Globally in 2026 (2025 forecast). Widely cited industry press release; methodology not publicly audited. Treated as directional indicator, not audited figure.

This is not a story about vaporware standards. All three specs have production deployments. The fragmentation exists precisely because each spec reflects a different set of trade-offs made at different points in time, for different device categories, by different working groups inside the GSMA — and carriers have implemented them in different combinations, at different fidelity levels, on different timelines.

If you are building a connected device that needs to work across multiple carriers or multiple countries, you are not choosing a standard. You are choosing which set of limitations you can live with.

What the GSMA Actually Published (and What It Left Undefined)

Understanding the fragmentation requires reading the standards as an implementation engineer, not as a standards body author. The specs define architecture. They do not define every edge case, error code behavior, or inter-carrier integration protocol. That gap is where fragmentation lives.

SGP.22: The Consumer Standard That Became the Default

SGP.22 (along with its architecture spec SGP.21) was released in 2016 for smartphones, smartwatches, and tablets. Its core architecture is a "pull" model: the device, guided by a user, initiates the profile download.

The key actors in the SGP.22 ecosystem are:

SM-DP+ (Subscription Manager - Data Preparation+): The carrier's secure vault. It generates, encrypts, and stores subscriber profiles, waiting for download requests.
SM-DS (Subscription Manager - Discovery Server): A global routing layer. When a device needs to fetch a profile, it queries the SM-DS to discover which SM-DP+ holds its profile. GSMA operates the root SM-DS; carriers can operate cascaded secondary SM-DS servers.
LPA (Local Profile Assistant): The software component on the device, typically embedded in the operating system, that orchestrates the communication between the eUICC chip and the remote servers.

The SGP.22 flow is deterministic when it works: scan a QR code, the LPA contacts the SM-DS, discovers the carrier's SM-DP+, establishes a mutually authenticated TLS session using certificates from the GSMA CI (Certificate Issuer), downloads the encrypted profile, and installs it on the eUICC. The entire sequence is user-triggered and assumes a device with a screen, user input capability, and a stable internet connection.

That assumption is where every IoT deployment breaks down.

SGP.02: The M2M Standard That Created Vendor Lock-In at Industrial Scale

The older SGP.02 standard (with SGP.01 as its architecture spec) was designed for the M2M market: automotive telematics, smart meters, point-of-sale terminals. It uses a "push" model, where the carrier's infrastructure sends profile updates to the device.

The SGP.02 architecture replaces SM-DP+ with SM-DP and adds a new actor: the SM-SR (Subscription Manager - Secure Routing), which manages the secure channel to each device's eUICC and orchestrates profile operations.

Here is the critical problem: to switch carriers under SGP.02, the current carrier's SM-SR (the "donor") must establish a real-time connection with the new carrier's SM-SR (the "recipient") to transfer custody of the profile download authorization. This requires bilateral commercial agreements between carriers, custom API integrations, and ongoing operational coordination.

The result is that SGP.02 deployments are effectively locked to the carrier that provisioned the device at the factory. Switching carriers requires either physical SIM swap or a bilateral inter-carrier integration that most carriers have not built with most other carriers. For a fleet of 50,000 smart meters deployed across three countries, this is not a theoretical limitation. It is a multi-million-dollar problem.

SGP.32: The IoT Standard That Arrived Late and Is Still Rolling Out

SGP.32 was released in 2022 and reached commercial production deployments in late 2024 and 2025. It was explicitly designed to solve the SGP.02 lock-in problem and the SGP.22 user-interaction problem simultaneously.

The architecture introduces two new components:

eIM (eSIM IoT Remote Manager): The enterprise-facing control plane. Instead of requiring inter-carrier SM-SR coordination, the eIM acts as an intermediary that can issue profile management commands to devices across any carrier's network. The enterprise operates or contracts with the eIM; the eIM communicates with carriers via standardized interfaces.
IPA (IoT Profile Assistant): A lightweight client on the device, optimized for constrained hardware. Unlike the LPA in SGP.22, the IPA is designed for devices running NB-IoT or LTE-M, with limited memory, intermittent connectivity, and no battery budget for protocol overhead.

SGP.32 replaces the legacy SMS-based OTA (Over-The-Air) command channel with IP-based protocols, specifically CoAP (Constrained Application Protocol) over DTLS (Datagram Transport Layer Security). This reduces per-operation power consumption from roughly 50 mJ (for a full SMS OTA round-trip on a constrained device) to approximately 3 to 5 mJ for a CoAP/DTLS exchange, a reduction that matters enormously for a battery-powered sensor targeting a five-year deployment life.

The standard also enables "bootstrap" connectivity: a device ships from the factory with a temporary provisional profile that provides enough connectivity to download its production profile from the eIM. The device never needs a physical SIM swap. The carrier assignment happens in software, triggered by the eIM when the device first comes online.

This is the zero-touch deployment model the industry has been chasing since SGP.02 made it impossible.

The Activation Gap: Why 73% Support Means 40% Capability

Here is the measurement problem that sits at the center of the eSIM fragmentation story.

GSMA research in 2025 found that 73% of mobile network operators globally claim eSIM support. The number is technically accurate and operationally misleading in equal measure. What "support" means varies enormously by carrier:

Verified SourceGSMA eSIM Compliance Report 2025

GSMA — eSIM Compliance Report 2025. Primary source for the 73% MNO claim rate and analysis of the activation gap between operator self-reported support and operational provisioning capability.

Support Level	What It Means in Practice	Estimated % of MNOs
Level 1: Profile delivery	Can push a profile to a compatible device	~73%
Level 2: Full consumer flow	QR code + OTA + activation without store visit	~55%
Level 3: Automated enterprise provisioning	API-driven bulk provisioning for IoT fleets	~30%
Level 4: SGP.32 / eIM integration	Full push-based headless device support	~15%
Level 5: TS.43 cross-platform transfer	Seamless iOS/Android eSIM profile transfer	~20%

The gap between Level 1 and Level 4 is the activation gap. An enterprise deploying 10,000 smart agriculture sensors across Germany, Brazil, and Japan needs Level 4 from every carrier in every country. Finding even one SGP.32-capable carrier per country is a challenge in 2026. Finding two for redundancy is harder. Finding three with competitive pricing is, in many markets, still not possible.

The reasons for the gap are not primarily technical. The SGP.32 specification is complete. The Trusted Connectivity Alliance (TCA) has published conformance test suites. Qualified eUICC manufacturers exist. The gap is commercial and organizational: carriers have not invested in upgrading their provisioning infrastructure because the enterprise IoT market, while growing, has not yet generated the revenue pressure required to move large carrier organizations at the pace that enterprise customers need.

Regulatory Fragmentation: When Standards Are Not the Problem

Even if every carrier in the world implemented SGP.32 perfectly, engineers deploying IoT devices globally would still face a second, entirely separate fragmentation layer: national regulatory regimes governing permanent roaming.

Permanent roaming is the practice of a device using a foreign eSIM profile indefinitely on a domestic network, without ever registering with a local carrier. It is economically attractive for enterprises (one global carrier relationship, one contract, one platform) and legally prohibited or heavily restricted in at least 40 countries.

Brazil: The 90-Day Clock

ANATEL, Brazil's telecommunications regulator, defines permanent roaming as continuous use of a foreign profile on Brazilian networks for more than 90 consecutive days. After 90 days, carriers are required to block or deactivate the connection. ANATEL has also mandated biometric identity validation for remote eSIM provisioning, adding a KYC (Know Your Customer) layer that most enterprise platforms are not designed to handle for headless devices.

Verified SourceANATEL Resolução nº 765

ANATEL — Resolução nº 765, de 18 de novembro de 2021. Brazilian regulatory primary source establishing the 90-day permanent roaming definition and biometric provisioning requirements for eSIM activations.

The SGP.32 solution is automatic profile localization: when a device enters Brazil for the first time, the eIM detects the location, triggers a profile switch to a Brazilian carrier, and the device is now operating on a local profile. In theory, this happens before the 90-day clock ever starts. In practice, it requires the enterprise to have a commercial agreement with a Brazilian MNO, and that MNO must have a functional eIM integration and a compliant provisioning flow.

Claro Brasil, Vivo (Telefonica Brasil), and TIM Brasil all offer eSIM provisioning for enterprise customers, but their SGP.32 readiness as of mid-2026 is at Level 2 to Level 3 in the taxonomy above, not Level 4. Engineers deploying to Brazil in 2026 are typically relying on specialized MVNOs (Mobile Virtual Network Operators) with ANATEL-compliant local profiles and pre-negotiated roaming agreements that handle the regulatory transition automatically.

India: The TRAI KYC Firewall

India's Telecom Regulatory Authority (TRAI) effectively prohibits permanent roaming through a different mechanism: mandatory KYC registration for all SIM activations, including eSIM provisioning. Every subscriber, including every IoT device, must be linked to a registered identity in Indian regulatory databases.

Verified SourceTRAI India M2M Recommendations

TRAI — Telecom Regulatory Authority of India, Recommendations on Usage of Embedded SIM for Machine-to-Machine (M2M) Communications (March 2024). Primary source for India's KYC mandate and M2M licensing requirements affecting eSIM provisioning.

For consumer devices this means Aadhaar-linked eKYC. For M2M and IoT devices, it means registered M2M service providers operating within India's licensing framework. The TRAI M2M roadmap explicitly requires local profile provisioning for devices operating in India beyond short-term durations.

The practical consequence for engineers is that global IoT platforms that lack direct TRAI-compliant M2M partnerships cannot legally operate long-term in India at all, regardless of how well their eSIM technology works.

China: Sovereignty Over Connectivity

China's approach is the most restrictive: a combination of "Great Firewall" data sovereignty requirements, mandatory identity registration tied to Chinese national ID numbers or business licenses, and strict controls on which SM-DP+ servers can provision profiles for devices operating in China.

Foreign eSIM profiles may operate on a short-term roaming basis, but long-term deployment of IoT devices in China without domestically provisioned profiles is legally precarious. Chinese carriers operating under MIIT (Ministry of Industry and Information Technology) supervision have invested heavily in domestic eSIM infrastructure, but that infrastructure is intentionally isolated from global SM-DS and SM-DP+ networks.

The engineering consequence is that a single global eSIM deployment strategy cannot include China. China requires a separate, domestically anchored provisioning stack with carriers operating inside the Chinese regulatory environment.

The TS.43 Transfer Problem: Consumer Fragmentation in Plain Sight

While enterprise engineers wrestle with the regulatory maze, consumer device engineers face their own standards fragmentation through GSMA TS.43.

TS.43 defines the "On-Device Service Activation" (ODSA) framework for transferring eSIM profiles between devices, including cross-platform transfers between Android and iOS. When it works, the user experience is elegant: both phones in proximity, a few taps, and the eSIM profile moves from the old phone to the new one. No carrier store visit. No QR code. No customer support call.

The catch is the entitlement server requirement. For a TS.43 transfer to succeed, both the source device and the target device must be supported by the carrier's Entitlement Server, a backend system that authenticates the transfer request, validates device eligibility, invalidates the old profile, and authorizes the new one.

Android 16 and iOS 26 both include native TS.43 transfer flows in their device setup wizards. But the device is only half the equation. Carrier entitlement server deployment is patchy:

Carriers that have invested in full TS.43 infrastructure deliver the "two phones, few taps" experience.
Carriers still on legacy provisioning infrastructure require users to call support, receive a new QR code, and manually re-activate.
Some carriers support TS.43 for same-platform transfers (Android-to-Android or iOS-to-iOS) but not cross-platform transfers, because the handoff protocol between Apple's and Google's implementation layers involves proprietary token exchange mechanisms that require carrier-side configuration for both.

Deutsche Telekom has been among the most aggressive European carriers in TS.43 deployment, implementing full cross-platform transfer capability and serving as a reference implementation for the GSMA's own developer guidance. NTT DOCOMO has deployed TS.43 for intra-ecosystem transfers in Japan, with cross-platform support expanding through 2026. Most mid-tier carriers globally have not yet completed the entitlement server upgrades required for full TS.43 compliance.

Verified SourceDeutsche Telekom eSIM Transfer

Deutsche Telekom — eSIM Transfer Feature Launch and TS.43 Implementation. Carrier-primary source confirming cross-platform GSMA TS.43 entitlement server deployment and user-facing eSIM transfer capability.

The user experience symptom is well-documented on forums and support communities: two eSIM-capable phones, both running current OS versions, both on the same carrier, and the "transfer eSIM" option either does not appear or fails silently. The failure is not a bug in the phone. It is a missing server-side capability at the carrier.

What Engineers Actually Need: A Decision Tree for 2026

Given the three-layer fragmentation (spec choice, carrier implementation depth, regulatory regime), here is a practical framework for making architectural decisions about eSIM connectivity in 2026.

For Consumer Devices (Smartphones, Wearables, Tablets)

Use SGP.22. It is the only spec with broad carrier support, and GSMA TS.43 profile transfer (even if imperfect) is layered on top. The engineering concerns are:

Validate your carrier list against TS.43 entitlement server deployment before committing to a "seamless transfer" feature in your marketing materials.
Plan for QR code fallback. It is not elegant, but it is universal.
For US-only devices, SGP.22 coverage is excellent. For European multi-carrier launches, verify TS.43 support per carrier, per country.

For Industrial IoT (Sensors, Meters, Trackers, POS Terminals)

Target SGP.32, but plan for a hybrid transition period. The eIM architecture is the right long-term choice. The practical steps:

Select an eUICC that is SGP.32 certified by a TCA-recognized test lab. Kigen (Arm's eUICC division), Infineon, and STMicroelectronics all have SGP.32-capable products in production.
Contract with an eIM operator that has production integrations with carriers in your target geographies. Soracom, EMnify (now part of BSQUARE), BICS, and 1ot.com are among the platforms with documented SGP.32 production deployments.
For markets where SGP.32 carrier coverage is thin (most of Latin America, South and Southeast Asia outside India's M2M framework, sub-Saharan Africa), design the provisioning fallback to SGP.22-style OTA with API-triggered activation, accepting that "zero-touch" becomes "minimal-touch" in those markets.

For Regulatory Compliance

The compliance decision tree is geography-first:

Brazil: Budget for a local MVNO partnership or direct agreement with a Brazilian MNO with ANATEL-compliant provisioning. Factor in the 90-day rule from day one of device deployment planning.
India: Engage a TRAI-licensed M2M service provider before the device design is finalized. The KYC requirements affect the provisioning architecture, not just the commercial layer.
China: Treat China as a separate platform. Do not attempt to extend a global eSIM strategy into China. Build a China-specific connectivity module with a domestically licensed carrier.
EU: The regulatory environment is carrier-permissive, but data residency and GDPR requirements affect where SM-DP+ servers and eIM platforms can be hosted. Verify that your eIM operator's data infrastructure is EU-compliant.

Conclusion: One Chip, Three Specs, Forty Countries

The eSIM promise, a single hardware SKU that can be provisioned anywhere on earth, remains technically achievable in 2026. The architecture in SGP.32, combined with a well-structured eIM deployment and a network of carrier partnerships, can deliver a device that provisions itself automatically, switches carriers in response to regulatory requirements, and never needs a physical SIM swap across a deployment life of five or ten years.

The gap between that promise and operational reality is not a technology gap. The specs are complete. The chips are certified. The gap is deployment depth: the 57 percentage points between "claims eSIM support" and "runs a full SGP.32 headless provisioning flow," accumulated carrier by carrier, country by country, through decisions made about infrastructure investment over the last three years.

For engineers, the practical lesson is that eSIM architecture decisions are connectivity strategy decisions disguised as hardware choices. The eUICC you select, the eIM platform you integrate, and the carrier agreements you negotiate before your first prototype is manufactured will determine whether your device works seamlessly in São Paulo, Mumbai, and Tokyo, or arrives in those markets and sits in a customs warehouse waiting for someone to physically flash it with a local SIM.

The standard is not the bottleneck. The rollout is.

External Sources

This article was human-architected and synthesized with AI assistance under the Nexus (AI) persona.