Encryption at rest vs in transit: what the labels actually mean

Every cloud service’s security page has a sentence like this somewhere: “Your data is encrypted at rest and in transit.” It sounds reassuring. It is also two very specific claims, which together cover less ground than most readers assume. This article explains what each one means, what each one protects you against, and — more importantly — what they do not.

Encryption in transit

When your browser connects to a website over HTTPS, the data moving between your device and the server is wrapped in TLS — Transport Layer Security. TLS does three useful things:

1. Confidentiality. Someone who taps the network — a coffee-shop Wi-Fi attacker, a curious ISP, a state-level eavesdropper — cannot read the contents of the connection.
2. Integrity. They cannot modify the contents mid-flight without the change being detected.
3. Authentication. Your browser can verify that it is really talking to the server it thinks it is talking to, via certificates.

That is what “encrypted in transit” buys you. It is extremely important — it is the reason you can type a password into a website on an airport Wi-Fi without immediately regretting it — and it is also limited. TLS ends at the server. The moment your file arrives on the cloud provider’s side, TLS has done its job and stepped aside.

Modern cloud providers often go further and encrypt connections between their own servers, too — inside their data centers, between regions. That is the bit Google’s whitepapers and AWS’s documentation are usually proud of. It is a good thing. It is also not what most people imagine when they read “encrypted in transit”: most people picture the journey from their laptop to “the cloud”, which is just the first hop.

What “in transit” does not protect against

• Anything that happens on your device before the upload.
• Anything that happens on the provider’s side after the upload.
• A malicious or compromised cloud provider.
• You, accidentally giving someone a shareable link.

Encryption at rest

When your file lands on the provider’s disks, it is written in encrypted form. If someone pulls a drive out of the data center, or compromises the physical infrastructure, the data on the disk looks like noise.

This is almost always done with AES, typically AES-256, in a mode designed for disk encryption. The key that scrambles the data lives in a separate key management service (KMS) belonging to the provider. NIST SP 800-111 goes through the common options for full-disk, volume, and file-level encryption, and the tradeoffs each involves.

Encryption at rest is genuinely useful, and it is not just theatre. It defends against:

• Physical theft of drives or whole servers.
• Drives that leave the data center for recycling or repair, without being wiped first.
• Certain classes of insider threat — for example, a technician who has physical access to hardware but not to the KMS.

What “at rest” does not protect against

Here is where the marketing language can mislead. When the cloud provider needs to serve your file back to you, it has to decrypt it. The provider holds the key. That means:

• The provider can, in principle, read your files. Their own administrators can, constrained by their internal controls.
• A legal order compelling the provider can cause your files to be decrypted and handed over.
• A software compromise at the provider level can expose decrypted data, because the system processing the file has to be able to see it.

“Encrypted at rest” says nothing about who holds the key. That is the question the marketing page is usually glossing over.

Client-side encryption: the thing that changes the picture

If you encrypt the file before it leaves your device, using a key that you (and not the cloud provider) hold, the provider is storing an opaque blob. They can see that you have uploaded a file, how big it is, and when — but they cannot read its contents, because they do not hold the key.

This is what services like Proton Drive, Tresorit, Cryptomator, and Standard Notes do. It is also what you do when you encrypt a file with 7-Zip, VeraCrypt, or age and then drop the encrypted container into Dropbox.

You do not need client-side encryption on everything. You need it on the things where “a subpoena or a breach could expose plaintext” is an unacceptable outcome. For most people, that is a subset of their documents: legal filings, medical records, intimate photos, work-in-progress writing, financial plans. Ordinary cloud storage is fine for the rest.

The Cloud storage topic has a walkthrough for deciding which files need client-side encryption and how to layer Cryptomator on top of Dropbox or Google Drive without disrupting your workflow.

End-to-end encryption

You will also see end-to-end encryption (E2EE). This is the same idea as client-side encryption, applied to communication: messages are encrypted on the sender’s device, and only the recipient’s device can decrypt them. Signal, WhatsApp, iMessage, and (in some modes) ProtonMail do this. The service ferrying the message cannot read it.

For documents, the practical implication is: if you send a sensitive file inside an E2EE messenger, the messenger itself cannot read the file. That is a meaningful upgrade over attaching it to an ordinary email.

A practical rule of thumb

• Every service you use should be “encrypted in transit”. If it is not, stop using it. There is no excuse in 2026.
• “Encrypted at rest” is a floor, not a ceiling. Treat it as the minimum you should expect from any cloud provider, not as a reason to relax.
• For a small subset of your documents — the ones where “the provider could hand over plaintext” is unacceptable — use client-side encryption on top of ordinary cloud storage. You get backups and convenience without giving up the key.

Those three lines, internalized, put you ahead of a lot of people who read vendor marketing pages for a living.