Workload federation is replacing secrets in multi-cloud access

At a glance

What this is: This analysis explains how workload federation lets non-human identities prove identity across clouds without shared secrets, and why that changes the access-control model for multi-cloud environments.

Why it matters: IAM and security teams need to treat cross-cloud workload access as a trust-governance problem, because static keys, duplicated identities, and fragmented secret handling all expand audit and compromise risk.

Context

Workload federation is a way for one identity system to validate a workload issued by another system and grant access without copying a shared secret. In multi-cloud environments, that matters because CI/CD pipelines, containers, and service calls now carry more of the access burden than human users do.

The governance gap is not whether identity exists, but whether it can be verified consistently across cloud boundaries. When teams rely on static keys or duplicated accounts, they create secret sprawl, brittle rotations, and unclear blast radius for compromised access.

For non-human identities, the hard part is making runtime trust portable across clouds without turning every service-to-service link into a custom authentication project. That is the problem this article addresses, and it is typical of modern multi-cloud access estates.

Key questions

Q: What breaks when workloads still rely on copied secrets across clouds?

A: Secret-centric access breaks because revocation, rotation, and audit scope all depend on knowing every place the credential was copied. In multi-cloud estates, that means one leaked key can outlive the system that issued it. Federation avoids that failure mode by moving access to runtime identity verification rather than persistent secret handling.

Q: Why do static credentials create more risk than short-lived access tokens?

A: Static credentials create more risk because they remain valid until someone finds and removes them, which gives attackers a durable entry path. Short-lived tokens reduce exposure time, but they still need scope limits and revocation. The real control is the combination of short lifetime, least privilege, and continuous review.

Q: How can IAM teams tell whether workload federation is working as intended?

A: Look for access events that are issued just in time, scoped to the target resource, and tied to verifiable claims from the originating workload. If teams still need environment variables, manual key rotation, or duplicate accounts to make access function, federation is not actually carrying the access model.

Q: How should security teams govern workload identity federation in multi-cloud environments?

A: Security teams should govern workload identity federation as a machine access control, not as a user login substitute. That means requiring attestation, short-lived credentials, resource scoping and explicit lifecycle rules for every workload identity. The goal is to eliminate standing secrets and make every access decision depend on current workload identity and policy.

Technical breakdown

Why workload federation is different from human federation

Human federation relies on interactive flows such as browser redirects, login prompts, and session establishment. Workloads do not behave that way. They are ephemeral, automated, and often distributed across multiple clouds, so they cannot complete MFA prompts or browser-based SSO. That is why the usual workforce model does not translate cleanly. The relevant unit of trust is the workload identity assertion, not the user session. In this model, the workload proves identity at runtime, the receiving system validates the assertion, and temporary access is issued only for the request at hand.

Practical implication: Treat workload access as runtime identity verification, not as a user-style sign-in problem.

How OIDC-based trust becomes short-lived cloud access

The article describes a two-phase model. First, a trust relationship is configured between the source identity system and the target cloud. Then the workload presents a signed token, commonly via OIDC, containing claims such as repository, namespace, role, or object ID. The target cloud validates those claims against its trust policy and exchanges them for a short-lived credential scoped to the requested resource. That credential expires automatically, which avoids distributing a persistent secret to the workload. The architecture depends on policy accuracy, claim mapping, and reliable token exchange across platforms.

Practical implication: Map token claims to cloud trust policies carefully, because the wrong claim mapping creates access drift.

Why federation reduces secret sprawl but increases trust design complexity

Federation removes the need to copy a secret into code, pipelines, or environment variables, which lowers exposure to theft and leakage. But it does not remove configuration complexity. Each cloud has its own federation mechanism, token format, and trust semantics, so the operational challenge shifts to consistent policy design across environments. That is why the article frames federation as a scale problem as much as a security model. The access method becomes the identity assertion, but only if the trust boundary is configured correctly everywhere it is used.

Practical implication: Standardise federation patterns across clouds, or misconfiguration will replace secret sprawl as the dominant risk.

Threat narrative

Attacker objective: The objective is to obtain durable cross-cloud access by compromising a reusable secret or over-permissioned workload credential.

1. Entry occurs through long-lived API keys, duplicated identities, or copied secrets stored in CI/CD pipelines, environment variables, and vaults.
2. Credential access follows when those static secrets are reused across services and clouds, giving an attacker or unauthorized party broad access wherever the key was copied.
3. Escalation and lateral movement happen because the same credential often survives rotation gaps and unclear ownership, expanding the blast radius across environments.
4. Impact appears as audit failure, delayed revocation, and access persistence after a credential is leaked or a deployment target changes.

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.

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

NHI Mgmt Group analysis

Secret distribution is no longer the right control plane for multi-cloud workload access: Once workloads, not people, become the main cross-cloud actors, copying credentials around the environment becomes the structural weakness. Federation changes the access question from possession of a secret to verification of a runtime identity assertion. Practitioners should treat secret elimination as an outcome of access design, not as the design itself.

Cross-cloud trust configuration has become the real governance surface: The article is right to separate identity issuance from access consumption, because the hard part is not token exchange in isolation. It is whether claim mapping, trust policy, and cloud-specific federation semantics stay aligned as environments change. That makes workload federation a governance and assurance problem, not just a technical integration pattern.

Ephemeral access breaks the assumptions behind secret-centric controls: Static key management assumes the credential is the durable object to govern. Federation replaces that object with a short-lived assertion and shifts risk to policy correctness at issuance time. The implication is that controls designed around rotation cadence and secret inventory will miss the dominant failure mode if trust policies drift.

Multi-cloud access needs identity portability, not identity duplication: Duplicating accounts across clouds creates the same governance debt that secret copying does, only with more administrative overhead. The article highlights a broader market direction toward portable trust layers that sit above individual cloud identity systems. Practitioners should expect federation, not duplication, to become the default design constraint for distributed workloads.

Federation makes auditability better only when the trust model is consistent: Short-lived credentials and verified claims improve traceability, but inconsistent federation semantics across AWS, Azure, and Google Cloud can still fragment accountability. The named concept here is cross-cloud trust debt: the governance gap that appears when access is portable in theory but not harmonised in practice. Practitioners should treat that debt as a design-risk signal.

From our research library:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data, according to the Ultimate Guide to NHIs.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Cross-cloud trust debt: Workload federation reduces the hidden cost of copying identities into every cloud, but it only works when claims, roles, and token semantics are aligned. If those mappings drift, federation can hide complexity rather than remove it, so programme owners need a control model that treats trust policy as a governed asset.

Teams should expect federation to shift audit work away from secret inventories and toward trust-policy validation, claim mapping, and temporary credential issuance. That is a useful change, because the governance evidence now follows the workload instead of the key, but it also means misconfiguration becomes the primary failure mode if consistency is not enforced.

According to the Ultimate Guide to NHIs, 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools. That scale explains why federation is gaining traction as a structural response rather than a point fix.

For practitioners

• Replace copied secrets with workload federation Inventory where CI/CD systems, containers, and service jobs still rely on static API keys, then move those paths to runtime identity assertions and short-lived credentials.
• Map trust claims to cloud policies Document which workload claims are authoritative in each cloud and validate how they resolve to IAM roles, service principals, or workload identity bindings.
• Remove duplicate identities between clouds Eliminate redundant service accounts and token stores where the same workload is represented differently in each environment, because duplication obscures ownership and revocation.
• Centralise access logging for token exchange Retain logs for every federation decision, including claim evaluation, trust policy match, and temporary credential issuance, so audit evidence follows the workload rather than a shared key.

Key takeaways

• Workload federation replaces copied secrets with runtime identity checks, which reduces the exposure that comes from distributing reusable credentials across clouds.
• The main governance challenge shifts from secret handling to trust policy design, claim mapping, and consistent federation semantics.
• Organisations that still depend on static keys, duplicate accounts, and manual rotation are carrying avoidable audit and revocation risk.

Key terms

• Workload Federation: A credential exchange pattern where a workload proves its identity and receives a short-lived, scoped token in return. It reduces dependency on stored secrets and gives governance teams a cleaner way to bind access to workflow context, trust conditions, and revocation boundaries.
• Runtime Identity Verification: Runtime identity verification is the process of proving a workload's identity at the moment access is requested rather than trusting a pre-stored secret. It ties access decisions to the current workload instance, which is more suitable for ephemeral services and short-lived sessions.
• Trust Policy: The rules that decide which workload may receive access under federation. In practice, trust policy binds claims such as repository, branch, environment, or runner posture to specific permissions, making it the control point that replaces the old stored secret.
• Secrets Sprawl: The uncontrolled proliferation of sensitive credentials, API keys, tokens, passwords, certificates, across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.

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.