Revolution in eSIM: Why SGP.32 Changes Everything for IoT

For years, the eSIM conversation revolved around smartphones. That era is over. Today, the shift to eSIM is a core architectural decision for anyone deploying millions of connected sensors, trackers, smart meters, cameras, appliances or vehicles.

Yet until recently, the industry faced an uncomfortable truth: neither of the existing GSMA standards truly fit the needs of IoT.

The Old World: Two Imperfect Choices

For nearly a decade, IoT teams had only two Remote SIM Provisioning (RSP) standards to choose from:

• SGP.02 — The original M2M standard
  Powerful, secure, but heavy, rigid, and deeply operator-controlled. Integration was slow, expensive, and often required bespoke engineering.
• SGP.22 — The consumer eSIM standard
  Designed for iPhones and wearables with screens and human interaction—not for headless, power-constrained IoT devices.

Because SGP.02 was too complex for most enterprises, IoT builders did something irrational but pragmatic: they forced SGP.22 into IoT environments. They shipped QR codes inside equipment boxes, created companion apps just to simulate a “remote human,” and relied on fragile bootstrap profiles to get devices online. It worked—but it was never built to scale.

The Breakthrough: SGP.32, the First eSIM Standard Designed for IoT

SGP.32 marks the end of workarounds. It is the first GSMA specification built specifically for headless IoT devices with limited power, memory, bandwidth, and compute.

While it reuses the proven backend of SGP.22 (the SM-DP+), it replaces the consumer-centric Local Profile Assistant with a new IoT-native architecture:

• eIM — IoT Remote Manager (cloud)
• IPA — IoT Profile Assistant (on or near the device)

Together, they enable a push-driven, server-orchestrated model that finally fits the realities of embedded devices. New concepts like the IoT Asset (IAS) and an evolved eUICC manufacturing trust chain (EUM) complete the model.

The result: a modern, scalable, zero-touch provisioning system built for massive IoT.

SGP.22 vs SGP.32: The New Strategic Line

The choice is now clear:

• Use SGP.22
  When you have a rich UI, or when you must integrate with the existing global consumer eSIM ecosystem.
• Standardize new IoT fleets on SGP.32
  To unlock zero-touch provisioning, multi-carrier flexibility, enhanced reliability, and long-term cost control.

Platforms like Spenza are emerging as the unified control plane bridging both worlds—managing consumer flows with SGP.22 while orchestrating fleet-scale IoT deployments with SGP.32.

Why This Matters in 2026 and Beyond

For CTOs, Product Managers, and Connectivity Architects, the difference between SGP.22 and SGP.32 is no longer academic—it’s a defining infrastructure decision. It determines whether your IoT strategy delivers:

• Frictionless onboarding
• Lower operational overhead
• Carrier independence
• Global scale
• Long-term device autonomy

IoT spent a decade contorting consumer technology to fit industrial realities. With the maturity of SGP.32, that compromise is finally over. The industry is entering a new phase—one defined not by workarounds, but by purpose-built, scalable, secure connectivity.

This is the roadmap for the next billion IoT devices. And the transition has already begun.

Why IoT Was Forced to Use Consumer Standards

The Physical SIM Problem

For decades, the physical SIM card defined mobile connectivity. It worked perfectly for smartphones—users could swap carriers, travel internationally, and replace devices with almost no friction.

But for IoT, the physical SIM quickly became a logistical and operational bottleneck.

Imagine manufacturing 100,000 connected vending machines for global deployment. With physical SIMs, you must:

• Choose a mobile operator before manufacturing.
• Manage 10+ hardware SKUs if deploying across 10 countries.
• Accept permanent vendor lock-in—once the SIM is embedded in a sealed device, replacing it requires a costly truck roll.
• Tolerate network gaps: if your chosen U.S. carrier has weak coverage in rural Montana, your device simply goes offline.

IoT needed a way to change carriers remotely and manage connectivity dynamically.
Remote SIM Provisioning (RSP) was the answer—allowing operator profiles to be downloaded and updated over the air.

The GSMA responded with two RSP standards:

• SGP.02 — for M2M/industrial devices
• SGP.22 — for consumer smartphones and wearables

But this split created a structural problem for IoT.

SGP.02: The M2M Standard That Failed

GSMA’s first attempt at IoT eSIM was SGP.02, a “push” model designed for automotive and industrial applications. Its fatal flaw? Architectural rigidity.

In SGP.02, the SM-SR (Subscription Manager Secure Routing) acted as gatekeeper. If you wanted to switch from MNO A to MNO B, MNO B had to integrate with MNO A’s SM-SR—a complex backend process that MNO A had little incentive to facilitate. The alternative, an “SM-SR Swap,” was technically fraught and commercially hostile.

The result: vendor lock-in disguised as a standard. SGP.02 worked for automotive giants with negotiating power, but for the broader IoT market, it was DOA.

SGP.22: The Consumer Standard IoT Hijacked

Launched in 2015, GSMA SGP.22 was designed for iPhones and Android devices. It introduced a “pull” model where users scan QR codes, initiate downloads, and confirm profile activation via on-screen prompts. The architecture assumes:

• A rich user interface with a camera
• A human operator making decisions
• High-bandwidth connectivity (TCP/IP, HTTPS, TLS)

For smartphones, SGP.22 was transformative. Apple’s eSIM adoption in 2018 proved the standard worked at scale. But for IoT? SGP.22 was a square peg in a round hole.

Here is a simplified summary:

In short: IoT needed the flexibility of M2M with the simplicity and ecosystem maturity of SGP.22. That is the gap SGP.32 is designed to fill.

The Paradigm Shift: Enter GSMA SGP.32

What Is SGP.32?

Released in May 2023, GSMA SGP.32 is the first eSIM standard architected specifically for IoT. It’s often described as a “hybrid”—not because it compromises, but because it intelligently combines the best of both worlds:

• The backend infrastructure of SGP.22 (reusing the proven SM-DP+ profile delivery system)
• A new frontend designed for headless devices (introducing the eIM and IPA components)

The genius of SGP.32 is that it virtualizes the user. Instead of requiring a human with a smartphone to trigger downloads, it introduces a server-side “remote user”—the eSIM IoT Remote Manager (eIM)—that pushes commands to devices on behalf of the enterprise.

Key Architectural Components

1. The eSIM IoT Remote Manager (eIM)

The eIM is the fleet commander. It’s a cloud-based platform that maintains device state and issues profile management commands: download, enable, disable, delete.

Critical difference from SGP.02’s SM-SR: The eIM is portable. It can be owned by the IoT enterprise, the OEM, or an independent service provider. This decouples device management from connectivity providers, eliminating vendor lock-in.

Use case: An enterprise managing 50,000 shipping trackers globally can set rules like: “If a tracker enters Singapore, disable the Vodafone profile and enable the Singtel profile.” The eIM detects location changes (via GPS or cell tower data) and orchestrates the switch automatically—no human intervention required.

2. The IoT Profile Assistant (IPA)

The IPA is the device-side agent. It replaces the LPA (Local Profile Assistant) from SGP.22 but has no UI. The IPA listens for commands from the eIM via the ESipa interface and executes them on the eUICC.

Two deployment options:

• IPAd (Device-based): IPA runs on the device’s application processor. Best for complex gateways or routers where deep integration with device logic is valuable.
• IPAe (eUICC-based): IPA resides inside the secure element. Best for constrained devices like sensors or meters where OEMs want to treat connectivity as a black box.

3. SM-DP+ (Reused from SGP.22)

SGP.32 reuses the standard SGP.22 SM-DP+ (Subscription Manager Data Preparation). This is strategic brilliance: any operator supporting consumer eSIMs can support IoT eSIMs without upgrading core infrastructure—provided they allow the eIM to act as the LPA proxy.

This interoperability creates a unified marketplace. IoT devices can access the same global ecosystem of profiles as smartphones.

Technical Innovations That Matter

Protocol Efficiency: CoAP and DTLS

One of SGP.22’s fatal flaws for IoT was its reliance on TCP/IP and HTTPS. These protocols are “chatty”—requiring 3-way handshakes, heavy TLS certificate exchanges, and keep-alive sessions that drain batteries.

SGP.32 introduces support for CoAP over UDP, secured by DTLS:

• CoAP (Constrained Application Protocol): A lightweight web-transfer protocol designed for low-power devices. Maps to HTTP but with a fraction of the header size.
• UDP (User Datagram Protocol): Connectionless; fires packets without session state overhead.
• DTLS (Datagram TLS): Provides encryption without TCP’s baggage.

Impact: For a battery-powered water meter that wakes once a week to transmit readings, switching from TCP/HTTPS to CoAP/UDP can extend battery life by 30-40%. On NB-IoT networks with high packet loss, UDP’s stateless nature prevents the catastrophic retransmission spirals that plague TCP.

Direct vs. Indirect Profile Download

SGP.32 offers two profile delivery modes:

Direct Download (ES9+ Interface): The eIM acts as a trigger. It sends a TriggerProfileDownload command to the IPA with the SM-DP+ address. The IPA opens a direct HTTPS connection to the SM-DP+ and pulls the profile. Best for high-bandwidth devices like connected cars or CCTV cameras with full TCP/IP stacks.

Indirect Download (ES9+’ Interface): The eIM acts as a proxy. The device cannot or should not connect directly to the SM-DP+ (e.g., it’s behind a corporate firewall or only supports CoAP). The eIM retrieves the Bound Profile Package from the SM-DP+, but critically, cannot decrypt it—the package is encrypted end-to-end with the eUICC’s keys (ES8+ interface). The eIM wraps the encrypted blob in a CoAP message and pushes it to the IPA.

Security win: The device never needs to speak HTTPS or DNS. It only talks to the eIM. This minimizes attack surface and simplifies firmware.

Scalability win: Enterprises can manage profile distribution through a single eIM endpoint, abstracting away the complexity of 20+ operator SM-DP+ URLs.

Bootstrap Profiles: Solving the Cold-Start Problem

How do you download a profile if you don’t have connectivity? SGP.32 formalizes the Bootstrap Profile:

• Devices ship with a pre-installed, low-cost generic profile
• On first boot, the device uses the Bootstrap to connect only to the eIM
• The eIM identifies the device (via EID) and automatically triggers download of the Operational Profile
• If the Operational Profile fails or expires, the device falls back to Bootstrap for recovery

This enables zero-touch provisioning: devices auto-configure themselves without human intervention.

SGP.22 vs SGP.32: Deep Technical Comparison

Pros and cons: SGP.22

Pros

• Mature ecosystem, widely supported by operators and devices.
• Simple onboarding for user-facing products.
• Reuses consumer infrastructure that many enterprises already integrate with.
  

Cons

• No native fleet-level control or zero-touch commissioning for headless IoT.
• Heavier protocols and user-centric flows increase power and operational cost.
• Difficult to implement vendor-neutral multi-carrier strategies at scale.

Pros and cons: SGP.32

Pros

• Server-driven, policy-based provisioning ideal for headless IoT.
• Lighter protocol stack that reduces data and power consumption.
• Decouples enterprise control (eIM) from operator infrastructure while reusing SM-DP+.
• Enables multi-carrier and multi-profile strategies with a single fleet-wide orchestrator.
• Aligned with the GSMA’s IoT roadmap (SGP.31/32) and emerging IoT compliance schemes.

Cons

• Requires SGP.32 capable eUICCs and firmware; not backward compatible with legacy SGP.02 hardware.
• The ecosystem is still maturing, with certified devices and full-stack solutions ramping through 2025.

Selecting the Right eSIM: Practical Criteria for Choosing SGP.22 vs. SGP.32

When to Use SGP.22

Stay with SGP.22 when your deployment aligns with traditional consumer-style eSIM activation:

Use SGP.22 if:

• Your devices have a rich UI and app ecosystem (smartphones, tablets, consumer CPE, wearables with screens).
• Your primary requirement is consumer-friendly activation, not automated fleet orchestration.
• You can tolerate manual onboarding steps such as QR codes, in-app activation, or user-driven provisioning.
• Your organisation is already deeply invested in an SGP.22 integration and your fleet size is relatively modest (<10,000 devices).
• You need immediate market availability, as SGP.22 still has broader operator support today.

In these scenarios, SGP.22 remains the fastest path to market, especially for consumer MVNOs or companion-device services.

When to Move to SGP.32

Prioritise SGP.32 when you’re designing large-scale, headless, or highly automated IoT deployments:

Use SGP.32 if:

• You’re deploying headless IoT devices (meters, sensors, gateways, trackers, industrial assets).
• You need remote provisioning at scale, typically 50,000+ devices.
• Per-device physical access or truck rolls are impossible or too costly.
• Your fleet spans multiple countries and operators, and a multi-carrier strategy is central to your business.
• You require automated lifecycle management (profile switching based on network conditions, location, battery, time-of-day, etc.).
• Long battery life on NB-IoT or LTE-M is important.
• You want portability, including the ability to switch eIM providers without losing device control.
• You’re building for 2026 and beyond, where SGP.32 adoption will continue accelerating.

SGP.32 delivers the automation, flexibility, and long-term control needed for modern IoT at scale.

How Spenza Simplifies SGP.22 and SGP.32 Management

Spenza is a connectivity orchestration platform designed to help enterprises, OEMs, and resellers behave like MVNOs without becoming telcos. Operator-neutral and multi-carrier by design, it delivers an API-first SaaS platform with white-label apps and portals, making it a natural choice to consolidate the complexity of SGP.22 and SGP.32 behind a single control plane.

From consumer devices like wearables, security cameras, and asset trackers to enterprise IoT deployments, Spenza supports both legacy and next-generation eSIM standards. Its roadmap includes SGP.32 support alongside existing SGP.22 flows, enabling enterprises to manage mixed fleets seamlessly.

Native Dual-Standard Support

Spenza provides:

• Unified management for SGP.22 and SGP.32 devices in a single dashboard
• API-first lifecycle management for profiles
• Multi-carrier profile marketplace with pre-integrated global operators
• Real-time diagnostics for consumer and IoT fleets

SGP.32-Specific Capabilities

• eIM Integration: Fleet-wide policy orchestration, location-aware profile switching, automated failover, and CoAP/DTLS support for constrained devices
• Zero-Touch Provisioning: Define rules once, deploy everywhere
• Compliance Automation: Pre-built templates for roaming restrictions, GDPR data residency, and regional telecom licenses

Migration Support

Spenza simplifies transitions between standards:

• Brownfield SGP.22 devices managed via LPA proxy integrations
• Greenfield SGP.32 devices orchestrated natively
• Gradual migration without disrupting operations

By natively supporting both consumer and IoT eSIMs, Spenza lets organizations consolidate SGP.22 and SGP.32 management, automate compliance, and scale globally—all from a single, unified platform.

Conclusion: Why SGP.32 is the Future of IoT eSIM Connectivity

SGP.32 represents a paradigm shift in IoT eSIM technology, addressing the limitations of legacy standards like SGP.02 and SGP.22. By enabling headless, zero-touch provisioning, multi-carrier flexibility, and scalable device management, it allows enterprises to deploy millions of connected sensors, meters, trackers, and industrial devices with ease. Its lightweight, secure protocols (CoAP/UDP with DTLS) ensure long battery life, reliable connectivity, and end-to-end security even in constrained IoT networks.

Platforms like Spenza simplify this transition by providing a unified orchestration layer for both SGP.22 and SGP.32, automating profile management, lifecycle operations, and compliance at scale. For CTOs, product managers, and IoT architects, adopting SGP.32 is no longer just a technical upgrade—it’s a strategic decision that determines the efficiency, flexibility, and global reach of future IoT deployments.

FAQs

Ready to modernize your eSIM strategy? Connect with our IoT connectivity experts for a personalized technical deep-dive and ROI analysis.