What is a non-human identity attack?

An attack in which the initial access or the lateral movement uses a credential belonging to software rather than to a person: a stolen API key, a compromised service account, an abused OAuth token, or a leaked CI/CD secret. The distinguishing feature is that most human-centric controls do not apply, because there is no multi-factor prompt, no impossible-travel signal and no user to notice anomalous behaviour.

What does a typical NHI attack path look like?

Four steps recur across the major incidents. A credential is obtained, usually from a repository, a log, a third-party breach or a misconfigured store. It is used from an unexpected location without triggering an alert, because the identity has no baseline location. Its permissions turn out to exceed its function, giving lateral reach. And it is not revoked quickly, because nobody owns it. Each step maps to a specific control, which is why attack-path analysis is a useful way to prioritise an NHI programme.

How do you prevent non-human identity breaches?

Four controls carry most of the value: eliminate credentials with unbounded lifetime, scope permissions to observed rather than requested usage, assign a named accountable owner to every identity, and test that revocation actually takes effect within a measured time. Detection tooling helps, but an over-privileged identity behaving exactly as configured produces no anomaly, which is why prevention outranks detection here.

What is the non-human identity attack surface?

It is the sum of every credential software holds and everything each can reach: service accounts in directories, API keys in configuration, OAuth grants to SaaS applications, tokens in CI/CD pipelines, cloud IAM roles, certificates, SSH keys, and now AI agent credentials. In most enterprises it is several times larger than the human identity surface and is the portion least likely to have a maintained inventory.

What is NHIDR, or non-human identity detection and response?

It is a vendor-originated term for applying detection and response techniques specifically to non-human identities, by analogy with ITDR for human identities. It is a marketing category rather than a defined standard, and no standards body or regulator uses it. The underlying idea is sound: baselines for machine behaviour differ from human ones. Treat capability claims under this label as you would any product claim, and ask what signals are actually being evaluated.

Which breaches were caused by non-human identities?

Several of the most consequential incidents since 2021 turned on machine credentials, including the Codecov bash uploader compromise in 2021, the Microsoft Storm-0558 token forgery and the Okta support system compromise in 2023, the Snowflake customer-instance credential attacks attributed to UNC5537 in 2024, and the Salesloft/Drift OAuth token compromise in 2025. We maintain detailed case studies for each.

Non-Human Identity Security, The Complete Primer

TL;DR

NHI security protects service accounts, keys, tokens, certificates, workload identities, and AI agents.
The 2025 attack surface is dominated by three patterns: leaked static credentials, orphaned identities, over-privileged service accounts.
The OWASP NHI Top 10 is the best shared taxonomy; five of the ten risks map to two underlying root causes.
Seven controls move the needle most: inventory, ownership, rotation, least privilege, lifecycle management, anomaly detection, third-party governance.
Traditional human-identity controls (MFA, manager-driven access review, behavioural UEBA) miss most of this surface by design.

The one-sentence definition

Non-human identity security is the subset of security practice that protects the digital identities of software entities, keys, tokens, certificates, service accounts, workload identities, and agents, from compromise, misuse, over-privileging, and orphaning.

It sits adjacent to but distinct from classical identity and access management (IAM), which was designed around human users, and from secrets management, which addresses only the credential-storage problem. NHI security is the broader governance frame that includes both the identity and its credentials.

What the attack surface looks like

Before controls, it helps to understand what an attacker is actually attacking. The NHI attack surface has four components:

1. The credential itself

Static API keys, service-account passwords, OAuth refresh tokens, SSH private keys, certificate private keys. Anywhere these live in plaintext (source-code repositories, CI/CD log files, container images, chat messages, developer laptops) is an attacker-reachable location. The "credential leakage" attack pattern, OWASP NHI2 in the Top 10, is the single most-exploited NHI risk.

2. The identity's permissions

An NHI is interesting to an attacker in direct proportion to what it can do. A narrowly scoped NHI with read-only access to a single resource is a small prize. A broadly scoped NHI with administrative access across many resources is a full-tenant compromise. This is the over-privilege problem (OWASP NHI5) and it is cumulative, the longer an NHI lives without right-sizing, the more permissions it tends to accumulate.

3. The identity's relationships (delegation chains)

Modern architectures stack NHIs. An AI agent authenticates to an MCP server; the MCP server authenticates to a backend API; the API calls a database through its own service account; the database is backed up by a third-party SaaS that holds its own OAuth token. Compromise of any link in the chain can propagate. The 2025 Salesloft/Drift OAuth supply-chain breach is the archetypal multi-tenant example, one compromised upstream NHI cascaded into the environments of 700+ downstream organisations.

4. The governance gap

Even an NHI that would be defensible under current controls becomes an attack asset when it falls outside the governance perimeter, when nobody knows it exists, when nobody owns it, when it was never added to monitoring. This is the orphan problem (OWASP NHI1). It is the highest-volume class of vulnerability in most environments.

The 2023 to 2025 threat landscape

Three years of public breach data converge on a clear pattern. A partial list, not comprehensive, of the incidents that established the category:

Year	Breach	Root-cause NHI
2021	Codecov Bash Uploader	Leaked credential in container image; kicked off CI/CD NHI attention
2023	Microsoft Storm-0558	Long-lived MSA signing key stolen in 2016, used in 2023 against 60K State Department emails
2023	Okta Support System	Service-account credentials stored in a personal Google account; one authentication, many downstream customer impacts
2023	Codecov	Compromised engineer's laptop allowed extraction of customer OAuth/API tokens
2024	Snowflake UNC5537	165 customer tenants compromised through single-factor static credentials harvested by infostealer malware
2025	Salesloft/Drift (UNC6395)	OAuth refresh tokens from Drift exposed 700+ downstream organisations' CRM data
2025	Shai-Hulud 2.0 npm worm	Self-replicating npm package worm exfiltrated credentials from ~25,000 repositories across ~1,195 organisations

The common thread: in every case, the initial access vector was an NHI credential. Not phishing. Not malware. Not a zero-day in a perimeter appliance. A key, token, or service-account credential that should have been protected, rotated, or revoked. Detailed post-mortems of each are in the breach catalog.

The OWASP NHI Top 10 at a glance

The Open Worldwide Application Security Project (OWASP) published version 1.0 of the Non-Human Identities Top 10 in 2025, through a dedicated working group sponsored in part by Astrix Security. The list is the most useful vendor-neutral risk taxonomy the field has. Full walkthrough in our framework page; here is the single-screen summary:

NHI1, Improper offboarding. The identity outlives its purpose.
NHI2, Secret leakage. Credentials end up in accessible places.
NHI3, Vulnerable third-party NHI. A supplier's compromised NHI pivots into your environment.
NHI4, Insecure authentication. Deprecated auth patterns (basic auth, bare passwords, long-lived bearer tokens).
NHI5, Overprivileged NHI. Broad permissions for convenience.
NHI6, Insecure cloud deployment configurations. Unsafe defaults in cloud IAM.
NHI7, Long-lived secrets. Credentials that never rotate.
NHI8, Environment isolation. NHIs shared across dev/staging/prod.
NHI9, NHI reuse. Single NHI serving many purposes.
NHI10, Human use of NHIs. Humans logging in as service accounts.

A pattern-recognition point: NHI1 and NHI7 share a root cause (lifecycle management). NHI2 and NHI4 share a root cause (credential hygiene). NHI5 and NHI6 share a root cause (authorisation design). That means a substantial fraction of the list can be addressed by investing in three specific capabilities rather than ten.

The seven controls that move the needle

Not every plausible control is worth the same investment. Our view, based on looking at what differentiates mature programmes from immature ones, is that seven controls produce disproportionate risk reduction:

1. Automated inventory

You cannot govern what you cannot see. An auto-discovered, continuously refreshed NHI inventory across directories, cloud accounts, SaaS tools, CI/CD, and Kubernetes is the foundation. Most programmes find 3 to 10× more NHIs on first inventory than leadership expects.

2. Enforced ownership

Every NHI has a current human owner (a person or a team). At provisioning. Without it, the identity cannot be created. Eliminating orphaned identities is single-handedly the largest risk-reduction move in most environments.

3. Credential rotation

Static credentials are rotated on schedule. Where possible, they are replaced with short-lived dynamic credentials or workload identity federation. The practical target: no credential older than 90 days in production; ideally, no static credentials at all.

4. Least privilege enforcement

Permissions are granted at the minimum needed and reviewed regularly. Drift is monitored. Just-in-time elevation is used for rare privileged operations.

5. Lifecycle automation

Offboarding is tied to identifiable events: employee departure, application retirement, integration removal. NHIs without recent activity are flagged and decommissioned.

6. Behavioural monitoring (ITDR / NHIDR)

NHI behaviour is baselined and anomalies are alerted. A service account that has run the same 3 queries every night for a year and suddenly attempts data export is a high-confidence signal.

7. Third-party integration governance

OAuth applications and SaaS-to-SaaS connections are reviewed at installation, re-reviewed on permission change, and revoked on deprecation. Post-Salesloft/Drift, this is no longer optional for any organisation running a significant SaaS estate.

Why traditional IAM misses this

Human IAM is built on a set of assumptions that don't hold for NHIs. The assumptions:

Assumption: The identity holder can be challenged for a second factor (MFA). Reality: NHIs typically cannot be MFA-challenged.
Assumption: The identity has a manager who can attest to its access. Reality: Many NHIs have no manager, or the manager is a team that has reorganised twice.
Assumption: Behaviour can be baselined on a population of humans with similar roles. Reality: NHIs are often unique, a single integration with its own access pattern.
Assumption: Offboarding is triggered by an HR event. Reality: NHIs have no HR event.
Assumption: Identity count scales with headcount. Reality: NHI count scales with architectural complexity, ~45× faster than headcount.

This is why extending human IAM onto NHIs produces disappointing coverage. The processes and tools meet the primitives they were designed for, and then they stop.

The NHI security stack

Tooling for NHI security has consolidated into rough categories over 2023 to 2026. The common stack:

NHI discovery & governance platforms, Astrix Security, Oasis Security, Entro Security, Token Security, Silverfort/Rezonate. Purpose-built for NHI inventory, lifecycle, and OAuth governance.
Secrets management, HashiCorp Vault (now IBM), AWS/GCP/Azure native key management, Doppler, Infisical, Akeyless. The credential-storage layer.
Secrets scanning, GitGuardian, Doppler/Truffle, GitHub's native scanning. Detection of leaked credentials.
Workload identity, SPIFFE/SPIRE, AWS IAM Roles Anywhere, Azure Workload Identity, GCP Workload Identity Federation, Aembit. The static-credential-replacement layer.
Privileged access management (PAM), CyberArk (post-Palo Alto acquisition), BeyondTrust, Delinea, Teleport. Traditional PAM extended to NHI.
ITDR / NHIDR, Silverfort, Microsoft Defender for Identity, CrowdStrike Falcon Identity. Identity threat detection and response, increasingly NHI-aware.

Vendor-neutral profiles of each category are in the vendor hub.

Practical next steps

If you are starting, in order:

Run the maturity assessment. Four minutes. Gives you a calibrated starting point.
Pick one category, API keys in CI/CD, AD service accounts, or OAuth-connected SaaS, and inventory it.
Identify orphans. NHIs with no current owner, no recent activity, or no purpose on file. Decommission aggressively.
Rotate the oldest credentials. Any credential more than a year old is a 2026 liability.
Run the OWASP NHI Top 10 self-audit. Map yourself against all ten risks. You will find the gaps.
Pick a framework. OWASP NHI Top 10 for risks, SPIFFE/SPIRE for architecture, CSA for programme guidance.

Non-human identity security.