Non-human identities outnumber humans and expand enterprise risk

At a glance

What this is: This is an explanation of non-human identities and the security risks they create at enterprise scale.

Why it matters: It matters because IAM and NHI teams need controls for machine access that human-focused identity programs do not adequately cover.

By the numbers:

• non-human identities now outnumber human users by 45 to 1 in the modern enterprise
• some organizations seeing ratios as high as 100 to 1

👉 Read Oasis Security's overview of non-human identities and their security risks

Context

Non-human identity, or NHI, is the access layer used by applications, services, workloads, and automation to authenticate without a person in the loop. The governance problem is that these identities are often created outside central IAM workflows, then left with long-lived secrets, broad permissions, and weak ownership. For teams building NHI governance, the issue is not just volume. It is that machine credentials can persist, spread, and operate faster than the controls built for human users.

The source article argues that NHIs are now foundational to cloud-native and AI-enabled environments, and that is broadly typical of enterprise reality. What is atypical is the degree to which organisations still treat them as an extension of human identity management rather than a separate control domain. That mismatch is where exposure accumulates, especially in hybrid and multi-cloud estates.

Key questions

Q: How should security teams govern non-human identities at scale?

A: Security teams should treat non-human identities as first-class identities with owners, scopes, expiry, and review dates. The practical model is continuous inventory plus least privilege plus automated rotation, backed by dependency mapping so changes do not break production systems. Without that combination, NHI governance becomes reactive and incomplete.

Q: When does credential rotation create more risk than it reduces?

A: Rotation becomes risky when teams do not understand which applications depend on a credential or how widely it is used. In those cases, blind rotation can disrupt production and make security teams hesitate to act again. The answer is not to avoid rotation, but to map dependencies first and automate change control.

Q: What is the difference between human identity controls and NHI controls?

A: Human identity controls rely on interactive authentication, user challenge, and behavioural oversight. NHI controls must manage secrets, certificates, tokens, service accounts, and workload permissions at machine speed. The difference is operational: machine identities need lifecycle governance and runtime visibility, not just login protection.

Q: Why do non-human identities complicate zero trust architecture?

A: Zero Trust assumes every access request must be verified, but NHIs often operate through persistent credentials, embedded trust, and automated workflows. That means trust can spread across systems unless access is continuously checked and tightly scoped. NHI governance is therefore a required part of any real Zero Trust programme.

Technical breakdown

Why non-human identities create a different attack surface

NHIs authenticate through secrets, certificates, tokens, API keys, and service accounts rather than interactive login flows. That means there is no MFA prompt, no user challenge, and often no clear human owner to receive alerts or approve changes. In practice, the risk comes from autonomous operation at scale. Once a credential is issued, it can be reused by applications, scripts, pipelines, and connected services until rotation or revocation occurs. The control problem is therefore lifecycle-driven: discovery, ownership, scope, expiry, and continuous review all matter at once.

Practical implication: Treat every machine credential as a governed identity with an owner, expiry, and review cadence.

Credential sprawl, over-privilege, and the failure of static trust

Credential sprawl occurs when machine credentials are created for projects, integrations, or workloads and then forgotten. Over time, these identities often accumulate permissions beyond the original use case, which increases blast radius if the secret is exposed. Static trust is the deeper architectural flaw: access remains valid even when the workload changes, the team changes, or the integration is no longer needed. The article’s examples reflect a common failure pattern in NHI security. Secrets outlive their business purpose, and the system rarely notices until there is a compromise or outage.

Practical implication: Map every credential to a business function, then shorten lifespan and reduce scope before exposure forces the change.

Why visibility gaps block safe rotation

Teams often avoid rotating or retiring NHIs because they do not know what will break. That is a dependency-mapping problem, not just a secrets-management problem. If a service account is embedded in production workflows, blind rotation can create service disruption, which pushes security teams to accept old credentials indefinitely. Effective NHI governance therefore needs visibility into where credentials exist, what systems depend on them, and whether they are still in use. Without that inventory, least privilege and rotation stay aspirational.

Practical implication: Build dependency maps before enforcing rotation so you can reduce exposure without breaking critical services.

Threat narrative

Attacker objective: The attacker wants durable machine-level access that can be reused across systems without repeated authentication friction.

1. Entry occurs when exposed API keys, service account secrets, or OAuth tokens are recovered from code repositories, logs, or third-party integrations.
2. Escalation follows when the compromised NHI has broad permissions or reusable access across cloud services, databases, or SaaS platforms.
3. Impact comes from persistent, automated access that attackers can use to move laterally, exfiltrate data, or alter configurations without triggering human login controls.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Non-human identity governance is now a core identity discipline, not an adjacent tooling problem. The article correctly frames NHIs as foundational to modern environments, but the governance implication is broader than secret hygiene. When machine identities outnumber humans by orders of magnitude, identity programmes that remain human-centric will under-control the highest-volume access layer. Practitioners should treat NHI governance as a first-class identity domain.

Ephemeral access without lifecycle control creates ephemeral trust debt. Short-lived tokens reduce some exposure, but they do not solve ownership, scope, dependency, or revocation at scale. If an organisation can mint credentials faster than it can inventory them, it has merely shifted risk into the runtime layer. The practitioner conclusion is to pair short-lived access with discovery and automated governance.

Dependency opacity is the real blocker to secure rotation. Most teams know that long-lived secrets are dangerous, but few can rotate them confidently because they lack system-to-identity dependency maps. That is why NHI programmes fail in operations, not in policy. Security leaders should reframe rotation as an observability and change-management problem as much as an access-control one.

Machine identity exposure will keep expanding as automation and AI agents proliferate. The article’s discussion of developers, pipelines, and cloud workloads points to a category that will only grow in volume and complexity. Each new automation layer adds credentials, entitlements, and implicit trust paths. Practitioners should expect the NHI control plane to become a permanent part of IAM architecture rather than a one-time project.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% reporting no or low visibility and 47% reporting only partial visibility.
• For a broader baseline on why this matters, see Ultimate Guide to NHIs , Why NHI Security Matters Now for the lifecycle controls that reduce long-lived identity risk.

What this signals

Ephemeral credential trust debt: shortening credential lifetime does not eliminate the governance burden if ownership, scope, and dependency data remain incomplete. For most programmes, the next maturity step is not more secrets tooling, but a control model that can answer who issued the identity, what it can reach, and what breaks if it changes.

With 72% of organisations saying they have experienced or suspect a non-human identity breach, the reader-level signal is clear: NHI risk is already inside the operating model. That shifts the priority from awareness to execution, especially for organisations still relying on ad hoc service account administration.

Teams that already use NIST Cybersecurity Framework 2.0 can fold NHI governance into identify, protect, detect, respond, and recover without creating a separate silo. The practical move is to connect discovery, rotation, and entitlement review to the same control objectives used for human identities, then measure the blast radius of every machine credential.

For practitioners

• Implement continuous inventory for all NHI credentials Track service accounts, tokens, certificates, API keys, and workload identities in one inventory, then assign an owner and business purpose to each record. Use that inventory to flag orphaned credentials and identities with no clear application dependency.
• Rotate long-lived secrets on a risk-based schedule Prioritise credentials with broad permissions, external exposure, or production reach, and automate rotation where dependency maps show low operational risk. For fragile systems, stage the change with validated rollback and monitoring.
• Reduce standing privilege for machine identities Replace broad, persistent permissions with narrow entitlements tied to the minimum workload function. Review service account scopes, OAuth app grants, and cloud roles together so privilege does not accumulate across platforms.
• Build dependency maps before decommissioning credentials Document which services, pipelines, and applications use each credential before revoking it. This lets security teams remove unused access while avoiding outages caused by hidden production dependencies.
• Align NHI controls to Zero Trust principles Require authentication, authorization, and continuous verification for machine access, then treat each workload identity as a trust decision rather than a network assumption. Use this model to reduce implicit trust between services.

Key takeaways

• Non-human identities create a machine-speed access problem that human-centric IAM controls do not fully solve.
• The hardest part of NHI security is not knowing that secrets are risky, but knowing what depends on them before you rotate or revoke them.
• Enterprises need continuous inventory, scoped privilege, and dependency mapping if they want to govern NHIs without disrupting production.

Key terms

• Non-Human Identity: A non-human identity is any digital identity used by software, services, devices, or automation to authenticate and access resources. It includes service accounts, API keys, tokens, certificates, and workload identities. These identities often operate at scale, which makes ownership, lifecycle control, and least privilege essential.
• Credential Sprawl: Credential sprawl is the uncontrolled growth of machine credentials across applications, pipelines, and cloud services. The risk is not only quantity, but forgotten secrets that remain active long after their original purpose has ended. In NHI programmes, sprawl usually correlates with weak inventory and weak ownership.
• Dependency Mapping: Dependency mapping is the process of identifying which systems, services, and workflows rely on a given identity or secret. It is critical for NHI rotation because teams need to know what will fail before they change credentials. Without it, security teams often delay remediation to avoid outages.
• Workload Identity: A workload identity is a machine identity used by an application, container, or service to authenticate to another system. It is usually short-lived or federated, but it still requires governance because its permissions can be broad and its behaviour can be hard to observe. Workload identity is a core NHI concept.

Deepen your knowledge

NHI lifecycle governance, credential rotation, and dependency mapping are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is moving from human-centric IAM to machine identity governance, it is worth exploring.

This post draws on content published by Oasis Security: What Are Non-Human Identities (NHIs) and Why Are They Risky? Read the original.