18 Apr 2026 8 min read
I write a secure-deletion tool called BitBurn. It implements NIST 800-88 Clear, NIST 800-88 Purge, and the Gutmann 35-pass method. Users pick a mode, drag files in, and the tool overwrites them before unlinking.
When I shipped the Gutmann mode I felt clever. Thirty-five passes with pre-computed magnetic patterns for MFM and RLL encoding! Nobody's recovering anything from that!
This was nonsense, and I'm going to explain why — partly for anyone still deploying Gutmann wipes in 2026, partly to make peace with my own past decisions. The short version: Gutmann was right for 1996. It is wrong for anything you are likely wiping today. The correct algorithm for a modern SSD is "throw the key away", and the second-best is "tell the firmware to wipe itself". Multi-pass overwrite is between useless and actively counterproductive.
Peter Gutmann's 1996 paper targeted MFM and RLL encoded magnetic hard drives. On those drives, individual bits weren't written perfectly on top of the previous bit — there was measurable residual magnetisation at the track edges. With a sufficiently sensitive magnetic force microscope and many hours of patience, a determined attacker could reconstruct the previous value of a flipped bit by analysing the flux transitions.
Gutmann's 35 patterns were designed to flip every bit in every encoding scheme the drive might use, leaving no residual pattern from the previous state. It was a defensible piece of work against 1996-era drives and 1996-era attackers.
Gutmann himself wrote an epilogue in 2001 that most blog posts quoting the method have never read:
For any modern PRML/EPRML drive, a few passes of random scrubbing is the best you can do. As the paper says, "A good scrubbing with random data will do about as well as can be expected". This was true in 1996, and is still true now.
That was about magnetic drives. SSDs make even "a few passes of random scrubbing" meaningless.
A solid-state drive does not write where you tell it to write.
When you issue a write to LBA 0x1234, the SSD's Flash Translation Layer (FTL) picks a free erase block and writes there. The mapping from logical to physical is kept in an internal table. The old physical block — containing your previous data — is marked for eventual garbage collection, but it is not erased immediately.
This is called wear-levelling and it exists because NAND flash cells have a finite number of program-erase cycles. If the FTL wrote to the same physical block every time you wrote to LBA 0x1234, that block would wear out in weeks. So it spreads writes across the entire pool of blocks, including the overprovisioning area — extra flash that the drive reserves and never reports to the host.
Three consequences follow:
Your overwrite lands somewhere else. When you write zeros to LBA 0x1234 to overwrite your secret data, the zeros go to a fresh block. Your secret data is still sitting in the old block, unmapped but unerased, until the controller gets around to garbage-collecting it. Could be seconds. Could be weeks.
You can't reach overprovisioning. Typically 7–28% of an SSD is overprovisioning that the host cannot address. If your sensitive data was ever written to one of those blocks (and then relocated), there is no LBA you can overwrite to cover it.
Pass 2 through 35 make it worse. Each additional overwrite pass allocates more fresh blocks, accelerating wear without touching the original data. You are burning through the drive's endurance to accomplish nothing.
Forensic researchers have recovered "deleted" data from SSDs that had been overwritten multiple times, specifically because the overwrites didn't land on the original physical blocks. This is not speculative — it's published, reproducible research.
Two things work. Exactly two.
Modern SSDs have a firmware-level command that tells the controller to erase every block it has, including overprovisioning. For ATA SSDs this is SECURITY ERASE UNIT. For NVMe it's the Sanitize command with the appropriate action (Block Erase, Crypto Erase, or Overwrite).
On Linux:
# SATA SSD hdparm --security-set-pass PWD /dev/sdX hdparm --security-erase PWD /dev/sdXNVMe
nvme sanitize /dev/nvme0 —sanact=2 # 2 = Block Erase nvme sanitize /dev/nvme0 —sanact=4 # 4 = Crypto Erase (if supported)
On Windows, diskpart's clean all does not issue Sanitize — it does a host-side overwrite. You want a vendor tool (Samsung Magician, Intel Memory and Storage Tool, Crucial Storage Executive) or you boot to a Linux USB and use nvme-cli/hdparm.
Caveat: firmware bugs exist. A 2011 UCSD study tested a dozen SSDs and found that some claimed to support Secure Erase but left data recoverable. Most modern drives are fine, but if your threat model is "nation-state with a scanning electron microscope", verify with your drive vendor. For "I'm selling this laptop on eBay", Sanitize is more than enough.
If the drive is encrypted — whether by BitLocker, LUKS, FileVault, or the drive's own self-encrypting-drive (SED) firmware — and you destroy the key, the ciphertext is indistinguishable from noise. You don't need to touch the data at all.
This is the actual answer for most real-world data destruction:
BitLocker: manage-bde -forcerecovery C: then Remove-BitLockerKeyProtector every protector, then repartition.
LUKS: cryptsetup erase /dev/sdX wipes all eight keyslots. Without any slot's passphrase, the master key cannot be recovered. Roughly a millisecond of wall time. Done.
SED with TCG Opal: sedutil-cli --revertNoErase PSID /dev/sdX (with the drive's PSID from the physical label) resets the drive to factory state with a new media encryption key. Previous data is now ciphertext encrypted under a key that no longer exists anywhere.
Encrypt-then-throw-away-the-key is faster, more thorough, and strictly more secure than any overwrite scheme. Encrypt all your disks from day one and secure deletion becomes a solved problem.
Multi-pass overwrite is not completely obsolete. It's the right tool in three specific cases:
Classic magnetic hard drives. If you're wiping a pre-SSD drive, a single-pass overwrite of zeros (NIST 800-88 Clear) is sufficient for all modern drives (post-2001ish). Gutmann's 35 passes are not required and have not been required for over two decades. One pass is fine.
Files on a partition where you cannot sanitize the whole drive. If you need to wipe a single file on an encrypted-but-shared volume, and you can't crypto-erase the volume because others are using it, file-level overwrite is the best available option. It is imperfect on SSDs for the FTL reasons above, but it's better than nothing and it's often what BitBurn is actually used for.
Free-space wipe before selling an HDD. If you want to leave the OS intact but erase deleted-file remnants on a spinning disk, a single-pass free-space wipe does the job. cipher /w:C: on Windows; sfill on Linux.
For everything else: Sanitize the drive, or crypto-erase it, or both.
Here's the tree I actually use:
Is the drive encrypted at rest? ├── Yes → destroy the key (crypto-erase). Done. └── No → is the drive an SSD or HDD? ├── SSD → ATA Secure Erase / NVMe Sanitize. Done. └── HDD → single-pass overwrite (NIST 800-88 Clear). Done. No, you do not need 35 passes.
Special case: individual file on a non-sanitizable volume? └── Single-pass overwrite, understand the limitations, and next time encrypt the volume so this isn’t a problem.
That's the whole thing. Gutmann is not on the tree. Neither is "7-pass DoD 5220.22-M", which was withdrawn from the DoD's own standard in 2007.
After writing this post I won't be removing the Gutmann mode from BitBurn — it's useful for the "I've inherited a pile of old HDDs and want to be thorough" case, and it does no harm on magnetic media beyond wasting time. But I added a line to the README in bold:
On SSDs and NVMe drives, use your drive's ATA Secure Erase or NVMe Sanitize command. File-level overwrites cannot reach overprovisioning or unmapped pages. For encrypted volumes, destroying the key is always the correct answer.
The version of me from two years ago would have argued about the nuances. The version of me with a year of incident-response experience has learned that the correct answer to "how do I make sure this data is gone" is almost never "run this tool". It's "what was the data, where was it written, and is the storage encrypted". If you get the answer to those three questions right, the tool barely matters.
Encrypt everything. Destroy the key when you're done. Sanitize hardware before it leaves your possession. That's the whole discipline.
BitBurn: github.com/swatto86/BitBurn.