AWS Just Made Cross-Cloud Federation Easier Than Ever. Here's Why It Matters for Your NHIs

The era of long-lived keys for cross-cloud authentication should be over. AWS's new Outbound Identity Federation makes eliminating them a reality.

Every security team knows the uncomfortable truth: cross-cloud authentication has been a ticking time bomb. When your AWS workloads need to talk to Azure, GCP, or third-party SaaS platforms, what's typically sitting in the middle? Long-lived API keys. Static credentials. Secrets that were created three years ago by someone who left the company, stored in a config file that's been copied to seventeen different environments.

We've seen this pattern exploited in breach after breach. The attackers don't need sophisticated zero-days. They just need one leaked key with cross-cloud access.

That's why AWS's recent announcement of IAM Outbound Identity Federation is significant. Not because it's revolutionary technology, but because it removes the excuses. The tooling now exists, natively within AWS, to eliminate long-lived credentials for external service authentication entirely.

What AWS Just Shipped

AWS IAM Outbound Identity Federation allows any IAM principal (roles, users, or service accounts) to obtain cryptographically signed JWTs that assert their AWS identity to external services. Instead of storing API keys or passwords to authenticate with third-party providers, your AWS workloads can now request short-lived tokens on demand.

Here's how it works:

1. Your application calls the new GetWebIdentityToken API using its existing AWS credentials
2. AWS STS returns a signed JWT containing identity claims about the calling principal
3. Your application presents this token to the external service
4. The external service validates the token against AWS's OIDC endpoints
5. Upon verification, the external service grants access. No static credentials involved.

Source: Simplify access to external services using AWS IAM Outbound Identity Federation

The tokens are ephemeral by design: they can be configured to last anywhere from 60 seconds to one hour, with a default of just five minutes. When the token expires, it's useless to attackers. No rotation schedules to manage. No secrets sprawl to track.

Why This Changes the Game for Multi-Cloud Security

For organizations operating across AWS, Azure, and GCP (which at this point is most enterprises), managing cross-cloud authentication has been a constant headache. The typical pattern looks like this:

• Create a service account in the target cloud
• Generate an API key or credential
• Store that credential somewhere "secure" (often a vault, sometimes a config file, occasionally a Slack message)
• Hope nobody leaks it
• Set a calendar reminder to rotate it in 90 days
• Forget about the calendar reminder

This model has fundamental problems. Static credentials don't know who's using them. They can be copied, shared, and exfiltrated without detection. They accumulate over time, creating shadow identities that outlive the projects and people who created them.

AWS Outbound Identity Federation flips this model. Instead of creating new credentials in external systems, your existing AWS identities become the credential. The external service trusts AWS as an identity provider and accepts tokens signed by AWS. No new secrets to create. No long-lived credentials to manage. No rotation schedules to forget.

The Broader Shift: Cloud Providers Enabling Secretless Architectures

AWS isn't the first to enable this pattern. Azure has Workload Identity Federation. GCP has Workload Identity. What makes AWS's announcement significant is that it completes the picture for bidirectional federation across all major cloud providers.

Consider what's now possible:

• AWS workloads can authenticate to GCP using signed JWTs instead of GCP service account keys
• AWS workloads can authenticate to Azure using federated tokens instead of client secrets
• AWS workloads can authenticate to SaaS platforms that support OIDC without embedded API keys

This creates a path to truly secretless authentication for cross-cloud and multi-cloud architectures. The technology exists. The standards are mature. The only remaining question is adoption.

What This Means for Your NHI Strategy

For security teams managing Non-Human Identities at scale, AWS Outbound Identity Federation opens up immediate opportunities:

Reduce your attack surface. Every long-lived credential you eliminate is one less secret that can be leaked, stolen, or misused. Ephemeral tokens generated on-demand create dramatically smaller windows of exposure.

Simplify lifecycle management. Static credentials require rotation, monitoring, and ownership tracking. Federated tokens eliminate this operational overhead entirely. There's nothing to rotate because there's nothing persistent.

Improve blast radius containment. When credentials are ephemeral and scoped to specific workloads, a compromise of one system doesn't give attackers persistent access to external services.

Enable Zero Trust enforcement. Federated authentication naturally aligns with Zero Trust principles: every access request requires fresh verification, tokens carry identity context that can be validated, and trust is established dynamically rather than statically.

Implementation Considerations

Adopting outbound federation requires coordination across multiple layers:

1. Enable the feature in your AWS account through the IAM console
2. Update IAM policies to grant sts:GetWebIdentityToken permission to workloads that need it
3. Configure external services to trust your AWS account's issuer URL
4. Modify applications to request tokens and present them to external services

The AWS documentation provides code examples and detailed guidance. The core workflow is straightforward, but the devil is in the details: you'll need to map token claims to permissions in external services, decide on appropriate token lifetimes, and update application code.

For organizations with hundreds or thousands of cross-cloud integrations, this migration won't happen overnight. But every integration you convert from static credentials to federated tokens reduces your exposure.

How to Enable AWS Outbound Identity Federation

Getting started with Outbound Identity Federation requires enabling the feature at the account level. You can do this through the AWS Console or Infrastructure as Code.

Enabling via AWS Console

Navigate to IAM in the AWS Console, then select Account settings under Access management in the left navigation pane. From there, enable Outbound Identity Federation for your account.

Once enabled, AWS generates a unique issuer URL for your account that hosts the OIDC discovery endpoints at /.well-known/openid-configuration and /.well-known/jwks.json. External services use these endpoints to validate tokens issued by your account.

Enabling via Terraform

For organizations managing infrastructure as code, you can enable the feature using Terraform:

This creates the federation configuration and outputs your account's issuer URL, which you'll need when configuring trust relationships with external identity providers.

Federating with Microsoft Entra ID

When federating AWS workloads with Microsoft Entra ID (formerly Azure AD), you must use a specific audience value. Entra ID expects the aud claim in the JWT to be set to api://AzureADTokenExchange. This is a requirement from Microsoft for workload identity federation scenarios.

Note: After configuring the federation trust in Azure via Terraform or the Azure portal, it can take up to an hour for the federation connection to sync across Microsoft's endpoints. If your initial token exchange attempts fail with authentication errors, wait and retry before troubleshooting further. This is a known propagation delay on the Azure side.

To request a token with the correct audience for Entra ID federation, use the AWS CLI:

This returns a signed JWT that you can then exchange for Azure credentials using the Azure CLI:

The same pattern applies for other cloud providers and SaaS platforms that support OIDC federation. Each will have their own audience requirements and token exchange mechanisms.

Clutch Federator: Updated for AWS Outbound Federation

At Clutch, we've been advocating for secretless cloud authentication since day one. Our open-source Federator project has helped organizations automate the setup of federated roles across AWS, GCP, and Azure, eliminating long-lived keys with Terraform scripts and step-by-step tutorials.

With AWS's new Outbound Identity Federation capability, we've updated Federator to support these enhanced federation flows. The latest version includes:

• Terraform modules for configuring AWS outbound federation alongside existing GCP and Azure federation patterns
• Updated tutorials covering the new GetWebIdentityToken workflow
• Best practices for migrating existing cross-cloud integrations to ephemeral tokens

If you're already using Federator, the update streamlines adoption of AWS's new capability. If you're new to cloud federation, Federator provides a comprehensive starting point for eliminating long-lived credentials across your entire multi-cloud environment.

Explore the updated Federator here.

The Bottom Line

AWS Outbound Identity Federation isn't just a feature release. It's a signal that the industry has reached consensus on how cross-cloud authentication should work. Short-lived, cryptographically signed tokens. Dynamic trust establishment. No static secrets.

The organizations that move fastest to adopt these patterns will dramatically reduce their NHI attack surface. The ones that don't will continue managing the same credential sprawl, rotation chaos, and breach risk that has plagued multi-cloud environments for years.

The tools are here. The excuses are gone.