Topic starter
24/10/2026 9:48 pm
TL;DR: Trusted access still fails when the endpoint is unknown or unmanaged, because a legitimate login does not prove the device is approved, according to ThreatLocker. Access decisions need endpoint status wired into the same decision path as the user.
Editorial analysis by NHI Mgmt Group, based on content published by ThreatLocker: “Device identity vs. user identity: Why security teams need both”.
Key questions
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Device identity closes a gap that user authentication cannot cover, because a legitimate login does not prove the endpoint is trusted.
Glossary terms: Device Identity, Device Posture, Endpoint trust binding, Unmanaged Device
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 6 days ago by NHI Mgmt Group
25/10/2026 11:13 am
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.
A question worth separating out:
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.
👉 Read our full editorial: Device identity and user identity need paired access decisions
This post was modified 6 days ago by NHI Mgmt Group