TL;DR: Cloud-native federation across AWS, GCP, and Azure reduces secret handling, but it still leaves shared instance identity, token lifecycle, and workload isolation gaps that can expose entire hosts, according to Riptides. The governance problem is no longer whether federation works, but whether the identity model can prove per-workload accountability at runtime.
NHIMG editorial — based on content published by Riptides: Why Cloud-Native Federation Isn’t Enough for Non-Human Identities in AWS, GCP, and Azure
By the numbers:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
- Only 5.7% of organisations have full visibility into their service accounts.
Questions worth separating out
Q: How should security teams govern cloud-native federation for non-human identities?
A: Security teams should govern cloud-native federation at the workload level, not just the instance level.
Q: Why do shared identities in cloud-native environments increase NHI risk?
A: Shared identities increase risk because one compromise can inherit the same permissions as every other workload on the host.
Q: When is cloud federation not enough for workload identity governance?
A: Cloud federation is not enough when you need to distinguish one workload from another on the same host, container node, or VM.
Practitioner guidance
- Map every cloud credential to its actual runtime subject Document whether each AWS, GCP, or Azure identity is bound to a host, a VM, a container, or a specific workload execution context.
- Test whether metadata-service access is process-scoped or host-scoped Validate which local processes can reach instance metadata, token endpoints, or credential files on each platform.
- Treat token retrieval and delivery as part of the control surface Review how short-lived credentials are fetched, cached, handed off, and revoked in memory and on disk.
What's in the full article
Riptides' full blog post covers the operational detail this post intentionally leaves for the source:
- Kernel-level enforcement flow for matching workload attributes to SPIFFE-based identity.
- sysfs-based credential delivery and why it matters for runtime scoping.
- On-the-wire credential replacement details for cloud SDK traffic.
- Kubernetes custom resource examples for CredentialSource, WorkloadCredential, and WorkloadIdentity.
👉 Read Riptides' analysis of cloud-native federation limits for NHI governance →
Cloud-native federation for NHIs: where the governance gap still sits?
Explore further
Cloud-native federation solves portability, not accountability. The article shows that AWS, GCP, and Azure can all issue short-lived credentials to workloads, but the trust boundary still often sits at the instance or VM. That means the federation layer can move credentials around efficiently while leaving the governance question unanswered: which process actually used the identity. For NHI programmes, portability without workload attribution is not governance maturity. The practitioner conclusion is that federation must be evaluated against isolation, not convenience.
A few things that frame the scale:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
A question worth separating out:
Q: What should IAM and NHI teams check before relying on metadata-service credentials?
A: They should check who can access the metadata path, how credentials are scoped, and whether retrieval is isolated from other processes on the host. They should also confirm that token refresh and delivery cannot be reused outside the intended workload. A secure metadata service does not automatically equal secure workload governance.
👉 Read our full editorial: Cloud-native federation still leaves NHI governance gaps in AWS, GCP and Azure