TL;DR: Poor secrets management remains a leading breach driver, with credential abuse cited in 22% of breaches in the 2025 Verizon DBIR, while cloud environments add more API keys, tokens, and certificates that must be secured, according to Aembit. Static credentials extend exposure windows; identity-first access and workload identity are the governance shift.
At a glance
What this is: This guide argues that cloud secrets management is moving from static credential storage toward identity-first access, because long-lived secrets, sprawl, and weak rotation create persistent exposure for NHIs.
Why it matters: It matters because IAM and NHI teams need controls that reduce the lifecycle of machine credentials, not just centralise them, especially as cloud and automated workloads multiply.
By the numbers:
- Poor secrets management is a leading cause of data breaches, and the 2025 Verizon Data Breach Investigations Report cites credential abuse as the initial attack vector in 22% of breaches.
Context
Cloud secrets management is the discipline of controlling API keys, passwords, certificates, tokens, and other credentials that systems use to authenticate, authorise, and encrypt traffic. In this article’s framing, the problem is not only whether secrets are stored securely, but whether the operating model still depends on long-lived credentials that create unnecessary exposure for non-human identities.
The governance gap is familiar to IAM teams: as more workloads, CI/CD systems, and AI-driven automation appear, secrets spread across code, pipelines, and configuration stores faster than manual review can keep up. That makes rotation, revocation, and access scoping harder to sustain, which is why the move toward identity-first access matters for NHI programmes.
Key questions
Q: What breaks when cloud teams still rely on static secrets for NHIs?
A: Static secrets create a persistent exposure window. Once a token, key, or password leaks into code, logs, or a pipeline, it can be reused until rotation or revocation happens. That is why static secrets undermine NHI governance: the credential often survives longer than the workload, the incident, or the team’s ability to notice the exposure.
Q: Why do stored NHI credentials increase cloud compromise impact?
A: Because the credential becomes a standing ticket into cloud services until it is rotated or revoked. Attackers can create resources, access data, and establish persistence before defenders notice, which turns one exposed secret into spend, data loss, and recovery work. The longer the secret lives, the larger the blast radius.
Q: When should organisations move from vault-based secrets to workload identity?
A: Organisations should make the move when workloads are growing faster than manual credential handling can safely support, or when the same secret is reused across services. If onboarding, rotation, and offboarding are already brittle, workload identity becomes a governance necessity rather than an optimisation.
Q: What controls matter most when secrets cannot be eliminated?
A: Rotation, least privilege, and auditability matter most. If a secret must exist, it should be scoped narrowly, rotated automatically, and monitored continuously so that exposure does not become open-ended. Access reviews and event logging help, but only if the credential lifecycle is actively governed from creation through revocation.
Technical breakdown
Why static credentials create persistent NHI exposure
A static secret is any credential that remains valid until someone rotates or revokes it. In cloud environments, that includes API keys, database passwords, tokens, and service credentials embedded in code or deployment tooling. The technical problem is persistence: once a secret is copied, logged, committed, or cached, it becomes reusable until its lifecycle is actively managed. For NHI governance, that turns compromise detection into a race against time, because the credential itself outlives the event that exposed it.
Practical implication: reduce the number of secrets that can survive beyond a task, environment, or deployment cycle.
How workload identity federation changes the trust model
Workload identity federation replaces stored shared secrets with short-lived credentials issued after the workload proves its identity through a trusted provider. Instead of authenticating with a reusable token, the workload exchanges evidence for temporary access scoped to a specific environment or trust boundary. That shifts control from secret storage to identity assertion, which is why it fits multi-cloud and hybrid architectures better than manual secret distribution. It also reduces the bootstrapping problem that appears when a vault needs a secret to unlock another secret.
Practical implication: prefer federated workload identity wherever the platform stack can support it.
Why vaults still matter even after identity-first access
A secrets vault centralises storage, logging, policy enforcement, and scoped distribution for the credentials you cannot eliminate. But a vault does not solve the full lifecycle problem on its own, because it still needs secure bootstrap, rotation discipline, and consistent policy across environments. The article’s point is that vaults are a control layer, not the end state. In mature NHI programmes, the vault becomes the fallback for exceptions, not the default identity mechanism for every workload.
Practical implication: use vaults to constrain exceptions, not as a substitute for workload identity.
Threat narrative
Attacker objective: The attacker wants durable access to cloud services and downstream systems by abusing a valid credential rather than exploiting a vulnerability.
- Entry occurs when a leaked API key, token, or hardcoded secret is exposed in code, CI/CD configuration, or another accessible store.
- Credential abuse follows when the attacker reuses the valid secret to reach databases, pipelines, or connected services without needing further authentication.
- Impact occurs when that standing credential allows lateral movement, data access, or persistence until the secret is rotated or revoked.
Breaches seen in the wild
- Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Identity-first access is now the practical control boundary for cloud NHI secrets. Static credential governance assumes secrets can be stored, monitored, and rotated fast enough to stay ahead of exposure. In cloud and automated environments, that assumption no longer holds once workloads, pipelines, and AI-driven processes multiply. The implication is that secrets management should be treated as an exception path, not the operating model.
Long-lived secrets create an identity blast radius that exceeds their original purpose. A database password or API key is rarely confined to one system once it enters code, logs, CI/CD, or support workflows. That is why the article’s emphasis on revocation and rotation is really about limiting how far a single secret can travel through an environment. Practitioners should think in terms of blast-radius reduction, not just storage hygiene.
Workload identity federation changes the NHI lifecycle assumption, not just the access method. NHI controls were built for credentials that could be inventoried and rotated on a schedule. Federation removes the need to preserve many of those credentials at all, which makes lifecycle governance sharper and simpler where it is supported. For the field, that means treating ephemeral credential issuance as the baseline design goal.
Secrets managers remain necessary, but only where identity-first access cannot yet fully replace secrets. The strongest programmes will use vaults to govern residual credentials while shrinking the population of credentials that need vaulting in the first place. That is a maturity shift from managing secrets everywhere to eliminating them wherever the workload trust model allows.
Cloud secrets risk is now a lifecycle and architecture problem, not a storage problem. The article connects leakage, rotation, privilege scoping, and multi-cloud consistency into one operational issue. That is the right framing for NHI governance because the control failure is usually not a single missing vault, but a system that still depends on credentials lasting longer than the workload that uses them.
From our research library:
- 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
Secret sprawl is the real boundary problem for NHI governance. When secrets are spread across code, config files, CI/CD systems, and developer endpoints, the control challenge shifts from vault design to lifecycle visibility. If the organisation cannot inventory where credentials exist, it cannot credibly claim to govern their access scope, rotation, or revocation.
Identity-first access is the cleanest way to shrink credential blast radius. Secrets stored outside managed systems are exposed in vulnerable locations including code, config files, and CI/CD tools according to the Ultimate Guide to NHIs. The programme implication is straightforward: every workload that can move to ephemeral trust should do so, because the risk is not just leakage but credential persistence.
CI/CD is now a first-class secrets domain, not a supporting control plane. 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026. That means pipeline identity, build credentials, and runtime secrets need the same governance attention once reserved for production accounts.
For practitioners
- Reduce long-lived credentials first Inventory API keys, passwords, certificates, and tokens that persist beyond a deployment or workload session, then prioritise the ones exposed in code, pipelines, or shared configs.
- Shift eligible workloads to federated identity Replace stored shared secrets with cloud IAM roles and workload identity federation where the platform supports short-lived trust exchange across environments.
- Automate rotation for unavoidable secrets Set rotation triggers by time, use, or security event so that static credentials do not survive long enough to become reusable attack paths.
- Tighten secrets access by role Limit who can read or retrieve secrets, apply just-in-time elevation for exceptional access, and review permissions that outlast the operational need.
- Centralise audit and alerting for secrets activity Log access, policy changes, failed retrievals, and rotation events, then alert on unusual access patterns, unexpected locations, or off-hours retrievals.
Key takeaways
- Cloud secrets risk is driven less by storage location alone than by credentials that remain valid long after the workload or deployment that used them.
- The article ties poor secrets management to breach exposure, with credential abuse cited in 22% of breaches in the 2025 Verizon DBIR.
- The most defensible control shift is from static credential administration toward identity-first access, with vaults used only where federation is not yet possible.
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 MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centres on secrets exposed in code, CI/CD, and config stores. |
| NHI-07 — Long-Lived Secrets | Static credentials and manual rotation are the main risk pattern described. | |
| NHI-05 — Overprivileged NHI | The guide stresses scoped access and least privilege for secrets-bearing workloads. | |
| Recommendation — Scan for exposed secrets and remove leaked credentials from code and pipeline stores immediately. Replace long-lived credentials with short-lived alternatives wherever workload trust allows. Constrain secrets access to the minimum role scope needed for each workload or operator. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Rotation, revocation, and credential lifecycle control are central to the article. |
| Recommendation — Apply authenticator management controls to automate rotation and revoke stale credentials quickly. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article focuses on scoping and reviewing access to secrets and workloads. |
| Recommendation — Review and restrict entitlements so secret access stays aligned to current operational need. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article describes stolen secrets enabling broader internal access and movement. |
| Recommendation — Map leaked secrets to credential access and lateral movement paths in detections and investigations. | ||
Key terms
- Secrets Sprawl: The uncontrolled proliferation of sensitive credentials, API keys, tokens, passwords, certificates, across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
- Workload Identity Federation: A mechanism allowing workloads in one environment to authenticate to another using short-lived tokens rather than stored credentials, based on mutual trust between identity providers.
- Secret Zero: Secret zero is the first credential needed to reach a secrets store, identity broker, or protected system. It is the root trust dependency that often survives even when everything else is rotated. If that initial credential is exposed, the rest of the secret model can collapse very quickly.
- Long-Lived Secret: A long-lived secret is a credential, token, API key, or certificate that remains valid for an extended period without frequent renewal. In NHI environments, it creates durable exposure because one leaked secret can keep granting access long after the original use case has changed.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 8, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org