Skip to main content
Commerce Security logo, "All 12 PCI DSS Requirements in Plain English," "Get it now for free," "Complete Survival Guide" and a button toclick to get it
Credential Stuffing Defense: What 23andMe's $6M California Settlement Reveals About State Privacy EnforcementRegulations & Laws
6 min readFor GRC Leaders

Credential Stuffing Defense: What 23andMe's $6M California Settlement Reveals About State Privacy Enforcement

Scope

This guide focuses on the security controls, legal obligations, and governance decisions your team must make when handling sensitive personal data under state-specific privacy laws, especially when credential-based attacks are a significant risk. It draws lessons from California's $6 million settlement with 23andMe following a credential stuffing attack that exposed data for approximately 6.9 million individuals, including 855,000 California residents.

You'll find specific guidance for implementing authentication controls, complying with state laws, and managing data deletion workflows when a breach occurs.

Key Concepts and Definitions

Credential Stuffing: An automated attack using stolen username-password pairs to gain unauthorized access to accounts on other platforms. These attacks use valid credentials, making detection difficult without behavioral analytics.

California Genetic Information Privacy Act: State legislation imposing consent requirements on the collection, use, and transfer of genetic data. It creates obligations beyond federal frameworks and was central to California's attempt to block 23andMe's sale to TTAM Research Institute.

State-Specific Privacy Enforcement: State attorneys general can pursue separate actions even when multi-state coalitions settle. California's decision to opt out of a 42-state $18 million settlement shows how states with stronger privacy laws exercise independent enforcement authority.

Data Deletion Rights Post-Breach: Consumers can request permanent removal of their personal information following a security incident, regardless of corporate ownership changes. This right survived 23andMe's bankruptcy and acquisition.

Requirements Breakdown

Authentication and Access Control

You must implement controls that detect and block credential-based attacks, even when customers reuse passwords. The states' argument against 23andMe centered on foreseeability: if credential stuffing is a known threat in your industry, you can't claim surprise when it happens.

NIST SP 800-63B provides the baseline. Section 5.1.1.2 requires comparing authentication attempts against lists of commonly used, expected, or compromised credentials. Section 5.2.2 addresses rate limiting and device fingerprinting for detecting automated attacks.

ISO/IEC 27002 Control 5.17 (Authentication Information) and Control 5.18 (Access Rights) establish the management framework. You need both technical controls (multi-factor authentication, anomaly detection) and governance processes (periodic access reviews, credential hygiene enforcement).

State Privacy Law Compliance

Operating in California subjects you to multiple overlapping frameworks:

  • California Consumer Privacy Act (CCPA): Grants deletion rights and imposes security obligations.
  • California Genetic Information Privacy Act: Adds consent requirements for genetic data transfers.
  • California Attorney General enforcement authority: Allows independent legal action separate from multi-state settlements.

The 23andMe case shows that bankruptcy doesn't erase these obligations. California attempted to block the $305 million sale to TTAM Research Institute because customers hadn't consented to the data transfer under state genetic privacy law.

Post-Incident Data Subject Rights

After a breach, you must operationalize deletion requests at scale. 23andMe customers retained the right to delete their genetic data even after ownership changed. Your data lifecycle management can't depend on corporate structure remaining static.

Your deletion workflow needs:

  • Verified identity confirmation before processing requests.
  • Deletion across all systems, including backups and analytics databases.
  • Audit trails proving deletion occurred.
  • Clear communication about what deletion covers (some data may need retention for legal compliance).

Implementation Guidance

Building Credential Attack Detection

Start with NIST Cybersecurity Framework (CSF) 2.0 Function PR.AC (Identity Management, Authentication, and Access Control). Your implementation should include:

  1. Breach database integration: Query services like Have I Been Pwned during password creation and reset. Reject credentials that appear in known breach compilations.

  2. Behavioral analytics: Monitor for login velocity (multiple attempts from different geolocations within short timeframes), device fingerprint mismatches, and access patterns inconsistent with the user's history.

  3. Adaptive authentication: Require step-up authentication when risk indicators trigger. A user logging in from a new device in a new country should face additional verification.

  4. Rate limiting: Implement account-level and IP-level throttling. CIS Critical Security Controls v8 Control 6.3 (Require MFA for Externally-Exposed Applications) and 6.5 (Require MFA for Administrative Access) provide the framework.

Addressing State-Specific Requirements

You can't treat state privacy laws as a checkbox exercise. California's decision to pursue separate enforcement after 42 states settled for $18 million total shows that states with stronger consumer protection frameworks will hold you to higher standards.

Build a state-law compliance matrix that tracks:

  • Which states have genetic/biometric-specific privacy laws.
  • Consent requirements that exceed your baseline.
  • Attorney general enforcement patterns (California, New York, and Massachusetts are particularly aggressive).
  • Data transfer restrictions during corporate transactions.

When handling sensitive categories (genetic, biometric, health), assume you'll need explicit consent for any data transfer, including internal restructuring or acquisition scenarios.

Preparing for Corporate Transitions

The 23andMe bankruptcy and sale created a legal collision: California argued the data transfer violated state law because customers hadn't consented, while the bankruptcy court ruled the sale could proceed. Your GRC program needs to address this scenario before it happens.

Pre-transaction due diligence checklist:

  • Document the legal basis for data processing under each applicable state law.
  • Review whether your privacy notices contemplate ownership changes.
  • Identify data categories requiring explicit consent for transfer.
  • Map which state AGs have jurisdiction over your customer base.
  • Calculate the cost of offering deletion as part of any transaction.

If you're the acquiring party, require representations and warranties that cover state-specific privacy compliance, not just federal frameworks.

Common Pitfalls

Assuming federal compliance satisfies state requirements: HIPAA compliance doesn't satisfy California's genetic privacy law. SOC 2 Type II doesn't address state-specific consent requirements. You need layered compliance that addresses the most restrictive jurisdiction where you operate.

Treating customer password practices as their problem: The states rejected 23andMe's argument that customers' password reuse caused the breach. If credential stuffing is foreseeable in your industry, you own the obligation to detect and block it.

Ignoring state AG enforcement trends: When 42 states settle and one opts out, that's a signal. California's separate $6 million settlement (on top of the multi-state $18 million and a $46.75 million class action settlement) shows that state-specific enforcement can multiply your total liability.

Failing to operationalize deletion at scale: Offering deletion rights in your privacy policy isn't enough. You need technical infrastructure that can process thousands of requests following a breach, with audit trails proving completion.

Underestimating data transfer restrictions: Corporate transactions involving customer data aren't purely commercial decisions. State privacy laws can impose consent requirements that affect deal structure, timing, and valuation.

Quick Reference Table

Control Area Primary Framework Key Requirement 23andMe Lesson
Authentication NIST SP 800-63B § 5.1.1.2 Compare credentials against breach databases Credential stuffing detection is mandatory, not optional
Access Control ISO/IEC 27002 Control 5.18 Implement adaptive authentication based on risk Behavioral analytics should trigger step-up verification
Incident Response NIST Cybersecurity Framework (CSF) 2.0 2.0 Function RS Operationalize data subject rights post-breach Deletion requests must work regardless of ownership changes
Privacy Compliance California Genetic Information Privacy Act Obtain consent for sensitive data transfers Bankruptcy doesn't erase state privacy obligations
State Enforcement CCPA § 1798.155 Track state AG enforcement patterns States with stronger laws pursue independent actions
Corporate Governance ISO 31000 Assess privacy risk in M&A transactions Data transfer restrictions affect deal structure and cost

Your authentication controls, state privacy compliance, and corporate transaction planning must account for the reality that credential-based attacks are foreseeable, state attorneys general exercise independent enforcement authority, and sensitive data creates obligations that survive bankruptcy and acquisition. The 23andMe settlements demonstrate that treating these as theoretical risks rather than operational requirements carries measurable financial consequences.

Green background, the words "The Biggest AI Security Risk Isn’t the Model. It’s the Agent." A robot drawing. A button for "Get the Free Guide."

You Might Also Like