Your Login Endpoint Is Being Tested Right Now. Your Rate Limiter Thinks It's Fine.

Here's a thing that happened to a mid-sized SaaS last year:
They had rate limiting. They had CAPTCHA on failed attempts. They had account lockout after 10 failures. Their security posture, by most checklists, was "reasonable."

Over 47 days, 2.3 million credential pairs were tested against their login endpoint.
Zero lockouts triggered. Zero CAPTCHAs served. Zero alerts fired.
The reason isn't a zero-day. It isn't some exotic bypass. It's something so structurally simple that once you see it, you can't unsee it — and you'll look at your own auth implementation differently.

The Velocity Gap
The entire architecture of brute-force and credential stuffing defense is built on one assumption: attacks are fast.
Lock out after N failures. Rate limit per IP. Detect anomalous request volumes. All of it assumes the attacker is in a hurry.
They're not.
The shift happened gradually and then all at once: credential stuffing operations evolved from spray-and-pray to what threat intelligence work now calls low-velocity distributed testing. The attack is spread across:

Thousands of residential proxy IPs (not datacenter ranges your WAF is watching)
Days or weeks, not hours
One or two attempts per IP, never enough to trigger per-IP thresholds
Human-realistic timing patterns, including sleep cycles, to defeat behavioral analysis

The math is simple and brutal: if you test 50,000 credentials at 1 attempt per IP, spread across 72 hours, with normally-distributed timing, you hit the following controls:
Control Status IP rate limiting (per-IP)✅ Never triggered
Account lockout (N failures per account)✅ Never triggered
Velocity-based anomaly detection ✅ Never triggered
CAPTCHA on failed attempts ✅ Never triggered
Your SIEM alert ✅ Never triggered

This isn't a hypothetical. This is operational tradecraft documented across dark web IAB (Initial Access Broker) forums and criminal communities. The tools to do this at scale are commoditized, cheap, and actively sold with "anti-detection" as a primary feature.

What You're Actually Logging
When a low-velocity credential stuffing operation runs against your endpoint, here's what your logs typically show:

A moderate uptick in failed logins, well within normal variance
Diverse IP distribution, mostly residential ranges
Normal User-Agent strings (the tooling rotates these)
No obvious geographic clustering — residential proxies span legitimate geographies
Login attempt timing that doesn't stand out from organic traffic patterns

What you're not seeing without specific instrumentation: the ratio of attempts-per-credential-pair and the relationship between accounts being tested. The attack looks like noise because it was designed to look like noise.

The Credential Ecosystem Problem
Here's the part that doesn't get talked about enough in engineering-focused security content:
The credentials being tested against your endpoint didn't come from nowhere. They came from a data breach marketplace — and those markets are now extraordinarily efficient.
A credential dump from a 2022 breach of a mid-tier e-commerce site gets:

Parsed and deduped
Tested against high-value targets (banking, crypto, SaaS)
Already-validated credentials sold to IABs at premium
Remaining "untested" credentials sold in bulk for a few dollars per thousand pairs
Those bulk credentials used in stuffing operations against your login endpoint

The time from breach to your endpoint being tested is now measured in weeks, not months. And the credentials being tested against you might be from a service your user signed up for 4 years ago that you've never heard of.
Your user reused a password. They have no idea. You have no idea. The attacker has a list.

The Controls That Actually Matter
Stop me if this sounds familiar: your security posture is built around preventing unauthorized logins. But with credential stuffing, the login often succeeds. That's the point. The credentials are real.
So the question shifts from "how do I stop the wrong password" to "how do I detect that a correct password is being used by the wrong person."
That's a fundamentally different problem.
What doesn't work (as a primary control):

Per-IP rate limiting alone
Account lockout on failed attempts (most stuffing succeeds on the first try per account)
Password complexity requirements (the password is correct)
Standard CAPTCHA (it's served on failure, stuffing succeeds)

What actually moves the needle:

1. Credential pair testing detection Look for the population of tested accounts, not individual account behavior. If 800 distinct accounts each receive exactly 1–2 login attempts from distinct IPs within a 24-hour window, that's a signal. None of those individually trigger a threshold. The population does.
2. Impossible travel and device fingerprinting on successful logins A successful login from a credential that has never been seen on this device/browser fingerprint, from an ASN associated with residential proxy providers, is worth flagging for step-up authentication — regardless of whether the password was correct.
3. Password breach detection at login Have I Been Pwned's API (and similar) lets you check whether the credential being used appears in known breach datasets. A correct password that's also in a breach corpus deserves extra scrutiny. This is underused.
4. Invisible MFA friction on anomalous signals Don't lock accounts on first anomaly. Do add friction. A step-up auth challenge that looks organic to a legitimate user is nearly impossible for an automated stuffing operation to complete at scale.
5. Honeypot accounts If you have the infra: seed your user database with accounts that should never see login attempts. Any attempt against them is, by definition, from a list. Treat it as a signal that a credential dump including your domain is in circulation.

The Structural Honest Assessment
Here's the take I'll stand behind: most auth security advice is optimized for a threat model that hasn't been operationally accurate for 3–4 years.
Rate limiting, lockout policies, and CAPTCHA were designed for an era when attackers were using their own IPs and moving fast. The underground adapted. The defense guidance largely didn't.
The "OWASP Top 10" framing, while useful for broad awareness, treats credential stuffing as a volume problem with a volume solution. The 2026 operational reality is that sophisticated stuffing operations deliberately operate below every volume threshold you've set, because they specifically studied where those thresholds are.
You can't fix this with a single control. You fix it by instrumenting for population-level patterns, not individual-account-level events. And by accepting that a successful login is not, by itself, evidence of authorization.

What This Means for Your Next Auth Review
Three concrete questions worth asking about your current implementation:

Do we have any visibility into population-level login attempt patterns, or only per-account and per-IP patterns? If the answer is "per-account and per-IP only," you have a detection gap.
What happens when a credential stuffing operation succeeds? What does the session look like, and what anomaly signals do we check at that point? If the answer is "nothing, a valid login is a valid login," you have a response gap.
Do we have any signal on whether credentials currently in use against our system appear in known breach datasets? If the answer is "no," that's a free improvement available today.

None of this is exotic. All of it is underimplemented.

This post is informed by threat intelligence research covering dark web credential markets, Initial Access Broker operations, and criminal tooling tradecraft — part of the Aether Intel AS-CTI-2026 series. TLP:WHITE.
Have you instrumented for population-level credential stuffing signals?

What's actually worked in your stack? Drop it in the comments.