Notifications
Clear all
Topic starter
04/06/2026 3:03 pm
TL;DR: Enterprises are now running five to ten secret stores at once, and the vendor argues that vaulting alone cannot govern non-human identities because consumer context, ownership, and dependency-aware rotation sit outside any single vault's boundary. That makes multi-vault governance a structural IAM problem, not a storage problem.
NHIMG editorial — based on content published by Oasis Security: The Multi-Vault Reality of Modern PAM
By the numbers:
- 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches.
Questions worth separating out
Q: How should security teams govern secrets across multiple vaults?
A: Security teams should govern multi-vault environments above the storage layer.
Q: Why does single-vault consolidation often fail in enterprise identity programmes?
A: Single-vault consolidation often fails because cloud-native stores are deeply embedded in deployment workflows and enterprise PAM platforms add friction at machine-identity scale.
Q: What breaks when teams rotate secrets without mapping dependencies first?
A: Rotation without dependency mapping breaks applications because the team changes a credential before knowing which workloads rely on it.
Practitioner guidance
- Inventory secrets across every store Build a unified inventory that includes enterprise vaults, cloud-native secret managers, CI/CD stores, environment variables, and SaaS platform credentials.
- Map the consumer-to-resource chain before rotation Document which application, service, or pipeline consumes each secret, what identity it authenticates as, and which resource it reaches.
- Apply one rotation and expiry policy across all vaults Set a single standard for rotation cadence, ownership approval, and expiration limits, then enforce it in every secret store.
What's in the full article
Oasis Security's full blog covers the operational detail this post intentionally leaves for the source:
- How the governance layer maps the consumer-to-resource context chain across AWS Secrets Manager, Azure Key Vault, CyberArk, Delinea, and HashiCorp Vault
- Why consolidation usually fails because cloud integration, licensing friction, and developer workflow choices preserve secret sprawl
- What safe dependency-aware rotation looks like when multiple applications and pipelines share the same secret
- How the vendor positions its architecture alongside existing PAM and vault investments
👉 Read Oasis Security's analysis of multi-vault PAM and NHI governance →
Multi-vault PAM sprawl: what IAM teams need to do now?
Explore further
04/06/2026 3:17 pm
Multi-vault PAM is not a tooling preference. It is a governance boundary problem. PAM was built to govern a bounded privileged access estate, not a federation of cloud vaults, CI/CD stores, SaaS credentials, and acquisition-era inheritance. Once secrets live in five or ten places, the control plane that matters is the one above the vaults, because the governance question becomes cross-store visibility and policy consistency. Practitioners should treat multi-vault as the operating reality, not a migration failure.
A few things that frame the scale:
- 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
- 91% of former employee tokens remain active after offboarding, according to The 2025 State of NHIs and Secrets in Cybersecurity.
A question worth separating out:
Q: How do organisations know whether PAM is actually covering privileged access?
A: Organisations know PAM is covering privileged access when they can demonstrate governance over the full secret estate, not just the credentials stored in one vault. If they cannot enumerate all NHIs, all consumers, and all dependent systems, then PAM coverage is partial and the hidden estate remains outside control.
👉 Read our full editorial: Multi-vault PAM is now an enterprise governance problem
