OWASP NHI Top 10 shows why NHI governance lags behind access risk

At a glance

What this is: OWASP’s first NHI Top 10 frames non-human identity risk around ten recurring failure patterns, led by offboarding gaps, leaked secrets, overprivilege, and weak authentication.

Why it matters: IAM teams need to treat NHIs as governed identities rather than static credentials because the same access models used for people do not contain workload, service account, and API key exposure.

By the numbers:

• Research from Entro Security puts the ratio at 144 non-human identities for every human user.
• GitGuardian’s 2026 report on secrets sprawl found that nearly 29 million new hardcoded secrets were exposed on public GitHub in 2025 alone.
• 64% of secrets exposed as far back as 2022 remained valid in early 2026.
• 53% of organisations grant privileged access to more than 10% of their cloud roles.

👉 Read Aembit’s analysis of the OWASP NHI Top 10 and its breach patterns

Context

Non-human identity governance is the discipline of controlling access for workloads, service accounts, API keys, tokens, certificates, and AI agents as identities, not as disposable configuration. The article’s central point is that security programmes still over-optimise for human authentication while NHIs often persist without expiry, review, or clear accountability.

That mismatch creates a structural governance gap across cloud, CI/CD, SaaS integrations, and emerging agentic systems. The article shows the same pattern repeating in different forms: credentials live too long, are over-scoped, or remain active after ownership changes, which makes NHI hygiene a core IAM problem rather than a niche operational issue.

Key questions

Q: What breaks when non-human identities are left with static credentials?

A: Static NHI credentials break the assumption that access can be reviewed before it is abused. If a token or API key never expires, an attacker only needs one exposure event to gain usable access. That is why secret sprawl and poor lifecycle control turn routine leaks into persistent compromise.

Q: Why do service accounts with standing privilege increase lateral movement risk?

A: Standing privilege expands the blast radius of one compromised identity. When a service account can read, write, or administer more systems than it needs, attackers inherit that scope immediately. The risk is highest in cloud and SaaS environments where privileges are often broad and inconsistently reviewed.

Q: How should security teams handle third-party NHI access offboarding?

A: Treat third-party NHI access as a lifecycle event with an owner, expiry condition, and revocation test. If the business relationship changes, the credential should not remain valid by default. The offboarding process must remove access from OAuth apps, service accounts, and integration tokens together.

Q: What do teams get wrong about least privilege for NHIs?

A: They often apply least privilege at creation time and assume it stays valid. In practice, workload scope changes, integrations expand, and service accounts accumulate permissions over time. Least privilege for NHIs has to be revisited as a living control, not a one-time setup step.

Technical breakdown

Why long-lived secrets become the default failure mode

Static secrets are attractive because they are easy to provision and hard to notice, but that convenience creates a durable attack surface. An API key or token often has no native user interaction, no MFA challenge, and no meaningful expiry unless the organisation adds one. That means compromise can remain invisible until the secret is found in a repository, log, image layer, or vendor integration. Once exposed, the credential behaves like a permanent access pass rather than a bounded entitlement. In NHI governance terms, the failure is not just leakage. It is persistence without lifecycle control.

Practical implication: move service credentials to short-lived, identity-bound access paths and track where static secrets still exist.

Overprivileged NHIs and blast-radius expansion

Overprivilege is what turns a single NHI compromise into a multi-system event. If a service account can read, write, or administer resources beyond its function, the attacker inherits that excess scope immediately. Because NHIs often support automation, teams tend to grant broad permissions to avoid breaking workflows, then never right-size them. The result is a mismatch between operational convenience and security intent. The article’s examples show that scope creep is not theoretical. It is the mechanism that converts a leaked or stolen credential into lateral movement and data exposure.

Practical implication: right-size permissions per application and review which accounts still carry broad cloud or SaaS access.

Third-party NHI access needs explicit lifecycle control

External integrations are a governance problem because the organisation rarely controls the full credential lifecycle. Third-party service accounts and OAuth connections can remain active after vendor changes, internal ownership changes, or security incidents elsewhere in the chain. That means access can outlive the relationship that justified it. In practice, many teams can name the application but not the human owner, expiry condition, or revocation trigger. This is why third-party NHI governance needs more than inventory. It needs lifecycle visibility, scoped trust, and a revocation model that matches business reality.

Practical implication: tie each third-party NHI to an owner, an expiry condition, and a tested offboarding workflow.

Threat narrative

Attacker objective: The attacker aims to turn a single exposed non-human credential into durable access across cloud, SaaS, or internal systems.

1. Entry occurs when attackers find an exposed NHI credential, such as a leaked API key, token, or service account secret in a repository or integration path.
2. Credential abuse follows when the static secret is used directly because it has no MFA prompt, no user challenge, and no meaningful expiry.
3. Impact comes when the compromised NHI grants overbroad access, allowing data theft, internal movement, or misuse of connected systems.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.

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

NHI Mgmt Group analysis

OWASP’s NHI Top 10 is a governance map, not just a risk list. The strongest value of the document is that it translates recurring NHI failures into repeatable control failures that IAM teams can actually govern. Offboarding, secret leakage, overprivilege, and identity reuse are not isolated hygiene issues. They are the same lifecycle problem showing up in different places, which is why NHI controls have to be managed as a programme, not an inventory exercise.

Long-lived secret persistence is the named failure mode that explains most NHI incidents. Static credentials were designed for systems where access could be treated as durable and reviewed later. That assumption fails when the credential itself is the attacker’s entry point and remains valid for months or years. The implication is that many NHI controls are built around the wrong premise: they expect credentials to behave like governed access grants when they actually behave like unattended bearer tokens.

Overprivileged service accounts create identity blast radius, not just excess access. The problem is not simply that permissions are too broad. It is that one compromised NHI can inherit enough authority to expose adjacent systems, automate abuse, or cross boundaries that human identity programmes normally constrain. That makes least privilege an operational design problem for service accounts, not just a policy statement.

Third-party NHI trust debt is now a category-level risk. Once an external credential is issued, organisations often lose sight of when it should be revoked, who owns it, and whether it still matches the business relationship. That is a lifecycle governance failure, not a tooling gap. Practitioners should treat every third-party NHI as a time-bounded trust relationship that decays unless actively governed.

OWASP NHI Top 10 and OWASP Agentic AI Top 10 are converging on the same control plane. The article’s cross-mapping to agentic risk signals that NHI governance is becoming the common substrate for cloud automation and AI-driven execution. That means IAM teams should stop separating workload identity, secret hygiene, and agent governance into disconnected initiatives. The practitioner conclusion is simple: one identity governance model now has to cover services, integrations, and autonomous runtimes together.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, according to The State of Non-Human Identity Security.
• From our research: 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, including 38% with no or low visibility and 47% with only partial visibility, according to The State of Non-Human Identity Security.
• That visibility gap is why practitioners should also review the Ultimate Guide to NHIs for lifecycle and governance patterns that reduce standing access.

What this signals

Credential persistence is becoming the defining NHI governance problem. The article points to a pattern security teams cannot ignore: the longer a secret remains valid, the more likely it is to be reused outside the intent of the original workflow. In practical terms, this means offboarding and rotation are no longer hygiene tasks. They are the controls that determine whether an exposed credential becomes a lasting control failure.

Service account governance now sits at the intersection of cloud security and identity governance. Teams that still treat machine access as a back-end operations issue will continue to miss where privilege accumulates. The right response is to tie NHI ownership, expiry, and scope to the same governance model used for human entitlements, then validate it against NIST Cybersecurity Framework 2.0 and 52 NHI Breaches Analysis.

Trust debt in third-party integrations is now a measurable programme risk. Once OAuth apps, vendor service accounts, and shared secrets proliferate, teams lose the ability to prove what should still be active. That is the signal to build a named control around lifecycle review, not just inventory, because unmanaged integrations create hidden paths into production.

For practitioners

• Inventory every standing NHI credential path Map API keys, tokens, certificates, service accounts, and OAuth app credentials to their owning system, business purpose, and expiry condition. Prioritise anything that still authenticates without a rotation record or explicit offboarding trigger.
• Replace static secrets with short-lived identity flows Use workload identity federation or equivalent identity-based authentication where possible so credentials are issued for the session, not stored indefinitely in code or pipelines. Reserve static secrets for exceptions that have a documented review date.
• Right-size permissions by application, not by team habit Review service accounts and automation roles for privileges that exceed the minimum required function. Remove broad cloud, SaaS, and database access that exists only because the credential was created for convenience.
• Test third-party offboarding before an incident does it for you Build a revocation checklist for vendor integrations, OAuth apps, and shared service accounts, then validate that a changed business relationship actually removes access. The key control is whether removal happens when the need ends, not when an incident forces the issue.

Key takeaways

• The article shows that the core NHI problem is not isolated leakage but credential persistence combined with weak lifecycle control.
• The evidence is broad enough to matter operationally, with public secret exposure, standing privilege, and missed rotation repeatedly turning into real compromise paths.
• Practitioners should treat offboarding, rotation, and privilege right-sizing as the controls that determine whether an NHI becomes a temporary tool or a permanent attack surface.

Key terms

• Non-Human Identity: An identity used by software rather than a person, including service accounts, API keys, tokens, certificates, and workload identities. In governance terms, it should be managed as an account with ownership, scope, expiry, and review requirements, not as a static configuration artifact.
• Standing Privilege: Access that remains continuously available instead of being issued only when needed. For NHIs, standing privilege is especially risky because it can persist without MFA, user presence, or a natural offboarding moment, which makes compromise easier to reuse across systems.
• Secret Sprawl: The uncontrolled spread of credentials across code repositories, logs, pipelines, images, and integrations. For NHI programmes, secret sprawl matters because every copy becomes a separate exposure point, and each exposed copy extends the time an attacker can use the same access path.
• Lifecycle Governance: The control discipline that tracks identity creation, use, review, rotation, and removal from start to finish. For NHIs, lifecycle governance is the difference between an identity that is actively managed and one that survives long after the workload or vendor relationship that created it.

Deepen your knowledge

OWASP NHI Top 10 risk patterns and lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building an identity programme that still relies on static secrets and broad service access, it is worth exploring.

This post draws on content published by Aembit: OWASP NHI Top 10 breakdown and governance implications. Read the original.