Credential abuse and secrets sprawl are driving breach exposure

At a glance

What this is: This analysis shows that stolen credentials and secrets sprawl now operate as one breach chain, with credential abuse still the leading initial access vector and exposed secrets staying exploitable for years.

Why it matters: IAM teams must treat human and non-human credentials as the same attack surface because the control failures, revocation gaps and ownership issues now cross both domains.

By the numbers:

• Credential abuse accounted for 22% of all breaches as an initial access vector, the single most common entry point.
• 28.65 million new hardcoded secrets were added to public GitHub commits in 2025, a 34% increase year over year and the largest single-year jump on record.
• 64% of valid secrets exposed in 2022 were still active in 2026.

👉 Read Aembit's analysis of credential abuse, secrets sprawl and workload identity

Context

Credential abuse is what happens when an attacker uses stolen or reused secrets to act as a legitimate identity. In practice, that means the breach begins with something security teams already consider normal authentication traffic, which makes detection and containment much harder than with noisy exploit-driven attacks. For NHI programmes, that is the core governance problem: the identity itself becomes the entry point.

The article argues that credential theft and secrets theft are converging into the same operational risk. That matters because human accounts, service accounts, API keys, tokens and certificates are often managed through different teams and different workflows, even though attackers move across them without caring about those boundaries. The result is a single exposure chain that traditional IAM and secrets tooling often treats as separate problems.

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 service accounts and API keys make breach containment harder?

A: Service accounts and API keys often lack the human controls that limit abuse, such as MFA prompts, clear ownership and natural offboarding events. If they are overprivileged or poorly tracked, a single leak can create long-lived access across multiple systems. That makes revocation speed, inventory accuracy and least privilege the decisive containment variables.

Q: How do security teams know whether secret rotation is actually working?

A: Rotation is working only if exposed credentials are found quickly, revoked everywhere they are used and replaced before attackers can reuse them. If a secret remains valid after exposure, or if owners cannot prove where it was deployed, rotation is only reducing exposure on paper. The signal to watch is not the rotation schedule, but the time from leak to invalidation.

Q: What should teams do when a credential leak is discovered in a third-party system?

A: Treat it as a live identity event, not a notification. Revoke the credential, confirm which workloads or accounts depended on it, and review whether the partner environment exposed other credentials with the same privileges. Third-party leaks often become internal breaches because the same identity reaches both environments.

Technical breakdown

Why stolen credentials blend into legitimate authentication traffic

Credential abuse works because attackers do not need to break the authentication system if they already hold valid credentials. In web application attacks, a stolen username and password can look identical to a real user unless the surrounding context is checked, including device, location, request pattern and privilege use. Credential stuffing makes this worse because each login attempt uses a different password once, which avoids obvious lockout thresholds. The technical problem is not authentication failure, but authentication success for the wrong party.

Practical implication: add context-aware detection around login behaviour instead of relying on credential validity alone.

How secrets sprawl creates long-lived access paths

Hardcoded secrets become durable access paths because they are copied into code, collaboration tools, build systems and vendor workflows faster than they are found and removed. Once a secret leaks, rotation only helps if the secret is actually discovered, revoked and replaced everywhere it was deployed. The article’s point is that exposure is not a moment, it is a lifecycle. If revocation is manual or delayed, the leaked credential remains a usable identity artifact long after the original mistake.

Practical implication: connect secret detection to automatic revocation and replacement, not just alerting.

Why workload identity changes the trust model for non-human access

Workload identity replaces stored shared secrets with runtime-issued, policy-scoped credentials. Instead of keeping a static credential in code or config, the workload proves who it is at the moment of access and receives a short-lived credential for that specific transaction. That changes the trust model from possession of a reusable secret to verification of identity and policy at runtime. For NHI governance, this is the architectural shift that matters because it removes the bootstrap dependency on standing secrets for many machine-to-machine connections.

Practical implication: migrate the highest-value service-to-service connections first, especially where static secrets expose customer or financial data.

Threat narrative

Attacker objective: The attacker wants to turn one exposed credential into durable access across accounts, systems and connected services without having to exploit software flaws.

1. Entry begins when attackers obtain valid credentials from infostealer logs, partner exposure or hardcoded secret leaks, then use those credentials against web applications, SaaS accounts or cloud services.
2. Escalation follows when the stolen identity has broader access than the original account owner intended, allowing attackers to move through connected systems without triggering obvious exploit signatures.
3. Impact is realised through ransomware deployment, customer account compromise, data theft or persistence that survives long after the original secret was leaked.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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 the baseline breach condition, not an edge case. Verizon’s 2025 data shows credential abuse as the leading initial access vector for the second consecutive year, which means identity compromise is no longer a secondary step after exploitation. Security teams should read that as a governance signal: if credentials are the primary entry point, then the identity layer is where most breach prevention work now lives. The practitioner conclusion is that access design, not just detection, has to be treated as a first-order control domain.

Static secret governance has become a lifecycle failure, not a discovery failure. GitGuardian’s finding that 64% of valid secrets from 2022 were still active in 2026 shows that the main problem is not finding exposures, it is revoking them. That is a control gap in ownership, offboarding and remediation workflow, not merely in tooling coverage. The practitioner conclusion is that secrets management cannot stop at inventory if the removal step is still manual and incomplete.

Identity blast radius is the right concept for understanding credential-driven breaches. Once a stolen credential can traverse cloud, SaaS and partner systems, the practical question is no longer whether a secret leaked, but how far that identity can move before it is revoked. The article shows that third-party exposure and internal secrets sprawl now feed the same blast radius. The practitioner conclusion is to measure the reachable damage of each credential, not just its existence.

Workload identity is becoming the control plane that separates reusable secrets from runtime access. The article’s emphasis on short-lived, policy-scoped credentials reflects the direction mature NHI governance is heading. Static credential stocks are expanding faster than manual review cycles can handle, so the market is shifting toward verification at use time rather than protection at rest. The practitioner conclusion is to treat runtime identity as the default design goal for machine-to-machine access.

From our research:

• 64% of valid secrets exposed in 2022 were still active in 2026, 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.
• That shift makes the Secret Sprawl Challenge the right next step for teams trying to move from exposure detection to secret elimination.

What this signals

Identity teams should expect credential abuse and secret sprawl to converge into one governance queue. The practical implication is that human IAM, NHI inventory and incident response can no longer run as separate workflows when the same leaked secret can drive both account takeover and workload compromise. Teams that treat them separately will keep missing the handoff point where exposure becomes breach.

Identity blast radius is the concept to operationalise next. Once a secret is exposed, the key question is how many systems it can reach before revocation completes. That is where NHI governance becomes measurable, because blast radius can be mapped by owner, privilege scope and downstream dependency rather than by credential count alone.

A useful signal is whether your organisation can revoke a leaked credential before it is reused in production. If the answer is no, the issue is not discovery. It is the absence of an end-to-end lifecycle path that connects detection, ownership, revocation and workload replacement across environments.

For practitioners

• Prioritise revocation for known exposed secrets Build an incident workflow that revokes a leaked credential as soon as it is discovered, then replaces every dependent secret or token in downstream systems before the next scheduled rotation.
• Move critical service connections to workload identity Start with production databases, financial APIs and customer data services, then replace stored static secrets with runtime-issued credentials that expire automatically after use.
• Correlate login anomalies with secret exposure signals Join infostealer intelligence, SaaS authentication logs and CI/CD secret scanning so the team can spot whether a valid credential is being used outside its expected workload or user context.
• Track secret ownership and offboarding explicitly Assign each non-human credential to a named system owner, require a decommissioning step when the workload is retired, and verify that orphaned service accounts are removed from every environment.

Key takeaways

• Credential abuse remains the dominant breach entry point, which means identity controls are now front-line security controls rather than supporting hygiene.
• Secrets sprawl is worsening faster than teams can revoke exposures, leaving valid credentials usable long after discovery.
• The most effective response is to shrink static credential use and move critical machine access to runtime-issued workload identity.

Key terms

• Credential Abuse: Credential abuse is the use of stolen, reused or leaked secrets to gain legitimate-seeming access. It succeeds because the attacker does not need to break authentication, only to present valid proof that still works. For NHI governance, it turns identity material into the attack path itself.
• Secrets Sprawl: Secrets sprawl is the uncontrolled spread of credentials across code, configuration, chat tools, build systems and third-party services. It becomes dangerous when no one can prove where each secret lives or who owns its revocation. The result is persistent exposure long after the original leak is found.
• Workload Identity: Workload identity is the runtime identity of a service, application or machine that proves who it is without relying on a reusable static secret. It supports short-lived, policy-scoped access and is central to modern NHI governance because it reduces the number of secrets that can be stolen and reused.
• Identity Blast Radius: Identity blast radius is the amount of damage a compromised identity can cause before it is revoked. It depends on privilege scope, downstream connections and how quickly owners can respond. This concept helps teams measure risk in terms of reachable systems, not just the number of exposed credentials.

Deepen your knowledge

Credential abuse, secret sprawl and workload identity are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a governance programme around exposed secrets and non-human access, it is worth exploring.

This post draws on content published by Aembit: credential abuse, secrets sprawl and what security teams should do now. Read the original.