Chapter 03 · 7 min read
Why overwriting an SSD doesn’t erase it
A three-pass overwrite on a 2 TB SSD takes about six hours, reports success, prints a certificate — and can leave your data sitting in cells the tool never touched. The tool isn’t lying. It genuinely wrote what it was told to write. It just wasn’t writing where you assumed.
03.1The problem in one sentence
On a hard disk, writing to logical block 12,345 puts those bits in a fixed physical spot. On an SSD, the controller decides where they go — and it will deliberately pick somewhere other than where the old copy is sitting.
Everything below is a consequence of that one sentence.
03.2Wear levelling
Flash cells die after a finite number of program/erase cycles. To stop a handful of hot cells wearing out years before the rest, the controller spreads writes across the whole device using a translation layer that maps logical addresses to constantly moving physical ones.
So when your wiping tool writes zeroes across the entire logical address space, the controller obligingly writes zeroes — to fresh cells. The cells holding the original data get marked stale. The data is still physically there until garbage collection gets round to erasing those blocks, which might be minutes, might be weeks, might be never.
03.3Over-provisioning
A drive sold as 960 GB usually contains 1,024 GB of flash. That spare capacity handles wear levelling, bad block replacement and garbage collection — and it is not addressable from the host at all.
Your overwrite cannot reach it. Not because the tool is bad, but because there is no command in the interface that addresses those cells. Retired blocks holding real data routinely sit in that pool.
03.4So multi-pass is worse than useless
It burns write endurance. It takes hours. And it produces a confident-looking report saying the drive was overwritten three times, which is true and almost entirely beside the point.
NIST 800-88 is explicit about this: the technique has to suit the media, and overwrite-based methods are not appropriate for flash. If someone is selling you a seven-pass wipe as a premium option on SSDs, you are paying extra for wear.
03.5What actually works
Stop trying to outmanoeuvre the controller and instruct it directly. Every enterprise SSD implements firmware-level sanitisation:
- SATA —
ATA SANITIZEwith block erase, orSECURITY ERASE UNIT - SAS —
SCSI SANITIZE, usually the block erase service action - NVMe —
NVMe Formatwith a secure erase setting
These finish in seconds to a couple of minutes rather than hours, because the drive erases flash blocks in parallel internally instead of streaming data across an interface. Faster and more thorough is an unusual combination, and it’s why the old habit persists — six hours feels more rigorous than ninety seconds.
03.6Cryptographic erase
Most enterprise SSDs are self-encrypting whether or not anyone switched it on. Everything written is encrypted with a media encryption key held in the controller. Discard that key, generate a new one, and every block on the device becomes unreadable ciphertext — instantly, including the over-provisioned space you couldn’t otherwise reach.
The catch is that it’s only as good as the key handling, which is why NIST treats it as a Purge technique and why it should be confirmed against the drive’s own reported status rather than assumed to have worked.
03.7What about degaussing?
A degausser destroys data by scrambling magnetic fields. Flash stores electrical charge in cells. There is nothing magnetic to disturb.
Running an SSD through a degausser does nothing at all. It is one of the more dangerous misconceptions in this field precisely because the process feels so decisive — loud machine, heavy drive in, drive out, job done. The drive is completely readable afterwards.
03.8Verify, don’t assume
A sanitise command can fail quietly. Drives refuse for all sorts of reasons: a frozen security state, a firmware bug, a failing device, a drive that’s locked.
A certificate saying “overwrite complete” with no verification result is an assertion, not evidence. Ours records the command issued, the drive’s own reported completion status and a read-back check — here’s one for a SAS SSD. Anything failing verification goes to physical destruction rather than being retried until it passes.
03.9Practical summary
| Media | Don’t | Do |
|---|---|---|
| SATA SSD | Multi-pass overwrite | ATA SANITIZE / SECURITY ERASE |
| SAS SSD | Multi-pass overwrite | SCSI SANITIZE (block erase) |
| NVMe SSD | Overwrite, degauss | NVMe Format, secure or crypto erase |
| Self-encrypting | Assume it’s off | Cryptographic erase, verified |
| Magnetic HDD | — | Single-pass overwrite Purge, or destroy |
| Anything that fails | Retry until it passes | Physically destroy it |
If you take one thing: ask whoever wipes your flash which command they issue. If the answer is a number of passes rather than the name of a command, they are using a hard disk method on solid state media.
About the author
Kamil Anwar — Founder, ServerGear. Kamil runs ServerGear, the data centre asset recovery arm of PYCO RENEW LTD. He spends most of his week looking at asset lists, arguing about what a four-year-old server is really worth, and making sure the drives that come with it are dealt with properly.