Encrypt at the layer that matches the threat you are defending against. Disk or hardware encryption protects against stolen equipment. Database encryption helps with stolen files and backups. Application level encryption protects specific fields even from someone who gets into the database. Keep the keys apart from the data in every case.
The four layers
The OWASP Cryptographic Storage cheat sheet lists where encryption can be performed: at the application level, at the database level, at the filesystem level and at the hardware level. It says which layers are appropriate depends on the threat model, and gives a clear example: hardware level encryption is effective against physical theft of the server but provides no protection if an attacker compromises the server remotely.
| Layer | Protects well against | Does not help much against |
|---|---|---|
| Hardware or disk | Stolen drives or servers | Remote access to a running system |
| Filesystem | Offline access to files and snapshots | An attacker with the running system's access |
| Database | Stolen database files and backups | A user or injection flaw that can query data in the clear |
| Application, field level | A database dump, and some insiders | A fully compromised application that holds the keys |
The last row carries a caveat from the same guidance: it may not be possible to fully protect keys from an attacker who has fully compromised the application, but steps can make theft harder.
Start with the threat model
Ask who you are protecting data against. A payments startup might list:
- A lost laptop or decommissioned disk.
- A leaked database backup in object storage.
- SQL injection that reads tables.
- A malicious or careless insider.
- A compromised application server.
Match each to a layer. Items 1 and 2 are covered by lower layers. Items 3 and 4 benefit from field level encryption with keys outside the database. Item 5 is the hardest and is addressed by limiting what the application can decrypt and by monitoring.
Reduce what you store
The guidance says the strongest protection for sensitive information is not storing it. It singles out card details as especially attractive to attackers and subject to strict PCI DSS storage rules. If a payment provider can hold the data, consider letting it.
Key placement matters as much as the layer
OWASP's key management section lists secure storage options: a hardware security module, a virtual HSM, key vaults from cloud providers, or an external secrets management service. Benefits it names include central management, easy rotation, secure key generation, simpler compliance with standards such as FIPS 140 or PCI DSS, and making keys harder to export.
It also says encryption keys should be stored separately from encrypted data. For example, if data is in a database, keys should not be in that database, so an attacker with SQL injection cannot get both. If keys must live in files or environment variables, the basic rules are: do not hard code keys, do not commit them, protect config files with restrictive permissions, and avoid environment variables where they can be exposed by diagnostic functions.
Algorithms and modes
Use AES with at least a 128 bit key, ideally 256, and an authenticated mode such as GCM or CCM through a maintained library, according to the guidance. It says custom algorithms are not an option. Generate keys with a cryptographically secure random function, not from words or keyboard mashing.
A decision path
- List the data you hold and delete what you do not need.
- Turn on disk and database encryption, which are usually configuration changes on managed platforms.
- For the most sensitive fields, add application level encryption with envelope keys held in a key service.
- Separate keys from data and give the application the least decrypt permission it needs.
- Document the threat model and what each layer covers, so reviewers see the reasoning.
Where Safeguard fits
Safeguard does not store keys or encrypt your data. Its dependency scanning and reachability analysis cover the cryptographic libraries in your code, and its policy gates help review changes to them. A free scan is available at gold.safeguard.sh/scan.
Quick check
Is disk encryption enough for a payments database?
It protects against stolen hardware and not against remote compromise of a running system. Add other layers according to your threat model.
Can I keep keys in the same database as the data?
Avoid it. If an attacker reaches the database, for instance through injection, they should not get the keys as well.
Sources
Last reviewed: 19 October 2026.
