Workload federation is replacing secrets in multi-cloud access

At a glance

What this is: This is an analysis of workload identity federation for multi-cloud access, with the key finding that runtime trust can replace static secrets for workloads if teams can manage cross-cloud policy consistently.

Why it matters: It matters because IAM, PAM, and NHI programmes still fail when workload access depends on shared credentials, duplicate identities, or brittle manual rotation across clouds.

By the numbers:

• GitGuardian’s 2026 report found roughly 29 million secrets detected on public GitHub in 2025, a 34 percent year-over-year increase.
• The 2026 Infrastructure Identity Survey found that 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.

👉 Read Aembit's analysis of workload federation across clouds

Context

Workload federation is the practice of letting a non-human identity prove who it is in one environment and receive access in another without copying a shared secret. In multi-cloud programmes, that matters because CI/CD pipelines, containers, and services need access that is machine-paced rather than human-paced, and static keys are still the default fallback in too many environments.

The governance problem is not whether federation exists. It is whether teams can scale trust relationships across clouds without multiplying identity sprawl, audit gaps, and brittle credential handling. That is where workload IAM becomes a structural issue for NHI programmes, not just an infrastructure convenience. See the Guide to SPIFFE and SPIRE for the broader workload identity model.

Key questions

Q: How should security teams replace static workload secrets with federation across clouds?

A: Start with the workloads that already cross trust boundaries, then replace copied secrets with runtime identity assertions issued by the native cloud or a federation layer. Keep the trust policy explicit, scope credentials to the request, and verify that revocation works without finding every copied secret first. The goal is to remove persistence from workload access, not just centralise it.

Q: Why do workload identities complicate zero trust architecture in multi-cloud environments?

A: Because zero trust assumes every access request is continuously evaluated against context, but multi-cloud workloads create many more trust edges than human users do. Each cloud may validate claims differently, so the programme must govern token issuers, policy mapping, and runtime posture together. Without that, zero trust becomes a label rather than an operating model.

Q: What breaks when service accounts still rely on long-lived secrets?

A: Revocation becomes slow, audit trails fragment, and the secret often turns into the real identity because it can be copied anywhere. That creates hidden reuse across pipelines, compute nodes, and developer tools. When one secret unlocks multiple paths, you lose both blast-radius control and reliable accountability.

Q: How do organisations know if workload federation is actually improving governance?

A: Look for shorter credential lifetimes, fewer copied secrets, clear ownership of each trust relationship, and audit logs that show who or what requested access at runtime. If teams still have to chase secrets across systems to revoke access, federation is only partially implemented.

Technical breakdown

Workload identity federation vs static secrets

Workload identity federation replaces reusable credentials with signed identity assertions issued at runtime. A workload presents a token that describes where it runs and who issued it, then the target system validates that claim against a trust policy and returns a short-lived credential. The model is built for ephemeral, non-interactive actors such as containers, functions, and pipelines. Static keys do the opposite. They persist beyond the request, can be copied, and often outlive the workload they were meant to represent.

Practical implication: if a workload still depends on a long-lived secret, the identity design has already failed before access is granted.

OIDC trust, claims, and cloud token exchange

Most workload federation flows use OIDC claims as the portable identity layer. The issuer signs the token, the receiving cloud checks the claims, and a security token service converts that assertion into a scoped, temporary credential. The details vary by platform, but the control logic is the same: trust is established once, then enforced at runtime through claim validation and policy mapping. That is what makes federation usable across cloud boundaries without embedding credentials in code or environment variables.

Practical implication: policy mapping and claim design must be treated as part of IAM engineering, not left to application teams after deployment.

Cross-cloud federation hubs and policy enforcement

At scale, the hard part is not issuing one token. It is managing many trust relationships across SaaS, cloud, and on-premises systems without turning every service-to-service connection into a bespoke integration. Federation hubs centralise this work by brokering token exchange and enforcing contextual policy at access time. That reduces secret distribution, but it also concentrates risk if claims, posture checks, or trust boundaries are misconfigured. The architecture only works if every trust edge is explicit and reviewable.

Practical implication: map every federation edge, then verify that each one has a clear owner, a bounded trust scope, and an auditable policy decision path.

Breaches seen in the wild

• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
• CI/CD pipeline exploitation case study — full server takeover via exposed .git directory and mismanaged CI/CD pipeline secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Workload federation is a control model, not just an authentication pattern. The important shift is that workloads no longer need to carry a persistent credential in order to be trusted across environments. That changes IAM from secret distribution to runtime trust evaluation, which is why federation belongs in NHI governance rather than in a narrow cloud integration discussion. Practitioners should treat every cross-cloud access path as an identity decision point.

Static secret dependence is the named failure mode that federation is trying to remove. Shared API keys, copied service account credentials, and environment-variable secrets create an access model where the secret becomes the identity. That breaks revocation, obscures accountability, and expands blast radius whenever a credential is reused across tools. The practitioner conclusion is simple: if access cannot survive without a copied secret, the governance model is already compensating for a design flaw.

Pairwise federation complexity creates a new governance burden even when the security model is correct. Each cloud platform exposes its own trust semantics, claim structure, and token exchange path, so scaling federation means governing the trust graph as carefully as the credentials it replaces. This is where NIST Cybersecurity Framework control thinking and zero trust design become operationally relevant. The practitioner takeaway is to manage federation as an enterprise control plane, not as one-off cloud plumbing.

Identity is the access method when the workload can prove itself at runtime. That is a healthier model than secret replication, but it also means posture, claim quality, and trust policy become the security boundary. AEMBIT's source article points to the right direction for practitioners, but the governance lesson is broader: workload IAM only becomes durable when identity, policy, and environment context are designed together. Teams should align federation with NHI lifecycle controls from the start.

Workload federation exposes the gap between cloud-native capability and enterprise operating model. The capability exists in every major cloud, but most organisations still lack the cross-platform governance to make it consistent. The result is a familiar pattern: strong technical primitives paired with weak operational control. Practitioners should focus on ownership, trust review, and policy drift before adding more workload identities into the estate.

From our research:

• The 2024 State of Secrets Management Survey found that only 44% of organisations are currently using a dedicated secrets management system, according to Guide to the Secret Sprawl Challenge.
• 54% of organisations are dissatisfied with their current secrets management solution because not all secrets are secured, and 43% cite lack of central management.
• For a broader NHI governance baseline, see Ultimate Guide to NHIs for the lifecycle and trust model behind workload access decisions.

What this signals

Secret replacement is only half the programme change. The more important shift is that federation moves workload access into a trust-policy lifecycle, which means review, ownership, and revocation have to be governed like any other identity control. The Guide to the Secret Sprawl Challenge is a useful reference point here because secret proliferation is still the failure mode most teams are trying to escape.

With 70% of organisations already granting AI systems more access than human employees, the broader market signal is clear: access models built around static credentials are already under pressure from machine-scale identity growth. That makes workload federation relevant not only for cloud engineering, but for the future shape of NHI governance.

Trust graphs will become the next governance surface. As federation spreads, the question is not whether a workload can authenticate, but whether every trust edge has a named owner, a review cycle, and a clear failure boundary. Teams that do not map those dependencies will end up with a distributed identity control plane they cannot explain to auditors or operations.

For practitioners

• Inventory every static credential used by workloads Map CI/CD pipelines, containers, serverless functions, and cross-cloud services to the secrets they still depend on, then prioritise the highest-blast-radius paths first. Replace copied credentials with runtime identity where the workload can authenticate through native cloud trust.
• Define trust policies before enabling federation at scale Document which issuer, claims, namespaces, and runtime contexts are acceptable for each target service, then test those policies end to end before rollout. Treat claim mapping as an access control decision, not a deployment convenience.
• Centralise review of federation edges and token scopes Create an owner for every cross-cloud trust relationship, then review the token exchange path, expiration window, and claim set on a fixed governance cycle. Use the 52 NHI Breaches Analysis to benchmark how secret exposure and overprivilege typically compound.
• Block workloads that fail posture checks even with valid identity Tie federation decisions to environment signals such as vulnerability state or approved runtime posture, so a valid token does not automatically equal permitted access. This keeps runtime trust tied to current risk, not just initial authentication.

Key takeaways

• Workload federation reduces secret sprawl by replacing copied credentials with runtime identity assertions, but it only works when trust policy is governed deliberately.
• The central risk is not the federation mechanism itself. It is the persistence of static secrets, duplicated identities, and unclear ownership across trust boundaries.
• IAM teams should treat cross-cloud workload access as an enterprise control plane problem, with explicit trust review, scoped claims, and runtime posture checks.

Key terms

• Workload Federation: Workload federation is a method of letting a non-human identity prove itself in one environment and receive access in another without copying a shared secret. It uses trust relationships, token exchange, and scoped credentials so access can be issued at runtime instead of stored indefinitely.
• Trust Policy: A trust policy is the rule set that decides which identity assertions are accepted and what access they unlock. In workload contexts, it binds token claims, issuer details, and runtime conditions to a specific authorization outcome, making policy the control plane for cross-environment access.
• Static Secret: A static secret is a long-lived credential such as an API key, token, or certificate that can be reused until it is rotated or revoked. For workloads, static secrets increase copy risk, obscure accountability, and make access persistence depend on storage hygiene rather than runtime identity.
• Runtime Identity Assertion: A runtime identity assertion is a signed claim presented by a workload at the moment it needs access. It allows the receiving system to validate who the workload is, where it runs, and whether the requested access fits policy, without relying on a reusable shared secret.

Deepen your knowledge

Workload federation and workload identity are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are replacing copied secrets with runtime trust across clouds, it is worth exploring.

This post draws on content published by Aembit: workload federation and access management across cloud providers. Read the original.