TL;DR: Multi-cloud secrets management is hard because AWS, Azure, and GCP each handle credentials, versions, logging, and lifecycle differently, while compromised credentials account for 66% of attack scenarios, according to Akeyless. The governance problem is not just centralisation, but eliminating standing secrets, inconsistent rotation, and fragmented visibility across environments.
NHIMG editorial — based on content published by Akeyless: Multi-Cloud Secrets Management: Best Practices for Security and Efficiency
By the numbers:
- 66% of attack scenarios, contribute to 66% of attack scenarios, exposing businesses to potentially hundreds of breaches annually.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
Questions worth separating out
Q: What breaks when cross-cloud access still depends on long-lived secrets?
A: Persistent secrets create reusable access that outlives the workload, the operator, and often the original business need.
Q: Why do long-lived secrets increase breach risk in cloud and fintech environments?
A: Long-lived secrets extend the time an attacker can reuse stolen access, which increases the chance of data theft, lateral movement, and compliance failure.
Q: How do security teams know if multi-cloud secret governance is failing?
A: Look for duplicated credentials, inconsistent rotation dates, secrets stored outside approved managers, and audit trails that differ by provider.
Practitioner guidance
- Centralise secret lifecycle policy Define one policy for creation, rotation, revocation, and recovery, then map it to each cloud’s native identity and secrets mechanism so the lifecycle is governed consistently.
- Replace long-lived secrets with ephemeral access Use just-in-time credentials and secretless authentication wherever workloads can authenticate through trusted identities such as cloud roles or federation.
- Unify audit trails across cloud providers Aggregate access logs and secret-use telemetry into one review path so incident responders can reconstruct who accessed which credential and when.
What's in the full article
Akeyless's full guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step handling of AWS, Azure, and GCP authentication differences for secrets and workload identity
- Implementation detail for unified rotation, revocation, and version control across cloud-native secret stores
- How the Universal Secrets Connector works with existing vaults and cloud tools without forcing migration
- The article’s practical guidance on combining JIT credentials with CI/CD and infrastructure-as-code workflows
👉 Read Akeyless's guide to multi-cloud secrets management and NHI controls →
Multi-cloud secrets management: is your NHI governance keeping up?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
Multi-cloud secrets management is an NHI lifecycle problem, not a storage problem. The source article treats secrets as operational objects that need centralisation, but the real governance issue is lifecycle coherence across clouds. When creation, rotation, versioning, and revocation differ by provider, the organisation loses a single accountable control surface. Practitioners should frame this as cross-cloud NHI lifecycle governance, not just vault administration.
A few things that frame the scale:
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to the Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which is why lifecycle control and inventory discipline matter before incidents happen.
A question worth separating out:
Q: Should organisations prioritise secretless authentication before expanding multi-cloud use?
A: Yes, when workloads can authenticate through trusted identities instead of static secrets. Secretless patterns reduce the number of credentials that need rotation, lower the chance of secret sprawl, and make cross-cloud access easier to govern. They are especially valuable when teams already struggle with cloud-by-cloud lifecycle inconsistency.
👉 Read our full editorial: Multi-cloud secrets management exposes the NHI governance gap