The Non-Human Identity Explosion

Non-human identities (NHIs), including API keys, service accounts, tokens, certificates, and AI agents, now outnumber human identities in enterprise environments by approximately 82 to 1, yet most security tools, processes, and governance frameworks were built for people. Machines authenticate with secrets, not passwords and MFA prompts, and they proliferate at software speed while organizations still manage them at human speed. The recommended action: inventory every NHI across your environment, assign each a named owner, apply least privilege, replace long-lived static secrets with short-lived automatically rotating credentials, and automate decommissioning so retiring a service also retires its credentials.

Quick Answer: What Is the Non-Human Identity Explosion and Why Does It Matter?

The NHI explosion refers to the rapid accumulation of machine credentials across enterprise environments, including API keys, service accounts, OAuth tokens, TLS certificates, SSH keys, cloud IAM roles, and AI agent identities, that now vastly outnumber human accounts. In most organizations, machines outnumber people 82 to 1. It matters because these credentials are the attack surface attackers now prefer: they have no MFA prompt, no HR offboarding process, no expiry mechanism, and they are routinely over-permissioned. When a machine credential is compromised, the attacker inherits all its access, often administrative access to production systems, with no human behavior pattern to trigger detection. The 2026 compliance environment has sharpened this urgency: PCI DSS 4.0 (Requirements 8.6.1-8.6.3, fully enforceable since March 2025) explicitly requires tight management of application and system accounts, and shortening TLS certificate lifetimes (200 days now, 47 days by 2029) mean certificate automation is no longer optional.

What Is a Non-Human Identity?

A non-human identity is a digital credential used by software rather than a person. A human proves identity with a password and perhaps a fingerprint. Software cannot do that, so it uses a secret instead: a token, an API key, a certificate, or a key. The receiving system checks the secret and grants access. Common NHI types include:

• Service accounts: credentials that allow an application to connect to a database, message queue, or another service without human login.
• API keys and OAuth tokens: secrets that authorize one application to access another’s data or functionality. For example, a SaaS tool reading records from your CRM.
• Cloud IAM roles: identity constructs in AWS, Azure, or Google Cloud that allow a workload (a Lambda function, a VM, a container) to access other cloud resources without static credentials.
• CI/CD pipeline credentials, SSH keys, and TLS certificates: secrets securing machine-to-machine connections in build and deployment pipelines.
• AI agents: autonomous software systems that call APIs and take actions on their own. This is the newest and fastest-growing NHI category, with each agent requiring its own credential.

The term machine identity is closely related. Machine identity typically points to credentials for devices and workloads; NHI is the broader term also covering software-to-software connections and AI agent credentials. For governance purposes, treat them as one problem space.

Why Are Non-Human Identities Growing So Fast?

NHIs are not new. What changed is the rate at which they multiply. Three forces caused it.

1. Cloud-native architecture decomposed applications: modern applications run as many small services rather than one monolithic codebase. Each microservice needs its own identity to authenticate to the others. With containers and Kubernetes, services start and stop continuously, creating and discarding hundreds of identities per day for a single application.
2. Automation creates credentials programmatically: every pipeline, integration, and infrastructure-as-code script can provision new credentials automatically. Some NHIs even create other NHIs, compounding the accumulation problem.
3. AI agents added exponential fuel: modern AI agents do not just answer questions. They take actions, call APIs, and access sensitive systems. Each agent is a new identity requiring credentials. Microsoft reported customers created over one million custom AI agents across SharePoint and Copilot Studio in a single quarter. Many agents are provisioned with delegated human credentials, making attribution of actions to a specific person difficult.

The result: machines create identities at software speed while organizations manage them at human speed. Gartner expects the gap between machine and human identity counts to continue widening as cloud adoption and AI agent deployment accelerate.

The Governance Gap: Why Human Controls Fail on Machines

The core problem is that identity tools were built for people. NHIs do not behave like people. That mismatch creates three compounding problems.

1. Human controls do not apply: MFA requires a phone or fingerprint; a service account has neither. SSO and HR onboarding processes handle employees, not API keys. So NHIs bypass the strongest human-facing security controls.
2. No unified inventory: each platform maintains its own credential store. AWS has IAM, GitHub has personal access tokens, databases have service accounts, SaaS platforms have integration tokens. No single view of all NHIs typically exists. When the person who created an NHI changes roles or leaves, the credential persists with full access and no owner. Research found 91% of former-employee tokens remain active after departure.
3. Permissions pile up and are never reviewed: NHIs are typically provisioned with broad access because it is faster to configure. Nobody reviews machine permissions quarterly the way access reviews target human accounts. Studies show 97% of NHIs carry excessive privileges, and 88% of organizations treat only human accounts as privileged, missing the machine identity attack surface entirely.

NHI Threat Model: How Attackers Exploit Machine Identities

Attack scenario	How it works	Why NHIs make it easier	Primary control
Credential theft from code repositories	Attacker finds API keys or tokens committed to a public or private code repository	44% of tokens are found exposed in code commits, tickets, and chat tools; no human password hashing protects them	Secret scanning in CI/CD pipelines; secrets manager instead of hardcoded credentials; immediate rotation on suspected exposure
Orphaned account exploitation	Attacker discovers a service account or token that is still active but has no current owner, monitoring, or review	91% of former-employee tokens remain active; orphaned accounts generate no behavioral alerts because no baseline exists	Automated decommissioning tied to application lifecycle; regular cleanup scans removing NHIs with no recent usage or owner
Lateral movement via over-privileged service accounts	Attacker compromises one service account and uses its broad permissions to access other systems	97% of NHIs have excessive privileges; a single compromised service account can reach production databases, secrets stores, and admin APIs	Least-privilege scoping for every NHI; just-in-time access for elevated operations; network segmentation limiting NHI reachability
Supply chain attack via third-party integration	A compromised third-party tool or SaaS integration uses its granted NHI permissions to access the organization’s data	Third-party integrations receive NHIs with persistent, broad access; the organization cannot audit the third-party’s own security posture	Inventory of all third-party NHIs with access reviews; scope grants to minimum required; revoke integrations that are no longer actively used
AI agent over-privilege exploitation	Attacker compromises or manipulates an AI agent with administrative-level access, enabling data exfiltration at machine speed	Agents are often provisioned with delegated human credentials or broad access; CSA found 92% of security professionals concerned about AI agent security	Apply least privilege to every AI agent identity; require human oversight for high-impact actions; ability to disable any agent immediately

NHI Risk Categories: The OWASP Non-Human Identities Top 10

In 2025, OWASP published its Non-Human Identities Top 10, ranking the biggest NHI risks by impact. The list provides the industry’s clearest prioritization framework for NHI security programs. The number one risk is Improper Offboarding (orphaned credentials). The full list covers:

1. Improper Offboarding: credentials that remain active after the service, project, or person they belong to is gone.
2. Secret Leakage: tokens and keys that end up in source code, logs, configuration files, or chat tools.
3. Vulnerable Third-Party NHI: integrations with external tools that carry NHI access into your environment.
4. Insecure Authentication: reliance on legacy or weak authentication mechanisms for machine-to-machine connections.
5. Overprivileged NHI: service accounts and tokens with more access than their function requires.
6. Insecure Cloud Deployment Configurations: static credentials in CI/CD pipelines rather than workload identity federation.
7. Long-Lived Secrets: credentials that never expire, maximizing the window an attacker has if they are stolen.
8. Environment Isolation: the same credential used across development, testing, and production environments.
9. NHI Reuse: the same identity or secret shared across different services or components.
10. Human Use of NHI: people using service accounts or machine credentials for manual tasks, blurring the audit trail.

The pattern is consistent: almost every risk traces back to secrets that live too long, too much privilege, and no clean way to retire an identity. Fix those three root problems and you address most of the list. For a detailed breakdown of each risk and its specific remediation, see our companion post on the Top 10 Non-Human Identity Risks.

How to Secure Non-Human Identities

1. Discover and inventory: run continuous scans across cloud, SaaS, and on-premises systems to find every NHI. Record each one in a central inventory with a named owner. Without visibility, no other control is meaningful.
2. Apply least privilege: give each NHI only the access its specific job requires. Restrict scope to the minimum: a specific API endpoint, a specific S3 bucket, a specific database table. Audit periodically and remove excess permissions.
3. Replace long-lived secrets with short-lived credentials: this is the single highest-impact improvement. The open SPIFFE standard (with its SPIRE reference implementation) gives each workload a short-lived cryptographic identity document (SVID) issued as an X.509 certificate or JWT, rotating automatically (often every hour by default). Stolen SVIDs are useless almost immediately. NIST SP 800-207A explicitly recommends SPIFFE for workload identity in cloud-native environments.
4. Use just-in-time access: grant permissions for a specific task and revoke them the moment the task completes. No permission lingers idle, removing the standing access that attackers exploit.
5. Automate decommissioning: retiring a service or application should automatically trigger revocation of its associated NHIs. Link NHI lifecycle to application and project lifecycle in the same way that HR offboarding triggers human account deprovisioning.
6. Monitor NHI behavior continuously: log all NHI authentication and access events. Alert on anomalies: an API key authenticating from an unexpected IP, a service account accessing a resource it has never touched, a token used outside its normal operating hours. These are often the first indicators of credential compromise.

Why This Matters Right Now in 2026

Two forces make NHI security a 2026 priority, not a future-state consideration.

AI agents are already being targeted. Gartner predicts that by 2028, 25% of enterprise breaches will trace back to AI agent abuse. Every AI agent is an NHI. Securing machine identities is the foundational prerequisite for safely deploying the AI tools that organizations are already building. The May 2026 six-agency guidance (CISA, NSA, and partners in Australia, Canada, the UK, and New Zealand) on Careful Adoption of Agentic AI Services requires least-privilege access, network segmentation, and rapid containment capability for every AI agent, all of which are NHI governance controls.

Certificate lifetimes are shrinking sharply. TLS certificates are machine identities, and as of March 15, 2026, public TLS certificates live for a maximum of 200 days (down from 398). This drops to 100 days in 2027 and 47 days in 2029. The renewal volume at 47-day lifetimes is approximately eight times higher than at 398-day lifetimes. Manual tracking and renewal will fail at that frequency; automated certificate lifecycle management is no longer optional. Note this applies to public TLS certificates; internal PKI sets its own limits, but the operational pressure to automate is identical.

Compliance is catching up. NIST SP 800-207 (Zero Trust Architecture) explicitly requires machine identities to be governed with the same rigor as human identities. PCI DSS 4.0 Requirements 8.6.1 to 8.6.3, fully enforceable since March 2025, require tight management of application and system accounts, prohibition of hard-coded passwords, and protection of service account credentials from misuse.

Limitations and Implementation Challenges

• Short-lived credentials require automation infrastructure: replacing static secrets with SPIFFE/SPIRE or cloud workload identity requires deploying and maintaining the identity issuance infrastructure. This is a meaningful investment but is the correct architectural direction; the alternative (permanent static secrets) creates unlimited exposure windows.
• Legacy applications may not support dynamic credential injection: some older applications read credentials from static configuration files at startup and cannot be reconfigured to accept dynamically injected short-lived credentials without code changes. These applications require a migration plan rather than an immediate switch.
• Third-party NHIs are not fully within your control: you can audit and scope the permissions you grant to third-party integrations, but you cannot directly govern how the third party handles the credential on their side. Vendor security questionnaires and integration risk reviews fill this gap partially.
• Discovery is ongoing, not one-time: NHIs are created continuously by automation. A one-time discovery scan provides a point-in-time snapshot; continuous scanning is required to keep the inventory current as new credentials are provisioned daily by pipelines, orchestration platforms, and development tools.

How Encryption Consulting Can Help

Certificates are the machine identity type that most organizations already depend on at scale, and they are exactly the ones now exploding in number and shrinking in validity period. CertSecure Manager addresses the certificate dimension of NHI security directly:

• Discovery and centralized inventory: CertSecure Manager discovers certificates across cloud, on-premises, and hybrid systems and consolidates them into a single inventory with owner assignment for each. Previously unknown or untracked certificates surface and are included in governance.
• Zero-touch automated renewal: certificates renew automatically before expiry. At 47-day certificate lifetimes in 2029, zero-touch renewal is not a convenience feature but a operational requirement; manual renewal at that frequency will cause outages.
• Policy enforcement and least privilege: each team manages only its own certificates; only approved algorithms and key sizes are permitted. This implements the least-privilege and governance controls that NHI security requires for the certificate inventory.
• Full audit trail: all certificate lifecycle events are logged, meeting PCI DSS 4.0 Requirements 8.6.1-8.6.3 and NIST SP 800-207 requirements for machine identity governance evidence.

For the broader NHI governance picture, including service accounts, API keys, AI agent credentials, and encryption strategy, our Encryption Advisory Services assess where you stand today and build a roadmap that covers the full machine identity and encryption program, not just certificates alone.

Conclusion

Non-human identities are now the largest and fastest-growing identity category in enterprise environments, and AI agents are accelerating that growth. The governance gap is structural: human IAM tools, MFA, and HR processes cannot manage machine credentials. The attack surface created by over-privileged, long-lived, unmonitored NHIs is one attackers already know how to exploit.

The response is operationally straightforward: find every NHI, assign it an owner, limit its permissions to what it genuinely needs, give it short-lived credentials that rotate automatically, monitor its behavior, and retire it cleanly when its purpose ends. The organizations that get this right in 2026 will not be the ones that responded to a breach — they will be the ones that made machine identity a first-class governance concern before a breach occurred. If you want to assess your current NHI posture and build a governance program that scales, contact Encryption Consulting.

Frequently Asked Questions

What is a non-human identity (NHI)?

An NHI is a digital credential used by software rather than a person: API keys, OAuth tokens, service accounts, TLS certificates, SSH keys, cloud IAM roles, and AI agent credentials. Software authenticates with secrets rather than passwords and MFA prompts. Machine identities is a closely related term; NHI is the broader category also covering AI agents and software-to-software connections.

Why do non-human identities outnumber human identities?

Three forces multiplied them: cloud-native microservice architectures that require a separate identity per service; automation that creates credentials programmatically at pipeline speed; and AI agents that each require their own credential and are being deployed by the millions. Machine identities outnumber human ones by 82 to 1 in typical enterprises, and Gartner expects this ratio to grow.

What is the governance gap in NHI security?

Three dimensions: human controls like MFA and SSO do not apply to machines; no unified inventory exists across platforms, so credentials accumulate with no single owner view; and NHIs are chronically over-privileged because broad access is faster to provision and no one reviews machine permissions. 97% of NHIs carry excessive privileges; 88% of organizations do not classify machine accounts as privileged.

What is SPIFFE and how does it help?

SPIFFE (Secure Production Identity Framework for Everyone) is an open standard that issues each workload a short-lived, cryptographically verifiable identity document (SVID), issued as either an X.509 certificate or JWT, through its SPIRE implementation. SVIDs rotate automatically (typically every hour), so stolen credentials expire almost immediately. NIST SP 800-207A explicitly recommends SPIFFE for cloud-native workload identity.

Why are TLS certificate lifespans shrinking and what does it mean for NHI management?

The CA/Browser Forum mandated reductions: 200 days maximum from March 2026, 100 days in 2027, 47 days by 2029. At 47-day lifetimes, renewal volume is approximately eight times higher than at 398-day lifetimes. Manual management fails at that frequency; automated certificate lifecycle management is required. TLS certificates are machine identities, so this is an NHI governance problem, not just an IT operations problem.

What are the most important controls for securing non-human identities?

Continuous discovery and inventory with named owners; least-privilege scoping of all NHI permissions; replacing static long-lived secrets with short-lived automatically rotating credentials (SPIFFE, cloud workload identity, certificate automation); just-in-time access for elevated operations; automated decommissioning tied to application lifecycle; and behavioral monitoring with anomaly alerting.