Secrets management for cloud NHIs is shifting to identity-first access

At a glance

What this is: This is a cloud secrets management analysis that argues long-lived credentials, secrets sprawl, and weak rotation are the main failure points in modern NHI environments.

Why it matters: It matters because IAM, PAM, and cloud security teams must govern machine access as a lifecycle problem, not just a storage problem, across workloads, pipelines, and human operators.

By the numbers:

• The 2025 Verizon Data Breach Investigations Report shows that credential abuse is cited as the initial attack vector in 22% of breaches.

👉 Read Aembit's guide to securing cloud secrets and workload identity

Context

Secrets management is the discipline of controlling credentials, tokens, certificates, and keys so they do not become a permanent path into production systems. In cloud environments, the problem is bigger than storage because the same secret often unlocks databases, CI/CD, and downstream services, which turns one leak into broad identity exposure.

The governance gap is that many programmes still treat secrets as static artefacts instead of lifecycle-bound NHI credentials. As AI agents, automation, and multi-cloud workflows expand, the number of places a secret can exist grows faster than the controls used to find, rotate, and revoke it.

Key questions

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. The practical model is short-lived workload identity first, then automated rotation for anything that cannot yet be eliminated. Governance should include inventory, ownership, revocation triggers, and access scope limits so one exposed credential cannot authenticate broadly across production services.

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. If the key is shared across environments or reused by multiple workloads, compromise becomes lateral movement. The bigger the trust surface around the secret, the larger the attack path becomes after exposure.

Q: What breaks when secrets are never rotated?

A: The main failure is persistence. A stolen credential remains valid until someone notices and revokes it, so attackers can keep using it long after the original leak. This also undermines audit confidence, because logs may show access, but they do not reduce the time the secret stays usable.

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.

Technical breakdown

Why long-lived secrets create persistent NHI risk

A long-lived secret is a credential that remains valid until someone rotates or revokes it. That design creates persistence for attackers because compromise is not self-limiting. In cloud environments, the same API key or token can authenticate to multiple services, so one exposed secret often expands into lateral movement across infrastructure. The article’s core technical point is that static credentials undermine the basic assumption that access can be bounded in time. When validity is indefinite, detection without revocation only tells you that the problem exists after the attacker has already had a usable window.

Practical implication: inventory every long-lived credential and treat persistence as an exposure problem, not just a hygiene issue.

Workload identity federation versus secret bootstrapping

Workload identity federation replaces stored shared secrets with cryptographic proof of workload identity and short-lived credentials. Instead of placing a bootstrap secret in a file or environment variable so a service can talk to a vault, the workload presents attestation from its runtime or cloud provider. This matters because the “secret zero” problem is recursive: the first credential needed to reach the vault is itself another secret that can be exposed. Federation reduces that bootstrap dependency, but only where systems, clouds, and trust boundaries support the exchange model reliably.

Practical implication: prioritise federation for workloads that still depend on a bootstrap secret to reach their own secret store.

Why rotation and least privilege must work together

Rotation shortens exposure time, but it does not solve overbroad access. Least privilege limits what a secret can do if it is stolen, while automated rotation limits how long the stolen secret remains usable. The article also points out that human access, workload access, and AI-driven automation all create different governance pressures, which is why access reviews and JIT controls need to be tied to the identity type involved. A secrets programme that rotates aggressively but leaves broad permissions in place still leaves attackers with too much room to move.

Practical implication: combine automated rotation with scope reduction so a leaked secret has both a shorter life and a smaller blast radius.

Threat narrative

Attacker objective: The attacker wants persistent authenticated access that can be reused across production systems, pipelines, and connected services.

1. Entry occurs when an attacker finds an exposed API key, hardcoded token, or unrotated service credential in a repository, script, or pipeline configuration.
2. Credential access follows when that secret authenticates the attacker to production systems, secret stores, CI/CD tooling, or downstream services without additional verification.
3. Escalation happens when the same identity is trusted across multiple environments and services, allowing lateral movement and broader privilege abuse.
4. Impact is achieved when the attacker can read data, manipulate pipelines, or impersonate workloads at scale before the secret is revoked.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Static credentials are a standing-privilege failure mode, not just a rotation gap. A secret that never expires turns one compromise into durable access, and the article’s examples show how attackers exploit that persistence. This aligns with OWASP-NHI and NIST CSF thinking: if validity outlives business need, access control has already failed. Practitioners should frame unrotated credentials as a blast-radius problem, not a housekeeping issue.

Identity-first access is the named shift this article is really describing. Moving from stored secrets to workload identity federation changes the governance model from “protect the credential” to “prove the workload.” That shift matters because the control point moves earlier in the lifecycle, before a shared secret can be copied, embedded, or reused. Practitioners should recognise this as the point where secrets management stops being reactive and starts becoming identity architecture.

Cloud secrets governance now has to cover human, workload, and automation paths together. The article explicitly connects developers, operators, workloads, and AI agents to the same credential problem, which means access reviews and JIT models cannot stay human-only. That is where NHI and IAM programmes converge. Practitioners should reassess whether one governance model can actually cover every identity subject that can touch a secret.

Persistent credential exposure window is the right failure-mode concept for this topic. The real risk is not just that a secret can leak, but that it can remain valid long after the workload or incident that created it has changed. That window is what attackers exploit, and it is what many manual processes fail to close. Practitioners should use that concept when explaining why detection without automated revocation is incomplete.

From our research:

• 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.
• Guide to the Secret Sprawl Challenge explains how to map exposure paths, ownership, and revocation gaps across cloud estates.

What this signals

Persistent credential exposure window: the real programme risk is not whether secrets exist, but how long they remain usable after exposure. If your controls cannot shorten that window automatically, your detection programme is only measuring damage after the fact.

As non-human identities multiply, secrets governance will increasingly sit at the intersection of IAM, PAM, and cloud operations. Teams that still separate secret storage from access governance will find that their control model does not match how modern workloads and pipelines actually authenticate. The next maturity step is to tie inventory, rotation, and revocation to one ownership model, then validate it against the OWASP Non-Human Identity Top 10.

For practitioners

• Replace static secrets with workload identity federation Move cloud workloads toward short-lived, cryptographically asserted identities wherever the runtime and trust boundary support it. This removes the bootstrap secret that often sits in a config file, environment variable, or script and reduces the number of credentials that can be copied or reused.
• 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. Manual rotation is too slow for credentials that may already be usable inside production and CI/CD systems.
• 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. Broad reuse across services is what turns a single leak into a multi-system compromise.
• Audit secret locations beyond code repositories Search Slack, Jira, Confluence, pipeline configs, container images, and developer endpoints for exposed credentials, because many leaks now originate outside source control. Central visibility is the prerequisite for revocation and compliance evidence.

Key takeaways

• Secrets management failures become identity failures when credentials outlive the workload or process that created them.
• The scale of the problem is now visible in breach data, with credential abuse remaining one of the most common initial attack vectors.
• The strongest control pattern is identity-first access, backed by automated rotation and tight blast-radius scoping.

Key terms

• Secrets sprawl: Secrets sprawl is the uncontrolled spread of credentials, tokens, certificates, and keys across systems, files, and workflows. In cloud environments it usually means the same identity data is duplicated in repositories, CI/CD pipelines, laptops, and configs, which makes discovery, rotation, and revocation slower than attacker reuse.
• Workload identity federation: Workload identity federation is a method for letting a service prove who it is without storing a reusable secret. The runtime exchanges cryptographic proof or provider-issued identity for short-lived credentials, reducing the need for bootstrap passwords, API keys, or tokens that can be copied and abused.
• Persistent credential exposure window: Persistent credential exposure window is the period during which a leaked secret remains valid and useful to an attacker. The longer that window stays open, the more a breach behaves like standing access rather than a one-time leak, which is why revocation speed matters as much as detection.
• Blast radius: Blast radius is the amount of system access, data exposure, or operational damage that a compromised identity can create. For secrets and workload identities, the term describes how far one stolen credential can move across services, environments, and trust boundaries before controls stop it.

Deepen your knowledge

Secrets sprawl and workload identity federation are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme still depends on long-lived credentials, this course helps you build a more defensible starting point.

This post draws on content published by Aembit: securing cloud secrets with identity-first access and rotation discipline. Read the original.