Encryption at Rest and in Transit

Two different threats with two different protections — a stolen disk versus an intercepted network connection — and why encrypting data solves neither problem an authorized process creates once it legitimately decrypts what it was trusted to read.

IntermediateJuly 6, 2026

"Encrypted" is not one property — it is a defense against a specific threat, and a data platform typically needs two different kinds of encryption to cover two genuinely different ones.

Two threats, two protections#

At rest protects data sitting on disk — a database file, a backup, a snapshot. The threat it defends against is physical or logical theft: a stolen laptop, a leaked backup, a misconfigured storage bucket made briefly public.
In transit protects data moving across a network — an API call, a database connection. The threat it defends against is interception: a network positioned between two systems reading traffic as it passes.

Encrypting one does nothing for the other. A perfectly encrypted database file sent over an unencrypted connection is fully readable to anyone who intercepts that connection; a perfectly encrypted connection carrying data that lands on an unencrypted disk leaves that data readable to anyone who later gets the disk.

Symmetric and asymmetric keys, and why real systems use both#

Symmetric-key encryption uses the same key to encrypt and decrypt — fast, and the usual choice for bulk data at rest. Public-key (asymmetric) encryption uses a mathematically related key pair — a public key anyone can use to encrypt, and a private key only the intended recipient holds to decrypt — slower, but solving a problem symmetric keys cannot: two parties who have never met can establish secure communication without first finding a way to share a secret key safely.

Text

[TLS handshake]
1. Client and server use asymmetric keys to agree on a   shared secret, without ever transmitting that secret directly2. Both sides switch to a symmetric key (the agreed secret)   for the actual, much larger volume of data that follows

Transport Layer Security (TLS) — the protocol behind HTTPS and most encrypted database connections — uses exactly this hybrid approach: asymmetric encryption to solve the "how do two strangers agree on a secret" problem once, then fast symmetric encryption for everything after.

Encryption does not replace access control#

An authorized process still sees plaintext

Data encrypted at rest is decrypted the moment an authorized process reads it to serve a legitimate query — at that point, it is ordinary, unencrypted data in memory, and anything that process is willing to do with it (log it, return it to an over-broad caller, cache it somewhere unencrypted) is entirely outside what encryption itself controls. Encryption protects data from someone who should never have had it at all; Access Control Models covers restricting who counts as "authorized" in the first place — the two are complementary layers, and neither substitutes for the other.

Where a data pipeline typically applies each#

Text

At rest:      database storage, backups, object storage buckets,              anywhere data is written to disk between processing stepsIn transit:   API calls (HTTPS), database connections (TLS),              inter-service traffic inside the same network

"It's just internal traffic" is a common reason to skip encryption in transit on connections that never leave a private network — and a common mistake, since an internal network being breached is not a hypothetical; treating every network hop as potentially observable is the safer default.

Common mistakes#

Treating "encrypted" as a complete answer to "is this secure"#

Encryption defends against specific threats — theft of the storage medium, interception on the wire. It says nothing about whether the systems authorized to decrypt the data are themselves trustworthy, correctly scoped, or free of bugs that leak decrypted data elsewhere.

Skipping encryption in transit on "internal" connections#

Internal networks are breached often enough that assuming safety from their boundary alone is a real, recurring source of incidents, not a theoretical risk being over-engineered against.

Storing an encryption key alongside the data it protects#

A key stored in the same location, with the same access controls, as the data it encrypts protects against nothing — anyone who can reach the data can reach the key next to it. Keys belong in a separate, dedicated secrets-management layer, the same principle Configuration and Secrets Management applies to credentials generally.