Keep encryption keys in a KMS, HSM or secrets manager, separate from the data they protect. OWASP's cryptographic storage guidance says to avoid hard coding keys in source and to avoid storing them in environment variables. Where those are not available, use the narrowest permissions you can.
What the guidance says
The OWASP Cryptographic Storage Cheat Sheet makes four relevant points. Keys should be stored in a separate location from the encrypted data. A KMS, HSM or secrets manager should be used where available. Keys should not be hard coded in source. And they should not be kept in environment variables. It also says formal key management processes should be implemented and tested.
Approaches compared
- Hard coded in source: the worst option. The key lands in version control, builds, logs and every developer laptop, and removing it later does not remove it from history.
- Environment variables: convenient, but they leak through process listings, crash dumps, debug pages, child processes and CI logs. OWASP advises against them.
- Files on disk with strict permissions: better than the two above when nothing else exists, but they sit next to the application and back up with it.
- A secrets manager: central storage, access control and audit logs, with the application fetching the secret at runtime.
- A KMS or HSM: the key never leaves the service. Your code sends data or a wrapped key in and gets a result back, so even a compromised app server cannot read the key itself.
How to pick
- Need the key to stay out of reach of your own app servers? KMS or HSM, ideally with envelope encryption so you only call it for small keys.
- Need to hand a credential to a service that must hold it? A secrets manager with short lifetimes and rotation.
- No managed service available? Files with tight permissions, a dedicated user, and a plan to move.
- Never source code or plain environment variables for long-lived keys.
Practices that matter more than the product
- Separate keys by purpose, so a signing key is not an encryption key.
- Give each service only the permission it needs, such as encrypt but not decrypt.
- Log every key use and review it.
- Have a rotation process that you have actually tested.
- Keep backups of keys under the same controls as the keys.
- Know who can delete a key, because deletion means data loss.
When keys leak
OWASP says to rotate after a suspected compromise and prefers re-encrypting existing data with the new key. Rehearse that before you need it, including how long a full re-encryption takes.
Quick check
Is a secret in an environment variable ever acceptable?
OWASP advises against it for encryption keys. For short-lived, low-impact values in a controlled environment it may be a pragmatic step, but plan to move it to a secrets manager.
Does a KMS remove the need to rotate keys?
No. It protects key storage and use. You still need cryptoperiods, rotation rules and a tested compromise response.
Safeguard's compliance and evidence automation can keep your key management procedures and evidence in one place for audits, and the free scan at gold.safeguard.sh/scan covers dependency scanning.
Sources
Last reviewed: 19 October 2026.
