Cryptographic erasure means making data unreadable by destroying the key that protects it. It works only when every copy of that key, and of any key that protects it, is truly destroyed and no recoverable plaintext remains. OWASP lists those conditions explicitly.
The idea
Deleting a terabyte of backups and replicas is slow and hard to verify. Destroying a 32 byte key is fast. If the data was encrypted under that key and nothing else can decrypt it, the data is as good as gone. That is cryptographic erasure, and it is popular for tenant offboarding and deletion requests.
The conditions
OWASP's Key Management Cheat Sheet says to use cryptographic erasure only when every copy of the protecting keys can be destroyed and no recoverable plaintext remains.
Three things make that harder than it sounds:
- Copies of keys: backups, escrowed copies, caches and memory copies all count. OWASP says to destroy all secret and private key copies, including those.
- Key hierarchies: if the data key is wrapped by a key encryption key that other data also uses, you cannot destroy the KEK without hurting everything else. You need a key per thing you may want to erase, such as per tenant.
- Plaintext leaks: if the application cached decrypted data, logged it, or exported it, destroying the key does nothing for those copies.
Design for erasure up front
- Use a separate data key per unit you may need to erase, for example per customer.
- Wrap each data key under a hierarchy where retiring the tenant key does not affect others.
- Keep an inventory of where each key and its backups live.
- Make sure derived data, search indexes and analytics extracts are either encrypted under the same key or deleted too.
- Record the destruction event with a timestamp, operator and authorization.
Destroying keys in practice
OWASP gives several practical notes.
- Overwriting keys in managed runtimes is best effort, because the runtime may have moved or copied the memory. Use platform zeroization APIs where available.
- For HSMs, use the vendor zeroize commands.
- Physically destroy obsolete media.
- When retiring a key encryption key, re-wrap the data keys under the replacement before destroying the old one, unless erasure is the goal.
- Public verification keys may be kept so archived signatures can still be checked.
Do not over claim
Telling a customer or regulator that data is deleted because the key is gone is a strong statement. Before you make it, confirm backups, replicas and exports were covered. Whether cryptographic erasure satisfies a given legal deletion duty is a question for counsel and for the specific regulation, not something a key policy settles alone.
Quick check
Is deleting a key in a KMS enough?
Only if no other copy of the key exists and the data cannot be decrypted another way. Check backups, exported key material and wrapped copies.
Can I erase one record by destroying a key?
Only if that record has its own key. If it shares a key with other records, destroying the key destroys all of them.
Safeguard's compliance and evidence automation can hold the destruction records and approvals as audit evidence, and the free scan at gold.safeguard.sh/scan covers dependency risk.
Sources
Last reviewed: 19 October 2026.
