Notifications
Clear all
Topic starter
14/07/2026 4:23 pm
TL;DR: SGP.32 is pushing zero-touch eSIM provisioning for IoT devices, but many SM-DP+ platforms still only support JSON while device flows increasingly rely on ASN.1, creating interoperability gaps that only surface in integration or live testing, according to Workz Group. The governance issue is not connectivity alone but whether NHI-style device identity workflows can survive heterogeneous provisioning stacks without hidden translation layers.
NHIMG editorial — based on content published by Workz Group: Ensuring universal interoperability right from the start of SGP.32
Questions worth separating out
A: Teams should test the full provisioning path before rollout and not assume that standards compliance guarantees interoperability.
Q: Why do IoT identity programmes still fail even when the standard is implemented?
A: They fail because the standard does not remove downstream variability.
Q: What do security teams get wrong about zero-touch eSIM provisioning?
A: They often treat zero-touch as a guarantee of scale rather than a claim that still depends on compatible infrastructure.
Practitioner guidance
- Validate ASN.1 and JSON interoperability early Build integration tests that exercise SGP.32 device flows against every SM-DP+ platform you expect to use, including live message exchange and error handling.
- Govern translation middleware as identity infrastructure Place any protocol translation layer under the same change control, logging, and version validation you would apply to other provisioning control plane components.
- Map provisioning dependencies across the full device estate Document which device models, regions, and subscription platforms depend on ASN.1, JSON, or both, so procurement and rollout plans reflect actual support boundaries.
What's in the full article
Workz Group's full article covers the operational detail this post intentionally leaves for the source:
- The specific role of the eIM middleware layer in bridging JSON-only SM-DP+ platforms with ASN.1-based IoT devices.
- The practical deployment benefits claimed for zero-touch provisioning across globally distributed device fleets.
- The GSMA SAS certification context and how it supports scalable IoT provisioning assurance.
- The product and rollout framing behind the universal interoperability approach for SGP.32 environments.
👉 Read Workz Group's analysis of SGP.32 interoperability in IoT eSIM provisioning →
SGP.32 interoperability gaps in IoT eSIM provisioning: are teams ready?
Explore further
14/07/2026 4:31 pm
Interoperability is becoming an identity governance control, not just an engineering concern. SGP.32 shows that device identity does not fail only when credentials are weak or stolen. It also fails when the provisioning contract between device, middleware, and subscription platform is inconsistent. For NHI programmes, that means the control objective is reliable lifecycle execution across heterogeneous systems, not just standard adoption.
A few things that frame the scale:
- Companies are dedicating an average of 32.4% of their security budgets to secrets management and code security, with US organisations leading at 40.8%, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
A question worth separating out:
Q: What is the difference between protocol translation and device identity governance?
A: Protocol translation solves message compatibility, while device identity governance decides whether the provisioning flow is trusted, observable, and consistent enough to operate at scale. A translation layer can make two systems talk, but it does not by itself prove lifecycle control, accountability, or supportability across the fleet.
👉 Read our full editorial: SGP.32 interoperability exposes a mismatch in IoT eSIM provisioning
