Who should be accountable for device trust in a zero-trust programme?

Why This Matters for Security Teams

device trust is not a point product outcome. It is the control chain that decides whether a device is known, healthy, enrolled, and still eligible to access protected resources. In a zero-trust programme, that chain usually spans IAM, endpoint management, and PKI, which is why accountability fragments so easily. When no one owns the full path from enrollment to revocation, posture checks become inconsistent and exceptions linger.

Current guidance in NIST SP 800-207 Zero Trust Architecture treats device trust as part of the access decision, not as a standalone asset inventory exercise. That aligns with NHIMG’s broader guidance in the Ultimate Guide to NHIs, where lifecycle control, visibility, and revocation are central to trust enforcement. NHIMG also notes that 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, which is a useful signal that trust programs fail when ownership is split across too many teams.

Security teams often assume device trust is “covered” once an endpoint tool reports healthy posture, but in practice many failures appear only after a stale certificate, broken enrollment path, or delayed revocation has already been exploited.

How It Works in Practice

Operationally, accountability should be divided by function but unified by one control owner. IAM normally owns the access policy and enforcement logic. Endpoint management owns device enrollment, health signals, and compliance state. PKI or certificate services own the cryptographic proof that a device is what it claims to be. One named owner, however, must be accountable for the end-to-end decision, because zero trust depends on consistent proof at request time, not on whether each tool works in isolation.

A practical model is to define device trust as a lifecycle:

• Enrollment proves the device was introduced through an approved process.
• Identity binding ties the device to a certificate, token, or workload identity.
• Posture evaluation confirms current health and compliance.
• Access decision uses real-time policy, not a static allow list.
• Revocation removes trust when the device is lost, noncompliant, or retired.

That lifecycle maps well to the NIST SP 800-53 Rev. 5 Security and Privacy Controls expectation that control ownership, monitoring, and remediation are explicit. For device identity and attestation patterns, NHIMG’s Guide to SPIFFE and SPIRE is relevant because workload identity approaches make proof more portable and less dependent on manual trust exceptions. In mature environments, the access decision should be explainable: which device, which certificate, which posture signal, which policy, and which revocation source all need to line up before access is granted.

These controls tend to break down when mobile fleets, contractor devices, and legacy VPN dependencies all use different enrollment and revocation paths, because trust becomes inconsistent across channels.

Common Variations and Edge Cases

Tighter device trust often increases operational overhead, requiring organisations to balance stronger assurance against support burden and device diversity. That tradeoff is especially visible when a programme includes BYOD, shared kiosks, industrial endpoints, or unmanaged third-party devices. Best practice is evolving, but there is no universal standard for how much posture evidence is enough in every environment.

One common edge case is certificate-backed access for devices that cannot run a modern endpoint agent. In those environments, current guidance suggests compensating controls such as network segmentation, limited scope certificates, or brokered access rather than pretending full trust exists. Another edge case is ownership during incident response: IAM may revoke the session, endpoint management may isolate the device, and PKI may invalidate the certificate, but the control owner still needs authority to trigger all three. Without that authority, revocation is slow and trust drifts.

For programme design, the cleanest accountability model is a single service owner with formal RACI across IAM, endpoint, and PKI, plus measurable SLAs for enrollment, posture refresh, and revocation. That is the difference between “distributed responsibility” and nobody being accountable when trust fails.

Related resources from NHI Mgmt Group

• Who is accountable for cryptographic posture management in a zero trust programme?
• Who should be accountable for identity intelligence in a Zero Trust programme?
• Who is accountable when identity-based access fails in a Zero Trust programme?
• Who should be accountable for stale access in a Zero Trust programme?