Non-human identity security explained

A non-human identity (NHI) is a software principal, such as a service account, workload, cloud instance, device, or automated agent, that can authenticate itself and be granted permissions to reach resources. No person sits behind it, and it is created by a software event rather than by a hire. Outside cybersecurity the phrase means something quite different, and the bare acronym NHI is dominated in general search by an unrelated meaning, so to be explicit: this page is about machine principals inside enterprise identity systems.

These identities now make up most of what authenticates in a modern estate. They hold standing privilege, they run continuously, they rarely have a named owner, and their credentials routinely outlive the systems that issued them. This page defines the population, draws its boundaries against machine identity and identity and access management (IAM), shows how these identities actually get compromised, and sets out what a security team does when one of them triggers an alert.

What is a non-human identity?

A non-human identity is any software principal that can authenticate and be authorized to reach resources, with no person behind it. Service accounts, workloads, cloud instances, devices, and automated agents all qualify. The category exists because automation needs credentials. Every scheduled job, pipeline, integration, and microservice has to prove who it is before it can do anything useful.

Non-human identity security, often shortened to NHI security, means finding that population, giving each identity an owner and a scoped set of permissions, shortening the life of its credentials, and detecting when one starts behaving in a way it never has before. Insider risk management programs increasingly fold these identities in, because an unowned service account and an unmonitored employee present a similar governance problem.

The boundary test, what counts and what does not

The Cloud Security Alliance draws the line narrowly. In its 2026 paper Defining Non-Human Identity, an entity qualifies as an NHI "only when it can authenticate (prove who it is) and be authorized (be granted permissions), either directly or indirectly, to access resources" (Cloud Security Alliance).

That test rules out several things people casually call non-human identities. A configuration record, such as a CMDB entry describing a server, is not an identity unless it is used to authenticate or to obtain entitlements. Neither are metadata objects, nor code and scripts that never authenticate. Most consequentially, secrets, tokens, API keys, and certificates are not identities either, unless they are bound to one. That last exclusion changes how a program is run, and the next section explains why.

The US government has its own term for the same idea. NIST defines a non-person entity (NPE) as "an entity related to information technology with a digital identity that acts in cyberspace, but is not a human actor," drawing on CNSSI 4009-2015, NIST SP 800-162, and NIST SP 800-207 (NIST CSRC). When a control framework or a federal contract says NPE, it means non-human identity.

How many non-human identities an organization has

There is no industry consensus on how far non-human identities outnumber human ones, and the published figures cannot be reconciled. They cover different populations: all enterprises in one study, cloud-native estates in another, large organizations only in a third. They use different denominators, counting machine identities per employee in one case and non-human identities per human identity in another. And they come from different methods, spanning authentication telemetry, repository scanning, and survey self-report. Treat any headline ratio as directional and scoped to its environment, never as a benchmark for yours.

What is safe to say is the direction. Non-human identities now vastly outnumber human ones in most estates, and the gap keeps widening as automation and agent-based workflows expand.

One reachable, dated, non-ratio measurement anchors that. A 2026 report found that 91% of active production identities were non-human, drawn from the AWS and Google Cloud environments that vendor monitors (Help Net Security). That is a share of observed active identities in one vendor's monitored estate. It is not a ratio, and converting it into one would invent a number the research does not support.

What are the types of non-human identities?

Non-human identities fall into five kinds, grouped by what the identity is bound to rather than by the credential it happens to present.

Five identity subjects

Table: The five non-human identity types in the Cloud Security Alliance taxonomy, what each identity is bound to, and a concrete example of each.

The middle column does the real work. A service account binds to an application principal, so it survives redeployment. A workload identity binds to a running pod, service, or function, so it may exist for seconds. Infrastructure identities attach to instances and nodes, device identities to hardware and firmware including IoT sensors, and agent identities to an autonomous actor. Workload identities are the fastest-growing group in containerized estates, which is why Kubernetes security work and non-human identity work overlap so heavily in practice.

The identity subject is not the authentication mechanism

Organizations routinely conflate the identity with the thing it uses to prove itself, treating an API key, a token, or a certificate as though the credential were the identity. It is not. Those are authentication mechanisms, and the taxonomy sorts them into five categories: static secrets such as passwords, API keys, and SSH keys, signed tokens such as JWT, OIDC, and SAML assertions, certificates including X.509 and SPIFFE SVIDs, hardware-backed or attestation-backed credentials held in a TPM, HSM, or secure element, and cloud-native session credentials of the short-lived, temporary kind.

The governance rule follows directly from the split. Anchor ownership, lifecycle, and entitlements to the subject, which is the service account or workload that persists. Tailor credential strength, rotation frequency, and renewal to the mechanism, which can be replaced without changing who the identity is. Programs that invert this end up rotating secrets diligently while nobody can say who owns the account those secrets belong to. That is also why an inventory of API keys is not an inventory of identities.

Are AI agents non-human identities?

Yes, with one qualification. The Cloud Security Alliance taxonomy names "agent identities (autonomous actor, including AI)" as one of its five types, so an AI agent is a non-human identity and inherits every failure mode on this page: standing privilege, unrotated credentials, and no named owner. The qualification is that agent-to-tool authorization now has a normative model of its own. The Model Context Protocol specification dated 2026-07-28 makes MCP servers OAuth 2.1 resource servers that "MUST validate that access tokens were issued specifically for them as the intended audience" (Model Context Protocol). The governance, lifecycle, and control questions specific to agents belong to agentic AI security.

How non-human identity relates to machine identity and IAM

Non-human identity security is IAM applied to principals that never had a joiner, mover, or leaver process. The table separates the three terms that get used interchangeably.

Table: How human identities, non-human identities, and machine identities differ across origin, credential, ownership, and end of life.

Human versus non-human identities

The difference that matters is where the identity comes from. Human identities move through HR-driven joiner, mover, and leaver processes, so their lifecycle has a system of record and a person accountable for it. Non-human identities originate from software lifecycle events instead: a deployment, a provisioning run, a workload starting, a pipeline executing, an autoscaling event, an agent invocation. No HR system knows any of that happened. That is why governance models built on joiner, mover, and leaver do not naturally apply to this population.

Machine identity and the certificate framing

The terms overlap without being synonymous. Machine identity management sits in the PKI tradition, centering on certificates, keys, and renewal before expiry. Non-human identity work centers on service accounts, OAuth tokens, API keys, and application-to-application authorization. The subject-versus-mechanism split explains the difference: a certificate is a mechanism, not a type of identity.

The certificate clock is tightening on its own schedule. The CA/Browser Forum adopted Ballot SC-081v3 on 11 April 2025, phasing the maximum validity period of publicly trusted TLS certificates from 398 days down to 47 days, with the reductions "proposed to occur starting in March 2026 and concluding in March 2029" (CA/Browser Forum). That schedule governs publicly trusted TLS certificates only. It does not reach internal PKI, and it does not touch the OAuth token and API key population that dominates this page.

Where NHI security sits relative to IAM

IAM is a cybersecurity discipline, and non-human identity security is the part of it covering principals with no person behind them. The distinction is operational rather than academic, because legacy IAM tooling was built around human lifecycle events. In a vendor-sponsored 2026 Cloud Security Alliance survey of 383 practitioners, conducted online in August and September 2025, 92% of respondents said they were not confident their legacy IAM solutions can effectively manage the risks associated with AI and non-human identities (Cloud Security Alliance). Identity analytics is where the two populations meet in practice, applying behavioral modeling to both.

How non-human identities get compromised

Non-human identities get compromised through offboarding that never revokes a credential, third-party integrations holding live tokens, and secrets that were never rotated. What makes them attractive is structural rather than exotic. They hold standing privilege, they run continuously, they rarely have an owner positioned to notice something is wrong, and their activity looks exactly like the legitimate automation it is impersonating.

Standing privilege and secrets sprawl

Every non-human identity holding permissions it does not currently need widens the attack surface, because the credential stays valid whether or not anything is using it. Stolen non-human credentials are also a direct route to lateral movement, since a service account that already talks to five systems is a ready-made path between them. The population concentrates where direct oversight is thinnest, which is why cloud security and non-human identity programs keep converging.

Secrets sprawl is the measurable part of the problem. The fifth edition of the State of Secrets Sprawl report, published on 17 March 2026, detected 28,649,024 new secrets in public GitHub commits during 2025, a 34% year-over-year increase, including 1,275,105 secrets belonging to AI-related services, up 81% year over year (GitGuardian). Those are credentials for identities somebody provisioned and nobody tracked, and credential theft that begins in a public repository requires no intrusion at all.

Third-party exposure compounds it. Verizon reports that third-party involvement in breaches is up 60% from last year's dataset, with breaches involving a third party now accounting for 48% of all breaches (Verizon newsroom). Its 2026 executive summary adds that exploitation of vulnerabilities "has risen to 31% in this year's reporting dataset" as the most common initial access vector (Verizon 2026 DBIR executive summary). The full report puts its in-scope incident window at 1 November 2024 to 31 October 2025. A supply chain attack reaching an integration's tokens reaches everything those tokens can touch.

What three verified incidents show

Table: Three verified incidents, each demonstrating a different way a non-human identity fails, with the root cause and the lesson it establishes.

Mapping the OWASP Non-Human Identities Top 10 to real incidents

The OWASP Non-Human Identities Top 10 runs to exactly ten entries, NHI1 through NHI10. Mapping them onto verified incidents separates the risks that are theoretical from the ones that have already produced consequences.

Table: Five entries from the OWASP Non-Human Identities Top 10 (2025), each mapped to a verified incident that instantiates it.

The five entries not mapped above are NHI4:2025 Insecure Authentication, NHI6:2025 Insecure Cloud Deployment Configurations, NHI8:2025 Environment Isolation, NHI9:2025 NHI Reuse, and NHI10:2025 Human Use of NHI (OWASP). That last entry is the one most often dropped from summaries of the list.

In MITRE ATT&CK terms, stolen API keys, OAuth tokens, and signing keys are obtained under TA0006 Credential Access. A naming note for anyone mapping older detection logic: the Enterprise matrix at v19.2 carries 15 tactics, and "Defense Evasion" is no longer among them, having been retired in v19 and superseded by TA0005 Stealth and TA0112 Defense Impairment.

The same pattern turns up in vulnerability records. CVE-2026-12564, published on 18 August 2026, describes a credential plugin in which an authenticated attacker holding credential-creation privileges can cause a controller pod's Kubernetes service account token to be read and sent to an attacker-controlled URL. The CNA scored it 9.6 critical, and NVD had not published its own score at the time of writing (NVD).

How to detect and contain non-human identity compromise

Detecting non-human identity compromise means baselining what each machine principal normally does and alerting on deviation, because the credential is valid and nothing about the authentication itself looks wrong. Containment then means revoking first and resolving production dependencies second, a decision most teams have not made in advance. That makes this a SOC operations problem as much as an identity governance one.

The gap is worth stating precisely rather than broadly. Guidance on non-human identity capabilities and on the ordering of response steps exists, and this page credits it below. What no ranking page supplies, and what even the category's own standards body does not, is SOC-facing triage criteria or a named, sequenced containment playbook. That is the layer this section adds.

Why human-centered detection signals do not fire on non-human identities

Human users access systems predictably, from particular locations or at particular times of day, and much of identity detection is built on that predictability. Non-human identities do not exhibit those physical behavior patterns, which is why impossible travel, the canonical example, is described by the Cloud Security Alliance as a pattern "centered around humans, but not for an NHI" (Cloud Security Alliance). Detections inherited from the human population fail quietly here. They do not misfire, they never fire.

Five capabilities replace them. Continuous detection and discovery finds identities nobody registered. Identity graphs map assumed-role chains and delegated trust, which create transitive privilege-escalation paths. Behavioral baselining establishes normal for each identity. Real-time detection covers first-time access to customer data, suspicious updates, and mass secret downloads. Incident response closes the loop. The function itself is identity threat detection and response, and identity behavior analytics supplies the modeling underneath.

Triage criteria for a non-human identity alert

Work the alert against these eight questions, ordered by how much each one moves the verdict.

1. Does the identity have a named human owner? Nobody can confirm the activity was expected.
2. Is the behavior outside the identity's established baseline? A workload doing a sixth thing after two years of five is the signal.
3. Is this a first-time access to a sensitive data store? The highest-value deviation available on a long-lived identity.
4. Is the credential long-lived or beyond its rotation interval? Rotation debt widens the window a stolen credential still works in.
5. Does the identity hold standing privilege beyond its function? Over-permission turns a small compromise into a large blast radius.
6. Is the identity reachable from a third-party integration? Third-party tokens are first-party exposure, as Salesloft Drift showed.
7. Does the identity graph show a transitive path to higher privilege? Assumed-role chains let unremarkable identities reach remarkable places.
8. Is there evidence of mass secret retrieval? Bulk reads from a vault are rarely normal automation.

‍

‍

A containment sequence, and the revoke-versus-break-production decision

The Cloud Security Alliance supplies the ordering, and it is sound. On detection, revoke compromised tokens and access keys first to sever attacker access. Then isolate affected workloads and scope the blast radius through identity graph traversal. Then automate recovery, including replacement credentials, only after the environment has been verified clean, retaining human validation for high-severity or ambiguous incidents so fresh secrets are not issued into a still-compromised context.

What that ordering assumes, and does not supply, is the decision layer beneath it. Three questions need answering before an incident rather than during one. Who owns the revoke decision when the identity has no named owner? What is the fallback when revoking breaks a production dependency? How do you stage revocation for a service account whose consumers are unknown?

The trade-off is not hypothetical. In the 2026 SANS State of Identity Threats and Defenses Survey of more than 500 security professionals globally, 92% fail to rotate machine credentials on a 90-day cycle, fearing that this might break service accounts (Infosecurity Magazine). A workable staging answer narrows scope before it cuts access: strip entitlements first, watch what breaks while the credential is still live, then revoke.

Revocation also has to reach the token layer. The FBI's advisory on malicious connected apps notes that authorizing one bypasses defenses such as multi-factor authentication, password resets, and login monitoring, and that because OAuth tokens are issued by the platform itself, activity from the malicious app can look like a trusted integration. In the Drift compromise, containment took that form: on 20 August 2025 all active access and refresh tokens for the application were revoked (FBI FLASH).

How fast is fast enough?

One publisher supplies both a target and a measurement, in the same unit and for the same action, which makes the pairing unusually clean. Its IAM working group offers an illustrative target of "less than 24 hours for remediation to contain compromised identities before adversaries achieve lateral movement." That is a goal for a mature program, not an observed benchmark.

Measured against it, in the vendor-sponsored 2026 survey of 383 practitioners, nearly one-quarter (24%) of organizations take more than 24 hours to rotate or revoke a credential after a potential exposure, and 30% take over a day to triage a high-severity credential leak (Cloud Security Alliance). Read that second figure carefully. It measures how fast teams triage, not what they triage on.

What evidence to preserve

Treat non-human identity telemetry as a retained, monitored control rather than an incidental artifact. Coupang is the strongest available argument. Regulators ordered preservation of access logs, and six days later the company manually deleted approximately six months of web access logs. Roughly 13% of the logs covering the attack period were lost, "making it impossible to identify all affected victims," and the commission referred the company for criminal prosecution over the destruction of evidence (The Record).

How to manage the non-human identity lifecycle

Managing non-human identities means discovering them, giving each one a human owner, and shortening the life of every credential. The stages run in order.

1. Discover every non-human identity across cloud, SaaS, and on-premises
2. Assign a named human owner to each identity found
3. Scope entitlements down to what the identity actually uses
4. Vault the credential and automate its rotation
5. Certify the inventory on a recurring review cycle
6. Decommission the identity when its purpose ends

Discovery, ownership, and inventory

Discovery comes first because nothing else works on a population you have not enumerated, and it has to span cloud, SaaS, and on-premises estates rather than one of the three. Ownership comes second, and it is the step most programs skip. In the same vendor-sponsored 2026 survey of 383 practitioners, 51% of organizations reported no clear ownership or accountability as a most significant pain point (Cloud Security Alliance). A certifiable inventory follows from those two. Standing privilege is also where privileged access monitoring and non-human identity work meet, and zero trust is the governing model, because it grants nothing on the strength of location or a prior authentication.

Rotation and secrets management

Three independent measurements point the same direction from three different starting points. They must never be averaged, merged, or subtracted, because no two of them share a denominator.

Table: Three independent measurements of credential rotation, drawn from an illustrative target, a self-report, and vendor telemetry. Every row carries a different denominator, so these figures must never be averaged, merged, or subtracted.

The telemetry row is a 2025 edition and is aging, and it reflects one vendor's own customer base rather than the market. Even so, convergence from a target, a self-report, and telemetry is stronger evidence than any one of the three alone.

Short-lived workload identity with SPIFFE and SPIRE

The standards-based answer to long-lived secrets is to stop having them. The Secure Production Identity Framework for Everyone (SPIFFE) is a set of open-source specifications for bootstrapping and issuing identity to services across dynamic and heterogeneous environments, using short-lived identity documents fetched through a simple API. SPIRE is the SPIFFE project's implementation of those specifications.

Four concepts carry the model. A SPIFFE ID is a URI-formatted name for a workload. An SVID, or SPIFFE Verifiable Identity Document, is the credential proving it, in X.509 or JWT form. The Workload API is how a workload fetches its own SVID without holding a static secret. A trust domain is the boundary inside which those identities are issued and trusted. Documentation currently sits at v1.15.2 (SPIFFE). Governance is settled: SPIFFE was accepted into the Cloud Native Computing Foundation on 29 March 2018, moved to Incubating on 22 June 2020, and graduated on 23 August 2022 (CNCF).

It belongs here because short-lived, attested workload identity removes standing credentials entirely, which is the structural answer to NHI7:2025 Long-Lived Secrets. Identity fabrics carry their own bugs, though. CVE-2026-18677, published on 12 August 2026, describes a service mesh in which a dataplane presenting a tags-bound token could register with an arbitrary workload label and obtain another workload's SPIFFE identity, scored 6.0 medium by the CNA and unscored by NVD at the time of writing (NVD).

Metrics that show risk reduction

Almost nothing in this field publishes measured benchmarks, so treat program targets as goals rather than as observed performance.

Table: Program targets published by the Cloud Security Alliance, with a measured comparator supplied only where the unit and the action match. The source's own caveat: "The targets presented here are illustrative goals for mature NHI security programs and should be adjusted based on organizational risk, NHI criticality, and operational requirements." They are not observed benchmarks.

Non-human identity security and compliance

NIS2 and DORA reach non-human identity through access control and third-party ICT risk rather than by naming it.

Table: How the two principal EU instruments reach non-human identity, and the exact article text each hook rests on.

Article 21(2) of NIS2 enumerates ten measures, (a) through (j), but the framing clause matters more than the count. The measures "shall be based on an all-hazards approach ... and shall include at least the following," which makes the ten a floor rather than a closed list. Note also what Article 21(2)(j) does not do. Because it ends "where appropriate," NIS2 does not unconditionally mandate multi-factor authentication. Member States had until 17 October 2024 to adopt and publish the transposing measures, and were to apply them from 18 October 2024 (European Commission).

Appendix G of the Cloud Security Alliance paper independently maps non-human identity practices across SOC 2, ISO 27001:2022, NIST SP 800-53 and NIST CSF, GDPR, HIPAA, PCI-DSS v4.0, DORA, and NIS2, landing least-privilege enforcement on Article 21(2)(i). Carry its caveat with it: "Mappings indicate alignment and do not guarantee certification." Broader compliance programs increasingly treat the non-human population as in scope by default.

Modern approaches to non-human identity security

The tooling landscape has organized into five vendor-neutral categories: discovery and inventory, secrets management and vaulting, entitlement and access governance, workload identity fabrics, and behavioral detection for machine principals. Most programs assemble two or three rather than buying one thing.

Evaluate on criteria rather than candidates. Ask how far discovery reaches across cloud, SaaS, and on-premises estates, and whether the tool maps ownership rather than merely listing identities. Check the breadth of credential types covered, and whether rotation automation accounts for production dependencies instead of assuming none exist. Ask whether behavioral detection is tuned for machine principals or inherited from human models, and confirm the evidence output is audit-ready, since identity threat detection and response work and compliance evidence draw on the same telemetry. The direction of travel is consistent: standing secrets are giving way to short-lived, attested workload identity.

How Vectra AI thinks about non-human identity security

Vectra AI starts from an assume-compromise premise. If a non-human identity can authenticate, it can be abused, and the real question is whether anyone would notice. The methodology is behavioral: machine principals need baselines built for machines, not detections inherited from humans.

‍