Credential stuffing exposes the gap between detection and enforcement

At a glance

What this is: This is an analysis of credential stuffing and why WAF-based blocking often fails to act on the detection signals that reveal it.

Why it matters: It matters because IAM, PAM, and identity security teams need enforcement that can use cross-account login patterns, not just request-by-request web controls, to stop valid sessions from being hijacked.

👉 Read Impart Security's analysis of credential stuffing and WAF enforcement gaps

Context

Credential stuffing is a form of account takeover in which attackers reuse breached username and password pairs until they find accounts that still accept them. The security gap is not limited to weak passwords. It is the mismatch between identity risk signals, which are visible across sessions and accounts, and enforcement layers that often evaluate one request at a time.

In practice, this makes identity governance part of web abuse defence, not a separate concern. When login anomalies, credential velocity, and session history are split across tools, teams may recognise the attack without being able to stop it. That intersection matters for human identity programmes, and it also informs how NHIs and automated clients should be monitored when they interact with the same auth paths.

Key questions

Q: What breaks when credential stuffing controls rely on WAF rules alone?

A: WAF rules usually see isolated requests, while credential stuffing is a cross-account pattern. That means the control can be too blunt, blocking legitimate users, or too weak, missing rotated user agents and distributed proxies. Effective defence needs shared identity and session context at the point where enforcement happens, not only downstream web filtering.

Q: Why do password reuse and credential stuffing remain so effective?

A: They remain effective because many users still reuse passwords and many environments still accept credentials without enough contextual risk checks. Attackers can test stolen credentials at scale, often quietly enough to avoid detection. The more identities that share a secret pattern, the more one breach can become many account takeovers.

Q: How do security teams know if stuffing controls are working?

A: Look for reduced account velocity from shared source patterns, fewer successful logins from breached credential lists, and lower post-authentication abuse after the control is enabled. A good signal set should show both fewer false positives and fewer valid sessions created from suspicious login bursts.

Q: What should teams do when credential stuffing is confirmed?

A: Contain it in the authentication path first. Prioritise blocking or step-up decisions for the affected login flow, preserve the evidence trail, and avoid broad account lockouts unless the attack pattern justifies them. The goal is to stop valid-session creation before the attacker can reuse it for fraud or data access.

Technical breakdown

How credential stuffing works across login endpoints

Credential stuffing uses lists of breached credentials rather than guessed passwords. Attackers distribute those lists through tooling and proxy networks so each source IP stays below common rate limits. The payload is usually a normal-looking login request, which means single-request inspection often misses the abuse. The important signal is aggregate behaviour across many accounts, short time windows, and repeated failure patterns that a web gateway cannot reliably reconstruct on its own.

Practical implication: teams need cross-account authentication telemetry, not just per-request filtering, to distinguish stuffing from ordinary login mistakes.

Why the detection signal disappears at the WAF boundary

A WAF sees an isolated HTTP request, while stuffing detection depends on correlation across sessions, identities, and source behaviour. That is why rules built from a downstream alert are usually approximate. They either block too broadly and hurt legitimate users or stay too narrow and are bypassed quickly. The governance problem is not alert quality. It is the loss of context when detection and enforcement live in different control planes.

Practical implication: enforcement must consume the same behavioural evidence that generated the alert, or the control will remain reactive.

Shadow mode and request-path enforcement for identity abuse

Shadow mode lets teams evaluate credential stuffing decisions against live traffic before blocking anything. That matters because it exposes whether the policy can use the evidence chain that matters, such as account velocity, direct POST login attempts, and post-authentication behaviour. Once the policy is trusted, deployment through version control and CI/CD makes the response auditable and reversible. For identity programmes, this is a governance pattern, not just a tuning exercise.

Practical implication: stage stuffing controls in shadow mode, then promote only policies that can be enforced where authentication is actually decided.

Threat narrative

Attacker objective: The attacker aims to turn reused credentials into valid sessions that can be monetised through account takeover or follow-on abuse.

1. Entry begins with breached credential lists sourced from public dumps or criminal marketplaces and tested at scale against login endpoints.
2. Escalation occurs when valid credentials produce working sessions, allowing the attacker to bypass the original compromise boundary.
3. Impact follows when the attacker uses the authenticated session for account takeover, fraud, or downstream data access.

NHI Mgmt Group analysis

Detection without enforcement is a governance failure, not a tooling gap. Credential stuffing is often recognised correctly but contained poorly because the evidence is trapped in one control and the block decision is made in another. That split weakens identity governance, especially when the behaviour spans many accounts rather than a single bad login. The practical conclusion is that authentication controls need a shared decision path, not just better alerting.

Cross-account credential velocity is the named concept teams should watch. This is the aggregate pattern that exposes stuffing, yet it is invisible to request-by-request controls. Once security teams treat velocity across identities as a first-class signal, they can design policies that respond to abuse patterns instead of individual failures. That approach aligns with OWASP Non-Human Identity Top 10 concerns around secret exposure and authentication abuse when automated clients and service accounts share the same access surfaces.

WAF-centric blocking is too coarse for identity abuse at scale. A WAF can rate limit and filter headers, but it cannot reliably reason about prior navigation, session history, or correlated failures across hundreds of accounts. That limitation matters for IAM teams because the abuse happens at the identity layer even when the traffic lands at the web layer. Practitioners should treat web filtering as one signal source, not the enforcement system of record.

Policy needs to move into the request path if organisations want controllable response. The article’s core lesson is that the system which understands the attack must also be the system that decides enforcement. That is the same architectural principle that underpins stronger authentication governance in NIST SP 800-63 and adjacent access control thinking in NIST SP 800-53. For practitioners, the question is whether identity signals can actually drive action before a valid session is established.

What this signals

Credential velocity is becoming a governance signal, not just a fraud signal. Teams that still treat repeated login failures as a generic web issue miss the identity pattern that actually defines stuffing. The operational shift is to treat cross-account login correlation as a control input, then map it to enforcement in the same path that makes the access decision.

Standing access assumptions fail quickly when stolen credentials are replayed at machine speed. That matters for IAM and for any NHI programme that still relies on long-lived secrets or reused auth material. The broader signal is that authentication design now needs to be assessed alongside request-path controls and identity lifecycle discipline, not separately.

The practical next step is to connect login telemetry to identity governance reporting so teams can explain not just that stuffing happened, but why it was or was not blocked. For readers extending controls into automated clients and service accounts, the same logic applies to 52 NHI Breaches Analysis and the OWASP Non-Human Identity Top 10.

For practitioners

• Instrument cross-account login correlation Track failed logins, session history, and source rotation across identities so stuffing patterns are visible at the aggregate level, not just per request.
• Move stuffing decisions into the enforcement path Ensure the control that detects abnormal login velocity can also block or step up authentication in the same request flow, rather than relying on a separate WAF rule.
• Use shadow mode before blocking Run the policy against live traffic in shadow mode, log the full evidence chain, and only promote rules that match expected behaviour without creating widespread false positives.
• Review post-authentication abuse signals Check whether successful logins immediately change recovery settings, access PII, or extract payment methods, because stuffing campaigns often continue after authentication succeeds.

Key takeaways

• Credential stuffing succeeds when identity signals are visible but enforcement is fragmented across tools.
• The most useful defence signal is cross-account credential velocity, not single-request inspection.
• Teams should move login abuse policy into the same path that evaluates authentication, then validate it in shadow mode.

Key terms

• Credential Stuffing: Credential stuffing is an attack that uses stolen username and password pairs from previous breaches to try logging into other services. It works because many people reuse credentials, and because the login attempt uses valid information, it can look ordinary until the surrounding behavior gives it away.
• Cross-Account Credential Velocity: Cross-account credential velocity is the pattern of repeated login attempts spread across many identities in a short period. It is a behavioural signal that emerges only when authentication events are correlated across accounts, making it useful for spotting coordinated abuse that per-request checks miss.
• Shadow Mode: Shadow mode runs two decision systems in parallel and compares their outputs without enforcing the new system yet. It is used to validate access parity safely, expose edge cases, and reduce the risk of hidden policy differences during migration or control replacement.
• Request-Path Enforcement: Request-path enforcement means the system that understands a security event also makes the blocking or step-up decision at runtime. In practice, this keeps detection context and action together, which is critical when abuse depends on correlation across sessions, identities, or behaviours.

What's in the full article

Impart's full blog post covers the operational detail this post intentionally leaves for the source:

• How the bot tooling, proxy rotation, and request patterns are assembled in a real stuffing campaign
• Examples of the login signals that distinguish a valid failed login from coordinated credential abuse
• The difference between alerting on stuffing and actually enforcing against it in the request path
• Shadow-mode workflow details for testing blocking logic before it affects production users

👉 Impart Security's full post covers the attack flow, detection signals, and request-path enforcement approach.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management for practitioners building stronger access control programmes. It gives identity and security teams a common language for reducing credential abuse across human and non-human systems.