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.
At a glance
What this is: This guide argues that multi-cloud secrets management breaks down when cloud-specific credential models, lifecycle states, and logging practices create fragmented control over non-human identities.
Why it matters: It matters because IAM, PAM, and NHI teams need one governance model for credentials that span AWS, Azure, and GCP, or they inherit inconsistent rotation, weak visibility, and audit gaps.
By the numbers:
- Compromised credentials contribute to 66% of attack scenarios, exposing businesses to potentially hundreds of breaches annually.
👉 Read Akeyless's guide to multi-cloud secrets management and NHI governance
Context
Multi-cloud secrets management is the operational problem of controlling credentials, tokens, keys, and their lifecycle across more than one cloud provider. The challenge is governance fragmentation: each cloud implements authentication, logging, and version handling differently, so the control model stops being uniform as soon as the environment becomes multi-cloud.
The article frames this as an NHI problem because secrets are non-human identities in practice. Once those credentials are scattered across AWS, Azure, and GCP, the organisation has to manage inventory, rotation, revocation, and observability across inconsistent native systems instead of a single lifecycle policy.
That makes the issue more than administration overhead. It becomes a control-plane design problem for identity teams, because gaps in secret state management and auditability create the conditions for standing access, slow response, and compliance drift.
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. Then scope the resulting credential tightly to the request and make the trust relationship revocable when the workload, supplier, or environment changes.
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. When access is not bound to a short-lived identity session, one exposed secret can outlive the task that needed it and become reusable in places the original system never intended.
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. Those symptoms usually mean the organisation has separate platform practices rather than one governed lifecycle, which makes revocation and incident response slow and unreliable.
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.
Technical breakdown
Why multi-cloud secret state becomes inconsistent
AWS, Azure, and GCP do not treat secret lifecycle the same way. AWS secret versions are immutable, Azure supports soft deletion, and GCP keeps explicit version histories. Those differences matter because rotation, rollback, and revocation are not just operational steps, they are governance states that determine whether a secret can still be used after change. In a multi-cloud environment, teams often inherit three different state machines instead of one policy model, which makes error handling and recovery harder than the credentials themselves. The real technical issue is not storage, but the lack of a shared control semantics for NHI credentials.
Practical implication: Treat lifecycle state as a governance boundary and map how each cloud records creation, versioning, deletion, and recovery before standardising policy.
How authentication fragmentation creates NHI risk
Each cloud provider uses a different trust pattern. AWS emphasises temporary credentials under IAM policies, Azure depends on managed identities and OAuth2 tokens, and GCP supports both long-lived service account keys and temporary impersonation. That variation creates inconsistent control surfaces for the same underlying NHI problem: who or what can authenticate, for how long, and under what conditions. When teams manage those patterns separately, they often end up with mixed credential lifetimes, uneven revocation paths, and uneven telemetry. The technical burden is therefore identity normalisation across cloud boundaries, not just secret storage.
Practical implication: Standardise authentication patterns by credential type and refuse to let each cloud define its own exception path for the same workload.
Why observability collapses across providers
Logging is fragmented because each cloud exposes different fields, retention patterns, and access trails. That means the security team does not get a single audit surface for secret access, rotation, and revocation events. Instead, investigations require correlation across multiple provider-native telemetry sources, each with different semantics and timing. For NHI governance, that is a material failure because credentials are only governable when their use can be observed and tied back to ownership, purpose, and lifecycle state. Without that linkage, secret sprawl becomes invisible until an incident forces discovery.
Practical implication: Build a normalised audit trail for secret activity across providers so investigators can reconstruct access without stitching together incompatible log formats.
Threat narrative
Attacker objective: The attacker wants durable access through exposed or unmanaged credentials that can be reused across cloud boundaries for breach, persistence, or lateral movement.
- Entry occurs through compromised credentials, which the article says are involved in 66% of attack scenarios.
- Escalation happens when fragmented authentication and inconsistent secret lifecycle handling leave standing or stale access paths in place.
- Impact follows when unmanaged secrets expand the attack surface, delay detection, and complicate recovery across cloud environments.
Breaches seen in the wild
- Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
- Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Secret sprawl is a control failure before it is a storage failure. When credentials are duplicated across cloud-native tools and providers, ownership, rotation, and revocation become inconsistent by design. That is why the governance gap appears in audit and incident response first, then in compromise impact later. Practitioners should treat sprawl as an inventory and authority problem, not just an operational nuisance.
Compromised credentials remain the dominant attack path because lifecycle controls lag operational reality. The article’s 66% figure is a reminder that secret exposure is not an edge case, it is a mainstream intrusion path. The implication is that identity teams need lifecycle enforcement that spans creation, use, version change, and revocation across all clouds, or the attack surface remains structurally open.
Unified visibility is the minimum viable control, but not the endpoint. A single dashboard matters only if it reflects consistent ownership, policy, and revocation authority across AWS, Azure, and GCP. Without that, monitoring becomes reporting, not governance. The real practitioner task is to make cross-cloud observability actionable enough to drive access decisions.
Multi-cloud secret governance needs a named concept: credential lifecycle normalisation. That means treating different provider-native secret behaviours as one governed lifecycle with common policy intent, even when the backend implementation differs. This is the only way to avoid policy drift across clouds and to keep NHI controls enforceable at enterprise scale.
From our research library:
- 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.
- Read next: Secrets Management Guide
What this signals
Credential lifecycle normalisation: multi-cloud programmes need one policy model for issuance, rotation, revocation, and deletion, even when provider-native implementations differ. If AWS, Azure, and GCP define those states differently, the enterprise will keep inheriting policy drift across every workload that depends on secrets.
The operational signal to watch is whether secret access can be traced back to a single owner and a single purpose across all clouds. When that answer depends on which provider generated the log, the programme has observability without governance.
Secrets sprawl remains the pressure point: 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. That concern is justified when multi-cloud estates multiply the number of places where static or mis-scoped credentials can persist.
For practitioners
- 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.
- Unify audit data across providers Correlate secret access, version change, and revocation events into one investigation workflow instead of relying on native logs alone.
- Prebuild cross-cloud incident revocation Document how to revoke compromised credentials quickly in each cloud and assign clear ownership before an incident occurs.
Key takeaways
- Multi-cloud secrets management becomes a governance problem when provider-native lifecycle differences prevent consistent control over credentials.
- The article links compromised credentials to 66% of attack scenarios, underscoring how exposed secrets translate into real intrusion risk.
- The practical fix is not just centralisation, but normalised lifecycle policy, unified observability, and faster revocation across clouds.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centres on exposed and scattered credentials across multiple clouds. |
| NHI-05 — Overprivileged NHI | Multi-cloud secrets often retain excessive access scope across cloud-native identity systems. | |
| NHI-07 — Long-Lived Secrets | The article directly recommends just-in-time credentials over standing static secrets. | |
| Recommendation — Scan multi-cloud estates for exposed secrets and remove any duplicated or unmanaged credentials. Reduce NHI blast radius by narrowing permissions on cloud credentials and service identities. Replace long-lived cloud secrets with short-lived credentials wherever workload design allows it. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential lifecycle, rotation, and revocation are central to the article's guidance. |
| Recommendation — Apply authenticator management controls to enforce rotation and revocation across cloud secrets. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Multi-cloud secrets governance depends on consistent access and entitlement control. |
| Recommendation — Review access permissions for cloud secrets and align them to a single enterprise policy. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article treats compromised credentials as a primary intrusion path. |
| Recommendation — Map exposed secrets to credential access and lateral movement paths in your detections. | ||
Key terms
- Multi-Cloud Secrets Governance: The policy model that governs how secrets, tokens, and workload credentials are issued, rotated, revoked, and audited across more than one cloud. It matters because separate stores in separate clouds quickly become separate trust models, which fragments accountability.
- Secrets Sprawl: The uncontrolled proliferation of sensitive credentials, API keys, tokens, passwords, certificates, across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
- Credential Lifecycle: Credential lifecycle is the process of issuing, rotating, expiring, and revoking secrets, certificates, and tokens across their usable life. For non-human identities, lifecycle discipline is the core control that separates temporary access from persistent exposure.
- Secretless Authentication: Secretless authentication is a pattern that keeps long-lived credentials out of application code and runtime memory wherever possible. Instead of exposing secrets directly to workloads, the access path mediates credential delivery at connection time, reducing the chance that stolen configuration or code reveals reusable access.
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
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on September 7, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org