Many believe multifactor authentication (MFA) could have prevented the 23andMe breach that exposed 6.9 million customers' data and resulted in an $18 million settlement with 42 state attorneys general. Security consultants and compliance frameworks often promote MFA as the ultimate defense against credential-based attacks. The investigation did find that 23andMe "did not require multifactor authentication," among other issues.
But here's the real issue: MFA wasn't the most significant control gap.
The Real Issue
MFA is important. ISO/IEC 27001 Annex A.9.4.2 addresses secure authentication, and the NIST Cybersecurity Framework (CSF) 2.0 includes strong authentication under its Identity and Access Management functions. You should implement it.
However, the 23andMe case highlights a deeper problem: the company couldn't detect the breach. The credential stuffing campaign went unnoticed from April 2023 through September 2023. Five months. This isn't just an authentication issue; it's a visibility issue.
The multistate investigation identified the actual control failures:
- No rate limiting or intrusion prevention
- Insufficient logging and monitoring
- Failure to investigate unusual login patterns
- No comparison of passwords against blocklists of known breached credentials
What's missing? A technical barrier at the authentication layer. These are detective and preventive controls that operate before, during, and after authentication attempts.
Understanding the Attack
Credential stuffing works when attackers test thousands of username-password pairs from other breaches. They're not bypassing authentication; they're using valid credentials at scale.
MFA would have blocked successful logins after credential validation. But here's what it wouldn't have done:
You wouldn't have known the attack was happening. Your logs would show failed MFA challenges, but without rate limiting, attackers could continue testing credentials indefinitely. Without monitoring for unusual patterns, you wouldn't trigger an incident response. Without comparing passwords against breach databases, you wouldn't identify which of your users had already been compromised elsewhere.
23andMe's failure wasn't just that attackers got in. It was that the company had no idea they were trying. For five months, someone was systematically testing credentials against their platform, and nobody noticed.
That's the control gap that matters. NIST SP 800-53 addresses this in SI-4 (Information System Monitoring) and AU-6 (Audit Review, Analysis, and Reporting). These controls are essential for detecting active attacks on your authentication layer.
Steps to Take
Start with visibility, not barriers. You need to know what's happening at your authentication boundary before you can defend it.
Implement rate limiting first. Set thresholds for failed login attempts per account, per IP address, and per time window. This basic access control hygiene should trigger alerts when exceeded.
Build monitoring that looks for credential stuffing patterns: distributed login attempts across many accounts, geographic anomalies, velocity checks, and user-agent analysis. Your SIEM should correlate these signals. If you're seeing 10,000 login attempts from 50 different IP addresses in an hour, that's not normal user behavior.
Compare user passwords against known breach databases during account creation and password changes. Services like Have I Been Pwned provide APIs for this. When a user tries to set a password that's already been compromised elsewhere, reject it. This addresses the root cause: credential reuse.
Log everything at the authentication layer. Not just successful logins, but failed attempts, MFA challenges, password changes, and account recovery requests. NIST SP 800-53 AU-2 requires organizations to determine which events need logging. Authentication events should be at the top of that list.
Then add MFA. But don't stop there. Monitor MFA bypass attempts, track which users haven't enrolled, and watch for patterns like repeated MFA denials followed by password reset requests.
The investigation found 23andMe also failed to "fix known vulnerabilities and properly review and test design features of its platform." That's your vulnerability management program. You can't patch what you don't track, and you can't test what you don't document. ISO/IEC 27001 Annex A.12.6.1 covers technical vulnerability management. Build a process that identifies, assesses, and remediates vulnerabilities within defined timeframes.
When MFA Is Essential
MFA does prevent certain attack paths. If an attacker has a valid username and password but can't pass the second factor, they don't get in. That matters.
For high-value accounts (administrators, anyone with access to sensitive data, anyone who can modify system configurations), MFA isn't optional. The NYDFS Cybersecurity Regulation requires MFA for privileged accounts. The NIST Cybersecurity Framework (CSF) 2.0 emphasizes strong authentication as a core identity management function. SOC 2 auditors will ask about it during your Type II examination.
MFA also reduces your blast radius when credentials do leak. If every account requires a second factor, a credential dump from another breach becomes far less useful to attackers.
But here's the distinction: MFA is a preventive control at the authentication layer. It works after an attacker has already obtained valid credentials and is attempting to use them. The controls 23andMe lacked were detective controls that would have identified the attack while it was happening and preventive controls that would have stopped it before credentials were even tested.
You need both. The conventional wisdom isn't wrong about MFA. It's incomplete. If you implement MFA but can't detect a credential stuffing campaign running against your platform for five months, you haven't solved the problem 23andMe faced. You've just made attackers work slightly harder while remaining blind to their attempts.
The $18 million settlement, combined with previous penalties from Spain and the United Kingdom, reflects this reality. Regulators aren't just punishing the absence of MFA. They're punishing the absence of basic security monitoring and response capabilities that should have detected the attack long before 6.9 million customer records were compromised.
