Non-Human Identity Maturity: Why It Needs Its Own Lens

Ask most IAM programs how they are doing and they will answer for their people: employees, contractors, the occasional partner account. Ask how they are doing on service accounts, API keys, CI/CD credentials, and the workload identities their applications use to talk to each other, and the answer gets quieter. That gap is no longer a rounding error. Palo Alto Networks' 2026 Identity Security Landscape report, a survey of more than 2,900 cybersecurity decision-makers, found organizations now manage an average of 109 machine identities for every human one, up from 82-to-1 a year earlier, and projects machine identities to grow 77% over the next twelve months against 56% growth in human identities.

A maturity conversation that only covers human identity is measuring a shrinking share of the actual attack surface. This article covers why non-human identity (NHI) keeps falling outside workforce maturity assessments, which domains actually govern it, and what evidence separates a program that manages machine identity from one that is simply unaware of how much of it exists.

Why Non-Human Identity Gets Missed

The omission is structural, not negligent. Most maturity frameworks, AXIS included in its original form, were built around the joiner-mover-leaver model: a person enters the organization, changes roles, eventually leaves, and access follows that lifecycle. A service account has no HR record to trigger deprovisioning. An API key does not change roles. A workload identity spun up by a CI/CD pipeline may exist for minutes and never appear in any inventory built for people.

The result, per ManageEngine's Identity Security Outlook 2026 (515 security leaders across the US and Canada), is that nearly half of surveyed organizations report machine-to-human identity ratios above 100-to-1, with some sectors reporting ratios as high as 500-to-1, while only 12% have achieved comprehensive automated lifecycle management for those identities. The ratio keeps climbing. The governance has not caught up. A separate survey of 800 US and UK IT leaders found non-human identities already outnumber human users at 83% of organizations, while NHI governance sits at just 21% adoption, the lowest of any AI-era security practice the survey measured. (Palo Alto Networks and ManageEngine both sell identity-security products; both figures are vendor-sponsored research, and should be read as directional rather than definitive.)

Which Domains Actually Cover It

Non-human identity is not a tenth domain bolted onto a maturity model. It is a cross-cutting concern that several existing domains already own, once you look for it.

Privileged Access Management. Secrets management, the practice of storing, rotating, and brokering the credentials non-human identities use, is PAM territory. The AXIS question bank treats it as its own capability rather than an afterthought under human privileged access, because a hardcoded database password and a shared admin login fail in the same way: both are a standing credential nobody is watching. See the control page for secrets management for what the failure modes look like at each maturity level.

Identity Security and Posture. Detecting anomalous behavior from a compromised service account, and knowing the attack surface created by thousands of unmanaged API keys, sits in identity threat detection and response (ITDR) and posture management. A human analyst reviewing login anomalies will not catch a workload identity quietly calling an API it has never called before unless that detection capability was built for non-human behavior specifically.

Cloud and SaaS IAM. Most non-human identity growth is a cloud phenomenon: every microservice, every serverless function, every SaaS-to-SaaS integration mints an identity of some kind. An organization assessing its cloud IAM maturity without asking who owns and rotates those identities is assessing a fraction of its cloud footprint.

The AI Agent Problem

Autonomous AI agents are the newest and fastest-growing category of non-human identity, and they make the governance gap worse rather than better. A traditional service account does one thing: it calls a fixed set of APIs for a fixed purpose, and its behavior is at least theoretically predictable. An agent is built to take actions a developer did not explicitly code, chaining tool calls and API requests in response to a prompt rather than a script. That flexibility is the entire point of the technology, and it is also why an agent credential with broad standing access is a materially different risk than a narrow service account with the same access scope. Palo Alto Networks' 2026 research counts agent identities inside the 109-to-1 ratio cited above, and reports they are growing faster than any other machine identity category. Most organizations have no process that distinguishes an agent credential from an ordinary API key when deciding how much access it should receive by default.

The honest answer, for most programs in 2026, is that agent identity governance is still being built while agents are already in production. That ordering problem is not unique to AI; it is the same pattern organizations went through with cloud adoption a decade earlier, when workloads multiplied faster than the governance built to track them. The domains that caught up with cloud, PAM for the credentials and identity security for the behavioral detection, are the same domains that will have to catch up with agents. Treating agent identity as a wholly new problem, rather than the latest and fastest-moving instance of the non-human identity problem, risks building a parallel governance track that duplicates work the existing domains should already be doing.

What a Managed Program Looks Like

The gap between a managed and an unmanaged non-human identity program is not sophistication. It is whether four basic questions have real answers.

Can you produce a complete inventory? An unmanaged program discovers service accounts the way most organizations discover shadow IT: by accident, usually during an incident. A managed program runs continuous discovery against cloud provider APIs, secrets managers, and CI/CD systems, and can state a real count rather than an estimate.

Does every credential have a named human owner? “The platform team” is not an owner. A managed program can name the person accountable for a given service account's existence, which matters the moment that credential needs to be rotated, investigated, or retired.

Are credentials rotated on a schedule, not a memory? The unmanaged default is a secret created once at deployment and never touched again, because nothing forces the rotation and nobody wants to risk breaking production by changing it. A managed program treats non-human credentials the same way a mature PAM program treats privileged human ones: automatic rotation, no standing shared secrets, brokered access rather than embedded passwords.

Is there a decommissioning process, not just a provisioning one? Most organizations have some process for creating a service account. Far fewer have one for retiring it when the application it served is decommissioned. Orphaned non-human credentials, still valid, attached to nothing anyone is watching, are functionally identical to the orphaned human accounts that show up in nearly every breach post-mortem, except nobody is looking for them.

Is access scoped to what the identity actually needs? Over-permissioning is the default, not the exception, for non-human credentials. A service account provisioned during initial deployment is routinely granted broad access because narrowing it later risks breaking something nobody fully understands anymore, and nobody revisits the grant once the system is in production. A managed program treats that scope as a liability to be reduced over time, the same way a mature PAM program eliminates standing privileged access for people, rather than a one-time decision made at provisioning and never revisited.

Measuring Non-Human Identity Without a Separate Framework

Non-human identity maturity does not need a parallel scoring system. It needs the existing domains to actually ask about it, and most legacy workforce-only assessments do not. When evaluating any IAM maturity instrument, including your own, check whether its secrets-management, ITDR, and cloud IAM questions explicitly separate human and machine identity, or whether they quietly assume “access” means a person. The 37-question AXIS bank treats non-human credential management as its own capability inside PAM precisely so an organization cannot score well on privileged access while its service accounts sit unmanaged. The full methodology, including how foundational gaps cap an otherwise strong score, is on the methodology page. For the broader picture of how domains combine into one defensible number, see The IAM Maturity Model, Explained.

Common Questions

What counts as a non-human identity? Service accounts, API keys, OAuth application credentials, workload identities issued to containers or serverless functions, bots, and the growing category of autonomous AI agents that call internal systems on a human's behalf. Anything that authenticates but was not issued to a person.

Is this the same as machine identity management? The terms are used interchangeably in most research. Some vendors narrow “machine identity” to certificates and TLS keys specifically; this article uses the broader sense that includes service accounts and API credentials, which is how the surveys cited here define it.

Should non-human identity be its own assessment domain? Not if the existing domains are asking the right questions. Splitting it out risks the same problem workforce-only assessments already have: a score that looks complete while missing most of the actual identity population. Better to verify PAM, identity security, and cloud IAM each explicitly cover it than to add a tenth domain that competes with them for attention.