Credential stuffing breaks the control most teams rely on

Account lockout is the oldest defence in the login playbook, and against guessing attacks it still works. It fails against an attack that reuses passwords leaked somewhere else, and the failure is structural rather than a matter of tuning thresholds.

Technical context

Credential stuffing is catalogued as a sub-technique of brute force in MITRE ATT&CK, under T1110.004. The definition matters because the two attacks leave different telemetry. Brute force sends many passwords at one account. Credential stuffing sends one or a few leaked username and password pairs at many accounts, usually through a botnet or a proxy pool so that source addresses rotate.
Reuse is what makes it work. Where a meaningful share of users carries the same password from a leaked consumer service into a corporate application, the attacker only needs volume. Reported success rates sit near 0.1 percent, which looks negligible until it is applied to a million pairs.

Why lockout does not help

A lockout policy fires when a single account accumulates failures. Stuffing gives each account one attempt, so the counter never reaches the threshold. The control is not weak. It is pointed at a different behaviour.
Two secondary problems follow. A strict lockout threshold is itself a denial-of-service primitive, because an attacker can lock accounts deliberately. Source-based blocking is bypassable, since an attacker who controls a proxy pool can spread attempts across thousands of addresses, and headers such as X-Forwarded-For are trivially spoofed where the application trusts them.
Rate limiting per IP therefore produces a false sense of coverage. Azure AD B2C's smart lockout shows a more useful design: it locks on the combination of request IP and password pattern, begins with a one-minute delay after ten failures, extends the duration in steps, and resets on success. That escalation slows an automated run without permanently locking a real user. It also shows the limit of the approach, because a distributed attack arrives from many IPs by construction.

What to detect instead

MITRE's detection analytics for this technique read like a specification rather than a list. The shared shape is a single source performing many authentication attempts with distinct username and password pairs in a short window, against services such as RDP, SMB, SSH, Kubernetes APIs and cloud identity providers. The analytics for identity platforms extend the pattern to Azure AD, Okta and Duo, where one source IP presents credentials leaked from unrelated domains.
Three signals carry most of the weight in practice.
Distinct-username failure rate per source. A client that fails against forty different accounts is more interesting than one that fails forty times against one account.
Success after repeated failures from the same source. Stuffing works on a small fraction of attempts, so the successful login inside a burst of failures is the real compromise indicator.
Geographic and device inconsistency on success. A user whose session jumps from a familiar device profile to an unfamiliar one, immediately after a burst of failures, deserves forced re-authentication.
None of these are available unless identity logs are retained long enough to compare bursts across days, and unless source attribution survives the proxies. Shared NAT egress points, corporate VPN concentrators and penetration-testing infrastructure all generate the first signal legitimately, which is why the successful-login correlation matters more than the failure count alone.

Mitigations that hold

Multi-factor authentication remains the highest-value control, and ATT&CK lists it as the primary mitigation for the technique. Some automated account takeover toolkits can defeat weaker second factors through real-time phishing proxies, so the second factor should be phishing-resistant wherever the account can reach sensitive systems.
Breached-credential awareness is the second control. Monitoring a public breach notification service for the corporate domain, then forcing a reset on any account found in a dump, converts an external event into an internal workflow. That is the practice HIBP domain alerts exist to support.
Risk-based step-up is the third. Instead of applying MFA uniformly, an organisation can require it, or require re-authentication, when a session shows the burst pattern described above. Escalating lockout is a coarse version of the same idea.
Password policy has a limited role. ATT&CK points at NIST guidance rather than composition rules, and for stuffing the relevant question is uniqueness rather than strength. A long, complex password reused across services is still a valid credential in a dump.

Limitations and defensive implications

Detection here is probabilistic. A proxy pool makes source identity unreliable, MFA fatigue and real-time phishing change the success economics, and a well-run attack may stay under any burst threshold by pacing attempts. The controls raise cost; they do not guarantee outcomes.
The practical sequence is to ensure authentication logs capture failure events with a stable source identifier, to define a burst threshold that separates the same-account case from the many-account case, to correlate successful logins against those bursts, to enable breach monitoring for the owned domain, and to require phishing-resistant MFA on the accounts that matter.
Lockout policy can stay in place, as long as nobody mistakes it for a defence against stuffing.