An approach to device governance that treats the user identity as the primary control point rather than the endpoint alone. It aligns access, policy, and trust to the person using the device, which helps organisations support remote work, BYOD, and mixed device fleets without losing security or operational consistency.
Expanded Definition
Identity-centric device management is a governance model in which access decisions follow the user identity first and the endpoint second. It treats the device as one signal in the trust decision, not the sole source of authority, so policy can remain consistent across corporate laptops, personal devices, and temporary or shared hardware.
This approach is often discussed alongside zero trust, but it is not the same thing. Zero trust is a broader architecture, while identity-centric device management is the operational pattern that binds user context, device posture, and policy enforcement together. The boundary matters: an organisation can have strong device controls without being identity-centric if access still depends on static network location or unmanaged exceptions.
In practice, the model is most useful when device ownership changes often, users work remotely, or fleets mix managed and unmanaged assets. The practical question is not simply whether a device is trusted, but whether the current user, session, and policy state still support the requested access.
For a broader identity governance baseline, NIST Cybersecurity Framework 2.0 remains a useful reference for access control and governance expectations, especially where device policy has to be tied to repeatable operational accountability.
Examples and Use Cases
- A contractor signs in from a personal laptop, and the organisation grants only the applications allowed for that identity, rather than opening broad network access to the device.
- A managed tablet used by frontline staff receives different access than the same tablet used by an admin account, because identity and role shape the policy outcome.
- A remote employee moves between home Wi-Fi and office connectivity without changing access behaviour, because the trust decision is identity-led rather than location-led.
- A bring-your-own-device programme permits email and collaboration tools but blocks sensitive admin consoles until the user meets stronger assurance conditions.
- A support team revokes access for a departing user across all device types at once, which is faster than trying to identify and clean up endpoint-specific exceptions.
The main tradeoff is operational complexity: once identity becomes the control point, policy design must be precise enough to avoid overexposure while still allowing legitimate flexibility. That usually requires good lifecycle discipline for users, sessions, and device posture signals.
NHIMG research shows why the model matters at scale: Ultimate Guide to NHIs notes that NHIs outnumber human identities by 25x to 50x in modern enterprises, which illustrates how identity-driven control models must handle volume, not just individual devices.
Security Implications
When identity-centric device management is misapplied, organisations may confuse user trust with device trust and create access paths that are broader than intended. The result is often inconsistent enforcement: one device can become a back door to multiple applications, or one stale identity can preserve access long after the user context has changed.
That failure mode matters because the attack surface is no longer just the endpoint. Weak identity proofing, poor session revocation, or overbroad policy exceptions can let an attacker reuse a legitimate account from an untrusted device, while defenders may assume the endpoint controls are enough.
Observable symptoms include excessive policy exceptions, persistent access after role changes, and fragmented enforcement across remote access, SaaS, and administrative tools. In environments with mixed fleets, the biggest gap is often not device compromise alone, but the inability to explain why two users on similar hardware receive very different trust outcomes.
NHIMG data underscores the governance impact: only 5.7% of organisations have full visibility into their service accounts, which is a reminder that identity-led control breaks down quickly when identity inventory and access ownership are weak.
Domain and Governance Relevance
In NHI and machine-access environments, identity-centric thinking is especially important because the same governance pattern often applies to service accounts, automation, and agent-driven access. The lesson from human device management carries over: access should be tied to a governed identity, current policy, and a clear ownership model, not to an asset being trusted by habit.
That makes lifecycle control more important than endpoint inventory alone. If the identity changes, is offboarded, or loses its assurance state, access must change with it, regardless of whether the underlying device still looks healthy. This is where identity-centric design supports both remote work and broader machine identity governance.
The term also highlights a governance distinction that teams sometimes miss: device compliance is not the same as access legitimacy. A compliant endpoint can still be a poor trust anchor if the identity attached to it is excessive, stale, or poorly governed.
For organisations aligning device policy with identity governance, the practical value is consistency. It becomes easier to enforce least privilege, reduce exception sprawl, and make access decisions that survive changes in location, device type, and operating context.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207), CIS Controls v8 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication, and Access Control | Identity-centric device management ties access decisions to user identity and assurance. |
| Recommendation — Align device access policy to identity assurance and enforce access control consistently across device types. | ||
| NIST Zero Trust (SP 800-207) | JEA — Least Privilege Access Decisions | The model applies zero trust by evaluating the user, device, and session before granting access. |
| Recommendation — Evaluate each request using identity, device posture, and context before granting access. | ||
| CIS Controls v8 | 6 — Access Control Management | The term depends on governing who can access what across managed and unmanaged endpoints. |
| Recommendation — Standardise account and access decisions so device differences do not create uncontrolled exceptions. | ||
| NIST AI RMF | GOVERN — Govern, Map, Measure, and Manage AI Risks | Identity-centric access becomes relevant where automated systems or AI agents inherit user-led policy. |
| Recommendation — Map identity-led device policy into governance so automated access remains explainable and controlled. | ||
| MITRE ATT&CK | T1078 — Valid Accounts | Stale or overbroad identity-led access can be abused with legitimate credentials from untrusted devices. |
| Recommendation — Monitor for valid-account abuse and revoke access quickly when identity context no longer matches. | ||
