Topic starter
22/09/2026 3:28 pm
TL;DR: Multi-vault secrets governance gives enterprises a way to control access, rotation, and audit activity across AWS Secrets Manager, Azure Key Vault, Google Secret Manager, Kubernetes, and HashiCorp Vault without forcing a full migration, according to Akeyless. The real value is consistent oversight, because fragmented vault logs, policy drift, and inconsistent rotation still leave identity teams without a reliable answer to who accessed what and when.
NHIMG editorial — based on content published by Akeyless: Multi-vault secrets governance and control across existing secret stores
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches.
Questions worth separating out
Q: What breaks when secrets are governed across multiple vaults without a single control model?
A: Governance breaks when the same identity has different rights, rotation logic, and audit formats in each store.
Q: Why do multi-vault environments create ongoing access risk?
A: They create risk because policy, rotation, and logging are often implemented differently in each vault.
Q: How can security teams tell whether multi-vault governance is actually working?
A: It is working when access decisions are consistent across vaults, rotation updates both the target system and the application path, and direct vault activity is still visible through native logs.
Practitioner guidance
- Define one governance layer for all connected vaults Inventory each secrets manager, its owner, and its identity model before adding policy or rotation controls.
- Separate central audit from direct-access control Restrict direct vault access with native permissions and network controls, then monitor exceptions separately from centrally governed requests.
- Test rotation against the application retrieval path Validate every rotation workflow end to end by confirming the credential changes in the target system and the application still retrieves the updated value from the expected store.
What's in the full article
Akeyless's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step setup for connecting AWS Secrets Manager, Azure Key Vault, Google Secret Manager, Kubernetes Secrets, and HashiCorp Vault
- Execution details for using the gateway model to mediate requests without copying secrets into a new store
- Rotation workflow examples that show how target-system updates and application retrieval paths stay aligned
- Practical guidance on when governance is enough and when staged migration makes more sense
👉 Read Akeyless's analysis of multi-vault secrets governance and control →
Multi-vault secrets governance: what changes for IAM teams?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
22/09/2026 3:29 pm
Multi-vault governance is really an identity control problem, not a secrets-store problem. The article is not about replacing one vault with another. It is about standardising access, rotation, and audit decisions across disparate secret stores so identity governance can operate across the estate. That makes this a NHI and IAM coordination issue, not a storage-platform discussion. Practitioners should treat the control plane, not the vault brand, as the unit of governance.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- 91% of former employee tokens remain active after offboarding, according to Entro Security, which shows how lifecycle gaps persist even when governance appears centralised.
A question worth separating out:
A: If teams can govern external managers in place, they avoid the operational disruption of moving every secret at once. That reduces the chance of outages, broken integrations, and rushed migration errors. It also lets security teams improve control quickly while preserving existing application dependencies. The practical outcome is better governance with less change risk.
👉 Read our full editorial: Multi-vault secrets governance closes the visibility gap in IAM
