Topic starter
06/06/2026 2:25 am
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.
Editorial analysis by NHI Mgmt Group, based on content published by Aembit: “Credential and Secrets Theft: Insights from the 2025 Verizon Data Breach Report”.
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.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Credential abuse remains a dominant breach path because stolen and reused secrets still authenticate like legitimate access.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
06/06/2026 4:05 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Credential abuse and secrets sprawl are driving breach exposure
This post was modified 1 day ago by NHI Mgmt Group