Device-centric controls fail when people share machines, move between endpoints, or use personal devices for work. A fixed machine policy cannot express changing trust, role, or session context, so the organisation ends up with inconsistent protection and technical debt. Identity-centric control is more reliable because the user remains the stable trust signal even as hardware changes.
Why Device-Centric Controls Fail in Modern Identity Environments
Device-centric controls assume the machine is the stable unit of trust, but modern work is built around identity, session context, and changing risk. That breaks down when the same person moves between corporate laptops, VDI, mobile endpoints, contractors, and unmanaged devices. A posture check can tell you the device is compliant, but it cannot tell you whether the current session should inherit the same access, or whether the request is now materially riskier.
This is why identity-centric control is increasingly the practical baseline, not a theoretical preference. NIST’s Cybersecurity Framework 2.0 emphasizes governance and continuous risk management, which aligns with the reality that trust must be evaluated as conditions change. NHIMG research also shows how often organisations still miss the basics: the Ultimate Guide to NHIs reports that only 5.7% of organisations have full visibility into their service accounts, a good indicator of how fragile machine-bound assumptions become at scale. In practice, many security teams discover the weakness of device-centric policy only after shared endpoints, remote work, or contractor access has already created inconsistent enforcement.
How Identity-Centric Control Replaces Fixed Device Trust
Security teams should shift from “what device is this?” to “who or what is requesting access, from what context, and for what purpose?” The difference matters because device attributes are static snapshots, while access decisions need to reflect live identity and session state. For human users, this usually means combining user identity, authentication strength, location, risk signals, and transaction context. For non-human identities, the same logic extends to workload identity, token scope, and workload provenance rather than the host alone.
In practice, that means:
- Use device posture as one input, not the decision-maker.
- Bind access to identity and session risk, not a single trusted machine.
- Apply least privilege and short-lived authorisation instead of persistent device trust.
- Re-evaluate access when context changes, such as endpoint drift, user switching, or remote access escalation.
This model fits better with Zero Trust thinking and with the operational realities documented in the Top 10 NHI Issues, where static secrets and excessive privileges routinely outlive the devices they were first issued from. It also aligns with the broader identity governance direction in NIST CSF 2.0, which treats access as an ongoing control problem rather than a one-time device approval. Current guidance suggests that device trust should be treated as a contributing signal, while the actual decision should be made at runtime using identity, session, and risk context. These controls tend to break down in BYOD-heavy environments with legacy VPNs because device posture and user intent diverge too often to support reliable enforcement.
Common Variations and Edge Cases
Tighter device control often increases operational friction, requiring organisations to balance stronger posture checks against user mobility and support overhead. That tradeoff becomes obvious in environments with shared workstations, third-party access, kiosk devices, VDI, or highly dynamic contractor workflows. In those cases, a fixed device policy can become either too strict to use or too weak to trust.
There is no universal standard for this yet, but current guidance suggests a layered model: device posture for hygiene, identity for authorisation, and session controls for ongoing assurance. This matters even more for non-human identities, where the “device” may be a container, runner, function, or ephemeral workload rather than a laptop. NHIMG’s Ultimate Guide to NHIs — Standards is useful here because it frames governance around lifecycle, visibility, and rotation instead of host trust alone. The practical lesson is that device-centric controls can still support assurance, but they should not be the sole gatekeeper when identities move across hardware and trust boundaries. Teams often learn this after remote access exceptions, shared endpoints, or endpoint sprawl have already turned policy exceptions into permanent architecture.
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 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, 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.AC-4 | Access decisions should shift from device trust to identity and context. |
| NIST Zero Trust (SP 800-207) | Zero Trust rejects implicit trust in endpoints and requires continuous verification. | |
| OWASP Non-Human Identity Top 10 | NHI-01 | Device-centric thinking fails for NHIs that move across hosts and environments. |
| CSA MAESTRO | Agent and workload governance must account for context, not fixed device trust. | |
| NIST AI RMF | AI systems change behavior and context, so trust must be managed continuously. |
Treat device posture as an input and enforce runtime access decisions against identity and session risk.
