TL;DR: User identity alone can look legitimate even when access comes from an unknown or unmanaged endpoint, because MFA, stolen session tokens, and approved accounts do not prove the device is trusted, according to ThreatLocker. The practical control shift is to combine user, device, resource, and policy signals so access decisions are tied to both identity and endpoint.
At a glance
What this is: This is a device identity analysis that shows why authenticated users can still be risky when the connecting endpoint is unknown, unmanaged, or compromised.
Why it matters: IAM teams need device identity alongside user identity because a valid login is not enough to trust the endpoint, especially in Zero Trust and BYOD scenarios.
Context
A login can be valid while the endpoint is still unsafe, which leaves a gap in identity assurance that user-centric controls alone cannot close. Device identity fills that gap by making the access decision depend on what is connecting as well as who is connecting, which is why it matters in non-human identity definitions as well as broader access governance.
In practical terms, device identity is the verifiable binding between an endpoint and the organisation’s trust model. If that binding is weak, copied, or stale, the access programme has no reliable way to distinguish an approved laptop from a spoofed or unmanaged one.
Key questions
Q: How should security teams combine user identity and device identity in access control?
A: 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.
Q: Why do valid credentials still create risk on unmanaged devices?
A: Because authentication proves only that the identity artefact was accepted, not that the endpoint is trusted. A stolen session token, replayed login, or approved account on a personal device can still reach data if the access model does not check the device. The risk is that a legitimate identity becomes an illegitimate access path.
Q: What are the signs that device identity controls are too weak?
A: Warning signs include stale endpoint records, permissive re-enrollment, alternate access routes that bypass device checks, and exceptions that remain in place after a device changes ownership or status. If the organisation cannot say which devices are approved right now, the control is not strong enough to rely on for access decisions.
Q: What should organisations do when a fleet device is retired or stolen?
A: Revoke its remote-access credentials immediately and remove its lifecycle labels from the access catalogue. If credentials are long-lived, a stolen or decommissioned device can keep tunnelling into the environment long after the business has lost track of it. Lifecycle offboarding has to be as authoritative as the original enrollment.
Technical breakdown
Why user identity is not enough for access control
User identity answers who authenticated, but it does not prove the endpoint is trustworthy. A stolen session token, a phished MFA approval, or a valid account used from an unmanaged laptop can all look legitimate at the login layer. Device identity adds a separate trust signal by tying access to evidence that is harder to copy or replay, such as managed enrollment, device-bound keys, or certificates. That distinction matters because authentication success and device trust are different controls. Mature access decisions do not treat either one as complete on its own. See the MFA Guide.
Practical implication: Treat user authentication as necessary but insufficient, and require a separate device trust check before granting access.
What makes a device identity stronger than an inventory record
A device identity is stronger when it is bound to the endpoint, managed through its full lifecycle, and revocable when status changes. A serial number or device name may help with inventory, but those attributes can be copied or spoofed. Strong device identity depends on evidence that is difficult to reproduce elsewhere and remains linked to ownership, approval, and retirement. That means the trust signal must survive beyond initial enrollment and must be invalidated when the device is lost, decommissioned, or reassigned. Otherwise, the organisation is relying on a static label rather than a living trust relationship. See the NHI Lifecycle Management Guide.
Practical implication: Use device-bound proof that can be revoked, not static inventory attributes that attackers can imitate.
How user, device, and policy should combine at the access path
The access decision should be evaluated at the point of connection, not only at sign-in. A user may be authorised for a resource, but the request should still fail if the device is unmanaged, the route is untrusted, or the policy does not match the requested action. This is the Zero Trust logic applied to endpoint assurance: verify the subject, verify the device, then constrain what that combination can reach. The critical architectural point is that the application must not remain reachable through an alternate path that bypasses the device check.
Practical implication: Enforce the device decision in the access path itself, so alternate routes cannot bypass trust validation.
Threat narrative
Attacker objective: The attacker wants to turn a valid login or stolen session into broader access from an untrusted endpoint.
- Entry begins when a user authenticates successfully from either a personal device or an endpoint an attacker has not earned trust for, making the initial access appear legitimate.
- Credential or session abuse follows when an adversary reuses stolen session material or valid credentials from different hardware than the organisation expects.
- Impact occurs when the environment allows that identity to reach resources without checking device trust, which expands access beyond the intended control boundary.
Breaches seen in the wild
- Okta support system breach 2023: A support service account credential saved in a personal Google profile let attackers take HAR files and hijack five Okta customers' sessions.
- CircleCI breach 2023: Malware stole a CircleCI engineer's SSO session; attackers exfiltrated customers' CI/CD secrets and keys, forcing a platform-wide rotation.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Device identity is now a second control plane for access decisions, not an optional context signal. User identity tells you who authenticated, but device identity tells you whether the endpoint itself is part of the trust boundary. That distinction matters because modern access failures increasingly arrive through valid accounts used on untrusted hardware. Security teams that still treat device signals as advisory are underestimating the attack surface.
Trusted-device assumptions collapse once authentication artefacts can move across hardware. A session token, MFA approval, or password does not prove the request came from an approved endpoint. The broken premise is that user authentication alone can anchor policy enforcement across all access paths. Once that premise fails, identity governance has to recognise the device as a first-class subject of control, not a peripheral attribute.
Device identity and device posture solve different problems, and confusion between them weakens both. Device identity establishes which endpoint is connecting, while posture asks whether that endpoint currently satisfies security conditions. Conflating the two creates false confidence: a known device can still be risky, and a healthy posture score does not establish ownership or enrolment. Practitioners need both signals to avoid over-trusting either state.
The named concept here is endpoint trust binding: the access model only works when identity, device, and policy are bound together at decision time. If those signals are evaluated separately or too early, attackers can slip through with legitimate credentials on the wrong endpoint. The control lesson is that trust has to be enforced where the request is made, not inferred after the fact.
What this signals
Endpoint trust binding: access programmes are moving toward decisions that bind user, device, and policy at the same enforcement point. That shift matters because any control that only checks identity at sign-in leaves room for token replay, unmanaged endpoints, and stale trust to persist after authentication.
Device identity also changes how teams should think about exception handling. Once the endpoint itself becomes part of the trust decision, temporary access, contractor access, and BYOD all need explicit revocation logic instead of relying on a one-time enrollment event.
The practical signal for programmes is simple: if device state changes but access does not, the organisation is still treating endpoint trust as static. A Zero Trust model only holds when device eligibility is continuously reassessed through the access path.
For practitioners
- Build an authoritative device inventory Classify endpoints by ownership, approval status, and business purpose so the access programme can tell which devices are eligible and which are not.
- Require device-bound proof Use managed enrollment and device-bound credentials, then protect the underlying keys so re-enrollment and impersonation are harder.
- Bind policy to the full request Evaluate user, device, resource, and action together, so a valid account cannot reach sensitive systems from an unmanaged endpoint.
- Enforce access at the connection path Route internal and cloud access through controlled pathways that validate the device before allowing the session to continue.
- Revoke trust when device status changes Remove access when a device is lost, retired, reassigned, or noncompliant, and test that revocation actually takes effect. See the NHI Lifecycle Management Guide.
Key takeaways
- Device identity closes a gap that user authentication cannot cover, because a legitimate login does not prove the endpoint is trusted.
- The main risk is not just stolen credentials but valid identity material being reused from unmanaged or unseen hardware.
- Effective programmes bind access to both subject and endpoint, then revoke trust when device status changes.
Related NHI Mgmt Group resources: Identity Security Programme Guide · NHI Lifecycle Management Guide · MFA Guide · Device and IoT Identity Guide
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 addresses the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-06 — Insecure Cloud Deployment Configurations | Device trust is enforced through cloud and access pathways that fail when validation is bypassed. |
| Recommendation — Enforce cloud access policies so device trust checks cannot be bypassed through alternate routes. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about access decisions that combine user and device signals before authorisation. |
| Recommendation — Tie authorisation to both identity and device eligibility before granting access to resources. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Session and credential handling are central to the token replay and device trust problem described. |
| Recommendation — Manage authenticators so stolen or replayed sessions do not remain usable across untrusted endpoints. | ||
| NIST Zero Trust (SP 800-207) | Continuous verification — Continuous verification | The article explicitly argues for Zero Trust decisions that verify the endpoint as well as the user. |
| Recommendation — Apply continuous verification so access remains contingent on both user and device trust. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article relies on controlled account and access lifecycle decisions for approved devices and users. |
| Recommendation — Use account governance to revoke device-linked access when ownership or approval status changes. | ||
Key terms
- Device Identity: Device identity is the cryptographic proof that a specific machine is the thing being accessed, independent of its IP address or current network. In fleet governance, it allows policy, audit, and revocation to follow the device across locations and transports.
- Device Posture: The current security condition of a device or runtime at the moment access is requested or renewed. Posture can include patch state, protection status, integrity, and whether the endpoint is managed. In identity governance, posture is part of the trust decision, not a separate endpoint problem.
- Endpoint trust binding: Endpoint trust binding is the practice of linking access rights to both the user and the specific device making the request. It prevents organisations from treating authentication success as sufficient proof of safety and forces access decisions to be evaluated at the point of connection.
- Unmanaged Device: An unmanaged device is a system that connects to enterprise resources without being fully enrolled in security controls, inventory, or policy enforcement. These devices are dangerous because they may still carry valid credentials, cached sessions, or access paths that attackers can exploit.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org