OWASP NHI Top 10 exposes where machine identity controls fail

At a glance

What this is: This is a practitioner analysis of OWASP's NHI Top 10 and the control failures that make non-human identities easy to abuse.

Why it matters: It matters because NHI sprawl affects IAM, PAM, secrets, and lifecycle governance at the same time, so gaps in one control plane quickly widen the blast radius in another.

By the numbers:

• Non-human identities often outnumber human users by roughly 17:1 in typical organizations.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.

👉 Read Cerbos's guide to the OWASP NHI Top 10 and machine identity risk

Context

Non-human identities are software identities such as service accounts, API keys, tokens, certificates, and workload identities that authorize applications and automated systems to access secured resources. In practice, they are the access layer that keeps cloud-native services, CI/CD, and distributed microservices functioning, and they now outnumber human identities in many environments.

The governance problem is that most security programmes still treat these identities as implementation detail rather than first-class subjects of IAM, PAM, and lifecycle control. That leaves secret leakage, orphaned credentials, and overprivileged service access as predictable failure modes, especially where authentication and authorization are managed separately.

The OWASP Non-Human Identity Top 10 is useful because it forces the issue into a control conversation rather than a tooling conversation. The central question is not whether machine identities are necessary, but whether organisations can inventory them, constrain them, and retire them fast enough to prevent routine compromise.

Key questions

Q: What breaks when non-human identities are not offboarded properly?

A: Orphaned NHIs remain valid long after the workload or integration they served is gone, which gives attackers a durable access path. The failure is not just administrative drift. It is living authentication that no longer has a legitimate owner, so compromise can happen through forgotten keys, tokens, or service accounts.

Q: Why do non-human identities create so much more risk than teams expect?

A: Because they multiply faster than human accounts and are often granted broad permissions to keep automation working. That combination makes them attractive to attackers, especially when secrets are long-lived or reused across systems. The result is a much larger attack surface than most IAM programmes account for.

Q: How do security teams know whether NHI governance is actually working?

A: Look for evidence that identities are inventoried, scoped, rotated, and revoked on time, then verify that access decisions are denied outside intended context. If secrets remain valid after exposure, or service accounts persist after retirement, the programme is signalling control failure rather than control maturity.

Q: Who should own machine identity risk when IAM, PAM, and secrets management overlap?

A: Ownership should sit with the identity programme, not with a single platform team. Machine identity risk crosses lifecycle, authorization, and secret management, so accountability has to span the teams that issue access, govern privileges, and retire credentials. Otherwise, the gaps between them become the attack path.

Technical breakdown

Why NHI inventory and offboarding are the first control problem

Non-human identity governance begins with discovery because you cannot protect what you cannot enumerate. Service accounts, API keys, and tokens often exist outside human joiner-mover-leaver processes, which means they can survive long after the workload, integration, or engineer that created them has changed. In distributed environments, that creates orphaned access: credentials that remain technically valid but operationally unowned. The real technical risk is not just exposure, but persistence. A forgotten identity can still authenticate, still authorize, and still move laterally unless its access is explicitly revoked across the systems that trust it.

Practical implication: build an authoritative inventory of non-human identities and tie decommissioning to revocation, not just documentation.

Secret leakage turns any exposed token into a live identity

Secret leakage happens when credentials escape their intended secure store and appear in source code, logs, chat, config files, or developer tooling. Once that happens, the secret is not a theoretical exposure, it is a live authentication path if the backend still accepts it. This is why long-lived secrets are so dangerous: the attacker does not need to break authentication, only to find an already-valid credential. The important technical distinction is that leakage is an origin event, while abuse is a downstream identity event. Controls like scanning help find exposure, but the real defence is short-lived credentials, rapid revocation, and constrained authorization.

Practical implication: treat secret scanning as detection only and pair it with automated rotation and revocation workflows.

Overprivileged NHIs widen blast radius across cloud and microservices

When a machine identity has more access than the workload actually needs, compromise becomes a permissions problem instead of a perimeter problem. In cloud-native systems, overprivilege is common because teams start with broad access to make integrations work, then never reduce it. The result is that a token intended for a narrow service action can become a path to data stores, deployment systems, or administrative APIs. Fine-grained authorization narrows that path by evaluating every request against policy rather than assuming the credential's possession is sufficient. That separation between identity possession and action permission is the core control boundary.

Practical implication: review every service account against actual runtime actions and remove any privilege that is not directly required.

Threat narrative

Attacker objective: The attacker wants a valid machine identity that can be used to move laterally, access sensitive systems, and persist without having to defeat human authentication directly.

1. Entry occurs when attackers locate an exposed NHI credential in code, logs, chat, or a third-party integration.
2. Escalation follows when the valid secret or token is reused to impersonate the workload and access systems beyond the original intended scope.
3. Impact occurs when the compromised identity is used for lateral movement, data access, or abuse of production resources, often without triggering human-authentication controls.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

NHI sprawl is a governance failure before it is a security failure. When machine identities outnumber humans, the problem is no longer isolated access management, it is programme design. The OWASP NHI Top 10 correctly treats these identities as a distinct control surface, because lifecycle, secrets, PAM, and authorization all fail differently once workloads hold credentials at scale. Practitioners should stop treating NHIs as exceptions and govern them as a core identity population.

Secret leakage is a blast-radius problem, not just a detection problem. A leaked token is only useful to attackers when the surrounding controls still accept it, and that is why 64% of valid secrets leaked in 2022 remaining live today matters. Detection without revocation simply shortens time-to-notice, not time-to-abuse. The implication is that security teams must measure exposure by residual validity, not by the existence of a finding.

Long-lived machine credentials create trust debt that compounds over time. Every day a secret remains valid increases the number of places it can be copied, cached, forwarded, or reused. That is why the strongest control pattern is not secret preservation but secret minimisation, with short-lived credentials and tight authorization around each use. Practitioners should treat every long-lived secret as deferred incident response.

Fine-grained authorization is what limits the damage after authentication fails. Authentication proves possession, but it does not prove that the identity should be able to do the requested action in that moment. Policy-as-code and contextual authorization matter because they keep a valid credential from becoming unrestricted access. In other words, least privilege only works if it is enforced at request time, not assumed at issuance time.

Machine identity governance has to converge with human IAM and PAM. The same organisation that enforces review, scoping, and emergency access on human accounts often leaves service identities to ad hoc ownership. That split is why NHI risk keeps accumulating outside standard IAM reporting. The field needs one governance model for all identity types, with control depth adapted to the actor, not the label. Practitioners should align NHI control ownership with the same discipline used for privileged human access.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• For deeper control mapping, read 52 NHI Breaches Analysis for the recurring breach patterns that follow secret exposure and privilege abuse.

What this signals

Ephemeral credentials are becoming the baseline expectation, not a specialist control. When leaked secrets remain valid for long periods, the real metric is not how many exposures you find but how quickly you can make them useless. That shifts programme design toward rotation, revocation, and identity-bound access rather than static secret storage.

The governance gap will widen wherever teams still separate NHI ownership from human IAM and privileged access oversight. A machine account that can survive a team change or a pipeline rebuild is not merely an operational artifact, it is an ungoverned identity. That is why lifecycle control has to become a reporting metric, not an afterthought.

Secret sprawl creates identity blast radius. As leaked credentials multiply across code, chat, and deployment systems, the key question becomes which identities can still act after exposure. Organisations should use that as a trigger to align secrets management with the controls in the OWASP Non-Human Identity Top 10 and with runtime authorization policy.

For practitioners

• Build a complete NHI inventory Map service accounts, API keys, tokens, certificates, and workload identities to the workloads and owners that depend on them. Reconcile the inventory with cloud IAM, secret stores, CI/CD, and application telemetry so orphaned identities are visible before they are abused.
• Shorten credential lifetime everywhere possible Replace long-lived secrets with short-lived tokens and workload-bound credentials such as OIDC-based federation or SPIFFE IDs where the platform supports them. Set rotation and expiry policies so a leaked credential has a narrow usable window.
• Tighten request-time authorization for machine identities Apply policy-as-code so every NHI request is checked against action, resource, and context rather than identity possession alone. Make the policy deny by default and explicitly allow only the runtime actions the workload needs.
• Separate human and service usage paths Prohibit human operators from logging in with NHI credentials and route elevated human access through proper privileged access workflows instead. This keeps audit trails meaningful and prevents machine secrets from becoming an informal admin backdoor.
• Tie offboarding to revocation evidence When a service is retired, a vendor relationship changes, or an integration is replaced, require proof that the credential was revoked across all trust points. Do not consider an NHI offboarded until the token, secret, and authorization path are all removed.

Key takeaways

• Non-human identity risk is mainly a governance problem until it becomes a breach problem.
• The scale of secret leakage means residual validity matters more than discovery speed.
• Practitioners should pair inventory, short-lived credentials, and request-time authorization to shrink blast radius.

Key terms

• Non-Human Identity: A non-human identity is a digital identity used by software rather than a person. It can be a service account, token, API key, certificate, bot, or workload identity. These identities authenticate systems and automate access, so they need lifecycle, authorization, and secret controls just like human accounts.
• Secret Leakage: Secret leakage is the accidental exposure of credentials outside their intended secure store. It commonly occurs in code, logs, tickets, chat, or deployment tooling. Once a secret is exposed, the risk becomes immediate if it is still valid, because the attacker can impersonate the workload without breaking authentication.
• Orphaned Identity: An orphaned identity is a non-human account or credential that still exists after the workload, vendor, or integration that used it has changed or disappeared. Orphans are dangerous because they often remain valid, poorly owned, and forgotten by standard review processes, creating long-lived unauthorized access paths.
• Blast Radius: Blast radius is the amount of damage an identity can cause if it is misused or compromised. In NHI security, it is shaped by privilege scope, token lifetime, and the number of systems that trust the credential. Smaller blast radius means fewer actions remain available after exposure.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Cerbos: a guide to the OWASP NHI Top 10 and practical ways to manage non-human identity risk. Read the original.