By NHI Mgmt Group Editorial TeamBased on Cerbos: “Safeguarding non-human identities: Understanding and addressing the OWASP top 10 threats” (August 15, 2025)

TL;DR: Machine identities are a higher-volume, lower-scrutiny attack surface where secret leakage, overprivilege, and offboarding gaps drive real breach risk, especially in cloud-native and distributed systems, according to Cerbos and OWASP's NHI Top 10. The security case is no longer about adding more identities, but about proving lifecycle, authentication, and authorization controls can keep pace with them.


At a glance

What this is: Cerbos's analysis of OWASP's NHI Top 10 frames non-human identity risk around exposed credentials, overprivilege, weak authentication, and poor offboarding.

Why it matters: IAM, PAM, and NHI teams need to treat machine identities as governed subjects, because the same lifecycle and privilege failures that affect humans can scale faster across services, APIs, and automation.

By the numbers:

  • Non-human identities often vastly outnumber human users by roughly 17:1 in typical organizations.

Context

Non-human identity governance is the problem space here: service accounts, API keys, tokens, certificates, and workload identities are being used to authorize software entities, but many programmes still manage them with weaker inventory, lifecycle, and privilege controls than human accounts.

Cerbos's article argues that this gap matters because machine identities are embedded across cloud-native and distributed systems, where one leaked secret or excessive permission can expose many downstream services. The article positions the OWASP NHI Top 10 as a control map for closing that gap rather than a feature checklist.


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 remain such a persistent NHI risk?

A: Leaked secrets persist because they are often embedded in code, pipelines, or collaboration tools, then left valid long enough for reuse. The real problem is not only exposure but weak identity lifecycle management, especially when ownership, rotation, and revocation are not tightly governed.

Q: How do teams reduce the blast radius of unmanaged service accounts?

A: Teams reduce blast radius by narrowing permissions, removing inactive identities, and preventing credentials from persisting after their business purpose ends. The goal is to make every service account easy to attribute, easy to review, and easy to revoke when its workload changes or disappears.

Q: How do organisations stop humans from misusing NHI credentials?

A: Separate human and machine identity paths so interactive work always uses a person’s account, not a service credential. If a human needs elevated access, use approved human IAM and PAM processes so audit trails, approvals, and session controls remain intact.


Technical breakdown

Why NHI inventory and lifecycle control come first

Non-human identities become risky when teams cannot answer what exists, who owns it, and when it should be removed. Service accounts and API keys often outlive the workload that created them, which turns ordinary credentials into orphaned access paths. In cloud-native environments, that problem compounds because one identity may span deployment, runtime calls, and admin automation. Lifecycle control is therefore not a housekeeping exercise but the baseline for governance, because every other control assumes you know which identities are still valid.

Practical implication: Build a complete NHI inventory and tie every credential to an owner, purpose, and revocation trigger.

Secret leakage turns authentication into an exposure problem

Secret leakage matters because a leaked token or API key is already authenticated access, not merely a password problem. Once a secret escapes into code, logs, chat, or CI output, an attacker does not need to defeat the identity system again. Short-lived tokens, vaulting, and scanning reduce the exposure window, but the real issue is that static credentials create durable trust in places where systems move quickly. That is why leaked machine secrets are often the fastest route from discovery to compromise.

Practical implication: Shift from long-lived secrets to short-lived credentials and monitor repositories, logs, and pipelines for exposure.

Overprivileged NHIs expand the blast radius of compromise

Overprivilege is what turns a single compromised machine identity into lateral movement and service-to-service abuse. If an NHI can perform more actions than its workload actually needs, an attacker inherits that excess scope the moment the credential is used. Policy-as-code and contextual authorisation matter because they let teams constrain what a valid identity can do at request time, even when the credential itself is real. That is the difference between authentication proving identity and authorisation limiting damage.

Practical implication: Review each machine identity against actual runtime tasks and remove permissions that are not required for execution.


Threat narrative

Attacker objective: The attacker wants durable authenticated access through a machine credential that can be used to move through cloud and application systems with minimal resistance.

  1. Entry occurs when an attacker finds a leaked API key, forgotten service account, or third-party credential that still works in production.
  2. Credential access then succeeds because the secret is already valid, so the attacker does not need to break the authentication layer first.
  3. Escalation follows when the compromised NHI has broader permissions than the workload truly needs, enabling lateral movement into adjacent services.
  4. Impact lands as data theft, cloud abuse, or environment compromise, often before the orphaned credential is detected and revoked.
  • 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 our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

The central failure is not machine identity volume, but machine identity governance lag. Cerbos's article shows that NHIs are now embedded in normal application and deployment paths, yet many programmes still treat them as secondary to human IAM. That creates a structural gap between how systems run and how access is governed. The practitioner conclusion is straightforward: machine identities need the same ownership, review, and revocation discipline as user accounts.

Secret leakage is a lifecycle problem before it is a secrets-management problem. A leaked key matters because teams allowed a credential to exist in a place where it could be copied, logged, or reused. OWASP NHI control NHI-02 maps to this failure mode directly, but the broader point is that detection after exposure is always late. The practitioner conclusion is to reduce credential exposure windows, not simply improve cleanup.

Overprivileged NHI: the identity blast radius concept explains modern breach propagation. A single service account with broad entitlements becomes a force multiplier for attackers once compromised, because the identity is treated as legitimate inside trust boundaries. This is why least privilege must be evaluated against actual workload behaviour rather than assumed service roles. The practitioner conclusion is to govern blast radius at the policy layer, not rely on credential possession as a safe proxy for trust.

Improper offboarding is where accountability disappears. The article's offboarding examples show that revoked projects, retired services, and changed vendor relationships can still leave valid machine access behind. That failure mode is especially dangerous because nobody is actively watching the identity once its original use case ends. The practitioner conclusion is to make offboarding an explicit NHI control, not an informal cleanup task.

Machine identity security has become a control plane issue, not just a credential hygiene issue. Cerbos's emphasis on centralized authorization reflects the reality that NHIs are used across distributed systems where local controls drift quickly. The field is moving toward policy-driven governance because the old model of scattered static permissions cannot keep pace with service-to-service access. The practitioner conclusion is to align inventory, authN, and authZ around one governed lifecycle.

From our research library:

What this signals

Identity blast radius is the right lens for NHI governance. Once a machine credential can act across deployment, runtime, and data planes, a single compromise becomes a platform-wide problem rather than a local one. That means NHI programmes should be assessed by how much damage a valid credential can cause, not just by how many credentials exist.

The practical shift is toward issuance-time control. Access reviews still matter, but they are weaker than policy decisions that constrain the credential before it is ever used. For teams maturing NHI governance, the control question is no longer whether secrets exist, but whether each secret can only reach the workload it was created for.


For practitioners

  • Inventory every non-human identity Map service accounts, API keys, tokens, certificates, and workload identities to an owner, a purpose, and a revocation path. Flag orphaned credentials and identities that no longer correspond to an active workload.
  • Replace long-lived secrets with short-lived credentials Use ephemeral tokens, OIDC federation, and vault-backed secret delivery wherever a machine identity does not require persistent credentials. Keep exposure windows as small as the workload allows.
  • Constrain machine privilege to runtime need Review actual API calls, deployment actions, and service-to-service dependencies, then remove permissions that are not required for those tasks. Use policy-based authorisation to enforce that limit at request time.
  • Block human use of NHI credentials Separate human administrative access from machine authentication paths so service credentials are never used for interactive work. Route elevated human access through approved identity and PAM controls instead.
  • Audit third-party access continuously Track every external service or integration that can use your credentials, monitor for unusual requests, and revoke access immediately when the relationship changes or the vendor no longer needs it.

Key takeaways

  • Machine identities are now a core attack surface because they often outnumber human users and are still governed with weaker scrutiny.
  • The main failure patterns are leaked secrets, excessive privileges, insecure authentication, and offboarding gaps that let credentials outlive their owners.
  • The most effective response is to combine inventory, short-lived credentials, and policy-based authorisation so machine access is constrained before abuse begins.

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 addresses the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-01 — Improper OffboardingThe article repeatedly centres on revoked, orphaned, and lingering machine access.
NHI-02 — Secret LeakageSecret exposure in repos, logs, and CI is one of the core risks discussed.
NHI-04 — Insecure AuthenticationThe article contrasts weak machine auth with modern short-lived token approaches.
Recommendation — Track machine identities through offboarding and revoke credentials when workloads or vendors retire. Scan for exposed secrets and eliminate credential storage in code, logs, and chat. Replace weak machine authentication with short-lived, validated identity assertions.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsThe article is fundamentally about governing which entitlements machine identities can exercise.
ID.AM-07 — Platforms and services are inventoriedNHI inventory and ownership are prerequisite controls for this subject.
PR.DS-01 — Data-at-rest protectionThe article touches secret storage and vaulting as core mitigations for leaked credentials.
Recommendation — Apply PR.AA-05 to limit each NHI to only the permissions its workload actually needs. Inventory platforms and services that issue or consume machine identities so ownership stays current. Protect stored machine secrets and keys so exposed values are harder to misuse.

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.
  • 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.
  • 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.

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.
NHIMG Editorial Note
Published by the NHIMG editorial team on June 11, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org