Encryption at Rest vs Encryption in Transit

Encryption at rest and encryption in transit are two complementary defenses that protect data at different points in its life. Encryption at rest secures information while it is stored on a disk or in a database; encryption in transit secures it while it moves across a network. Because they address different threats, understanding how each works, and why neither alone is sufficient, is fundamental to designing a secure system.

Two States of Data, Two Threat Models

Data generally exists in three states: at rest (stored), in transit (moving over a network), and in use (loaded in memory and being processed). Encryption at rest and encryption in transit protect the first two, and each targets a distinct attacker.

• Encryption at rest defends against someone who obtains the storage medium: a stolen laptop, a discarded hard drive, a copied database file, or a compromised backup.
• Encryption in transit defends against someone who intercepts the network: an eavesdropper on shared Wi-Fi, a malicious router, or an attacker performing a man-in-the-middle attack.

A system can implement one without the other, which is exactly why they must be considered separately.

How Encryption at Rest Works

Encryption at rest uses fast symmetric cryptography, almost always AES, to encrypt stored data. It appears at several layers:

• Full-disk encryption (FDE) encrypts an entire volume beneath the file system. Technologies in this category protect a device if it is lost or stolen while powered off.
• File- or folder-level encryption protects specific items, allowing different keys for different data.
• Database and application-level encryption encrypts particular columns or records, so sensitive fields stay protected even inside an otherwise accessible database.

The Key Management Challenge

Encryption at rest is only as strong as its key handling. If the decryption key sits on the same disk in plaintext, an attacker who steals the disk gets both. Real systems address this with:

• Envelope encryption, where data is encrypted with a data encryption key (DEK), and that DEK is itself encrypted by a key encryption key (KEK) held in a separate, guarded system.
• Key management services (KMS) and hardware security modules (HSM) that store master keys in tamper-resistant hardware and never expose them directly.

Envelope encryption works roughly as follows:

DEK          = random_key()                 # data encryption key
ciphertext   = AES_GCM_encrypt(DEK, data)    # encrypt the data with the DEK
wrapped_DEK  = AES_GCM_encrypt(KEK, DEK)     # KEK lives in a KMS or HSM
# store ciphertext and wrapped_DEK together; the KEK never leaves the KMS

This structure also makes key rotation inexpensive, because rotating the KEK only requires re-wrapping the small DEK rather than re-encrypting all of the underlying data.

A subtle limitation is that once a system is running and unlocked, data at rest is decrypted for use, so encryption at rest does little against an attacker who already has live access to a running, authenticated system.

How Encryption in Transit Works

Encryption in transit protects data as it travels between systems, most commonly using TLS (Transport Layer Security), the protocol behind HTTPS. A TLS connection is established through a handshake that:

1. Authenticates the server using a certificate, so the client knows it is talking to the real destination and not an impostor.
2. Performs a key exchange, typically ephemeral elliptic-curve Diffie-Hellman, to agree on a shared session key.
3. Encrypts the session with a fast authenticated cipher such as AES-GCM or ChaCha20-Poly1305, protecting both confidentiality and integrity.

Some deployments also use mutual TLS, in which the client presents a certificate too, so both ends authenticate each other rather than only the server. Using ephemeral keys gives the connection perfect forward secrecy, so a later theft of the server's long-term key cannot decrypt previously recorded sessions. Other transit protections include VPNs and SSH, which build encrypted tunnels for broader categories of traffic.

Why You Need Both, and Where the Gap Remains

The two protections are not alternatives; they cover different moments in a data flow. Consider a message sent to a cloud service:

• In transit, TLS stops network eavesdroppers from reading it on the way.
• At rest, disk or database encryption stops someone who later steals the storage from reading it.

Without transit encryption, the message is exposed on the wire. Without rest encryption, it is exposed on stolen media. A complete design applies both.

Yet a gap remains: with only these two protections, the service provider itself can read your data, because it holds the keys and processes plaintext in memory. Closing that gap requires end-to-end encryption, where only the endpoints hold keys, or confidential computing approaches that keep data encrypted even while it is in use inside a hardware-protected enclave.

Key Takeaways

• Encryption at rest protects stored data against stolen disks, databases, and backups, usually with AES-based symmetric encryption.
• Encryption in transit protects moving data against network eavesdroppers and man-in-the-middle attacks, most commonly with TLS.
• They defend different threat models, so a secure system needs both rather than choosing one.
• Encryption at rest depends on strong key management: envelope encryption, KMS, and HSMs keep keys separate from the data they protect.
• Neither hides data from the service provider; only end-to-end encryption or confidential computing addresses data exposed during processing.