Crypto-shredding means destroying the encryption key so the ciphertext becomes unreadable. It can make deleting data from many backups practical, but only if every copy of the protecting keys is destroyed and no recoverable plaintext remains. OWASP warns that destroying a wrapping key does not erase plaintext copies of the keys it protected.
The idea
Encrypt each customer's, tenant's or record's data under its own data key, held in a key service. To delete, destroy that key. The ciphertext may still sit in backups, snapshots and replicas, but nobody can read it.
This pairs naturally with envelope encryption. See envelope encryption explained.
What OWASP says about destruction
OWASP's key management guidance describes destruction as the final lifecycle state. Destroy all copies of secret and private keys, including backup, archived, escrowed and memory copies, once they are no longer needed for decryption or recovery and retention requirements are met.
Cryptographic erasure is appropriate only when all copies of the protecting keys can be destroyed and no recoverable plaintext copies remain. The page adds that:
- Overwriting keys in memory is best effort in managed runtimes, where copies may persist. Use platform secure memory or zeroization APIs where available.
- For HSMs, use the vendor's zeroize or destroy commands.
- Physical media holding keys should be destroyed per your sanitization standards.
NIST's media sanitization guide lists crypto erase among its keywords. Its Revision 1 page says that revision was withdrawn on 26 September 2025 and superseded by Revision 2, so read the current revision for method details.
When it works well
- Many copies of the data exist (backups, replicas) and rewriting them all is impractical.
- Keys are granular, one per subject or tenant.
- Keys live only in a key service you control.
When it fails
- One key protects everything. Destroying it deletes everything, so you will not do it.
- Keys were exported, escrowed or logged somewhere.
- Plaintext copies exist in caches, exports, analytics or search indexes.
- Key backups were taken and never tracked.
Design checklist
- Choose key granularity that matches deletion requests.
- Keep a key inventory that includes every backup of key material.
- Make destruction an auditable action with approvals.
- Handle the delay: some key services schedule deletion after a waiting period. Check your service.
- Treat derived data as in scope.
- Test it: delete a test subject, then try to restore and read their data.
A test you can run
Treat crypto-shredding as a claim to be tested, not assumed. Create a test tenant with realistic data in every store it touches: primary database, search index, cache, object storage and a backup. Record where its key lives, including any backups of key material. Destroy the key through your normal process. Then try to read the tenant's data from each location, including from a restored backup in an isolated environment. Every attempt should fail, and search for any plaintext remnant in logs and exports. Whatever you find readable is a copy you forgot, and fixing it is the real work.
Quick check
Does crypto-shredding satisfy a deletion request on its own?
Whether it counts as erasure under a given law is a question for your counsel. Technically it only works if all key copies and plaintext copies are gone.
Is it the same as deleting the ciphertext?
No. The ciphertext may remain. It just cannot be decrypted.
Sources
Last reviewed: 19 October 2026.
