Accountability sits with the security and identity teams that define access policy, device assurance, and conditional access requirements. IAM establishes who the user is, but it does not by itself prove the endpoint is safe. Organisations should treat device trust as a shared control between identity, endpoint, and security operations rather than a directory-only problem.
Why This Matters for Security Teams
When IAM is asked to prove device trust, the control boundary is already too narrow. Identity systems can authenticate a user or workload, but they do not continuously validate endpoint health, local compromise, unmanaged browsers, or risky session context. That gap is where conditional access, endpoint management, and security operations have to work together. NIST’s Zero Trust guidance makes this separation explicit in NIST SP 800-207 Zero Trust Architecture, and NHIMG’s Ultimate Guide to NHIs shows how identity failures compound when access, secrets, and privilege are handled as isolated problems.
The practical issue is accountability. Security leaders often assume IAM can enforce device trust by itself, but device posture is usually supplied by external signals from EDR, MDM, certificate health, or browser and network context. If those signals are missing, stale, or not enforced consistently, access decisions become policy theatre rather than risk control. In practice, many security teams discover the weakness only after a trusted account is used from an unmanaged or compromised endpoint, rather than through intentional testing of access paths.
How It Works in Practice
Accountability should sit with the teams that own the full decision chain, not just the directory. Identity teams define the access policy, security teams define the device trust requirements, and endpoint teams provide the telemetry that proves whether those requirements are met. IAM remains the enforcement point, but it needs trusted inputs from device assurance systems to make a meaningful decision.
In a mature model, access is evaluated at request time using multiple signals: user identity, device compliance, certificate status, patch level, jailbreak or root detection, location, and session risk. The policy may allow full access, step-up authentication, read-only access, or outright denial. That approach aligns with OWASP Non-Human Identity Top 10 and NIST’s emphasis on continuous verification rather than one-time trust.
- Identity team: define who can request access and under what assurance level.
- Endpoint team: provide managed-device status, compliance, and health signals.
- Security operations: monitor anomalies, drift, and exceptions in real time.
- Application owners: enforce conditional access at the service boundary, not only at login.
For non-human identities, the same logic applies to workload trust. NHIMG’s 52 NHI Breaches Analysis reinforces that compromised credentials and weak privilege boundaries are rarely contained by identity tooling alone. Device trust breaks down when legacy apps cannot consume conditional access signals, when contractors use unmanaged devices, or when offline endpoints cannot return fresh posture data because the trust decision becomes static and blind.
Common Variations and Edge Cases
Tighter device assurance often increases user friction and operational overhead, requiring organisations to balance stronger access control against business continuity. That tradeoff is real, especially in remote work, BYOD, field operations, and third-party access scenarios where full device management is impractical.
Current guidance suggests treating some of these cases as exceptions with compensating controls, but there is no universal standard for this yet. A contractor on an unmanaged device may need browser-based access with session limits, while a managed laptop may receive broader entitlements. The key is to avoid collapsing all exceptions into a single “trusted” bucket. NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks is useful here because it shows how risk grows when access decisions are detached from lifecycle controls, while the NIST SP 800-53 Rev 5 Security and Privacy Controls model supports separating access enforcement from device assurance ownership.
Where this guidance breaks down most often is in environments with split control planes, such as acquired companies, heavily outsourced IT, or applications that only support basic SSO without conditional access hooks. In those cases, accountability still belongs to security and identity leadership, but enforcement may need to shift to compensating controls such as segmentation, strong session monitoring, or explicit exception approvals.
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 CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 | Device trust depends on strong authentication and context-aware access decisions. |
| NIST SP 800-63 | AAL | Assurance levels help distinguish identity proofing from endpoint trust. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous verification of identity and device context. | |
| OWASP Non-Human Identity Top 10 | NHI-03 | Access decisions fail when workload or device trust is assumed without validation. |
| NIST AI RMF | GOVERN | Accountability requires clear ownership for risk decisions and control enforcement. |
Tie device assurance signals to access approvals and review exceptions through the access control process.
Related resources from NHI Mgmt Group
- Who should be accountable for closing access-trust gaps across BYOD, shadow IT, and unmanaged applications?
- Who is accountable when compliance or cyberinsurance requirements are not met because device trust is incomplete?
- Who is accountable when access governance fails in a complex application estate?
- Who is accountable when SAP access risks are not governed consistently across cloud and on premises systems?
