Non-human identities are outgrowing human IAM controls

At a glance

What this is: This is an explanatory analysis of non-human identities, their types, and why they create outsized security risk when credentials, ownership, and visibility are weak.

Why it matters: For IAM and NHI practitioners, the issue is that machine identities expand the attack surface faster than conventional human-centric controls can absorb.

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 article on what non-human identities are and why they are risky

Context

Non-human identities are machine accounts, secrets, tokens, certificates, and service principals that authenticate software, workloads, and automation. The governance gap is that these identities are created at speed, distributed across cloud and SaaS environments, and often lack the ownership and lifecycle controls that IAM teams rely on for people.

The article argues that NHIs are risky because they do not use MFA, are often long-lived, and can be tightly coupled to production workflows. That starting point is typical in modern cloud environments: the risk is not that teams ignore NHIs, but that existing identity processes were built for human users and do not scale cleanly to machine access.

Key questions

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

A: Start with a complete inventory, then assign each machine identity an owner, purpose, scope, and expiry. After that, enforce least privilege, automate rotation, and monitor for unusual use. Governance fails when NHIs are treated as static secrets instead of living identities with a lifecycle.

Q: Why do non-human identities create more risk than many human accounts?

A: They are often long-lived, over-privileged, and poorly monitored, while also lacking MFA and behavioral oversight. That combination gives attackers durable access if a secret is exposed. The real risk is not volume alone, but the ease with which one credential can unlock many systems.

Q: What is the difference between NHI rotation and secrets rotation?

A: Secrets rotation changes the credential material, while NHI rotation governance also includes ownership, scope, dependency checks, and retirement. Rotating a secret without understanding the identity behind it can break production or leave the underlying access path intact.

Q: When should organisations replace long-lived NHI credentials with short-lived ones?

A: Whenever the application architecture can support it without disrupting production. Short-lived credentials are most effective when services can re-authenticate cleanly and dependencies are known. If rotation is unsafe today, first build visibility and test coverage so the move reduces risk instead of creating outages.

Technical breakdown

Why NHI credentials fail human-centric IAM assumptions

Human IAM depends on interactive authentication, user accountability, and routine review. NHIs break that model because a service account or API key often acts autonomously, without a person present to approve each access event. The authentication material can be the identity itself, which means the secret, token, or certificate becomes both proof and privilege. That creates a different control problem: compromise is silent, rotation can break dependent systems, and ownership is often spread across DevOps, application, and platform teams. Practical implication: treat NHI lifecycle control as an engineering dependency, not just an IAM policy issue.

Practical implication: inventory machine identities by application and owner before you attempt to change credentials or permissions.

Credential sprawl, privilege, and rotation risk in NHI estates

Credential sprawl occurs when NHIs are created for a narrow task and then left active long after the task changes. Over time, permissions widen, dependencies multiply, and rotation becomes harder because no one knows what will fail. This is why over-privileged service accounts and long-lived tokens are such a persistent problem. The technical failure mode is not just theft. It is the combination of excessive scope, poor visibility, and weak expiry discipline that turns one credential into a durable access path. Practical implication: prioritize short-lived credentials and map dependencies before tightening access.

Practical implication: shorten token lifetimes and rehearse rotation in non-production systems before enforcing it in production.

How AI and automation increase non-human identity density

Automation increases the number of identities created per workflow, especially when CI/CD pipelines, cloud services, and AI-driven processes each need their own credentials. That density matters because every new NHI is another authorization surface, another secret to protect, and another lifecycle to manage. When AI systems call tools or APIs, they add execution authority to an already complex identity model. This is where NHI governance begins to overlap with agentic AI security: the problem is not only who can log in, but what autonomous software can do once authenticated. Practical implication: design governance around machine-to-machine access patterns, not user login patterns.

Practical implication: apply the same ownership and approval discipline to AI agents that you already expect for privileged workloads.

Threat narrative

Attacker objective: The attacker wants durable, low-noise access to systems and data by abusing machine credentials that look legitimate to normal monitoring.

1. Entry via exposed API keys, OAuth tokens, or service account secrets left in repositories, logs, or integrations.
2. Escalation through over-privileged NHI permissions that let the attacker access adjacent systems without human approval.
3. Impact through persistent machine-to-machine access to production data, cloud resources, or automation workflows.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

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 lifecycle problem, not a point-in-time inventory exercise. The article correctly frames NHIs as dynamic, programmatic, and widely distributed. That combination means discovery alone is insufficient unless it is linked to ownership, expiry, rotation, and offboarding. Practitioners should assume that unmanaged growth will continue unless the lifecycle is enforced at creation and at change time.

Credential sprawl is really identity blast radius. Once a token, key, or certificate is widely reused, the security question changes from whether a secret can be found to how far it can be used. That is why access scope, dependency mapping, and expiry matter more than simple secret counts. Practitioners should evaluate blast radius, not just credential volume.

AI agents intensify the NHI problem because execution authority and identity are converging. When software can choose actions and call tools on its own, the old boundary between workload identity and privileged automation gets thinner. That does not create a new IAM discipline so much as it exposes the limits of human-first IAM models. Practitioners should align AI governance with NHI governance from the start.

Short-lived credentials only help when the surrounding operational model can tolerate them. The article points to a real tension: teams need to reduce standing access, but they also need enough mapping and telemetry to avoid breaking production. That makes dependency visibility a prerequisite for safer rotation. Practitioners should use rotation as a controlled change process, not as an isolated security toggle.

NHI ownership debt: this is the backlog of machine identities with unclear owners, unclear consumers, and unclear retirement paths. The debt accumulates when developers, platform teams, and IAM teams each assume someone else will clean it up. Practitioners should assign accountable owners and make retirement part of normal change management.

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.
• From our research: 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• From our research: Use 52 NHI Breaches Analysis to trace how exposure, privilege, and missed rotation become repeatable incident patterns.

What this signals

NHI ownership debt will be the operational bottleneck for most programmes before tooling becomes the issue. Discovery is necessary, but the next constraint is accountable ownership for machine identities that were never designed to have a clear human steward. Teams that cannot tie identities to systems and change owners will struggle to rotate safely or retire anything at all.

With 85% of organisations lacking full visibility into third-party vendors connected via OAuth apps, the governance gap is already larger than many teams assume. That number points to a structural issue in supplier and integration oversight, not just an access review problem. Practitioners should expect NHI governance to become a procurement and third-party risk question, not only an IAM question.

As machine identities and AI-driven workflows multiply, the practical control point shifts toward dependency mapping, short-lived access, and continuous verification. NIST Cybersecurity Framework 2.0 is useful here because the problem spans identify, protect, detect, respond, and recover. Teams that integrate NHI controls into change management will be better positioned to absorb autonomous systems without losing visibility.

For practitioners

• Create an authoritative NHI inventory Map service accounts, API keys, tokens, certificates, and workload identities to application owners, business purpose, and expiry date. Include where each credential is stored and which systems depend on it.
• Reduce standing privilege on machine identities Replace broad, persistent permissions with narrowly scoped roles and task-specific access. Review inherited permissions for cloud workloads, CI/CD pipelines, and SaaS integrations.
• Automate rotation with dependency checks Use scheduled rotation for long-lived secrets, but pair it with dependency mapping and test runs so production workflows do not fail when credentials change.
• Baseline NHI behaviour and alert on drift Capture normal authentication patterns, resource access, and source locations for high-value NHIs, then alert when a credential touches unfamiliar systems or unusual geographies.

Key takeaways

• Non-human identities expand enterprise risk because they are created at scale, rarely governed end to end, and frequently tied to secrets that become the identity itself.
• The data points to a confidence and visibility gap, which means many organisations are managing NHIs with less certainty than they have for human identities.
• The right response is lifecycle governance: ownership, least privilege, rotation discipline, dependency mapping, and monitoring that can absorb production realities.

Key terms

• Non-Human Identity: A non-human identity is a digital identity used by software, services, or automation to authenticate and access resources. It typically relies on secrets, tokens, certificates, or federated credentials, and it needs lifecycle governance just like a human account, often with even less tolerance for mistakes.
• Credential Sprawl: Credential sprawl is the uncontrolled accumulation of machine secrets, keys, and tokens across systems, teams, and environments. It usually starts with a single use case and ends with overlapping permissions, unclear ownership, and a larger attack surface than the organisation expected.
• Identity Blast Radius: Identity blast radius is the amount of damage an attacker can do after compromising a single identity. For NHIs, it is shaped by scope, reuse, dependency depth, and whether the credential unlocks downstream systems without additional checks.
• Workload Identity: A workload identity is a machine identity assigned to an application, container, service, or compute instance so it can authenticate to another system. It is a core part of cloud and automation security because it connects runtime access to policy, telemetry, and rotation discipline.

Deepen your knowledge

NHI lifecycle governance, ownership, and credential rotation are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is building controls for service accounts, API keys, and workload identities, 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.