Credential stuffing: why a 0.1 percent success rate is a disaster

The arithmetic that makes a tiny rate a catastrophe

A credential stuffing attack is not a guessing game. It is a test of pairs that are already known to be real, harvested from earlier breaches and sold as combo lists. The attacker does not invent passwords. They take a pair that worked on one site and try it on another, because people reuse passwords.

The 2025 Okta Businesses at Work report documented campaigns where attackers authenticated successfully at rates as low as 0.1 percent. That sounds like a failure, until the list size is counted. A 0.1 percent success rate on a 500-million-record combo list yields 500,000 validated accounts. The attacker does not need a high rate. They need a long list, and the lists are long: one leaked database from a mid-tier retail breach in early 2026 contained 4.3 billion username-password pairs.

The reuse is the multiplier. A 2025 SpyCloud report puts password reuse at 65 percent of users. Every pair that worked on the breached site has a two-in-three chance of working somewhere else, and the bot tests the somewhere elses in bulk.

The warning sign arrives before the stuffing does

Akamai's 2026 State of the Internet fraud report shows the pattern that precedes the attack. In a 30-day sample of login traffic, 26.6 percent of all login attempts were rated high or critical risk, and account verification requests made up 40 percent of that risky traffic. The attackers check which email addresses map to real accounts before they launch the stuffing campaign, because a verified list is worth more than an unverified one.

Commerce is the most targeted sector. It recorded 41.1 percent of all high- and critical-risk login attempts, ahead of financial services at 20.8 percent. The reason is the inventory: a commerce account holds a saved payment method, a shipping address, and a purchase history, which is everything a fraudster needs to order goods on someone else's card.

The FBI's 2025 Internet Crime Report puts account takeover losses at $359.7 million. That is the reported number, and it is the number after the victims who never report are excluded.

Why the usual defences fail at this rate

A CAPTCHA on the login page helps, until the attacker solves it at scale, which they do, or buys solved sessions, which they also do. A rate limit keyed to one IP address helps, until the attacker rotates through residential proxies, which they do. A password rule helps nobody, because the passwords in the list already passed the rule on the site they were stolen from.

The defence that works is the one that looks at the login, not the password. A login from a new device, in a new country, at 3 a.m., with a session that has never seen the account before, is a different event from the same login on the account's usual phone. The first gets a challenge. The second does not. The difference is the signal, and the signal is the behaviour, not the credential.

The check that stops the test

Watch the verification requests. A spike in account verification traffic, password resets, and email checks is the attacker's reconnaissance, and it arrives before the stuffing does. A monitoring rule that flags a surge in verification requests per hour is the earliest warning a store gets, and it costs nothing to add.

Enforce a second factor on the accounts that matter, and make it an authenticator app, not SMS. A second factor does not stop the bot from testing the password. It stops the password from being enough.

And when a breach lands, assume the pairs are already in a list. A forced reset on the affected accounts, a check of recent logins from new devices, and a look at the payout details are the first three moves, and they are the ones that have to happen in the first 24 hours, not the first week.

Keep reading: Credential Stuffing After a Breach: What to Do in the First 24 Hours, Residential proxy networks: why the worst bot traffic has a home address, and Why rate limiting alone never stops a distributed bot attack cover the nearby cases in this series.

Frequently asked questions