The Truth Behind the “16 Billion Passwords” Headline

The claim that 16 billion passwords had been exposed sounded like a single, unprecedented breach of Apple, Google, Facebook and almost every other major online service. That was not what the evidence showed.

By Navid Sobbi, Founder and CEO, NSI Global

PUBLISHED: 5 August 2025  SUBSTANTIVELY REVISED: 9 September 2026

The Number Described Records, Not 16 Billion Victims

Cybernews reported that its researchers had identified 30 exposed datasets containing approximately 16 billion credential records in total. The records were spread across separate collections, and the researchers acknowledged that duplication existed and that the number of unique accounts could not be determined.

That distinction changes the meaning of the story.

A single person can generate several records because the same email address may appear against multiple websites. The same record may be copied into different collections or repeated within one collection. Old credentials can also be repackaged alongside newer infostealer logs. Adding every row together therefore produces a large number without establishing how many people, accounts or current passwords are actually represented.

The most useful interpretation is not “16 billion passwords were newly stolen”. It is that very large stores of credential data continue to be collected, copied and left exposed.

Apple, Google and Facebook Were Not Shown to Have Been Breached

The presence of an Apple, Google or Facebook login URL in an infostealer record does not show that the provider’s infrastructure was compromised.

Infostealer malware commonly operates on the user’s device. If an infected user signs into an online service, the malware may capture the login URL and credentials associated with that session. The resulting record identifies the service the victim accessed; it does not identify the service as the origin of the theft.

Bob Diachenko, who contributed to the Cybernews research, subsequently clarified that there had been no centralised breach of Apple, Google or Facebook in connection with the reported datasets. Credentials for accounts on those services may still have been present, but that is a different proposition.

For executives and incident-response teams, the distinction is important:

1. A service-provider breach directs attention to the provider’s environment, notification and remediation;
2. An infostealer exposure directs attention to the endpoint, identity, active sessions and other credentials used from the affected device; and
3. A repackaged credential list may reflect an older incident but still present a risk wherever passwords have been reused or remain active.

Misclassifying the event can send an organisation towards the wrong containment action.

Later Analysis Showed How Far Headline Counts Can Exceed Unique Exposure

Have I Been Pwned founder Troy Hunt later analysed 2.7 billion rows supplied from part of the reported corpus. He extracted approximately 325 million valid website-email-password combinations and 109 million unique email addresses.

That is not an analysis of all 16 billion reported rows, so it cannot produce a definitive deduplicated total for the entire story. It does demonstrate why raw row counts should not be treated as a count of distinct victims.

Hunt also reported that 96 per cent of the unique email addresses and 96 per cent of the unique passwords in the material he analysed were already represented in Have I Been Pwned. His assessment was that much of the data had circulated previously, although the material still included 4.4 million email addresses not previously held in the service.

This evidence qualifies two competing narratives. The story was neither a new breach of every major platform nor a harmless collection of wholly irrelevant old data. It was a large, duplicated credential corpus in which some material was already known and some was not.

A 24 Billion Record Exposure Reinforced the Same Lesson in 2026

The number became larger the following year, but the analytical problem remained the same.

In June 2026, Cybernews reported a separate exposed Elasticsearch environment containing approximately 24 billion records. Researchers said most appeared to be infostealer logs and aggregated collections, but they could not determine how many records were duplicates or how many unique people were represented. Cybernews later reported that the environment belonged to a threat-intelligence and breach-monitoring platform and had been exposed during a temporary migration.

The progression from 16 billion to 24 billion does not mean that eight billion additional people were compromised. It shows why record counts taken from aggregated credential stores are a poor measure of human impact.

The better questions are:

1. Are the credentials current?
2. Which organisations and domains are represented?
3. Did the data originate from an infected endpoint, a breached service or a recycled collection?
4. Are session cookies, authentication tokens or other artefacts present?
5. Has the affected identity been used successfully since the suspected exposure?

Those questions support action. The headline count does not.

Why an Infostealer Exposure Requires More Than a Password Reset

An infostealer is malware designed to collect information from an infected device. Depending on the malware and access available, the captured material may extend beyond usernames and passwords to browser-stored credentials, cookies, session tokens, cryptocurrency information, application data and system details.

This creates a specific containment problem. Changing a password from an infected device may simply expose the replacement. An attacker holding an active session token may also retain access until sessions are revoked, even after a password has changed. If the same credentials were reused, the risk extends to other accounts that never appeared in the original record.

A corporate credential found in a stealer log should therefore be treated as an indicator requiring investigation, not as proof that every associated account has been accessed.

The organisation may need to determine:

1. Which endpoint the credential came from and whether it remains compromised;
2. Whether the password was reused across corporate or personal services;
3. Whether active sessions, refresh tokens and remembered devices have been revoked;
4. Whether mailbox rules, OAuth grants or recovery details were altered;
5. Whether authentication logs show successful access, unusual locations or impossible travel;
6. Whether privileged, financial or customer systems were reachable through the identity; and
7. Whether evidence must be preserved for legal, regulatory, insurance or employment purposes.

Where suspicious access is identified, NSI Global’s ransomware and business email compromise incident-response capability can support forensic scoping, evidence preservation and reconstruction of attacker activity.

What Organisations Should Do When Corporate Credentials Appear in a Leak

1. Validate the Exposure Without Spreading It

Use established breach-notification or threat-intelligence sources and follow internal handling procedures. Do not paste a live corporate password into an unknown “breach checker” or circulate stolen records through email and collaboration platforms.

A result from Have I Been Pwned can indicate that an email address or password appears in data held by the service. A negative result does not prove that the credential or device is clean; no public service contains every stolen dataset.

2. Preserve Evidence Before Destructive Remediation

If the exposure may involve fraud, data theft, employee activity, regulatory notification or litigation, coordinate legal, IT and forensic decisions before wiping or rebuilding the suspected endpoint. Immediate containment can still be necessary, but it should be performed in a way that does not unnecessarily destroy the evidence needed to determine what occurred.

Digital forensic incident response may be required where the organisation needs to identify the affected device, determine persistence, reconstruct access or establish whether data was exfiltrated.

3. Contain the Identity, Not Only the Password

From a trusted device, reset exposed or reused credentials, revoke active sessions and tokens, review remembered devices and examine changes to recovery methods, mailbox forwarding and application permissions. Privileged and financial identities should receive immediate priority.

4. Find the Source

Determine whether the exposure came from malware on an endpoint, password reuse after an unrelated breach, phishing, a compromised third party or another source. Without that step, the replacement credential may be exposed again and the original intrusion pathway may remain open.

5. Strengthen Authentication Around Consequence

The Australian Signals Directorate recommends multi-factor authentication and recognises that phishing-resistant methods using public-key cryptography provide stronger protection than weaker implementations such as SMS or voice codes. Passkeys and FIDO2 security keys should be prioritised for administrators, executives, finance teams and other high-consequence accounts where supported.

MFA does not make a compromised endpoint harmless. It materially reduces risk, but stolen sessions, social engineering and weak recovery pathways can still undermine an account.

6. Use Unique Credentials and Govern the Password Manager

A password manager can generate and store a different credential for each service, limiting the value of one leaked password elsewhere. The manager itself should be protected with a strong, unique master passphrase, MFA and trusted-device controls.

The response priority is to change credentials known or reasonably suspected to be exposed and eliminate reuse. Routine calendar-based password changes should not substitute for monitoring, strong authentication and incident-driven resets.

What Individuals Should Do

Individuals do not need to change every password because a large number appeared in a headline. They should act where there is evidence of exposure or reuse:

1. Check established breach-notification services for the email addresses you use.
2. If a credential may have been stolen by malware, use a trusted device to secure the affected accounts.
3. Change exposed and reused passwords, starting with primary email, financial and recovery accounts.
4. Sign out other sessions and review recovery addresses, phone numbers and connected applications.
5. Enable a passkey, security key or the strongest available MFA method.
6. Monitor accounts for unexpected login alerts, password resets, forwarding rules and financial activity.
7. If the suspected device behaves unusually or the exposure involves sensitive organisational access, seek specialist advice before erasing it.

The Management Lesson: Measure Exposure, Not Headlines

The 16-billion-record story became widely misunderstood because a technically impressive count was treated as a measure of unique human impact. The later 24-billion-record exposure showed that even larger totals can arise from aggregated, duplicated collections maintained for an entirely different purpose.

Boards and security leaders should resist two equally poor responses: panic because the number is enormous, or complacency because the number is inflated.

The appropriate response is evidence-led. Determine whether your identities are represented, whether the credentials remain usable, whether an endpoint was infected and whether unauthorised access occurred. Then contain the affected identity, investigate the source and strengthen the controls that failed.

NSI Global’s Cyber Posture Consulting service helps organisations assess identity, endpoint, cloud and governance controls against their actual exposure. Where compromise is suspected, incident response and digital forensic investigation provide the evidence needed to distinguish a circulating credential from an active intrusion.

For a confidential discussion about credential exposure, suspected infostealer activity or business email compromise, contact NSI Global.

Frequently Asked Questions

Were 16 Billion Passwords Stolen From Apple, Google and Facebook?

No central breach of those companies was established by the 2025 reporting. The datasets included login records associated with many services, but the available evidence pointed to infostealer logs and aggregated credential collections rather than a coordinated compromise of the named providers.

Were There 16 Billion Unique Passwords or Victims?

No such conclusion could be drawn. The figure represented rows across 30 datasets containing duplication. A person, email address or password could appear several times and against several services.

Should Everyone Change Every Password?

Not solely because of the headline. Change credentials known or reasonably suspected to be exposed, replace every reused instance and secure high-value accounts first. If malware may be involved, make those changes from a trusted device and revoke existing sessions.

Does MFA Prevent Every Account Takeover?

No. Strong MFA significantly reduces risk, particularly when it is phishing-resistant, but it does not remediate an infected endpoint or automatically invalidate stolen session tokens and weak recovery channels.

Can Have I Been Pwned Prove That an Account Is Safe?

No. It can identify data known to the service. An address not appearing in its records may still have been exposed elsewhere, and a listed address does not by itself prove that an account is currently compromised.

Sources and Further Reading

1. Cybernews – 16 Billion Credentials Report and Subsequent Clarifications
2. Troy Hunt – Analysis of the 16 Billion Password Story
3. Cybernews – 24 Billion Record Exposure, June 2026
4. Australian Signals Directorate – Implementing Multi-Factor Authentication
5. Australian Signals Directorate – Passkeys
6. Australian Signals Directorate – Password Managers
7. Have I Been Pwned

General information only: This article provides general cyber security information and does not replace incident-specific technical or legal advice.