Notifications
Clear all
Topic starter
22/07/2026 4:35 pm
TL;DR: Cross-cloud workload identity remains fragile because AWS, Azure, and GCP each trust different token dialects, forcing teams into brittle claim mapping, hand-built federation, and fallback secrets, according to Hush Security. The real risk is not just complexity: long-lived credentials persist when federation becomes too hard, and auditability fractures across clouds.
NHIMG editorial — based on content published by Hush Security: cross-cloud workload identity and federation across AWS, Azure, and GCP
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- Eliminate persistent fallback secrets Remove environment variables, service account JSON files, and other long-lived credential fallbacks from cross-cloud workloads.
- 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.
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.
👉 Read Hush Security's analysis of cross-cloud workload identity and federation →
Cross-cloud workload identity: are your controls keeping up across clouds?
Explore further
22/07/2026 4:39 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Cross-cloud workload identity still breaks when secrets fill federation gaps
