TL;DR: GitGuardian says OWASP’s 2025 Non-Human Identity Top 10 formalises machine-identity risks such as secret leakage, improper offboarding, overprivileged NHIs, and insecure authentication at a time when NHIs can outnumber humans 100:1. The practical shift is that discovery, lifecycle control, and least privilege have to move into DevSecOps workflows because human-centric IAM assumptions no longer fit machine identities.
At a glance
What this is: This is GitGuardian’s analysis of OWASP’s 2025 NHI Top 10, which spotlights the main machine-identity risks enterprises now need to govern more deliberately.
Why it matters: It matters because IAM, PAM, and DevSecOps teams now have to treat non-human identities as a first-class governance domain, not a side effect of application delivery.
By the numbers:
- NHIs can outnumber humans 100:1 in modern enterprises.
👉 Read GitGuardian's analysis of the OWASP NHI Top 10 for machine identity risk
Context
Non-human identities are machine identities that authenticate and act inside systems without a human in the loop. GitGuardian argues that the enterprise problem is no longer visibility alone, but the mismatch between machine identity scale and IAM models built around people.
OWASP’s 2025 NHI Top 10 is presented as a dedicated risk model for secret leakage, offboarding, overprivilege, insecure authentication, and related lifecycle failures. The core governance question is how teams assign ownership, review access, and revoke machine credentials fast enough to match delivery speed.
The article also notes that shadow IT and third-party integrations widen the issue because machine identities are created across teams, pipelines, and vendors. That makes the starting position typical rather than exceptional for modern enterprises.
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 long-lived secrets create more risk for machine identities?
A: Long-lived secrets turn a one-time exposure into persistent access. If a token or key stays valid for months, an attacker can reuse it quietly, often without triggering human-centric controls. That is why rotation alone is not enough unless revocation, ownership, and validation are automated.
Q: How do security teams know if NHI governance is actually working?
A: A working NHI programme shows clear ownership, short-lived credentials, frequent revocation, and low numbers of dormant or shared machine accounts. Teams should be able to trace every high-risk nonhuman identity to a business purpose, a runtime policy, and a retirement path. If they cannot, governance is fragmented.
Q: How should teams embed NHI controls into DevSecOps without slowing delivery?
A: Place discovery, secret scanning, ownership checks, and privilege review at the points where code, configuration, and pipelines already change. That keeps the control close to creation and reduces the chance that machine identities escape into production without oversight. The aim is continuous governance, not after-the-fact cleanup.
Technical breakdown
Why OWASP split NHI risk from traditional application security
Traditional OWASP lists focus on human-centred authentication flows, sessions, and application abuse paths. NHI risk is different because service accounts, API keys, tokens, and certificates act continuously, often outside an interactive session and without the same review cadence. That means misuse can persist long after the original owner has moved on. The main technical shift is from session protection to lifecycle and scope control across machine identities. Practical implication: treat machine identity governance as a distinct control plane, not as a subset of user IAM.
Practical implication: separate machine identity inventory, credential control, and access review from human account processes.
How secret leakage becomes a machine identity compromise path
An NHI credential is often the identity itself: if the secret leaks, the identity leaks with it. Hardcoded API keys, plaintext tokens, and exposed certificates create a direct path from code or configuration to authenticated access, especially when secrets are long-lived and widely reused. Once a credential is discovered, attackers can authenticate as the workload that owns it and often inherit whatever permissions that workload already has. Practical implication: secret scanning must be tied to revocation, not just detection, because exposure without invalidation leaves the identity usable.
Practical implication: pair secret detection with rapid revocation and rotation workflows.
Why offboarding and least privilege fail together in NHI estates
Improper offboarding leaves machine identities running after the service, integration, or owner has changed. Overprivilege then turns those forgotten identities into high-value access paths because the credential still works and the permissions were never narrowed. The article’s point is that enterprises usually apply more lifecycle discipline to human accounts than to service accounts or API keys, even though machine identities can touch production data continuously. Practical implication: ownership, expiry, and entitlement scope have to be managed as one governance problem.
Practical implication: link machine identity ownership to entitlement review and decommissioning triggers.
Threat narrative
Attacker objective: The attacker aims to turn a leaked or forgotten machine credential into durable authenticated access that can expose data or control downstream systems.
- Entry occurs when an attacker finds a leaked API key, token, or certificate in code, logs, or configuration files.
- Credential access succeeds because the leaked secret still authenticates the machine identity and may carry broad permissions.
- Impact follows when the attacker uses that standing access to read data, call services, or pivot through connected systems.
Breaches seen in the wild
- Coupang Signing Key Breach: Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.
- Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
NHI governance failed because enterprises treated machine identities as implementation details rather than governed identities. The article shows that the problem is not only the number of NHIs, but the absence of clear ownership, lifecycle ownership, and entitlement discipline. Once a service account or API key is treated as disposable infrastructure, no one owns revocation, review, or retirement. The implication is that NHI governance has to become a named operating model, not an exception process.
OWASP’s NHI Top 10 matters because it turns machine-identity risk into a shared language for security, engineering, and compliance. That matters when teams need to align on secret leakage, offboarding, overprivilege, and authentication failures without collapsing them into generic access-control language. A common taxonomy makes it easier to assign controls, measure drift, and explain risk across programmes. The practitioner takeaway is that governance becomes easier once the failure modes are explicitly named.
Identity blast radius: the article highlights that the real cost of overprivileged NHIs is not just misuse, but the size of the downstream trust zone that one credential can reach. A machine identity with broad access can traverse services, environments, and data sets faster than many human access reviews can react. That shifts the control objective from asking whether access exists to asking how far one credential can move. The practitioner conclusion is to govern machine privileges by reachable impact, not by entitlement count alone.
Human-centric IAM controls do not map cleanly onto machine identities because the review window is wrong. Humans can be recertified on a schedule, but NHIs can be created, used, and forgotten inside delivery workflows that outpace periodic review. That means the governance model must follow the credential lifecycle, not the calendar. The implication for practitioners is that automation must be built around issuance, scope, and retirement, not just periodic attestation.
The NHI Top 10 is effectively a signal that DevSecOps now owns more of identity governance than most organisations have admitted. The article connects detection, enforcement, and lifecycle control directly to pipeline and code workflows, which means identity security is no longer only an IAM team function. This widens accountability across engineering and security operations. Practitioners should interpret that as a mandate to embed machine-identity controls where code and configuration are created.
From our research library:
- Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
- Read next: Ultimate Guide to NHIs
What this signals
Identity blast radius: once a machine credential is exposed, the practical question is no longer whether the secret exists, but how far that identity can move before it is invalidated. Teams should assume that overprivileged NHIs convert a single leak into multi-system exposure unless scope is constrained at issuance.
Machine identity governance now has to sit inside engineering workflows because periodic reviews alone cannot keep pace with the rate at which NHIs are created and retired. For most programmes, the next maturity step is not another policy document, but tighter linkage between discovery, offboarding, and privilege enforcement.
The NHI Top 10 gives practitioners a common risk vocabulary that can be used across IAM, PAM, and DevSecOps discussions. That matters because machine identity failures are usually distributed across teams, yet the control failure is collective.
For practitioners
- Inventory every machine identity and its owner Build a current register of service accounts, API keys, tokens, and certificates, then assign a named business and technical owner to each one.
- Tie secret detection to immediate revocation Treat every exposed credential as an active identity event by revoking, rotating, or disabling the secret as soon as it is found.
- Enforce least privilege at issuance time Scope each new machine identity to the minimum permissions it needs, then review any broad access before the credential enters production.
- Set explicit offboarding triggers for machine identities Decommission credentials when services are retired, vendors change, or pipelines are replaced so old identities do not linger as zombie access.
- Map NHI controls into DevSecOps workflows Place discovery, secret scanning, and lifecycle checks inside build and deployment pipelines so machine identity risk is caught where it is created.
Key takeaways
- Machine identities behave like governed credentials, not like ordinary application artefacts, so ownership and lifecycle must be explicit.
- The main risks in the NHI Top 10 are not theoretical categories but concrete failure modes such as secret leakage, overprivilege, and improper offboarding.
- The strongest control response is to inventory NHIs, shorten secret lifetime, and move revocation and scope checks into delivery workflows.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centres on leaked machine credentials and the resulting exposure path. |
| NHI-01 — Improper Offboarding | Improper offboarding is one of the article's core NHI Top 10 risks and a repeated governance failure. | |
| NHI-05 — Overprivileged NHI | The article explicitly warns that excess permissions expand the blast radius of a compromised NHI. | |
| Recommendation — Scan for exposed machine secrets and revoke any credential that appears in code, logs, or repositories. Retire machine identities when services, vendors, or pipelines are decommissioned. Limit each machine identity to the minimum permissions needed for its current task. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential lifecycle and rotation are central to the article's NHI governance argument. |
| Recommendation — Apply authenticator management to rotate, revoke, and age-limit machine credentials. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Least privilege and entitlement scope are central to the article's governance model. |
| Recommendation — Review and right-size machine identity permissions before they reach production. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article's threat pattern is leaked credential abuse followed by access expansion. |
| Recommendation — Map leaked machine credentials to credential-access and lateral-movement hunting priorities. | ||
Key terms
- Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
- Secrets Leakage: Secrets leakage is the exposure of credentials such as API keys, tokens, or certificates in places where they can be discovered and reused. The risk is not just disclosure, but unauthorized authentication that turns a coding or pipeline mistake into active access.
- Offboarding: Offboarding is the controlled retirement of a workload, service account, token, certificate, or other non-human identity when it is no longer needed. It includes revoking credentials, removing permissions, and verifying that no residual trust path remains available to attackers.
- Overprivileged Nhi: An overprivileged NHI is a service account, token, key, or other machine identity that has been granted more access than it needs to do its job. The risk is not theoretical. Excess scope increases blast radius, makes compromise more valuable to attackers, and slows containment when the identity is abused.
What's in the full article
GitGuardian's full article covers the operational detail this post intentionally leaves for the source:
- The full OWASP NHI Top 10 breakdown, including the ten risk categories and how each one maps to machine identity governance.
- Examples of how GitGuardian positions discovery, secret analysis, and lifecycle visibility across real development workflows.
- The article's discussion of how NHI risks differ from traditional OWASP application security assumptions.
- The FAQ section's practical guidance on integrating NHI controls into DevSecOps pipelines.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 1, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org