Topic starter
19/08/2026 3:25 pm
TL;DR: Identity governance built for people is no longer sufficient for modern enterprises, Linx Security says, with service accounts, APIs, workloads, and AI agents now creating the larger share of access risk, while Sophos reports 71% of organisations had at least one identity-related incident in the past year. The shift to identity-centric IAM extends ownership, least privilege, lifecycle management, and access review to every identity type, but it also exposes the limits of governance models that still assume humans are the primary unit of control.
Editorial analysis by NHI Mgmt Group, based on content published by Linx Security: “Why Identity-Centric Security Is Replacing Human-Centric IAM”.
By the numbers:
- 71% of organisations had at least one identity-related security incident in the past year, according to Sophos as cited by Linx Security.
Key questions
Q: What breaks when identity governance stays focused only on employees?
A: Blind spots open up around identities that are not tied to a person, including APIs, workloads, certificates, and agents.
Q: Why do non-human identities increase risk when they are not tightly governed?
A: Non-human identities increase risk because they are numerous, often persistent, and frequently granted access that outlives the task they support.
Q: What signals show that identity-centric IAM is working?
A: Look for one inventory across human and non-human identities, named owners for every account, lower use of standing privilege, and lifecycle events that actually remove access when the identity is retired.
Practitioner guidance
- Unify identity inventory across human and non-human accounts Create a single inventory that maps employees, contractors, service accounts, APIs, workloads, and AI agents to accountable owners, systems, and lifecycle state.
- Assign operational owners to every non-human identity Require a named engineering, platform, or application owner for each service account, API, workload, or agent so governance does not depend on HR records or tribal knowledge.
- Convert standing privilege into time-bound access Use just-in-time access where business workflows can tolerate it, especially for identities that only need elevated permissions during discrete jobs or automation runs.
Bottom line: Traditional IAM leaves material risk when service accounts, APIs, workloads, and AI agents are governed outside the same model as employees.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:10 pm
Identity-centric IAM is a governance expansion, not a new category of control. The article is right to frame the shift as applying the same principles to more identity types, because ownership, least privilege, lifecycle management, and review already form the core of mature identity governance. What changes is the subject population, not the discipline. The practitioner conclusion is that program design should stop dividing identities into separate governance theories and instead unify them under one lifecycle and accountability model.
A few things that frame the scale:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: How should teams govern access when AI agents and service accounts share the same business systems?
A: Treat them as different identity subjects with the same governance obligation. Create one access model that covers ownership, entitlement scope, review cadence, and offboarding across human and non-human identities, then apply role-appropriate controls to each class. The goal is not separate programmes. It is one risk model that can follow access across systems and workflows.
👉 Read our full editorial: Identity-centric IAM is replacing human-centric governance