The Conduent Breach: How Did “Industry Standard” Security Fail 10.5 Million People?

Conduent at the NYSE
Understanding why encrypted data gets stolen starts here: on October 21, 2024, threat actors gained unauthorized access to Conduent Business Solutions’ network. The breach went undetected until January 13, 2025; nearly three months later. By then, attackers had compromised data belonging to 10.5 million people, making it the largest healthcare breach reported in 2025.

But the damage wasn’t done over three months. It was done the moment attackers gained access to systems actively processing personal and health information. With at least nine class action lawsuits filed and state regulators investigating, one critical question echoes through courtrooms and boardrooms: How did “industry standard” security measures fail so catastrophically? The answer reveals a fundamental vulnerability that most organizations don’t understand about their encryption systems.

The Real Problem Isn’t Detection Time

Media coverage has focused on the timeline: unauthorized access from October 2024 to detection in mid-January 2025. Three months sounds alarming, and it is, but it misses the fundamental issue.

Data exfiltration doesn’t take three months. It takes minutes, perhaps hours. When attackers accessed Conduent’s systems, they immediately gained access to Social Security numbers, medical records, and health insurance information for clients including Blue Cross Blue Shield of Montana, Blue Cross Blue Shield of Texas, Humana, and Premera Blue Cross.

Here’s the critical point most miss: Conduent, like virtually every organization handling sensitive data, decrypts data to use it. While running member eligibility checks, processing claims, and managing back-office operations, that data remains in clear text and therefore easy for hackers (or even a database admin) to review. The moment attackers breached the system, they had access to usable data.

Faster detection wouldn’t have prevented this breach. Better firewalls wouldn’t have prevented this breach. The vulnerability wasn’t in Conduent’s security monitoring or perimeter defenses; it was in the fundamental architecture of how data must be better secured in all states, even when in use.

Why Encrypted Data Gets Stolen: The Gap in Encryption Strategies

Typical encryption deployments protect data in only two states:

  • At rest (stored in an inactive state)
  • In transit (moving between systems)

But there’s a third state: In use (actively being processed). And this is the attack vector for hackers.

To work with data, systems currently decrypt it. Because these enterprise systems run around the clock, the data inside those systems remains decrypted and vulnerable. When Conduent’s applications were processing daily activities such as checking eligibility, processed payments, or generating reports, the data had to be in readable, unencrypted form. During those processing operations, which run continuously in enterprise administrative systems, the data was vulnerable.

This is a limitation of the benefit of legacy encryption architecture that affects every organization processing sensitive data. You can have perfect perimeter security, excellent monitoring, and rapid incident response; but once your data is decrypted for use, you have an exposure window. This is the encryption gap we cover in depth in The Encryption At Rest Myth: the reason why following industry standard encryption is no longer sufficient to protect data in active use.

Why “Industry Standard” Is No Longer a Defense

The considerable lawsuits stacking up against Conduent allege “failure to implement reasonable data security measures.” Plaintiff attorneys specifically cite the company’s inability to protect information that was obtained, collected, and stored as part of its business operations.

Defense counsel now face an uncomfortable question: When opposing counsel asks, “Why didn’t you implement continuous encryption that protects data even during active processing?” what’s the answer?

“We followed industry standards” used to be sufficient. But courts are increasingly sophisticated about cybersecurity. They understand that technology evolves. And when next-generation solutions exist that eliminate entire classes of vulnerability, claiming “we did what everyone else does” may not satisfy the court’s definition of “reasonable security measures.”

The legal landscape is shifting. Organizations that can demonstrate they implemented the most advanced protection available have fundamentally stronger defensive positioning. Opting for continuous encryption eliminates the vulnerability, and thereby the damages, the negative PR and the regulatory reporting. Even in hackers penetrate the perimeter (as Zero Trust architectures expect); if there is no exposure of PII, then there is no event.

The Third-Party Vendor Multiplier Effect

Premera Blue Cross and Blue Cross Blue Shield of Texas quickly issued statements emphasizing “this was not a breach of our systems.” They’re attempting to deflect liability to Conduent. But their exposure remains significant.

When you entrust sensitive data to a third-party vendor, you’re still accountable if that vendor’s security measures prove inadequate. Even with pristine internal systems and rigorous vendor assessments, if your vendor must decrypt your data to process it, you’ve created an exposure point that traditional contracts and security requirements can’t eliminate.

For the 462,000 Blue Cross Blue Shield of Montana members affected by this breach, it’s little comfort that Montana BCBS’s own systems weren’t compromised. Their data was still exposed the moment attackers accessed Conduent’s systems; and the insurer still faces regulatory investigations and potential litigation.

The Conduent breach highlights a critical vendor risk that standard security questionnaires don’t address. Asking vendors, “Do you use encryption?” isn’t enough when that encryption only protects data at rest and in transit: not during the active processing that vendors are contracted to perform.

What Continuous Encryption Changes

Imagine if Conduent’s systems had been protected by continuous encryption; technology that keeps data encrypted even during active processing, not just at rest or in transit.

When attackers breached the systems, they would effectively be in the dark. They cannot see what is available, and therefore they won’t know what to steal, if anything. Yes, they could have accessed servers, copied files, and exfiltrated data blindly. But everything they obtained would be in its encrypted state; useless for extortion, impossible to sell on dark web markets, and worthless for identity theft.

The SafePay ransomware gang claims to have stolen 8.5 terabytes of data from Conduent. With continuous encryption, those 8.5 terabytes would be gibberish that cannot be decrypted even with quantum technology. No leverage for ransom demands. No value on criminal marketplaces. No exposure for the affected individuals.

This isn’t theoretical. Homomorphic encryption technology that enables continuous data protection has existed conceptually for years. What’s changed is deployability. Next-generation solutions now deliver continuous encryption at speed and scale on standard hardware; eliminating the performance penalties and costs that previously made this technology impractical for most organizations.

The Numbers Behind the Conduent Breach

Consider what Conduent now faces:

  • Nine federal class action lawsuits (and counting)
  • State regulatory investigations across multiple jurisdictions
  • Mandatory breach notifications to 10.5 million individuals
  • Two years of credit monitoring and identity protection services for affected individuals
  • Immeasurable reputation damage affecting a company with $3.4 billion in annual revenue
  • Litigation costs that will likely reach tens of millions of dollars

The breach occurred because data had to be decrypted during processing. That architectural requirement created the vulnerability. Everything that follows: the lawsuits, the regulatory scrutiny, the notification costs, the reputation damage, stems from that single point of exposure.

Against this risk, the investment in continuous encryption technology becomes remarkably straightforward. For a detailed breakdown of what breach costs actually look like across industries, see How Much Does a Data Breach Cost?. Organizations aren’t comparing deployment costs against theoretical risk, they’re comparing it against the quantifiable costs that breaches like Conduent’s actually generate.

Three Questions Your Leadership Team Should Ask Today

  1. Processing vulnerability: “During our normal business operations, when our systems are actively processing sensitive data, is that data decrypted and therefore vulnerable if someone breaches our perimeter?” For most organizations, the answer is yes.
  1. Vendor exposure: “For each third-party vendor that processes our sensitive data, what happens if attackers breach their systems during active data processing?” If your vendors decrypt data to use it, their breach becomes your liability.
  1. Legal positioning: “If we face breach litigation, can we demonstrate we implemented technology that protects data during active processing, or only ‘industry standard’ encryption that requires decryption during use?” As courts become more sophisticated, this distinction increasingly matters.

Embracing New Standards

The Conduent breach will generate headlines for months as litigation proceeds and regulatory investigations conclude. But the lasting impact should be a fundamental reconsideration of what “reasonable security measures” means now.

Encryption at rest and in transit served us well when the primary threat was data theft during transmission or from stored databases. But modern breaches, like Conduent’s compromise of actively processing data, demonstrate that the real vulnerability occurs during data use, not during storage or transmission.

Organizations that continue to rely solely on encryption that protects data at rest and in transit are making a calculated bet: that attackers will never breach their perimeter, that courts will always accept “industry standard” as sufficient, and that the exposure during active processing won’t be exploited.

For 10.5 million people affected by the Conduent breach, that bet will follow them for years to come. The vulnerability wasn’t about detection time or perimeter strength; it was about data being kept in a clear state by a vendor they didn’t even know about.

The architectural question is simple: If attackers breach your perimeter tomorrow and access your processing systems, will they find usable data or encrypted gibberish?

For most organizations today, the honest answer is uncomfortable. But it doesn’t have to stay that way.

Ready to evaluate continuous encryption for your organization? Schedule a no-obligation technical briefing to learn how Donoma Seshat eliminates the exposure window that made the Conduent breach so devastating.

Schedule a Briefing

Frequently Asked Questions

Why is encrypted data still getting stolen in major breaches?

Most enterprise encryption deployments only protect data at rest and in transit. The moment an application decrypts data for active processing, that data exists in cleartext. Attackers who breach the perimeter during those processing windows find usable, readable data. The Conduent breach is a direct example: the data was likely encrypted at rest, but attackers accessed it during active processing when it had to be decrypted to function.

What is the encryption gap and why does it matter?

The encryption gap is the window during which data must exist in cleartext to be processed. Traditional encryption closes two of three vulnerability states, at rest and in transit, but leaves data exposed during active use. For enterprise systems that run continuously, this means data is effectively unprotected for most of its operational life. Closing the encryption gap requires continuous encryption: technology that keeps data encrypted even during processing.

What is continuous encryption and how does it differ from standard encryption?

Standard encryption decrypts data before processing, creating a cleartext exposure window. Continuous encryption (also known as encryption in use) keeps data encrypted throughout its entire lifecycle: at rest, in transit, and during active use. Operations run directly on encrypted data. Even if an attacker breaches the perimeter and accesses processing systems, they find only encrypted output with no usable value for extortion, sale, or identity theft.

How does third-party vendor data processing create liability for the organizations that hire them?

When you share sensitive data with a vendor for processing, and that vendor must decrypt your data to perform the contracted work, you have created an exposure point outside your own security perimeter. If the vendor is breached during active processing, your data is exposed regardless of how strong your own systems are. Standard vendor security questionnaires and contractual obligations do not eliminate this risk. Only continuous encryption removes the exposure.

What legal standard is emerging for data-in-use protection after breaches like Conduent?

Courts are increasingly distinguishing between organizations that implemented standard encryption (at rest and in transit) and those that protect data during active processing. Plaintiff counsel in breach litigation are starting to question why continuous encryption was not implemented when the technology is commercially available. Claiming industry standard compliance is becoming a weaker defense as courts recognize that available technology has advanced beyond that standard.

What would continuous encryption have changed about the Conduent breach outcome?

If Conduent’s systems had used continuous encryption, the 8.5 terabytes the SafePay ransomware gang claims to have exfiltrated would have been encrypted gibberish with no decryptable value. No ransom demand would have leverage. No notification to 10.5 million individuals would have been legally required. No class action lawsuits would have had damages to allege. The breach attempt would have been a security incident, not a data exposure event.

Additional Resources: