What breaks when teams keep one vault per cloud?

Why one vault per cloud fractures policy and audit

A separate vault in each cloud turns secrets governance into a set of provider-specific islands. Policy decisions, audit trails, ownership, and access review all get enforced differently, so the same secret may be governed one way in one environment and another way elsewhere. That makes it harder to answer a basic question: who can use which credential, under what conditions, and with what evidence?

The practical issue is not just duplication. When the control plane is split, teams often lose consistency in how secrets are named, stored, approved, rotated, and retired. A vault strategy should make governance simpler to prove, not force every cloud team to reconstruct the same control story in its own dialect.

Why rotation and lifecycle drift across providers

Rotation becomes fragile when each cloud uses a different secret format, API, expiry model, or dependency chain. A vault pattern that works cleanly in one platform may fail to map to another cloud’s IAM or application runtime, so renewal schedules slip, automation breaks, and exceptions accumulate. Over time, the lifecycle of a credential becomes tied to the weakest provider-specific process.

That is why the strongest programs treat rotation as a cross-environment control, not a local convenience. If a credential cannot be rotated consistently, it usually means the surrounding ownership, dependency mapping, or service integration is still too cloud-specific to support reliable governance.

For deeper background on credential rotation and lifecycle challenges, see Guide to NHI Rotation Challenges and NHI Lifecycle Management Guide, both of which cover the operational failure points that appear when rotation and offboarding are not managed as a single lifecycle.

Why multi-vault sprawl increases blast radius and weakens control

Multiple vaults can look like separation, but they often create more places to misconfigure access. Teams duplicate role assignments, secret grants, break-glass paths, and policy exceptions across clouds, which increases the chance that one environment ends up overprivileged. If a vault admin, CI/CD integration, or application token is compromised, the attacker benefits from the same fragmentation that slowed defenders down.

One useful way to think about this is that vault sprawl expands the number of trust boundaries you must monitor. A single cross-cloud view helps you spot overprivilege, shared credentials, and stale secrets sooner; a scattered model hides those patterns until an audit or incident exposes them. NHIMG’s Azure Key Vault Contributor escalation 2024 shows how a seemingly narrow permission can become full secret exposure when policy and access design are too loose.

If you want a broader view of how sprawl and rotation interact, Guide to the Secret Sprawl Challenge is directly relevant because it ties vault growth, leaked credentials, and remediation pressure back to the same control gap.

What a cross-cloud vault model needs to work

A workable design usually depends on central policy, consistent inventory, and one operational standard for secret issuance and retirement. The goal is not necessarily one physical product for every cloud, but one governance model: common naming, common ownership, common rotation triggers, and common evidence for audit. Without that, “multi-cloud” becomes “multi-standard,” which is where controls start to drift.

Practitioners should also decide which differences are acceptable and which are not. For example, cloud-specific encryption details or native integrations may vary, but access review cadence, revocation rules, and logging expectations should not. If those basics cannot be standardized, the organization should assume its vault architecture is already creating governance debt.

Risk and Threat Considerations

Fragmented vaulting raises both exposure and detection risk. A secret that is properly managed in one cloud can remain long-lived, overprivileged, or poorly audited in another, and attackers often look for exactly those inconsistencies because they are easier to abuse than a tightly governed central model.

Failure mechanism: Separate vaults produce separate policies, logs, and rotation workflows, so control gaps emerge where ownership, expiry, or approval logic does not line up across providers.

Impact: Security teams lose reliable visibility into secret use, stale credentials persist longer, and a compromise in one cloud can spread through inconsistent access paths and weaker lifecycle enforcement.

Practitioner Guidance

What to verify: Confirm that you can answer the same audit questions, access questions, and rotation questions across every cloud from one control model, even if implementation details differ. If each cloud needs a different operating procedure, the architecture is already fragmented at the governance layer.

What to prioritise: Standardise ownership, expiry, logging, and revocation before adding more vault instances. A single consolidated inventory is more valuable than a visually tidy multi-vault diagram if the latter still leaves secret lifecycle decisions inconsistent.

Common mistake: Treating cloud-native vault adoption as a control improvement by itself. It only becomes an improvement when the organisation can prove that policy and rotation are still coherent end to end.

Practitioner takeaway: The real test is not how many vaults you run, but whether every secret still behaves like it belongs to one governed lifecycle with one audit story and one revocation path.

Related resources from NHI Mgmt Group

• What breaks when teams keep treating cloud-delivered IT services like one-time hardware purchases?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities in cloud environments?
• What breaks when teams keep on-premises access models in the cloud?