Should organisations centralise all secrets into one vault?

Not automatically. Centralisation improves visibility only if access boundaries, environment separation, and lifecycle controls are strong enough to prevent one compromise from spreading. In some environments, a single control plane is useful, but the real question is whether it reduces blast radius without creating a single point of failure.

Why This Matters for Security Teams

Centralising secrets sounds efficient because it promises one inventory, one policy layer, and one audit trail. In practice, the decision is less about convenience and more about whether the vault becomes a control point or a concentration point. The current guidance in the OWASP Non-Human Identity Top 10 is that secrets must be treated as high-value NHI assets with lifecycle, access, and exposure controls, not just stored in a single repository.

NHI Management Group research on the Guide to the Secret Sprawl Challenge shows why this is hard: 62% of all secrets are duplicated and stored in multiple locations, and 50% of organisations are onboarding new vaults without proper security approval. That combination means centralisation can reduce sprawl, but it can also create a single compromise path if the vault is over-permissioned or weakly segmented. The real issue is not where the secrets sit, but whether the vault design limits blast radius when access is abused. In practice, many security teams discover that centralisation improved visibility only after a leaked token had already been reused across several environments.

How It Works in Practice

Effective centralisation starts with boundary design. A single vault may be acceptable for policy administration, but it should not mean one flat trust domain for every application, environment, and team. Separate namespaces, per-environment access policies, and workload-specific identities are essential so that dev, staging, and production do not share a common failure path. The Ultimate Guide to NHIs — Static vs Dynamic Secrets is useful here because static secrets and long-lived tokens behave very differently from dynamic, short-lived credentials.

Operationally, a strong vault program usually includes:

• JIT issuance for secrets that expire after a task or session ends.
• Workload identity instead of shared human-style accounts for applications and agents.
• Policy checks at request time, not just at provisioning time.
• Rotation and revocation workflows that are automated, not ticket-driven.
• Logging that ties every secret access to an owning service, environment, and purpose.

This is also where implementation discipline matters. Centralisation should be paired with guardrails for token export, CI/CD injection, and secret retrieval from code and collaboration tools. NHIMG case studies such as the Reviewdog GitHub Action supply chain attack and the CI/CD pipeline exploitation case study show how quickly secrets leak once automation is allowed to overreach its intended scope. These controls tend to break down when a single vault serves every environment without strict tenancy separation because one compromised token can unlock broad cross-system reuse.

Common Variations and Edge Cases

Tighter centralisation often increases operational overhead, requiring organisations to balance visibility against availability, latency, and failure isolation. That tradeoff is real, especially for distributed teams, multi-cloud estates, and legacy applications that cannot easily adopt dynamic credentials.

Best practice is evolving rather than universal. For highly regulated environments, a central control plane with strong segmentation is often preferable to scattered ad hoc stores. For acquisition-heavy or hybrid estates, multiple vaults may be justified temporarily if they preserve environment isolation and avoid a brittle migration. The key exception is when centralisation becomes a dependency for every application path without a fallback, because then the vault outage can become a business outage.

NHIMG research in the 52 NHI Breaches Analysis and the 2025 State of NHIs and Secrets in Cybersecurity suggests the biggest failure mode is not vault count alone, but weak lifecycle controls around what enters and leaves the vault. Centralise where it improves governance, but avoid designs that let one misconfiguration expose every secret in the estate.

Related resources from NHI Mgmt Group

• What breaks when organisations do not centralise secrets management?
• What breaks when organisations use one IAM model for humans and non-human identities?
• How can organisations reduce secrets exposure across repositories and collaboration tools?
• What do organisations get wrong about vaultless secrets management?