OWASP NHI Top 10: 10 Controls to Mitigate Every Risk Category

Key Takeaways

• Non-human identities now outnumber humans by roughly 45 to 1 in cloud environments, making the OWASP NHI Top 10 the most relevant framework for machine identity risk in 2026.
• Secret leakage (NHI2) and long-lived secrets (NHI7) account for the majority of named NHI breaches in the last two years, including Drift/Salesloft, Okta, and BeyondTrust.
• Capital One's 2019 breach exposed 100 million records through a single overprivileged cloud IAM role, the textbook case for NHI5 (overprivileged NHI) and least-privilege enforcement.
• Traditional IAM and PAM were built for human workflows; mitigating the OWASP NHI Top 10 is the operational foundation of non-human identity security, requiring machine-first controls with runtime behavioral baselines per identity.

Quick Answer

What is the OWASP NHI Top 10?

Your environment is full of identities that are not people. Service accounts, API keys, OAuth tokens, workload identities, and AI agents now run most of the work in cloud and SaaS, and they outnumber human users by roughly 45 to 1. The OWASP NHI Top 10 is the security industry's shared list of the ten ways those identities most often get exploited, ranked by how much damage they cause in real breaches. It runs from leaving access in place after a workload is gone (NHI1) to people quietly borrowing a machine's credentials (NHI10). Unlike other OWASP top 10 security risks frameworks that catalog application and API vulnerability classes, the NHI Top 10 focuses on the identities operating behind those APIs, making it the reference framework for non-human identity security programs in 2026.

How do you mitigate the OWASP NHI Top 10?

Start by finding every non-human identity you have, then make sure each one holds only the access it needs, for only as long as it needs it. That single principle (right access, right duration, nothing extra) covers most of the framework. The rest comes down to watching how each identity behaves once it is live, and cleaning up the ones you no longer use. Every one of the ten OWASP categories maps to one of these moves, and each section below pairs the control with a real breach that shows what happens when it is missing.

In practice, that means five things:

• Know what you have. Keep a live inventory of every machine identity across cloud, SaaS, CI/CD, and AI agents, each tied to a named owner.
• Give each one its own identity. Avoid shared service accounts, and scope permissions to the single job the identity actually does.
• Keep credentials short-lived. Issue them when a task starts, rotate them automatically using short-lived credentials, and never paste a secret into code.
• Watch behavior, not just access. Build a baseline of how each identity normally acts so you can spot the moment it does something it never has before.
• Retire what you stop using. Remove access the instant a workload, employee, or vendor goes away, rather than waiting for the next audit. This is what the NHI lifecycle requires.

The OWASP NHI Top 10 at a Glance

Here is the full framework in plain terms: what each risk actually means, and the control that addresses it.

1. Eliminate Hardcoded Secrets and Strengthen API Key Security

Maps to NHI2 (secret leakage) and NHI7 (long-lived secrets). API key security and hardcoded credential hygiene remain the most common entry point in modern NHI breaches: poor API key security is the gap attackers reliably find first. The 2024 Drift chatbot compromise, which cascaded into 700 organizations across Salesforce, Google Workspace, Slack, S3, and Azure, started with a stolen OAuth token that retained the persistence and scope to traverse every connected SaaS surface.

The mitigation is to replace embedded secrets with vault-issued, short-lived credentials, and to scan repositories continuously through pre-commit hooks, CI gates, and post-merge sweeps. Any secret found in source control should be treated as already compromised: rotated, audited for downstream use, and the workflow refactored to fetch credentials at runtime rather than ship them in code.

2. Enforce Least Privilege for Non-Human Identities

Maps to NHI5 (overprivileged NHI) and NHI9 (NHI reuse). The 2019 Capital One breach is the textbook case: a single cloud IAM role had read access to S3 buckets it had no operational reason to touch, and an attacker who reached that role exfiltrated 100 million records. NHIs accumulate permissions because convenience consistently beats precision, and most environments lack the telemetry to show what each service account actually uses.

The least privilege principle requires scoping each identity to exactly the access its workload needs and nothing more. Failure modes and the mitigations that work in production:

3. Rotate Secrets and Shorten Credential Lifetimes

Maps to NHI7 (long-lived secrets) and NHI4 (insecure authentication). The 2023 Okta support system breach traced back to a service account credential saved insecurely on an engineer's personal device. The credential had been valid for an extended period with no rotation in place. Static, long-lived secrets are the most consistent source of preventable breach disclosures in the NHI category.

Automate token rotation and default to short-lived credentials issued by a secrets management platform, and remove humans from the credential lifecycle wherever feasible. Manual rotation does not scale to machine populations that turn over thousands of identities per CI/CD run.

4. Centralize Identity Visibility Across Cloud, SaaS, and CI/CD

Maps to NHI9 (NHI reuse) and underpins every other category. NHIs proliferate across environments faster than any inventory can track them manually. The common forms an inventory must cover:

• Service accounts in AWS IAM, Azure Entra ID, and Google Cloud IAM
• API keys, OAuth tokens, and webhook secrets across SaaS integrations
• Workload identities in Kubernetes and serverless runtimes
• Automation tokens in GitHub Actions, GitLab CI, and Jenkins
• AI agents and MCP server credentials interacting with internal tools

A unified identity graph that connects each NHI to its owner, workload, and downstream resources is the only practical way to regain control. An NHI without a named owner is an unowned blast radius waiting to be exploited.

5. Monitor Behavior, Not Just Access

Maps to NHI10 (human use of NHI) and NHI4 (insecure authentication). Static permission checks miss the actual threat surface, which is how a credential gets used once it is live. Runtime behavioral baselines per NHI catch the deviations that point to compromise:

• Unusual API call patterns, frequency spikes, or endpoints never touched before
• Unexpected data access by volume, geography, or sensitivity classification
• Deviation from the baseline established during normal operation of that specific identity

This is where machine identity security parts ways with human IAM. Humans have intuition, off-days, and patterns a SIEM can model in broad strokes. Machines have predictable behavior that, when it breaks, almost always signals something is wrong. A service account that has called the same three endpoints for six months and suddenly enumerates an S3 bucket is not a tuning problem, it is a signal.

6. Secure the Software Supply Chain

Maps to NHI3 (vulnerable third-party NHI). The 2024 BeyondTrust incident showed how a credential compromise in a remote support SaaS vendor cascaded into multiple customer environments, including the US Treasury. Third-party NHIs are now a standard breach vector, and most organizations have no inventory of which vendors hold which tokens with which scopes.

Common supply chain exposures and the mitigations that hold up under audit. Many of these exposures also intersect with broader OWASP top 10 security risks, particularly broken access control and insecure API design, because the same vendor token that holds too much scope is both an NHI governance failure and an application security risk:

7. Apply Just-in-Time Access for Machine Workflows

Maps to NHI4 (insecure authentication) and NHI5 (overprivileged NHI). Always-on access for NHIs creates blast radius that does not need to exist. Most automated workflows need their credentials for minutes, not months, and standing access is a convenience choice rather than a technical requirement. Just-in-time access eliminates that standing exposure entirely.

Just-in-time access for NHIs means:

• Credentials are issued at workflow start, not provisioned in advance
• Permissions are revoked automatically when the task completes
• Access is tied to specific triggers, not standing identity attributes

8. Isolate High-Risk Workloads by Blast Radius

Maps to NHI6 (insecure cloud deployment configurations) and NHI8 (environment isolation). Not all identities carry equal weight. A service account with read access to a non-production logging bucket and a service account with write access to production payment infrastructure are not the same problem, but most security tooling treats them identically.

Segment by blast radius. Tighten controls on identities that touch crown-jewel systems. Isolate them at the network, runtime, and identity layers so a compromise stays contained rather than cascading. Blast-radius analysis at provisioning time is faster and cheaper than incident response after the fact.

9. Audit and Govern Continuously

Maps to NHI1 (improper offboarding) and the lifecycle dimension of every other category. Quarterly reviews are not a control in environments where 1,000 new identities can spin up in a single CI/CD run. By the time a compliance audit catches a stale identity, it has often been exploitable for months.

Continuous identity lifecycle tracking, end-to-end ownership mapping, and real-time governance aligned to actual usage are the only patterns that scale to machine populations. Offboarding has to be event-driven (workload retired, employee departed, vendor offboarded) rather than calendar-driven.

10. Integrate NHIs into Your Zero Trust Strategy

Maps to NHI10 (human use of NHI) and reinforces all ten categories. NIST Zero Trust principles were largely articulated around human identities. The translation to machine identities is direct but rarely implemented: every request verified, every credential evaluated in context, every policy enforced at runtime rather than only at provisioning. Token's Zero Trust security model page covers how the principles apply specifically to NHIs.

Treating NHIs as first-class Zero Trust participants means:

• Every API call, not just every login, is authenticated and authorized
• Identity, device posture, and behavioral signals are combined per request
• Policies are evaluated continuously, not only at the moment of credential issuance
• Trust is evaluated, never assumed, on every request.

How Token Security Approaches the OWASP NHI Top 10

The Challenge

The pattern across every OWASP NHI category is the same. Non-human identities were never built into traditional IAM and PAM tooling as a first-class concept because that tooling was designed for humans logging into laptops, not for service accounts, OAuth tokens, and AI agents operating at API speed. Retrofitting human-first IAM onto machine populations is the gap the OWASP NHI Top 10 catalogs, one risk category at a time.

The Approach

Token Security is built around this gap. The platform is a dedicated non-human identity security solution that discovers every NHI across cloud, SaaS, CI/CD, and agentic AI environments, then builds a unified identity graph with ownership, entitlements, and runtime behavioral baselines per identity. Remediation is automated through the same control loop: detect drift, evaluate blast radius, and apply the right mitigation pattern from the ten categories above without manual ticket cycles.

The platform reinforces the Discover, Understand, Enforce model directly against the OWASP framework:

• Discover: continuous inventory of every NHI, including shadow AI agents and orphaned credentials (covers NHI1, NHI9)
• Understand: contextual entitlement mapping, blast-radius analysis, and behavioral baselining (covers NHI4, NHI5, NHI10)
• Enforce: automated remediation, lifecycle governance, and policy-driven controls (covers NHI2, NHI3, NHI6, NHI7, NHI8)

The Outcome

Security teams move from chasing each OWASP category by hand to operating a single control loop against the full framework. The 45-to-1 ratio is not slowing down, agentic AI is accelerating it, and the controls in this guide are the ones that hold up at the scale machine identities now operate.

How Security Teams Put the OWASP NHI Controls into Practice

Getting Visibility That Actually Leads to Action

NHI2, NHI5, and NHI9 share a common upstream failure: teams do not know what machine identities they have, let alone what each one can access. Lemonade's security team found themselves in exactly this position. They had tried other vendors and received broad claims about finding machine identity risk, with outputs too noisy to act on. The problem the OWASP NHI Top 10 describes is not just a discovery gap. It is a signal-to-noise problem. A tool that surfaces 50,000 findings has not solved NHI risk; it has created a different operational burden.

"Token Security has enhanced our security by providing us accurate and relevant visibility into machine identity risks, something I have yet to see from other vendors. It's the first service I've seen that delivers on the widely-made claim of finding machine identity risk. It provides us with the right amount of detail to mitigate issues without burdening us with tens of rows of useless alerts." — Jonathan Jaffe, CISO at Lemonade

That distinction matters for the OWASP framework specifically. NHI5 (overprivileged NHI) and NHI9 (NHI reuse) are not remediated by generating a list. They are remediated when a security team can see exactly which identity holds excess permissions, trace it to an owner, and fix it without breaking a dependent workload. Visibility that leads directly to action is the gap most tools leave open.

Keeping AI Adoption from Outrunning Security Oversight

NHI10, human use of NHI, is the category that agentic AI makes significantly harder to manage. As teams deploy AI agents quickly, shadow AI becomes a real operational risk: agents running with no inventory record, no behavioral baseline, and no named owner. HiBob faced a version of this directly. AI adoption across the business was accelerating faster than the security team could track it, and the question was not whether to stop it, but how to govern it without becoming the reason it slows down.

"Token Security gives us visibility we simply didn't have before. We can now automatically identify and control custom GPT agents running in our environment and ensure the required security level. Knowing that no AI agent is operating beyond our oversight means we can confidently accelerate our AI adoption, allowing our business to quickly evolve, which is a game-changer for both our security and growth." — Tamir Ronen, Global CISO at HiBob

This is the version of the OWASP NHI problem that most organizations are now facing. The framework was written for service accounts and API keys. The same risks apply, often at greater velocity, to AI agents. An agent with unconstrained access and no behavioral baseline is NHI5, NHI7, and NHI10 simultaneously. Governing it starts with knowing it exists.

Why Non-Human Identities Require a New Security Model

The OWASP NHI Top 10 is not a list of theoretical risks. Every category in the framework matches a named breach in the last 24 months, and every breach traces back to controls designed for humans being asked to govern machines. The fix is not better human IAM. It is identity infrastructure built for machines from the ground up: continuous discovery, behavioral baselines per identity, blast-radius-aware enforcement, and lifecycle governance that operates at the speed NHIs are created and retired.

Agentic AI is making the gap wider, not narrower. Every AI agent deployed adds new non-human identities, new integration points, and new shadow AI footprint outside any inventory. Organizations that treat the OWASP NHI Top 10 as their baseline are the ones positioned to absorb that growth without each new agent becoming each next breach.