OWASP Non-Human Identities Top 10 (2025).

What the OWASP NHI Top 10 is, and isn't

The OWASP NHI Top 10 is a risk taxonomy: a structured list of the ten most prevalent and severe risks to non-human identities in enterprise environments, published by a dedicated OWASP working group in 2025. It is modelled on the OWASP Top 10 for web applications and the OWASP API Security Top 10, shorter, more opinionated, and designed for rapid adoption by working practitioners.

It is not:

• A complete NHI controls framework (that would be CSA's programme guide, or individual vendor reference architectures)
• A regulatory requirement (it is a community standard, not a regulation)
• A benchmarking model (the 5-stage maturity model on this site does that job)
• An architecture specification (that is SPIFFE/SPIRE and the IETF WIMSE drafts)

The primary source document is maintained at owasp.org/www-project-non-human-identities-top-10/. The 2025 working group was led by volunteers from multiple organisations, with Astrix Security as the initial co-sponsor. Our walkthrough here is independent, editorial, and not commissioned by OWASP or by any sponsor.

Quick reference, all ten at a glance

NHI1, Improper offboarding

What it is: An NHI is created for a purpose, the purpose ends, and the NHI continues to exist with live credentials and accumulated privileges. The defining characteristic of orphaned identities.

Why it happens: NHIs have no natural decommissioning trigger. When a human leaves, HR fires an event. When an application is retired, nobody fires an event. The NHI lives on.

Exemplar: Microsoft Storm-0558 (2023). A 2016-era MSA signing key remained valid in 2023, used to forge tokens against 60,000 US State Department emails. Seven years past its intended lifespan.

Controls: Event-driven offboarding tied to HR terminations, application retirements (CMDB), and integration removals. Inactivity-based retirement (no authentication in 90 days). Quarterly orphan sweeps that flag NHIs with no current owner. See lifecycle triggers.

NHI2, Secret leakage

What it is: Credentials end up in places accessible to attackers, public or private source repositories, CI/CD log files, container images, Slack, developer workstations, backup archives.

Why it happens: Developers need credentials to develop. Without a centralised secret store that's easier than hardcoding, credentials end up inline.

Exemplar: Shai-Hulud 2.0 (November 2025), self-replicating npm package worm exfiltrated credentials from approximately 25,000 repositories, tied to ~1,195 organisations (Entro Security). Codecov (January 2023), attacker extracted customer OAuth tokens and API keys from an engineer's compromised workstation.

Controls: Centralised secret store (Vault, Secrets Manager, Key Vault). Secret scanning (GitGuardian, GitHub native, TruffleHog) across all source repositories and CI logs. Developer training and pre-commit hooks. Rapid rotation on detection. See secrets management.

NHI3, Vulnerable third-party NHI

What it is: A third-party supplier's NHI credential, their OAuth refresh token, their integration service account, their API key, is compromised, and the attacker pivots into your environment through the supplier's authorised access.

Why it happens: Third-party integrations require shared trust, and your defenders don't have visibility into the supplier's identity posture.

Exemplar: Salesloft/Drift (August 2025). Attackers (tracked as UNC6395 by Mandiant) compromised Drift, extracted OAuth refresh tokens granting access to 700+ downstream organisations' Salesforce data, and systematically harvested data across the victim population. Victims included Cloudflare, Google, Tanium, Zscaler, and Palo Alto Networks.

Controls: OAuth application review on installation. Periodic re-review of granted scopes. Revocation of unused integrations. SSPM tooling (Astrix, AppOmni, Obsidian) for SaaS-to-SaaS integration inventory. Contractual language requiring supplier notification of credential-related incidents. See full case study.

NHI4, Insecure authentication

What it is: NHIs authenticate with deprecated mechanisms, HTTP basic auth, bare passwords, long-lived bearer tokens without binding, rather than modern patterns (OIDC, mTLS, workload identity federation).

Why it happens: Legacy applications don't support modern auth. Migrations are hard. Short-term pragmatism outlasts the migration plan.

Exemplar: Snowflake UNC5537 (2024). Static single-factor customer credentials harvested by infostealer malware were used across 165 Snowflake customer tenants, including AT&T (with ~110M customer records and a reported $370K ransom payment) and Ticketmaster (~560M records). The credentials were valid precisely because MFA enforcement was a customer configuration choice that many had not adopted.

Controls: Require modern authentication (OIDC with workload binding) for all new NHIs. Enforce MFA where the NHI is human-proxying (e.g. personal access tokens). Deprecate basic auth and static passwords on a scheduled migration. Use workload identity federation instead of long-lived keys where supported. See SPIFFE/SPIRE.

NHI5, Overprivileged NHI

What it is: NHIs are granted more permissions than they need for their purpose, creating broader lateral-movement potential when compromised.

Why it happens: Right-sizing is tedious. Granting broad permissions is fast. Reviewing them afterward requires effort nobody has.

Exemplar: Okta Support System (October 2023). A service account credential stored in an engineer's personal Google account was compromised; the service account had broad access to customer support-case data, which was exfiltrated. The principle-of-least-privilege failure compounded the initial credential-exposure failure.

Controls: Permission boundaries enforced at creation. Regular access reviews (quarterly for high-privilege, annually for the population). Unused-permission detection and removal. Just-in-time elevation for rare privileged actions. Attribute-based access control (ABAC) where applicable.

NHI6, Insecure cloud deployment configurations

What it is: Cloud IAM configurations, AWS IAM policies, Azure RBAC assignments, GCP IAM bindings, with insecure defaults, overly broad wildcards, public exposure, or missing conditional access.

Why it happens: Cloud IAM is complex. Defaults are often permissive. Wildcards are easy; precise policies are hard.

Exemplar: A long tail of cloud-configuration breaches 2020 to 2024, including numerous S3-bucket and GCS-bucket exposures where NHI permissions were misconfigured. No single "famous" incident, but the volume is substantial.

Controls: Cloud security posture management (CSPM) tooling (Wiz, Prisma Cloud, Orca, Lacework) with NHI-aware rule sets. Infrastructure-as-code linting with policy engines (OPA, Checkov, Terrascan). Service control policies and permission boundaries enforced at the organisation level. Regular review of wildcard-containing IAM policies.

NHI7, Long-lived secrets

What it is: Credentials that never rotate, or rotate only in response to known exposure. The inverse of the short-lived / dynamic / workload-identity ideal.

Why it happens: Rotation is operationally hard. "If it isn't broken, don't fix it" applies. Integration with modern rotation patterns is often an afterthought.

Exemplar: Microsoft Storm-0558 again (credential age was seven years). Codecov Bash Uploader (2021), the leaked credential was long-lived and unrotated, enabling months of downstream harvesting before detection.

Controls: Scheduled rotation in the centralised secret store. Dynamic secret generation for databases and cloud IAM. Workload identity federation where available. Target: p50 credential age under 90 days; ideally under 7 days. See dynamic and short-lived secrets.

NHI8, Environment isolation

What it is: NHIs shared across environments (dev, staging, production), so a compromise of the development environment grants access to production.

Why it happens: Sharing NHIs is a shortcut. Separate NHIs per environment require proper CI/CD patterns and configuration-per-env hygiene.

Exemplar: Multiple incidents where attackers compromised a developer or staging environment and pivoted to production via shared service accounts or shared API keys. Often underreported because the transition from dev to prod isn't always visible in breach disclosures.

Controls: Distinct NHIs per environment. Environment-specific permission boundaries. Separate secret-store namespaces per environment. Network-level segmentation so production-only NHIs cannot be exercised from development contexts.

NHI9, NHI reuse

What it is: A single NHI used for multiple unrelated purposes, so its permissions are the union of all those purposes, and compromise exposes all of them.

Why it happens: Creating new NHIs has friction. "Just use the existing one" is the path of least resistance.

Exemplar: Common organisational pattern: one "automation" service account that runs deployments, runs backups, and handles monitoring, with accumulated permissions from all three. Compromise of any one use case exposes the others.

Controls: Separate NHI per use case / per application / per integration. Naming conventions that encode purpose. Provisioning workflows that default to creating new NHIs rather than reusing. Discovery processes that flag NHIs used by multiple distinct systems.

NHI10, Human use of NHI

What it is: Humans logging in as service accounts, or sharing NHI credentials across a team for operational convenience. Breaks identity accountability and exposes NHI credentials to human-vector risks (phishing, credential stuffing).

Why it happens: Operational convenience, especially during incidents. Permissions that humans need are convenient when already present on a service account.

Exemplar: The 2022 Uber breach involved, among other vectors, the attacker obtaining access to a privileged PowerShell script containing service-account credentials used for operational purposes. The pattern is widespread across enterprises.

Controls: Block interactive login for service accounts where possible. Break-glass access logged separately with alerting. Distinct privileged access tooling (PAM) for human operators. Just-in-time elevation rather than shared long-lived credentials.

Self-audit, run it now

Scoring yourself against all ten risks takes about eight minutes and produces a coverage percentage plus a remediation email. The OWASP NHI Top 10 self-audit is the tool.

Primary source: owasp.org/www-project-non-human-identities-top-10. Always consult the primary source for the authoritative current version.

Frequently asked questions

What is an overprivileged NHI?

A non-human identity holding permissions beyond what its actual function requires. It is one of the OWASP Non-Human Identities Top 10 categories and is among the most common findings in practice, because permissions are typically granted based on what was requested at creation rather than on observed usage, and are almost never reduced afterwards. The practical test is to compare granted permissions against ninety days of actual use.

What is a vulnerable third-party NHI?

An identity granted to an external vendor, SaaS integration or connected application, where the risk is inherited from a party outside your control. It is an OWASP NHI Top 10 category and the pattern behind several major incidents, including the Salesloft/Drift OAuth compromise: the integration was legitimate, the scope was broad, and the compromise happened at the third party rather than at the customer.

Is there an OWASP NHI Top 10 PDF?

OWASP publishes the Non-Human Identities Top 10 through its project site and the material is freely available. We deliberately do not host a copy, because the list is revised and a mirrored PDF becomes a stale authority. Always work from the OWASP project page for the current version, and use our walkthrough for interpretation rather than as a substitute.

How does the OWASP NHI Top 10 relate to the OWASP Top 10 for Agentic Applications?

They are complementary lists from adjacent OWASP efforts. The NHI Top 10 enumerates risks to non-human identities generally, including service accounts, secrets and third-party integrations. The Top 10 for Agentic Applications, published in December 2025, addresses threats specific to autonomous agent systems. Organisations deploying agents usually need both, since an agent is a non-human identity with additional failure modes.

Does the OWASP NHI Top 10 cover secrets rotation?

Yes, in substance. Long-lived and unrotated credentials appear as a distinct risk category, and rotation is the primary control. Note that rotation on its own is insufficient if the identity is also overprivileged or unowned: a rotated credential attached to an over-scoped identity narrows the theft window without narrowing the blast radius.

Is the OWASP NHI Top 10 a standard?

No. It is a published industry framework from OWASP: authoritative, widely referenced, and freely available, but not certifiable and not referenced by any regulator. Use it to structure an assessment and to communicate risk categories. If you need something citable to an auditor, map findings onto ISO/IEC 27001 controls or an ISO/IEC 42001 management system.