How to Secure Erase (reset) an Intel Solid State Drive (SSD)
Archived note. Originally published 30 June 2009 on iishacks.com. It describes the first-generation Intel X18-M, X25-M and X25-E solid state drives, and the DOS-based HDDErase utility, as they behaved at that time. Those drives predate TRIM support on Windows, and standalone DOS erase utilities have since been replaced by vendor toolboxes and by the ATA sanitise and NVMe format commands; the current reference for sanitising storage media is NIST SP 800-88 Rev. 1. Verify against current vendor documentation before applying any of it to a live system.
The operation described below destroys every byte on the target drive and there is no recovery afterwards. Confirm the drive identifier before issuing the command.
The original note
By mid-2009 the performance degradation found in Intel SSDs from the write and rewrite cycle was widely known. The drives remained extremely fast, but there were cases where it was worth resetting one — to restore its performance, or to erase it securely before a second sale or before installing it in a different computer or server.
The note quoted the drive vendor’s own description of the command as it stood at the time:
An alternative method (faster) is to use a tool to perform a SECURE ERASE command on the drive. This command will release all of the user LBA locations internally in the drive and result in all of the NAND locations being reset to an erased state. This is equivalent to resetting the drive to the factory shipped condition, and will provide the optimum performance.
The tooling problem
The difficulty in 2009 was not the command but getting at it. The Center for Magnetic Recording Research no longer had HDDErase 3.3 on its website, and 3.3 was the version needed to secure erase the Intel X18-M, X25-M and X25-E. HDDErase 4.0 was not compatible with the Intel SSDs, although it was the correct choice for other hard drives. That distinction is what one of the inbound links still pointing at this page records in its anchor text: reportedly not compatible with intel ssds.
Because the utility had been withdrawn, the note hosted a copy of the 3.3 zip file and linked to it. This archive does not host that file and does not redistribute a third-party utility. It is recorded only because it is part of what the page was.
The procedure as recorded
- Usage instructions were included inside the zip file.
- A DOS 6.22 boot disk was required. Under Windows XP this was created from Explorer by right-clicking the A drive, choosing Format and selecting the create-boot-disk option;
HDDErase.exewas then copied onto it. - AHCI (SATA mode) had to be disabled in the BIOS before booting into DOS, or the utility would not run and work properly. Most BIOS versions of the period offered IDE emulation for the SATA ports. AHCI had to be switched back on afterwards.
- Secure erasing the Intel SSD took about a minute; nothing is written during the operation, so elapsed time bears no relation to drive capacity.
Why 2009-era SSDs slowed down
NAND flash cannot be overwritten in place. A page can be programmed only after the erase block containing it has been erased, and erase blocks are far larger than the pages written into them. A drive with clean blocks absorbs a write immediately; a drive with none has to read a block, merge the new data with the still-live data around it, erase the block and write the whole thing back.
That is the whole of the problem the note opens with. A new drive is fast because every block is clean; once every logical block address has been written once, nothing is left clean but the over-provisioned reserve. Reads stay quick. Small random writes do not.
Deleting files did not help, because in 2009 the drive was not told about deletions — a delete updates filesystem metadata and the drive sees nothing. TRIM closed that gap later, arriving on Windows with Windows 7. Before that, the only way to give a controller back its clean blocks was to tell it that none of them held anything, which is exactly what the quoted command does.
What ATA Secure Erase is
Secure Erase is not a file-level wipe and not a host-driven overwrite. It is a command in the ATA command set: the host issues it, the drive’s own firmware carries it out, and nothing is streamed across the interface. On flash, the controller issues a block erase across the NAND and resets its logical-to-physical mapping table — which is why the command mattered for performance and not only for security. The drive is not merely made unreadable; it is returned to the condition it was in when the mapping table was empty and every block clean.
The command sits inside the ATA security feature set, which has to be armed with a user password before an erase can be issued. That is why an interrupted run was worse than none: a drive left security-enabled is a drive nobody can read without knowing what the utility set.
The frozen-drive problem
Two things had to be got past before the command would reach the drive, and the note names the first: a DOS-mode utility had no driver for a controller running in AHCI mode, which is why IDE emulation had to be selected in the BIOS first and restored afterwards.
The second was the security freeze. Most system firmware freezes attached drives during power-on, blocking any change to a drive’s security state until the next power cycle — a sensible defence against a malicious password-set, and one that blocks the legitimate case too. The era’s workaround was to boot with the drive frozen, then unplug and reconnect its power connector while the system ran. It worked, but it meant handling a live SATA connection on a running machine.
What replaced the utility of 2009
HDDErase was the common route because nothing else exposed the ATA command to an ordinary administrator. Compatibility with any given controller was uneven, which is what forced the split between the 3.3 and 4.0 builds: there was no authoritative compatibility matrix, only forum reports and a version withdrawn from its own publisher’s site.
Vendor drive toolboxes then began exposing a secure erase directly, so the manufacturer took responsibility for issuing the command against its own firmware, and operating-system tooling made the ATA security commands reachable without a DOS boot disk. The command set moved on too: ATA gained a sanitise feature with an explicit block-erase operation, and NVMe drives expose their own format-with-secure-erase settings. The performance motivation evaporated as well — with TRIM working end to end, a drive does not need resetting.
The modern reference
For sanitisation rather than performance, the correct current reference is NIST SP 800-88 Rev. 1, Guidelines for Media Sanitization. It is worth reading before trusting any 2009-era advice, for one reason above all: a conventional multi-pass overwrite is not a reliable sanitisation method on flash, because remapping means the host cannot address the physical blocks holding old copies of data, and over-provisioned capacity is never exposed to the host.
Two cautions carry forward. The operation destroys everything on the drive, and it targets firmware of a specific generation — so the vendor’s current documentation for the drive in hand outranks anything on this page. Support dates for the operating systems named here can be checked against the Microsoft product lifecycle.
Other storage notes are collected under Hardware. The later note on fixing an SSD freezing on Windows 7 covers a different failure on a much later Intel drive, leaning on high average disk queue length for the measurement side. The full index is at post archives, on the IIS Hacks archive.