Encryption at rest
Scrambling stored data, such as other services' passwords, API keys and files, so that someone who copies the database or disk can't read it.
Updated October 2026 · with examples from our own builds
What does encryption at rest mean in practice?
Encryption at rest protects what is stored, as opposed to what travels over the network. Disks and cloud databases often encrypt by default; the stronger form is the application encrypting sensitive fields itself, so even a full database dump shows only ciphertext.
Picture the database leaking and ask what an attacker could use. Customer passwords should be hashed, never encrypted. Credentials your product must use again, such as mailbox passwords or a customer's API keys, should be encrypted with keys kept outside the database.
Key management is the real work: where keys live, how they rotate and what the system does when a key is missing. Encryption with the key stored next to the data protects nothing.
Encryption at rest at a glance
- Protects against
- Stolen database copies and disk images
- Critical detail
- Keys stored apart from the data
- Plan for
- Key rotation without re-encrypting everything at once
Where has encryption at rest come up in our builds?
Every stored secret is encrypted with AES-256-GCM under a per-account key derived with HKDF-SHA256 from a master key that exists only in the server environment. Each encryption uses a fresh IV, payloads carry a version so the algorithm can be rotated, and the server refuses to start if the master key is missing or the wrong length.
Mailbox passwords for the panel's webmail are encrypted with AES-256-GCM, and no mail is stored in the panel's database.
The per-user encryption that crypto-shred is designed to destroy isn't yet in place in the app's backend, so the shred step can't be signed off end to end; the case study lists the gap rather than overstate the protection.
Common questions about encryption at rest
Is my cloud provider's default encryption enough?
It protects against stolen disks, not against someone who can query the database. For credentials and other high-value fields, encrypt them in the application with keys held outside the database.
Should user passwords be encrypted?
No. Store them with a slow password hash such as bcrypt, so even the system can't read them back. Encryption is for data the system has to use again, like a mailbox password.
Related terms
Sources
Planning a product and not sure where encryption at rest fits? Ask us, or browse all 116 terms in the glossary.