Notifications
Clear all
Topic starter
07/06/2026 8:27 pm
TL;DR: AWS’s outbound identity federation lets workloads use short-lived signed JWTs instead of long-lived keys for external access, reducing secret sprawl and rotation burden across AWS, Azure, GCP, and SaaS integrations, according to Clutch Security. Static credentials assume the trust boundary is stable; federated access replaces that assumption with ephemeral, verifiable identity.
NHIMG editorial — based on content published by Clutch Security: AWS outbound identity federation and its implications for NHIs
Questions worth separating out
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.
Q: Why do federated workload tokens reduce NHI risk in multi-cloud environments?
A: Federated tokens reduce risk because they are short-lived, issued on demand, and validated against a trusted issuer instead of being copied into files, chat tools, or ticketing systems.
Q: How do teams know whether cross-cloud federation is actually improving governance?
A: Look for fewer persistent credentials, fewer secret-rotation exceptions, and clearer issuer and audience mappings for external services.
Practitioner guidance
- Inventory cross-cloud integrations that still rely on persistent secrets Map every AWS workload that authenticates to Azure, GCP, or SaaS with API keys, client secrets, or password-based service accounts.
- Convert external authentication to federated trust flows Replace stored credentials with issuer-based trust, validate audience and issuer claims, and scope permissions to the smallest workload identity that actually needs access.
- Retire secret rotation as the primary control for eligible workloads If an integration can use short-lived federated tokens, remove the secret from rotation schedules, ownership trackers, and exception lists.
What's in the full article
Clutch Security's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step AWS Console and Terraform enablement for outbound identity federation
- Exact token request and exchange workflow for AWS workloads authenticating to Azure Entra ID
- Implementation notes on audience claims, issuer validation, and Azure propagation delay
- Federator project updates for teams migrating existing cross-cloud integrations
👉 Read Clutch Security's analysis of AWS outbound identity federation for NHIs →
AWS outbound federation: what it means for NHI controls?
Explore further
07/06/2026 10:21 pm
Persistent cross-cloud secrets are now a governance choice, not a technical necessity. Once a platform can issue short-lived signed identity assertions natively, keeping static API keys in circulation reflects a control failure as much as an architecture decision. The problem is not just leakage risk, it is the continued acceptance of credentials that outlive the workload, the operator, and sometimes the entire project. Practitioners should treat remaining long-lived keys as exceptions that require explicit justification.
A few things that frame the scale:
- 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to The 2024 Non-Human Identity Security Report.
- Another finding from the same research shows that 59.8% of organisations see value in simplifying non-human access management with dynamic ephemeral credentials.
A question worth separating out:
Q: How should security teams prioritise migration from secrets to federation?
A: Start with high-blast-radius workloads, vendor integrations that already support OIDC, and any service account that currently stores a secret outside the cloud provider. Then remove the old credential path entirely instead of running federation and static keys in parallel for long periods.
👉 Read our full editorial: AWS outbound identity federation changes multi-cloud NHI governance
