149 Million Passwords Leaked in January 2026—So Why Are ‘Passkeys’ Still Losing the Security War Inside Your Company?
The “149 million passwords” headline wasn’t a Big Tech breach—it was a cloud-exposed credential cache that shows why passwords still dominate enterprise logins despite passkeys.
Key Points
- 1Reframe the “149M passwords” panic: it was an exposed, aggregated credential cache—not proof Google or Meta suffered a single mega-breach.
- 2Recognize the enterprise risk: consumer credentials fuel credential stuffing, phishing, and reset-chain attacks that quietly turn “personal” leaks into workplace incidents.
- 3Measure passkeys by real coverage: track passkey sign-in share, fix inconsistent UX, and reduce password fallbacks that keep the credential economy profitable.
Late January 2026 produced a familiar kind of tech panic: headlines warning that “149 million passwords” for Gmail, Facebook, Instagram, and other popular services were “exposed online.” For many readers, the implied story was straightforward—another mega-breach at a household-name platform, another reminder that the internet runs on sand.
The real story was both less scandalous and more unsettling. Cybersecurity researcher Jeremiah Fowler, in reporting shared via ExpressVPN research and then widely picked up, found a publicly exposed, cloud-hosted dataset containing roughly 149.4 million unique username/password combinations and about 96GB of credential data (some coverage described it as ~98GB). The dataset appeared to be accessible on the web without password protection or encryption, and reporting suggested it took nearly a month from disclosure to get the hosting suspended.
What makes the episode worth revisiting isn’t just the scale. It’s the mismatch it highlights: the security industry’s confident talk about a “passwordless future,” and the messy enterprise reality where passwords still sit at the center of work life. Passkeys are widely described as the antidote—phishing-resistant, cryptographic, and increasingly supported by major platforms. Yet many companies struggle to turn “we’re rolling out passkeys” into “most logins no longer depend on passwords.”
“The January 2026 dataset wasn’t proof that Google or Meta failed. It was proof that passwords fail quietly—then fail loudly.”
— — TheMurrow Editorial
The January 2026 dataset: exposed credentials, not a single-company breach
That distinction matters because it changes the prevention conversation. A platform breach raises questions about vendor security controls. An exposed cache of already-stolen credentials raises questions about the broader credential supply chain: malware on endpoints, unsafe storage practices, and the shadow economy that treats logins as a commodity.
What the numbers really mean (and why they still matter)
- ~149.4 million unique username/password pairs
- ~96GB of credential data (sometimes reported as ~98GB)
- A hosting environment reportedly accessible without password protection or encryption
- A reported response timeline of nearly a month from disclosure to takedown
Even without a single “breached company,” that’s a large blast radius. Credential caches don’t respect boundaries. The same login reused across services can turn one compromise into five. A password for a personal email account can become a pivot point for social engineering, password resets, and credential stuffing.
The “leaked vs. stolen” framing problem
Those “known unknowns” leave a hard truth: in 2026, the internet’s password problem isn’t limited to breaches. It also includes careless cloud configuration, routine endpoint compromise, and the long afterlife of stolen logins.
“A password doesn’t need to be ‘hacked’ to become dangerous. It only needs to be reused, collected, and left in the open.”
— — TheMurrow Editorial
Why enterprises should care: consumer credentials don’t stay consumer
An exposed trove of logins is particularly useful to attackers who prefer quiet entry. Password reuse enables straightforward credential stuffing. Even when reuse doesn’t work, the presence of real credentials tied to real identities supplies material for targeted phishing: names, email formats, and patterns across services.
The stepping-stone effect
- Personal email accounts tied to password resets
- Social accounts used for professional networking and impersonation
- Old credentials that still work on fringe systems
- Any app with weaker authentication that can be leveraged for access or intel
Even if none of the leaked credentials belong to a company system directly, the dataset can still fuel campaigns that end with an enterprise compromise. That’s the uncomfortable bridge between “consumer leak” and “workplace incident.”
What defenders can measure—and what they often don’t
Passkeys are often presented as the clean solution. The question is why the clean solution keeps arriving late.
Key Insight
What passkeys actually are (and why the definition matters)
Academic work has described passkeys as enabling phishing-resistant sign-in precisely because there is no password to type into a fake page. The cryptographic exchange is tied to the legitimate site’s origin.
Synced vs. device-bound: two passkey models, two risk profiles
- Synced passkeys: available across a user’s devices via a passkey provider
- Device-bound passkeys: cannot leave the issued device; hardware security keys are a common example
That difference shapes enterprise comfort levels. Synced passkeys improve usability and reduce lockout risk across devices. Device-bound passkeys can be easier to reason about in high-assurance environments, because key material doesn’t sync.
The National Institute of Standards and Technology (NIST) has explicitly discussed “syncable authenticators”—often called passkeys—saying they can offer greater security than passwords while allowing use across multiple devices. That’s a notable endorsement from a body that tends to be careful with language.
“Passkeys don’t ‘strengthen’ passwords. They remove them from the equation.”
— — TheMurrow Editorial
Why passkeys feel inevitable—and why inevitability is not a rollout plan
Inside enterprises, though, “better cryptography” competes with a more stubborn reality: identity systems are sprawling, authentication flows vary across apps, and the last 10% of users and systems often consume 90% of the effort.
Adoption isn’t coverage: the enterprise passkey rollout trap
The FIDO Alliance enterprise research (a US/UK snapshot) captures that tension. Many organizations are deploying passkeys, but the same research highlights the need for training and documentation and describes how organizations measure success via metrics such as activation rate and the share of passkey-based authentication. Those metrics imply what most rollouts feel like: a long transition with uneven uptake.
Why some organizations still hesitate
- Complexity
- Costs
- Lack of clarity about implementation
Those aren’t excuses; they’re descriptions of real friction. A passkey rollout touches identity providers, device management, help desks, compliance requirements, and application owners. It also collides with legacy software that assumes a password field exists because it always has.
The human layer: training is not optional
Training also prevents the most dangerous failure mode: partial adoption that creates false confidence. A passkey pilot that covers only a subset of applications can leave password-based paths alive and well—exactly the pathways credential caches exploit.
Editor’s Note
The hidden adoption killer: inconsistent implementations and confusing UX
Academic research on passkeys “in the wild” highlights heterogeneous implementations across websites. Some services present a clear “Sign in with passkey” button. Others bury the option behind multi-step flows, use conditional mediation that’s hard for users to interpret, or implement passkeys in ways that make discovery inconsistent. Modern JS-heavy sites add further complexity.
A USENIX Security 2026 preprint analyzing real-world adoption adds another uncomfortable point: even how adoption is measured can vary. Differences in data sources and directory integration can distort “adoption rate” narratives. Vendor dashboards may show enrollment, while app logs show something else. The story a CIO hears can diverge from what users experience.
Real-world example: one enterprise, many login rituals
- A central SSO portal supports modern authentication.
- Several critical SaaS apps support passkeys in theory but present different enrollment and sign-in flows.
- A few older internal apps still require passwords because they can’t speak modern standards.
- Contractors and partners authenticate differently, often with less support and more exceptions.
Under that pattern, passkeys become “available” without becoming “default.” Users bounce between experiences and fall back to the one universal tool they know: the password.
Why inconsistent UX becomes a security problem
“For now” is how passwords survive every attempted replacement.
Key Takeaway
The platform layer in 2026: momentum and mess, at the same time
The January 2026 credential exposure illustrates why momentum matters: as long as passwords remain common, attackers can keep assembling, trading, and exploiting credential collections. Passkeys reduce the value of those collections—but only for the accounts that truly move off passwords.
A practical way to think about “passwordless”
The gap between those two meanings causes confusion in boardrooms and budget meetings. A company can spend heavily on “passwordless” initiatives and still have a password sitting behind the scenes—ready to be stuffed from the next exposed dataset.
The sober view: passkeys are a migration, not a switch
That doesn’t make passkeys a failure. It makes them infrastructure. Infrastructure changes slowly until it suddenly becomes normal—often after years of uneven groundwork.
What to do now: practical takeaways for individuals and organizations
For individuals: reduce the value of your own credentials
Individual actions to take now
- ✓Change passwords on accounts that reuse credentials, especially for primary email accounts.
- ✓Use a password manager to generate unique passwords where passkeys aren’t available.
- ✓Enable multi-factor authentication where possible—prefer methods designed to resist phishing when available.
- ✓Treat your email account as critical infrastructure; it is the reset key to everything else.
For organizations: aim for coverage, not announcements
Enterprise actions to prioritize
- ✓Measure share of passkey-based authentication, not just enrollment.
- ✓Identify the top applications by risk and usage; make passkeys the default there first.
- ✓Invest in training and documentation—explicitly called out as necessary in FIDO’s enterprise research.
- ✓Reduce UX fragmentation: consistent sign-in prompts, clear user flows, and predictable recovery paths.
- ✓Plan for exceptions without letting exceptions become the norm.
The goal isn’t to “win” an adoption statistic. The goal is to make the next credential cache less valuable.
Conclusion: the password problem keeps finding new containers
Passkeys address the underlying weakness with better primitives: public-key cryptography, phishing resistance, fewer shared secrets floating around. NIST’s discussion of syncable authenticators and the FIDO Alliance’s work on enterprise deployment reflect a genuine shift from theory to practice.
Yet enterprise reality keeps intruding: uneven coverage, complex environments, and inconsistent user experiences. Adoption is happening, but not uniformly—and attackers only need the weakest path.
The clearest takeaway is also the least comforting: the password era won’t end because passkeys exist. It will end when passkeys become the default across the systems people actually use, with fewer fallbacks and fewer “just this once” exceptions. Until then, credential caches will continue to be found—sometimes by researchers, sometimes by criminals, and sometimes by whoever stumbles across an open cloud container first.
Frequently Asked Questions
Was Google, Facebook, or Instagram breached in the January 2026 “149 million passwords” incident?
Reporting indicated the dataset was not evidence of a single-company breach. Coverage described it as an aggregated cache of credentials likely collected elsewhere and then exposed publicly via an unsecured cloud-hosted dataset. That distinction matters: it points to credential theft and unsafe storage, not necessarily a failure of one major platform’s internal security.
What exactly was exposed, and how big was it?
The dataset reportedly contained about 149.4 million unique username/password combinations and roughly 96GB of credential data (some reports cited ~98GB). It was reportedly accessible online without password protection or encryption, which is why researchers and journalists described it as a major exposure event even though the source of the credentials was unclear.
Were the passwords “leaked” or “stolen”?
The most accurate framing is that credentials were exposed in an online dataset, and many of those credentials were likely previously stolen through other means—often discussed in coverage as associated with infostealer/keylogging malware. “Leaked” is commonly used in headlines, but it can obscure responsibility and the real prevention steps.
What is a passkey, in plain terms?
A passkey is a password replacement based on FIDO2/WebAuthn public-key cryptography. Instead of typing a shared secret, your device proves you control a cryptographic key tied to the legitimate website or app. That design is why passkeys are commonly described as phishing-resistant: there is no password to hand over to a fake login page.
What’s the difference between synced passkeys and device-bound passkeys?
Synced passkeys can be available across a user’s devices through a passkey provider, while device-bound passkeys stay on a specific device (hardware security keys are a common example). The FIDO Alliance treats both under the “passkey” umbrella. Enterprises often weigh usability and recovery advantages of synced models against the tighter control of device-bound options.
If passkeys are better, why aren’t companies fully using them already?
FIDO’s enterprise research notes that organizations cite complexity, costs, and lack of clarity about implementation as barriers. Even among organizations deploying passkeys, success is often tracked by activation rate and share of passkey-based authentication, suggesting a gradual transition. Real-world implementation also varies across apps, creating inconsistent user experiences that slow adoption.
What should organizations measure to know whether passkeys are actually reducing risk?
Enrollment alone is not enough. Track the percentage of real sign-ins using passkeys versus passwords, especially for high-risk and high-volume applications. Also monitor help-desk tickets, recovery events, and which apps still allow password fallbacks. The practical goal is coverage—reducing how often a password can be used as an entry point, even if a credential dataset resurfaces elsewhere.
