Notifications
Clear all
Topic starter
12/06/2026 12:36 am
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
12/06/2026 9:59 am
Federation is now the default answer to static-secret overexposure. The article describes the right architectural direction: short-lived credentials, claim-based trust, and cloud-specific token exchange. That matters because most NHI risk still comes from durable secrets that are hard to rotate, hard to audit, and easy to reuse across cloud boundaries. The practitioner conclusion is that federation should be the baseline pattern for new workload access.
Claim-scoped federation is becoming the practical test for workload governance. When the same external IdP can be used across AWS, GCP, and Azure, the difference between secure and unsafe implementation is not the protocol. It is the quality of the claim mapping, the trust policy, and the review process around them. Teams should expect federation to move from architecture choice to audit question quickly.
A question worth separating out:
Q: How do organisations know if federation is actually improving security?
A: Look for fewer long-lived workload secrets, tighter role bindings, and shorter credential lifetimes across AWS, GCP, and Azure. If teams still rely on embedded keys or broad service account access, federation has not materially changed the risk profile, only the login path.
👉 Read our full editorial: Non-human identity federation across AWS, GCP, and Azure
