SGP.32: The IoT eSIM Standard That Changes How Connected Devices Are Managed

What is SGP.32?

SGP.32 is the GSMA standard for remote SIM provisioning designed specifically for IoT devices. It defines the technical architecture for managing eSIM profiles across connected device fleets without physical access, user interaction, or manual configuration. Where earlier eSIM standards were designed for smartphones or legacy M2M deployments, SGP.32 is built for headless IoT devices: sensors, meters, gateways, maritime equipment, and autonomous vehicles that run for years without user interaction or physical access.

The standard introduces two components that did not exist in previous eSIM specifications: the eIM (eSIM IoT Remote Manager) on the server side, and the IPA (IoT Profile Assistant) on the device side. Together they enable a provisioning model driven entirely from the cloud, with no dependency on user action or device-side configuration steps.

Kaleido Intelligence forecasts 240% CAGR for SGP.32 eSIMs through 2028. Commercial deployments are accelerating through 2026, with broader MNO support and completed hardware certification expected to drive volume growth in 2027.

Why the previous standards were not enough

To understand what SGP.32 changes, it helps to know what it replaces.

SGP.02 was the first M2M eSIM standard, published in 2014. It enabled remote SIM provisioning for industrial devices but relied on SMS as a communication channel, required complex bilateral agreements between operators, and was not designed for fleet management at scale. For a device fleet of 10,000 units across 15 countries, the provisioning complexity of SGP.02 outweighed the flexibility it was meant to provide.

SGP.22 solved a different problem. It was designed for consumer devices, primarily smartphones. The provisioning model assumes a user is present: someone scans a QR code, taps through a device menu, or installs a companion app. For IoT devices with no screen, no user, and no interface, SGP.22 does not work as intended. The industry adapted rather than waited: QR codes shipped inside device packaging, companion apps simulated user interaction that the device itself could not provide, bootstrap profiles required activation steps after deployment. None of it worked well past a few hundred devices.

SGP.32 removes those adaptations. It is the first GSMA specification that treats IoT devices as what they are: embedded, headless, often battery-powered, intermittently connected, and deployed in environments where physical access after installation is not part of the operational model.

How SGP.32 works: the architecture

SGP.32 introduces a cleaner separation of responsibilities than previous standards. Three components handle the entire profile lifecycle.

The eIM (eSIM IoT Remote Manager) is the orchestration layer. It sits on the server side and handles all decisions about which profile goes to which device, when, and under what conditions. In practice: the eIM triggers profile downloads, manages profile state, and executes switching logic based on pre-configured business rules. Everything that in earlier standards required manual action or bilateral operator coordination now runs from here.

The IPA (IoT Profile Assistant) is the device-side component, available in two variants. IPAd runs within the device itself. IPAe is embedded directly in the eUICC chip. The IPA handles secure communication with the eIM and executes the profile operations the eIM instructs. It is designed for constrained hardware: limited memory, intermittent connectivity, low power budgets.

The SM-DP+ (Subscription Manager Data Preparation+) is the profile preparation backend, inherited from SGP.22. It prepares, stores, and delivers operator profiles. In SGP.32, the SM-DP+ no longer acts as a controlling party toward the device. Profiles are held until the eIM requests them. The SM-DP+ executes; the eIM decides.

The architecture is push-driven and server-orchestrated. Decisions about connectivity happen centrally. The device receives instructions and executes them. It does not need to know which operator it will connect to before it ships.

Zero-touch provisioning: what it means in practice

Zero-touch provisioning is the operational capability SGP.32 makes possible at IoT scale. A device ships from the factory with a bootstrap profile: a minimal connectivity credential that gives it enough network access to contact the eIM on first power-on. Once the eIM is reached, it identifies the device, checks its deployment rules, and pushes the correct operational carrier profile. The device connects on the right network, in the right country, with the right data plan, without anyone handling it between the factory floor and the deployment site.

A device manufacturer shipping 50,000 smart meters across Europe no longer sources SIMs per country: one hardware SKU ships everywhere, the eIM handles local activation on first power-on. An IoT reseller managing fleet trackers across 30 markets sees new devices go live without a provisioning step in the field. On vessels rotating between flag states and territorial waters, carrier profiles update automatically as position changes. In each case, the operational step that previously required human intervention disappears.

What SGP.32 means for the partner and reseller channel

Most of the published content on SGP.32 addresses device manufacturers, chip vendors, and network operators. The partner and reseller perspective is largely absent from that conversation, which is notable because partners are the distribution layer through which most IoT connectivity reaches end customers.

The changes SGP.32 introduces affect the partner proposition directly, and not just technically.

Global deployments from a single product. Before SGP.32, offering global IoT connectivity as a reseller meant sourcing local SIMs per country (multiple supplier relationships, multiple invoices, per-country logistics) or accepting the coverage and regulatory constraints of permanent roaming. SGP.32 removes both. A partner can offer one SIM product that works everywhere, activates automatically in the correct regulatory context, and manages itself across its operational lifetime.

A managed service that is harder to replicate. A partner offering zero-touch provisioning, automated carrier switching, and over-the-air profile management as part of a managed connectivity package is offering something that competitors without eIM infrastructure cannot match. The operational value is concrete: fewer field visits, fewer support escalations, faster onboarding, and the ability to add countries or carriers to a live deployment without touching deployed hardware.

Permanent roaming compliance without the operational overhead. Regulations in markets including Brazil, India, Turkey, and several EU member states restrict permanent roaming for IoT SIMs. Without SGP.32, managing compliance across these markets means separate SIM products per market or multi-IMSI approaches that add complexity. With SGP.32-compliant eIM infrastructure, local carrier profiles are pushed automatically when a device enters a regulated market. Compliance is maintained without manual intervention, across every market in the deployment.

The eSIM Orchestrator role

The eSIM Orchestrator role is distinct from both the carrier and the connectivity management platform, though it works with both.

Carriers own the network. CMPs manage active connections: usage monitoring, alerts, suspension, activation. The eSIM Orchestrator manages the profile layer beneath both. It determines which operator a device uses and updates that decision over the device lifetime, without physical access and without requiring a bilateral agreement between the customer and each individual MNO.

This role emerged specifically with SGP.32 and does not map onto previous market structures. It is not a logical extension of either the carrier or the CMP function. It is a separate layer that sits above the carrier and below the operational dashboard, handling the decisions that neither the carrier nor the standard CMP was designed to make.

TNF operates as an eSIM Orchestrator with direct carrier relationships across 900+ networks in 200+ countries. The IoT portal is the interface through which that orchestration layer is accessible to partners. Profile lifecycle management, zero-touch provisioning, carrier switching, and eIM operations are accessible from the same platform as SIM lifecycle management, billing, and reporting.

SGP.32 and the permanent roaming problem

Permanent roaming regulations represent one of the strongest commercial drivers for SGP.32 adoption. When a device spends its operational life on a foreign network, some regulators require that it eventually connect to a local network. The definition of “eventually” varies by market, but the regulatory exposure is real and has caused connectivity failures for operators who did not plan for it.

Without SGP.32, addressing this means pre-provisioning devices with local SIMs per market, creating hardware complexity and supply chain overhead, or maintaining multi-IMSI solutions that work but are not standardised and require ongoing management.

The eIM monitors deployment context and pushes a local carrier profile when regulatory thresholds are approached. The switch happens without field intervention. For partners selling into regulated markets, this turns a deployment blocker into a managed capability they can include in a standard connectivity package.

SGP.32 adoption: where the market stands

The specification reached maturity in 2023. Hardware certification for eUICC chips with IPAe support progressed through 2024 and 2025. At Mobile World Congress 2026, SGP.32 readiness was described by multiple operators as a defining criterion in enterprise and automotive IoT procurement. Soracom opened pre-orders for its SGP.32-compatible Connectivity Hypervisor in March 2026, citing live automotive field testing as the basis.

The ecosystem is still maturing on the MNO side. Not every operator has completed SGP.32 support on their network, which means the pool of carrier profiles manageable via eIM is still expanding. Partners evaluating SGP.32-based products should verify carrier coverage in their specific deployment markets before making product commitments. A provider willing to share a current list of certified carrier profiles and supported markets is easier to trust than one that speaks only to roadmap.

What to look for in an SGP.32-ready connectivity provider

A number of providers reference SGP.32 in their positioning without having implemented the full architecture. Before committing a deployment, a few things are worth verifying directly.

Whether the provider operates its own eIM or resells access to a third party’s matters for SLA control, provisioning timelines, and the depth of carrier relationships behind the platform. A resold eIM means a dependency on another party’s uptime and commercial agreements.

Integration between the eIM and the connectivity management platform is the difference between one operational interface and two systems that need to stay in sync. If profile lifecycle management and usage monitoring sit in separate tools, the operational efficiency SGP.32 is meant to deliver does not fully materialise.

On the hardware side, whether a provider supports both IPAd and IPAe implementations determines which device designs are compatible with their infrastructure. Providers that only support one limit the hardware options available to their partners and customers.

Finally, certified carrier coverage in specific deployment markets is more useful than a headline network count. The total number of networks a provider accesses says less about SGP.32 readiness than knowing which of those networks have completed eIM certification for the markets where your devices will actually operate.

Three deployments that illustrate the difference

Smart metering, energy sector. Eight thousand monitoring sensors need to go live across sites in Germany, Poland, Romania, and Turkey. All four countries have different carriers and Turkey has permanent roaming restrictions. The manufacturer ships one hardware SKU with a bootstrap profile. Each sensor powers on, contacts the eIM, and receives the correct local carrier profile. Turkey’s regulatory requirement is met without a separate SIM product or a field configuration step. The operations team manages the entire fleet through one platform from day one.

Vessel tracking, Northern European logistics. Two hundred vessels operating between ports in Norway, Denmark, Germany, and the Netherlands need reliable connectivity as they move between territorial waters. Each carrier profile change used to require coordination between the vessel operator and the connectivity provider. Now the eIM tracks vessel position and updates carrier profiles as vessels cross coverage zones. The operations team does not manage individual SIM changes. What previously generated support tickets became background infrastructure.

Fleet telematics, global operator. An MSP manages telematics devices for 15,000 vehicles across Europe, the Middle East, and Southeast Asia. New vehicles arrive with devices already embedded. The eIM activates connectivity on first ignition. When vehicles are reassigned to different regions, carrier profiles update without SIM replacements or field visits. The MSP’s customers see one dashboard. The MSP receives one wholesale invoice. The logistics overhead that previously scaled with fleet size no longer does.

Summary

SGP.32 moves provisioning decisions from the device to the server, removes the dependency on physical access for profile changes, and makes one hardware SKU viable across every deployment market. Permanent roaming compliance shifts from a per-market logistics problem to a managed eIM function. The eSIM Orchestrator role, which did not exist as a defined commercial function before SGP.32, becomes the layer that handles what neither the carrier nor the CMP was designed to do.

For partners and resellers, the standard expands what a managed connectivity proposition can include. Zero-touch activation, automated carrier switching, and over-the-air profile management are not available through retail SIMs, single-carrier agreements, or standard CMP platforms without eIM infrastructure behind them. SGP.32 is the specification that makes those capabilities standardised, certifiable, and deliverable at scale.