IT teams should treat identity as the control plane, then map every device, user, service, and application to explicit access rules. That means reducing assumptions based on network location or device ownership, enforcing least privilege, and reviewing trust continuously. The practical goal is to make access decisions based on verified identity and context, not on whether something sits inside the perimeter.
Why access control starts with the identity, not the endpoint
A device-centric model assumes trust can be inferred from where a request comes from or what hardware it uses. An identity-centric model removes that shortcut: every request is evaluated against a known subject, its permissions, and the context of the request. That shift matters because access becomes portable across laptops, phones, workloads, APIs, and services, rather than tied to an IP range or managed device label.
This is the same logic behind Zero Trust Identity Guide, where policy follows the identity and trust is re-evaluated continuously instead of being granted once at the perimeter.
For teams, the practical change is architectural: identity becomes the control plane. Devices still matter, but as one signal among many, not as the basis for blanket access.
How to map users, devices, services, and applications to explicit access rules
The first implementation step is to inventory who and what actually asks for access, then separate those subjects into clear policy classes. Human users, managed devices, service accounts, workloads, and applications do not all deserve the same treatment, and they should not share the same assumptions about session length, approval, or privilege.
A useful reference point is IAM and IGA Basics, which frames authentication versus authorization, entitlement governance, and least privilege across both people and machines. That is the right mental model for moving from “is this device trusted?” to “what is this identity allowed to do right now?”
Once identities are mapped, apply explicit rules for access scope, resource sensitivity, and step-up requirements. The policy should answer three questions: what is the subject, what is it allowed to reach, and what additional assurance is required before access is granted.
What changes when trust is continuously reviewed
Continuous trust review means access decisions are not frozen at enrollment or login. They should be revisited when device posture changes, when a workload moves environments, when an application starts using a different token, or when a user’s risk context changes. This is where identity-centric access becomes more resilient than device-centric trust, because it can react to change instead of assuming continuity.
For teams managing both people and non-human actors, NHI Lifecycle Management Guide is a good companion view of the same principle: provisioning, rotation, offboarding, and review are lifecycle events, not one-time setup tasks. That matters because stale privileges and stale trust are often the real failure, not the original grant.
In practice, this also means access reviews should be driven by evidence: current ownership, current purpose, current scope, and current business need. If those cannot be demonstrated, the access should be treated as suspect or at least overdue for recertification.
Risk and Threat Considerations
Device-centric trust creates a brittle boundary that attackers can exploit through stolen devices, cloned posture, compromised VPN sessions, or misuse of credentials from an apparently managed endpoint. Once access is granted because a device looks trusted, excessive privilege and weak revalidation can turn one compromise into broad lateral movement.
Failure mechanism: The control fails when location, ownership, or device health is treated as a durable proxy for authorization, even though the actual subject, session, or workload state has changed.
Impact: Attackers can retain access after compromise, reuse a trusted path for persistence, and reach systems that should have required stronger verification or narrower scope.
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, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | Covers authentication for service and non-human subjects. |
| AC-6 — Least Privilege | Directly supports narrowing access by role and need, not device trust. | |
| Recommendation — Use IA-9 to authenticate workloads and services before granting access. Apply AC-6 to restrict each identity to the minimum required access. | ||
| NIST Zero Trust (SP 800-207) | 3 — Continuous Diagnostics and Mitigation | Identity-centric access depends on ongoing verification and context updates. |
| Recommendation — Continuously evaluate access signals before authorizing each session. | ||
| CIS Controls v8 | 6 — Access Control Management | Maps to account and access governance across users, devices, and services. |
| Recommendation — Inventory and govern all access paths, then remove standing excess privilege. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Requires controlled access based on policy rather than implicit trust. |
| Recommendation — Define and enforce access rules that follow identity and business need. | ||
Practitioner Guidance
What to prioritise: Start with the highest-blast-radius identities, including admin users, service accounts, and application credentials that can reach production systems. If those are still governed by broad network trust, the model is not yet identity-centric.
What to verify: Confirm that each access decision is tied to an explicit policy object, a current identity, and a current context signal. If a team cannot explain why access was allowed without referring to “it was on the corporate device,” the control design is still device-led.
Common mistake: Replacing perimeter trust with conditional access rules that still implicitly assume managed endpoints are safe by default. That is only a partial shift if privilege remains broad or if review is not continuous.
Practitioner takeaway: The real transition is not from devices to identities as labels, but from static trust to policy that is continuously bound to the subject, the privilege, and the moment of access.
Related resources from NHI Mgmt Group
- How should security teams run access reviews for non-human identities?
- How should security teams govern non-human identities that have persistent access?
- How should security teams govern API keys used for generative AI access?
- How should security teams use device identity in zero trust access decisions?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
