End to end encryption protects your messages. It does not protect your data.
That distinction matters more than most organizations realize. According to IBM’s 2025 Cost of a Data Breach Report, the global average cost of a data breach reached $4.44 million in 2025, with U.S. organizations averaging over $10 million per incident. The phrase was conscripted by vendors and incorrectly applied to data security, causing longstanding misunderstandings of data security postures.
We’ll break down how the phrase “end to end encryption” has become misunderstood: why it is only accurate in the context of messaging apps, and why applying it to enterprise data security is perpetuating a significant misunderstanding that enables ongoing data loss. If you want the full picture of what those misunderstandings cost, start with The Encryption At Rest Myth.
Why Disk Encryption Is Not the Answer You Think It Is
Before we get to end to end encryption, there is another technology that needs clarification: disk encryption.
Full disk encryption is widely deployed and widely misunderstood. The misunderstanding is this: organizations implement disk encryption and believe their data is protected as long as it exists on that disk. It is not. Not in the way that matters.
Disk encryption protects the physical storage medium. It is excellent at one specific job: preventing someone from reading your data if they steal the hardware. A laptop left in an airport. A decommissioned server sold without proper wiping. A hard drive pulled from a data center rack. In those scenarios, disk encryption works exactly as intended.
The moment the system boots, the drive mounts, and the operating system loads; the disk decrypts. Everything on it becomes accessible to any authorized application running on that system. A ransomware attacker who compromises credentials and logs in remotely is an authorized application as far as disk encryption is concerned. A nation-state actor with persistent network access finds a fully decrypted filesystem waiting for them. Hackers do not need to defeat disk encryption. Once they are in the system, disk encryption protects nothing from them.
Disk encryption is a control for physical theft. It is not a control for network-based attacks, credential compromise, or insider threats. The scenarios that produce large, consequential breaches are all network-based. Disk encryption addresses almost none of them once the system is running.
Where “End to End Encryption” Delivers on its Promise
End to end encryption was designed to solve a specific problem: protecting a message while it travels from one person to another. When you send a message on Signal or WhatsApp, that message is encrypted on your device, travels across the internet as unreadable ciphertext, and only decrypts on the recipient’s device. Nobody in the middle can read it. Not the app company. Not your internet provider. Not a hacker who intercepts the traffic. The encryption holds for the entire journey. That is a genuinely elegant solution to a genuinely hard problem. And for messaging, it works.
The problem is what happens when marketers conscripted the language (incorrectly) and people came to believe it accurately describes their data security posture.
Data Exists in 3 States. Today’s Encryption Misses 1 of Them Completely.
Data does not just sit in one place doing nothing. It moves through three distinct states, and each one has different exposure characteristics.
At rest: data sitting in a database, a file system, a storage location. Not being accessed. Not moving. Many encryption tools address this state well. Your database encryption, your disk encryption, your cloud storage encryption all can protect data well at rest.
In transit: data moving from one place to another. Across a network, between servers, from a database to an application. TLS (Transport Layer Security) encryption secures data in transit. It is the industry-standard protocol that protects data as it travels across a network. This is the state the security industry has spent thirty years solving. It is largely solved.
In use: data used by an active application. A query runs. A report generates. An AI model performs an inference. A compliance officer runs a search. When a system is live, so is its data. The system decrypts the data and exits the protection of encryption entirely. It exists in plain text in memory, in the processing layer, in the application. Every application that reads data to do something useful with it decrypts that data to do so.
“End to end encryption,” when applied to data other than communications, is really only encryption at the “ends” of the data lifecycle: when it is in transit and at rest. Unfortunately, data stays active the vast majority of its lifespan and is therefore currently unprotected and vulnerable to the continuous stream of breaches and data loss.
The “Decrypt to Use” Threat Vector
Here is the mechanism behind every significant enterprise data breach in the last decade. An attacker does not need to break your encryption. They do not need to crack your keys, defeat your algorithms, or do anything technically sophisticated at the cryptographic layer. They just need to reach your data during the window when your own applications have already decrypted it.
That window is always open. Every time a nurse pulls a patient record. Every time a financial analyst runs a report. Every time an e-discovery workflow searches an archive. Every time an AI tool processes customer data. The application decrypts the data so it can work with it. An attacker who reaches the system during that moment finds the same plain text the application finds.
This is not a flaw in a particular security product. It is a fundamental characteristic of how computing and standard encryption have been designed to work as efficiently as possible. The “decrypt to use” security vector is not a bug. It is the architecture.
Securing Data in Use with Continuous Encryption
When organizations start to understand the data-in-use problem, someone on the security team often mentions fully homomorphic encryption (FHE). FHE allows computation on encrypted data without decrypting it. If you want to go deeper on this, Fully Homomorphic Encryption Is Too Slow. Now What? covers why FHE is theoretically powerful and practically limited at enterprise scale.
In production use, FHE has a problem. It is extraordinarily computationally expensive. Operations that run in milliseconds on standard data can take minutes or hours on FHE-encrypted data. At enterprise scale, with production workloads, FHE creates latency that makes it operationally impossible for most use cases. This is not a temporary limitation waiting for better hardware. It is a fundamental mathematical characteristic of the technology.
So when organizations evaluate FHE, discover the performance penalty, and conclude that data-in-use encryption is not yet practical; they are right about FHE. They are wrong about the new ways in which data can stay continuously encrypted across all three states of data.
Donoma has pioneered a continuous encryption platform (Seshat) that delivers on the promise of FHE without all the penalties. It does not rely on the same mathematical approach. It does not carry the same performance penalty. It is a different architecture that achieves the same outcome: data that stays encrypted while applications work with it, without the computational overhead that makes FHE impractical at scale.
The distinction matters because the objection “we looked at homomorphic encryption and it was too slow” is no longer a valid objection to continuous encryption. They are not the same thing. Evaluating FHE and ruling out continuous encryption is like test-driving a semi-truck and concluding that personal transportation is impractical.
Deploy Encryption Without Replacing Your Infrastructure
The other objection that emerges in early conversations is architectural. Organizations assume that protecting data during active processing requires rebuilding the application, replacing the database, or inserting new infrastructure at multiple layers of the stack. A project that sounds like it takes years and costs a fortune before it protects a single record.
It does not have to be that way.
Seshat’s continuous encryption deploys at the application layer. It sits between the application and the data. The database/data store does not change. The application does not change. The infrastructure does not change. The encryption layer intercepts data before it writes to the database and encrypts it; and intercepts the query result before it reaches the application, decrypting it for the authorized session while keeping the underlying record encrypted.
What changes is what an attacker finds if they reach the database during an active processing session. Instead of plain text records, they find ciphertext. The application works normally. The authorized user sees their data on the screen as usual. The attacker finds nothing they can use.
Critically, Seshat never decrypts the underlying record. The data store always holds ciphertext, full stop. The application layer establishes a dynamic, secure connection between the data store and the authorized screen, similar in concept to a proxy, and decryption happens only within that rendered view, for that session. There is no decrypted dataset sitting in application memory for an attacker to find. Compromising a session exposes what is visible on one screen at one moment, not the underlying database.
Seshat is a continuous encryption platform built on this architecture. It runs on standard CPUs with no specialized hardware requirement. It deploys at the application layer without replacing existing database infrastructure. It runs with only milliseconds of added latency and is post-quantum ready; which matters for organizations protecting data whose sensitivity extends beyond the current threat horizon. For a deeper look at how it compares to the FHE alternatives, see Homomorphic Encryption Alternatives: What Works at Enterprise Scale.
The application of terminology we routinely see as “end to end encryption” is a misappropriation of technology to make people feel comfortable about their application purchase. It made people feel so comfortable that they didn’t realize they were being promised an outcome that did not exist, until now.
One question to take to your security team: when your database is running and an application executes a query, is that data encrypted at that moment? If the answer is no, or if they are not sure, you are carrying the exposure described here.
If you want to understand what closing that gap looks like for your specific environment, book a solution briefing with the Donoma team.
The technology is ready. The business case is clear. The time for action is now.
Frequently Asked Questions
Does disk encryption protect enterprise data from breaches?
Disk encryption protects data on a physical storage medium from being read if that hardware is stolen or improperly decommissioned. It does not protect data once the system boots and the drive mounts. At that point, every authorized application has access to decrypted data; so does every attacker operating through compromised credentials or persistent network access. The scenarios that produce large enterprise breaches are network-based, not physical. A ransomware attacker, a nation-state actor with persistent access, or a malicious insider all arrive after the disk has already decrypted. Disk encryption does not stop any of them.
What is “end to end encryption” and what does it actually protect?
End to end encryption protects communications data in transit between two endpoints. When you send a message on Signal or WhatsApp, it encrypts on your device and only decrypts on the recipient’s device. Nobody in the middle can read it. End to end encryption was designed for this specific use case and does it well. What it does not protect is data at the point of use. That is when an application, database query, or analytics workflow actively processes that data. That processing window is where enterprise data breaches happen.
What are the three states of data and which ones does encryption actually cover?
Data exists in three states. At rest: sitting in a database or file system, not being accessed. In transit: moving across a network between systems. In use: actively being processed by an application; a query running, a report generating, an AI model performing inference. Standard encryption covers at rest and in transit reasonably well. The industry has spent thirty years solving those two states. Data in use is the third state. It remains largely unprotected by standard encryption approaches.
What is the decrypt to use vulnerability?
The decrypt to use vulnerability is the architectural requirement that standard encryption imposes: data must decrypt before any application can process it. Every query, every report, every analytics run creates a decryption event. During that event, data exists in plain text in memory and the processing layer. An attacker who reaches a system during active processing finds readable data regardless of how strong the encryption is at rest or in transit. This is not a flaw in any particular security product. It is a fundamental characteristic of how standard encryption and computing work together.
What is the difference between continuous encryption and fully homomorphic encryption?
Fully homomorphic encryption (FHE) allows computation directly on encrypted data using complex mathematical operations. It theoretically closes the decrypt to use gap but carries a severe performance penalty. Operations that run in milliseconds on standard data can take minutes or hours on FHE-encrypted data. Continuous encryption is a different architecture that achieves data-in-use protection without the FHE performance penalty. It does not use the same mathematical approach. Ruling out continuous encryption because FHE was too slow is like ruling out personal transportation because a semi-truck was impractical.
Does deploying Seshat’s continuous encryption platform require replacing existing infrastructure?
No. Seshat deploys at the application layer, sitting between the application and the database. The database does not change. The application does not change. The infrastructure does not change. The encryption layer intercepts data before it writes to the database, encrypts it, and intercepts query results before they reach the application, decrypting them for the authorized session while keeping the underlying record encrypted. What changes is what an attacker finds during active processing: ciphertext instead of plain text.
Does Seshat ever decrypt the underlying data record?
No. The data store always holds ciphertext. Seshat establishes a dynamic, secure connection between the data store and the authorized user’s screen, similar in concept to a proxy, and decrypts only the rendered view for that session. There is no decrypted dataset sitting in application memory.
Why does end to end encryption not prevent enterprise data breaches?
End to end encryption protects communications data in transit. Enterprise data breaches happen at the point of use. That is when data decrypts for processing. An attacker does not need to defeat encryption algorithms or steal keys. They need to reach the system during the window when the application has already decrypted the data. That window opens every time any authorized user accesses data for any legitimate purpose. End to end encryption closes the transit window. It does nothing for the processing window. Until the processing window is closed with continuous encryption, breaches will continue.
Additional Reading:
The Encryption At Rest Myth: Why Your Encryption Strategy Fails to Protect Data
Fully Homomorphic Encryption Is Too Slow. Now What?
Homomorphic Encryption Alternatives: What Works at Enterprise Scale
How Much Does a Data Breach Really Cost?
