In case you missed it, AWS presented on an interesting innovation at re:Invent 2025 that allows AWS workloads to authenticate to external services (such as Azure or Kubernetes) by exchanging their AWS identities for short-lived tokens. This completely eliminates the need to store any long-term API keys or passwords. And it is free for all services, per their announcement.
While this is fantastic news all unto itself, it really is a harbinger of change. The way we handle authentication is shifting, especially in the enterprise, and this is just the latest example.
The legacy approaches DevOps, IAM, and Security teams have used for access management of non-human identities (NHIs) across platforms, applications, and cloud resources have led to secret and vault sprawl, with credentials becoming the number one way attackers gain a foothold.
Now, we also face the challenge of securing access for agentic AI that needs to act on your behalf. All while dealing with the operational reality of shipping and scaling workloads quickly.
So, given what we know about the dangers of plaintext credentials and how attackers exploit them, and the fact that alternative approaches exist, why have we not changed how we authenticate our workloads?
Like with any massive effort, we need more than just new tech; we need a plan. We need insight into the current state and a way to track our progress as we move towards better solutions.
Let's take a closer look at AWS IAM Outbound Identity Federation and how GitGuardian can help you make the transition that will improve life for your security, IAM, DevOps, and development teams.
Moving Off Long-Term Credentials: Technology Is The Easy Part
At a high level, AWS IAM outbound identity federation provides a clean pattern for the common situation where an AWS workload needs to call an external service outside of AWS. Historically, that meant taking a credential issued by the external service and storing it somewhere close to the workload, hopefully in a secret manager, an environment variable, or a CI system. But far too often, they would end up in code or in plaintext in configuration files.
With outbound identity federation, a workload requests an AWS Security Token Service (STS) short-lived JSON Web Token (JWT) that asserts its identity. It then presents the JWT to the external service, which verifies it using AWS-published verification keys. Many platforms support this, including AWS, Azure, and Google Cloud. Teams running Kubernetes also have multiple options for implementing workload identity verification.
All Access Runs Through Identity
Across all identity-based authentication approaches, you are no longer standardizing on “where do we store the secret.” You are standardizing on “how do we prove identity.”
In AWS’s flow, token issuance is controlled by IAM permissions, and token properties such as audience, signing algorithm, and lifetime can be constrained by policy. AWS also gives each account an issuer URL with OIDC discovery endpoints that external services can use for verification.
That is the identity story. Identity becomes the control plane for everything that used to be glued together with shared secrets.
This is also why this AWS launch fits into a broader direction the industry has been slowly moving toward for years. You see it in OpenID Connect (OIDC)-based workload identity, in service-to-service authentication patterns, and in standards like SPIFFE (Secure Production Identity Framework for Everyone) and Workload Identity in Multi-System Environments (WIMSE), which treat identity as the main concern and treat any credentials as a short-lived consequence of that identity.
Technology has finally caught up, and identity federation should be the standard for all projects. While that might be possible for new greenfield projects, the reality on the ground means dealing with our legacy systems that still need to deliver on uptime SLAs and do it securely.
The Messy Middle: Time, Bandwidth, And Buy-in
The biggest mistake teams can make is treating this change in authentication and access management like a simple “enable the feature” exercise. It often starts with enabling outbound federation in your cloud account. But the hard problem is adoption, and that is a human and procedural issue, not a technological one.
Bandwidth is a major constraint for this, or any, new process or project. On paper, refactoring an authentication path might be “a few weeks of work.” In reality, that same team is on-call, shipping features, and burning down tickets because the product cannot pause while you modernize its plumbing.
The result is that identity work gets sliced into tiny increments, postponed until the next incident, or scoped down to the minimum change required to keep the lights on.
Coordination Requires Cross-Departmental Alignment
If you want outbound federation to become the default, you have to plan for this operational load, not pretend it does not exist. This requires buy-in and coordination, along with a way to track progress transparently.
Everyone involved is optimizing for something slightly different.
- Security wants fewer standing secrets, but also needs clear ownership over who can mint tokens, what audiences are allowed, and how validation is enforced.
- Platform and cloud engineering teams have to wire this into each environment and maintain the paved roads of shared libraries, examples, guardrails, and defaults that make the right thing the easy thing.
- Application owners have to touch code paths that have been stable for years, where “stable” usually means “nobody wants to be the one who changes it.”
- The IAM owner wants a centralized, auditable control point where they can enforce least-privilege to identities once they are subject to authorization schemes. They care about who can mint what, for which audiences, and under what conditions, and standardize those patterns across teams.
Disagreement over priorities and resource allocation is where many migration efforts stall out. Not because anyone disagrees with the end goal of eliminating static secrets, but because getting alignment to make the bandwidth available is hard. Getting the needed interdepartmental realignment of ownership and resources is the real challenge of moving towards zero-trust access management.
We first need to get agreement across the org that we must move forward to address access with better security, clearer authorization patterns, and less overhead for developers to fight permissioning. After that, the questions are: What moves first? What can wait? Which external services can validate JWTs today, and which are still stuck on API keys? And what gets escalated due to a breach or leak?
This is where visibility matters. You need to know where secrets are today, how they are being used, and whether the number of long-term credentials is actually going down as you roll out short-lived alternatives.
Visibility into the state of your NHIs, via their existing secrets, is where GitGuardian becomes extremely useful.
Using Gitguardian As Your Migration Scoreboard
As you adopt and scale outbound identity federation, the telemetry you need will let you track progress with real metrics:
- How many hardcoded secrets are we finding per month in repositories and pipelines?
- For each incident, is there a corresponding entry in a vault, or are we still seeing raw credentials that have no managed home?
- Are secrets in vaults being rotated regularly, and are long-lived static credentials being retired as workloads move to short-lived tokens?
- Which teams or systems are lagging behind, based on recurring detections or unchanged vault usage patterns?
The GitGuardian NHI Governance platform is here to give you the insight to know if you are actually moving in that direction.
Start with discovery. GitGuardian’s secrets detection can scan source code, internal repositories, CI/CD pipelines, and developer productivity tools to find hardcoded API keys, database passwords, certificates, and over 500 other sensitive access tokens. This gives you a baseline of where long-term secrets are hiding today. Most teams discover more exposure than they expected.
From there, you can begin to map those findings to your desired future state. Over time, you want each of those secrets either removed, moved into a managed vault, or replaced by a short-lived identity flow.
GitGuardian’s vault integrations allow you to connect to vaults like HashiCorp Vault, CyberArk's Conjur, and cloud providers like AWS Secrets, Google's Secrets Manager, and Azure's Key Vault. Once you connect all your vaults, GitGuardian can act as a centralized inventory, providing visibility into stale, unused, or unrotated secrets and helping organizations govern non-human identities at scale.
These vault integrations allow the platform to collect metadata about secrets stored in vaults, including versions and rotation history. Combined with its detection capabilities, you can correlate “this secret appeared in code three months ago” with “this value now lives in Vault and has been rotated twice.”
The platform's Push-to-Vault feature helps close the remediation loop by turning a detected leak into an actual migration step. Instead of stopping at “rotate and move on,” teams can push newly detected secrets into an approved vault directly from the incident workflow, making follow-on rotation and access controls easier to standardize. It is a practical bridge for the messy reality that you will still find secrets during the transition, even as you work to replace more of them with short-lived identity over time.
GitGuardian’s analytics are designed to turn an identity migration into something you can run like a program. Instead of relying on anecdotes, you get a consistent way to measure coverage, exposure trends, and remediation effectiveness over time, and to tie those trends back to the teams and systems that own the work. In practice, that means you can answer the questions leadership will ask without hand-waving, like "Are we actually reducing secret exposure?", "Are the right controls in place where leaks happen?", "Are teams getting faster at cleanup, and is the footprint of long-lived credentials shrinking as more access moves to short-lived identity?"
In parallel, you can bring your cloud IAM layer into the same view. GitGuardian’s NHI Governance can integrate directly with identity providers like AWS IAM, Okta, and Microsoft Entra. From those sources, GitGuardian pulls read-only IAM data, such as users, roles, and groups, and enriches it with permission context so you can see which NHIs exist, which access keys are effectively long-lived, what they can access, and where they violate policy.
That matters during an outbound federation migration because it helps you identify the machine identities that should be first in line for modernization, and the ones that still have the highest risk if leaked.
Turning Identity Federation Into a Measurable Migration
AWS IAM Outbound Identity Federation is the kind of shift that looks simple on a slide and feels complicated in a backlog. The token flow is straightforward. The hard part is getting every team, service, and “we’ll fix it later” integration to move off long-term credentials without breaking production or stalling in committee.
If identity is the new control plane, you still need a way to map progress for the messy middle, while secrets still live, and we are still one leaked key away from a bad day.
This is where GitGuardian can really help. Discovery gives you the baseline. Vault and IAM integrations give you the inventory and context. Analytics turns it into a program you can run, track, and defend with real numbers.
The real goal is not simply that “we enabled outbound federation.” It’s “we can prove secret exposure is shrinking, long-lived credentials are being retired, and the remaining risk is visible and owned.”
That’s how you make identity federation stick, not as a feature launch, but as a measurable migration.
If you are looking to get started on your own project, we would love to help you inventory what secrets you have and what state they are in.
Further reading:
Tiexin Guo
Tiexin Guo
