TL;DR: Weak secrets management now drives a large share of cloud incidents, with Cycode citing 22% of overall security incidents in 2025 stemming from credentials in public view. The real problem is not storage alone but secret sprawl across code, CI/CD, and collaboration tools, where rotation and detection must work together.
At a glance
What this is: This is a 2026 secrets management comparison that argues vault-centric programs miss the larger problem of exposed, hardcoded, and unrotated credentials spread across delivery and collaboration systems.
Why it matters: IAM and NHI teams need to treat secrets detection, validation, and rotation as one governance problem because storage control alone does not stop credentials from leaking into developer workflows.
By the numbers:
- 22% of overall security incidents in 2025 stemmed from credentials in public view.
- 43% of all exposed secrets reside outside code repositories, with 14% found in messaging and collaboration platforms like Slack, Jira, and Confluence.
- 26% of secret exposures occur in CI/CD workflows.
Context
Secrets management is not just a storage problem. In practice, the governance gap appears when credentials are created, copied, embedded, shared, and reused faster than teams can track them across code, CI/CD, and collaboration tooling.
Cycode's 2026 guide frames vaults as one control in a larger lifecycle, not the whole answer. That matters for NHI and workload identity because an exposed API key, token, or certificate is already an identity event, even if it was never meant to become one.
The core issue is secret sprawl: credentials leave approved systems and reappear in places security teams do not continuously govern. When that happens, rotation, validation, and detection all need to be part of the same operating model.
Key questions
Q: What breaks when secrets are still stored outside managed vaults?
A: Secrets become easy to reuse across humans, scripts, and agents without a consistent audit trail. That increases the chance of exposure, weakens revocation, and makes it unclear which identity used the credential. A vault is only useful if it is the normal access path, not an optional store.
Q: Why do exposed API keys and weak API controls create outsized breach risk?
A: Exposed API keys are powerful because they often grant direct access to applications, data, and automation paths without the friction of interactive login. If keys are reused, overprivileged, or poorly monitored, a single leak can enable broad unauthorized access and rapid abuse. API controls matter because digital services increasingly depend on machine-to-machine access that attackers can exploit quietly.
Q: How can security teams tell whether secret management is actually working?
A: Look for fewer plaintext secrets, narrower reuse, faster rotation, and a shrinking set of credentials that remain valid across multiple systems. If the same password or API key can still unlock several services, secret management is not yet reducing blast radius in practice.
Q: How should organisations respond when vulnerable code also contains secrets?
A: Treat it as both an application defect and an identity exposure event. Revoke or rotate the exposed credentials, search for reuse across pipelines and services, and investigate whether the secret enabled access beyond the original codebase. The remediation path should follow the credential, not only the repository.
Technical breakdown
Why vault-only secrets control breaks down
A vault controls storage and retrieval, but it does not govern every place a secret can appear. Once a credential is hardcoded into a repo, pasted into a ticket, or echoed into a pipeline log, the vault is no longer the only system in scope. That is why modern secrets management needs both preventive controls, such as dynamic retrieval and rotation, and detective controls that scan code, CI/CD, chat, and documents. The technical mistake is treating the vault as a boundary instead of a component in a wider credential lifecycle.
Practical implication: map where secrets can surface outside the vault and treat each surface as a governed control point.
How secret detection and validation change operational risk
Secret detection finds exposed credentials where they should not exist, while validation determines whether a discovered secret is still active. That distinction matters because an inactive secret is still evidence of process failure, but an active one is an immediate access path. Validation also helps prioritise response, reducing noise when thousands of findings exist. In mature programmes, detection, validation, and rotation are chained together so that exposure discovery is not just logged but converted into an identity decision about whether access still exists.
Practical implication: pair discovery with validation so teams can distinguish historical exposure from live credential risk.
Why hardcoded secrets and unrotated credentials create persistent attack paths
Hardcoded secrets are dangerous because they turn source code and configuration into credential stores that attackers can search at scale. Unrotated credentials extend that danger by keeping the same access path valid long after the original use case changed. The result is persistence without intrusion, where discovery alone is enough to authenticate. For NHI governance, that means credential age, storage location, and usage context all matter. A secret is not safe simply because it was once placed in a trusted platform.
Practical implication: treat credential age and repository location as separate risk dimensions during review.
Threat narrative
Attacker objective: The objective is to obtain valid access by discovering exposed credentials and using them before they are rotated or revoked.
- Entry begins when API keys, passwords, or tokens are hardcoded into repositories, configuration files, or collaboration tools instead of being kept inside governed systems.
- Credential access follows when exposed secrets are discovered and reused directly, without needing exploitation of an application flaw.
- Impact occurs when the attacker or unauthorised user authenticates with live credentials, creating breach, ransomware, or compliance consequences.
Breaches seen in the wild
- 12,000 secrets in LLM training data: Truffle Security found 11,908 live API keys and passwords hard-coded in web pages captured by Common Crawl, a dataset used to train LLMs.
- OneLogin API flaw (CVE-2025-59363): A OneLogin API flaw exposed OIDC client secrets to anyone with an API key, including vendors (CVE-2025-59363); fixed with no customer impact.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Vault-only control is an incomplete governance model: a vault governs secret storage, not secret exposure. Once credentials move into code, chat, documentation, or CI/CD logs, the control boundary has already been crossed and the programme is relying on detective coverage it may not have. Practitioners should treat vaults as one layer in credential governance, not the governance model itself.
Secret sprawl is now a lifecycle problem, not a storage problem: the article's most important message is that credentials fail when creation, distribution, runtime use, and retirement are managed separately. This is the same pattern that creates NHI governance debt elsewhere: identity is not just where the credential lives, but where it travels and how long it remains valid. Teams need a lifecycle view of every secret, not a vault-centric inventory.
Exposure outside source control is the named concept that should change prioritisation: once secrets appear in collaboration tools and pipeline artefacts, the highest-value control is no longer central vault adoption but broad discovery coverage. The issue is not whether a secret is stored securely somewhere, but whether the organisation can see where it escaped and whether it is still live. Practitioners should re-order controls around visibility and validation.
Hardcoded and unrotated secrets create identity persistence without governance: a credential can remain usable long after the business need has ended, which means access survives the workflow that created it. That is a lifecycle failure, not just a bad practice. Security teams should treat every exposed secret as an offboarding problem for a machine identity.
Secrets management and secrets detection are complementary controls, not competing tool categories: the article correctly separates known-system governance from exposure discovery. That distinction matters because a mature programme needs both prevention inside approved systems and detection outside them. Practitioners should stop evaluating secrets tooling as a single-feature purchase and assess whether the stack covers the full credential path from issuance to exposure to revocation.
From our research library:
- 88% of security professionals are concerned about secrets sprawl, with 49% of those in larger organisations described as "very concerned", according to the 2024 State of Secrets Management Survey.
- Organisations that rely heavily on static credentials reported a 20-percentage-point increase in security incidents compared with those with low reliance, according to the 2026 Infrastructure Identity Survey.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
Exposure outside the vault is the control gap to watch: the next stage of secrets governance is not more storage consolidation, but broader visibility into where credentials escape during development and collaboration. That means scanning repositories is necessary but insufficient unless the programme also covers tickets, chat, pipelines, and object storage.
Discovery without validation creates noise, not governance: security teams need to know whether a found secret is active before they can decide whether to rotate, revoke, or simply record it. That shifts secrets management from a storage-centric discipline to a lifecycle-control discipline, which is where the strongest identity programmes are heading.
For practitioners
- Map all secret exposure surfaces Inventory repositories, CI/CD pipelines, collaboration platforms, configuration files, and object storage where credentials can appear outside the vault.
- Add validation to secret discovery Require every exposed secret finding to be checked for live status so triage separates stale artefacts from active credentials.
- Shorten credential lifetime aggressively Replace long-lived API keys, passwords, and tokens with dynamic credentials or tightly bounded rotation schedules wherever the system allows it.
- Treat collaboration tools as secret stores Apply the same scanning and alerting to Slack, Teams, Jira, and Confluence that you already apply to source control.
- Tie revocation to exposure response Define a response path that revokes or rotates live credentials as soon as discovery confirms they are still active.
Key takeaways
- Secrets management tools now have to govern exposure as well as storage because credentials leak into code, chat, pipelines, and configuration outside the vault.
- The article ties weak credential handling to a material share of security incidents, which is why detection and rotation can no longer be separated in practice.
- Practitioners should judge tooling by how well it finds live secrets, tracks where they escaped, and drives revocation before those credentials become usable access paths.
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 CSF 2.0 and CIS Controls v8 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 exposed secrets in code, chat, and pipelines. |
| NHI-07 — Long-Lived Secrets | Unrotated credentials are a key driver of the risk described here. | |
| NHI-01 — Improper Offboarding | Live secrets must be revoked when the workflow or system no longer needs them. | |
| Recommendation — Scan for leaked secrets across the SDLC and revoke any credential discovered outside approved storage. Reduce credential lifetime and replace static secrets with dynamic or short-lived alternatives. Tie secret revocation to offboarding events for applications, environments, and integrations. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The topic is governed access to non-human credentials and their lifecycle. |
| Recommendation — Review secret entitlements regularly and remove access that is no longer required. | ||
| CIS Controls v8 | CIS-5 — Account Management | Secrets function as accounts for applications and services in this article. |
| Recommendation — Inventory and manage machine credentials with the same discipline used for user accounts. | ||
| MITRE ATT&CK | TA0006 — Credential Access | Exposed API keys and tokens create direct credential-access opportunities for attackers. |
| Recommendation — Map exposed-secret findings to credential access activity and prioritise remediation on live credentials. | ||
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.
- Secret Validation: Secret validation is the attacker practice of testing stolen credentials against the target provider to confirm that they still work. In supply chain attacks, this turns a stolen token from a possibility into an active access path, often within minutes or hours of theft.
- 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.
- Dynamic credentials: Dynamic credentials are secrets issued on demand and allowed to expire automatically after a defined use window. They reduce exposure by limiting how long a credential can be reused, but they only work when applications and access policies can support short-lived authentication without manual exceptions.
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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on August 20, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org