Vault sprawl is the governance gap undermining NHI security

At a glance

What this is: Vault sprawl is the proliferation of multiple secret stores and vault instances that leaves organisations unable to track where secrets live, who owns them, or which copy is authoritative.

Why it matters: For IAM and NHI practitioners, vault sprawl turns access control, rotation, and incident response into a cross-team negotiation instead of a governed control process.

By the numbers:

• 23.77 million hard-coded credentials were added to public GitHub repos in 2024 alone.
• 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits.

👉 Read GitGuardian's analysis of vault sprawl and NHI governance

Context

Vault sprawl is the accumulation of too many secret stores, vault instances, and duplicated credentials across an enterprise. In practice, it appears when secrets management is solved locally by individual teams rather than through a shared NHI governance model, and the result is that IAM teams lose visibility into where machine credentials live and who can still use them.

For NHI practitioners, the issue is not simply storage sprawl but control-plane drift. If a secret can exist in source code, CI/CD variables, a cloud-native vault, and a team-specific store at the same time, then lifecycle controls become unreliable and offboarding becomes guesswork. The NHI Lifecycle Management Guide explains why provisioning, rotation, and retirement need to be treated as one operating model rather than separate tasks.

That failure mode is not typical of a mature programme. It is the predictable result of growth, speed, and fragmented ownership colliding with access patterns that were never designed for autonomous workloads, bots, and agents.

Key questions

Q: How should security teams reduce vault sprawl without disrupting delivery?

A: Start by building a complete inventory of where secrets exist, then define a common lifecycle policy for access, rotation, and retirement. Do not begin with a vault migration. Most disruption comes from inconsistent ownership and duplicate secrets, not from the number of tools. Standardised metadata and automated policy checks reduce friction while preserving delivery speed.

Q: When does vault sprawl become a real security risk?

A: Vault sprawl becomes a real risk when teams can no longer identify the authoritative secret copy, the owning workload, or the current access path. At that point, rotations become error-prone, offboarding becomes incomplete, and leaked secrets can remain active longer than intended. The risk is governance failure, not just operational clutter.

Q: What is the difference between secrets sprawl and vault sprawl?

A: Secrets sprawl is the uncontrolled spread of credentials into code, tickets, chats, and other plaintext surfaces. Vault sprawl is the organisational response that creates too many secret stores, duplicate copies, and inconsistent control models. One is the exposure problem, the other is the governance problem that follows when exposure is handled in silos.

Q: Should organisations centralise secret storage or standardise secret governance first?

A: Standardise governance first. A single policy model for ownership, rotation, access, and audit evidence works even when storage remains distributed across clouds and teams. Centralising storage without standardising governance often just moves the inconsistency into a different tool. Mature programmes treat the control model as the primary asset.

Technical breakdown

How secrets sprawl becomes vault sprawl

Secrets sprawl starts when credentials leak into places such as source code, tickets, chats, and documentation, then get copied forward to keep systems running. Vault sprawl is the downstream architecture problem: teams respond by adding more vaults, more native cloud secret stores, and more isolated workflows. The result is not stronger control but fragmented control, where different teams maintain different access models, audit trails, and rotation paths for the same logical secret. That fragmentation creates uncertainty about the authoritative copy and makes lifecycle actions riskier than the original leak. This is why secrets governance and vault governance cannot be separated in mature NHI programmes.

Practical implication: inventory the entire secret path, not just the vaults.

Why duplicated credentials increase blast radius

When the same credential exists in multiple stores, compromise of one copy becomes compromise of the identity behind it. Duplicated secrets also slow remediation because teams must first determine which copies are live, which are stale, and which workloads still depend on them. In NHI terms, the blast radius is not limited by storage location but by reuse pattern. Cross-environment sharing, overuse of a single NHI, and long-lived credentials all expand the impact of a leak. Governance should therefore focus on reducing credential reuse and establishing a single source of truth for ownership, scope, and rotation status.

Practical implication: treat duplicated secrets as a control failure, not a housekeeping issue.

What a common control plane changes for NHI governance

A common control plane does not mean one vault product. It means one operating model for identity inventory, metadata, access decisions, rotation, and retirement across many stores. That model lets security teams answer basic governance questions consistently: who owns this credential, what workload uses it, where is it valid, and when was it last rotated. Without those answers, audit evidence becomes approximate and incident response becomes manual. With them, teams can automate policy enforcement across heterogeneous tools and environments while keeping delivery teams on a predictable path. This is the minimum architecture needed to govern NHIs at enterprise scale.

Practical implication: standardise policy and metadata before you standardise tooling.

Threat narrative

Attacker objective: The attacker objective is to turn one leaked credential into broad, durable machine access across multiple workloads and environments.

1. Entry occurs when a secret is exposed in source code, tickets, chats, or a duplicated vault copy that an attacker can discover.
2. Escalation follows when the same credential is reused across workloads, environments, or teams, allowing the attacker to move from one system to another.
3. Impact occurs when the exposed NHI grants persistent access that survives rotation delays, enabling data access or operational disruption.

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

Vault sprawl is an NHI governance failure, not a storage preference. Multiple vaults can be defensible in isolation, but they become a control problem when no shared ownership model exists for credentials, rotation, and audit evidence. The real risk is not that teams use different tools, but that the organisation can no longer answer the same governance questions consistently across tools. Practitioners should treat vault sprawl as a programme defect, not a tooling debate.

Secrets and vaults must be governed as one lifecycle. Discovery, storage, usage, rotation, and retirement are separate steps only on paper. In practice, duplicated credentials and local vault decisions create long-lived exposure paths that outlast the business justification for the secret. A lifecycle view reduces ambiguity and closes the gap between what teams think is protected and what is still live in production. Practitioners should align policy to the full credential lifecycle.

Identity blast radius is the metric that matters when secret stores multiply. The more places a credential exists, the larger the impact when one copy leaks or one team misses a rotation. That makes least privilege, scope limitation, and secret uniqueness more important than the count of vault features. The field should judge vault strategy by how much it constrains blast radius, not by how many stores it can connect. Practitioners should optimise for containment, not convenience.

Enterprise NHI programmes need a single source of truth for ownership and usage. Without metadata for owner, workload, environment, and last rotation date, governance becomes an investigation after every incident. Metadata is what turns scattered secrets into governed identities and supports evidence for auditors, incident responders, and platform teams. The practical conclusion is straightforward: if a secret cannot be attributed, it is not governed.

Secret sprawl remains the upstream signal, but vault sprawl is where the control gap becomes visible. GitGuardian's research shows 23.77 million hard-coded credentials were added to public GitHub repos in 2024, and that scale forces teams to react quickly. The enterprise response often creates a second-order problem by multiplying stores instead of reducing exposure. Practitioners should fix the governance model before they multiply the storage model.

From our research:

• 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
• 62% of all secrets are duplicated and stored in multiple locations, causing unnecessary redundancy and increasing the risk of accidental exposure.
• For a broader control model, see Ultimate Guide to NHIs: Lifecycle Processes for Managing NHIs for how to tie discovery, rotation, and retirement into one lifecycle.

What this signals

Identity blast radius is now the practical measure of vault sprawl. As credential copies multiply, the cost of a single leak is no longer local to one team or one tool. That means NHI programmes should prioritise containment, metadata, and deterministic rotation paths over incremental vault additions. The governance question is not how many stores exist, but how far one exposed secret can travel before it is neutralised.

Offboarding failures are a strong signal that vault sprawl has outgrown manual controls. When former employee tokens remain active, the issue is not just stale access but an identity lifecycle that no longer closes cleanly. Organisations should expect more pressure to automate retirement checks, reconcile ownership, and prove that inactive credentials are actually removed. The programme lesson is simple: if offboarding is manual, vault sprawl will keep creating hidden access.

With 44% of NHI tokens exposed in the wild, per our 2025 State of NHIs and Secrets in Cybersecurity report, the market signal is clear: enterprises need policy-driven control across all secret stores, not just better storage hygiene. That shift will favour teams that can enforce one governance model across cloud, CI/CD, and runtime environments. The next phase of maturity is not another repository for secrets, but a control plane that makes every repository behave consistently.

For practitioners

• Implement enterprise secret inventory Map every secret across source code, CI/CD variables, vaults, runtime environments, and ticketing systems so ownership and authority are explicit. Use that inventory to identify duplicates, stale copies, and unknown dependencies before attempting broad remediation.
• Standardise metadata for every NHI secret Require owner, workload, environment scope, and last rotation date for each credential so teams can make consistent access and renewal decisions. Metadata should travel with the secret, not live in a separate spreadsheet or ticket queue.
• Automate rotation from usage signals Tie rotation and renewal to real usage and policy state, then retire secrets that are duplicated, orphaned, or no longer tied to active workloads. This reduces manual exceptions and shortens the window in which a leaked credential remains useful.
• Consolidate governance before consolidating tools Define one policy model for access, audit, and lifecycle management across all secret stores, then map existing tools to that model. The goal is consistent evidence and enforcement across environments, not simply fewer platforms on the asset list.

Key takeaways

• Vault sprawl is the governance consequence of handling secrets sprawl with isolated tools and local decisions.
• Duplicated credentials and unclear ownership expand the identity blast radius, making rotation and offboarding unreliable.
• Practitioners should standardise lifecycle policy and metadata before they attempt to consolidate secret stores.

Key terms

• Vault Sprawl: Vault sprawl is the uncontrolled growth of secret stores, vault instances, and duplicate credential repositories across an organisation. It creates fragmented access control, unclear ownership, and inconsistent rotation practices, which makes it difficult to prove where a secret lives or whether the authoritative copy is still in use.
• Secrets Sprawl: Secrets sprawl is the spread of credentials into plaintext surfaces such as source code, tickets, chat systems, and documentation. It is the upstream exposure problem that often triggers broader governance failures when teams respond by copying the same secret into more places instead of removing it.
• Identity Blast Radius: Identity blast radius is the amount of damage an exposed or mismanaged NHI credential can cause once it is compromised. It grows when secrets are reused, duplicated, or left active across multiple environments, because one leak can grant access to more systems than the original owner intended.
• NHI Lifecycle Management: NHI lifecycle management is the practice of governing non-human identities from creation through use, rotation, and retirement. It ensures each credential has an owner, a scope, an expiration path, and a clear decommissioning process, which is essential when machine identities outnumber human-controlled accounts.

What's in the full article

GitGuardian's full article covers the operational detail this post intentionally leaves for the source:

• How its inventory and metadata model connects multiple secret managers into one governance view
• How Push-to-Vault handles exposed secrets through controlled remediation paths
• How NHI Governance analytics track policy breaches and secret hygiene over time
• Which integrations it supports across common secret managers and operational environments

👉 GitGuardian's full post covers inventory, remediation workflows, and NHI governance analytics.

Deepen your knowledge

Vault sprawl, secrets lifecycle, and NHI ownership are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a governance programme from a fragmented starting point, it is worth exploring.