Why do long-lived secrets still appear in cross-cloud workloads?

Why Long-Lived Secrets Keep Surviving Cross-Cloud Migration

Cross-cloud workloads often start with a clean federation design, then drift into exception handling when teams hit incompatibilities between identity providers, cloud-native token exchange, and service registration. At that point, a persistent secret looks simpler than fixing trust plumbing across environments. The problem is that static secrets outlive the runtime condition that justified them, so a temporary workaround becomes an enduring control gap. That is exactly the kind of pattern highlighted in the Guide to the Secret Sprawl Challenge and in the OWASP Non-Human Identity Top 10.

The risk is not only leakage. Long-lived secrets blur ownership, complicate revocation, and make workload identity harder to prove during incident response. In cloud-to-cloud and SaaS-to-cloud integrations, teams frequently inherit secrets from platform templates, partner onboarding, or CI/CD defaults, then fail to revisit them after federation stabilises. In practice, many security teams discover the exposure only after the secret has already been copied into logs, pipelines, or alternate runtimes.

What Actually Happens When Federation Breaks Down

In cross-cloud architectures, the preferred pattern is usually workload identity plus short-lived token exchange, not a static credential stored in a vault and reused indefinitely. The SPIFFE workload identity specification is useful here because it frames identity around what the workload is, not where it runs. When that model is implemented well, a service can authenticate, obtain a time-bounded credential, complete the task, and lose access automatically.

Long-lived secrets appear when one or more of these steps becomes unreliable:

• claim mapping is inconsistent across clouds or tenants
• trust registration is hard to automate in every environment
• token exchange fails under network segmentation or policy drift
• platform teams need a fallback for legacy services that cannot speak federation
• developers choose persistence because it is faster than debugging runtime auth

That shortcut creates hidden coupling. A secret issued for one workload can later be reused by a different service, a build runner, or a sidecar with broader reach than intended. NHIMG research on the 230M AWS environment compromise shows how quickly cloud trust failures become systemic once credentials are portable across accounts and services. The better practice is evolving toward intent-based authorisation, short TTLs, and automated revocation tied to runtime context, but there is no universal standard for this yet.

This guidance tends to break down in hybrid estates where a single application must support multiple cloud providers, older message queues, and third-party APIs because the operational cost of per-task federation is still higher than dropping in a shared secret.

Where Teams Should Draw the Line on Temporary Exceptions

Tighter secret controls often increase delivery overhead, requiring organisations to balance faster integration against stronger revocation discipline. That tradeoff is real in partner integrations, disaster recovery paths, and legacy applications that cannot easily adopt federated identity. Current guidance suggests that a long-lived secret should be treated as an exception with an owner, an expiry date, and a retirement plan, not as a normal integration method.

Two patterns help reduce drift. First, treat cross-cloud access as a workload identity problem and require cryptographic proof at runtime wherever possible. Second, make the fallback secret visibly temporary: scoped to one system, one environment, and one purpose, with monitoring that checks whether the exception is still needed. The NHIMG Ultimate Guide to NHIs — Static vs Dynamic Secrets is a practical reference for this distinction, especially when teams need to justify why a credential should be ephemeral rather than persistent.

The largest edge case is vendor-managed or SaaS-driven cross-cloud connectivity, where the customer may not control the identity plane at all. In those environments, the right question is often not how to eliminate every secret immediately, but how quickly the secret can be rotated, whether it is isolated from human use, and whether the integration can be redesigned around federation later. The hardest failures show up when a temporary exception is promoted to a permanent dependency and no one can still explain who owns the secret.

Related resources from NHI Mgmt Group

• What breaks when cross-cloud access still depends on long-lived secrets?
• How should security teams migrate workloads away from long-lived secrets?
• What breaks when service accounts still rely on long-lived secrets?
• Why do long-lived secrets increase breach risk in cloud and fintech environments?