Stolen Password and Credential Statistics (2026)

How many accounts sit in breach data, how much of it comes from stealer malware and credential-stuffing lists, how often identity attacks are password attacks and what multi-factor authentication and passkeys change.

By Siddharth ShankarUpdated October 12, 202633 statistics · 10 sourcesCite this page

Key takeaways

• The pool of stolen credentials is vast: 17.8 billion breached accounts across 1,043 breaches in Have I Been Pwned (HIBP). One person can appear many times, so this is not a count of people.
• Credential data built for reuse is part of that pool. HIBP lists a 2-billion-record credential-stuffing dataset added in November 2025 and several stealer-log collections of 100 million records or more.
• Passwords are the main target. More than 97% of identity attacks Microsoft sees are password attacks, and identity-based attacks rose 32% in the first half of 2025 (Microsoft).
• MFA changes the odds. Microsoft says MFA can block more than 99% of identity-based attacks.
• Passkeys performed better in one industry index. At nine large companies, passkey sign-ins succeeded 93% of the time against 63% for other methods (FIDO Alliance).

How many credentials are exposed

Have I Been Pwned (HIBP) is a public database of breached account data, and it publishes totals on its site. Its numbers show how much credential data is in circulation. They do not show how many individuals are affected.

The datasets listed are examples of credential-stuffing and stealer-log collections that HIBP shows with their record counts. They are not a ranking of the largest breaches. The list on HIBP’s page includes larger and smaller entries from other years. A “stealer log” comes from malware on a personal device, not from a company’s database; see what a stealer log breach is.

How attackers use stolen passwords

Reused passwords are what turn one breach into many. Credential stuffing, where attackers try leaked email and password pairs on other services, depends on people using the same password in more than one place. Our explainer on credential stuffing shows how that works, and the ICO’s fine on the 23andMe credential-stuffing breach is a UK example.

What people do after a breach

Password managers and passkeys

The index covers nine companies that have run passkeys for one to three years and draws on a Liminal survey. The results show what happens where passkeys are well supported and may not hold for other services. The 73% time reduction is the FIDO Alliance’s figure for passkeys against traditional MFA.

The LastPass case is a reminder that a password manager is also a target. For concrete steps after a breach, see your email was in a data breach: what to do next.

Methodology and limitations

Every figure on this page comes from the organization that published it, such as a regulator, a government agency or the original report. We read the source page or document directly, and we record the period each figure covers. When a number could not be confirmed against a primary source, we left it out. Rows marked “Our calculation” are simple arithmetic on published figures, and the inputs are named in the same row.

• HIBP counts accounts in the breaches it has loaded. It does not hold all breaches, and the same person can appear many times.
• Microsoft’s figures describe the identity attacks it observes, over July 2024 to June 2025.
• The 99% MFA figure is Microsoft’s statement of what MFA can block, not a measured outcome across all accounts.
• The FIDO figures come from nine large companies and a survey, so they are a best case rather than an average.

Counts of reports, complaints and notifications measure what was reported or notified, not everything that happened. Currency symbols follow the source. Where an agency does not name its currency, we show the symbol the source uses (for example, C$ for Canada and A$ for Australia are our labels). Figures from different countries use different definitions and should not be added together. Spot an error? Tell us and include the source link; we correct verified errors and note the date at the top of the page.