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.
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: 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.
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.
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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →