OWASP NHI Top 10 exposes the machine identity governance gap

At a glance

What this is: This article explains the OWASP NHI Top 10 and argues that machine identities have become the dominant governance gap in modern environments.

Why it matters: It matters because IAM, PAM, and cloud security programmes that still centre humans leave service accounts, API keys, and OAuth apps outside effective lifecycle control.

👉 Read Unosecur's analysis of the OWASP NHI Top 10 and machine identity governance

Context

Modern identity programmes were designed around human users, but the article argues that the more important access layer now belongs to machines. Service accounts, API keys, OAuth apps, bots, cloud roles, and workload identities authenticate, deploy, and move data across environments, often with more privilege and less oversight than employees.

The governance problem is not just scale. It is that machine identities are frequently unmanaged, poorly inventoried, and tied to long-lived credentials or overbroad trust relationships, which makes conventional human IAM controls incomplete. The OWASP NHI Top 10 is presented as a vendor-neutral way to structure that gap for practitioners.

The starting position here is typical for modern enterprises: automation has expanded faster than identity governance, so machine access has accumulated without the lifecycle discipline applied to people.

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 static NHI credentials increase third-party breach impact?

A: Static NHI credentials increase third-party breach impact because they persist beyond the moment of use. If a token or service account secret is copied into a report or repository, the attacker can replay it later and potentially pivot into connected systems. The longer the credential lives, the larger the downstream blast radius becomes.

Q: What are the signs that machine identity management is failing in an organisation?

A: Common signs include incomplete inventory, spreadsheet based tracking, manual renewal processes, unclear ownership, and repeated certificate expiry events. Another signal is when teams struggle to audit where machine identities exist or cannot automate lifecycle actions at scale. If operational teams keep reacting to expiring certificates instead of governing identity lifecycles proactively, the control environment is already under strain.

Q: What problem does ownership attribution solve for service accounts and API keys?

A: It closes the gap between exposure detection and accountable remediation. Many organisations can find the secret, but not the human who introduced it, maintains it, or can safely replace it. Ownership attribution gives security teams a practical way to assign action without relying on informal knowledge that disappears during staff changes.

Technical breakdown

Why machine identities change the access model

Machine identities do not behave like human users. They authenticate programmatically, often at high frequency, and they are embedded in CI/CD pipelines, SaaS integrations, and cloud-to-cloud workflows. That means the access problem is not login friction but lifecycle control, trust scope, and credential persistence. When a service account or OAuth app carries broad entitlements, the identity itself becomes the control plane for data movement and deployment. In practice, that makes inventory, ownership, and permission scope more important than password policy ever was for human accounts.

Practical implication: govern machine identities as production infrastructure, not as incidental implementation detail.

How long-lived secrets create silent blast radius

The article repeatedly points to API keys, tokens, and other long-lived secrets as the fastest route to compromise. Unlike human credentials, these secrets can sit in code, logs, pipelines, or integration configs for long periods, and they often remain valid even when the original use case has changed. Once exposed, they can be replayed without interaction, which gives attackers durable access and makes detection harder. That is why secrets sprawl and credential persistence are inseparable in NHI governance.

Practical implication: reduce standing secret exposure by tying issuance, rotation, and revocation to identity ownership and usage.

Why overprivileged OAuth apps and service accounts are so dangerous

Overprivileged NHIs are not just a policy problem. They create a multiplier effect because machine identities are frequently chained across systems, so one excessive grant can unlock storage, mail, build systems, or cloud roles. The article’s examples show that once an NHI is trusted broadly, compromise of that identity can expose customer secrets, internal mailboxes, or production data paths. In governance terms, excessive privilege becomes a structural weakness because the identity often exists to automate access that no human will later review in detail.

Practical implication: constrain machine identity permissions to the narrowest workload, environment, and trust boundary possible.

Threat narrative

Attacker objective: The attacker wants durable programmatic access through machine identities that can be reused to steal data, pivot across environments, and hide inside normal automation traffic.

1. Entry occurs when attackers obtain a leaked API key, unexpired token, or legacy service account credential from code, logs, developer systems, or third-party integrations.
2. Escalation happens when the compromised NHI already has broad or reusable access, allowing the attacker to authenticate to multiple cloud services, SaaS platforms, or CI/CD workflows.
3. Impact follows when the identity's standing trust enables secret exfiltration, mailbox access, customer data exposure, or lateral movement across interconnected workloads.

Breaches seen in the wild

• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
• OneLogin API flaw (CVE-2025-59363): A OneLogin API flaw exposed OIDC client secrets to anyone with an API key, including vendors (CVE-2025-59363); fixed with no customer impact.

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 is now the missing layer between cloud IAM and real access control. Human IAM programmes can mature for years and still leave the machine estate effectively unmanaged. The article’s core point is that service accounts, API keys, OAuth apps, and workload identities are not edge cases but the default path through which modern systems operate. Practitioners should treat machine identity governance as a distinct operating discipline, not an extension of user access administration.

The most dangerous NHI control gap is credential persistence without lifecycle ownership. Long-lived tokens, forgotten keys, and orphaned service accounts create a standing trust surface that remains exploitable long after the original need has passed. That is why the article’s real governance signal is not just inventory, but revocation authority tied to ownership and expiry. The practitioner conclusion is simple: if nobody can answer who owns a machine identity, the identity is already outside governance.

Identity blast radius is the right concept for understanding NHI risk at scale. A single overprivileged token rarely stays local because machine identities are chained across cloud, CI/CD, and SaaS control points. The OWASP NHI Top 10 makes that pattern visible by connecting privilege, reuse, and environmental trust boundaries. Security leaders should measure how far one compromised machine identity can travel before they assume the controls are sufficient.

The OWASP NHI Top 10 validates that machine identity security is a governance architecture problem, not a tooling checkbox. Visibility matters, but only because it enables ownership, rotation, offboarding, and privilege reduction across a fragmented estate. The field should stop asking whether NHIs are a niche class and start asking whether current identity governance can see and control the real perimeter. The practitioner implication is to reorganise control ownership around machine identities, not just humans.

Human IAM assumptions do not scale into automation-heavy environments. MFA, conditional access, and behaviour analytics remain useful for people, but they do not solve the governance model for tokens, service accounts, and OAuth trust chains. The article shows that modern infrastructure runs on identities that never log in like a person and never retire like one either. Practitioners should rethink identity programme boundaries before another hidden machine credential becomes the easiest path in.

From our research library:

• NHIs outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs.
• Read next: Ultimate Guide to NHIs

What this signals

Machine identity governance has to become a first-class programme, not a sub-feature of human IAM. The article’s core risk is that cloud and SaaS automation now depends on identities that are neither visible nor lifecycle-managed in the same way as people. That means the operational question is no longer whether to inventory NHIs, but whether the organisation can continuously own, classify, and retire them before they become the default access path.

Identity blast radius is the concept practitioners should use to prioritise remediation. A reused or overprivileged machine identity can cross pipelines, clouds, and SaaS integrations faster than most review processes can detect. Teams should focus on the identities that can reach the most systems with the fewest controls, because those are the ones most likely to turn routine automation into enterprise-scale exposure.

For practitioners

• Inventory every machine identity source Build a single view across cloud IAM, CI/CD, SaaS apps, secrets stores, and third-party integrations so service accounts, API keys, and OAuth apps are owned and classified.
• Enforce ownership and offboarding for NHIs Tie each non-human identity to a named system owner, defined expiry or review date, and a revocation path so abandoned credentials do not remain active.
• Replace long-lived secrets with shorter trust windows Reduce replayable credential exposure by limiting token lifetime, rotating secrets where rotation is still required, and removing credentials that persist after the workload changes.
• Shrink privileges around the actual workload boundary Review whether each machine identity needs broad cross-environment access or only a narrow set of actions in one pipeline, app, or cloud account.
• Separate dev, test, and production identities Prevent shared managed identities, reused keys, and cross-environment trust from turning a low-trust environment into a path to production systems.

Key takeaways

• Machine identities are now the main governance gap in modern cloud and SaaS environments, not a peripheral exception to human IAM.
• The risk comes from unmanaged lifecycle, long-lived secrets, and overprivileged trust chains that turn automation into a durable attack surface.
• Security teams need one operating model for inventory, ownership, privilege scope, and offboarding across service accounts, API keys, OAuth apps, and workload identities.

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.
• Long-Lived Secret: A long-lived secret is a credential, token, API key, or certificate that remains valid for an extended period without frequent renewal. In NHI environments, it creates durable exposure because one leaked secret can keep granting access long after the original use case has changed.
• 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.

What's in the full article

Unosecur's full blog covers the operational detail this post intentionally leaves for the source:

• OWASP NHI Top 10 walk-through with the article's per-risk explanations and incident context
• Detailed examples of how each NHI failure mode appears in cloud, CI/CD, and SaaS environments
• Unosecur's own automation and detection workflow for machine identity inventory and governance
• Benchmarks, scoring, and implementation details for teams assessing their current NHI posture

👉 Unosecur's full blog expands the OWASP NHI Top 10, incident examples, and machine identity governance implications.

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.