OWASP NHI Top 10: Six Risks Only Behavioral Observability Can Detect

OWASP built a catalogue of what goes wrong with machine credentials. It did not build a way to find out which ones you are carrying. Six of the ten risks cannot be answered from configuration or provisioning at all.

OWASP shipped the Non-Human Identity Top 10 for an unglamorous reason. Every other Top Ten assumes a person is behind the login. Injection, broken access control, security misconfiguration, all of it written with a human somewhere in the loop, subject to onboarding, MFA, a manager, and eventually an exit interview. This catalogue covers everything that authenticates without one: service accounts, API keys, workload identities, CI/CD tokens, assumed roles, and the agents and pipelines carrying them.

Ten risks, ranked on exploitability, prevalence, detectability, and impact. Improper offboarding at number one, secret leakage at two. Long-lived secrets, overprivileged NHIs, credential reuse, environment isolation failures, and at number ten, humans quietly driving service accounts because their own account has MFA on it.

Now open the project's Detection Resources page. It indexes one open-source tool. GitHub only.

We do not read that as a failure of the project, which is careful, vendor-neutral, and honest about its own inclusion criteria. We read it as an accurate snapshot of where the industry sits. There is now a mature taxonomy of what goes wrong with machine credentials and very little that tells you which of the ten you are carrying right now, on which credential, in which system.

Why the catalogue resists automation

Machine or Non-Human identities now outrun humans by 109 to 1 in Palo Alto Networks' 2026 Identity Security Landscape, up from 82 to 1 the year prior, across roughly 2,900 decision-makers. Entro Labs puts cloud-native environments closer to 144 to 1. Pick your denominator, at any of those numbers a taxonomy you apply by hand is a reading exercise, not a control.

Sort the ten into two piles and the problem gets specific.

Pile one is declared state. Overprivileged NHIs, long-lived secrets, insecure cloud deployment configurations, secrets committed to repositories. These live in IAM policy documents, key metadata, pipeline definitions, and source control, and the tooling here is real. Policy analyzers parse grants. Secret scanners parse commits. GitGuardian found 28.65 million new hardcoded secrets on public GitHub during 2025, a 34 percent jump, which tells you the scanning works fine. Ask what a credential is permitted to do and something in your stack answers today. Ask what it actually did and the room goes quiet.

Pile two is observed behavior, and six of the ten sit there.

There is also a structural gap in how most NHI discovery gets done, and it matters for coverage. Nearly every tool in this category enumerates by API. It authenticates to Entra ID, to AWS IAM, to GitHub, to Okta, and asks each platform to list its own service principals, roles, apps, and keys. That works, and it is bounded by an obvious ceiling: you only discover identities inside systems that expose a management API and agree to describe them. A service account performing an LDAP simple bind against a domain controller does not appear in any SaaS inventory. Neither does a Postgres role authenticating over a private subnet, an appliance holding a local account, a Kerberos service principal requesting tickets for a file share, or a container presenting a static bearer token to an internal API that predates your identity program. Those credentials authenticate constantly. No API will volunteer them.

This is why flow-based discovery became the approach we invested in. AuthMind derives identity from access paths, correlating identity and system events with network, cloud, and application logs rather than installing agents or polling platform APIs, and builds the inventory from what actually authenticated. Different input, different ceiling. Below are the six behavioral risks and the signal each one produces.

Mapping the six that only behavior answers

NHI1, Improper Offboarding

Ranked first, and it is not a configuration fact. Configuration confirms the identity exists. Only authentication activity tells you whether anything still uses it, from where, and against what. Two findings come out of last-use telemetry and they get opposite treatment. A service principal nobody claims with no successful authentication in nine months is cleanup. The same principal authenticating forty minutes ago from a commercial hosting ASN is an incident. Configuration reads identically in both cases.

The catch is that last-use has to span every protocol, not just federated sign-in, because IdP logs only observe what routed through the IdP. Kerberos ticket requests, LDAP binds, direct database authentication, SigV4-signed S3 calls, and Kubernetes API bearer tokens all constitute use, and all of them are invisible to a discovery method that reads the IdP and stops. Ownership attribution is the other half. Mapping each NHI back to a real corporate owner is what turns a dormant-credential list into a set of decisions somebody will actually make.

NHI2, Secret Leakage

Scanners answer where secrets are stored. They cannot answer whether a secret is being used, by whom, or whether the consumer is the one you provisioned it for. That distinction is why the remediation numbers look the way they do, and we will come back to it.

Flow-based observability closes the loop from the other end: which identity accessed the vault or secrets manager, which secret was retrieved, and where that material was subsequently presented. It also surfaces the stores nobody registered. Shadow vaults and unmanaged key managers are common, and they are common precisely because standing up a secrets backend is a fifteen-minute task that no approval workflow gates. A vault your program does not know about holds credentials your program cannot rotate.

NHI3, Vulnerable Third-Party NHI

OWASP frames this around IDE extensions and third-party SaaS, and the discovery question is which external integrations actually hold live tokens against your estate. App registries list the ones somebody filed. Outbound access paths reveal the rest, including OAuth grants issued by a developer eighteen months ago to a vendor that has since been acquired. Third-party NHI risk is fundamentally an inventory problem wearing a supply-chain costume.

NHI4, Insecure Authentication

Technically the cleanest case for observability, because declared intent and runtime behavior separate here more sharply than anywhere else on the list. OWASP names deprecated OAuth flows explicitly: implicit flow exposing access tokens in the URL, authorization code without PKCE, non-standard implementations that mint JWTs on demand or convert access tokens into cookies, and app-specific passwords that route around MFA entirely.

Your architecture diagram says OIDC with federated workload identity. Your traffic may show a subset of those workloads falling back to a static bearer token when the federated path errors, NTLM in play where policy retired it, an LDAP simple bind carrying credentials in cleartext, RC4 encryption types still negotiated in Kerberos exchanges, or HTTP Basic surviving on an internal API because one consumer never migrated. Both statements are true at once, and only one describes what an attacker gets to use. Observed authentication method per flow is a field configuration does not have.

NHI8 and NHI9, Environment Isolation and NHI Reuse

These share a shape. A credential's definition lives in one place and knows nothing about how many places present it. Reuse exists only as a pattern across authentication events: one key, four distinct source workloads. Isolation failure is the same pattern with a segment boundary crossed, the same credential fingerprint authenticating from production and from a staging subnet. Neither is a lookup. Both are a fan-out count you have to observe, and fan-out is also the most honest available proxy for blast radius, since it tells you what genuinely breaks if you kill the credential.

NHI10, Human Use of NHI

Cannot be discovered any other way, full stop. No field in any system records that a person is driving a service account. It exists exclusively as behavior: interactive session characteristics on a credential built for programmatic access, a workstation subnet as the source rather than a compute node, activity clustering in business hours in one timezone, and no MFA anywhere in the path.

Every individual event is legitimate. The pattern is the finding.

Resolving it means attributing that activity back to a named human, which is the same ownership machinery NHI1 needs.

Cloud deployment configurations, NHI6, land in between. Static access keys versus a properly scoped Assume Role With Web Identity call is a config question, but which subjects actually assume a given role, and whether an assumed-role chain terminates somewhere your threat model never anticipated, comes from the access path.

What this is worth in a budget conversation

Here is the number that reframes the whole discussion. Of secrets GitGuardian confirmed valid in 2022, 64 percent were still unrevoked as of early 2026. Four years. Found, reported, ticketed, still live.

Detection worked. Remediation stalled, and it stalled for a reason every operator will recognize: nobody could say with confidence what would break if they killed the credential. So it stayed, got an exception, and aged into infrastructure. Usage evidence is what dissolves that. A finding that says "this key is over-permissioned" produces a queue item. A finding that says "this key is over-permissioned, has been presented by exactly one workload for six months, and has never exercised ninety percent of what it is entitled to" produces a decision that closes.

Same logic runs the other direction on cost. Rotate-everything is the post-incident reflex and it carries a real bill in engineering hours, change windows, and breakage, while doing nothing about reach. A shared connector credential bound to cluster-admin was never a rotation problem, and rotating it buys a fresh key with identical blast radius. Knowing what is genuinely in service lets you retire rather than rotate. Retiring only costs once.

Two findings from our own deployments have held steady. Roughly 65 percent of the AI and automation identities we surface are unmanaged, and about half were not on the customer's inventory at all before we looked. Where the agentic ones live is the part that should bother you: about 95 percent of the agentic AI activity we observe sits in user environments rather than the data center. Which drops risk number ten, the one that only behavior can find, directly into the path of the fastest-growing identity population you have. Palo Alto's survey has AI agent populations projected to grow 85 percent this year, with only 37 percent of organizations able to revoke agent credentials and 30 percent holding immutable audit logs of agent activity.

What we would ask on Monday

Take the OWASP list and add a column its authors deliberately left out. For each of the ten, write the system that would tell you whether you have it, and mark whether that system reads configuration or observes behavior. Six of your answers will be blank or will name a config source that structurally cannot produce the finding.

Then two questions for whoever owns detection. If a service account started behaving like a person on Thursday afternoon, which rule fires? And if one authenticated successfully from an address that has never presented it before, does anything see the origin change, or only the success?

OWASP told us what to look for. Finding it is still ours.