OWASP Non-Human Identities Top 10: Risks and Controls for 2025

The OWASP Non-Human Identities Top 10 2025 lists security risks involving identities used by applications, services, workloads, automation, and integrations. Its categories cover offboarding, secret leakage, third-party identities, insecure authentication, excessive privilege, cloud deployment configuration, long-lived secrets, environment isolation, identity reuse, and human use of automation identities.

The official OWASP NHI Top 10 2025 focuses on risks that application developers and security teams can find throughout the software lifecycle. It ranks the entries with the OWASP Risk Rating Methodology and cites breach research, surveys, and vulnerability sources as inputs.

An identity is not the same thing as its credential. A service account, application registration, workload principal, bot, or automation user may have several secrets, keys, certificates, or tokens over its lifetime. Rotating one credential does not remove the identity’s permissions, ownership problem, or active sessions.

Key Takeaways

• Inventory the identity object, credentials, owner, purpose, permissions, dependencies, environments, activity, and retirement condition together.
• Prefer short-lived credentials issued to a verified workload, but retain strict authorization and a tested revocation path.
• Use a separate identity for each application, component, and environment when their access or lifecycle differs.
• Detect human sign-in through non-human identities and move administrative work to named, attributable human accounts.

What Counts as a Non-Human Identity

A non-human identity is a digital principal intended for software or automated activity rather than a person. Common examples include cloud service accounts, application registrations, OAuth clients, Kubernetes ServiceAccounts, CI/CD identities, database users, bots, integration accounts, and device or workload identities.

API keys, passwords, private keys, certificates, and tokens are credentials or identity documents. They prove or support access as a principal, but they are not the complete identity record. The non-human identity security guide explains discovery, ownership, permissions, lifecycle, and monitoring in more detail.

The OWASP list often discusses secrets because long-term application credentials create common attack paths. Workload identity and federation can remove many static secrets, but insecure trust policy can still grant the wrong workload excessive access. Credential modernization and access governance need to progress together.

OWASP Non-Human Identities Top 10 Risks Explained

NHI1: Improper offboarding

Improper offboarding leaves an identity, credential, permission, trust relationship, or session active after its application or integration no longer needs access. Deprecated services are easy to miss because they may have no current owner and no regular sign-in.

Tie every identity to an owner, dependency, and retirement trigger. Disable access when the application, environment, vendor relationship, or workload ends, then monitor for failed use that reveals a missed dependency. Delete credentials and trust rules after a controlled observation period.

NHI2: Secret leakage

Secrets can leak through source repositories, build logs, images, configuration, tickets, chat, model prompts, browser storage, telemetry, and artifacts. A secret scanner may find a string without identifying the principal, privilege, environment, or whether the credential remains valid.

Prevent new static secrets where workload federation is available. Store remaining credentials in managed secret systems, restrict retrieval, redact logs, scan code and artifacts, and rotate exposed values quickly. Investigation must identify use of the old credential and review the associated identity’s permissions.

NHI3: Vulnerable third-party NHI

Third-party tools and SaaS integrations often receive application identities or OAuth grants into company systems. A compromised vendor, extension, package, or update can misuse those valid permissions without attacking the target directly.

Inventory third-party principals separately from ordinary user accounts. Review publisher, permissions, data access, callback destinations, credential storage, update process, and offboarding. Use a dedicated identity with narrow resources so compromise of one integration does not reach unrelated systems.

NHI4: Insecure authentication

Non-human identities may use shared passwords, static keys, weak client secrets, unsigned requests, missing certificate validation, or tokens accepted for the wrong issuer or audience. Authentication can also fail when services cannot distinguish one workload instance from another.

Prefer platform-issued, short-lived credentials based on authenticated workload properties. Validate issuer, subject, audience, signature, expiry, and intended token type at the receiving service. Protect bootstrap credentials and rotate signing keys under a process that avoids accepting unknown issuers.

NHI5: Overprivileged NHI

Developers may grant broad roles because exact permissions are hard to determine during setup. Those roles persist, and a compromised workload can use every allowed action even if normal code calls only a small subset.

Start with task-specific access, separate read and write identities where useful, and restrict resources, conditions, and environments. Compare assigned permissions with observed activity, then remove unused actions carefully. High-risk operations should require a separate path or approval rather than living in the default role.

NHI6: Insecure cloud deployment configurations

CI/CD and cloud deployment identities can hold permission to create infrastructure, change policies, read secrets, and deploy code. Unsafe trust conditions, forked pull requests, unprotected environments, shared runners, and unpinned actions can turn a pipeline into an access path.

Use isolated runners for sensitive work, protect deployment environments, pin dependencies, and restrict which repositories, branches, workflows, and claims can obtain cloud roles. Separate build from deployment authority and production from lower environments. Record the source revision and identity for every deployment.

NHI7: Long-lived secrets

Long-lived secrets increase the time an attacker can use a stolen credential and make rotation disruptive. A credential copied into several systems may remain active because no owner knows every dependency.

Use workload identity federation or a broker to issue temporary credentials after verifying the workload. Where a static secret remains necessary, set an expiry, automate rotation, track every consumer, and test rollover before an emergency. Short lifetime reduces exposure but does not correct excessive permissions.

NHI8: Environment isolation

Development, test, staging, and production can become connected through shared identities, credentials, trust stores, or secret backends. Compromise in a lower environment then provides a valid path into production.

Use distinct principals and trust policies for each environment. Prevent production credentials from reaching lower builds, restrict network and secret access, and separate administrative roles. Promotion should move verified artifacts, not reuse the build environment’s identity inside production.

NHI9: NHI reuse

Identity reuse assigns one principal to several applications, services, components, or tenants. Audit records cannot show which workload acted, and revoking access for one system breaks the others. A compromise also inherits the combined permission set.

Issue a separate identity when purpose, owner, permissions, lifecycle, or environment differs. Use automation to make identity creation cheap and apply standard policy. Preserve stable workload identifiers in logs so operators can trace activity without depending on a shared account name.

NHI10: Human use of NHI

People sometimes sign in with service accounts or copy application tokens for debugging and administration. Their actions then appear as automation, bypass individual authentication controls, and make accountability or offboarding difficult.

Give administrators named human identities and time-limited elevation. Provide an audited break-glass process for emergencies and block interactive sign-in for service principals where the platform supports it. Alert on user agents, source systems, time patterns, and operations inconsistent with the workload’s normal behavior.

NHI Inventory Must Join Several Data Sources

Identity-provider exports alone miss local database users, embedded credentials, certificates, and identities created inside development platforms. Secret scanners find credentials but may not identify the principal that accepts them. Runtime logs show active use while missing dormant access.

Combine cloud IAM, directories, SaaS integrations, secret managers, certificate systems, Kubernetes, CI/CD platforms, source scans, API gateways, databases, and activity logs. Normalize each finding around a principal and link its credentials and permissions. Preserve source evidence so analysts can distinguish a confirmed identity from a suspected secret.

Prioritize with both configuration and behavior. An unused administrator identity with no owner may deserve faster action than a frequently used narrow workload identity. Credential age is useful, but privilege, exposure, environment, owner, and observed activity explain the likely impact.

Workload Identity Reduces Secrets but Changes Trust

Federation replaces a stored target credential with a token exchange based on a local workload assertion. The receiving system validates issuer, subject, audience, and other claims before issuing temporary access. This reduces static secret distribution and makes expiry automatic.

The trust rule becomes the sensitive control. A pattern that accepts every repository, namespace, branch, or service account can let the wrong workload assume the role. Review both sides of the exchange and bind trust to exact workload attributes where possible.

The workload identity federation guide compares cloud patterns and explains token validation. Federation should also create audit links between the source workload, exchanged credential, target role, and resulting API calls.

How to Test Non-Human Identity Controls

Start with lifecycle tests. Create an identity, issue credentials, change ownership, rotate access, suspend the workload, move it between environments, and retire it. Verify that the correct permissions, sessions, tokens, secrets, and trust relationships change at each step.

Run negative authentication and authorization cases. Present tokens from the wrong issuer, subject, audience, tenant, environment, or expired session. Attempt unused actions, cross-environment access, human login, and calls after revocation.

Test response readiness with a leaked credential scenario. The team should identify the principal, privileges, consumers, recent activity, owner, and safe replacement process quickly. If rotation requires searching repositories and asking several teams who uses the secret, the identity record is incomplete.

Frequently Asked Questions

What is the OWASP NHI Top 10?

It is OWASP’s 2025 list of major risks involving identities used by software and automation. The entries cover identity lifecycle, credentials, authentication, privilege, environment separation, third parties, reuse, and human misuse. It is an awareness and prevention resource rather than a complete identity standard.

Are API keys non-human identities?

An API key is usually a credential associated with a user, application, service, or project principal. Calling the key an identity can hide ownership, permissions, and lifecycle information stored elsewhere. Inventory the key and the principal that accepts it as linked but distinct records.

Do short-lived credentials solve NHI security?

Short-lived credentials reduce the time a stolen token remains useful and remove some rotation work. They do not fix broad trust, excessive permissions, unsafe issuance, identity reuse, or missing ownership. The workload and target service still need authentication, authorization, monitoring, and revocation.

Why should each workload have a separate identity?

Separate identities allow different permissions, owners, environments, and retirement events. They also make audit records attributable to a specific service or component. Shared identities combine impact and force teams to keep access active for every remaining consumer.