How should security teams replace shared secrets for workloads that span multiple clouds?

Why This Matters for Security Teams

Shared secrets do not scale across multi-cloud workloads because they collapse identity, access, and trust into one reusable credential. Once that credential is copied into another cluster, pipeline, or supplier environment, the security team loses control over where it lives and who can replay it. Current guidance increasingly favors workload identity and ZTA patterns, as reflected in OWASP Non-Human Identity Top 10 and the SPIFFE workload identity specification.

NHIMG research shows why this matters operationally: in The State of Secrets Sprawl 2026, 64% of valid secrets leaked in 2022 were still valid and exploitable today, which means detection without revocation leaves a live attack path. That risk becomes sharper in cross-cloud integrations, where workload sprawl, CI/CD runners, and partner systems all widen the blast radius. In practice, many security teams discover the problem only after a secret has already been copied into a second environment and reused outside the original trust boundary.

How It Works in Practice

The replacement pattern is federated workload identity. Instead of issuing one shared secret for every cloud, each workload authenticates with its native identity signal, then exchanges that proof for a short-lived credential scoped to a specific API call, service account, or session. In practice, that proof can be a signed token, an attestation from a trusted runtime, or a workload certificate issued through a federation layer such as SPIFFE and SPIRE.

For multi-cloud deployments, the key design choice is not the cloud provider but the trust broker. Security teams should define which workload identity sources are accepted, which claims must match, and what policy must be true before a credential is minted. That is why modern approaches pair workload identity with real-time policy evaluation instead of static RBAC alone. When the request is evaluated at runtime, the decision can incorporate environment, workload posture, tenant, and purpose. The Guide to SPIFFE and SPIRE is a useful operational reference, and the Ultimate Guide to NHIs — Static vs Dynamic Secrets explains why dynamic credentials are safer than reusable ones.

• Issue identity to the workload, not to the environment.
• Exchange that identity for a short-lived credential only when policy permits.
• Bind the credential to one request path, service, or task where possible.
• Revoke trust immediately when the workload, image, cluster, or supplier changes.

This pattern aligns well with the CI/CD pipeline exploitation case study, because runner compromise is exactly where long-lived secrets become easiest to steal and replay. These controls tend to break down when legacy applications require embedded credentials or when cross-cloud partners cannot consume federated identity tokens.

Common Variations and Edge Cases

Tighter credential scoping often increases operational overhead, requiring organisations to balance automation effort against the reduction in secret sprawl. That tradeoff is real, especially in hybrid estates where one cloud supports token exchange cleanly and another still depends on older service-account models. Best practice is evolving, but the direction is consistent: move away from reusable secrets wherever the workload can prove identity cryptographically.

There is no universal standard for every cross-cloud topology yet, so teams should treat portability as an implementation question, not a reason to keep shared secrets. Some workloads will need JIT credentials for a single job, while others will need a short-lived delegated token with constrained audience and TTL. In autonomous or highly automated systems, this matters even more because behaviour is dynamic: the same workload may chain tools, call new services, or change its request pattern without warning. That is why identity should be tied to intent and runtime context, not just to a static role definition.

For governance, security teams should map controls to frameworks such as OWASP Non-Human Identity Top 10, SPIFFE workload identity specification, and Guide to the Secret Sprawl Challenge so that revocation, auditability, and least privilege are enforced consistently across clouds.

Related resources from NHI Mgmt Group

• How should security teams handle AI client access to governed data without shared secrets?
• How should security teams handle secrets across multiple cloud-native vaults?
• How should security teams decide whether JIT access is safe for non-human identities?
• How should teams reduce the risk from exposed NHI secrets?