Encryption at Rest vs in Transit: What Each Protects Against
Basics4 minInnovialabs editorial team
In short
Encryption in transit (TLS) protects data while it moves across a network; encryption at rest protects it on disks, in databases and backups. You need both, but neither stops an attacker who breaks into the application itself.
The short answer
Data exists in three states: moving across a network, stored on a disk and being processed in memory. Encryption covers the first two, and they are different problems.
- Encryption in transit protects against someone who eavesdrops on or tampers with traffic: public Wi-Fi, an ISP, a compromised router.
- Encryption at rest protects against someone who gets hold of the storage or a file: a stolen laptop, a decommissioned disk, a leaked backup, access to a cloud storage bucket.
One does not replace the other. HTTPS will not help if a database backup sits unprotected in storage, and an encrypted disk will not help if passwords travel the network in plain text.
Where each one applies
| Layer | Type | Example |
|---|---|---|
| Browser to server | In transit | HTTPS (TLS) on the site and API |
| Server to database | In transit | TLS connection to PostgreSQL, MySQL, Redis |
| Between services | In transit | TLS or mTLS inside a cluster, VPN between sites |
| Server or laptop disk | At rest | Volume encryption: LUKS, BitLocker, FileVault, cloud provider disk encryption |
| Database | At rest | Database file encryption (TDE) or an encrypted volume |
| Backups | At rest | Encrypting archives before they go to storage |
| Individual fields | At rest | Field-level encryption for passport numbers, tokens, medical data |
What it does NOT protect against
This is the most important part. Encryption is not a magic shield.
- Application compromise. If an attacker finds an SQL injection or steals an admin account, the application decrypts and serves the data itself. To a running system, an encrypted disk looks like a normal one.
- Leaked keys. If the encryption key sits next to the data — in the same repository, in a plain file on the same server — the protection is nominal.
- Weak passwords and XSS. Encryption does not stop someone logging in as another user or running a script in a user's browser.
- Data in memory. During processing, data is decrypted.
- Logs and temp files. If personal data is written to logs in plain text, database encryption does not cover it.
So encryption is one layer of defence, alongside access control, updates and audits.
A minimal setup for a typical web app
- HTTPS everywhere: a certificate for the domain, a redirect from HTTP, an HSTS header. No mixed content.
- TLS to the database and cache, especially when they run on separate servers or as a managed cloud service.
- Disk encryption on servers and team laptops. Cloud providers usually let you enable it for disks and storage.
- Encrypted backups with a key stored separately from the backups themselves.
- User passwords are hashed, not encrypted, with a slow algorithm (bcrypt, scrypt, Argon2). This is not encryption: the password cannot be recovered, and that is the point.
- Field-level encryption for the most sensitive fields — document numbers, access tokens for third-party services.
- Secrets and keys live in a secrets manager or tightly scoped environment variables, not in code.
Example of checking that a PostgreSQL connection requires TLS:
psql "host=db.example.com dbname=app user=app sslmode=verify-full sslrootcert=ca.pem"
The verify-full mode checks both encryption and the server's identity via its certificate.
Common mistakes
- Assuming "the cloud encrypts everything" and never checking backups, exports and logs.
- Encrypting backups but storing the key in the same bucket.
- Enabling HTTPS on the site while talking to the database over an open network without TLS.
- Encrypting passwords reversibly instead of hashing them.
- Not planning key rotation and recovery: a lost key means lost data.