How should security teams use device identity in zero trust access decisions?

Why This Matters for Security Teams

Device identity is only useful in zero trust if it reflects the device’s current trust state, not a one-time enrollment event. That distinction matters because access decisions are increasingly made against endpoints that can be managed, cloned, rooted, jailbroken, or simply out of compliance after the original registration. Zero trust guidance in NIST SP 800-207 Zero Trust Architecture is clear that trust should be continuously evaluated, while the OWASP Non-Human Identity Top 10 shows how stale identity signals become exploitable when they are treated as static.

For security teams, the risk is not just unauthorized devices getting access. It is also over-trusting managed devices that have drifted out of posture, lost certificate validity, or been enrolled into a different risk state than the one captured in the IAM record. In practice, the access layer needs to interpret device identity as a live signal tied to enrollment status, cryptographic proof, policy compliance, and health telemetry. The Ultimate Guide to NHIs notes that 90% of IT leaders say proper NHI management is essential for successful zero-trust implementation, which is a strong signal that identity is now a control plane issue, not just an inventory problem. In practice, many security teams discover device trust gaps only after a compromised endpoint has already been accepted as “known.”

How It Works in Practice

Device identity works best as one input into a runtime policy decision, not as a blanket grant. The access request should combine identity proof, certificate state, posture signals, and contextual risk before a session is allowed. That usually means validating whether the device is enrolled, whether its certificate is current, whether it meets baseline controls such as encryption and EDR coverage, and whether it is operating in an expected risk zone. This aligns with the continuous evaluation model described in NIST SP 800-207 Zero Trust Architecture and the control emphasis in NIST SP 800-53 Rev 5 Security and Privacy Controls.

In operational terms, teams often implement this with device certificates, endpoint management telemetry, conditional access, and policy enforcement at the application or proxy layer. The device itself becomes part of the authorization context, not the only proof of trust. A practical decision flow usually includes:

• Confirm current enrollment and ownership before any access grant.
• Check certificate validity, revocation status, and expected device posture.
• Require stronger controls for unmanaged, shared, or high-risk devices.
• Re-evaluate trust during the session, not only at login.
• Reduce access scope when posture degrades instead of waiting for full block decisions.

This approach is especially important for service-heavy environments, because device trust can be extended into workload and machine access patterns. The Guide to SPIFFE and SPIRE is useful here because it shows how cryptographic workload identity can complement endpoint identity when machine-to-machine trust must be asserted continuously. These controls tend to break down when organizations rely on a static device inventory as if it were a real-time trust signal, because post-enrollment posture drift is then invisible to the access engine.

Common Variations and Edge Cases

Tighter device-based access often increases operational overhead, requiring organizations to balance security assurance against onboarding friction and support complexity. That tradeoff is real, especially in mixed fleets where some devices are managed, some are BYOD, and some are shared kiosk or contractor endpoints. Best practice is evolving, but current guidance suggests that different trust tiers should exist rather than a single pass-fail device rule.

Edge cases are where many programs stumble. A device may be compliant but temporarily unreachable by the management plane, which raises the question of whether stale telemetry should block access immediately or degrade it gradually. A certificate may still be valid while the endpoint is compromised, so certificate presence alone is not enough. Likewise, high-trust users on low-trust devices should not inherit the same access as they would from managed endpoints, because role alone does not offset endpoint risk. The practical answer is to combine device identity with conditional access, least privilege, and explicit session controls, while preserving auditability for exceptions.

For teams building out this model, NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks is a useful reference for understanding how stale identity state and poor lifecycle control create exposure. The same logic applies to endpoints: if the device state cannot be validated in real time, it should not be treated as fully trusted.

Related resources from NHI Mgmt Group

• How should security teams use identity analytics to improve access governance?
• How should teams unify zero trust controls across identity and device security?
• How should security teams use GRC to govern identity access decisions?
• How should security teams run access reviews for non-human identities?