Safeguard
Security Guides•

Encryption at rest: disk, database or application level?

Disk, database and application level encryption defend against different threats. A decision guide for choosing by threat model, not by checkbox.

Safeguard Security Team
3 min read

Pick the level of encryption at rest by the threat you are defending against. Disk or volume encryption protects against lost or stolen storage. Application level encryption also protects against someone who can query your database. OWASP says the right level depends on the threat model.

Three common levels

OWASP's cryptographic storage guidance says encryption can be applied at the application, database, filesystem or hardware level, depending on the threat model. NIST SP 800-111, written for end user devices, groups storage encryption into full disk encryption, volume and virtual disk encryption, and file or folder encryption.

What each one defends against

  • Full disk or volume. Helps against: Stolen laptop, discarded drive, copied raw storage. Does not help against: A logged in user or running process reading files.
  • Database level. Helps against: Stolen database files or backups. Does not help against: A user with valid database access.
  • Application level. Helps against: A compromised database account, a curious admin, a SQL injection that dumps tables. Does not help against: A compromised application with key access.

The pattern: the closer to the application the encryption sits, the fewer parties can see plaintext, and the more work you take on for search, sorting and key handling.

Decision guide

  1. Laptops and phones: turn on full disk encryption. See laptop encryption checklist.
  2. Cloud storage and databases: use the platform's encryption at rest as the baseline. It is usually a setting, and some services enable it by default. For S3 see default encryption explained.
  3. Sensitive fields such as national IDs or health data: consider application level encryption with envelope keys. See envelope encryption explained.
  4. Passwords: do not encrypt, hash. See Argon2id settings.
  5. Card numbers: avoid storing, or tokenize. See tokenization vs encryption.

Keep keys apart from data

OWASP says to store encryption keys apart from the data they protect, for example keeping keys on the filesystem when the data sits in a database, so that one compromised location does not expose both. Separate systems give stronger isolation.

Do not forget the backups

Encrypted primary storage with plaintext backups defeats the purpose. Check that snapshots and exports inherit encryption.

An example with three data sets

Take a SaaS company with three kinds of data. Employee laptops hold source code and mail: full disk encryption is the obvious control, since the threat is loss or theft. The production database holds customer records: platform encryption at rest covers stolen storage and snapshots, while one column of national ID numbers also gets application level encryption with per-tenant keys because a database administrator should not read it. The analytics warehouse holds hashed or tokenized stand-ins instead of raw values, because the best protection is not holding the data at all. Three data sets, three different answers, each tied to a stated threat.

Quick check

If my cloud disks are encrypted, is my data safe from a SQL injection?

No. The database decrypts for any valid query. Disk encryption does not stop application level attacks.

Is application level encryption always better?

It protects against more, but it complicates search and key management. Use it for the fields that justify it.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.