Vaults alone do not solve secrets sprawl and exposure risk

At a glance

What this is: This is a secrets-management analysis arguing that vaults are necessary but insufficient because they store secrets without governing their lifecycle, usage, or exposure.

Why it matters: It matters because IAM, NHI, and platform teams need controls that address discovery, monitoring, rotation, and privilege scope, not just storage.

👉 Read Entro Security's analysis of why vaults are not enough for secrets management

Context

Secrets management is not the same thing as secret storage. A vault can hold tokens, API keys, and certificates, but it does not by itself tell you where those secrets live, how often they are used, or whether they have already leaked into other systems. That distinction matters because most secrets risk comes from lifecycle gaps, not from the act of storing a value in one place.

For IAM and NHI programmes, the problem is governance depth. If access is provisioned once and then left unobserved, the organisation may have a vault but still lack control over exposure, overprivilege, and dark-web leakage. That is the core limitation the article is pointing to: the control plane stops at storage, while the risk continues downstream.

Key questions

Q: How should security teams govern secrets that move beyond the vault?

A: They should treat the vault as only one control point and build governance around discovery, ownership, usage monitoring, and revocation. If a secret can exist in code, chat, tickets, or pipelines, then the programme needs visibility into those locations as well. A vault without lifecycle governance reduces storage risk but leaves exposure risk largely unchanged.

Q: Why do duplicated secrets increase breach impact?

A: Duplicated secrets increase breach impact because every extra copy creates another place an attacker can find valid access and another revocation problem for defenders. If one secret is reused across systems, compromise of a single copy can expose multiple applications. That makes inventory accuracy and unique ownership more important than simply putting the secret in a vault.

Q: When does vaulting stop being enough for secrets management?

A: Vaulting stops being enough when the organisation cannot answer where secrets are copied, who owns them, and whether they are still valid after exposure or workload change. At that point, the problem is not storage but governance. The programme needs discovery, monitoring, rotation, and revocation to reduce real risk.

Q: What should teams do when a secret may already be exposed?

A: They should assume the secret is compromised until proven otherwise, revoke it, rotate dependent credentials, and check for secondary copies across repositories, tickets, and collaboration tools. The goal is to limit reuse before an attacker can convert exposure into access. Waiting for confirmation usually gives the attacker more time than defenders have.

Technical breakdown

Why vaults stop at storage

A vault is a controlled repository for secrets, usually with encryption, access checks, and retrieval logging. That design answers one narrow question: who can fetch a secret from the vault. It does not answer where the secret is copied next, whether the same secret exists in multiple places, or whether the secret remains valid after exposure. In practice, the vault is only one control point in a broader secrets lifecycle that also includes discovery, distribution, rotation, revocation, and usage monitoring.

Practical implication: treat the vault as one control in the secrets lifecycle, not as the lifecycle itself.

How secrets sprawl creates hidden exposure

Secrets sprawl happens when tokens, keys, and certificates accumulate across code, tickets, chat tools, repositories, and multiple vaults. The more copies exist, the harder it becomes to know which secret is authoritative and which one is stale, duplicated, or forgotten. This is a governance problem as much as a technical one, because duplication expands blast radius and makes revocation uncertain. The article’s point is that organisations often lose inventory before they lose control.

Practical implication: build inventory and exposure discovery before assuming rotation or vaulting will reduce risk.

Why least privilege for secrets is hard to set upfront

The article notes that secrets permissions are often chosen at creation time, which leads teams to overprovision access to avoid breakage. That creates standing privilege on programmatic credentials, even when the workload only needs a narrow slice of access. Once a secret is over-scoped, every system that inherits it also inherits the excess privilege. In identity terms, this is a lifecycle failure: the permission boundary was defined too early and rarely corrected after the workload changed.

Practical implication: review secret permissions after deployment, not only at issuance time.

Threat narrative

Attacker objective: The attacker aims to reuse valid programmatic credentials to move beyond the initial application or pipeline and reach sensitive systems or data.

1. Entry occurs when a secret is copied outside the vault into code, a pipeline, or another service, creating a second exposure point beyond the controlled store.
2. Escalation follows when the exposed secret carries broader permissions than the workload actually needs, allowing an attacker to reuse it across connected systems.
3. Impact lands when the attacker uses that programmatic access to reach data, cloud resources, or downstream services without triggering the vault itself.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Google Firebase misconfiguration breach — Firebase misconfigurations exposed 19.8M secrets across developer instances.

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-only thinking is a control boundary mistake, not a storage strategy. Vaults answer where secrets sit, but not whether they are duplicated, reused, or still valid after exposure. That means the organisation can satisfy storage discipline while leaving the true risk surface untouched. The implication is simple: the security programme must govern secrets as living credentials, not as static objects in a repository.

Secrets sprawl is the operational signal that governance has lost inventory. When teams cannot say how many secrets exist, they cannot credibly manage exposure, revocation, or ownership. This is not just an optimisation gap. It is a control failure that makes incident response slower and accountability weaker across DevOps, security, and platform teams. Practitioners should treat inventory accuracy as a core governance outcome, not a reporting extra.

Least privilege for secrets fails when permissions are set only at creation time. The article shows the common assumption that a secret can be safely over-scoped and fixed later. That assumption fails because programmatic access often persists long after the original use case changes. The implication is that secrets governance must be lifecycle-aware from issuance through reuse, rotation, and offboarding.

End-to-end monitoring is the missing assurance layer between vault and breach. A vault can log requests, but it cannot by itself detect unusual usage patterns, dark-web exposure, or credential reuse outside its boundary. That is why secrets governance must extend into monitoring and exposure intelligence. For practitioners, the key question is whether the programme sees only storage events or the full credential trail.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
• From our research: 28% of secrets incidents now originate outside code repositories and are 13% more likely to be categorised as critical than code-based leaks, according to The State of Secrets Sprawl 2026.
• For a broader control framework, review the Guide to the Secret Sprawl Challenge and compare its lifecycle view with vault-centric operating models.

What this signals

Secret sprawl is now a governance problem, not just a hygiene problem. When secrets are duplicated across repositories, collaboration tools, and build systems, the programme loses the ability to say which credential is authoritative. That changes the work of IAM and platform teams from storage administration to lifecycle governance, and it demands an inventory model that can survive cloud and DevOps drift. With 64% of valid secrets leaked in 2022 still exploitable today, revocation discipline is now as important as detection.

Vault-centric programmes will keep missing the real exposure boundary until they search outside code. Collaboration tools and ticketing systems now carry meaningful secret risk, so the issue is not where the vault sits but where the secret is copied next. That shifts practitioner focus toward discovery across the full collaboration and delivery stack, including the locations described in the Guide to the Secret Sprawl Challenge.

Static secret ownership will not scale if programmes do not recheck scope after deployment. Permissions set at issuance often outlive the workload they were meant to support, which means review cadence has to follow operational change, not just creation events. Teams that only measure vault coverage will miss the larger question: whether a secret still needs the access it was granted. The boundary that matters is lifecycle, not storage.

For practitioners

• Map every secret to an owner and system of record Create an authoritative inventory across vaults, repositories, tickets, chat tools, and CI/CD systems so duplicated and unmanaged secrets can be identified before rotation or revocation work begins.
• Reduce overprovisioned secret permissions after deployment Review the actual permissions attached to each secret once the workload is live, then trim access that was added only to avoid breakage during provisioning.
• Automate exposure detection and revocation together Pair leak detection with automated revocation workflows so a discovered secret is not left valid while teams investigate the exposure.
• Track secrets outside the vault boundary Search for credentials in code, collaboration tools, and build systems because secrets that escape the vault often become the first source of unauthorised access.
• Use lifecycle reviews for long-lived secrets Revalidate ownership, scope, and business need on a schedule for secrets that survive application changes or vendor transitions, rather than assuming issuance-time approval is still sufficient.

Key takeaways

• Vaults are necessary controls, but they do not by themselves solve secret exposure, reuse, or lifecycle drift.
• Secrets sprawl expands breach impact because duplicated credentials are harder to inventory, revoke, and contain.
• The control that changes outcomes is end-to-end governance across discovery, ownership, monitoring, rotation, and revocation.

Key terms

• Secrets Management: Secrets management is the discipline of storing, distributing, monitoring, and revoking credentials such as API keys, tokens, and certificates. A vault may be part of it, but the real control objective is to keep secrets discoverable, limited in scope, and invalidated quickly when they are exposed or no longer needed.
• Secrets Sprawl: Secrets sprawl is the uncontrolled growth of duplicated credentials across repositories, collaboration tools, pipelines, and vaults. It makes inventory unreliable, increases the chance of accidental exposure, and slows revocation because defenders no longer know which copy is current or authoritative.
• Vault: A vault is a protected storage system for secrets that controls who can retrieve them. It does not, by itself, govern where secrets are copied next, how they are used, or whether they remain valid after exposure, so it must be paired with lifecycle monitoring and revocation.
• Least Privilege For Secrets: Least privilege for secrets means giving each credential only the permissions needed for its intended workload and nothing more. In practice, that requires revisiting access after deployment, because permissions chosen at creation time are often broader than the workload actually uses.

What's in the full article

Entro Security's full blog covers the operational detail this post intentionally leaves for the source:

• How the vendor frames the limits of vault-only storage versus full secrets lifecycle management
• The specific remediation and monitoring capabilities the vendor associates with holistic secrets protection
• Examples of secret exposure scenarios across repositories, cloud services, and collaboration tools
• The vendor's own explanation of why least privilege is difficult to set correctly at creation time

👉 Entro Security's full post covers the vault limitations, secrets sprawl, and least-privilege implications in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.