Non-human identity federation across clouds: what IAM teams need to know

TL;DR: OIDC-based federation replaces long-lived API keys and service account secrets with short-lived, auditable tokens across AWS, GCP, and Azure, reducing leakage risk while tightening trust boundaries for workloads, according to Riptides. Static credentials still dominate NHI deployments, so federation changes the operating model more than the tooling stack.

NHIMG editorial — based on content published by Riptides: Non-human identity federation with external IDPs, a guide for AWS, GCP, and Azure

By the numbers:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• Only 5.7% of organisations have full visibility into their service accounts.

Questions worth separating out

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

A: Start by using an external OIDC provider to issue short-lived identity tokens, then exchange those tokens for cloud-specific access through tightly scoped trust policies.

Q: Why do static credentials create so much risk for workload identities?

A: Static credentials are durable, reusable, and hard to observe once they leave the vault or secret store.

Q: What do IAM teams get wrong about cloud federation?

A: They often treat federation as an authentication feature instead of an access governance model.

Practitioner guidance

• Inventory all long-lived workload secrets Find API keys, tokens, certificate files, and service account keys stored in code, CI/CD variables, containers, and shared repositories.
• Build trust policies around exact claims Match on issuer, audience, and subject with the narrowest viable values, then test every cloud role binding against a real workload identity.
• Separate federation by workload purpose Do not let one external IdP path become a universal credential for all pipelines or services.

What's in the full article

Riptides' full blog post covers the operational detail this post intentionally leaves for the source:

• Exact AWS STS, GCP workload identity pool, and Azure federated credential configuration steps.
• Sample trust policies and claim mappings for different workload types and cloud targets.
• CLI examples for exchanging an external OIDC token for short-lived cloud credentials.
• The provider-specific audit points teams should review when federation metadata or ownership changes.

👉 Read Riptides' guide to non-human identity federation across AWS, GCP, and Azure →

Non-human identity federation across clouds: what IAM teams need to know?

Explore further

View Full Forum →  |  NHI Foundation Course →