Multi-cloud secrets management exposes the NHI governance gap

At a glance

What this is: This guide argues that multi-cloud secrets management breaks down when credentials, tokens, and keys are governed as cloud-by-cloud exceptions rather than as one lifecycle.

Why it matters: It matters because IAM, PAM, and NHI teams need consistent control over secrets, rotation, visibility, and offboarding across cloud boundaries, or they inherit avoidable exposure.

By the numbers:

• 66% of attack scenarios
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.

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

Context

Multi-cloud secrets management is the discipline of controlling credentials, tokens, keys, and certificates across more than one cloud provider. In practice, the challenge is not whether secrets exist, but whether their lifecycle can be governed consistently when each cloud uses different identity primitives, logging models, and rotation mechanics.

This article is really about the NHI governance gap created by fragmented cloud control planes. It shows why teams that rely on provider-specific patterns end up with inconsistent access, uneven observability, and secrets that outlive their intended use. That is a typical problem for enterprises operating across AWS, Azure, and GCP.

The primary risk is not complexity by itself. It is the accumulation of standing access, divergent lifecycle states, and secret sprawl that make audits, incident response, and revocation harder than they should be.

Key questions

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. That makes offboarding incomplete, rotation inconsistent, and breach impact larger because one leaked key can be reused across environments until someone finds and revokes it.

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. In cloud and fintech environments, the problem is compounded by multiple replicas, integrations, and shared tooling, which makes revocation slower and harder to prove.

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.

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.

Technical breakdown

Why multi-cloud authentication becomes fragmented

Each cloud provider exposes a different identity and secrets model. AWS leans on temporary credentials and IAM policies, Azure typically centres access around Entra ID managed identities and OAuth tokens, and GCP supports both service account keys and temporary impersonation patterns. When teams manage these as separate operating models, they create policy drift, uneven revocation paths, and inconsistent assurance around who or what can authenticate. The issue is not just implementation variance. It is that the same workload can inherit different risk profiles depending on which cloud it touches.

Practical implication: Standardise the trust model for workload authentication before teams add more clouds or more secrets.

How secrets lifecycle drift creates hidden exposure

Secrets lifecycle management is the point where multi-cloud sprawl becomes a governance problem. Versioning, deletion, recovery, and rotation are handled differently across cloud-native secret stores, so a secret that is retired in one environment may still be valid in another. That mismatch stretches the credential exposure window and makes offboarding unreliable. In NHI terms, the real problem is not that a secret exists, but that it remains usable after the operational need has passed.

Practical implication: Treat rotation and revocation as cross-cloud lifecycle controls, not as isolated platform tasks.

Why observability and incident response break across clouds

Monitoring a multi-cloud secret estate is difficult because logs, audit trails, and access events are not emitted in a uniform way. Security teams may know a secret was accessed, but not have a consistent view of where, by whom, and under what conditions across all providers. That creates blind spots for detection, forensics, and emergency revocation. When access telemetry is fragmented, the organisation cannot reliably reconstruct secret use or prove that access was limited to the intended scope.

Practical implication: Unify secret access telemetry before you rely on audit evidence for detection or compliance.

Threat narrative

Attacker objective: The attacker wants durable, cross-environment access that survives normal rotation and exposes sensitive data or cloud control paths.

1. Entry occurs when a long-lived secret, API key, or token is exposed in code, configuration, messaging, or a cloud-native secret store.
2. Escalation follows when the exposed credential works across multiple cloud environments or survives beyond its intended lifecycle, allowing broader access than the original use case.
3. Impact arrives as attackers move laterally, exfiltrate data, or maintain persistent access through unmanaged secret copies and inconsistent revocation states.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• GitHub Dependabot Breach — GitHub Dependabot tokens stolen and abused to push malicious commits to repositories.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Secret sprawl is the clearest sign that NHI governance has been fragmented by platform boundaries. The more teams rely on cloud-native exception handling, the more likely they are to duplicate credentials, leave stale versions behind, and weaken auditability. That pattern aligns with OWASP Non-Human Identity Top 10 concerns around visibility, privilege, and lifecycle control. The practitioner takeaway is simple: if a secret can exist in three places, it will eventually be governed as three different risks.

Ephemeral credential trust debt: The article’s emphasis on JIT secrets and secretless authentication points to a larger problem in modern cloud governance, which is that static credentials accumulate unresolved trust over time. Long-lived secrets are not just harder to rotate; they force security teams to carry forward assumptions about scope, ownership, and revocation that rarely stay true across multi-cloud environments. The implication is that identity design should reduce the number of credentials that ever need lifecycle rescue.

Unified visibility only matters if it is paired with enforceable revocation. Central dashboards and consolidated logs help, but they do not solve the underlying control problem unless teams can revoke access across providers with consistent policy. This is where NIST CSF access governance and OWASP NHI lifecycle thinking intersect: the control must be portable, not just observable. Practitioners should judge tooling by whether it can close the loop from detection to revocation without manual translation between clouds.

From our research:

• 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.
• That same governance gap is explored further in Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs, where offboarding and revocation are treated as core controls rather than cleanup tasks.

What this signals

Ephemeral credential trust debt: multi-cloud teams should treat every surviving static secret as accumulated trust that has not been revalidated. The more clouds, vaults, and CI/CD systems in play, the more likely that trust debt will outlive the system it was meant to protect. This is where inventory, rotation, and revocation become one programme, not three separate ones.

A practical identity programme for multi-cloud environments needs to connect governance to execution. That means using the OWASP Non-Human Identity Top 10 as a control checklist, and the NIST Cybersecurity Framework 2.0 as the operating model for protecting, detecting, and recovering when credential exposure occurs.

For practitioners

• 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.
• Audit secret sprawl outside managed stores Search code, configuration files, and CI/CD systems for credentials that exist outside approved secret managers, then remove or rotate them on a defined schedule.
• Test cross-cloud revocation paths Verify that a revoked credential is actually invalidated in every environment where it may have been copied, cached, or inherited through integration.

Key takeaways

• Multi-cloud secrets management fails when each cloud is governed as a separate identity universe rather than one lifecycle.
• Static secrets create trust debt, because every extra day they remain valid increases the chance that exposure turns into access.
• The practical fix is cross-cloud lifecycle control, with secretless authentication and revocation paths that actually close everywhere access exists.

Key terms

• Hybrid cloud secrets management: Hybrid cloud secrets management is the process of issuing, storing, rotating, and revoking credentials across public cloud, private cloud, and on-premises systems. The challenge is consistency, because each environment can enforce different access and lifecycle rules for the same identity artefacts.
• 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.
• Ephemeral Credentials: Ephemeral credentials are short-lived access artefacts issued for a limited task or session. They reduce the window for abuse, but they only improve security when paired with strong scope limits, telemetry, and automatic revocation at task completion.
• 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:

• 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

👉 Akeyless's full guide covers cloud-by-cloud authentication, lifecycle automation, and cross-platform visibility detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.