How should security teams implement federation for non-human identities across clouds?

Why This Matters for Security Teams

Federation for non-human identities is attractive because it removes long-lived secrets from the cloud boundary, but it only works when trust is narrow and measurable. For security teams, the real risk is not federation itself, but over-broad trust policies that let any token from a legitimate issuer behave like a trusted workload. That pattern collapses least privilege across clouds and makes incident response harder because access is distributed across identity providers, cloud roles, and application scopes.

Current practice is moving toward short-lived, claim-bound token exchange backed by policy checks, not static shared secrets. That matters because cloud workloads, CI/CD jobs, and agents often impersonate one another faster than humans can review entitlements. NHIMG research shows 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, which is a useful warning even outside AI-specific use cases. The same lesson applies to cross-cloud NHI federation: replace durable credentials with ephemeral trust, or you inherit all the blast radius of a password vault with none of the clarity.

Security teams reviewing a cloud compromise frequently discover the federation mistake after an attacker has already reused a broadly trusted token path to move between environments.

How It Works in Practice

Effective cross-cloud federation usually starts with an external identity provider that issues a short-lived OIDC token for the workload, pipeline, or agent. That token should then be exchanged for a cloud-native credential only after the destination cloud evaluates issuer, audience, subject, and any additional claims such as environment, workload class, or repository provenance. The goal is to bind the trust relationship to a specific identity and use case, not to a generic account that can act anywhere.

Practitioners should treat this as a policy design exercise, not a plumbing exercise. A practical implementation typically includes:

• short token lifetimes with automated renewal only for active workloads;
• tight trust policies that reject ambiguous issuers, wildcard subjects, and shared audiences;
• separate roles per workload or deployment path, rather than one federated role for many systems;
• runtime checks that enforce context such as branch, namespace, service account, or cloud account;
• central logging for token issuance, exchange, and privilege use across all clouds.

This is consistent with the direction of the NIST Cybersecurity Framework 2.0, which emphasises governable identity, logging, and continuous risk management. It also aligns with the concerns described in NHIMG research on The State of Non-Human Identity Security, where visibility gaps and over-privileged accounts remain common failure points. In practice, federation works best when the workload can prove what it is at the moment of access, rather than relying on a once-approved relationship that never changes. These controls tend to break down in multi-tenant platform environments where shared service accounts, wildcard claims, or default cloud role templates are used for convenience because the trust boundary becomes too broad to validate meaningfully.

Common Variations and Edge Cases

Tighter federation often increases operational overhead, requiring organisations to balance security gains against token management, policy maintenance, and debugging complexity. That tradeoff becomes especially visible when teams federate across AWS, Azure, and GCP with different role models and claim vocabularies.

Current guidance suggests avoiding “one federation pattern for everything.” Human-operated admin access, CI/CD pipelines, application-to-application calls, and autonomous agents each need different trust boundaries. For example, CI/CD systems can often be bound to repository, branch, and build context, while long-running services usually need workload identity anchored in runtime metadata. For agentic workloads, the standard is still evolving: best practice is to combine OIDC federation with ephemeral, per-task authorization rather than letting an agent retain broad standing access. That approach is consistent with the direction highlighted in The 2026 Infrastructure Identity Survey, where 70% of organisations reportedly grant AI systems more access than they would give a human employee doing the same job.

Two edge cases deserve special attention. First, external contractors or vendor-operated automation may require separate issuers and stricter audience restrictions to prevent cross-tenant reuse. Second, legacy cloud services that do not support fine-grained claim mapping may force teams to use intermediary brokers or identity translation layers. In both cases, the federation design should fail closed. The safest pattern is to treat cross-cloud trust as per-workload, per-purpose, and revocable by default, because once a token can move between clouds without precise claim binding, the federation model becomes a lateral movement path.

Related resources from NHI Mgmt Group

• How should security teams implement zero standing privilege for non-human identities?
• How should security teams implement least privilege for non-human identities?
• How should security teams implement ABAC for non-human identities?
• How should security teams implement Zero Trust for non-human identities?