Join our Newsletter — 33% off our NHI Course

Multi-cloud secrets management: is your NHI governance keeping up?

 

(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 16521
Topic starter  

TL;DR: Akeyless says multi-cloud secrets management becomes risky because AWS, Azure, and GCP handle authentication, versioning, logging, and lifecycle controls differently, while compromised credentials contribute to 66% of attack scenarios. The governance gap is not centralisation alone but the mismatch between cloud-specific secret models and consistent NHI lifecycle control.

Editorial analysis by NHI Mgmt Group, based on content published by Akeyless: “Mastering Multi-Cloud Secrets: Your Guide to Overcoming Security Challenges”.

By the numbers:

  • Compromised credentials contribute to 66% of attack scenarios, exposing businesses to potentially hundreds of breaches annually.

Key questions

Q: How should security teams replace shared secrets for workloads that span multiple clouds?

A: Use federated workload identity so the workload proves who it is with a signed token or attestation instead of a shared static secret.

Q: Why do static secrets become more risky in multi-cloud estates?

A: Because static credentials stay valid long enough to be copied, cached, and reused across environments.

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

  • Normalise secret lifecycle policy Define one enterprise policy for creation, rotation, revocation, and deletion, then map how each cloud provider implements those states.
  • Inventory every cloud-native secret path Catalog AWS, Azure, and GCP secret stores, service account keys, managed identities, and token paths so ownership is explicit.
  • Remove standing secret dependencies Replace long-lived static credentials with temporary or just-in-time credentials wherever workloads and pipelines allow it.

Bottom line: Multi-cloud secrets management becomes a governance problem when provider-native lifecycle differences prevent consistent control over credentials.

What's in the full article

Akeyless's full guide covers the operational detail this post intentionally leaves for the source:

  • Cloud-by-cloud handling of authentication, secret versions, and deletion states across AWS, Azure, and GCP
  • Step-by-step guidance for automating credential rotation, distribution, and revocation across multi-cloud workloads
  • How unified monitoring and logging can be operationalised for cross-cloud secret investigations
  • How the Universal Secrets Connector works with existing cloud-native secret stores without migration

👉 Read Akeyless's guide to multi-cloud secrets management and NHI governance →

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 5 months ago
Posts: 17012
 

Multi-cloud secrets management is now an identity governance problem, not a vaulting problem. The article shows that cloud providers expose different secret lifecycles, authentication models, and audit behaviours, so centralisation alone does not create governance. The practitioner consequence is that NHI policy has to be normalised above the provider layer, or every cloud becomes its own exception domain.

A few things that frame the scale:

  • 88% of security professionals are concerned about secrets sprawl, with 49% of those in larger organisations described as "very concerned", according to the 2024 State of Secrets Management Survey.
  • Companies are dedicating an average of 32.4% of their security budgets to secrets management and code security, with US organisations leading at 40.8%, according to the State of Secrets in AppSec.

A question worth separating out:

Q: What should teams do first when cloud infrastructure incidents are driven by exposed secrets and misconfigurations?

A: The first step is to inventory where secrets, keys, and access paths exist, then verify which of them are exposed, overpermissive, or publicly reachable. From there, teams should tighten configuration baselines, remove unnecessary public access, and increase monitoring for abnormal use of cloud credentials. Without that sequencing, response stays reactive instead of reducing the attack surface.

👉 Read our full editorial: Multi-cloud secrets management exposes the NHI governance gap



   
ReplyQuote
Share:

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.