Last technical review: September 14, 2026 by PC-Doctor Engineering

A software overwrite writes to logical addresses. On a modern drive, the logical address the host writes to is not necessarily the physical location where the earlier data lives. Wear-leveling remaps writes on solid-state drives, retired sectors on any drive fall out of the address space, and ATA features such as HPA and DCO hide entire ranges from the host. Sanitization therefore has to be performed by the drive’s own firmware, which knows where every block is, rather than by a host that can only see the addresses it has been shown.

That is the whole argument. The rest of this article is about why it holds, where the exceptions are, and what a tool has to do about it.

Where the Host Stops Seeing the Drive

A write from an erase tool travels down a stack that looks roughly like this:

Erase tool or application
 -> file system
 -> block and volume layer
 -> ATA, SCSI, or NVMe driver
 -> host controller
 -> drive controller: address translation, remapping, hidden areas
 -> physical media: NAND flash or magnetic platters

Everything above the drive controller operates on logical block addresses. Everything below it is the drive’s business. The controller decides which physical location a logical address maps to, which physical locations are retired, and which address ranges the host is allowed to know about at all.

A host-side overwrite — the traditional pattern write that every wipe utility performs — can only touch the logical addresses the controller exposes. It cannot address a retired sector, a spare block, or a range the controller has been told to hide. This is why the standards distinguish a Clear, which sanitizes “all user-addressable storage locations,” from a Purge, which has to reach everything.^[1] The difference between the two is exactly the set of locations below the controller that a host cannot see.

 

Magnetic Drives and Flash Are Not the Same Problem

On a magnetic hard drive, the mapping from logical to physical is mostly stable. Writing a pattern to every user-addressable sector really does overwrite the data that was there, and a linear overwrite of the whole drive is an effective Clear. The remaining gap is small but real: sectors the drive has retired because they were failing are remapped to a spare pool, and the original locations — with whatever data they held when they failed — are no longer addressable by the host. An overwrite cannot reach them. Only the drive’s firmware can.

On a solid-state drive, the mapping is not stable at all, and that changes everything. Flash cells cannot be overwritten in place; a block has to be erased before it can be written again, and erasing wears it out. To spread that wear evenly, the controller’s flash translation layer sends each new write to whichever physical block is best positioned to receive it. A write to logical address 1,000 today can land on a different physical block than the write to logical address 1,000 yesterday. The old block is marked stale and reclaimed later by garbage collection, on the controller’s schedule, not the host’s. Overwriting a logical address on an SSD does not overwrite the data that was previously at that address. It writes a new copy somewhere else and leaves the old one in place until the controller gets around to it.

SSDs also carry over-provisioned capacity — physical flash the host cannot address at all, reserved for wear-leveling and bad-block replacement. On enterprise drives it can be a substantial fraction of the raw capacity. Data that has migrated into over-provisioned blocks is, by definition, outside anything a host-side overwrite can reach.

The consequence is direct. A pattern write can achieve a Clear on flash, because it does reach every user-addressable location. It cannot achieve a Purge, because it cannot reach the rest. For a Purge on an SSD, the sanitization has to be done by a firmware command that instructs the controller to erase or cryptographically destroy every block it manages, addressable or not.

 

Hidden Areas: HPA, DCO, and AMAC

HPA, DCO, and AMAC are ATA features that reduce the capacity a drive reports to the host. An OEM uses them to reserve a region — often for a recovery image — that the operating system cannot see and cannot allocate. A block-by-block overwrite respects the reported capacity and never touches the reserved region. Erasure software has to detect the restriction and remove it before a Clear can cover the whole drive.^[3]

The mechanism is simple. A Host Protected Area sets a maximum address below the drive’s true capacity; a Device Configuration Overlay can do the same and additionally alter the feature set the drive advertises. The ATA command set marked both feature sets obsolete in ACS-3, in 2011, and Accessible Max Address Configuration is the mechanism that remains in current revisions, with the same effect.^[4] Obsolete in the standard does not mean absent from the field: drives that implement HPA and DCO are still in service and still arrive at refurbishers and recyclers. In every case the drive presents itself as smaller than it is, and everything the host does — partitioning, formatting, wiping — is bounded by the smaller number. A drive that shipped at 512 GB and reports 508 GB has 4 GB that a wipe utility will never see, and if that region ever held user data, an overwrite that reports success has left it intact.

These three features are specific to ATA. NVMe and eMMC do not implement HPA or DCO, but they have their own mechanisms for placing storage beyond the host’s ordinary reach. eMMC devices support write-protected regions — temporary, power-on, and permanent — which are hardware-enforced security zones rather than filesystem partitions.^[6] An erasure tool clears the temporary protection it is permitted to clear before it erases; permanent protection, by definition, cannot be cleared, and a region under it has to be accounted for rather than assumed away. NVMe supports write-protected namespaces. The lesson is the same across all three interfaces: the drive controller can carve out regions the host cannot address in the normal way, and a sanitization process that trusts the reported capacity will miss them.

A tool built for sanitization treats hidden areas as the first problem, not an afterthought. It interrogates the drive for HPA, DCO, and AMAC restrictions, removes them so the full native capacity is exposed, and only then begins the erase. Whether every hidden region was in fact reached is also one of the questions a post-erase analysis has to answer before the result can be classified — which is why, as the previous article in this series described, the level on a certificate is assigned after the erase rather than before it.

 

The Command Hierarchy

Given that the drive’s firmware has to do the work, the practical question becomes which firmware command to issue. Not all of them are equal.

ATA Secure Erase — the SECURITY ERASE UNIT command — dates from the 1990s and predates flash storage entirely. It instructs the drive to erase itself, but the standard leaves the drive a great deal of latitude about how. In 2011, researchers at the University of California, San Diego tested the command on a set of consumer SSDs and found that the results varied by drive: several erased correctly, some did not erase all data, and at least one reported that the erase had succeeded while leaving the data recoverable.^[2] A command that can return success without doing the work is not a basis for a certificate.

ATA Sanitize — the SANITIZE DEVICE feature set, added to the ATA command set in ACS-2 — was designed to close that gap. It defines specific operations (block erase, cryptographic scramble, overwrite) with defined semantics, requires the drive to process every physical block including those outside the user-addressable range, and reports its own progress and completion status. When a drive supports it, Sanitize is the command to use.^[4]

NVMe has the same split. Format NVM with secure-erase settings can perform a user-data erase or a cryptographic erase, but its scope is the namespace being formatted. The NVMe Sanitize command, introduced in NVMe 1.3, operates on the entire NVM subsystem, defines block-erase, crypto-erase, and overwrite actions, and is the operation IEEE 2883 expects for a Purge on NVMe media.^[5][6] Sanitize should be preferred whenever the drive supports it.

Software overwrite sits at the bottom of the hierarchy for the reasons above: it reaches only user-addressable space, and on flash it does not even reliably overwrite that. It remains a legitimate Clear, and on a drive that supports no firmware sanitize command it may be the only option available. What it cannot be is a Purge on a modern drive.

The table is a preference order, not a guarantee. Whether a given command actually reaches every block on a given drive is a property of that drive’s firmware, and the only way to know is to check afterward.

 

Cryptographic Erase

Cryptographic erase is the technique that lets a Purge finish in seconds on a drive that would take hours to overwrite. If a drive has encrypted every block it has ever stored, destroying the encryption key makes every block — addressable, over-provisioned, retired, hidden — unreadable at once. Nothing has to be rewritten. The drive simply loses the ability to decrypt its own contents.

The precondition is the part that gets skipped. A cryptographic erase is only a sanitization if the data was encrypted throughout its life on the drive and the key is destroyed in a way that cannot be undone. A drive that began encrypting partway through, or that retained a copy of the key, or whose key destruction cannot be verified, has not been purged, however quickly the command returned. NIST 800-88 Revision 2 expanded its guidance on cryptographic erase for exactly this reason, tying it to key-management and zeroization requirements rather than treating it as a single command.^[1] Self-encrypting drives that implement the TCG Opal specification are the common case where cryptographic erase is available and verifiable; they are the subject of a separate article.

 

A Command Is Not Evidence

Every command in the hierarchy above returns a status. The UCSD result is a reminder that the status is not the same as the outcome: a drive can report that a sanitize operation completed when it did not, either because the firmware is defective or because the drive’s characteristics prevented the operation from reaching every location.

This is why sanitization tools verify. NIST 800-88 Revision 2 describes verification for non-destructive techniques as confirming the completion status reported by the tool and checking for errors, anomalies, and the health of the media, and it notes that exhaustive sampling of the drive’s contents is not required unless organizational policy demands it.^[1] In practice, a tool built for certificates does more than read the return code. It examines the drive after the erase to determine whether hidden areas were removed and whether the drive’s characteristics prevented a complete result, and it classifies the erase — Purge or Clear, under the standard the customer chose — on the basis of what it found. Both PC-Doctor Drive Erase products are built on this sequence: remove address restrictions, issue the strongest firmware operation the drive supports, analyze the result, classify, and record. The difference between them is the standard the classification is made against — Service Center Drive Erase classifies the result as a NIST 800-88 Purge or Clear; Factory Drive Erase classifies it, by default, as an IEEE 2883-2022 Purge or Clear.

The concession is the same one that applies to every diagnostic. A verified sanitize tells you the state of the drive under the checks that were performed. It does not tell you that a drive with defective firmware is trustworthy, and it does not substitute for a policy that says which drives are allowed to be reused at all.

 

The Boundary That Matters

Sanitization is a question about who is allowed to see the whole drive. The host is not. It sees logical addresses, bounded by whatever capacity the controller chooses to report, mapped to physical locations it cannot inspect. A host-side overwrite is a thorough way to write to all of that, and no way at all to write to anything else.

The drive controller is the only component with the full map. A sanitization process that respects that boundary — remove the restrictions the host can remove, hand the erase to the firmware, and then check whether the firmware did what it said — can make claims a certificate can carry. A process that overwrites the visible drive and calls it clean is making a claim about locations it has never seen.

 

Frequently Asked Questions

Does a multi-pass overwrite help on an SSD?

No. Each pass writes to the logical addresses the controller exposes, and the controller may place each pass on different physical blocks. Additional passes add wear without adding coverage. On flash, a Purge requires a firmware sanitize or a verified cryptographic erase, not more overwriting.

Is ATA Secure Erase enough?

Not on its own. The command’s behavior is drive-dependent, and drives have been documented returning success without erasing all data.^[2] Where the drive supports the ATA Sanitize feature set, use it instead. Where it does not, the result of a Secure Erase should be verified before it is classified as anything.

Does formatting or TRIM sanitize an SSD?

No. A format rewrites filesystem structures and leaves the data blocks in place. TRIM tells the controller which blocks are no longer in use, and the controller may erase them eventually, on its own schedule, with no guarantee of when or whether. Neither is a sanitization technique under any standard.

Is an overwrite fine on a hard drive?

For a Clear, yes: a full overwrite of a magnetic drive reaches all user-addressable sectors. It still does not reach sectors the drive has retired and remapped. For a Purge on a hard drive, use the drive’s firmware sanitize command where available.

How do you know the firmware command actually worked?

By checking afterward. The command’s return status is a claim; verification is the evidence. A sanitization tool should confirm completion status, check the drive for errors and anomalies, confirm that hidden areas are gone, and classify the erase on what it finds rather than on what the drive reported.

 

References

1. National Institute of Standards and Technology. Guidelines for Media Sanitization, NIST Special Publication 800-88 Revision 2. September 2025. ↩
2. Wei, M., Grupp, L. M., Spada, F. E., and Swanson, S. Reliably Erasing Data From Flash-Based Solid State Drives. Proceedings of the 9th USENIX Conference on File and Storage Technologies (FAST ’11), 2011. ↩
3. IEEE Standards Association. IEEE 2883-2022, IEEE Standard for Sanitizing Storage. 2022. ↩
4. T13 Technical Committee. ATA/ATAPI Command Set (ACS) standards. The SANITIZE DEVICE feature set was introduced in ACS-2; ACS-3 Revision 1a (October 15, 2011) records the HPA feature set (f10203r1) and Device Configuration Overlay (f10204r0) as obsolete. ↩
5. NVM Express, Inc. NVM Express Base Specification, Sanitize command. ↩
6. JEDEC. JESD84-B51, Embedded Multi-Media Card (e·MMC) Electrical Standard. Section 6.6.9 (Erase, including Secure Erase, CMD38) and Section 6.6.40 (Secure Write Protect Mode and Clear Write Protect, CMD29). ↩