19 Billion Passwords Are Circulating. The Number Isn't the Story

When the "19 billion compromised passwords" story hit, my inbox lit up with the same question from a dozen founders.

"Should we be panicking?"

The honest answer: panic at the number is the wrong panic. The number is theater. What sits underneath the number is the actual story, and it is harder to fix than rotating credentials.

Here is what I told them.

The 19 billion figure is mostly recycled

When researchers report a "compilation," the headline counts every line in every file across every breach they have indexed. That math is impressive in a screenshot and almost useless operationally. Once you de-duplicate, single-digit percentages of that dataset are unique credentials. The rest is the same passwords from the same accounts surfacing in compilation after compilation, the same way the same songs end up on every "greatest hits" album.

The serious analysis behind these stories repeatedly lands in the same place: a large share of the data comes from infostealer logs, not from a fresh breach of any one provider. Infostealers harvest whatever sits in browser-saved credentials on infected machines. So "19 billion" is really "credentials that escaped, over the years, from people who clicked the wrong installer."

If you treat this as a fresh-breach event and run a forced password reset, you have done something that feels like action and changes very little. The credentials that hurt you were already out in the open. Many were out years ago.

What it actually proves

Strip away the count and the lesson is uncomfortable.

The password as an authentication primitive is finished. We have spent two decades trying to patch around it. Complexity rules. Rotation policies. Password managers. KBA. Then we layered MFA on top because the primitive itself could not carry the load.

Every layer added cost. Every layer leaked. SMS OTP got SIM-swapped. Security questions got socially engineered. Even TOTP, the better second factor, gets phished in real time by attacker-in-the-middle kits that proxy your login session.

The 19B headline is a marker of how thoroughly the primitive has failed. We are not arguing about whether passwords are insecure anymore. We are arguing about how fast organizations can move off them.

The infostealer reality your stack has to assume

Treat any password your users have typed into any site, ever, as compromised. Not someday. Now. The 19B compilation is one of several published in the last 18 months. None of them will be the last.

That assumption changes the design of your stack in three ways.

First, the password is no longer a security control. It is a deprecated legacy input you are tolerating during a migration. Plan the migration explicitly. Set a target date. Communicate it.

Second, the second factor has to be phishing-resistant. SMS OTP fails this bar. Push notifications without number matching fail this bar. Passkeys pass. FIDO2 security keys pass. Anything cryptographically bound to the origin passes.

Third, detection has to assume credentials are valid before the session starts. Behavior, device posture, geo-velocity, impossible travel: these are not nice-to-haves once you accept that the credential is no longer evidence of identity. They are the perimeter.

The checklist I would hand a CISO this week

If you are running a credential-based stack right now, this is the order I would work it.

1. Identify your top three accounts to protect by blast radius: admin accounts, support tooling, anything with destructive permissions on customer data. Move these to phishing-resistant MFA in the next 30 days. No exceptions, no breakglass that bypasses the policy without alerting.
2. Run a credential-monitoring sweep against published breach corpora. You almost certainly have users whose current password is in one. Force a reset on hit, but reset to passkey, not to another password.
3. Kill SMS OTP wherever it is still a "second factor." NIST quietly stopped treating it as AAL2-grade years ago. Most of your stack is overdue.
4. Add login-time signals: device, IP reputation, behavioral baseline, impossible travel. If you cannot deploy these in-house, your CIAM vendor almost certainly offers them and you are not using them.
5. Start the passwordless migration. The right way to start is not "remove the password." It is "let users add a passkey, prefer passkey on login, then later make passkey mandatory for new accounts." The path is incremental, not big-bang.
6. Pick a sunset date for password-only login for new accounts. Twelve months out is aggressive but defensible. Eighteen months is realistic. Put it on a roadmap slide and brief the board.

The thing you do not have to do

You do not have to do an emergency forced reset for everyone. That is the panic response, and it generates support volume without buying you much. Users who reset to "Password1!" become "Password2!" and the credential is still in the next compilation.

What you have to do is treat the password itself as the bug. Every project that ends with a stronger password is treating the symptom. Every project that ends with a key pair on a phone, bound to your origin, is treating the cause.

That is what I would actually tell a CISO this week. The 19 billion headline is a useful forcing function. It is a terrible diagnosis.

What is your next move?

If you are early in the passwordless conversation internally, the passwordless authentication guide lays out the migration path. If you are mid-breach response and trying to size the credential-stuffing exposure, the credential stuffing and ATO breakdown covers what the attackers actually do with this data once it leaks.

FAQ

Are there really 19 billion unique compromised passwords?

No. The 19B figure counts every entry across every breach in a compilation. Once you deduplicate by unique credential, the truly unique entry rate is in the single-digit percentages. Most of the data is recycled from previously known breaches and infostealer logs.

Should I force a password reset for all users?

Not as the primary response. Forced resets generate support volume without addressing the underlying issue: the password itself is the weak primitive. Use credential monitoring to target users with known-compromised passwords, and pair every reset with a passkey enrollment prompt.

Is SMS OTP still good enough as a second factor?

No. SMS OTP is vulnerable to SIM swapping and is no longer treated as AAL2-grade authentication under NIST SP 800-63B revisions. Phishing-resistant options like passkeys, FIDO2 keys, or push with number matching are the current baseline.

What is the fastest path to phishing-resistant authentication?

Start by enabling passkeys for new sign-ins, prefer passkey login when available, and require passkeys for high-risk operations. For admin and high-blast-radius accounts, deploy FIDO2 hardware keys within 30 days. Build toward a sunset date for password-only login on new accounts.

How is this breach different from past compilations?

Operationally, it is not. It is larger, more publicized, and triggered more news cycles. The underlying mechanics (infostealers harvesting browser-saved credentials, prior breach data being repackaged) are the same. The lesson is the same too: the password is the bug.

About the author

Deepak Gupta is a serial entrepreneur and cybersecurity researcher, who founded and scaled a CIAM platform to 1B+ users. He writes about AI, cybersecurity, and B2B growth at guptadeepak.com.