What is the difference between protocol translation and device identity governance?

Why This Matters for Security Teams

Protocol translation and device identity governance are often treated as adjacent problems, but they answer different security questions. Translation is about whether two systems can exchange data in the right format. Governance is about whether the device, workload, or provisioning path is known, approved, monitored, and removable over time. Security teams get into trouble when a compatibility layer is mistaken for a trust control. That confusion creates blind spots in onboarding, offboarding, and incident response, especially when NHIs are involved and secrets, certificates, or API keys outlive the device they were issued to.

That gap is visible in broader NHI programmes as well. NHI Management Group’s Ultimate Guide to NHIs notes that NHIs outnumber human identities by 25x to 50x in modern enterprises, which means even a small governance failure scales quickly. The problem is not just whether a protocol works, but whether the identity behind the protocol can be trusted throughout its lifecycle. The NIST Cybersecurity Framework 2.0 frames this as an asset, access, and continuous monitoring issue, not a pure interoperability issue. In practice, many security teams encounter protocol compatibility problems only after a provisioning path has already created unmanaged devices or orphaned credentials.

How It Works in Practice

Protocol translation sits at the transport or application boundary. It may convert formats, map fields, or normalize message flows so one system can talk to another. Typical examples include gateway-based translation between legacy device protocols and cloud APIs, or adapters that let an older provisioning system feed a modern control plane. That function is useful, but it does not decide whether the source device is authentic, whether the enrollment request is approved, or whether the resulting identity is restricted to the minimum necessary scope.

Device identity governance operates one layer higher. It defines how a device or workload is enrolled, attested, named, rotated, revoked, logged, and reviewed. In mature environments, that usually includes:

• approved enrollment paths and owner assignment
• certificate or key issuance with clear TTL and revocation rules
• inventory linkage between device, identity, and business service
• continuous monitoring for drift, reuse, or privilege creep
• offboarding processes that remove trust when the device is retired or compromised

That distinction matters because a translated message can still come from an untrusted, duplicated, or stale identity. The NHI Management Group Lifecycle Processes for Managing NHIs guidance emphasises that identity lifecycle control is separate from the wire protocol. Current best practice suggests pairing protocol adapters with workload identity, policy-as-code, and audit logging so the control plane can validate who or what is making the request at runtime. The NIST Cybersecurity Framework 2.0 supports this by tying access decisions to governance and monitoring outcomes, not just connectivity. These controls tend to break down in OT-heavy or hybrid environments where device ownership is unclear and legacy protocols do not expose reliable identity signals.

Common Variations and Edge Cases

Tighter device identity governance often increases onboarding effort, so organisations have to balance operational speed against trust assurance. That tradeoff is especially visible in mixed fleets, where some devices support modern attestation and others only expose coarse protocol identifiers.

One common edge case is a gateway that both translates protocol and brokers identity. That can be helpful, but it is not automatically governance. If the gateway is simply reissuing messages, it may hide the original device provenance and reduce auditability. Another edge case is third-party managed equipment, where the provisioning flow is controlled by a vendor. In that case, governance needs contract terms, logging, and revocation rights, not just protocol compatibility. NHI Management Group’s Top 10 NHI Issues research highlights that rotation, visibility, and excess privilege are recurring failure points, which is why translation alone rarely solves the risk.

There is no universal standard for this yet across every device class. Best practice is evolving toward separating the adapter function from the trust function: translation keeps systems interoperable, while governance keeps the identity lifecycle defensible. That separation becomes critical when protocols are stable but the fleet is dynamic, because the message format may remain valid long after the identity behind it should have been revoked.

Related resources from NHI Mgmt Group

• What is the difference between device security and identity governance in ot?
• What is the difference between protocol migration and identity governance?
• What is the difference between device management and device-based identity governance?
• What is the difference between human identity governance and AI agent governance?