Cross-cloud workload identity still breaks when secrets fill federation gaps

At a glance

What this is: This is an analysis of why cross-cloud workload identity remains difficult, and why teams still fall back to long-lived secrets when federation across AWS, Azure, and GCP becomes too brittle.

Why it matters: It matters because IAM and NHI teams need consistent, short-lived, auditable access for workloads and agents across clouds, not hand-maintained trust that silently drifts into secret sprawl.

By the numbers:

• 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits.
• 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches.

👉 Read Hush Security's analysis of cross-cloud workload identity and federation

Context

Cross-cloud workload identity is the problem of proving what a non-human workload is, and granting it access, when that workload moves across AWS, Azure, and GCP. The article’s core finding is that federating those identities remains fragile enough that many teams still rely on long-lived secrets instead of standards-based trust.

For IAM and NHI programmes, the issue is not whether federation exists in each cloud. The issue is whether those trust relationships can be maintained, audited, and retired without turning every workload into a custom integration project. At scale, that maintenance burden becomes a governance problem as much as a technical one.

Key questions

Q: How should security teams govern workload identity across mixed cloud environments?

A: Security teams should use a workload identity control plane that can issue short-lived credentials, enforce policy at access time, and preserve audit context across Kubernetes, VMs, CI/CD, and SaaS. The governance goal is consistency, not feature parity with human IAM. If one environment is covered differently from the rest, policy drift and evidence gaps will follow.

Q: Why do long-lived secrets still appear in cross-cloud workloads?

A: They usually appear because federation is harder to maintain than storing a key. When claim mapping, token exchange, or trust registration becomes brittle, teams take the shortcut and persist a secret. That creates a hidden control failure, because the credential survives long after the runtime need that justified it has changed.

Q: What breaks when cross-cloud identity has no unified audit trail?

A: Recertification, incident review, and accountability all break down because no one can easily reconstruct which workload accessed which cloud resource and under what trust relationship. Separate provider logs are useful, but they do not create programme-level governance. Without a single audit trail, access may be technically valid but operationally ungovernable.

Q: How do organisations reduce risk when a workload must span multiple clouds?

A: Use runtime-issued access, minimise trust edges, and retire any credential path that still depends on persistent secrets. The goal is to keep the identity ephemeral, the trust path explicit, and the audit trail centralised. If a workload can only function by preserving a static credential, the design is already carrying avoidable risk.

Technical breakdown

Why cross-cloud trust becomes a token translation problem

Each cloud identity system uses its own token exchange model, claim semantics, and policy engine. AWS relies on OIDC federation and role trust policies, Azure uses federated identity credentials, and GCP uses workload identity pools plus service account impersonation. The problem is not simply interoperability. It is that an assertion valid in one system often has no clean equivalent in another, so teams end up writing custom claim mappings and audience rules for every pairing. That creates brittle trust logic that is hard to standardise across clusters, clouds, and deployment patterns.

Practical implication: treat cross-cloud federation as a policy engineering problem, not a one-time integration.

Why short-lived workload credentials are hard to sustain

Modern workloads are ephemeral, which means static credentials are structurally a poor fit. Pods, functions, and autoscaling groups may exist only briefly, but many cross-cloud setups still fall back to long-lived keys or service account JSON files because the federation path is too complex to maintain. Once that happens, the identity model stops being runtime-issued and becomes stored-secret based. That shifts risk from access control into secret handling, rotation, and cleanup, where drift is far more likely and detection is weaker.

Practical implication: remove any fallback path that depends on persistent secrets crossing cloud boundaries.

Why cross-cloud audit trails fragment even when access works

Cross-cloud access can be technically functional and still be governance-poor. Each cloud emits its own logs, in its own schema, with no native unified view of which workload accessed what across the estate. That makes recertification, incident reconstruction, and policy enforcement difficult because identity intent has to be inferred from multiple control planes. In practice, this is where many programmes lose accountability: the access succeeded, but no one can easily prove who authorised it, how long it lived, or whether it still matches policy.

Practical implication: design for a single audit trail before expanding workload federation across multiple clouds.

NHI Mgmt Group analysis

Cross-cloud federation has become a policy translation problem, not a protocol problem. The article shows that the hard part is no longer whether OIDC or SAML exists, but whether an identity assertion can survive translation across cloud-specific claim vocabularies and authorisation models. That makes every cross-cloud trust relationship a custom governance artefact. Practitioners should treat federation design as an identity policy standardisation exercise, not a connector project.

Persistent secrets are the failure mode that appears when federation is too expensive to maintain. The article is explicit that teams fall back to long-lived keys when cross-cloud trust becomes brittle. That is a lifecycle failure, not merely a technical shortcut, because the old credential often persists after the new trust path exists. The implication is that secret retention becomes the hidden shadow layer beneath modern workload identity.

Unified audit is now a prerequisite for cross-cloud NHI governance. A workload that can move between clouds without a single inventory or audit trail cannot be governed as a coherent identity. Separate cloud logs may show activity, but they do not answer the accountability question at the programme level. Practitioners should regard identity visibility across clouds as a control objective, not a reporting convenience.

Identity blast radius grows when one workload identity is reused across multiple cloud boundaries. The article describes a world where every off-diagonal trust pairing adds another maintenance path and another failure point. That is why workload identity needs to be scoped by deployment context, not by organisational convenience. The practitioner lesson is to minimise the number of trust edges any one identity can traverse.

Zero standing privilege is easier to say than to sustain across clouds. The article’s runtime-issued, short-lived access model aligns with modern identity governance, but only if the lifecycle is fully automated across providers. Otherwise, teams reintroduce standing access through exceptions, fallback secrets, and manual renewal. The conclusion for IAM and NHI programmes is that ephemeral access must be supported end to end, or it will decay into persistence.

From our research:

• 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits, according to The 2025 State of NHIs and Secrets in Cybersecurity.
• 62% of all secrets are duplicated and stored in multiple locations, which means cross-cloud trust often inherits sprawl before it inherits governance.
• Use Ultimate Guide to NHIs to connect federated workload access, secret lifecycle, and offboarding into one governance model.

What this signals

Cross-cloud identity will keep failing in exactly the same place until teams stop treating federation as an integration success metric and start treating it as an identity lifecycle control. The real governance gap is not issuance, it is retirement, because every extra trust edge increases the chance that a workload keeps access longer than intended. That is why workload identity programmes need a single inventory and a single audit model before they scale into more clouds.

Identity blast radius: the term describes how quickly one workload trust decision expands across multiple cloud control planes. In practice, the blast radius grows when teams reuse the same identity across environments, then compensate with exceptions and fallback secrets. If your programme cannot answer where that identity exists, who can renew it, and how it is decommissioned, it is already behind the operational reality of multi-cloud access.

For practitioners

• Standardise cross-cloud trust on one issuer pattern Register a single identity issuer per environment and map it consistently into AWS, Azure, and GCP rather than building bespoke pairwise trust. That reduces the claim-mapping surface and makes policy drift easier to spot.
• Eliminate persistent fallback secrets Remove environment variables, service account JSON files, and other long-lived credential fallbacks from cross-cloud workloads. If federation fails, fix the federation path rather than preserving a secret-based bypass.
• Centralise workload inventory and audit Maintain one inventory of workloads, their cloud trust relationships, and their token lifetimes so access can be recertified and retired coherently. This is the only practical way to govern access across multiple cloud control planes.
• Align runtime renewal with workload lifespan Issue short-lived credentials that refresh automatically before expiry and die when the workload ends. For long-running services, renewal should be transparent to the application and visible to the identity team.

Key takeaways

• Cross-cloud workload identity fails when cloud-native trust models have to be translated into a common governance layer.
• Persistent secrets often reappear because federation is operationally harder than storage, which turns a technical gap into a lifecycle risk.
• Teams need one inventory, one audit trail, and short-lived runtime access if they want multi-cloud identity to remain governable.

Key terms

• Cross-cloud workload identity: The identity used by a workload to authenticate and authorise itself across multiple cloud providers. In practice, it must survive different token formats, claim semantics, and policy engines without falling back to persistent secrets or ad hoc trust mappings.
• Token exchange federation: A trust pattern where one identity assertion is exchanged for another credential recognised by a downstream system. For workloads, this is the mechanism that lets a runtime identity in one cloud obtain a native credential in another cloud without storing a long-lived key.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

What's in the full article

Hush Security's full post covers the operational detail this post intentionally leaves for the source:

• Exact federation setup flow for AWS, Azure, and GCP, including the issuer and audience values used in each cloud.
• Step-by-step token exchange sequence for pods that need to authenticate across multiple cloud providers.
• Details on how Hush rotates short-lived tokens before expiry and refreshes them for long-running workloads.
• Console-driven connector setup flow that shows the cloud-specific parameters to paste into each provider.

👉 The full Hush Security post covers the federation flow, token lifecycle, and cloud-specific setup details.

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 building or maturing identity controls across workloads, it is worth exploring.