The Multi-Vault Reality of Modern PAM

TL;DR: Most enterprises now run five to ten secret stores at once and will not consolidate to one, because the operational and licensing costs are too high. That makes traditional Privileged Access Management, which governs only what is inside its own vault, structurally insufficient for the non-human identities that dominate privileged access today. Closing the gap requires a governance layer that operates above existing vaults: discovering identities everywhere, mapping the consumer-to-resource context chain, enforcing policy uniformly, and running dependency-aware rotation across the full landscape.

‍

In customer conversations, I rarely meet an identity and security organization that set out to be multi-vault. They arrived there one defensible decision at a time.

The cloud team adopted AWS Secrets Manager because it was native to their environment. The Azure team picked Key Vault for the same reason. Central security mandated CyberArk or Delinea for on-premises and regulated workloads. DevOps standardized on HashiCorp Vault for CI/CD pipelines. SaaS platforms (Snowflake, Databricks, GitHub) kept their own credential stores. Then an acquisition closed, and the acquired company brought another vault stack with it.

Each of those decisions made local sense. The problem appears at the organizational level: a privileged access program designed to govern one vault is now expected to govern five, ten, or more, and it cannot do so coherently.

This is the structural gap most security teams are quietly working around. Privileged Access Management (PAM) continues to do what it was built to do. What changed is the population of identities using it, and that population now lives outside the boundary the original PAM model was drawn around.

‍

Vaulting solves storage. It does not solve governance.

A common misconception in enterprise identity programs is that secrets management is access management. The two are related, but they are not the same problem.

A vault tells you where a credential is stored. It does not tell you why the credential exists, what consumes it, what it authenticates as at runtime, or what would break if it were rotated. PAM layers meaningful controls on top of vaulted credentials, including session management, access approvals, and detailed audit logging. Those controls were architected for human-scale privileged access, in which the identity is known, the consumer is singular, and the lifecycle is anchored in HR records and Active Directory.

Non-human identities operate outside that frame. Developers, automation tooling, and third-party integrations create them on demand, without an authoritative source of record. They authenticate through secrets, tokens, and certificates, generally without MFA. Many are never decommissioned. And in modern enterprises, they outnumber human identities by orders of magnitude.

For the architectural breakdown of why PAM was never designed for service accounts, see our earlier piece on how NHIM complements PAM.

‍

The adoption trap

The common instinct, once a security team recognizes the sprawl, is to mandate consolidation: pick one vault and migrate everything into it. In practice, this rarely succeeds at the scale required.

Cloud-native vaults are deeply integrated with their ecosystems. Moving secrets out of AWS Secrets Manager tends to break IAM role assumptions and deployment automation that engineering teams have built over the years. Enterprise PAM vaults add per-secret licensing costs that, at machine-identity volumes, discourage broad adoption. Developers route around friction rather than through it. The vault that central security mandates is therefore rarely the vault that developers prefer to use.

The predictable outcome is partial adoption. The official vault holds a portion of the credentials, while the majority continue to live in cloud-native stores, CI/CD pipeline configurations, environment variables, and, too often, hardcoded inside application code itself.

The data support the pattern. GitGuardian's 2025 State of Secrets Sprawl reported that 5.1% of repositories already using a secrets manager still leaked secrets. The same report counted 23.8 million secrets leaked on public GitHub in 2024, a 25% year-over-year increase, with private repositories leaking at roughly eight times the rate of public ones.

Mandating a single vault without addressing the underlying developer workflows does not eliminate sprawl. It tends to make the ungoverned portion harder to see.

‍

The questions PAM cannot answer

When secrets live across five, ten, or more storage systems, security teams lose the ability to answer the questions that define a governance program.

• How many non-human identities and secrets does the organization actually have? 
• Who owns each one, and who is accountable when it is compromised? 
• Which ones remain in use, and which are stale? 
• For any given secret, what consumes it, what does it authenticate as, and what would break if it were rotated?

These are not vault questions. No single vault can answer them, because the answers require correlation across every location where credentials live, plus context that the vault was never designed to capture.

The OWASP Non-Human Identities Top 10 for 2025 makes the consequences concrete. The list cites improper offboarding of NHIs that remain active long after they should have been decommissioned, secret leakage into code and collaboration tools, overprivileged identities, and long-lived secrets that give attackers an unlimited window of exploitation. The Cloud Security Alliance's State of NHI Security report found that only 15% of organizations feel highly confident in their ability to prevent NHI-related attacks.

Auditors have begun to ask sharper questions. Whether the organization has a vault is no longer the operative test. Whether the organization can demonstrate governance over the totality of its privileged access, including machine identities, is.

Auditors have noticed too. The question is no longer do you have a vault? It is can you demonstrate governance over all privileged access, including machine identities?

‍

What the next phase of PAM looks like

The objective should not be to replace PAM. It should be to extend PAM with a governance layer that operates above the existing vaults already in production.

Multi-vault is, for almost every enterprise, a permanent condition rather than a transitional state to be resolved through migration. A governance layer suited to that condition has to deliver capabilities that PAM was not architected to provide.

It must perform continuous, agentless discovery of every non-human identity across every cloud, SaaS platform, on-premises environment, developer tool, and CI/CD pipeline. The point of that discovery is to surface what is not stored in the vault, in addition to what is.

It must map the full context chain. That means knowing which consumer (an application, a service, or a pipeline) uses which secret (a key, a token, or a certificate) to authenticate as which identity (a service account, a role, or a principal) to access which resource (an API, a database, or a cloud service). Without that chain, discovery produces an inventory rather than a governance program.

It must enforce a consistent policy across every vault. Rotation cadence, ownership requirements, least-privilege rules, and expiration limits should be defined once and applied uniformly, regardless of where any individual credential is stored. A secret in Azure Key Vault should be governed with the same rigor as a secret in CyberArk.

Finally, it must support safe, dependency-aware lifecycle operations. Rotation and decommissioning have to account for every consumer of a secret before any action is taken. Most teams hesitate to rotate precisely because they cannot map those dependencies, which is the reason secrets become long-lived in the first place. Long-lived secrets remain among the most exploited attack vectors in enterprise environments.

This is the governance layer Oasis was built to deliver. It operates above existing PAM and vault infrastructure rather than competing with it. Your CyberArk, Delinea, AWS Secrets Manager, Azure Key Vault, and HashiCorp investments remain in production. What the layer adds is unified visibility, enforceable ownership, and lifecycle automation that no single vault can produce in isolation.

‍

Three questions for your team

Before scoping your next PAM initiative, ask the following.

1. Can we enumerate every non-human identity in our environment, not only what is in the vault?
2. For any given secret, do we know every consumer, system, and dependency chain attached to it?
3. Could we rotate or decommission any NHI today without risk of an outage?

If the answer to any of these is no, your PAM program has room to grow.

‍

Read the white paper: The Next Phase of PAM: Governing Non-Human Identity at Scale. The vendor-agnostic playbook for completing your privileged access program across every vault and every cloud.

See how Oasis fits into your stack: How Oasis Completes Your PAM Strategy. The architecture, the six capabilities that close the gap, and what deployment looks like alongside your existing vaults.