OWASP NHI risks expose gaps in machine identity governance

At a glance

What this is: This is an analysis of the OWASP Top 10 Non-Human Identity Risks for 2025, focused on how orphaned service accounts, leaked secrets, overprivilege and human misuse keep machine identity exposure elevated.

Why it matters: It matters because IAM, PAM and NHI programmes have to govern machine identities as a distinct access class, or the same control gaps will keep reappearing in cloud, CI/CD and third-party integrations.

👉 Read Akeyless' analysis of OWASP NHI risks and machine identity governance

Context

Non-human identity governance is the discipline of controlling access for service accounts, API keys, tokens, certificates and automation credentials. In this article, the underlying problem is not that organisations lack security tools, but that they still manage machine identities as if they were static extensions of human accounts.

Akeyless uses the OWASP Top 10 Non-Human Identity Risks for 2025 to frame the main failure modes: orphaned identities, secret leakage, weak authentication, overprivilege, environment sprawl and human misuse of machine credentials. That combination shows why NHI controls need lifecycle, not just storage, and why cloud automation increases the consequences of weak governance.

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 leaked secrets and reused service accounts create so much risk?

A: A leaked secret is an active credential, not just evidence of exposure, and reused service accounts can open multiple applications or environments at once. The risk grows because one compromise can turn into repeated access until every dependent system is cleaned up. That is why lifecycle control matters as much as storage control.

Q: How should security teams separate machine identities across environments?

A: Give each environment and each application its own identity, policy and secret set so a compromise in development cannot automatically reach production. Shared credentials defeat isolation, make least privilege vague, and widen the blast radius of any incident. The safest pattern is unique access for each workload boundary.

Q: When does human use of service accounts become an accountability problem?

A: It becomes an accountability problem the moment a person uses a machine credential for manual work, because actions are no longer cleanly tied to an individual identity. That breaks traceability during investigations and weakens approval and review processes. Human access and machine access need separate paths.

Technical breakdown

Why orphaned machine identities stay exploitable

Improper offboarding is a governance failure, not just an admin miss. Service accounts and access keys created for temporary projects often outlive the work they were meant to support, which means the credential remains a valid entry point even after the business need has disappeared. In NHI terms, the problem is that lifecycle state and access state drift apart. Once that happens, the identity becomes an unowned capability sitting inside production systems, waiting for reuse or abuse. Practical implication: lifecycle ownership must be tied to every non-human identity at creation, not after discovery.

Practical implication: bind service account ownership and expiry to the project or workload that created the identity.

How leaked secrets become persistent access paths

Secret leakage is dangerous because a copied API key is not a log event or a transient exposure, but an operational credential that can be replayed until it is revoked or rotated. Hardcoded secrets in repositories and deployment files create a second trust boundary outside the original system, which is why runtime injection and centralised secrets handling matter. The real weakness is not only disclosure, but the fact that many workflows still treat secrets as if their location, not their lifecycle, determines their security. Practical implication: treat code and CI/CD as secret exposure surfaces and remove credentials from static artefacts.

Practical implication: eliminate long-lived secrets from code, build files and pipeline variables.

Why shared credentials collapse blast radius control

Environment isolation and NHI reuse are closely linked. When the same credentials are reused across development, testing and production, or across multiple applications, compromise in one zone gives the attacker a route into others. That breaks blast-radius assumptions because the identity no longer maps to a single system, environment or risk boundary. Least privilege also becomes difficult to enforce when one credential is expected to serve multiple purposes. Practical implication: issue unique identities and unique access policies per environment and per application instance.

Practical implication: separate identities by environment and application to keep compromise from spreading laterally.

Threat narrative

Attacker objective: The attacker wants persistent unauthorised access to cloud services, sensitive data and production workflows through machine identities that were never properly governed.

1. Entry occurs when attackers obtain a leaked API key, a reused service account or an orphaned non-human identity that was never deactivated.
2. Credential abuse follows when that standing access is replayed against cloud services, CI/CD pipelines or shared development environments.
3. Escalation happens when overprivileged or reused machine identities allow access to additional systems, data stores or production workloads.
4. Impact is broader breach scope, because the same credential pattern can expose multiple applications, environments and operational services at once.

Breaches seen in the wild

• Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.
• Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.

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

Machine identity governance fails when organisations treat non-human identities as temporary implementation details. The article shows the opposite: service accounts, API keys and automation credentials are now production access paths, not incidental plumbing. Once those identities outlive the project, they become unmanaged trust anchors. Practitioners need to stop assuming machine access is low-risk simply because no person is typing the password.

Ephemeral credential trust debt is the hidden liability in cloud automation. The more teams rely on shared secrets, reused accounts and static configuration files, the more they accumulate access that is easy to deploy and hard to retire. That debt shows up as orphaned NHIs, secret leakage and environment bleed. The practical conclusion is that governance must measure how much access can survive without a current business owner.

Human use of NHIs is a governance failure, not a convenience pattern. When administrators use service account credentials for manual tasks, accountability breaks and incident response loses traceability. That creates a mixed control problem across IAM, PAM and NHI governance because the same credential is serving both machine and human purposes. The practitioner conclusion is simple: if a credential can be used by a person, it is no longer governed as a machine identity.

OWASP NHI risks expose the gap between identity inventory and identity control. Many organisations can list machine identities, but cannot prove which ones are valid, isolated, rotated or genuinely assigned to a current workload. The article reinforces that inventory alone does not equal governance. Practitioners should read this as a signal to re-evaluate lifecycle ownership, rotation discipline and environment separation together.

The NHI control model now has to cover trust boundaries that used to be assumed away. Third-party plugins, CI/CD secrets, overprivileged service accounts and shared environment credentials all extend the attack surface beyond a single system boundary. The governing question is no longer whether a secret exists, but whether it can be reused outside the context for which it was issued. Practitioners should align controls to that narrower trust model.

From our research library:

• NHIs outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs.
• 68% of organisations do not know how to fully address NHI risks, according to the Ultimate Guide to NHIs.
• Read next: Service Account Security Guide

What this signals

Ephemeral credential trust debt: cloud automation often creates credentials faster than teams can retire them, which turns lifecycle lag into a permanent governance liability. The immediate programme question is whether ownership, revocation and expiry are enforced at issuance time or deferred until discovery.

Machine identity programmes should be evaluated on their ability to prevent credential reuse across workloads and environments, not on how many secrets are stored in a vault. Reuse turns a single compromise into a multi-system issue, so separation is a control objective, not an implementation detail.

For practitioners

• Map every service account to a named owner and expiry rule Require a business or platform owner for each machine identity, and tie deactivation to project closure, workload retirement or vendor offboarding.
• Remove secrets from static code and configuration files Move API keys and tokens out of repositories, build files and deployment configs, then inject them at runtime from governed secrets storage.
• Separate identities by environment and application Issue distinct credentials and policies for development, testing and production, and avoid any shared service account across applications.
• Prevent human use of machine credentials Block administrators from using service account secrets for manual tasks and route human access through enterprise authentication and PAM controls.
• Rotate long-lived secrets on a fixed schedule Set mandatory expiry for API keys, tokens and certificates, and revoke credentials that cannot be tied to an active owner or workload.

Key takeaways

• The article frames NHI risk as a governance problem centred on service accounts, secrets and automation credentials that remain active beyond their intended use.
• The main exposure pattern is standing access, shared credentials and weak separation across environments or applications, which can widen the impact of a single compromise.
• Practitioners need lifecycle ownership, runtime secret handling and strict identity separation if they want machine identity controls to hold up in cloud environments.

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.
• Machine Identity Governance: Machine Identity Governance is the discipline of controlling how non-human identities are created, used, monitored, and retired. It covers service accounts, API keys, certificates, tokens, workloads, and automation identities, with policies for ownership, lifecycle, least privilege, rotation, attestation, and auditability across cloud, application, and infrastructure environments.
• 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.
• Environment Isolation: Environment isolation is the practice of keeping development, test, and production access separated so compromise in one zone does not automatically reach another. For machine identities, weak isolation usually means the same credential or trust relationship can cross boundaries and enlarge the blast radius.

What's in the full article

Akeyless' full analysis covers the operational detail this post intentionally leaves for the source:

• The full OWASP NHI Top 10 breakdown across all ten risk categories and the examples used for each one
• A closer look at how Akeyless maps its secrets and machine identity platform to each NHI risk
• The article's scenario-level discussion of service accounts, API keys and environment isolation in a cloud workflow
• The concluding framing on why the NHI risk model matters for automated access governance

👉 Akeyless' full post expands the OWASP NHI Top 10 examples and governance context.

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.