Cloud-native federation still leaves NHI governance gaps in AWS, GCP and Azure

At a glance

What this is: This analysis argues that cloud-native federation is useful but incomplete because shared identities, hidden token handling, and weak workload isolation still undermine NHI governance.

Why it matters: It matters because IAM, PAM, and NHI teams need controls that bind identity to the workload itself, not just to the host or cloud platform.

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.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.

👉 Read Riptides' analysis of cloud-native federation limits for NHI governance

Context

Cloud-native federation helps workloads authenticate across AWS, GCP, and Azure without hardcoded long-lived secrets, but it does not solve the underlying governance problem of who or what is actually holding the identity. In practice, many cloud-native patterns still bind credentials to a host, a node, or an instance, which leaves multiple processes sharing the same trust boundary.

That matters for non-human identity governance because workload identity, secret handling, and access accountability are still being decided at the infrastructure layer rather than the workload layer. The result is better portability, but not necessarily better isolation, and that distinction is where many NHI programmes still fall short.

Key questions

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. Short-lived credentials are useful, but they still need process isolation, clear ownership, and revocation paths that reflect the real execution context. If multiple workloads can use the same trust boundary, the federation design has not yet solved NHI governance.

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. That turns a single process failure into a broader access problem and weakens accountability. In NHI programmes, shared trust boundaries should be treated as structural exposure, not as a harmless efficiency trade-off.

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. If the platform cannot bind access to a unique runtime subject, you still have a host-centric model rather than a workload-centric one. That gap matters most in hybrid and multi-cloud estates with mixed trust zones.

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.

Technical breakdown

Shared instance identity and why federation stops at the host

AWS instance profiles, Azure managed identities, and GCP metadata service tokens are all cloud-native ways to let workloads obtain temporary credentials without manually storing secrets. The limitation is structural: the identity is usually attached to the instance or VM, not to each process or container. That means any workload on the host that can reach the metadata path may inherit the same trust context unless additional isolation is enforced. Federation therefore reduces secret sprawl, but it does not automatically create workload-level identity boundaries or process-level accountability.

Practical implication: treat host-bound cloud federation as a starting point, not as proof of per-workload isolation.

Ephemeral tokens still depend on secure retrieval and refresh logic

Short-lived tokens reduce exposure time, but they do not remove the need to obtain, refresh, protect, and deliver credentials safely. If a workload needs a token from an external IDP or a cloud metadata service, something in the stack must orchestrate that exchange and keep the resulting credential out of reach from unintended processes. That orchestration layer becomes part of the trust model. In other words, the credential may be ephemeral, but the retrieval path, memory handling, and delivery mechanism still define whether the design is actually safer.

Practical implication: audit the token retrieval path, not just token lifetime, when assessing NHI risk.

SPIFFE-based workload identity and runtime binding

SPIFFE gives workloads a cryptographic identity format that is meant to be portable across environments, and SPIRE is the common reference implementation used to issue and verify that identity. In a runtime-bound model, the important question is whether the workload can prove who it is at the moment it requests access, not whether the host is already trusted. That is why workload attributes such as binary path, namespace, or deployment metadata matter: they let the platform bind credentials to the thing actually executing, rather than to a shared machine context. This is the part cloud-native federation usually leaves unfinished.

Practical implication: use workload-unique identity assertions if you need governance below the host level.

NHI Mgmt Group analysis

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.

Shared identity per instance is the real control failure. The article’s limitation section is the key signal here. If all workloads on a host share one identity, a compromise in one process can impersonate others and expand blast radius across containers or services. That is exactly the kind of failure mode NHI governance is meant to prevent, but the cloud-native model does not always express it at workload granularity. The practitioner conclusion is that shared trust domains must be treated as a known risk, not an implementation detail.

Workload-unique identity is the missing named concept here. The governance gap is not simply secret storage, it is the absence of verifiable identity tied to the workload itself. When identity is derived from runtime attributes such as binary path or namespace, the platform can distinguish one process from another and make access decisions on that basis. That is the point at which federation starts to look like governance rather than transport. The practitioner conclusion is that workload-level identity must become the unit of control.

Runtime credential delivery gap: This model exposes a specific operational weakness in many NHI architectures: credentials may be short-lived, but delivery still depends on kernel, user-space, or SDK integration behaving correctly at runtime. If that path is not controlled, the ephemeral credential can still be exposed, intercepted, or reused before the intended workload consumes it. The practitioner conclusion is that secure delivery is part of the identity design, not a downstream implementation concern.

Centralised policy helps, but it does not replace lifecycle governance. The article highlights central policy management across cloud providers, yet lifecycle decisions still determine who can assume which identity, when, and under what conditions. That is where lifecycle review, revocation, and offboarding remain essential even in multi-cloud federation models. The practitioner conclusion is that a central control plane must still be paired with identity lifecycle discipline across environments.

From our research:

• 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.
• For a broader lifecycle lens, see Ultimate Guide to NHIs for how visibility, rotation, and offboarding shape the control model.

What this signals

Workload-level identity will become the dividing line between federation and governance. As cloud estates become more hybrid, teams will need to prove that a credential belongs to a specific runtime subject, not just to a cloud instance. That pushes identity architecture toward workload selectors, stronger policy binding, and tighter lifecycle control across AWS, GCP, and Azure.

The operational test is no longer whether a workload can obtain a token. It is whether the organisation can explain who can read it, where it lives in memory or on disk, and how quickly it disappears when the workload changes. That is where identity reviews and secrets hygiene start to overlap.

Identity blast radius: when multiple workloads inherit a shared trust context, the compromise domain expands far faster than the cloud federation story suggests. The next control maturity step is to reduce the number of places where one identity can speak for many workloads and align that with NIST Cybersecurity Framework 2.0 identity and access protections.

For practitioners

• 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. If multiple processes can read the same credential path, treat that as shared identity exposure rather than acceptable federation.
• 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. If the same node identity can be consumed by unrelated workloads, add isolation controls before expanding federation further.
• 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. Pay particular attention to user-space helpers, SDK configuration, and any sysfs or file-based delivery path that could widen exposure.
• Bind policy to workload attributes, not just cloud roles Use selectors such as namespace, binary path, command-line arguments, or deployment metadata to distinguish one workload from another. That gives IAM and NHI teams a more precise control boundary than the node or instance alone.
• Add lifecycle checks to every cross-cloud identity path Reconfirm ownership, revocation, and offboarding for identities that move between AWS, GCP, and Azure. Cross-cloud federation does not remove the need to retire stale identities when the workload, owner, or deployment model changes.

Key takeaways

• Cloud-native federation improves access portability, but it does not by itself create workload-specific accountability.
• Shared instance identity, token delivery, and runtime retrieval remain the control points that determine whether federation is actually safer.
• NHI programmes should evaluate federation by isolation strength and lifecycle discipline, not by whether secrets have become shorter lived.

Key terms

• Workload Identity: A workload identity is a machine or application identity used to authenticate software rather than a person. In a strong governance model, it should map to one runtime subject, with access decisions tied to the workload’s actual execution context and lifecycle rather than a shared host.
• Instance-Bound Identity: Instance-bound identity is a credential or token model where the trust anchor is the VM, node, or host rather than the specific process using it. It is convenient for cloud operations, but it weakens accountability when multiple workloads share the same environment.
• Ephemeral Credential: An ephemeral credential is a short-lived secret or token issued for a narrow purpose and limited duration. It reduces exposure time, but it only improves security if retrieval, delivery, and revocation are also controlled and the credential cannot be reused outside the intended workload.
• SPIFFE ID: A SPIFFE ID is a standardized workload identity string used to represent a software workload in a portable way. It lets security controls bind access to a specific workload identity rather than to a cloud provider or machine-specific credential format.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Riptides: Why Cloud-Native Federation Isn’t Enough for Non-Human Identities in AWS, GCP, and Azure. Read the original.