Because they were designed for slower-changing environments where secrets and access relationships were easier to track. Cloud and multi-cloud estates create more identities, more integrations, and more movement between systems, which makes manual rotation and static governance too slow to keep up.
Why Legacy Secrets Management Struggles in Cloud and Multi-Cloud Estates
Legacy secrets management was built for environments where applications were slower to change, trust boundaries were clearer, and access paths were easier to inventory. Cloud and multi-cloud estates invert those assumptions. Workloads spin up and down quickly, service-to-service calls multiply, and secrets spread across CI/CD, Kubernetes, serverless, and third-party integrations. NHIMG research shows 35.6% of organisations cite consistent access across hybrid and multi-cloud environments as their top NHI security challenge, and the problem grows as estates become more distributed.
This is why static rotation schedules and manual vault hygiene often lag behind reality. The issue is not only storage, but identity sprawl, inconsistent policy enforcement, and poor visibility into where secrets are used. The Guide to the Secret Sprawl Challenge and the OWASP Non-Human Identity Top 10 both highlight how secret distribution and weak lifecycle controls become structural risks once automation takes over. In practice, many security teams discover the scale of the problem only after credentials have already been copied into pipelines, images, and messaging tools.
How It Works in Practice
Cloud-ready secrets management has to treat secrets as short-lived operational dependencies, not permanent artifacts. That means replacing broad, static credentials with workload-specific, ephemeral access that is issued at runtime, scoped to a single task, and revoked as soon as the task completes. The operational model shifts from “store and rotate” to “prove workload identity, authorize in context, and minimize secret lifetime.”
Current best practice is to anchor access in workload identity and policy, then issue dynamic credentials only when the request is legitimate. For example, a build job, API integration, or container should authenticate with a workload identity primitive, then receive a bounded token or secret just long enough to complete a specific operation. The Ultimate Guide to NHIs — Static vs Dynamic Secrets describes why static secrets are brittle in fast-moving estates, while the NIST Cybersecurity Framework 2.0 reinforces the need for governance, protection, and continuous oversight across asset lifecycles.
- Use workload identity to authenticate services, jobs, and agents before any secret is issued.
- Prefer ephemeral tokens and JIT access over long-lived shared secrets.
- Centralize policy, but evaluate it at request time with environment context.
- Instrument secret usage so teams can see where credentials move across clouds and pipelines.
- Revoke access automatically when a task, deployment, or session ends.
The practical benefit is reduced blast radius and fewer orphaned credentials. The operational tradeoff is that integration complexity rises at first, especially where legacy apps cannot natively support federated identity or short-lived tokens. These controls tend to break down when older systems require hard-coded credentials and cannot tolerate runtime token exchange.
Common Variations and Edge Cases
Tighter secret lifetimes often increase operational overhead, requiring organisations to balance security gains against application compatibility and platform maturity. Not every workload can move to dynamic secrets immediately, and current guidance suggests prioritizing the highest-risk paths first, especially CI/CD, privileged automation, and cross-cloud integrations. The 230M AWS environment compromise is a reminder that one weak credential path can cascade across an otherwise well-managed estate.
There are also edge cases where centralized vaulting helps, but only if the vault is paired with strong identity controls and tight lifecycle automation. Multi-cloud estates often fragment into multiple secret stores, and NHIMG research notes that organisations maintain an average of six distinct secrets manager instances, which undermines centralized control. That fragmentation is especially dangerous when developers fall back to insecure sharing channels or copy secrets into tooling that was never designed for long-term credential custody. The best answer is usually hybrid: keep legacy vaults where needed, but move new workloads toward short-lived, context-aware credentials and continuous policy enforcement. Security teams should treat static secrets as a temporary exception, not the default operating model.
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 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Addresses secret rotation and lifecycle weaknesses that cloud sprawl exposes. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access is central when workloads and secrets move across clouds. |
| NIST AI RMF | GOVERN | Governance is needed to assign ownership for dynamic, distributed secret use. |
| NIST Zero Trust (SP 800-207) | SC.L1-2 | Zero trust reduces reliance on static trust in cloud and multi-cloud access paths. |
| OWASP Agentic AI Top 10 | A2 | Autonomous agents amplify secret sprawl and need runtime authorization controls. |
Use ephemeral, task-bound credentials for agents and revoke them immediately after use.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
