OWASP NHI risks expose gaps in machine identity governance

At a glance

What this is: This article maps the OWASP Top 10 NHI Risks for 2025 to common machine identity failure modes, with the key finding that orphaned accounts, secret leakage, overprivilege, and reuse remain the most dangerous control gaps.

Why it matters: It matters because identity teams cannot treat NHIs as a side channel anymore, and the same governance disciplines used for human access now have to cover secrets, lifecycle, and privilege across automation.

👉 Read Akeyless's analysis of the OWASP Top 10 NHI Risks for 2025

Context

Non-human identity governance is the discipline that controls how service accounts, API keys, tokens, certificates, and automation credentials are created, used, rotated, and retired. In this article, the primary security issue is not tooling complexity but the persistence of identity weaknesses that allow NHIs to outlive the task they were created for.

The article uses the OWASP NHI risk lens to show how machine identity exposure usually starts with lifecycle mistakes, secret sprawl, or excessive privilege, then expands into broader account compromise and lateral movement. That is a typical enterprise pattern, not an edge case.

For IAM teams, the important point is that these are not separate categories of risk. They are interconnected control failures that demand one governance model across secrets, offboarding, environment separation, and human-to-machine access boundaries.

Key questions

Q: What breaks when service accounts are not offboarded after a project ends?

A: The identity remains valid long after the business need is gone, which leaves an orphaned entry point for attackers and a blind spot for audit teams. Offboarding failures turn temporary access into standing access, so revocation has to be tied to project closure, ownership, and expiry rather than manual cleanup alone.

Q: Why do reused machine identities increase breach impact?

A: Reuse makes one credential useful across multiple systems, so a single compromise can move from one workload to another without additional authentication barriers. That is why unique identities, environment separation, and workload-level ownership are essential when the same secret would otherwise unlock several applications.

Q: How do security teams know when secret sprawl is becoming unmanageable?

A: When they cannot confidently answer where each secret exists, which workloads depend on it, and how quickly it can be retired without breaking business services. If the answer requires manual archaeology across code, tickets, and pipelines, the sprawl is already beyond routine control.

Q: Who is accountable when administrators use service account credentials manually?

A: Both IAM and PAM teams need to own the boundary, because human actions taken through machine credentials break traceability. The right model is separate human authentication, separate machine authentication, and clear logging that preserves person-level accountability even when a service account is involved.

Technical breakdown

Improper offboarding creates orphaned non-human identities

When service accounts and access keys are not retired after a project ends, they become orphaned identities. These credentials often remain valid even when no one is watching them, which makes them ideal entry points for attackers. The technical problem is not just forgotten cleanup. It is the absence of enforced lifecycle expiry, revocation, and ownership tracking for identities that exist outside human HR processes.

Practical implication: tie NHI retirement to project closure and automate revocation so unused credentials cannot remain active indefinitely.

Secret leakage turns code repositories into credential stores

Hardcoded API keys and tokens create a direct bridge from source control to production access. Once secrets are embedded in code, every clone, fork, backup, and review path becomes part of the exposure surface. Runtime injection, centralised secret management, and zero-knowledge handling reduce that footprint, but only if the organisation stops treating repositories as a safe place to stage credentials.

Practical implication: block committed secrets at the point of creation and move all runtime credentials out of source code.

Overprivileged and reused NHIs widen blast radius

Service accounts that carry broad permissions, or that are reused across applications and environments, turn one compromise into many. Least privilege is not only about smaller permissions. It is also about identity uniqueness, environment separation, and limiting how far a single credential can travel. Without those controls, one NHI becomes a shared trust anchor for multiple systems.

Practical implication: segment identities by workload and environment, then remove shared credentials that can spread compromise.

Threat narrative

Attacker objective: The attacker aims to turn valid machine identity access into durable access, broader privilege, and operational control over sensitive systems.

1. Entry occurs when attackers find orphaned service accounts, leaked API keys, or reused credentials that still authenticate successfully.
2. Escalation follows when those NHIs carry more privilege than the workload needs, or when the same credential works across multiple environments and applications.
3. Impact is reached when the attacker uses the valid machine identity to steal data, modify systems, disrupt services, or move laterally inside the enterprise.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

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

NHI Mgmt Group analysis

Orphaned NHI ownership is the governance failure that turns temporary access into permanent exposure. The article's offboarding problem is not a housekeeping issue, it is a control failure in identity lifecycle management. When a service account survives the project that created it, the organisation has effectively allowed access to persist without a living owner. That is the exact condition attackers exploit, and it is why NHI governance must treat retirement as a control boundary, not an administrative task.

Secret sprawl creates an identity control plane problem, not just a leakage problem. Hardcoded keys in repositories, static credentials in pipelines, and reused tokens across environments collapse the separation between development, deployment, and production. Once secrets travel through code, the repository becomes part of the authentication system. Practitioners should read this as a signal that secret handling must be governed as identity infrastructure, not as a code hygiene issue.

Shared and overprivileged machine identities create identity blast radius. The article correctly shows that reuse and broad permissions make one compromise propagate across applications and environments. That is the same structural weakness seen in many NHI incidents: access is defined too broadly at provisioning time and then reused until it becomes inseparable from operations. The practical conclusion is that each workload should have its own identity boundary and its own revocation path.

Human misuse of NHIs exposes the accountability gap between people and machines. When administrators use service account credentials for manual tasks, incident response and audit trails lose the ability to assign actions to a person. That is a governance problem across IAM and PAM, not a niche NHI issue. The discipline here is clear separation of human and machine authentication paths so that accountability does not disappear when convenience increases.

Unique identity per workload is becoming the minimum viable assumption for NHI governance. Reuse across applications, environments, and teams is no longer defensible when the cost of compromise is lateral expansion. The issue is not simply excess access, it is identity indirection that makes blast radius impossible to bound. Practitioners should treat uniqueness, lifecycle, and environment isolation as one governance system rather than three separate controls.

From our research:

• 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to the 2024 Non-Human Identity Security Report.
• Only 23.7% of organisations share secrets through insecure methods such as email or messaging applications, which still leaves a meaningful exposure path for machine identities.
• This pattern reinforces the need to read Ultimate Guide to NHIs , Static vs Dynamic Secrets alongside the lifecycle guide for practical remediation.

What this signals

Secret sprawl debt: when credentials are scattered across code, chat, and pipelines, the governance problem becomes cumulative rather than isolated. That is why identity programmes need a single view of issuance, storage, rotation, and revocation across all non-human access paths.

The article points in the same direction as our NHI lifecycle guidance: lifecycle controls matter more than point fixes when identities are created faster than teams can retire them. For practitioners, that means offboarding, rotation, and environment separation should be measured as one control chain, not three disconnected tasks.

With 35.6% of organisations naming hybrid and multi-cloud access consistency as their top NHI challenge, the operational message is clear: access policy has to travel with the workload, not stay behind in a single platform.

For practitioners

• Automate NHI offboarding at project closure Bind service account and key revocation to project and application retirement so orphaned identities cannot remain active after the work ends.
• Block hardcoded secrets before merge Use repository scanning, pipeline checks, and developer workflows that prevent API keys and tokens from being committed into source control.
• Separate identities by workload and environment Issue unique credentials for each application and environment so development, testing, and production do not share the same trust boundary.
• Reduce privilege before reuse becomes normal Review service accounts that have broad permissions or are shared across multiple systems, then narrow their scope and ownership to a single workload.

Key takeaways

• The article shows that the biggest NHI failures are lifecycle, secret, and privilege failures, not isolated product gaps.
• Exposure remains high because organisations still struggle to govern non-human access as rigorously as human access.
• The controls that matter most are offboarding, runtime secret handling, and workload-specific identity boundaries.

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 Sprawl: The uncontrolled proliferation of sensitive credentials — API keys, tokens, passwords, certificates — across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Orphaned Identity: An orphaned identity is a service account, token, or other machine credential that no longer has a clear owner, purpose, or retirement path. These identities create compliance and security risk because they are easy to forget, difficult to review, and often remain active long after they should have been removed.

What's in the full article

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

• How its platform maps specific controls to each OWASP NHI risk category across offboarding, secrets, and access boundaries.
• The exact runtime handling patterns for injecting and rotating credentials in CI/CD and cloud environments.
• The machine identity and secrets management workflows that support environment isolation and workload-specific access.
• The implementation detail behind zero-knowledge secret handling and policy enforcement in hybrid deployments.

👉 Akeyless's full post covers the control mapping, runtime secret handling, and machine identity workflows behind each risk.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.