TL;DR: Credential abuse stayed the leading breach entry point while 28.65 million new hardcoded secrets appeared in public GitHub commits in 2025 and many exposed secrets remained active for years, according to Aembit citing the 2025 Verizon DBIR, GitGuardian and IBM. Static credentials now create a persistent identity exposure window, not a solved control problem.
At a glance
What this is: This analysis ties together breach data and secrets-sprawl research to show that stolen credentials, hardcoded secrets and slow revocation are reinforcing the same exposure pattern.
Why it matters: IAM, PAM and NHI teams need to treat static credentials as an active breach surface because the same control gaps affect human accounts, service accounts and workload identities.
By the numbers:
- Credential abuse accounted for 22% of all breaches as an initial access vector.
- 64% of valid secrets exposed in 2022 were still active in 2026.
Context
Credential abuse is the use of stolen or reused usernames, passwords, tokens, API keys or other secrets to gain access. In this article's framing, the problem is not a single compromised account but a credential ecosystem that keeps producing usable access across human identity and NHI programmes.
The governance gap is lifecycle control. Static credentials move across repositories, collaboration tools, SaaS environments and workload connections faster than manual ownership, revocation and rotation processes can keep up, so breach exposure persists long after initial discovery.
Key questions
Q: What breaks when stolen credentials are the main entry point for breaches?
A: When stolen credentials become the primary entry point, traditional perimeter and exploit-focused controls lose much of their value because the attacker is already authenticated. Defenders then need stronger context checks, tighter privilege boundaries and faster revocation. The real failure is assuming authentication success means legitimate access, which is no longer true in credential-heavy breach patterns.
Q: Why do hardcoded secrets keep creating breach exposure even with a vault in place?
A: Because a vault does not remove the original secret from code, tickets, chat or build logs once it has escaped. Exposure can persist across copies, forks and caches, and delayed revocation leaves the credential usable long after discovery. The problem is lifecycle control, not storage alone.
Q: How can teams tell whether secret rotation is actually reducing risk?
A: Teams should look at whether a rotated secret was ever exposed at runtime, whether it still works in downstream systems, and how quickly it can be revoked everywhere it matters. Rotation only reduces risk if the old credential cannot be reused and the replacement is not injected as another durable secret. Otherwise, the attack window remains open.
Q: When should organisations move from service accounts to workload identities?
A: They should move when an account is used for unattended cloud operations, scripted administration, or infrastructure provisioning. In those cases, managed identities or service principals usually fit the execution model better because they avoid human sign-in assumptions and reduce the chance that MFA policy will disrupt business operations.
Technical breakdown
Why stolen credentials still drive initial access
Stolen credentials remain effective because they look like legitimate authentication, especially when attackers use them once per account, vary timing and blend into normal login traffic. In basic web application attacks, reused credentials and credential stuffing can evade simple rate limits because the request itself is valid, even if the source is malicious. This is why credential abuse persists alongside MFA and password policy programmes. The failure is not authentication in the abstract. It is the assumption that possession of a usable credential still implies trustworthy context at sign-in time. Practical implication: treat credential use as a continuously monitored event, not proof of legitimacy.
Practical implication: Correlate login behaviour, device context and source reputation before trusting a successful sign-in.
How hardcoded secrets become a long-lived breach surface
Hardcoded secrets turn code repositories, chat tools and ticketing systems into credential distribution channels. Once a token, API key or certificate lands in source control or collaboration content, its exposure can persist through forks, caches, logs and downstream copies even if the original file is later removed. Rotation helps only after discovery, and delayed revocation leaves the secret valid throughout the exposure window. This is a classic NHI governance failure because the identity is now detached from the system that owns it. Practical implication: inventory secrets where they actually live, not only where teams think they should live.
Practical implication: Scan code, tickets and collaboration tools together, then revoke leaked secrets immediately rather than waiting for rotation cycles.
Why third-party and workload credentials expand the blast radius
Third-party access and workload credentials widen exposure because ownership, responsibility and authentication boundaries are often split across teams and vendors. When a SaaS account, service account or API key is shared across integrations, the credential can outlive the relationship or the workload that created it. That creates persistence for attackers and weakens offboarding discipline. The same pattern appears across human and non-human identity programmes: if no owner can answer who should revoke the credential, it will remain active too long. Practical implication: map each high-value connection to a named owner, a renewal condition and a revocation path.
Practical implication: Assign explicit ownership to every third-party and workload credential, then tie revocation to offboarding and change events.
Threat narrative
Attacker objective: The attacker wants durable access through legitimate-looking authentication so they can move deeper into connected systems without triggering obvious exploitation signals.
- Entry occurs when attackers use stolen credentials, credential stuffing or exposed secrets to authenticate as a legitimate user or workload.
- Escalation follows when valid access is reused across services, partner environments or cloud workloads that share trust with the first account.
- Impact emerges as attackers reach databases, customer records, financial APIs or ransomware staging paths that were reachable through the compromised identity.
Breaches seen in the wild
- PyPI secrets exposure 2023: Researchers found 3,938 unique secrets in published PyPI packages, 768 still valid; a new release or yank does not remove them.
- 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.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Credential abuse is now a lifecycle problem, not just an authentication problem: the breach pattern begins long before sign-in and continues long after compromise. Static credentials, exposed secrets and delayed revocation create the conditions for repeated abuse across human accounts, service accounts and workloads. The practitioner conclusion is that identity governance has to follow the credential through creation, use, exposure and offboarding.
Hardcoded secrets are a governance failure in source control and collaboration systems: the article shows that private repositories, Slack, Jira and Confluence can hold more usable secrets than teams expect. That means the control boundary is broader than the vault. The practitioner conclusion is that secret discovery must extend across developer and collaboration surfaces, not stop at code scanning alone.
Vendor and workload access without clear offboarding ownership is the most dangerous scaling problem: once an integration depends on a shared credential, no one owns the end of its life unless the programme makes that explicit. That is why third-party exposures and lingering valid secrets persist. The practitioner conclusion is that ownership, renewal and revocation must be assigned at the identity level, not the application level.
Blast-radius reduction matters more than rotation theatre: rotation only changes the length of exposure if the credential is already discovered; it does not remove the trust assumption that the secret can be reused. Secrets management therefore helps most when it is paired with scoped access and identity-based runtime verification. The practitioner conclusion is to measure exposure by reachable privilege, not by the existence of a vault.
Static credential dependence is now the named concept to watch: the article makes clear that modern breach exposure comes from organisations continuing to depend on credentials that are both reusable and discoverable. That dependence breaks the assumption that access can be controlled once and left in place. The practitioner conclusion is to treat static credential dependence as a programme-level risk indicator, not a line-item hygiene issue.
From our research library:
- 30.9% of organisations store long-term credentials directly in code, according to the Ultimate Guide to NHIs.
- 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to the State of Secrets Sprawl 2026.
- Read next: Secrets Management Buyer's Guide
What this signals
Static credential dependence: organisations should treat reusable credentials as a programme-level exposure signal, because the same secret can sit in code, collaboration tools and cloud integrations at once. The practical shift is from counting secrets to reducing how many places an identity can be reused, leaked or revived.
The strongest operational signal is not how many secrets exist but how long compromised ones remain valid. When revocation lags discovery, the control failure is lifecycle governance, not missing tooling, and that gap applies equally to human, NHI and service-account estates.
For practitioners
- Audit exposed credential paths Search code repositories, collaboration tools and CI/CD logs for hardcoded secrets, then classify each finding by owner, privilege scope and revocation path.
- Move high-value connections to workload identity Prioritise production databases, financial APIs and customer data stores for secretless workload-to-workload access so those flows no longer depend on reusable static credentials.
- Make revocation faster than rotation If a secret leaks, revoke it immediately and treat scheduled rotation as a backstop, not the primary control.
- Assign identity owners to third-party and service credentials Tie every external integration, service account and API key to a named owner, a renewal event and a documented offboarding trigger.
- Monitor for credential reuse across environments Look for the same username, token or key appearing in multiple services, because reuse expands blast radius and makes compromise portable.
Key takeaways
- Credential abuse remains a dominant breach path because stolen and reused secrets still authenticate like legitimate access.
- Hardcoded secrets and slow revocation turn short-lived mistakes into long-lived exposure windows across repositories, chat systems and cloud workflows.
- The control answer is not rotation alone but faster revocation, tighter ownership and more runtime identity-based access for the highest-value connections.
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 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Hardcoded secrets and exposed credentials are the core risk in this article. |
| NHI-07 — Long-Lived Secrets | The article highlights secrets that remain valid for years after exposure. | |
| NHI-05 — Overprivileged NHI | The article stresses that reused secrets often carry more access than necessary across systems. | |
| Recommendation — Scan repositories, chat tools and CI logs for secret leakage and revoke exposed credentials immediately. Reduce long-lived secret exposure by replacing static credentials with shorter-lived access wherever possible. Review NHI privilege scope and remove excess access before leaked credentials can be reused across environments. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential lifecycle and revocation are central to the breach exposure described here. |
| Recommendation — Apply authenticator management controls to enforce rotation, revocation and secure issuance of credentials. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article centers on stolen credentials being used to enter and move through environments. |
| Recommendation — Map credential abuse to credential access and lateral movement tactics, then prioritize detections around reuse and propagation. | ||
Key terms
- Credential Abuse: Credential abuse is the use of valid secrets or accounts by an unauthorised party or for unauthorised purposes. In practice, it often looks like normal authentication unless teams correlate context, privilege, and behaviour. It is one of the most persistent ways identity failures become breaches.
- Hardcoded Secret: A hardcoded secret is a credential written directly into source code, scripts, configuration files, or build assets. It is convenient for development but dangerous in production because it can be copied, indexed, propagated, and reused outside the intended control boundary.
- 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: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.
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 June 6, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org