Why do cloud-specific secret vaults create governance problems for data platforms?

Cloud-specific vaults can tie access to one provider or one workspace, which makes migration, cloning, and multi-cloud operation harder to control. That often leads to duplicate secrets, inconsistent permissions, and uneven lifecycle management. The risk is not only technical lock-in. It is fragmented accountability for workload credentials.

Why This Matters for Security Teams

Cloud-specific vaults are not just a storage choice. They shape who can request, rotate, clone, and revoke secrets across data pipelines, orchestration layers, and analytics workloads. When vaults are bound to a provider account or workspace, governance fragments as soon as a platform team needs portability, cross-account replication, or shared control across environments. That creates duplicated secrets, inconsistent access reviews, and unclear ownership for workload credentials.

This is why NHI governance has to be treated as a lifecycle and accountability problem, not a vault feature checklist. The issue is amplified when teams rely on static secrets instead of ephemeral issuance, because secret copies persist long after the pipeline, cluster, or workspace that created them has changed. NIST’s NIST Cybersecurity Framework 2.0 emphasises governance and continuous risk management, but cloud-bound vault models often make those activities harder to execute consistently. NHIMG’s Guide to the Secret Sprawl Challenge and Ultimate Guide to NHIs — Static vs Dynamic Secrets both point to the same operational failure: secret growth outpaces governance.

In practice, many security teams encounter vault sprawl only after a migration, merger, or incident has already exposed how many hidden copies existed.

How It Works in Practice

Cloud-specific vaults usually inherit the trust and policy model of one provider, which is efficient inside that boundary but awkward everywhere else. For data platforms, that means the vault often becomes coupled to a specific subscription, project, account, or workspace. Once a team clones a lakehouse, rebuilds an ELT pipeline, or splits environments across clouds, the secret model has to be re-created instead of carried forward cleanly.

Operationally, this creates three recurring problems. First, secrets are duplicated across environments to preserve uptime during migration. Second, permissions diverge because each workspace has different local administrators and lifecycle rules. Third, revocation becomes uneven because rotation is handled by each cloud or platform separately, rather than through one policy layer. Current guidance suggests treating workload credentials as NHI assets with owner, purpose, TTL, and revocation path attached. That is the governance model described in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and reinforced by the OWASP Non-Human Identity Top 10.

A better practice is to centralise policy while decentralising issuance: use a control plane that can issue short-lived credentials, map access to workload identity, and enforce rotation and revocation based on task context rather than cloud locality. That aligns with NIST control thinking in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where least privilege and configuration management intersect. This also reduces the audit gap caused by duplicate secrets because the system of record remains the policy layer, not the individual vault instance. These controls tend to break down when data platforms span multiple clouds and legacy pipelines still require long-lived shared secrets because ownership and revocation cannot be enforced consistently.

Common Variations and Edge Cases

Tighter central control often increases migration effort and platform overhead, so organisations have to balance portability against operational simplicity. That tradeoff is real, especially for data platforms that mix managed services, self-hosted jobs, and third-party connectors. Best practice is evolving, but there is no universal standard for how much of the secret lifecycle should be centralised versus delegated to each cloud.

One common edge case is a hybrid estate where the vault is cloud-native for one environment and external for another. That can be workable if policy, identity, and audit logging remain consistent, but it often fails when teams copy secrets manually to support disaster recovery or temporary cutovers. Another edge case is analytics tooling that caches tokens locally or refreshes them outside the vault’s lifecycle controls. In those environments, the problem is not just storage location. It is that secret issuance, usage, and revocation are no longer governed as one process.

NHIMG’s Top 10 NHI Issues and 230M AWS environment compromise show why fragmented trust boundaries matter: once credentials are replicated across environments, containment becomes slower and accountability becomes harder to prove. In mature programs, the goal is not “one vault for everything” but one governance model for every secret, regardless of where it is physically stored.

Related resources from NHI Mgmt Group

• Why is it important to integrate identity and data governance?
• How does the consumer-secret-entitlement model help with governance at scale?
• Why do identity platforms create governance problems when they are not integrated?
• Why does embedded authorization create governance problems in regulated platforms?