Data Encryption Explained: At Rest, In Transit, and In Use

"The data was encrypted" answers the wrong question

After a breach, "the data was encrypted" is the sentence everyone hopes to say. But on its own it means almost nothing, because data exists in three different states, and encryption in one does nothing for the others. Data sitting on a disk, data moving across a network, and data loaded into memory while an application processes it face entirely different threats — and are protected by entirely different mechanisms. An organization can encrypt its databases at rest, encrypt every connection in transit, and still expose plaintext the moment the data is decrypted to be used.

Understanding encryption means understanding the three states of data and what each form of protection actually defends against. Just as important, it means understanding that the encryption algorithm is rarely the weak point — modern ciphers like AES-256 are not the thing attackers break. Key management is where encryption programs succeed or fail. The whole model reduces to a simple idea: convert readable data into unreadable ciphertext with a key, so that stealing the data without the key is worthless. Everything hard is about protecting, distributing, and controlling those keys.

The three states, and the gap in the middle

Each state maps to a distinct threat and a distinct control. The table below frames them; the sections that follow explain the important nuances.

The critical insight in that table is the gap in the middle row of the lifecycle. Data at rest and in transit are well-solved problems with mature, ubiquitous tooling. Data in use — decrypted into memory so an application can actually do something with it — is the state that has historically been unprotected, and it is exactly where an attacker with a foothold on the host does their work. Most breaches do not involve cracking encryption at all; they involve stealing data when it is legitimately decrypted for use, or stealing the keys.

At rest: protecting the stored copy

Encryption at rest protects data written to persistent storage — disks, databases, backups, object storage. Its threat model is loss of the physical or logical medium: a stolen laptop, a decommissioned drive that was not wiped, an exfiltrated backup file, a copied cloud snapshot. If the storage is encrypted and the key is not on the medium, the stolen copy is unreadable noise.

The nuances that matter in practice:

• Layers of granularity. Full-disk encryption protects against physical theft but does nothing once the system is running and the volume is mounted — to a logged-in process, the data is plaintext. File- and column-level or application-level encryption protects specific sensitive data even from other processes on the same running system, at the cost of more complexity.
• The key location is the whole game. Encryption at rest only helps if the key is stored separately from the data it protects. A database encrypted with a key sitting in the same environment, readable by the same compromised account, provides little real protection against an attacker who already owns that environment.
• "Encrypted at rest" is often the floor, not the ceiling. Cloud providers encrypt storage by default, which defends against their hardware being stolen — but not against an attacker using your valid credentials to read the data through the normal API, where it is served decrypted.

At rest is necessary and cheap. It is also the state that gives the most false comfort, because it does nothing against the credential-based attacks that cause most breaches.

In transit: protecting data on the move

Encryption in transit protects data as it crosses networks — between a browser and a server, between microservices, between your environment and a SaaS provider. The threat is interception: an attacker positioned on the network path eavesdropping or manipulating traffic (a man-in-the-middle). TLS is the workhorse, and it has become close to universal for a reason.

Where in-transit encryption goes wrong is usually in the details, not the algorithm:

• Certificate validation. TLS only defends against man-in-the-middle if the client actually verifies the server's certificate. Disabled or improperly validated certificates — common in rushed internal integrations — silently defeat the protection.
• Internal traffic often runs in the clear. Organizations encrypt external connections diligently and leave east-west traffic between internal systems unencrypted, trusting the network perimeter. A zero-trust posture assumes the internal network is hostile and encrypts internal traffic too.
• Version and cipher hygiene. Old TLS versions and weak cipher suites are exploitable; keeping the configuration current is ongoing maintenance, not a one-time setup.

In transit is well understood and largely solved where it is actually applied — the failures are gaps in coverage and misconfiguration, not broken cryptography.

In use: the state that is finally getting solved

For decades, protecting data while it is being processed was accepted as impossible — to compute on data, you had to decrypt it, and decrypted data in memory was fair game for anyone who compromised the host. Confidential computing is closing that gap. It uses hardware-based trusted execution environments (TEEs) — secure, isolated enclaves inside the processor — to keep data encrypted even in memory, decrypted only inside a protected region the host operating system and hypervisor cannot read. Even an attacker who compromises the underlying server, or a cloud provider's own administrators, cannot read the plaintext inside the enclave.

This matters most for the scenarios where sensitive data must be processed in an environment you do not fully trust — shared cloud infrastructure, or collaborative analytics where multiple parties want to compute over combined data without exposing their raw inputs. Related techniques such as homomorphic encryption (computing directly on ciphertext) remain largely specialized and performance-limited, but confidential computing is production-viable today for the right workloads. It is not yet a default the way at-rest and in-transit encryption are, but it is the state to watch, because it addresses the exact point in the data lifecycle where most protection has historically evaporated.

Key management decides everything

Every point above converges on the same truth: encryption is only as strong as the management of its keys. An attacker does not break AES — they find the key, or they wait until the data is decrypted for legitimate use. A robust key management practice is what turns encryption from a checkbox into a control.

• Separate keys from data. Keys must not be stored alongside, or accessible through the same credentials as, the data they protect. Dedicated key management services and hardware security modules exist to enforce that separation.
• Rotate and revoke. Keys should be rotated on a schedule and revocable immediately if compromise is suspected, so a stolen key has a limited useful life.
• Control and audit access. Who and what can use a key to decrypt should be tightly scoped and fully logged. Key usage is one of the highest-value audit trails you have.
• Decide who holds the keys. In cloud, customer-managed keys give you control and the ability to cut off access, at the cost of operational responsibility. This choice has direct compliance and data-sovereignty implications.

Strong key management is also what makes encryption count toward regulatory obligations — many frameworks treat properly encrypted data whose keys were not compromised as effectively unexposed, which is why key custody is a security compliance question as much as a technical one.

Where to start

Get the fundamentals universal first: encrypt data at rest everywhere, enforce TLS on every connection including internal east-west traffic, and fix the quiet failures — disabled certificate validation, legacy cipher suites, keys stored next to the data they protect. Then invest where the real leverage is: centralize key management with proper separation, rotation, and audit, because that is the difference between encryption that protects you and encryption that only looks good in a policy. Evaluate confidential computing for the specific workloads that process sensitive data in untrusted environments.

intSignal helps design encryption and key management as part of a broader data protection and data loss prevention strategy — covering all three states, with key custody and audit that stand up to a compliance review. Talk to our security team and we will help you find where your data is actually exposed today, encrypted label or not.