Use both signals at the time of access, not as separate checks that happen in different systems. User identity proves who authenticated, while device identity proves the endpoint is approved and eligible. The strongest model requires the user, device, resource, and policy to align before the request is allowed, especially for cloud and remote access.
Why combine user and device identity at the same decision point?
Access control works best when the decision is made from the complete context of the request, not from one identity signal in isolation. A signed-in user can still be risky if the endpoint is unmanaged, compromised, or outside policy. Likewise, a trusted device does not justify access if the user session is weak, over-scoped, or anomalous.
The practical reason to combine the two is that they answer different questions. User identity establishes who is asking, while device identity establishes whether the requesting endpoint is one you are willing to trust for that resource, at that moment. When teams separate those checks across systems or time windows, they create gaps that attackers and misconfigurations can exploit.
For that reason, many teams now treat the access decision as a joint evaluation of subject, endpoint, resource, and policy. That is especially important for remote access, hybrid work, and cloud services where the device is often the only reliable signal about local trustworthiness and compliance state.
How the combined model should work in practice
The design goal is not simply “add device checks” to an existing login flow. It is to make the access decision conditional on both the human or service actor and the device posture at the moment of authorization. That means the user may authenticate successfully, but access still fails if the endpoint is unknown, unhealthy, or not enrolled in the approved device trust process.
A sound implementation usually places device identity into the policy engine alongside user attributes, resource sensitivity, location, session context, and risk signals. The control should be enforced where access is granted, not only where identity is proven. That distinction matters because authentication alone does not tell you whether the session is coming from a corporate laptop, a hardened mobile device, or a compromised endpoint.
For cloud and remote access, the model works best when the device has a durable identity, such as a certificate-backed or attested device record, and the access policy checks that identity continuously or at least on reauthentication events. NHIMG’s Device and IoT Identity Guide is a useful reference when you want the device side of that trust model to be explicit rather than implied.
What makes this harder than a normal login flow?
The main challenge is that user identity and device identity are governed by different lifecycle processes. Users change roles, credentials expire, and sessions end. Devices get reimaged, replaced, patched, lost, enrolled, or retired. If those lifecycles are not joined, you can end up granting access to a valid user on an obsolete or untrusted endpoint, or blocking a legitimate user because device records are stale.
There is also a policy design issue. If teams over-rely on device identity, they can create a false sense of safety and allow broad access from “known good” endpoints. If they over-rely on user identity, they can ignore the endpoint as an attack surface and miss malware, token theft, or unmanaged devices. The better model is layered and contextual, not either-or.
NHIMG’s IAM and IGA Basics helps frame the user side of the control, while Authorisation Models Guide shows how to express the decision in policy terms rather than hardcoding it into isolated systems.
Risk and Threat Considerations
When user and device identity are checked separately, attackers can exploit the gap by hijacking a valid user session from an unmanaged or compromised endpoint. The same weakness also appears in legitimate operations when device state drifts, because stale approvals can leave access open long after the endpoint should have been removed from trust.
Failure mechanism: The access path accepts one strong signal, such as successful user authentication, while ignoring or inconsistently enforcing the endpoint trust condition. That creates an authorization gap that can be reached through stolen credentials, session theft, unmanaged devices, or delayed device revocation.
Impact: Sensitive resources may become reachable from endpoints that should not be trusted, which increases the chance of data exposure, lateral movement, and uncontrolled use of cloud or remote access privileges.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | User identity must be proven before access is granted. |
| IA-3 — Device Identification and Authentication | Device identity is central to deciding whether the endpoint is eligible for access. | |
| AC-3 — Access Enforcement | The combined user-device decision is enforced at authorization time. | |
| Recommendation — Authenticate organizational users before evaluating authorization and endpoint trust. Require device identification and authentication for approved endpoints. Enforce access only when user, device and policy conditions all pass. | ||
| NIST CSF 2.0 | PR.AA-05 — Assets Are Protected | Combining user and device signals strengthens protection of the access path. |
| Recommendation — Protect access decisions with device-aware authorization checks. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The topic is fundamentally about controlling access with multiple trust signals. |
| Recommendation — Define access rules that incorporate both user and device trust. | ||
Practitioner Guidance
What to verify: Confirm that the policy decision is made at the same point in time for both signals, and that the device check is not merely informational. If the access path can succeed when the device is unknown, stale, or noncompliant, the control is not doing real work.
Decision rule: If the resource is sensitive enough that endpoint trust matters, make device identity a gating condition for access rather than a post-login annotation. If the environment cannot support durable device identity, treat that as a control gap and reduce exposure through tighter resource segmentation.
What practitioners underestimate: The biggest failure is often operational, not conceptual. Teams build a strong sign-in flow, then leave device posture and device revocation disconnected from the authorization engine, which means the access policy looks strong on paper but fails at the moment that matters.
Practitioner takeaway: The useful standard is not “user authenticated” or “device trusted” in isolation, but “this user on this approved device may access this resource now.”
Related resources from NHI Mgmt Group
- How should security teams combine identity context with data context to improve access control?
- How should security teams structure initial user onboarding so identity states, group assignment, and access control work cleanly from the start?
- How should security teams decide whether JIT access is safe for non-human identities?
- How should security teams automate user access reviews without losing control quality?