SGP.32 in IoT: Why It Works in the Lab, but Breaks at the Boundaries

With Mobile World Congress and Embedded World taking place right now, SGP.32 is again being positioned as the next major leap for eSIM in IoT. The direction is right. The risk is that we keep framing adoption as a technical milestone, while the real blockers show up later, in production, at the boundaries between parties.

SGP.32 rarely fails because the standard is incomplete. It fails because multi-party delivery without a shared operating model turns “decoupling” into diffused ownership. In the lab, every component behaves. In production, the handovers decide whether customers trust it.

What Is SGP.32, and Why It Matters

eSIM, more precisely eUICC, matters in IoT because devices are deployed for years and are often hard to reach. Physical SIM swaps are slow, costly, and operationally unrealistic at fleet scale.

SGP.32 is the GSMA standard designed to modernize remote provisioning for IoT. It enables remote profile download and activation at scale. That is important, but it is also the part that is easiest to demonstrate. Adoption rarely breaks on the download.

The Hard Part Starts After the Download

In real operations, the hard part is whether an enterprise customer can run the system without becoming an integration company. Once SGP.32 is in production, “connectivity works” depends on the full chain: device and firmware, eUICC behavior, the provisioning platform, the mobile network, and enterprise prerequisites such as APNs, IP pools, firewall rules, private routing, VPN connectivity, and policy constraints. SGP.32 is a critical building block, but still only one building block.

In real operations, the hard part is whether an enterprise customer can run the system without becoming an integration company.

“Everything Is Green”, but the Application Sees Nothing

A pattern that repeats across deployments is simple: the profile is downloaded and activated, every component reports success, but enterprise traffic never reaches the application.
In many cases, provisioning is not broken. Alignment is broken. The APN points to the wrong environment, the IP pool does not match the expected address space, firewall rules block traffic, private routes are missing or inconsistent. Each layer can be correct in isolation, which is exactly why the customer experience can be wrong end-to-end.

Fragmentation Turns Incidents into Parallel Investigations

Different teams describe the same incident in different language. Connectivity teams call it routing. Device teams call it firmware. RSP teams call it provisioning. The customer calls it an outage.
This is not semantics. It is what fragmentation looks like under pressure. If responsibilities are organized around components, incidents turn into parallel investigations with selective evidence sharing and slow audit-log exchange, “just to be on the safe side.” A lot of energy goes into proving innocence instead of restoring service.
Repair times increase. Trust drops. And the conclusion becomes “SGP.32 is not ready”, even when the underlying issue is not the standard, but the operating model around it.

The Shift SGP.32 Needs: From Features to Operability

If SGP.32 is to scale beyond early adopters, the conversation has to move from feature lists to operability.

That means:

• Clear incident ownership, including who owns enterprise routing alignment and who leads end-to-end triage
• A shared factual baseline, common evidence set, consistent timestamps, consistent states, traceable audit logs across device, eUICC, RSP, and network
• Success metrics that measure fleet outcomes, not component success, meaning traffic reliably reaches the application after activation
• A “single pane of glass” that is a workflow plus data model, not a dashboard, consistent terminology, consistent states, clear handovers, and incident choreography across parties

This is where the ecosystem shifts from “components that comply” to “systems that operate.”

More Options Raise the Stakes at the Boundaries

This becomes more important as additional options enter the system. Private 5G, satellite multi-orbit and multi-constellation (NTN) connectivity approaches increase reach and resilience. They also increase the number of policies, bearers, and failure modes.

Optionality is valuable as long as operations remain simple. If not, complexity multiplies exactly where things already break today, at the boundaries between parties.

Anyone running SGP.32 at scale already knows: the hard part is not the download. The hard part is everything that has to work around it

The Best Time to Fix This Is Before the Escalation

Many teams are reorganizing right now around IoT connectivity and eSIM. This is the right moment to bake accountability into architecture and operations, not after the first escalation.

Anyone running SGP.32 at scale already knows: the hard part is not the download. The hard part is everything that has to work around it and after it, so that “green” actually translates into “running.”