Intro

Imagine showing up to work one day and realizing that your system has been leaking sensitive customer data for months. Not just a small slip-up, but a big one – sending personal information to a third party without the proper protections. That’s exactly what happened at Lemonade.

In insurtech, where digital platforms and sensitive customer data are central to the business, security is everything. The industry is a prime target for cyber threats, and even with all the technology available, vulnerabilities like this can still slip through the cracks.

It’s not just about checking compliance boxes, but learning and keeping the trust of customers. In this article, I’ll break down what went wrong at Lemonade, why it could’ve been prevented, and what can be learned from it to ensure it doesn’t happen to you.

Dissecting the Lemonade data breach

In April 2025, Lemonade, a tech-driven insurance company took decisive action when it uncovered a data leak that had quietly persisted for 17 months. It impacted about 190,000 people and exposed driver’s license numbers, a critical piece of sensitive personal information. While it’s unsettling that the issue went unnoticed for so long, the root cause was a straightforward misconfiguration in Lemonade’s auto-insurance quote system.

Here’s what happened: information meant to flow securely to a trusted third-party service was inadvertently made public through an API. No elaborate hacking was involved – just a simple technical slip that allowed driver’s license numbers to be accessed openly. In an insurtech setting, where protecting personally identifiable information (PII) is non-negotiable, spotting and fixing that kind of oversight is crucial.

Lemonade’s prompt identification and containment of the mistake demonstrate their commitment to keeping client’s data safe. Every company can hit a snag – what matters is how swiftly you respond, plug the hole, and strengthen your defenses.

Why did it happen?

The root of the problem was pretty simple – a lack of proper encryption and data masking during API transactions. Sensitive information was sent unencrypted and exposed in API traffic, a vulnerability that’s easily avoidable with basic secure development practices.

How long the issue lasted and how was it discovered?

What stands out to me the most in this whole incident is just how long the breach went unnoticed – nearly 18 months. That’s a long time for sensitive data to be exposed, and it seems sheer luck prevented a much worse outcome. For any organization, especially one handling personal data, this kind of delay in uncovering security risks raises real questions about how well threat monitoring and logging are working.

Lemonade has clarified that the breach wasn’t the result of a targeted attack, which is certainly reassuring for their affected clients. But even so, as a security expert, I have to say the length of the exposure period is unjustifiable.

Even small anomalies, like repeated unencrypted data transfers, should trigger alerts or be picked up in regular audits by teams. It’s a reminder to all of us in the industry that security can’t be a one-time setup. It has to be proactive, constant, and built into every layer of the system.

What did Lemonade do to address the problem?

Once Lemonade found out about the breach, they acted quickly. On top of the notifications sent out to affected users I’ve already mentioned, they also filed the required disclosures with regulators, including in states like California and Maine where that’s legally mandated. Of course, they also fixed the technical issue in their auto quote system quickly. They also went for a very common practice, offering a year of free credit monitoring to those impacted.

It’s good to see they took these steps seriously and responded in line with compliance standards. But no company can afford such risks if they handle sensitive personal data.

Red team vs blue team: How the Lemonade breach could have been exploited (and prevented)

It’s all too common to see hindsight critiques after a breach, but real-world scenarios like this API misconfiguration show exactly how things can unravel. A hands-on Red Team vs. Blue Team drill, which I present below, can help your security and engineering teams learn and grow together.

Red team view (attacker’s perspective)

From the moment an adversary sets their sights on Lemonade’s auto-quote API, their goal is crystal clear: quietly siphon off sensitive personal data – like driver’s license numbers – without raising the alarm.

First, they scope out the landscape by probing publicly exposed endpoints, capturing traffic with tools such as Burp Suite or Postman. With each intercepted request and response, they search for weaknesses. Soon enough, they discover that the API is dishing out raw driver’s license numbers in plain text – no encryption, no authentication, nothing standing between them and a treasure trove of PII.

Armed with this knowledge, they automate. A custom script fires off thousands of quote requests, feeding randomized or previously leaked data to the API and steadily harvesting personal records at scale. Behind the scenes, harvested data is quietly funneled off-site, ready for sale on the dark web or use in identity fraud.

At the heart of this attack lies a simple misstep: sensitive data exposed without tokenization, access controls, or basic encryption. Compounding the problem, there’s no monitoring to flag an unusual spike in quote requests or detect anomalous access patterns giving the attacker free rein to exfiltrate information undisturbed.

Here’s a clear, simple flowchart illustrating the attack progression:

Blue team view (defender’s perspective)

Let’s now step into the shoes of the defending team, and define the high-level objective as:

Prevention, detection, and response to an attempted exfiltration of sensitive data via an API.

Here’s how we would approach it at Clurgo.

Tokenization at the source
The first thing we would recommend to Lemonade would be replacing driver’s license numbers with irreversible tokens (for example, in a “XYZ-111-222” format), before releasing them to any external or third-party system.

These tokens would be randomly generated character strings that attackers wouldn’t be able to reverse-engineer to reveal the original driver’s license numbers. For that, they’d need access to the internal database that maps tokens to real data. So, even if intercepted, the tokens would be useless to unauthorized parties, posing no risk or creating no real case for ransom.

API gateway enforcement and anomaly detection

From day one, Lemonade should have treated every API call as a potential attack vector. That starts with end-to-end encryption and strict data masking so even if traffic veers off course, raw driver’s license numbers never appear in plain text. On top of that, enforce scoped API keys, and role-based permissions to guarantee that only authorized services can request sensitive fields.

Next, put continuous traffic monitoring and automated rate-limiting in place to cap how many quote requests a single client can fire off in any time window. Feed live metrics like request volume, response size, user-interaction frequency into real-time anomaly-detection models trained on Lemonade’s own traffic. Those machine-learning algorithms catch the subtle patterns static rules miss like an unfamiliar IP harvesting PII or a sudden geographic spike and trigger instant safeguards: throttling, credential revocation, or endpoint lockdown.

Finally, bake these controls into your CI/CD pipeline and back them up with regular pentests and configuration audits. By weaving encryption, access controls, monitoring, anomaly detection, and rigorous reviews into your development lifecycle, you transform every potential misstep into a routine security check, keeping customer data safe and your team always one step ahead.

Alert & response playbooks

Assuming that an attacker would have actively exploited the exposed API from Lemonade, the defender team’s success would have depended on how quickly and effectively they could detect and contain the breach. This is where alert and response playbooks come in.

They feature predefined plans that guide the security team through exactly what to do when specific types of anomalies or threats are detected.

In this scenario, a good playbook would start with automated alerts triggered by unusual behavior. At Clurgo, we’d make sure that the moment this alert fires, the incident response team is notified through channels like Slack, PagerDuty, or email.

From there, the response plan would kick in. Tokens used to access the API would be immediately revoked to cut off further data leakage. A kill-switch mechanism would disable external API calls, effectively shutting down the vulnerable endpoint. The team would then begin triage: containing the breach, assessing the scope, preserving logs for forensics, and preparing public and regulatory communications if needed.

Code-level controls

At the API layer, enforce strict payload validation so that no sensitive field like a driver’s license number can slip through unless explicitly authorized. By embedding these checks directly in your code, you create a last line of defense that blocks accidental exposures before they ever leave your service.

Data minimization & anonymization

Share only what’s absolutely essential, treat each subcontractor like a traveler packing just the essentials, and you dramatically shrink your attack surface. As mentioned earlier, whenever possible, replace real driver’s license numbers with pseudonyms or hashes: think of these as nicknames or fingerprints that mask identities while still allowing verification. By limiting what travels and cloaking what remains, Lemonade would keep customer PII protected even when working with external partners.

By weaving these practices into their development lifecycle, Lemonade could have turned a single misstep into just another item on their security checklist keeping customer data safe and their team confidently one step ahead of attackers.

The impact of data breaches – what do they mean for business and technical decision-makers?

The Lemonade breach is a wake-up call for both business and technical leaders. It wasn’t caused by a sophisticated attack, but by a preventable misconfiguration and long-overdue detection. Here’s why both sides should care:

Business decision-makers

• Reputation risk – customer trust erodes fast after a breach, especially when PII is exposed for 17 months.
• Regulatory impact – delayed detection can lead to legal penalties, audits, and compliance failures.
• Financial cost – beyond fines, breaches trigger customer churn, legal fees, and higher cyber insurance premiums.
• Investor confidence – poor security hygiene raises red flags during due diligence.

Technical decision-makers

• Basic failures, big consequences – unencrypted data in API traffic signals gaps in secure development practices.
• Lack of monitoring – no alerts flagged abnormal access patterns are a clear DevSecOps blind spot.
• Security is cross-functional – It’s not just on security teams; developers, DevOps, and product owners all play a role.

As you can see, business leaders must champion data security at the top, and technical leaders must bake it into every line of code and process. Breaches like Lemonade’s are preventable, but only if the right conversations happen across functions, early and often.

Insurtech security benchmark table: How does your organization compare?

Keeping data secure in insurance

The Lemonade data breach proves just how important it is to stay ahead of security issues, especially in insurtech, where customer data is so sensitive (and the penalties for data violations are so severe). The fact that there was a simple misconfiguration that stood behind all this shows two things. The first, is that you need to have a team who is proactive about security, and the second – that they should be skilled to fix any issues as fast as possible.

At Clurgo, we have experience building secure tech for insurance companies. We can help you set up the right security practices to prevent problems and ensure your team is ready to act quickly if anything goes wrong. Let’s work together to keep your data safe.