Yes. OWASP says encryption keys should be stored in a separate location from the encrypted data, so an attacker who reaches only one cannot get both. A key in the same database row, bucket, or repository as the ciphertext adds little protection once that one place is breached.
What separation protects against
Think of the attacker paths. A stolen database backup, a misconfigured storage bucket, a SQL injection that dumps tables, a leaked disk snapshot. In each case the attacker holds data. If the key travels with it, they hold everything. If the key sits behind a different system and a different permission, they hold ciphertext they cannot read.
Levels of separation
| Level | Example | Protects against |
|---|---|---|
| Same row or file | Key column beside encrypted column | Almost nothing |
| Same server, different file | Key in a config file on the app host | A database dump, not a host takeover |
| Different service | Key in a secrets manager or key vault | A dump of the data store |
| Different account and role | Key service in a separate cloud account | A broad compromise of the app account |
| Hardware module | HSM holds the key, you call it | Key extraction, even by admins |
Each step costs a bit more effort and adds a real barrier. Choose the level that matches the data. OWASP lists using platform secure storage, such as an HSM, cloud key vault, or secrets manager, where available.
A two layer pattern
OWASP describes using a data encryption key to encrypt data and a key encryption key to encrypt the data key. The KEK should be at least as strong as the DEK and stored separately from it. In practice the encrypted DEK can sit with the data, since it is useless alone, while the KEK stays in the key service.
What OWASP says to avoid
When secure storage is not available, OWASP's basic rules are: do not hard code keys in source code, do not check keys into version control, protect configuration files with restrictive permissions, and avoid environment variables. The page lists environment variables as something to avoid, which surprises many teams.
Steps to separate keys this week
- List where each key lives today and where the data it protects lives.
- Flag any key stored within reach of the same credential as its data.
- Move flagged keys to a key vault or secrets manager with its own access policy.
- Give the application only the permission to use the key, not to export it, where the service supports that.
- Log every key use, and alert on odd patterns.
- Test restore. You must be able to recover data after a key service outage.
Do not forget backups
Backups copy data. If backups also copy the keys into the same archive, separation is gone. Keep key backups apart from data backups, with different custodians where practical. Retire old keys carefully, since OWASP notes retired keys may be kept for a period because old backups might need decrypting.
Try it yourself
Open the continuous monitoring demo and see how a change over time raises an alert. Think about which key location changes in your own estate you would want an alert for.
Click through it at your own pace, or open it full screen.
Safeguard can generate an SBOM and scan your dependencies, so outdated cryptography libraries with known advisories show up in one inventory, and policies can gate a build on them. A free scan is at gold.safeguard.sh/scan.
Quick check
Is an encrypted DEK next to the data a violation?
No, that is the normal envelope pattern, as long as the key that wraps it is stored separately.
Does a separate database count as separate storage?
Only if it has separate credentials and access paths. If one login reaches both, the separation is cosmetic.
Sources
Last reviewed: 19 October 2026.
