What is the difference between device-centric and identity-centric access control?

Device-centric access control starts with the endpoint and treats the device as the main trust signal. Identity-centric access control starts with the person, service, or workload and evaluates access based on verified identity, context, and policy. The first model is narrower and often easier to overtrust. The second better supports modern environments with remote work, SaaS, and non-human identities.

How the two models think about trust

Device-centric access control treats the endpoint as the main signal, so trust is built around the device state, device posture, or whether the endpoint is recognised. That works best when the endpoint is tightly managed and the device is a reliable proxy for the actor. Identity-centric access control moves the decision to the actor itself, then uses context and policy to decide whether that actor should be allowed in.

The practical difference is that device-centric control asks, “Is this a trusted device?” while identity-centric control asks, “Is this the right identity, under the right conditions, for this action?” That shift matters because the same person can operate from many devices, and the same device can be used by many identities or processes over time.

Identity-centric control also fits better with a zero trust identity approach, where the access decision is continuous rather than granted once because the endpoint looked safe at sign-in.

Where device-centric control is still useful

Device-centric access control is not obsolete. It is often effective in environments where endpoints are centrally managed, the attack surface is small, and the organisation can reliably enforce device compliance, patching, and hardware trust. In those cases, the device can be a strong part of the access decision, especially for local apps, internal networks, and tightly controlled corporate fleets.

The weakness is that a trusted device is not the same thing as a trustworthy request. If a session is hijacked, a browser is abused, or credentials are stolen elsewhere, device trust can become an overbroad shortcut. Device-centric models also struggle when users work remotely, use unmanaged devices, or reach SaaS platforms that need finer-grained policy decisions than “this laptop is approved.”

For device trust to be credible, teams usually need to pair it with strong device attestation and lifecycle discipline. A useful reference point is the Device and IoT Identity Guide, because the same trust problem appears when endpoints, phones, and connected devices become access actors themselves.

Why identity-centric access control is the better default for modern environments

Identity-centric access control is broader because it evaluates the person, service, workload, or other actor, then layers policy on top of identity, context, and least privilege. That makes it better suited to hybrid work, SaaS, API-driven systems, and non-human access paths, where the device alone cannot describe who or what is actually asking for access.

This model is especially important when access is not just human. Service accounts, workloads, tokens, and integrations often need permissions that are independent of any one machine. That is why identity-centric control is usually paired with governance over credentials, entitlements, and privilege boundaries rather than just endpoint checks. A good foundation for that broader model is IAM and IGA Basics, because identity-centric access depends on lifecycle, authorization, and review discipline.

It also helps explain why mature access programs increasingly separate authentication from authorization. You can confirm identity without granting broad access, and you can re-evaluate access each time a request is made. That is the logic behind modern policy-driven controls such as Authorisation Models Guide, which shows how roles, attributes, and relationships can express access more precisely than device trust alone.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST Zero Trust (SP 800-207), NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST Zero Trust (SP 800-207)	Identity-centric access control — Zero Trust Architecture	The question contrasts endpoint trust with identity-led access decisions.
Recommendation — Shift sensitive access decisions from endpoint trust to identity, context, and policy signals.
NIST SP 800-53 Rev 5	IA-2 — Identification and Authentication (Organizational Users)	Identity-centric control depends on verifying the requesting user before access is granted.
	IA-9 — Identification and Authentication (Non-Organizational Users)	Identity-centric access also applies to external users, services, and other non-corporate actors.
	AC-6 — Least Privilege	Identity-centric access is typically paired with least-privilege authorization instead of broad device trust.
Recommendation — Require strong authentication for organizational users before enforcing access policy. Apply appropriate authentication controls to non-organizational identities and access paths. Limit each identity to the minimum permissions needed for the request.
CIS Controls v8	CIS-6 — Access Control Management	The comparison is fundamentally about how access is granted and restricted.
Recommendation — Centralise access decisions and review them against identity and business need.

Practitioner Guidance

What to prioritise: Use device-centric control for device hygiene and posture, but do not let it become the only gate for sensitive access. If the action is high impact, require identity and context checks in addition to endpoint trust.

What to verify: Confirm that the access policy can distinguish a managed endpoint from a trusted requester. If the same policy would approve a stolen session, a shared device, or a service credential used from a different host, the model is too device-led.

What practitioners underestimate: Device trust can hide privilege creep because it feels operationally simple. The stronger design is usually identity-first, with device signals used as one input among several rather than as the deciding factor.

Practitioner takeaway: Device-centric control answers “is the endpoint acceptable?”, but identity-centric control answers the security question that usually matters more, “should this actor get this access, right now, for this request?”