Device trust is the confidence that a requesting endpoint is known, managed, and in a compliant state. It matters because identity alone does not prove safety. In zero trust programmes, device trust becomes one of the inputs used to decide whether access should be granted or sustained.
Expanded Definition
Device trust is the assurance signal used to judge whether an endpoint is sufficiently known, managed, and compliant to participate in an access decision. In zero trust programmes, it is not a standalone verdict; it is one input among identity, posture, location, and behaviour. The concept overlaps with endpoint compliance, device posture, and device assurance, but no single standard governs this yet, and definitions vary across vendors. For that reason, practitioners should treat device trust as a control outcome, not a product feature. In NHI and agentic workflows, the same question applies to the machine that is requesting access as to the identity behind it: is it registered, patched, encrypted, monitored, and authorised for the action it is trying to perform? NIST’s NIST Cybersecurity Framework 2.0 reinforces this by tying governance, access control, and continuous monitoring to risk-based decision-making.
The most common misapplication is treating device trust as a one-time device check at login, which occurs when organisations fail to re-evaluate posture during the session or after a compliance change.
Examples and Use Cases
Implementing device trust rigorously often introduces operational friction, requiring organisations to weigh stronger access assurance against user experience, device enrollment effort, and support overhead.
- A service account requests access from a build runner that is enrolled in MDM, patched, and encrypted. The device trust score helps determine whether the automation can proceed without forcing a manual approval step.
- An AI agent uses an endpoint to reach internal APIs. If the machine fails posture checks, the access policy can deny execution even when the agent identity is valid, reducing the chance of compromised automation.
- A contractor connects from a managed laptop but disables disk encryption after enrollment. A continuous posture check can downgrade trust and force re-authentication or session termination.
- A security team compares device trust signals with visibility gaps highlighted in the Ultimate Guide to NHIs to understand where unmanaged endpoints may amplify NHI exposure.
- During access federation design, practitioners map endpoint checks to policy decisions that support NIST Cybersecurity Framework 2.0 outcomes such as access control and continuous monitoring.
Why It Matters in NHI Security
Device trust matters because identity strength alone does not stop a stolen token, compromised workstation, or rogue automation host from abusing legitimate access. For NHIs, that weakness is amplified: many organisations still lack full visibility into service accounts, and NHI risk often persists because the endpoint or host context is not governed as tightly as the credential itself. NHI Mgmt Group research shows that only 5.7% of organisations have full visibility into their service accounts, which makes endpoint trust signals even more important when an NHI is invoked from an opaque machine. That is why the Ultimate Guide to NHIs treats lifecycle control, visibility, and governance as inseparable from access decisions. Device trust also supports zero trust architecture because policy must adapt when posture changes, not just when credentials are presented. In practice, this means the security team must know whether the requesting endpoint is managed, monitored, and allowed to carry the privileges attached to the identity. Organisations typically encounter device trust as a priority only after a compromised endpoint is used to access secrets or APIs, at which point the control becomes operationally unavoidable to address.
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 address the attack and risk surface, while NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST Zero Trust (SP 800-207) | SP 800-207 | Zero Trust evaluates device posture as a core signal in access decisions. |
| NIST CSF 2.0 | PR.AC-1 | Device trust supports access control decisions based on risk and context. |
| OWASP Non-Human Identity Top 10 | NHI-05 | NHI controls require governing the host context that executes non-human identities. |
Require managed, compliant endpoints for NHI use and deny access from unknown hosts.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on May 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
