Encryption at Rest vs Encryption in Transit

Encryption at rest protects data while it’s stored — on a disk, in a database, in a backup — so that anyone who gets hold of the physical or logical storage medium still can’t read it without the key. Encryption in transit protects data while it’s moving between two points over a network, so anyone intercepting the traffic sees only ciphertext. They solve different threat models, and a system that only implements one of them still has a wide-open gap.

Two different attackers

Encryption at rest defends against an attacker who gets access to storage itself: a stolen laptop, a decommissioned hard drive that wasn’t wiped, a cloud storage bucket misconfigured to be public, or an attacker who has breached a server and is reading files directly off disk. If the data is encrypted at rest and the attacker doesn’t have the key, the raw bytes are useless to them.

Encryption in transit defends against an attacker positioned somewhere on the network path — a compromised Wi-Fi hotspot, a malicious router, an ISP, or anyone running a man-in-the-middle attack. Without transit encryption, that attacker can read (or tamper with) every request and response as it crosses the wire, even if the data sits encrypted at both endpoints.

These are independent protections. Data encrypted at rest is decrypted in memory before it’s sent anywhere, so if it then travels over plaintext HTTP, the encryption-at-rest work is irrelevant to that leg of the journey. The reverse is also true: TLS protects data in flight, but once it lands on a server’s disk unencrypted, a storage-level breach exposes it in full.

How each is typically implemented

At rest:

• Full-disk or volume-level encryption (common on cloud block storage — the storage layer transparently encrypts and decrypts, invisible to the application).
• Database-level encryption, either transparent data encryption at the storage engine level or column/field-level encryption for specific sensitive fields.
• Application-level encryption, where the app encrypts a value before writing it, using keys it manages itself — the strongest option, since a database compromise alone doesn’t expose plaintext, but it also means the app has to handle key management correctly.

In transit:

• TLS for HTTP traffic — see how HTTPS works for the full handshake and certificate chain.
• mTLS for service-to-service traffic where both sides need to authenticate each other, common inside microservice meshes.
• VPNs or private network links for traffic that shouldn’t traverse the public internet at all, discussed more in what a VPN is.

At rest vs in transit

	Encryption at rest	Encryption in transit
Protects against	Storage/disk theft, backup exposure	Network interception, MITM attacks
Typical mechanism	Disk/volume encryption, DB encryption	TLS/mTLS
Where it applies	Data sitting on disk, in a database, in backups	Data moving between client, server, and services
Protects a live, decrypted process?	No — data is plaintext in memory when in use	No — only covers the network hop
Common failure mode	Unencrypted backups or misconfigured buckets	Falling back to plaintext HTTP, expired certs

The gap both leave: data in use

Neither category protects data while it’s actively being processed in memory — a running application has to decrypt data to operate on it, and at that moment it’s plaintext in RAM. This is the gap that techniques like confidential computing and hardware-backed enclaves aim to close, though for most applications the realistic mitigation is smaller blast radius: minimize what’s held in memory, avoid logging sensitive fields, and treat process memory dumps and core dumps as a real exposure risk, not just a debugging convenience.

Key management is the part that actually matters

Encryption is only as strong as how the keys are handled. Storing an encryption key next to the data it protects — in the same database, the same config file, the same disk — defeats most of the point, since anyone who steals the data likely also gets the key. Dedicated key management services, hardware security modules, or a TPM for device-level keys exist specifically to keep keys separated from the data and to support rotation without re-encrypting everything from scratch. This is also where hashing and encryption get confused — encryption is reversible by design (that’s the point, you need the plaintext back), while hashing for things like passwords is deliberately one-way.

The takeaway

Encryption at rest and encryption in transit protect against two different attackers — one who steals storage, and one who intercepts network traffic — and neither substitutes for the other. A production system needs both by default: TLS everywhere data moves, and encryption (ideally with well-managed, separated keys) everywhere data sits. The remaining gap is data in active use in memory, which is a harder problem and, for most applications, best handled by minimizing what sensitive data touches memory in the first place rather than trying to encrypt around it.