SSD Sanitization and Cryptographic Erase: Why Overwriting Fails

Overwriting every addressable sector is a sound way to sanitize a magnetic hard drive and an unreliable way to sanitize a solid state drive. The reason is architectural, not a matter of doing more passes, and understanding it is what separates a correct answer from a confident wrong one.

Why overwriting does not reach the data

Flash memory cells wear out after a finite number of write cycles, so an SSD controller distributes writes across the whole device to extend its life. The logical block address the operating system writes to is mapped by the controller to whatever physical cell it chooses, and that mapping changes constantly.

So when software overwrites logical block 500, the controller writes the new data to a fresh physical cell and marks the old one invalid. The original data is still physically present, just no longer reachable through the normal interface.

Over-provisioning compounds this. Drives contain more flash than they advertise — commonly seven to twenty-eight percent extra — held back for wear levelling and bad block replacement. That capacity is not addressable by the host at all, so no host-level overwrite can touch it, while data can and does reside there.

Deleted-but-not-yet-erased blocks awaiting garbage collection add a third pool of recoverable data. None of this is defeated by additional overwrite passes, which is why multi-pass wiping on an SSD achieves nothing except wear.

What does work

Cryptographic erase is the cleanest method and the one to know. Self-encrypting drives encrypt everything written to them with a key held in the controller, transparently and at full speed. Sanitizing means discarding and regenerating that key: the data remains on the flash and becomes undecryptable ciphertext.

It completes in seconds regardless of capacity, and it reaches every cell including over-provisioned space, because the data everywhere was encrypted with the same discarded key. The caveats are real: it depends entirely on the drive implementing encryption correctly and actually destroying the key, and several vendor implementations have been found defective. For high-sensitivity data, follow it with physical destruction rather than trusting the firmware alone.

ATA Secure Erase and the newer Sanitize command instruct the drive's own firmware to erase all cells, including those the host cannot address. Because the controller performs it, it reaches the areas software cannot. Support and correctness vary by vendor, and the drive may be in a frozen security state that requires a power cycle before the command is accepted — the usual cause of "the tool says it cannot run."

Encrypt from the start is the strategy that makes all of this easier. If full disk encryption was enabled on first use and the key was never exposed, discarding the key sanitizes the drive whatever its internal behaviour. This is also why a factory reset on a modern phone is effectively a cryptographic erase, and why the same encryption defeats the offline boot attack during the drive's working life.

Physical destruction remains the answer for the highest classifications. For flash, shredding must produce particles small enough that individual memory chips are destroyed rather than merely separated — a shredder sized for platters is not sufficient for SSDs.

Verification

Verify rather than assume. Read back a sample of sectors and confirm they contain no recoverable data, and where the drive reports a sanitize status, record it.

Understand what verification can and cannot prove: reading through the normal interface cannot inspect over-provisioned space, so a clean read confirms the addressable area and says nothing about the rest. That limitation is precisely why firmware-level commands and cryptographic erase are preferred over host-level overwriting, and why documentation of the method used matters as much as the result.

Keep a record for each drive — serial number, method, date, operator, and outcome. Where drives leave your control, a certificate of destruction from the vendor naming serial numbers is the standard evidence, and demonstrable deletion is what data protection obligations such as the right to be forgotten actually require.

The decision in one line

Magnetic drive staying internal: overwrite. Magnetic drive leaving your control: purge or destroy, degaussing where the drive will not be reused. SSD staying internal: cryptographic erase or the drive's sanitize command. SSD leaving your control at any sensitivity: sanitize command plus verification, or destruction. Failed drive that cannot accept commands: destruction, because no software method can reach it. The wider framework these sit in is covered under media sanitization.

Exam angles

Know that wear levelling and over-provisioning make host-level overwriting unreliable on SSDs, and that additional passes do not help. Identify cryptographic erase as discarding the encryption key, completing in seconds and covering inaccessible areas. Know ATA Secure Erase and Sanitize as firmware-level commands. Recognize a failed drive as a destruction case, and remember that enabling full disk encryption at deployment is what makes later sanitization simple.