Back up encryption keys that protect data you must be able to recover, protect the backups as carefully as the keys, and never escrow signing keys. OWASP's key management guidance is blunt on the first point: a lost key means permanently unrecoverable data.
Why backup is a security task
Teams spend effort on keeping keys secret and forget the other failure. If the only copy of a key is lost, every record encrypted under it becomes noise. For long-lived data such as archives, that is a business-ending event rather than a minor outage.
OWASP says to implement secure key backup for long-term encrypted data. It also says key backup databases should themselves be stored encrypted, using a module validated to FIPS 140-2 or 140-3.
What to back up
Think in terms of purpose.
- Data encryption keys and key encryption keys for data you must read again, such as archives and records under retention rules: back up.
- Keys that protect short-lived data you can regenerate or discard: usually no backup needed. Losing them is acceptable.
- Root or wrapping keys at the top of a hierarchy: back up with extra care, because everything below depends on them.
If you use envelope encryption, you mostly need to protect the key encryption key and the wrapped data keys stored with the data.
Escrow, and the exception
Escrow means placing a copy with a separate trusted party or process so keys can be recovered, for example for investigations or when re-provisioning. OWASP says to escrow encryption keys when it is useful for those purposes, and never to escrow signing keys.
OWASP does not spell out its reasoning here. The usual argument, which is our interpretation, is non-repudiation. If a second party holds a copy of a signing key, a valid signature no longer proves that only the owner signed. Keep signing keys in one place, protected by an HSM or key service, and plan replacement rather than recovery.
Protecting the backup
A backup is another copy of the secret, so it needs the same standards as the original or better.
- Encrypt backups under a key encryption key stored apart from the backup media.
- Restrict who can restore, and require two people for the most sensitive keys.
- Log every backup creation and every restore.
- Store backups in a different failure domain from the primary, such as another region or account.
- Test a restore on a schedule. A backup never restored is an assumption.
Destruction has to include copies
When a key is retired, OWASP says to destroy all copies of secret and private keys, including backups, escrowed copies and memory copies. Plan for that at creation. If you cannot list where the copies are, you cannot honestly claim a key is gone.
A short policy template
State, for each key class: whether it is backed up, where, who may restore, how often restore is tested, and when copies are destroyed. One page is enough, and auditors tend to ask for exactly this.
Quick check
Should the application team hold the key backup?
Better to separate duties. The people who operate the application should not alone control the copies that can decrypt its data.
Is escrow always a good idea for encryption keys?
Only when you have a reason, such as investigations or re-provisioning. Each escrowed copy is another place the key can leak, so decide deliberately.
Safeguard's compliance and evidence automation can keep key backup and restore test evidence tied to the controls auditors ask about, and the free scan at gold.safeguard.sh/scan covers dependency risk.
Sources
Last reviewed: 19 October 2026.
