Notifications
Clear all
Topic starter
06/06/2026 1:59 am
TL;DR: Cloud-native vaults simplify developer workflows, but decentralized secrets storage across cloud, SaaS, and on-prem systems creates visibility gaps, inconsistent governance, and stale credentials, according to Oasis Security. The real issue is not where secrets live, but whether policy, rotation, and decommissioning can be enforced consistently across every identity source.
NHIMG editorial — based on content published by Oasis Security: Navigating the Complexity of Decentralized Secrets Management
By the numbers:
- Only 44% of organisations are currently using a dedicated secrets management system.
Questions worth separating out
Q: How should security teams handle secrets across multiple cloud-native vaults?
A: Security teams should standardize policy and inventory before they standardize storage.
Q: Why do decentralized secrets create governance risk in hybrid environments?
A: Decentralized secrets create governance risk because lifecycle actions become fragmented across tools, teams, and platforms.
Q: What do organisations get wrong about cloud-native vaults?
A: Organisations often assume cloud-native vaults solve governance by themselves.
Practitioner guidance
- Inventory every secret source Map cloud-native vaults, SaaS internal credential stores, CI/CD repositories, and on-prem systems into one live inventory so security teams can see where secrets exist and who depends on them.
- Centralize policy before migrating storage Define rotation, vaulting, exposure, and decommissioning rules once, then enforce them across AWS, Azure, SaaS, and on-prem accounts instead of pushing every team into a single vault.
- Treat rotation as a dependency-managed workflow Require application ownership, downstream dependency checks, and rollback criteria before automating rotation so changes do not break business-critical integrations.
What's in the full article
Oasis Security's full blog covers the operational detail this post intentionally leaves for the source:
- Native-vault examples for AWS SSM Parameter Store, Secrets Manager, and Azure Key Vault in real deployment patterns
- How Oasis describes unified policy enforcement across cloud, SaaS, and on-prem accounts
- The migration and rotation workflow details behind moving secrets between third-party vaults and cloud-native stores
- The product-specific context around lifecycle automation and business continuity handling
👉 Read Oasis Security's analysis of decentralized secrets management →
Secrets sprawl in hybrid estates: what IAM teams need to know?
Explore further
06/06/2026 3:23 am
Decentralized secrets management is a policy failure before it is a tooling failure. The article shows that the main breakage is not the existence of cloud-native vaults, but the loss of a consistent control layer across them. When secrets are scattered across cloud, SaaS, and on-prem systems, access governance becomes partial and reactive. The practitioner conclusion is that visibility and policy consistency must be designed as one programme, not treated as separate problems.
A few things that frame the scale:
- Only 44% of organisations are currently using a dedicated secrets management system, according to the 2024 State of Secrets Management Survey.
- 54% of organisations are dissatisfied with their current secrets management solution because not all secrets are secured, and 43% cite lack of central management.
A question worth separating out:
Q: How can teams reduce breakage when automating secret rotation?
A: Teams should map application dependencies, ownership, and fallback behavior before they automate rotation. Rotation fails when downstream systems are not ready for the change or when decommissioning is not coordinated. The safest model is lifecycle-aware automation that checks impact before updating the credential.
👉 Read our full editorial: Decentralized secrets management needs centralized policy, not a single vault
