Encryption at rest is a standard requirement. It shows up on compliance checklists, passes audits, and gives security teams a defensible answer when the board asks about data protection.
It also protects data in exactly one scenario: a powered-off disk that someone physically walks off with.
That is not how breaches happen.
Your Data Is Never Actually at Rest
The term “encryption at rest” implies a data state: data sitting quietly on a disk, going nowhere, doing nothing. In theory, encrypting that disk protects the data if someone walks off with the hardware.
Here is the problem: operational databases that power your applications are almost never in that state. From the moment an application starts at system boot, it enters an active, in-use condition that persists until the system is powered completely down. Something that production environments are designed to prevent.
Even when no user query is running, the database is still working. It is managing buffers, running maintenance operations, updating system catalogs, handling log management. The system is on. The data is accessible. The encryption that protects the disk at rest has already been removed so the engine can operate.
This is not a edge case. It is the normal state of every database in your organization, around the clock.
Why Disk Encryption Doesn’t Solve This
“But we have full disk encryption.” Most organizations do. It is a reasonable control for a specific and narrow threat: someone physically removing a storage device from a powered-off machine.
The moment the operating system mounts that encrypted disk (a prerequisite for the database to function) the protection disappears. The database engine must decrypt the files to operate. Any process or user with appropriate system privileges can now access that data. Disk encryption offers no protection for a running database; which is to say, it offers no protection for your database during the 99.9% of its life when it is actually doing its job.
The TDE Problem Is Worse
Transparent Data Encryption (TDE) and similar database-native “encryption at rest” features create a more dangerous illusion, because they sound more targeted. They encrypt individual database files on disk. They are widely certified. They show up well in audit reports.
They also decrypt data automatically when it is loaded into database memory. Which means:
All data accessed by the database engine exists in unencrypted form in memory. Database administrators have access to cleartext data. Query results, temp tables, and cached data are unprotected. Logs frequently contain sensitive data in plaintext.
Sophisticated attackers understand this. They do not target encrypted files on disk. They target running systems where the encryption has already been removed for operational purposes. The data is sitting in memory, in cleartext, waiting.
The Window Is Always Open
To understand the actual exposure scope, consider when a database is functionally vulnerable under conventional encryption approaches:
Whenever the database service is running. When any application is connected. When administrator tools are open. When automated processes are executing. During backup and replication operations.
In a production environment, that window is open continuously. Encryption at rest addresses one narrow threat; data in use is the actual problem, and conventional approaches leave it completely unaddressed.
What Actually Closes the Gap
Protecting data during active use requires encryption that persists through the entire data lifecycle: at rest, in transit, and while the database engine is actively operating on it. Not encryption that is applied and then removed the moment work begins.
This is what continuous encryption solves. Rather than encrypting the storage container and then decrypting the contents for use, continuous encryption maintains protection throughout query processing, analytics, and every other database operation. Administrators can maintain systems without ever accessing cleartext. Exfiltrated data is worthless; it was never decrypted in the first place.
The compliance box that says “encrypted at rest” can still be checked. It just can no longer be treated as the end of the conversation.
The Bottom Line
Every major breach that has made headlines in the past several years shared a common characteristic: the attacker gained access to data in use and therefore wide open from the moment the system was running. This is the same vulnerability that exposed 10.5 million Conduent customers to class action litigation.
Encryption at rest is a necessary floor. It is not a ceiling, and treating it as one is what produces the steady drumbeat of breach disclosures that land in your inbox every week.
If your encryption strategy stops at the storage layer, your data is exposed for the majority of its operational life. The gap is well understood. The technology to close it exists.
The question is whether your organization will close it before an attacker finds it first.
Donoma’s Seshat platform maintains continuous encryption throughout the data lifecycle, including while data is actively in use. If you want to understand what closing the data-in-use gap looks like for your environment, schedule a briefing today.
Frequently Asked Questions
Why does encryption at rest fail to prevent data breaches?
Because up until now, data could not be encrypted and processed at the same time. To run, your database decrypts your data. That window is where attackers work; it has nothing to do with how strong your perimeter is.
What is the encryption gap?
The encryption gap is the exposure that exists when data is actively being used. Traditional encryption covers two of the three states data exists in: at rest and in transit. The third state, data in use, has been the open door. Most breaches walk right through it.
What is data in use vulnerability?
It is the period when your encrypted data becomes cleartext so your systems can process it. During that window, anyone with access to the system can read it; and in a breach, that includes the attacker. The lock works fine until the door is opened, often by personnel with legitimate credentials.
What is continuous encryption?
Continuous encryption keeps data encrypted across all three states: at rest, in transit, and in use. It eliminates the decrypt-to-use requirement. The data never becomes cleartext, even during active processing; which means a breach produces nothing usable.
How is continuous encryption different from encryption at rest?
Encryption at rest protects data when your system is off. For most organizations, that means it provides very little protection; production databases run continuously. Continuous encryption works while the system is running.
Does disk encryption protect a running database?
No. The protection ends the moment your operating system mounts the disk to run the database. It is designed for a powered-off system. Any process or user with system access can reach the data once it is operational.
What encryption protects data during active processing?
Continuous encryption, sometimes called encryption in use or Fully Homomorphic Encryption (FHE). Donoma Seshat is built specifically for this: enterprise data systems that cannot stop running, and cannot afford to expose data when they do.
Related Reading
Data Encryption: Understanding the Often Unseen Vulnerability You Must Avoid
