What’s broken with identity management for NHI sprawl

At a glance

What this is: The article argues that identity management is failing because NHI growth, privilege concentration, and lifecycle complexity outpace human-centric IAM and PAM controls.

Why it matters: It matters because security teams now need controls that work across human, NHI, and autonomous programmes without assuming identities are stable, visible, or manually governable.

By the numbers:

• 10-50x

👉 Read Oasis Security's analysis of what is broken in identity management for NHIs

Context

Identity management is breaking under NHI sprawl because many environments now contain far more machine identities than human users, while the controls still assume a person, a ticket, and a review cycle. In practice, service accounts, roles, tokens, keys, and secrets create access paths that are harder to inventory, harder to attribute, and much easier to leave behind than human accounts.

The governance gap is not just visibility. Existing IAM and PAM programmes were designed around identifiable people, central provisioning, and human verification factors, while NHI estates behave like distributed infrastructure with ownership, usage, and permission state spread across systems. That mismatch is why identity-first governance for NHIs has become a separate programme concern rather than an extension of traditional user IAM.

Key questions

Q: How should security teams inventory non-human identities across cloud and SaaS environments?

A: Start with ownership, runtime location, and privilege level, not just credential type. A usable inventory should map service accounts, API keys, tokens, roles, and certificates to the workload they support, the business service they enable, and the team that can revoke them. If you cannot answer those three questions, the identity is already outside governance.

Q: Why do secret managers not solve non-human identity governance on their own?

A: Secret managers protect stored credentials, but they do not establish who owns the identity, what it can reach, or whether it should still exist. Governance failures happen when teams treat vaulting as the end state. Access can remain standing, over-privileged, or orphaned even when the secret itself is encrypted and rotated.

Q: What breaks when NHI lifecycle management is missing?

A: Orphaned service accounts, stale tokens, and untracked privileges accumulate until teams cannot safely rotate or revoke them. The operational failure is not only exposure. It is also change risk, because administrators no longer know which workload depends on which identity. That is how routine maintenance turns into outage potential.

Q: Who is accountable when a privileged non-human identity causes a security incident?

A: Accountability should rest with the team that owns the workload, the identity platform, and the business service exposed by that access. In mature governance models, responsibility is shared but explicit, with named owners for provisioning, review, and revocation. If ownership is ambiguous, accountability has already failed before the incident begins.

Technical breakdown

Why NHI sprawl breaks human-centric IAM models

NHI sprawl emerges when service accounts, roles, tokens, keys, and certificates accumulate faster than teams can map them to owners and business functions. Human IAM assumes a relatively stable user population, clear onboarding and offboarding, and interactive authentication. NHIs do not behave that way. They are created by applications, pipelines, and cloud services, often without durable ownership metadata or a clear human approver. Once that happens, entitlement review loses context and access policy becomes incomplete by design.

Practical implication: inventory NHIs by ownership, purpose, and runtime location before trying to govern them through user-centric processes.

Why secret managers are not identity governance

A secret manager stores and rotates credentials, but it does not by itself answer who owns the identity, where it is used, what it can reach, or whether the access should still exist. That distinction matters because credential storage is only one control layer. Identity governance requires lifecycle state, access scope, dependency mapping, and revocation logic. Without those, a vaulted secret can still represent standing, high-risk access even when the credential itself is protected.

Practical implication: pair vaulting with ownership, dependency, and revocation controls so stored credentials do not become unmanaged standing access.

How autonomous workflows change the governance problem

The article points to AI-workflows and AI-powered services as a growth driver, which matters because machine-to-machine access is becoming more dynamic. When access is generated and consumed by software services at runtime, static permission models lose precision quickly. The underlying problem is not just count. It is that access decisions move closer to execution, while the governance model still expects a human to notice, certify, and remediate after the fact.

Practical implication: design controls that can trace runtime access decisions back to service ownership and execution context, not only to a provisioning record.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• 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

NHI sprawl is no longer a hygiene issue. It is a governance boundary problem. Once machine identities outnumber human identities by an order of magnitude, user-centric IAM stops describing the real attack surface. The result is not just more accounts, but more unowned access paths, more hidden privilege, and more places where accountability disappears. Practitioners should treat NHI inventory and lifecycle control as a separate governance plane, not a side task.

Secret storage is not the same thing as identity control. The article correctly separates vaulting from identity awareness, and that distinction matters operationally. A vaulted token can still be over-privileged, orphaned, or connected to a business process no one can safely change. That means secret managers reduce exposure of credentials but do not resolve ownership, access scope, or offboarding risk. Practitioners need to stop equating protected secrets with governed identities.

Attack surface inflation is being driven by architecture, not just bad administration. Hybrid cloud, microservices, and automated workflows create identity volume that conventional review processes were never sized to handle. The important point is that the problem scales with the operating model. If identity creation is embedded in deployment and automation pipelines, governance has to move upstream into the same operational path. Otherwise, controls arrive after the privilege is already live.

Identity-aware lifecycle management is now a prerequisite for resilient operations. The article’s warning about downtime during threat response or maintenance is the practical consequence of poor NHI visibility. When teams cannot see which identities support which workloads, they cannot safely revoke, rotate, or change them. That makes lifecycle governance a resilience issue as much as a security issue, especially for business-critical applications.

From our research:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to The State of Non-Human Identity Security.
• 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.
• For a broader control lens, review Ultimate Guide to NHIs for lifecycle and visibility guidance.

What this signals

NHI governance will increasingly be judged on dependency mapping, not just secret hygiene. As environments add more machine identities, the practical question becomes whether a team can explain which workloads break if an identity is changed. That shifts programme design toward ownership records, runtime relationships, and safe revocation paths rather than credential-only controls.

The category is also moving toward tighter integration between identity operations and delivery workflows. If provisioning, review, and offboarding remain separate from the systems that create access, teams will keep accumulating identities they can store but not safely govern.

Identity blast radius: the real metric becomes how far a single NHI can reach before governance notices. Teams that can bound that blast radius will be able to act faster on rotation, revocation, and incident response without destabilising core services.

For practitioners

• Build a complete NHI inventory Classify service accounts, API keys, tokens, roles, and certificates by owner, workload, environment, and privilege level before applying policy. Treat unknown ownership as a governance defect, not a documentation problem.
• Separate vaulting from governance Keep secret rotation, access approval, and entitlement review as distinct controls so a protected credential is not mistaken for a governed identity. Require every vaulted secret to map to an accountable owner and a named runtime dependency.
• Map privileged NHIs to critical dependencies Identify which business services fail if a privileged identity is rotated, revoked, or deleted, then define the minimum safe response path for each one. This avoids emergency changes that create outages while still reducing standing risk.
• Move lifecycle controls into delivery pipelines Trigger provisioning, review, and offboarding checks in the same workflows that create service identities so governance happens where access is born. That reduces orphaned accounts and gives security teams a durable audit trail.

Key takeaways

• The core problem is structural: identity management built for humans cannot fully govern the volume, speed, and dependency patterns of modern NHIs.
• The scale signal is clear, with NHIs already outnumbering human identities by 10-50x and highly privileged machine access materially increasing exposure.
• The practical response is to combine inventory, ownership, lifecycle control, and dependency mapping so governance matches how machine identities are actually created and used.

Key terms

• Non-Human Identity: A non-human identity is any digital identity used by software, services, workloads, or devices rather than a person. It includes service accounts, API keys, tokens, certificates, and machine roles. Governance must track ownership, access scope, and lifecycle because these identities can create persistent, high-impact access paths.
• Identity Lifecycle Management: Identity lifecycle management is the process of creating, reviewing, rotating, and removing access as business needs change. For NHIs, the lifecycle is often tied to code, pipelines, and runtime dependencies, so offboarding and rotation must be coordinated with the systems that depend on the identity.
• Secret Manager: A secret manager is a control that stores and sometimes rotates credentials such as tokens, keys, and certificates. It reduces exposure of sensitive material, but it does not by itself establish ownership, entitlement context, or revocation accountability, which means governance can still fail even when storage is secure.
• NHI Sprawl: NHI sprawl is the uncontrolled growth of machine identities across environments, teams, and tools. It usually appears when applications and infrastructure create access faster than governance can inventory, classify, and retire it, leaving security teams with more identities than they can accurately manage.

Deepen your knowledge

NHI lifecycle management, ownership mapping, and secret governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a control model for machine identities at scale, it is worth exploring.

This post draws on content published by Oasis Security: What's Broken with Identity Management? Read the original.