SGP.32 for IoT: Architecture, Deployment Impact, and What Changes for Enterprises

By Marc Kavinsky, Lead Editor at IoT Business News.

SGP.32 is the GSMA’s next-generation Remote SIM Provisioning (RSP) specification designed specifically for IoT devices. Its goal is to make eSIM operations more scalable and more adaptable to constrained devices and “headless” deployments—without depending on the legacy assumptions that shaped earlier eSIM models.

By Marc Kavinsky, Lead Editor at IoT Business News.

For enterprises, OEMs and connectivity providers, the shift is not just about a new standard. It changes how fleets are onboarded, how connectivity is orchestrated across geographies, and how responsibilities are split between device software, backend orchestration, and profile delivery infrastructure. It also creates a transition period where mixed fleets (SGP.02 and SGP.32) will coexist for years, forcing pragmatic operating models rather than “big bang” migrations.

Why SGP.32 exists: the operational limits of earlier eSIM approaches

Two realities pushed the market toward an IoT-native RSP architecture. First, many IoT devices are deployed with minimal or no user interface and cannot rely on user-driven activation flows. Second, enterprise IoT deployments are increasingly global, long-lived, and operationally demanding: fleet managers need repeatable profile lifecycle actions (download, enable, disable, delete) at scale, with traceability and predictable failure modes.

Earlier IoT eSIM deployments commonly leaned on the GSMA M2M approach (often associated with SGP.01/SGP.02), which was built for embedded UICC remote provisioning in an era where SMS-based transport and tightly coupled ecosystem roles were more common. SGP.32 modernises the model around IoT fleet realities, including IP-based communication options and clearer orchestration roles.

Architecture at a glance: what’s new in SGP.32

SGP.32 introduces a more IoT-appropriate separation of responsibilities between device-side logic and backend orchestration. While terminology and implementation details vary by vendor, most enterprise readers should internalise three core building blocks:

IPA (IoT Profile Assistant): a device-side software component that handles profile management interactions on constrained or unattended IoT devices.
eIM (eSIM IoT Remote Manager): a server-side orchestration component that manages transactions and lifecycle operations at fleet scale.
SM-DP+: the backend platform that securely stores and delivers eSIM profiles (also present in other GSMA eSIM models).

This matters because it re-frames “eSIM management” as an orchestrated lifecycle process rather than a one-time activation event. In practical terms, SGP.32 pushes organisations to think in runbooks: how you bootstrap the initial profile, how you switch profiles under operational constraints, and how you manage rollback when the network path is degraded.

For historical context on how the GSMA positioned the IoT eSIM model and its ecosystem roles, refer to the GSMA’s new IoT eSIM specification.

What changes for enterprise deployments

1) Bootstrapping becomes a first-class design problem

Most large IoT deployments start with a bootstrap connectivity plan: the device needs enough connectivity to reach provisioning services, even before it is fully “in service.” With SGP.32, the bootstrap model becomes more explicit and operationally central. You need to define:

Which profile is used for first attach (and how it is sourced).
How the device authenticates to provisioning services.
What happens if the bootstrap profile works only in a subset of countries or radio environments.

In procurement terms, this pushes buyers to ask not only “does it support SGP.32?” but also “what is your bootstrap strategy, and how do you prove it works across my target footprint?”

2) Profile switching is no longer a rare event

Many fleets only switch profiles when something breaks (coverage gaps, roaming restrictions, commercial contract changes). In practice, once enterprises adopt a more automated orchestration layer, profile switching becomes a normal operational action—used to optimise reliability, cost, or compliance. That changes the test plan: you must test switching under weak signal, under intermittent IP connectivity, and at scale (thousands of devices per hour) without triggering unexpected throttling or backoff behaviours.

For a connectivity-provider lens on how these orchestration models are being productised, see global enterprise IoT deployments and the emergence of “hub” approaches.

3) Legacy fleet reality: SGP.02 and SGP.32 will coexist

A common misconception is that SGP.32 instantly “replaces” older fleet architectures. The reality is that many deployed devices cannot be upgraded into a new RSP model without hardware changes, deep firmware work, or re-certification. Enterprises should plan for mixed operations:

Existing devices continue to run as-designed (often SGP.02-based M2M eSIM operations).
New device generations adopt SGP.32 where it creates clear operational upside.
Fleet tooling must unify reporting, alerting, and policy—even if the RSP mechanics differ underneath.

For a concrete example of how vendors are positioning solutions to bridge old and new, see legacy IoT devices and compatibility claims in the market.

4) Roles and responsibilities shift across the ecosystem

SGP.32 is also a business change. The market is moving toward clearer separation between network access, orchestration, and device lifecycle operations. That can benefit enterprises that want multi-operator flexibility without heavy custom integrations, but it can also create ambiguity: who is accountable for provisioning success, for audit logs, for incident response, and for recovery when a profile download fails mid-transaction?

As organisations negotiate contracts, they should demand explicit SLAs around provisioning operations, not only “network uptime.”

SGP.32 vs eUICC vs iSIM: don’t mix the layers

Teams often conflate the RSP standard (SGP.32) with the form factor and silicon integration choice (eUICC, eSIM, iSIM). In practice:

SGP.32 is about how profiles are remotely managed and orchestrated for IoT.
eUICC/eSIM describes the secure element capability to host multiple profiles and enforce policy.
iSIM integrates SIM functionality into a system-on-chip approach, changing BOM, power, and manufacturing constraints.

To explore how iSIM is being productised for IoT and what it changes in device design, see iSIM integration by Soracom. For a concrete SGP.32 + iSIM module announcement, see SGP.32 and iSIM integration by G+D and Murata.

Deployment checklist: how to evaluate “SGP.32-ready” claims

As the ecosystem is still in transition, “SGP.32-ready” is sometimes used loosely. Enterprises should validate readiness with an evidence-based checklist:

Lifecycle completeness: can the solution reliably download, enable, disable, delete, and switch profiles in the conditions your devices will face?
Bootstrap model: what initial profile is used, and how is it secured and maintained?
Interoperability: can the orchestration layer work across multiple profile providers and connectivity partners without bespoke integrations?
Observability: are provisioning events logged with sufficient detail for troubleshooting and audit?
Failure recovery: what happens if profile delivery fails halfway through, or a device goes offline during a transaction?

In 2025–2026, “zero-touch” operational narratives are increasingly common. Use them as a prompt to ask for concrete proof: test reports, certified components, and live references. For example, see zero-touch eSIM introduction by Digi International.

What SGP.32 will not solve on its own

SGP.32 improves the architecture for remote provisioning, but it does not remove the hard parts of enterprise IoT:

Radio reality: coverage, interference, and device placement still drive connectivity success.
Regulatory constraints: permanent roaming rules and local requirements remain a commercial and operational constraint.
Security operations: keys, credentials, update pipelines, and incident response must be designed and staffed.
Integration debt: provisioning is only one part of the fleet stack (device management, data, applications, and support workflows still matter).

Enterprises that treat SGP.32 as “magic roaming” or “instant global compliance” often end up disappointed. The winners will be teams that treat SGP.32 as an enabler for better lifecycle discipline—and invest in validation, monitoring, and operational runbooks.

Recommended adoption path for enterprises

A pragmatic adoption strategy usually looks like this:

Phase 1: implement SGP.32 in a new device generation or a contained geography, focusing on bootstrap reliability and switching tests.
Phase 2: standardise orchestration and observability practices across business units and geographies.
Phase 3: rationalise contracts and operational responsibility across operators, orchestrators, and device teams.

Alongside the technical plan, keep commercial terms tight: define who owns provisioning SLAs, what constitutes a provisioning incident, and how failures are escalated. This is where SGP.32’s architectural promise becomes measurable operational value.