Most conversations about eSIM in IoT circles have centred on the same question: how do you get a profile onto a device at scale? That’s a valid question, and SGP.02 answered it well enough for the M2M world. But the industry has moved. IoT deployments are no longer measured in hundreds of devices provisioned at a factory gate. They’re fleets of tens of thousands — asset trackers in transit, environmental sensors in the field, connected vehicles crossing six borders — and the hard problem isn’t getting the profile on. It’s managing what happens after.

SGP.32, the GSMA’s specification for consumer-oriented IoT eSIM architectures, arrived specifically to address that gap. It introduces the eIM (eSIM IoT Manager) as a standardised control plane and redefined how profile management should work at the device level through the iUICC (integrated UICC) model. More importantly, it shifts the architectural weight from provisioning events to continuous lifecycle governance. If SGP.02 was about Day 1, SGP.32 is fundamentally a Day 2 standard.

What actually changes

The clearest departure from SGP.02 is the absence of a dedicated LPA (Local Profile Assistant) on the device. In SGP.32, the eIM acts as the remote orchestration layer, communicating directly with a lightweight client on the iUICC. This matters operationally because it removes the dependency on device-side software for profile management — meaning a firmware update or a locked-down hardware abstraction layer no longer blocks your ability to push a policy change.

The eIM also introduces machine-readable automation hooks that don’t exist in earlier specifications. You can trigger profile switches based on network quality metrics, location zone changes, or contract thresholds — without any human in the loop. That’s not a minor improvement. For a fleet manager overseeing 40,000 devices across APAC and EMEA, it’s the difference between manual exception handling and actual operational leverage.

SGP.32 also formalises the relationship between the SM-DP+ (Subscription Manager Data Preparation Plus) and the eIM under IoT constraints, including low-power and intermittent connectivity scenarios. The spec accounts for devices that may go offline for extended periods and need deferred command execution — something that’s effectively impossible to manage gracefully under older provisioning models.

Day 2 operations: what governance actually looks like

“Day 2 operations” is becoming industry shorthand for everything that happens after a device is provisioned and in the field. In practice, for IoT fleet managers, it breaks down into three layers.

Verification is the first. Knowing which devices are running which profile, under which operator contract, with what RSP event history — and being able to audit that at any moment. GSMA’s IoT SAFE framework sits alongside SGP.32 here, providing cryptographic attestation of device identity. Without this, fleet operators are flying blind: they can’t confirm profile state without pinging each device individually, which doesn’t scale.

Governance is the second layer. This is about policy — who can trigger a profile change, under what conditions, and with what approval chain. Enterprise IoT buyers are increasingly demanding RBAC (role-based access control) at the SM-DP+ and eIM level. Connectivity managers want auditability. Security teams want zero-trust enforcement on every profile operation. SGP.32’s architecture accommodates this; most vendor implementations don’t yet.

Optimisation is the third. This is where the commercial model starts to bend. As multi-operator and pan-regional IoT deployments grow, the ability to switch profiles dynamically in response to cost signals or QoS degradation becomes a genuine differentiator. Smart policy engines — increasingly offered as part of connectivity management platforms — sit on top of the eIM and automate these decisions. The technology is available. The integrations are still catching up.

How the partner ecosystem is forming

Pan-European IoT deployments are driving a new kind of alliance structure. Operators that lack coverage density in Eastern Europe or the Nordics are partnering with regional MVNOs that have deep roaming agreements, connecting via API-layer integrations that treat the SM-DP+ as a shared infrastructure component rather than a proprietary asset.

Platform players like Eseye, Tele2 IoT, and Transatel (now part of NTT) have been building multi-operator stack management for years. What’s changing in 2026 is that SGP.32 compliance is increasingly being written into procurement RFPs — which means the platform must be certifiably compliant, not just “compatible.” GSMA certification is the floor, not a differentiator.

The API-first connectivity management category is also accelerating. Platforms like Emnify, Hologram, and Pelion are positioning around programmatic lifecycle control — the ability to write a few lines of Python or hit a REST endpoint and trigger a profile change across a thousand devices. That’s the operational reality SGP.32 was designed to support, and it’s where competitive moats are forming.

What to demand from vendors in 2026

Any IoT eSIM vendor worth evaluating should be able to answer five questions clearly.

Certification and compliance

Do you hold GSMA SGP.32 certification, and can you provide documentation? “SGP.32-ready” without certification is marketing.

eIM architecture

Is the eIM a proprietary platform, or is it interoperable with third-party SM-DP+ infrastructure? Lock-in at the eIM layer is the new SIM lock.

Lifecycle API coverage

What percentage of Day 2 operations — profile swap, suspension, decommission, audit log export — are API-accessible? If it still requires a support ticket, it’s not enterprise-grade.

Multi-operator support

Can you manage profiles from multiple operators through a single eIM instance, with per-operator policy controls? Single-operator platforms have no place in a global IoT deployment.

SGP.02 migration path

For existing M2M deployments still running on SGP.02, what is the migration roadmap? Vendors without a clear answer are likely managing two parallel legacy platforms indefinitely.

The bigger picture

The IoT eSIM market is at an inflection. The provisioning problem is largely solved. The governance problem is not — and that’s where the next wave of vendor consolidation will happen. GSMA’s SGP.32 is the framework; the race is now about who builds the best operational layer on top of it.

Compared to the consumer eSIM market — where the differentiation game has compressed into price-per-GB and geographic coverage breadth — IoT eSIM is still genuinely complex, and that complexity rewards operators who invested early in platform depth. Eseye’s multi-operator management, Tele2 IoT’s GSMA-certified stack, and Transatel’s wholesale infrastructure are built around exactly the lifecycle control problems SGP.32 formalises.

The risk for mid-tier vendors is commoditisation from below: as certification becomes table stakes and API-native management becomes the norm, the providers who don’t own the eIM layer will be squeezed into reseller territory. The risk from above is platform consolidation — hyperscalers like AWS (IoT Core) and Azure (IoT Hub) are already integrating connectivity management APIs, and it’s not a stretch to imagine them absorbing the eIM function as a managed service.

What the market needs, and what the GSMA’s own IoT SAFE and SGP.32 working groups have consistently signalled, is interoperability over vertical integration. The eIM should be a standard interface, not a moat. Whether the industry actually moves that direction, or whether a few platform players successfully close the stack, is the defining question for IoT connectivity in the next three years.

FAQ Block:

Q: What is SGP.32 and why does it matter for IoT? SGP.32 is a GSMA specification that standardises IoT eSIM lifecycle management through the eIM (eSIM IoT Manager) architecture. Unlike SGP.02, it’s designed for Day 2 operations — governance, verification, and dynamic profile control across large device fleets.

Q: What is the difference between SGP.02 and SGP.32? SGP.02 is the original M2M remote SIM provisioning standard, focused on factory-stage provisioning. SGP.32 extends this for modern IoT deployments with API-native orchestration, iUICC support, and automated lifecycle management without a device-side LPA.

Q: What are Day 2 IoT eSIM operations? Day 2 operations refer to everything that happens after a device is provisioned: profile verification, policy governance, dynamic operator switching, audit logging, and decommissioning. SGP.32 was architected specifically to support these workflows.

Q: What should I ask IoT eSIM vendors about SGP.32? Ask for GSMA certification documentation, eIM interoperability details, API coverage for lifecycle operations, multi-operator support, and a clear SGP.02 migration roadmap if you have existing M2M deployments.

Q: How does eSIM lifecycle management work for large IoT fleets? Through an eIM acting as the remote control plane, fleet operators can trigger profile swaps, apply policy rules, run cryptographic attestation via IoT SAFE, and automate operator selection — all without physical access to devices.