Secrets Sprawl vs Vault Sprawl: How to Diagnose and Consolidate Secret Stores

Secrets sprawl and vault sprawl are often reported as one problem, yet they have different causes, different owners and different fixes, and treating vault sprawl with more secret scanning leaves the real gap open. Secrets sprawl is uncontrolled copies of credentials outside any approved store: in code, CI logs, chat, tickets and laptops. Vault sprawl is the opposite failure inside the approved estate: too many secret stores, created by different teams with different policies, no single inventory and no clear owner, so nobody can say where a given credential lives or whether it is rotated. This guide focuses on vault sprawl: how to tell it apart from secrets sprawl, how to find every store, how to decide between consolidation and federation, how to migrate and decommission, and how to measure both problems side by side. It is for platform, cloud security and identity teams who own secrets infrastructure. Products named as examples are listed alphabetically.

Key takeaways

• Different problems, linked causes. Secrets sprawl is credentials outside stores; vault sprawl is ungoverned stores. Vault sprawl feeds secrets sprawl, because teams copy secrets between stores and into pipelines when the stores do not connect.
• Store count is not the metric. Many stores can be correct: Microsoft advises one Key Vault per application, region and environment. Sprawl is stores without an owner, an inventory entry, a policy baseline or a single audit stream.
• Find stores through the cloud control plane. AWS Resource Explorer, Azure Resource Graph and Google Cloud Asset Inventory list secret resources across accounts and projects; self-hosted vaults and CI secret stores need their own discovery.
• Consolidate the control plane first. One inventory, one policy baseline and one log destination fix most vault sprawl. Physical consolidation is a second, optional step for stores that add risk without adding isolation.
• Measure both sprawls on one scorecard. Secrets outside stores, duplicate secrets across stores, orphaned stores and rotation coverage per store tell you which problem to fund next.

The short answer

Secrets sprawl means a credential exists in places it should not: source code, configuration files, container images, build logs, chat messages or developer machines. The fix is detection, revocation and moving the secret into a managed store or replacing it with workload identity. Vault sprawl means the managed stores themselves have multiplied without governance: a central vault, several cloud secret managers per account, Kubernetes Secrets in every cluster, CI platform secrets, and a team's private vault that nobody else knows about. The fix is inventory, ownership, a common policy baseline and, where it reduces risk, consolidation. Measuring leaked secrets in depth is covered in the Secret Sprawl Measurement Guide; the architectural choice between one platform and many is covered in Centralised vs Decentralised Secrets Management. This page sits between them: how to diagnose and clean up an estate that already has too many stores.

How vault sprawl creates secrets sprawl

The two problems are linked in a predictable loop. When stores do not share identity or policy, teams solve integration by hand: they export a secret from one store and paste it into another, into a CI variable, or into a Kubernetes manifest. Each copy is a new place to rotate and a new place to leak. The OWASP Secrets Management Cheat Sheet notes that services often share the same secrets, which makes tracing the source of a leak difficult, and that multi-cloud estates face different APIs, access control models, rotation mechanisms and fragmented audit logs.

• Manual bridging: a database password lives in a self-hosted vault and is copied into a cloud secret manager for a serverless function. When the vault rotates it, the copy breaks, and the team disables rotation.
• Bootstrap secrets: every additional store needs credentials to reach it. OWASP points out that the primary secret of one secrets solution must itself be stored in a secondary solution, so each new store adds at least one more high-value secret.
• Audit gaps: an incident responder searching one store's logs cannot see reads from the other copies, so a leaked secret's use goes unnoticed.
• Shadow stores: a team that finds the central service slow creates its own store, and the inventory is out of date the day it is written.

Fixing vault sprawl therefore reduces secrets sprawl at source: fewer manual copies, fewer bootstrap credentials and one place to look during a leak. The AI-specific route by which secrets now escape into tools and transcripts is in AI Coding Tools and Secrets Sprawl.

Threat model for each problem

Secrets sprawl

• Adversary path: read a credential where it was left (public or internal repository, container image layer, CI log, collaboration tool) and use it directly. No store compromise is needed.
• Failure modes: scanning only Git, closing alerts without revoking the credential, and no owner for the identity behind the secret.
• Controls: push protection and scanning across code, images and logs; revocation measured until the issuer rejects the credential; replacement of static secrets with workload identity federation. See the OWASP NHI Top 10 NHI2 Secret Leakage Guide.

Vault sprawl

• Adversary path: gain a cloud identity or CI identity with read access to a forgotten store, or to a store whose access policy never received the baseline, and enumerate its secrets. In decentralised cloud stores there is no separate vault login: the cloud role is the key.
• Failure modes: stores no one owns; secrets duplicated across stores with different rotation states; inconsistent logging so reads are invisible; over-broad policies created when a team was in a hurry; stores left running after a project or an acquired company was absorbed.
• Controls: a complete store inventory with owners, a policy and logging baseline enforced by cloud policy, removal of duplicate copies with one system of record, decommissioning of orphaned stores, and least privilege reviews per store.

Finding every store

A vault sprawl programme starts with an inventory of stores, not of secrets. The cloud control planes make the first pass straightforward; the rest needs targeted discovery.

For every store record: owner (a team, not a person), business service, environment, cloud account or cluster, authentication methods, who can administer it, logging destination, number of secrets, rotation coverage and whether it is a system of record or a delivery copy. OWASP Section 2.11 lists the per-secret metadata worth keeping (creator, consumer, purpose, type, contact and rotation needs); the same discipline applied to stores turns a list into a governable estate.

How many stores is too many?

There is no correct number. Microsoft's Key Vault guidance is explicit that separation is a security control: grouping secrets in one vault increases the blast radius of a security event, separating by application is the most common boundary, and multitenant SaaS should use one vault per tenant. An estate with 300 well-governed vaults can be healthier than one with five unmanaged ones. Use these tests instead of a count:

• Ownership test: every store has a named owning team and a business service. A store with no owner is sprawl regardless of size.
• Purpose test: each store exists for an isolation reason (application, environment, tenant, region, regulatory zone). A store that exists only because a team did not know another one existed fails.
• Baseline test: each store meets the same minimum policy: logging enabled and shipped to the central destination, deletion protection on, no wildcard read grants, federated authentication for workloads.
• Uniqueness test: a secret has one system of record. If the same credential appears in several stores, every copy except the delivery copies managed by sync is sprawl.
• Visibility test: incident responders can find which store holds a given credential, and who read it, within one query. OWASP recommends sending secret usage logs to a single location accessible to incident response.

Consolidation versus federation

Once the inventory exists, each store gets one of four outcomes. The choice depends on whether the store provides genuine isolation and whether its workloads can reach an alternative with native identity.

Delivery copies are well supported by current tooling. HashiCorp Vault secrets sync pushes secrets one way from Vault to AWS Secrets Manager, Azure Key Vault, Google Secret Manager, GitHub repository Actions secrets and Vercel projects; Vault remains the system of record and a deletion in Vault deletes the destination copy. The documentation also states that synchronisation is last write wins, that out-of-band changes made directly in the destination are not corrected by reconciliation, and that read access is checked only when an association is created or updated. External Secrets Operator works in the other direction for Kubernetes: its controller fetches secrets from an external store and creates and reconciles Kubernetes Secrets, with SecretStore scoped to a namespace and ClusterSecretStore usable across the cluster. Availability: Vault secrets sync requires a Vault Enterprise licence or HCP Vault Dedicated and a one-time activation, per HashiCorp's documentation. Operating guidance for the operator is in the External Secrets Operator security guide.

Worked scenario: an acquisition doubles the store count

A software company with a central vault and per-account cloud secret managers acquires a smaller firm. Six months later the inventory shows 140 stores, against 70 before. Analysis of the new stores finds: 30 cloud secret stores in the acquired firm's accounts with logging off; 12 Kubernetes clusters with hand-made Secrets; one self-hosted vault cluster with a root token held by a former employee's team; and 400 credentials present in both the old vault and a cloud store, with different values in 90 cases.

1. Contain: rotate the self-hosted vault's administrative credentials and revoke unused root tokens; turn on logging for all 30 stores through cloud policy.
2. Assign: give each store an owning team and business service in the inventory; stores still unclaimed after a deadline are frozen and scheduled for retirement.
3. Resolve duplicates: for the 400 shared credentials pick the system of record (the central vault), confirm which value is live with the consuming service, rotate, and turn the cloud copies into synced delivery copies or delete them.
4. Classify: the 30 cloud stores per application are deliberate boundaries and are kept and baselined; the 12 clusters move to External Secrets Operator reading from the cloud stores; the self-hosted vault is migrated and retired.
5. Measure: after one quarter, stores without owner fall to zero, duplicate credentials to under 20 delivery copies, and the store count settles at about 110: still above 70, but every store passes the five tests.

The outcome is not fewer stores for its own sake; it is an estate where every store has a reason, an owner and a baseline.

How to implement: phased approach

1. Define the standard: write the store baseline (logging destination, deletion protection, authentication methods, admin roles, tagging for owner and service) and the approved store types per platform.
2. Inventory stores: run the control plane queries above across all accounts, subscriptions and projects, add self-hosted and CI stores, and reconcile with billing and procurement records.
3. Assign owners and classify: record each store's purpose and decide keep, federate, delivery copy or retire. Freeze creation of unclassified stores through cloud policy where possible.
4. Pilot on one business unit: apply the baseline and resolve duplicates for one unit first, in report-only mode for policy enforcement, and measure breakage before enforcing.
5. Migrate in waves: move secrets for retiring stores service by service. Run old and new stores in parallel, switch consumers, confirm reads have stopped in the old store's logs, then rotate the secret so the old copy is useless.
6. Decommission safely: disable access before deletion, keep soft delete or backups for the agreed retention, and remove the bootstrap credential that reached the old store.
7. Prevent recurrence: require new stores to be created through a self-service template that applies the baseline and registers the inventory entry, so the fast path is also the governed path.

Rollback: keep the old store read-only rather than deleted until consumers have run cleanly through at least one rotation cycle, and keep the migration mapping (old path to new path) so any missed consumer can be repointed quickly.

Detection and measurement: one scorecard for both sprawls

Alert on creation of new secret stores outside the self-service template, on logging being disabled on any store, and on reads from stores marked for retirement. Measuring rotation in practice is covered in How to measure secret age and rotation coverage.

Where identity fits

Every store is accessed by identities, and most of them are non-human: workloads, CI runners, sync processes and operators' automation. Vault sprawl multiplies those identities and their bootstrap credentials. The most effective consolidation step is often not moving secrets but removing them: replace stored database passwords and cloud keys with workload identity federation or dynamic credentials, so there is nothing to sprawl. See the Dynamic Secrets and Ephemeral Credentials Guide.

Framework mapping

Common failure patterns

• Counting stores instead of governing them: a target such as "one vault" removes deliberate isolation boundaries and increases blast radius.
• Two-way edits on synced copies: teams change a value in the delivery copy, the next sync overwrites it, and production breaks; sync tools do not correct out-of-band edits until the next write.
• Retiring a store without rotating its secrets: copies elsewhere still work, so the migration moved a secret without removing the exposure.
• Treating vault sprawl with scanning alone: scanners find secrets in code, not ungoverned stores with logging off.
• Central service too slow to use: if a new store takes weeks to approve, teams create shadow stores; the self-service template is a sprawl control.
• Inventory built once: without continuous control plane queries, acquisitions and new accounts reintroduce unknown stores within months.

Practitioner checklist

• Report secrets sprawl and vault sprawl as separate measures with separate owners.
• Inventory every store through cloud control plane queries plus self-hosted, Kubernetes and CI discovery.
• Give each store an owning team, a business service and an isolation reason.
• Enforce a store baseline: central logging, deletion protection, no wildcard reads, federated workload access.
• Pick one system of record per secret and make every other copy a managed one-way sync or remove it.
• Classify each store as keep, federate, delivery copy or retire, and migrate in waves with rotation at cut-over.
• Provide a self-service store template so the governed path is the fastest path.
• Track owner coverage, baseline compliance, duplicates and rotation coverage per store each month.

Standards and references

• OWASP: Secrets Management Cheat Sheet
• Microsoft Learn: Best practices for using Azure Key Vault
• Microsoft Learn: Overview of Azure Resource Graph
• AWS: Resource Explorer supported resource types
• Google Cloud: Cloud Asset Inventory supported asset types
• HashiCorp: Vault secrets sync
• External Secrets Operator: Overview

Related NHI Mgmt Group resources: Centralised vs Decentralised Secrets Management, Secret Sprawl Measurement Guide, Cloud Secrets Managers Guide, Leaked secret breaches.