Legal Analysis: Root Insurance Company’s $975,000 Penalty for Data Security Lapses.

Ramyar Daneshgar

31 Mar 2025 — 5 min read

By Ramyar Daneshgar

Disclaimer: This article is for educational purposes only and does not constitute legal advice. If you require legal guidance specific to your organization, consult with a licensed attorney experienced in cybersecurity and data protection law.

Enforcement Analysis: Root Insurance Company – A Case Study in Web Application Misconfiguration and Data Privacy Liability

Document: Assurance of Discontinuance No. 25-009
Agency: New York Attorney General (NYAG), Bureau of Internet & Technology
Respondent: Root Insurance Company
Penalty: $975,000
Effective Date: March 5, 2025

I. Introduction

This enforcement action by the New York Attorney General’s Office against Root Insurance Company offers a comprehensive example of how insecure web applications, insufficient authentication mechanisms, and poor internal security governance can result in widespread unauthorized access to sensitive personal information.

Root’s public-facing insurance quote tool was exploited through automated requests, enabling threat actors to retrieve unmasked driver’s license numbers (DLNs) of over 72,000 individuals, including at least 44,449 New York residents. These DLNs were subsequently used in fraudulent unemployment claims. The breach resulted in a $975,000 monetary settlement and a multi-year binding agreement to overhaul the company’s information security practices.

This matter is illustrative not only for regulated industries but for all companies that handle personally identifiable information (PII) through APIs or public-facing web applications.

II. Chronology of the Incident

Prefill Functionality: Root’s quote tool retrieved sensitive consumer data (e.g., DLNs) from third-party data aggregators using limited user input (name, address, DOB), then pre-filled an insurance application PDF.
Exploit: On January 19, 2021, Root’s systems were targeted using automated scripts (bots) that exploited this design flaw to extract DLNs en masse.
Discovery: An internal alert was triggered on January 27 due to an uptick in unaffiliated profile generation. A temporary CAPTCHA was deployed, but only after the incident had been ongoing for over a week.
Containment: By February 2, Root had permanently masked DLNs in the quoting flow and removed the vulnerable functionality.
Impact: More than 72,000 DLNs were accessed. A significant portion were subsequently used to file fraudulent unemployment claims with the New York State Department of Labor.

III. Legal and Regulatory Violations

A. Executive Law § 63(12)

This statute prohibits any fraudulent or illegal conduct in the conduct of business. Root’s failure to protect consumer data through reasonable security controls constituted unlawful conduct under this provision.

B. General Business Law § 899-bb

This law requires any entity that owns or licenses New York residents’ private information to maintain reasonable safeguards. Under § 899-aa and § 899-bb, “private information” includes an unencrypted driver’s license number when linked to a name or address. Root failed to implement reasonable controls—such as masking, authentication, or bot mitigation—allowing for large-scale unauthorized access to such data.

IV. Technical Failures and Organizational Oversights

1. Lack of Authentication and Authorization Controls

The application disclosed sensitive information (including full DLNs) without verifying the identity of the user. This failure made it possible for threat actors to access private information by simply submitting plausible combinations of names and addresses.

2. Absence of Rate Limiting and Bot Detection

The insurance quote tool lacked basic protections such as CAPTCHA, IP throttling, and traffic monitoring. This omission made the system vulnerable to scripted attacks and data scraping.

3. Improper Data Handling and Exposure

DLNs were embedded in plain text within PDF files generated by the application. This constituted a serious failure to follow the principle of least privilege and violated modern data minimization standards.

4. Inadequate Security Governance and Risk Assessment

Root did not conduct sufficient risk assessments of public-facing tools or document secure coding and deployment standards. Security teams failed to anticipate or identify the systemic risk posed by the prefill functionality until it was exploited.

5. Delayed Incident Response

Even after unusual activity was detected, Root did not initially recognize the exposure of DLNs. The security incident team acted reactively and escalated the matter only after days of continued exposure.

V. Mandated Compliance Measures

The AOD imposes sweeping corrective actions on Root Insurance, including:

A written, annually updated Information Security Program (ISP) tailored to the nature and volume of private information processed.
Designation of a qualified Chief Information Security Officer (CISO) with reporting obligations to the CEO and Board of Directors.
Complete data inventory and flow mapping, including use of APIs and third-party integrations.
Implementation of secure development lifecycle (SDLC) practices, with security and privacy assessments required for every change to public or internal applications.
Enforcement of multi-factor authentication (MFA) for access to sensitive systems and unredacted PII.
Deployment of automated attack detection, bot mitigation, and anomaly monitoring.
Establishment of robust incident response protocols, with rapid containment, investigation, and remediation mandates.
Log retention policies requiring access logs be stored for at least one year and readily available for 90 days.

VI. Lessons Learned

1. Public-Facing APIs and Prefill Tools Must Be Treated as Attack Surfaces

Organizations must recognize that publicly accessible quote tools or form-fill applications, especially those backed by third-party data providers, are extensions of their data perimeter. Every endpoint capable of returning sensitive information should be subject to stringent access controls and abuse detection mechanisms.

2. Authentication Must Precede Data Disclosure

The principle of “no data without identity verification” should be hard-coded into all applications handling regulated information. Sensitive fields (e.g., DLNs, SSNs, financial account numbers) must not be retrievable without prior user authentication, identity validation, and session integrity checks.

3. Security Must Be Embedded in the Software Development Lifecycle (SDLC)

This case illustrates the danger of siloed development and security operations. Data privacy and application security must be integral to the design, testing, and deployment of any software system. Secure coding practices, threat modeling, and regular penetration testing are essential.

4. Rate Limiting and Bot Detection Are Foundational Controls

Organizations must implement standard web application security controls such as rate limiting, CAPTCHA, IP blocking, and bot behavior detection. The absence of these basic measures in Root’s quote tool was a critical oversight that enabled automated exploitation.

5. Sensitive Data Should Be Masked or Obfuscated by Default

Even in legitimate workflows, unredacted PII should be masked wherever feasible—especially in documents that are generated dynamically and served to users or browsers. The use of full DLNs in unprotected PDFs represents a fundamental violation of data minimization principles.

6. Continuous Risk Assessment is a Regulatory Expectation

Regulators now expect organizations to engage in continuous assessment of security risks—especially around changes in data flows, system architecture, and third-party integrations. A one-time risk review is insufficient when dealing with evolving threat models.

7. Real-Time Monitoring and Log Review Are Critical for Timely Detection

Threat actors exploited Root’s systems for more than a week before detection. Organizations must adopt centralized logging, real-time monitoring, and SIEM integration to detect anomalies such as unusual access patterns or rapid-fire submissions from unauthenticated users.

8. Breach Response Must Be Swift, Escalated, and Multi-Tiered

Root delayed escalation of the incident for critical days. A mature incident response process must include real-time triage, automated alerts, incident classification, executive notification, and post-incident reviews. Delays in recognizing and containing a breach can materially increase exposure and legal liability.

VII. Conclusion

The Root Insurance enforcement action provides a compelling case study on the intersection of cybersecurity engineering, legal compliance, and consumer protection. The violations underscore that in today’s regulatory climate, a failure to implement even basic security controls can constitute a breach of law.

For legal and compliance professionals, the Assurance sets a strong precedent regarding what regulators view as “reasonable safeguards” under state privacy statutes. For security engineers, it reinforces the need for architectural security and adversarial thinking when designing consumer-facing platforms.

Resources

Learn more from the NY press release and prior auto actions: https://lnkd.in/g9_aaw7T
Information about best practices under the NY Shield Act: https://lnkd.in/gJKYa2Tb
Information about MA's standards for the protection of personal information: https://lnkd.in/g_TRhppj

Author: Ramyar Daneshgar Security Engineer & Legal Policy Researcher at CybersecurityAttorney.com

This article is provided for informational purposes only and does not constitute legal advice. For legal counsel, please consult a licensed cybersecurity attorney.