What Cryptographic Erasure Cannot Delete
On 26 September 2025 NIST withdrew SP 800-88 Revision 1. Most privacy training material still cites it. If your notes on media sanitisation came from a course written before last autumn, they describe a document that no longer stands, and cryptographic erasure is one of the places where the rewrite bites.
What the current guidance says
SP 800-88 Revision 2 landed in September 2025. The three sanitisation methods survive intact: clear, purge and destroy.
Almost everything else moved. NIST described the change plainly when it published. The focus shifted “from providing guidelines for hands-on sanitization decisions to maintaining the confidentiality of sensitive information”. The technique tables went with it.
Revision 2 no longer tells you how to wipe a particular device. It points you to IEEE 2883, NSA specifications, or an organisationally approved standard. The technical answer now lives in a storage standard. NIST governs the programme around it, including when cryptographic erasure is the right call.
One more reversal is worth knowing. Revision 1 asked for elaborate sampling to verify sanitisation. Revision 2 says that unless organisational policy requires it, “elaborate sampling of an ISM’s contents (e.g., full or representative) after clear or purge sanitization techniques is not necessary”.
How cryptographic erasure works
NIST calls it Cryptographic Erase, or CE. The idea is simple. Encrypt everything on the media, then destroy the key. The ciphertext stays where it is and nobody can read it.
The stated objective is narrow and precise: “to permanently prevent the decryption of ciphertext associated with sensitive information”. Note what that does not say. Nothing leaves the drive. Cryptographic erasure changes the readability of data, never its presence.
That is also why cryptographic erasure is fast. Wiping a multi-terabyte array takes hours. Destroying a key takes milliseconds. The speed is the whole commercial argument, and it is real, provided three conditions hold.
The plaintext condition
Encryption has to cover the media before anyone writes sensitive data to it. Revision 2 puts it through ISO/IEC 27040, which “specifies that no sensitive data has previously been stored on the ISM in plaintext form (i.e., not encrypted) as CE can only sanitize keys related to encrypted data”.
This is the condition that defeats cryptographic erasure most often in practice. Someone enables full-disk encryption on a laptop already two years in service. Everything written before that moment sits on the platter in the clear, and no amount of key destruction touches it.
The key location condition
Every copy of the key has to go. Revision 2 states the risk in one line: “If the target cryptographic keys (or any key at or below the level of key sanitized during CE) exists outside of the ISM, there is a possibility that the key can be used in the future to recover encrypted data.”
Escrowed keys count. Backup key stores count. A key management service holding a copy for disaster recovery counts too. Cryptographic erasure that leaves a recoverable key behind has achieved nothing at all.
The durability condition
Revision 2 adds a condition that Revision 1 did not carry, and it matters for data with a long life. If cryptographic weaknesses emerge in the algorithms used, or if computing capability advances far enough to recover keys, “the sensitive data can become recoverable”.
Ciphertext nobody can read today may not stay that way for twenty years. For short retention that is academic. For medical or genetic records it turns cryptographic erasure into a live design question.
Why cryptographic erasure replaced overwriting
Cryptographic erasure became important because the old default broke. Revision 2 is direct about it.
Flash storage with spare cells and wear levelling makes it “infeasible for a user to sanitize all previous data using this approach because the device cannot support directly addressing all areas in which sensitive data has been stored using the native read and write interface”. Over-provisioned solid-state drives achieve “very little confidentiality protection” from overwriting.
Then comes the sentence every privacy technologist should be able to quote. Users “who have become accustomed to relying on overwrite techniques on magnetic ISM and who have continued to apply these techniques as ISM types evolved (e.g., to flash memory-based devices) can be exposing their data to increased risk of unintentional disclosure”.
Habit is the vulnerability. The procedure stayed put while the hardware moved, and cryptographic erasure is the answer the industry reached for.
Where cryptographic erasure meets an erasure request
Article 17 of the GDPR gives a right to erasure without undue delay. Article 5(1)(e) caps how long a controller may keep data in identifiable form. Neither provision names a technique, which leaves controllers to work out what erasure means on real infrastructure.
Backups are where that gets awkward. The ICO’s guidance on the right to erasure is the clearest statement available. A valid request means “you will have to take steps to ensure erasure from backup systems as well as live systems”. Where immediate overwriting is impossible, “the key issue is to put the backup data ‘beyond use'”, held until the schedule replaces it and used for nothing else.
The EDPB reached the same subject from the enforcement side. Its coordinated enforcement report on the right to erasure, adopted in February 2026, covered 764 controllers across 32 supervisory authorities. Authorities found controllers without specific procedures for handling erasure requests in backups. Two of its recommendations read like a brief for this article. Follow established standards to erase and destroy data in a secure and structured manner. Then verify the erasure, and keep enough evidence to demonstrate it.
Cryptographic erasure answers part of that neatly. Encrypt a backup under a per-tenant or per-subject key, and destroying that key puts the backup beyond reading without touching the tape. That only works where the three conditions above sit in the design from the outset. Architecture decides it, not incident response.
What CIPT asks
The Body of Knowledge is the IAPP’s published map of what each exam covers. Data destruction sits in the domain on collection, use, dissemination and destruction, and cryptographic erasure appears as one technique among several.
Exam items tend to describe a disposal situation and ask which method is appropriate, or which one fails. Two reflexes serve well. Ask what happened before anyone switched encryption on, because that decides whether cryptographic erasure is available at all. Then ask where else a key might live, because the answer is usually somewhere.
Keep the vocabulary straight as well. Clear, purge and destroy are levels of assurance, not brands of tool. This is the same discipline that separates predictability, manageability and disassociability as engineering objectives, and that makes differential privacy a mathematical guarantee rather than a synonym for anonymisation.
If technique questions keep costing you marks, the pattern is usually that the scenario is testing a boundary rather than a definition. The CIPT Exam Question Masterclass drills exactly that reading.
