Credential stuffing exposes the gap between detection and enforcement

At a glance

What this is: This is an analysis of credential stuffing as an identity attack pattern, showing that detection can be accurate while enforcement still fails when it sits outside the request path.

Why it matters: It matters to IAM and security teams because login protection only works when account-level signals, session context, and blocking decisions are connected before a valid session is established.

Context

Credential stuffing is a login abuse pattern, not a password guessing problem in the classic sense. Attackers use real username and password pairs stolen from breaches, then automate large-scale testing until they find reused credentials that still work. The governance problem is that many control stacks detect suspicious authentication behaviour in one place but attempt to block it in another.

For IAM practitioners, the important distinction is between seeing the attack and stopping the attack. Detection tools can identify velocity across accounts, proxy rotation, and session anomalies, but enforcement often sits in a WAF or adjacent control that only evaluates individual requests. That mismatch is where identity signals lose value and reused credentials turn into live sessions.

Key questions

Q: What breaks when credential stuffing detection is separated from enforcement?

A: The control loses the identity context needed to block the attack reliably. Detection can identify credential velocity, proxy rotation, and account-level abuse, but a separate enforcement layer often only sees isolated requests. That split produces broad WAF rules, false positives, and delayed containment, so stolen credentials still become valid sessions.

Q: Why do reused credentials still create account takeover risk even when bots are detected?

A: Because detection alone does not stop authentication from succeeding. If the attacker reaches the login endpoint with valid credentials before enforcement acts, the result is a legitimate session, not a suspicious event. The account then becomes available for data access, recovery changes, or other downstream abuse.

Q: How do organisations know whether credential stuffing controls are working?

A: Look for fewer reused secrets in code and configuration, lower volumes of anomalous login attempts, faster secret rotation after exposure, and clear ownership for every service credential. A healthy programme can revoke a compromised credential quickly and see the change reflected across pipelines, APIs, and monitoring.

Q: Should organisations rely on WAF rules or identity-aware controls for login abuse?

A: Identity-aware controls should carry the blocking decision because they can evaluate account history, session state, and behavioural patterns that a WAF cannot see. A WAF can still help with coarse suppression, but it should not be the primary enforcement point for credential stuffing.

Technical breakdown

How credential stuffing succeeds at the login layer

Credential stuffing works because the attacker does not need to break authentication, only to reuse it. A campaign begins with breached credential lists, then distributes login attempts through proxies so each source looks low volume. Each request can be syntactically valid, with realistic headers and a correct content type, which makes single-request inspection weak. The useful signal emerges only when multiple failed logins, IP rotation, and account-level velocity are correlated over time. That means the attack is fundamentally cross-request and cross-account, not a one-off malformed login attempt.

Practical implication: teams need enforcement that can evaluate login behaviour across accounts and sessions, not just filter individual requests.

Why WAF enforcement misses identity context

A WAF is designed to evaluate traffic at the edge or request layer, so it usually lacks the session history and account correlation needed to understand credential stuffing. It can rate limit, geo-block, or filter by header, but those controls are rough approximations of the real detection signal. That creates a structural gap: the bot detection layer sees credential velocity across many accounts, while the WAF sees only separate requests. When those layers are split, the organisation turns a high-confidence alert into an imprecise rule.

Practical implication: map the enforcement point to the same layer that sees authentication context, or the rule will remain an approximation.

Why request-path decisions change the control model

When detection and enforcement share the same request path, the control can use the same signals it detects, including navigation history, account velocity, and post-authentication behaviour. That changes the unit of decision from a network request to an identity event. In practice, this is the difference between translating an alert into a static rule and making a real-time blocking decision with full evidence. Shadow mode then becomes the validation step, because teams can see exactly what would be blocked before they turn enforcement on.

Practical implication: validate login policies in shadow mode, then promote only when the evidence chain matches the intended blocking decision.

Threat narrative

Attacker objective: The attacker wants to turn stolen credentials into working sessions at scale, then abuse those authenticated accounts before enforcement catches up.

1. Entry begins with breached credential lists assembled from prior incidents, public dumps, or criminal marketplaces and loaded into an automated stuffing tool.
2. Credential access succeeds when repeated login attempts hit reused passwords and produce a valid session instead of a failed authentication event.
3. Impact follows when the attacker uses the authenticated session to access the account and continue downstream abuse before the organisation can translate detection into blocking.

Breaches seen in the wild

• 23andMe credential stuffing 2023: Credential stuffing into 18,000 accounts exposed nearly 7 million people through the DNA Relatives feature.

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

Detection without enforcement is a governance failure, not a tooling gap. Credential stuffing shows that teams can identify suspicious authentication behaviour and still fail to stop it if the block decision lives outside the layer that understands account and session context. That is why the real control issue is not whether the alert is accurate, but whether the enforcement path can consume the same evidence. Practitioners should treat this as an identity-control design problem, not a tuning problem.

Cross-request correlation is the named concept here: the attack only becomes visible when many individually normal requests are evaluated together. Credential stuffing is not meaningfully governed by per-request inspection because the attacker deliberately keeps each attempt looking ordinary. The control boundary therefore has to move from isolated transaction review to aggregated identity and session analysis. Practitioners should design login protections around correlated identity signals, not edge heuristics.

WAF-centric blocking creates a false sense of control over account abuse. A WAF can still be useful for rate shaping and coarse suppression, but it cannot replace an enforcement layer that understands authentication state, login history, and post-authentication behaviour. The more an organisation relies on translation from alert to rule, the more it delays containment. Practitioners should align blocking with the same runtime context that produces the detection.

Credential stuffing is an IAM issue because valid credentials are the attacker's access path. This is not just bot management or web abuse. Once reused credentials produce a valid session, the attacker is operating inside the identity plane and the remaining risk is privilege use, account recovery abuse, and downstream data access. Practitioners should treat reused-password abuse as part of identity governance, not only web security.

Shadow mode is the right validation pattern when enforcement logic is tightly coupled to user traffic. The article's operational model is clear: observe decisions, log evidence, then promote to active blocking once the policy behaves as intended. That sequencing reduces the risk of false positives while preserving the ability to stop account abuse in real time. Practitioners should insist on evidence-rich policy promotion before turning login enforcement on.

What this signals

Cross-request correlation is now a baseline requirement for login defence. Credential stuffing campaigns are designed to look harmless per request, which makes request-only enforcement structurally weak. Practitioners should expect the decisive signal to emerge from account velocity, session history, and post-authentication behaviour rather than from a single malformed login.

Detection and enforcement must converge at the point of authentication. The article's core lesson is that a high-confidence bot alert is not the same thing as a blocking decision. For IAM teams, that means login control design should prioritise runtime context and policy execution where the identity event occurs, not after the fact.

For practitioners

• Align detection and blocking in the same runtime layer Move credential stuffing decisions into the application request path so the system that sees the login context can also block the attempt without a tool handoff.
• Correlate login attempts across accounts and sessions Use aggregate signals such as credential velocity, IP rotation, and session history to identify campaigns that look normal one request at a time.
• Run login policies in shadow mode first Evaluate every decision against live traffic, log the evidence chain, and only promote to enforcement after the policy matches expected outcomes.
• Limit WAF rules to coarse suppression Use the WAF for rate shaping and broad containment, but do not rely on it for identity-aware blocking decisions that require cross-account correlation.

Key takeaways

• Credential stuffing succeeds when stolen credentials are tested at scale and reused passwords still open a valid session.
• The main governance weakness is not detection quality but the distance between detection and enforcement.
• Blocking has to happen in a context that understands authentication state, or the attack will keep outrunning the rule.

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-Request Correlation: Cross-request correlation is the ability to evaluate many individual requests together so a pattern becomes visible that no single request reveals. In credential stuffing, that means linking account velocity, IP rotation, and session behaviour to distinguish campaign activity from normal user mistakes.
• 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.
• 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.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security practitioners connect identity controls to runtime enforcement across the broader programme.