TL;DR: Poor secrets management remains a leading breach driver, with the 2025 Verizon DBIR citing credential abuse as the initial attack vector in 22% of breaches; the article argues that cloud teams should move from long-lived secrets to workload identity and tightly governed rotation. Static credentials create persistent exposure windows that modern NHI programmes can no longer treat as manageable.
NHIMG editorial — based on content published by Aembit: securing cloud secrets with identity-first access and rotation discipline
Questions worth separating out
Q: How should security teams govern long-lived cloud secrets?
A: They should treat long-lived secrets as a residual risk to be minimized, not a normal operating state.
Q: Why do exposed API keys create such a large blast radius?
A: Because many API keys and tokens authenticate not just one service, but a chain of databases, pipelines, and downstream systems.
Q: What breaks when secrets are never rotated?
A: The main failure is persistence.
Practitioner guidance
- Replace static secrets with workload identity federation Move cloud workloads toward short-lived, cryptographically asserted identities wherever the runtime and trust boundary support it.
- Automate rotation for every long-lived credential Set rotation based on age, use, and security events, and make revocation automatic when a secret is suspected to be exposed.
- Scope each credential to the smallest viable blast radius Use RBAC, JIT elevation, and access reviews to keep secrets tied to one workload, one environment, or one task.
What's in the full article
Aembit's full guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step patterns for replacing static credentials with cloud IAM roles and workload identity federation.
- Specific rotation models for time-based, usage-based, and event-driven secret updates across cloud environments.
- Practical vault design tradeoffs for single-environment and multi-environment deployments.
- Detailed guidance on auditing, alerting, and compliance evidence for secret access and revocation.
👉 Read Aembit's guide to securing cloud secrets and workload identity →
Cloud secrets sprawl: is your NHI programme still built on static credentials?
Explore further
Secrets sprawl is the identity problem hiding inside cloud operations. The article is correct that secrets now live in repositories, config files, containers, laptops, and pipelines, but the deeper issue is that every new non-human workload adds another identity boundary to govern. That makes secrets management a lifecycle discipline, not a storage discipline. Practitioners should treat uncontrolled secret placement as a sign that NHI governance has not yet been centralised.
A few things that frame the scale:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
A question worth separating out:
Q: How can organisations reduce credential abuse in cloud environments?
A: They should combine elimination, rotation, and scope control. Eliminate secrets where workload identity federation is available, rotate the rest automatically, and restrict access through least privilege and JIT elevation. That combination reduces both the number of exploitable credentials and the amount of access any single credential can unlock.
👉 Read our full editorial: Secrets management for cloud NHIs is shifting to identity-first access