Every product page says “encrypted“. Almost none of them say which kind. That word covers two completely separate things. One protects your data while it travels across a network. The other protects it once it lands on a disk somewhere. They stop different attackers, at different moments, and having one tells you nothing about whether you have the other.
I build a local first email client, so I spend a lot of time thinking about the second one. Here is what actually separates them, and why the gap between the two is where most real breaches happen.
The Short Answer
Encryption in transit protects data while it moves. Encryption at rest protects data while it is stored.
Think of a letter going to a mailbox:
In transit is the armored van on the road. Nobody driving alongside can read what is inside. Intercept the van and you get a sealed container you cannot open. The moment it reaches the mailbox, the van’s job is done.
At rest is the lock on the mailbox itself. It matters after the letter stops moving, which is where it will sit for months or years. Someone can pry the door open and reach inside, and what they pull out is still unreadable without the key.
The van does not protect the box. The box does not protect the road. A system with only transit encryption has armored delivery to an unlocked container.
What Does Encryption in Transit Mean?
Data in transit is data moving across a network. Your browser talking to a server. Your mail client fetching messages over IMAP. A backup client uploading to a cloud bucket. The mechanism is almost always TLS, Transport Layer Security. That is what the padlock in your address bar means, and it is what wraps the IMAP and SMTP connections your email client opens. The standards here moved recently, and it is worth knowing where things stand. TLS 1.0 and 1.1 were formally deprecated in RFC 8996 back in March 2021 and pushed to historic status. TLS 1.3 arrived in RFC 8446 in 2018 with a one round trip handshake, no legacy cipher suites, and mandatory forward secrecy. Then in July 2026 the IETF published RFC 9846, which replaces RFC 8446 as the TLS 1.3 spec and also obsoletes RFC 5246, the original TLS 1.2 document.
Adoption caught up. Qualys SSL Pulse measured TLS 1.3 support on 75.3 % of the top 150,000 sites as of June 2025, and roughly 90 % of browsers negotiate it when the server allows.
What this buys you is protection against anyone sitting between two endpoints. Coffee shop Wi-Fi. A compromised router. An ISP inspecting traffic. That threat is real, and TLS handles it well. What it does not do is follow your data past the endpoint. Once the bytes are written to disk, TLS is finished.
What Does Encryption at Rest Mean?
Data at rest is data written to storage. Databases, log files, caches, backups, that synced folder you forgot was syncing.
This is not a marketing category, by the way. NIST defines data at rest as information that is neither being processed nor transmitted, sitting instead on storage media. NIST SP 800-175B Revision 1, the federal guideline for applying cryptography, is built around exactly this split: protecting information during transmission, and protecting it in storage. Stored data gets its own control, SC-28, in NIST SP 800-53. Different threat, different control, different section of the standard.
In practice you encrypt at rest with symmetric crypto, usually AES from FIPS 197. That happens at one of two levels, and the difference between them matters more than most people realize.
Full Disk Encryption vs Application Level Encryption
Full disk encryption, meaning BitLocker on Windows or FileVault on macOS, encrypts the whole volume. Great when the laptop is powered off or locked.
Here is the part that trips people up: Once you log in and the volume mounts, everything is plaintext to the operating system and to every process running under your account. Full disk encryption protects against a stolen laptop. It does not protect against anything running on your machine while you are using it.
Application level encryption is narrower. One database file, its own key, still encrypted while you are logged in and working. That distinction is the whole reason it exists.
Why the Gap Between Them Matters
Look at the timeline of any piece of data: An email crosses the network in a few hundred milliseconds. Then it sits on your disk for the next three years. Transit is the short, dramatic part. Rest is where your data actually lives.
Now look at how data actually gets exposed. A laptop taken from a car. A backup drive nobody can find. A server decommissioned without a wipe. A shared folder shared with more people than intended. Malware reading files under your user account. A storage bucket left open to the internet.
Not one of those is a transit problem. The van already arrived safely every single time. The only question that changed the outcome was whether the box was locked.
Verizon’s Data Breach Investigations Report has said the same thing year after year. Stolen credentials, misconfiguration and physical loss drive a large share of confirmed breaches. Intercepting properly encrypted traffic on the wire barely registers by comparison. The attackers moved to the destination a long time ago. A lot of security thinking has not.
What Encryption at Rest Does Not Fix
This gets oversold constantly, so here are the limits:
Data in use is still exposed. To process data you have to decrypt it in memory. Someone with code execution on your unlocked machine can often read it right there. Confidential computing chips away at this. It is not a solved problem.
Key management is where implementations die. Store the key next to the data with nothing protecting it and the encryption is theater. Keys should come from a user secret or live in hardware like a TPM or Secure Enclave. Nobody gets breached because AES failed. They get breached because of how the key was stored.
Metadata leaks anyway. File sizes, timestamps, folder structure, access patterns. Encrypted contents, visible shape.
Your operating system keeps copies you never approved. Search indexes, swap files, crash dumps, thumbnail caches, automatic backups. Any of these can end up holding plaintext pulled out of your data. This is the strongest argument for encrypting at the application layer rather than trusting the disk layer alone. If the database file itself is encrypted, an index that reaches it reads ciphertext. A backup that uploads it uploads ciphertext.
Why This Hits Local First Software Differently
Where your data sits changes which of the two you should care about:
In a cloud app, your data rests on the vendor’s infrastructure. Their at rest encryption protects against certain failures on their end, but they hold the keys. They can read your mail when they need to, for search, for support, for a court order.
In local first software, your data rests on your machine. No vendor holding keys, which is a real privacy win. It also means the security of that stored copy is entirely a question of how the app stores it. Transit encryption covers a few seconds per sync. Everything else, all day, every day, is at rest.
That is why YouniqMail supports encrypting its local database. Mail comes in over IMAP inside a TLS connection, which handles the road. The local store can then be encrypted, which handles the box. Two mechanisms, each doing the job the other cannot.
The Four Questions to Ask
Next time a product tells you it is “encrypted“, ask these.
Is it encrypted while moving? Is it encrypted while stored? Who holds the keys? And is the stored encryption at disk level or application level, meaning does it still hold up while the machine is unlocked?
The word encrypted tells you almost nothing on its own. Those four answers tell you nearly everything.
Frequently Asked Questions
Is HTTPS encryption at rest or in transit?
In transit only. HTTPS protects data while it moves between your browser and a server. Once it arrives and gets written to storage, HTTPS is out of the picture. Protecting it there takes a separate mechanism.
Do I need both encryption at rest and encryption in transit?
Yes. They stop different attackers at different stages. Transit encryption blocks interception on the network. Rest encryption blocks whoever gets hold of the drive or the file. Neither one covers for the other, and most security frameworks require both.
Does full disk encryption count as encryption at rest?
It counts, with a catch. BitLocker and FileVault protect a device that is powered off or locked. After you log in and the volume mounts, the OS and every process under your account read plaintext. Application level encryption keeps working in that state.
What is the difference between encryption at rest and end to end encryption?
They answer different questions. Encryption at rest is about where the data is protected, meaning in storage. End to end encryption is about who holds the keys, meaning only the people communicating and not the provider in the middle. A cloud service can encrypt at rest while still holding your keys. End to end specifically shuts the intermediary out.
Is my email encrypted at rest by default?
On the provider side, usually yes, but with keys they control, which is how they scan and index your mail. On your own device it depends entirely on the client. Plenty of mail apps drop messages into a local database with no encryption beyond whatever full disk encryption the OS provides, which means any process running as you can read the local copy once you are logged in.
Which encryption algorithm is used for data at rest?
AES, almost always. Specified in FIPS 197, typically with a 256 bit key in an authenticated mode like GCM. Authenticated modes cover integrity as well as confidentiality, so stored data cannot be quietly altered either.