User and device identity is the way an organisation recognises a person and an endpoint as distinct, trusted entities in access control and monitoring. It ties authentication, device posture, certificates, and enrolled device records together so policies can decide whether a login, token, or session should be allowed.
How user and device identity works
User and device identity is a paired trust model, not just a login label. The user establishes who is requesting access, while the device establishes which endpoint is joining the session, where the request is coming from, and whether the endpoint itself meets policy.
That pairing matters because modern access decisions rarely rely on a password or token alone. The identity system also considers device registration, certificate binding, attestation signals, posture, and enrollment state before it allows a session to proceed or applies step-up checks.
Why organisations bind people to endpoints
Binding a user to a device lets policy distinguish an authorised person on a trusted endpoint from the same person on an unmanaged or suspicious one. It supports conditional access, device trust, session risk scoring, and monitoring that can tell whether a token is being used from an expected endpoint.
This is especially important where access is sensitive, persistent, or high value. A strong user identity with a weak device can still be a risky session, and a trusted device without a valid user context should not automatically inherit access. The control objective is to reduce blind trust in either factor on its own.
For a practical overview of the device side of that trust model, see the Device and IoT Identity Guide, which covers device certificates, attestation, and secure onboarding.
What makes device identity trustworthy
Device identity is strongest when it is rooted in hardware, enrollment, and lifecycle control rather than a static label. Certificates, attestation, and managed device records help prove that the endpoint is the same device that was onboarded, is still under organisational control, and has not been trivially cloned or replaced.
That trust is only as good as the identity lifecycle behind it. If device records are stale, certificates are not rotated, or onboarding is weak, the organisation may continue to trust an endpoint long after its real security state has changed.
When you need a broader view of device identity across fleets, the Identity for IoT Fleets Guide explains provisioning, rotation, and retirement patterns for per-device identities.
For hardware-rooted approaches, the IoT Device Identity with TPM and DICE Guide shows how attestation and device keys can anchor trust in the endpoint itself.
How policy uses user and device identity together
In mature environments, user identity and device identity shape the same policy decision. The user proves intent, the device proves context, and the access layer decides whether to allow the login, issue a token, continue a session, or require additional verification.
This is why device identity often sits close to authentication, conditional access, and session monitoring. It helps systems recognise normal work patterns, flag impossible or unexpected device changes, and limit access when the endpoint no longer satisfies the organisation’s trust requirements.
For a broader explanation of how people and machine-held identities meet in practice, Human vs Non-Human Identity is useful background on the boundary between user-facing and machine-facing identity models.
For identity and access control at the account layer, Ultimate Guide to NHIs — What are Non-Human Identities is a useful companion reference where access decisions also depend on the identity type behind the request.
Risk and Threat Considerations
User and device identity becomes risky when organisations trust a session after authenticating the user but before validating the endpoint. Stolen tokens, cloned devices, unmanaged endpoints, or weak enrollment can let an attacker ride a valid user session from a device the organisation would never have approved on its own.
Failure mechanism: Weak device binding, stale device records, or poor certificate and attestation handling lets an untrusted endpoint present as trusted, so the access layer cannot reliably distinguish legitimate use from abuse.
Impact: Attackers may gain authorised-looking access, evade conditional access controls, persist through compromised sessions, or widen the blast radius of stolen credentials and tokens.
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 provides the primary governance reference for this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | User identity and login assurance are central to this access model. |
| IA-3 — Device Identification and Authentication | Device identity and endpoint trust are part of the access decision. | |
| IA-5 — Authenticator Management | Certificates, tokens, and enrollment material must be managed across the identity lifecycle. | |
| Recommendation — Require strong authentication for organizational users before granting access. Authenticate endpoints before allowing them to influence session or access decisions. Rotate, protect, and revoke authenticators and credentials across their lifecycle. | ||
Practitioner Guidance
Governance implication: Treat user identity and device identity as a single access decision domain, with clear ownership for enrollment, trust signals, certificate lifecycle, and decommissioning. If the user and device records drift apart, policy decisions become inconsistent even when authentication still appears to work.
What to watch for: Reused devices, orphaned device registrations, weak onboarding, and endpoints that keep being trusted after posture or ownership has changed. Those are the conditions where identity-based access control starts to lose precision.
Related resources from NHI Mgmt Group
- What is the difference between user identity and device identity in access decisions?
- What happens when organisations try to evaluate identity controls without testing multi-device and multi-user scenarios?
- What happens when mobile identity is used without strong device protection and user controls?
- How should organisations modernise user directory management as they move more identity and device control into the cloud?