They should use a federation rule that allows the destination service to validate the source workload’s attestation evidence, then issue only a short-lived, scoped credential. The key decision is whether the trust relationship is explicit and policy-driven, not whether the two environments can exchange credentials.
How should teams structure cloud-to-cloud workload access?
When one workload needs to call another service, the safest pattern is not to share a reusable static secret. Instead, the caller should present proof of its own workload identity, the target should verify that proof, and the resulting credential should be narrow in scope and short in lifetime. That keeps trust explicit, auditable, and easier to revoke.
The practical difference is between “these systems can exchange credentials” and “this service is willing to trust this specific workload under this policy.” That policy-driven model is what makes cross-cloud access manageable at scale, especially when the same application moves across clusters, accounts, or providers.
Why attestation-backed federation is the right trust model
Workload identity federation is the mechanism that turns a remote workload into a verifiable caller without handing it a long-lived key. In a well-designed flow, the destination service validates attestation evidence, checks the issuer and audience, and only then mints a short-lived token or role grant. That approach is closely aligned with the SPIFFE workload identity specification, which treats workload identity, attestation, and trust bundles as the core of service-to-service trust.
This model matters because it changes the security boundary. The source workload is no longer trusted because it sits in a certain network or account; it is trusted because it can prove who it is and what environment it is running in. That makes the access decision more specific, less reusable by attackers, and easier to constrain to a single resource or workflow.
In cloud environments, the same principle shows up in federation patterns such as OIDC trust, managed identities, workload identity pools, and token exchange. The implementation can vary by provider, but the security objective stays the same: verify the workload first, then issue a limited credential that cannot roam freely.
What the destination service should validate before issuing access
The destination should validate more than just a signature. It needs enough context to decide whether the calling workload is the one it expects, in the place it expects, and for the purpose it expects. That usually means checking the attestation source, audience, issuer, and any policy claims that bind the workload to a runtime environment, cluster, or deployment identity.
Where teams already use identity federation for cloud workloads, the strongest controls are the ones that keep the credential audience narrow and the trust policy explicit. The OAuth 2.0 Authorization Framework defines the general token exchange pattern, while OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens shows how to bind a token to the caller so a stolen bearer token is less useful. When the access token is also audience-restricted, the resulting credential is far less transferable.
That validation step should also be paired with a clear expiration policy. Short-lived credentials reduce the time window for misuse, token replay, and accidental overreach. If the credential lasts longer than the operational task it supports, teams usually drift back toward the same exposure they were trying to remove.
What good practice looks like in day-to-day operations
Good practice is to treat workload-to-service access as an authorization problem first and a connectivity problem second. The source workload should have a unique identity, the target should maintain a tight allowlist or trust policy, and the granted credential should carry only the permissions needed for one service action or one narrow API surface. The Cloud Workload Identity Guide is a useful internal reference for the common cloud-native patterns that support this model.
Teams should also plan for the failure modes that appear after deployment. Trust policies rot when environments change, audience restrictions get widened during debugging, and temporary credentials quietly become the default integration method. A stronger operating model is to review who can mint or accept federation trust, rotate supporting keys and certificates where applicable, and verify that every federated path still maps to an owner and a business purpose. For broader workload-identity navigation, Guide to SPIFFE and SPIRE and NHI Authentication Guide both reinforce the same operational pattern: prove the caller, scope the grant, then let the access expire quickly.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Cross-cloud workload trust depends on sound workload authentication and federation. |
| NHI-05 — Overprivileged NHI | The answer stresses narrow, scoped credentials for service-to-service access. | |
| NHI-07 — Long-Lived Secrets | The answer explicitly recommends short-lived credentials instead of static secrets. | |
| Recommendation — Bind workload authentication to attested identity and reject broad bearer-style access. Limit federated credentials to the minimum audience, action, and lifetime required. Replace static secrets with short-lived, expiring credentials wherever federation is possible. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | Workload-to-service federation requires strong machine or service authentication. |
| AC-6 — Least Privilege | The answer centers on issuing only a short-lived, scoped credential. | |
| IA-5 — Authenticator Management | Short-lived, managed credentials are central to the access pattern described. | |
| Recommendation — Use IA-9-style controls to authenticate non-organizational workloads before granting access. Grant only the minimum permissions and duration needed for the delegated call. Manage credential issuance, expiry, rotation, and revocation tightly. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Federated workload access is fundamentally an access-control decision. |
| A.8.5 — Secure authentication | The trust model depends on validated workload authentication evidence. | |
| A.5.23 — Information security for use of cloud services | The subject is specifically about cloud workload access across services and providers. | |
| Recommendation — Define and enforce access rules for workload-to-service trust relationships. Require secure authentication evidence before accepting cross-service access. Apply cloud-specific trust rules and review them as cloud dependencies change. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | The topic is about controlling which workload may access which service. |
| Recommendation — Standardise approval, scoping, and review of service-to-service access paths. | ||
Practitioner Guidance
What to prioritise: Start by defining the trust policy for the destination service, not by issuing a shared secret. If the access path cannot be expressed as “this workload, from this runtime, may call this resource for this purpose,” the design is still too loose.
What to verify: Confirm that the credential is audience-bound, short-lived, and tied to the caller’s attested identity rather than a reusable static token. If the same credential can be copied into another workload and still works, the control is weaker than it looks.
Common mistake: Teams often secure the transport but leave the trust model broad. Mutual TLS or a federated login flow alone is not enough if the token can be replayed broadly or reused across services without a strict policy boundary.
Practitioner takeaway: The key design choice is not whether two cloud environments can authenticate to each other, but whether each access grant is explicitly justified, narrowly scoped, and difficult to reuse outside the intended workload and service pair.
Related resources from NHI Mgmt Group
- What should teams do when an AI agent needs access to a database or cloud service?
- What should IAM teams do when service account access is broader than the workload needs?
- How should teams secure non-human identities across cloud and SaaS?
- How should security teams decide whether JIT access is safe for non-human identities?