What is encryption at rest?

Encryption at rest is the encryption of data while it is stored, on a disk, in a database, in object storage or in a backup, so that someone who obtains the stored bytes without the key sees only ciphertext.

The layer decides what it stops

"Encrypted at rest" is a true statement about almost every cloud service, which is why it says little on its own. The OWASP Cryptographic Storage Cheat Sheet lists the levels at which it can happen: "at the application level", "at the database level", "at the filesystem level" and "at the hardware level", and says the right one "will depend on the threat model" (OWASP).

The lower the layer, the narrower the protection. OWASP's own example: hardware-level encryption "is effective at protecting against the physical theft of the server" but "will provide no protection if an attacker is able to compromise the server remotely." The same holds, to a degree, for disk and database encryption: whatever runs above the layer sees decrypted data.

Keys belong somewhere else

Encryption at rest is only as strong as the separation between data and key. OWASP: "Where possible, encryption keys should be stored in a separate location from encrypted data." If the database and the key that opens it are in the same backup, the backup isn't protected.

Common mistakes

• Treating "encrypted at rest" as an answer to "who can read it?" It answers "what if someone steals the storage?"
• Keys next to data, in the same server, volume or backup.
• Forgetting what stays plain. Many systems encrypt values but not names, tags or logs.

What is at rest in Crunu

Values in Crunu are encrypted before they leave your device, so what the server stores is already ciphertext: environment contents encrypted with the environment key, and environment keys sealed to each recipient's public key. This is encryption on the client, the last row of the table above, and it holds whatever the hosting platform does underneath. A full copy of the database gives an attacker ciphertext, public keys, token HMACs, signed documents and metadata, but no values, because the account key is derived from a password and a Secret Key that never reach the server.

Two caveats. Metadata such as project and environment names, email addresses and the audit log is stored in plain form; see metadata exposure. And the server's own .env, with SERVER_KEY, should be stored separately from database backups. How this compares with server-side vaults is in who can decrypt your secrets?.

Sources

• OWASP Cryptographic Storage Cheat Sheet, checked October 30, 2026.