The data breach encryption failure that cost Red Hat an estimated $100 million did not happen because their encryption was missing. It happened because their encryption had a gap every enterprise shares: data that must decrypt to be used cannot be protected while it is being used. For a detailed breakdown of what breach costs look like across industries, the numbers are larger than most organizations model — and the Red Hat figure does not include multi-year reputational damage to sales cycles.
Here’s the hard truth: this entire cascade could have been prevented with adoption of a continuous encryption solution that continuously encrypts data so it can never be stolen.
The Cyber Breach That (Really) Broke Vendor Trust
When the Crimson Collective hacking group disclosed their Red Hat haul, they didn’t just dump source code. They showed they had taken over 800 Customer Engagement Reports (CERs) containing the crown jewels of enterprise infrastructure: database connection strings with embedded passwords, VPN profiles, authentication tokens, network architecture blueprints, and API keys. These weren’t theoretical vulnerabilities; the attackers explicitly stated they had already used stolen credentials to access customer systems. “Gained access to some of their client’s infrastructure as well,” the group posted, “already warned them but yeah they preferred ignoring us.”
The victim list includes well known enterprises such as JPMorgan Chase, AT&T, Verizon, Walmart, IBM, Cisco, Mayo Clinic, Kaiser Permanente, the FAA, NSA, and Department of Homeland Security. The Belgium Centre for Cybersecurity immediately issued a “high risk” advisory, instructing organizations to rotate all tokens and credentials shared with Red Hat.
The business impact? Red Hat faces reputation damage that will haunt sales cycles for years, potential regulatory fines across multiple jurisdictions, and litigation from customers whose infrastructure was compromised. Industry analysts estimate total damages (direct costs plus customer impact) could exceed $100 million.
Data Breach Encryption Failure: Why Your Strategy is Likely Incomplete
The Red Hat breach exposes what security experts call the “decrypt to use” vulnerability, and it’s likely undermining your defenses at this very moment. Here’s the uncomfortable reality: operational databases are never truly “at rest.” They run continuously, processing thousands of queries per second. Your encryption-at-rest strategy provides zero protection when data is actively being used, which is essentially always. The full explanation of why this happens and why it affects every organization running standard database infrastructure is in The Encryption At Rest Myth.
Traditional encryption strategies creates a dangerous cycle:
That decryption window is where sophisticated attackers strike. They don’t waste time on encrypted files; they target running systems where encryption has already been removed for operational purposes. In Red Hat’s case, authentication tokens and customer infrastructure details existed in repositories either unencrypted or easily accessible when developers and consultants needed them for work. Once attackers breached the GitLab instance, they found a treasure trove of credentials in usable form.
Aras Nazarovas, information security researcher at Cybernews, captured the cascading threat: “Source code and consulting engagement reports, if leaked, can help attackers analyze internal company infrastructure and software. This makes it significantly easier and faster to identify vulnerable attack vectors.” Stolen data became an instruction manual for attacking Red Hat’s customers.
How Donoma Seshat’s Encryption-in-Use Would Handle it
Donoma Seshat eliminates the fundamental vulnerability that made Red Hat’s breach catastrophic: the requirement to decrypt data before using it. Using breakthrough homomorphic-level encryption technology, Seshat keeps data continuously encrypted: at rest, in transit, and critically, during active processing and use. This isn’t theoretical cryptography; it’s quantum-resistant, software-based protection that integrates with existing enterprise systems at scale and speed on existing computing infrastructure.
Here’s exactly how Seshat would have prevented the Red Hat catastrophe:
Stolen credentials become worthless. The authentication tokens that attackers used to breach downstream customer systems would have been encrypted during storage and processing. Even when stolen, they would appear as cryptographic gibberish without the private decryption key. Red Hat’s consultants could still authenticate and work with customer systems using encrypted credentials; but hackers with the same stolen data could not. The attack chain breaks immediately.
Customer data remains protected even during breaches. Those 800+ Customer Engagement Reports containing infrastructure details, database URIs, and network configurations? With Seshat, Red Hat consultants could analyze encrypted client infrastructure data, generate encrypted reports, and perform diagnostics, all without ever seeing plain text information. A compromised repository yields only encrypted data that cannot be exploited. Your sensitive infrastructure blueprints stay encrypted even when a network compromise occurs.
The supply chain vulnerability disappears. The traditional security model requires trusting third parties with decrypted data:
Seshat implements zero-trust at the data level. Cloud providers, consultants, and vendors process your encrypted data without ever seeing it unencrypted. Breaching their systems yields only protected data.
As Donoma Software CEO Michael Barry explains: “By eliminating the ‘decrypt to use’ vulnerability, organizations achieve what was previously out of reach: security, performance, and collaboration that is software and CPU agnostic.”
The Business Case: Risk Elimination With Operational Reality
CFOs ask the right question: what’s the ROI on implementing this level of encryption? Start with the Red Hat breach as your baseline. The Centre for Cybersecurity Belgium advised immediate credential rotation across hundreds of organizations—imagine the emergency IT costs alone. Add forensic investigations, legal fees, regulatory fines, customer remediation, and multi-year reputation damage.
Now compare with Seshat, the breach still occurs but yields zero exploitable data. Stolen files remain encrypted, authentication tokens are useless, customer infrastructure stays protected. The incident becomes a manageable security event rather than a supply chain catastrophe.
Beyond breach prevention, Seshat unlocks business capabilities previously constrained by security concerns.
- Financial services firms can leverage cost-effective cloud AI for fraud detection while keeping transaction data encrypted during analysis.
- Healthcare organizations enable multi-institution medical research on encrypted patient records without HIPAA exposure.
- Manufacturing companies share encrypted production data with global suppliers without IP theft risk.
Performance concerns are understandable but now outdated. Early homomorphic encryption implementations were prohibitively slow. Seshat’s architecture delivers speed and scalability on standard CPUs without specialized hardware requirements. The platform is highly horizontally scalable and software-based, integrating with existing enterprise data platforms while preserving applications and years of platform investment. Users perceive no performance degradation.
When Trust Fails, Cryptography Prevails
The Red Hat breach confirms what security researchers have warned for years: perimeter security is imperfect, and data-at-rest encryption is insufficient. Sophisticated attackers breach even well-defended network. The 2025 Salesforce supply chain attack affected 700+ companies through similar development infrastructure compromise. Your competitive advantage now depends on ensuring system breaches yield no data.
Three strategic moves for leadership:
- Audit your “data in use” exposure.
Identify where sensitive data must be decrypted for processing: credentials in code repositories, customer data shared with vendors, regulated information sent to cloud providers, AI training datasets, intellectual property accessed by third-party analytics. These are your Red Hat vulnerabilities, where a breach at your partner becomes your catastrophe.
- Pilot Seshat for highest-risk data flows.
Start with your most sensitive data: authentication tokens, customer PII sent to cloud services, proprietary algorithms, or regulated healthcare/financial information. Seshat deployments are customized for each client, with the team assessing your application structure and security needs to design tailored implementation strategies. Early wins build organizational confidence.
- Reframe security as competitive advantage.
Deployment of privacy-preserving technology increasingly differentiates market leaders. Customers, partners, and regulators recognize organizations that protect data even during breaches. In procurement processes, your ability to process partner data without seeing it unencrypted becomes a decisive advantage. The Belgium cybersecurity advisory told organizations “your vendors’ security posture is now your problem.” Seshat makes you the secure partner others want to work with.
The Red Hat Lesson: Prevention Beats Remediation
Red Hat’s VP of Communications assured stakeholders they have “no reason to believe the security issue impacts any of our other Red Hat services or products.” But the Crimson Collective already accessed customer infrastructure using stolen credentials. The breach expanded beyond Red Hat the moment authentication tokens were compromised. This is the new reality: supply chain breaches cascade, and traditional security’s “decrypt to use” requirement guarantees exposure during operational use.
Seshat’s continuous encryption doesn’t just prevent the initial theft; it breaks the attack chain by making stolen data cryptographically useless. Authentication fails. Infrastructure blueprints remain encrypted. Customer systems stay secure even when consultants’ repositories are breached. The technology transforms breaches from catastrophic events into manageable incidents.
The question isn’t whether your organization will face a security incident; it’s whether stolen data will destroy customer trust, trigger regulatory penalties, and cascade into supply chain disaster. Red Hat’s $100 million lesson is now your strategic advantage. Choose prevention over remediation. Choose continuous encryption over status quo. Choose Seshat over vulnerability.
To learn more about continuous encryption with Donoma Seshat, book a no-obligation demo today.
Frequently Asked Questions
What is a data breach encryption failure and why does it happen?
A data breach encryption failure occurs when an organization’s encryption controls protect data in some states but leave it exposed in others. The most common form is encrypting data at rest and in transit but leaving it decrypted during active processing. Because operational databases and applications run continuously, data is effectively unprotected for the majority of its operational life. Attackers who breach the perimeter find plain-text data that encryption-at-rest never protected, because the application already decrypted it for use.
How did Red Hat’s encryption strategy fail in the 2025 breach?
Red Hat’s breach exposed the decrypt-to-use vulnerability at scale. Authentication tokens, customer infrastructure credentials, and sensitive engagement reports existed in accessible form because consultants and developers needed to work with them. Once attackers breached the GitLab instance, they found credentials in usable form; not because Red Hat lacked encryption, but because the data had to be decryptable to be useful. That requirement created the exposure window. Stolen credentials then cascaded into downstream customer systems at hundreds of organizations.
What is a supply chain breach and why is it harder to defend against?
A supply chain breach occurs when attackers compromise a vendor or partner who has legitimate access to your systems or data, then use that access to reach you. It is harder to defend against because the attacker arrives with valid credentials from a trusted source. Traditional perimeter security cannot distinguish between a legitimate consultant accessing your infrastructure and an attacker using that consultant’s stolen credentials. The only control that stops the cascade is ensuring that stolen credentials yield only encrypted, unusable data.
What is continuous encryption and how would it have changed the Red Hat outcome?
Continuous encryption keeps data encrypted throughout its entire lifecycle, at rest, in transit, and during active processing. With continuous encryption in place, the authentication tokens and customer infrastructure credentials in Red Hat’s repositories would have been encrypted during storage and processing. Even when stolen, they would appear as cryptographic gibberish without the private decryption key. The attack chain breaks immediately: stolen credentials cannot be used to access downstream customer systems because they are not in usable form.
Does continuous encryption affect developer and consultant workflows?
No. Authorized users work as they always have. The encryption operates below the application layer. What changes is what an attacker finds with stolen credentials: encrypted output with no usable value. Red Hat consultants could still analyze client infrastructure data, generate reports, and perform diagnostics using encrypted data. A compromised repository yields only ciphertext that cannot be exploited. The workflow continues; the attack vector disappears.
How should organizations assess their own decrypt-to-use vulnerability?
Start by identifying every location where sensitive data must be decrypted for processing: credentials stored in code repositories, customer data shared with vendors, regulated information sent to cloud providers, AI training datasets, and intellectual property accessed by third-party analytics tools. Each of those is a potential Red Hat scenario: a location where a breach at your partner becomes your liability. The question to ask is: if an attacker compromised each of those systems, what would they find in usable form?
