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.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Workz Group's blog post: SGP.32 is widening the gap between IoT eSIM provisioning intent and real-world SM-DP+ interoperability, with JSON-first platforms often failing to align cleanly with ASN.1-based device flows.
Why it matters: IAM, IoT, and NHI practitioners need to treat provisioning compatibility as a governance problem, because hidden format mismatches can derail lifecycle control and deployment reliability.
Context
SGP.32 is a GSMA standard for zero-touch eSIM provisioning in IoT environments, but standards adoption does not automatically mean every participating platform speaks the same message format. In this article, the tension is between device-side provisioning logic that uses ASN.1 and many commercial SM-DP+ systems that still expect JSON.
That mismatch matters because the provisioning workflow is part of the identity lifecycle for connected devices. If a platform cannot interpret the device's provisioning language consistently, teams do not just get an integration nuisance; they get uneven identity onboarding across environments, which complicates rollout planning and supportability.
Key questions
Q: Where does SGP.32 provisioning fail in practice?
A: It fails where device-side and platform-side message formats do not align consistently. A device flow may use ASN.1 while a commercial SM-DP+ platform still expects JSON, so the workflow only breaks once integration or live testing exercises the full path across real environments.
Q: Why do SGP.32 interoperability gaps increase rollout risk?
A: Because compatibility is not guaranteed by the standard alone. If providers support ASN.1 unevenly, OEMs and service providers cannot assume a single provisioning design will behave the same across every SM-DP+ environment, which creates deployment uncertainty and support overhead.
Q: How should teams test IoT eSIM provisioning before launch?
A: They should verify the complete provisioning journey across the actual device, eSIM, middleware, and SM-DP+ combinations they expect to operate in production. Testing must include the message format conversion path, because that is where many hidden interoperability issues surface.
Q: What should security and IoT teams do when a translation layer is required?
A: They should govern it as an operational control, not a convenience feature. That means assigning ownership, testing message fidelity, and treating any translation between ASN.1 and JSON as part of the trusted provisioning boundary.
Technical breakdown
ASN.1 versus JSON in SGP.32 provisioning
SGP.32-enabled IoT devices can use IPAe logic on the eSIM and communicate in ASN.1, a compact structured encoding commonly used in telecom workflows. Many SM-DP+ platforms were built around consumer eSIM flows and expect JSON, which is easier for application integration but not always equivalent in message structure. The interoperability problem is not that one format is inherently better. It is that provisioning state, attributes, and responses must survive translation without changing meaning. When that translation layer is absent or inconsistent, the workflow may pass design review but fail once real device traffic hits the platform.
Practical implication: Validate message-format compatibility early and treat ASN.1-to-JSON translation as a lifecycle dependency, not an integration footnote.
Why interoperability breaks show up late
The article's central operational point is that many of these gaps do not surface until integration or live testing. That is typical when a platform's compatibility claim is based on partial support, environment-specific enablement, or uneven provider coverage rather than end-to-end verified provisioning paths. In practice, the device may appear ready, the standard may be implemented, and yet the SM-DP+ side still rejects or misinterprets a step in the workflow. This is a classic multi-party identity problem: each component can be locally correct while the combined workflow still fails.
Practical implication: Use interoperability testing across real SM-DP+ variants before mass deployment, not after device rollout has already started.
Middleware as a compatibility control
The article points to a built-in middleware translation layer as the practical bridge between JSON-only SM-DP+ servers and ASN.1-based IoT devices. Mechanically, middleware preserves the provisioning relationship while adapting the message structure at the boundary. That can reduce dependence on every upstream platform reaching full IoT-specific support immediately. The important governance distinction is that this does not eliminate interoperability risk. It relocates it into the translation layer, where message fidelity, protocol integrity, and supportability must all be managed as part of the device identity stack.
Practical implication: Treat translation middleware as governed infrastructure with testing, version control, and support boundaries, not as an invisible fix.
NHI Mgmt Group analysis
SGP.32 interoperability is an identity lifecycle problem, not just a transport problem. The article shows that zero-touch eSIM provisioning depends on more than standards compliance because the device identity workflow still has to move cleanly through SM-DP+ operations. When device-side ASN.1 and platform-side JSON do not align, onboarding becomes uneven even if the specification is technically supported. The practitioner lesson is to govern provisioning as an identity lifecycle path, not as a one-time connectivity setup.
Hidden translation layers are now part of the trust boundary. A middleware bridge can make heterogeneous provisioning stacks work, but it also becomes a governance surface that must preserve message meaning, state transitions, and protocol integrity. That is a familiar NHI pattern: compatibility fixes often create a new control point rather than removing the need for control. Teams should assume the translation layer is operationally material and bound to support and change-management discipline.
Interoperability claims without end-to-end verification create support debt. The article's repeated emphasis on discovery during integration or live testing reflects a wider programme issue: partial platform support is not the same as deployable support. For IoT identity programmes, that means compatibility has to be proven across the actual ecosystem, not inferred from a standard reference alone. The implication is simple. Procurement, engineering, and operations need shared evidence before rollout.
IoT eSIM provisioning now sits in the same governance class as other non-human identity lifecycles. The device may not be an account, but it still has onboarding, credential binding, operational continuity, and dependency management. Once those steps span multiple vendors and message formats, the programme starts to resemble NHI governance in practice, even if the terminology differs. Practitioners should manage SGP.32 adoption as lifecycle governance across devices, platforms, and translation paths.
Universal interoperability only exists when the weakest platform path is proven. The article makes clear that some providers added ASN.1 support while others remain inconsistent, so the real standard is not theoretical compliance but ecosystem-wide behaviour. That means the market still rewards teams that validate the least mature path first. For practitioners, the right question is whether every deployment target can complete the same provisioning outcome, not whether the standard says it should.
What this signals
SGP.32 adoption will increasingly be judged by ecosystem compatibility, not specification coverage. For IoT programmes, that changes the procurement conversation. Teams should ask which SM-DP+ environments have been proven in practice, because identity lifecycle reliability depends on the weakest integration path, not the most optimistic support statement.
Compatibility middleware is becoming part of the control plane for device identity. Once translation is introduced, it needs the same scrutiny as any other lifecycle dependency. That means change control, testing discipline, and clear support boundaries around how device messages are normalized before provisioning completes.
For practitioners
- Validate end-to-end provisioning paths Test SGP.32 onboarding across the exact SM-DP+ platforms, device types, and environments you plan to use, not a single reference implementation.
- Map message-format dependencies Document where ASN.1 is used on the device side and where JSON is still required on the platform side so compatibility assumptions are explicit.
- Govern any translation middleware Treat the middleware layer as a controlled part of the identity stack, with ownership, versioning, and acceptance testing tied to provisioning changes.
- Separate standard support from deployable support Require evidence that provisioning works in live or pre-production integration, because partial feature support can still fail in real interoperability paths.
Key takeaways
- SGP.32 does not remove interoperability risk from IoT eSIM provisioning, because device and platform message formats can still diverge across the ecosystem.
- The article shows that ASN.1 and JSON mismatches often surface late, which makes live integration testing more important than nominal standard support.
- Teams should govern provisioning compatibility as a lifecycle issue, especially when translation middleware becomes part of the trusted path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-06 — Insecure Cloud Deployment Configurations | The article centres on deployment-path mismatch across provisioning infrastructure. |
| NHI-08 — Environment Isolation | Different device and platform message formats create environment-specific behaviour that must be controlled. | |
| Recommendation — Validate provisioning infrastructure paths against NHI-06 before rollout across heterogeneous SM-DP+ environments. Test provisioning behaviour across isolated environments to expose format-specific failures before production. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Service Accounts) | IoT provisioning is a machine-to-machine identity workflow requiring service-side authentication governance. |
| Recommendation — Apply IA-9 to govern machine-to-machine provisioning identity paths and verify authenticating components end to end. | ||
| CIS Controls v8 | CIS-5 — Account Management | Device onboarding and provisioning are account lifecycle functions for connected devices. |
| Recommendation — Use CIS-5 to ensure connected-device identities are provisioned, tracked, and supported across their lifecycle. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Provisioning compatibility determines whether device entitlements are issued and accepted correctly. |
| Recommendation — Align entitlement issuance and acceptance checks with PR.AA-05 across the full provisioning chain. | ||
Key terms
- SGP.32 Provisioning: SGP.32 provisioning is the process of remotely onboarding an IoT eSIM so a device can be activated without manual handling. In practice, it is an identity lifecycle workflow that must work across device logic, eSIM components, and operator provisioning platforms.
- SM-DP+: The subscription management platform that delivers and manages eSIM profiles. In IoT provisioning, it is the system that must interpret device requests correctly, which means format compatibility and lifecycle support matter as much as nominal standards compliance.
- ASN.1: A structured message encoding used in many telecom and machine-to-machine systems. In SGP.32 flows, it can create interoperability friction when downstream platforms expect JSON instead, because the same provisioning intent is represented in a different machine-readable form.
- Provisioning Middleware: Provisioning middleware is a translation layer that adapts one system's provisioning messages into another's expected format. In IoT identity governance, it becomes part of the trusted path and must preserve message meaning, protocol integrity, and lifecycle state.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on July 14, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org