Non-human identity federation across AWS, GCP, and Azure

At a glance

What this is: This is a guide to federating non-human identities across AWS, GCP, and Azure using an external OIDC identity provider, with the central finding that static credentials create unnecessary leakage and governance risk.

Why it matters: It matters because IAM and NHI teams need a cross-cloud model that reduces secret sprawl while preserving auditable, least-privilege access for workloads, pipelines, and services.

Context

Non-human identity federation is the practice of letting workloads authenticate through an external identity provider and receive short-lived cloud credentials instead of carrying their own long-lived secrets. In this article, the governing problem is not cloud access in the abstract but how to keep service accounts, CI pipelines, APIs, and automation trustworthy across AWS, GCP, and Azure.

The article’s core argument is that static keys and tokens are the wrong default for multi-cloud workloads because they are hard to rotate, easy to leak, and weak on traceability. Federation moves the control point to OIDC trust configuration, where claim mapping, issuer validation, and role scoping define whether the identity can be trusted at all.

Key questions

Q: How should teams replace long-lived workload secrets with federation across cloud providers?

A: Start by inventorying every workload that still depends on static API keys, tokens, or service account secrets, then bind each one to an external identity provider with narrowly scoped issuer, audience, and subject rules. The goal is not only shorter credentials, but a trust model that is auditable and specific to each workload class.

Q: Why do service accounts and static secrets create more risk than federated workload access?

A: Service accounts and static secrets create risk because they persist beyond the original task and can be copied, reused or leaked. Federated workload access reduces that risk by issuing short-lived credentials that expire quickly and are tied to a specific identity proof. That narrows replay opportunities and limits lateral movement.

Q: What breaks when workload identity trust policies are too broad?

A: A broad trust policy can let multiple workloads, projects, or environments inherit the same access path, which expands the blast radius if one identity is abused. In practice, the failure is not federation itself but the loss of workload-level separation in the claim mapping and role binding layer.

Q: How do IAM teams compare AWS STS, GCP Workload Identity Federation, and Azure federated credentials?

A: They are all variants of the same federation pattern, but they differ in how trust is expressed and how identity is impersonated. AWS centers on role assumption, GCP on pools and service account impersonation, and Azure on federated credentials attached to managed identities or app registrations.

Technical breakdown

Why OIDC federation changes workload trust

OIDC federation replaces embedded static secrets with signed identity tokens issued by an external identity provider. The cloud provider validates issuer, audience, signature, expiration, and claims before exchanging that token for a short-lived cloud credential. That matters because the workload is no longer proving identity with a reusable secret. It is proving identity through a time-bound assertion that can be constrained by trust policy, audience restrictions, and claim-based role binding. In practice, this changes the security boundary from secret custody to trust configuration and token validation.

Practical implication: treat issuer, audience, and claim mapping as security controls, not setup details.

How AWS, GCP, and Azure implement federated non-human identity

Each cloud provider expresses the same pattern differently. AWS uses IAM roles with Web Identity and STS. GCP uses Workload Identity Federation with pools, providers, and service account impersonation. Azure uses federated credentials on a user-assigned managed identity or app registration. The shared design is temporary credential issuance based on an external token, but the governance surface differs: role trust policy in AWS, attribute mapping and impersonation binding in GCP, and federated identity credentials in Azure. That means portability is architectural, not procedural, and misconfiguration can happen at the provider-specific trust layer.

Practical implication: validate the trust model separately for each cloud instead of assuming federation is uniform.

Why static credentials fail in multi-cloud NHI estates

Static API keys, long-lived tokens, and service account secrets create persistence where workloads only need episodic access. They are difficult to rotate consistently, often end up in code or configuration, and offer poor auditability because the secret itself becomes the durable bearer of access. Federation reduces that persistence by issuing ephemeral credentials on demand, but only if the surrounding trust relationship is tightly scoped. Without that, federation can still overgrant access, just with better packaging.

Practical implication: inventory long-lived workload secrets first, then prioritize the identities with the broadest cloud permissions.

Breaches seen in the wild

• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
• Codefinger S3 ransomware 2025: Codefinger used victims' compromised AWS keys to re-encrypt S3 buckets with SSE-C, set 7-day deletion and demanded ransom for the key.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Federation is now the baseline control for cross-cloud non-human identity governance. Static credentials do not scale cleanly across AWS, GCP, and Azure because every new trust boundary multiplies leakage, rotation, and audit problems. Federation does not eliminate governance, but it makes the control point explicit: trust in the issuer, trust in the claims, and trust in the scoped role. Practitioners should treat that shift as a structural redesign, not an authentication convenience.

OIDC trust configuration is the real security boundary. The article correctly centers issuer validation, audience checks, and claim mapping because those are the places where federated access is accepted or rejected. If those conditions are too broad, federation simply moves old secret risk into a new trust-policy risk. The practical conclusion is that identity governance for NHIs now lives in policy precision, not secret storage alone.

Cross-cloud federation exposes a reusable identity blast radius if claim design is lazy. A single external IdP can simplify operations, but it can also unify too much privilege if the same subject or audience is accepted everywhere. That creates a shared failure domain across clouds, teams, and workloads. Practitioners should design for differentiated trust relationships per workload class, not one generic federation pattern for everything.

Riptides’ analysis reinforces that auditability must be designed into token exchange, not added after the fact. Short-lived credentials help only when issuance, impersonation, and role assumption are all logged and reviewable. That matters for NHI governance because the problem is no longer just whether a secret leaked, but whether the federation event itself can be traced to a workload, a scope, and a decision. Teams should expect identity audits to move upstream into trust-policy review.

Federated NHI models are converging on runtime identity as the governing concept. The article’s mention of SPIFFE-based identities points to the direction the market is moving: identities that are issued, exchanged, and constrained at runtime rather than pre-provisioned as durable secrets. That does not make lifecycle governance disappear. It makes lifecycle governance more continuous, because trust relationships, claim mappings, and access scopes now require ongoing validation.

From our research library:

• NHIs outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs.
• Read next: Ultimate Guide to NHIs

What this signals

Non-human identity federation is becoming a governance problem before it is a tooling problem. The security question is no longer whether a workload can authenticate, but whether the trust relationship that authorises it is narrow enough to survive scale across clouds. IAM teams should expect federation reviews to move closer to policy engineering, especially where workloads span CI/CD, backend services, and automation.

Identity blast radius is the concept that best captures the trade-off in this article. Federation reduces the persistence of stolen secrets, but it can also concentrate trust into a single external IdP if claim design is too coarse. That is why cloud-by-cloud alignment, workload-class separation, and issuer discipline matter more than any single implementation choice.

Machine actors already outnumber people by a wide margin in most environments, according to the Ultimate Guide to NHIs. As that ratio grows, the federation model becomes the practical way to keep non-human access reviewable without relying on static credentials that no longer fit cloud-scale operations.

For practitioners

• Map every long-lived workload secret Identify API keys, service account secrets, and static tokens used by CI pipelines, services, and automation jobs across AWS, GCP, and Azure. Rank them by privilege, exposure surface, and rotation difficulty so federation work starts where the risk is highest.
• Define issuer, audience, and subject constraints Require exact matches for issuer URLs, token audiences, and subject claims before a cloud provider accepts a federated token. Keep trust policies narrow enough that the external IdP can authenticate the workload without creating a reusable cross-cloud access path.
• Bind each workload class to a distinct trust relationship Avoid using one generic federation pattern for pipelines, production services, and AI workloads. Separate roles, pools, or federated credentials so each workload class receives only the permissions and claim mappings it actually needs.
• Audit token exchange and role assumption logs Confirm that IdP issuance events, cloud token exchanges, and downstream role assumptions are all retained and correlated. This is the evidence chain you will need when reviewing whether a federated workload acted within its intended scope.
• Rotate IdP metadata and validation inputs on a schedule Plan for certificate thumbprints, signing keys, issuer metadata, and audience settings to change over time. Federation depends on those validation inputs remaining current, so stale metadata becomes an availability and trust failure rather than a minor maintenance issue.

Key takeaways

• Federated non-human identity shifts the control point from secret storage to trust policy, claim mapping, and short-lived token exchange.
• The main operational risk is not just leaked credentials but overbroad trust relationships that let one workload inherit access it should not have.
• IAM teams should prioritize federation where static secrets are hardest to rotate and where auditability matters most across clouds.

Key terms

• Non-Human Identity Federation: A method of letting software workloads authenticate through a trusted external identity provider and exchange that proof for cloud credentials. It replaces durable secrets with short-lived tokens, which improves auditability and reduces the standing exposure window across AWS, GCP, Azure, and other systems.
• OIDC Identity Provider: An OIDC Identity Provider is the system that authenticates a user or workload and issues identity tokens for other services to trust. In OpenID Connect, it performs the authentication step, publishes signing keys and metadata, and returns ID tokens, often alongside access tokens, so relying applications can verify identity claims.
• Workload Identity Federation: A mechanism allowing workloads in one environment to authenticate to another using short-lived tokens rather than stored credentials, based on mutual trust between identity providers.
• Claim Mapping: The process of translating token claims such as issuer, subject, and audience into cloud permissions. It is where identity intent becomes access reality, so weak mapping can turn a technically sound federation flow into an over-permissioned and difficult-to-audit trust relationship.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.