When 23andMe reached an $18 million settlement with 42 state attorneys general over a breach affecting 6.9 million people, it highlighted how misunderstood genetic data protection remains. The breach exposed genetic ancestry data months before the company detected it, revealing no credential stuffing protections, inadequate intrusion prevention, and absent logging or monitoring.
These myths persist because genetic data sits at an uncomfortable intersection: it's health information under some frameworks, biometric data under others, and research material in yet another context. Organizations often assume standard IT security practices will suffice or rely too heavily on consent mechanisms while ignoring essential technical controls. The 23andMe settlement makes the cost of these misconceptions clear.
Myth 1: Multi-Factor Authentication Is Optional for Consumer Genetic Services
Reality: Credential-based attacks are the entry point, and MFA is essential.
The 23andMe breach succeeded because the company had "no protections against hacks relying on stolen credentials," according to the New York Attorney General's office. Attackers used credential stuffing to access accounts, then exploited the DNA Relatives feature to scrape data from connected profiles.
ISO/IEC 27001 Annex A.9.4.2 requires secure log-on procedures, including multi-factor authentication for systems processing sensitive data. NIST Cybersecurity Framework 2.0 calls this out under PR.AC-7: "Users, devices, and other assets are authenticated." For genetic data specifically, HIPAA Security Rule §164.308(a)(5)(ii)(D) mandates procedures for verifying authorized access when health information is involved.
You can't rely on customers to use unique passwords. If your service holds genetic data, implement mandatory MFA at account creation, not as an opt-in security feature. The settlement now requires the 23andMe Research Institute to undertake risk assessments and appoint a special board to oversee data security, which should have been standard practice from the start.
Myth 2: Genetic Data Breaches Are Self-Evident and Quickly Detected
Reality: Without logging and monitoring, you won't know you've been breached until the data appears on the dark web.
23andMe didn't learn of the breach "until months after it occurred." Some stolen data had already been posted on the dark web by the time the company confirmed the incident. The investigation found the company "failed to do logging or monitoring for breaches" and "did not probe atypical login patterns."
NIST SP 800-53 control AU-6 requires organizations to review and analyze system audit records for inappropriate or unusual activity. ISO/IEC 27001 Annex A.12.4.1 mandates event logging, and A.12.4.2 requires protection of log information. For genetic data under state breach notification laws, detection speed directly impacts your legal notification timeline.
Your Computer Security Incident Response Team needs real-time visibility into authentication patterns, data access anomalies, and bulk download attempts. If you're processing genetic data and can't answer "what accounts accessed DNA Relatives data in the past 24 hours?" within minutes, your detection capability is insufficient.
Myth 3: Blaming Users for Weak Passwords Is a Viable Defense
Reality: Regulatory bodies and courts reject the "user responsibility" argument when you failed to implement basic controls.
After confirming the breach, 23andMe "blamed consumers for how their accounts were configured and how passwords were used," according to the Attorney General's press release. This defense collapsed under multistate investigation because the company had failed to implement compensating controls that would have stopped credential reuse attacks.
The General Data Protection Regulation Article 32 requires "a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing." You can't claim user error when you haven't implemented technical measures to prevent foreseeable attack vectors. The NIST Cybersecurity Framework 2.0 function "Protect" exists precisely because you must assume credential compromise will occur.
If you're collecting consent for genetic data processing but not enforcing technical controls, you're building a compliance façade. The settlement's requirement that customers maintain their right to delete personal data indefinitely means you'll be managing consent and data retention for the life of your organization. Build the controls to match that timeline.
Myth 4: Vulnerability Management Can Wait Until After Feature Development
Reality: Known vulnerabilities in systems processing genetic data create immediate regulatory exposure.
The investigation found 23andMe "did not fix known vulnerabilities" and "did not test new design features" for security implications. This isn't a resource constraint problem; it's a prioritization failure that regulatory bodies now treat as willful negligence.
ISO/IEC 27001 Annex A.12.6.1 requires management of technical vulnerabilities, including timely installation of security patches. NIST SP 800-53 SI-2 (Flaw Remediation) establishes clear timelines: high-risk vulnerabilities demand immediate attention, typically within 30 days or less. When you're processing genetic data that can't be changed, the permanence of exposure amplifies the risk.
Your vulnerability management program needs defined SLAs tied to data sensitivity, not just CVSS scores. Genetic data systems should follow the same patching urgency as payment card environments under PCI DSS 4.0, where critical vulnerabilities require remediation within defined timeframes.
Myth 5: Bankruptcy Erases Your Data Protection Obligations
Reality: Genetic data follows the assets, and regulatory requirements transfer with it.
23andMe filed for bankruptcy protection in March 2025. In July 2025, the 23andMe Research Institute paid $305 million for the company's assets, including genetic data for customers who hadn't requested destruction. The settlement's data protection requirements now bind the Research Institute, not the bankrupt entity.
This creates a precedent: when you acquire genetic data through asset purchase, you inherit the privacy obligations. The institute must follow 23andMe's privacy policy, which bars sharing with employers, insurers, public databases, and law enforcement absent legal process. It also continues the practice of sharing and selling de-identified customer data for biomedical research.
If you're evaluating an acquisition involving genetic data, your due diligence must include current consent language, outstanding breach litigation, pending regulatory actions, and the technical debt in the security program. The $47 million fund for breach victims approved by a Missouri bankruptcy court in June came before the $18 million state settlement, demonstrating that liabilities can exceed the asset value.
Myth 6: State Attorneys General Only Act After Federal Agencies
Reality: Multistate coalitions now launch investigations within days and drive the enforcement agenda.
The 42 attorneys general launched their investigation "days after the breach occurred," not months or years later. This speed reflects a shift in state enforcement posture, particularly for breaches affecting genetic data where no single federal agency has clear jurisdiction.
State breach notification laws create the initial disclosure obligation, but attorneys general are increasingly using their consumer protection authority to impose security requirements that function like regulatory mandates. The settlement requires the Research Institute to undertake risk assessments and appoint a special board to oversee data security, effectively creating a consent decree that operates as a compliance framework.
Your incident response plan should assume state AG involvement within the first week of a reportable breach. If you're operating in multiple states and processing sensitive data categories like genetic information, you're facing potential multistate coordination from the start.
What to Do Instead
Map your genetic data flows against ISO/IEC 27001 Annex A controls and NIST Cybersecurity Framework 2.0 functions. Identify where you're relying on user behavior instead of technical controls. Implement mandatory MFA, real-time authentication monitoring, and automated vulnerability scanning with defined remediation SLAs.
Build your Computer Security Incident Response Team's detection capability around the assumption that credentials are already compromised. Test your ability to identify anomalous data access patterns weekly, not quarterly.
Review your consent management and data deletion processes against the settlement's requirement that customers maintain deletion rights indefinitely. If you can't execute a complete data deletion request within 30 days, including backups and research datasets, you're not meeting the emerging standard.
The 6.9 million people affected by this breach didn't choose weak security; they trusted a company that failed to implement controls matching the sensitivity of what it collected. Your customers are making the same trust assumption about your program right now.
