Overwrite, Block Erase or Crypto Erase: Choosing the Wipe Method per Drive, and Verifying Each One

"Verify 10% of the drive" assumes the wipe left something you can check. For an overwrite it did. For a cryptographic erase it didn't. And whether a drive gets an overwrite or a purge in the first place often depends on who happened to pick the method from a menu.

This article covers the three ways a drive is usually sanitized, why the method should be chosen per drive from what the drive supports, what to do when purge isn't available, and how to verify each method honestly.

---

1. Three ways to sanitize a drive

NIST Rev. 2 describes Clear as protecting against "simple, non-invasive data recovery techniques using the same interface that is available to the user," and purge as making recovery infeasible "using state-of-the-art laboratory techniques" while keeping the drive "in a potentially reusable state." It says "When possible, the purge sanitization method should be used instead of the clear sanitization method," and points to IEEE 2883 for the specific techniques, "using dedicated, standardized device sanitize commands."

On SSDs the difference matters. Overprovisioning and wear leveling mean an overwrite through the host interface may not reach every physical block, which is why NIST gives "an ISM that employs overprovisioning" as an example of a sanitization scope that was "too narrowly focused."

2. The method should come from the drive, not the operator

Which purge a drive can run depends on its interface (NVMe, SATA, SAS), its model and firmware, and sometimes on the station it's plugged into. A single laptop can hold an NVMe boot drive and a SATA data drive with different capabilities.

Asking an operator to choose from a menu creates three problems:

• Inconsistency. Two technicians pick differently for the same drive model.
• Silent downgrades. Choosing "overwrite" because it always works turns a purge-capable drive into a Clear.
• No reason on record. Nobody can later explain why a drive got the method it got.

The better pattern is for software to read each drive's reported capabilities and apply a fixed order of preference, every time. The operator confirms; the drive decides.

3. When purge isn't available

Two common reasons a purge can't run:

• The drive doesn't support it, or doesn't support it through the interface available on that station.
• ATA security is frozen. Many system firmwares put SATA drives' security features into a frozen state at boot, which blocks Secure Erase until the drive is power-cycled unfrozen. Software should detect this and not attempt the command.

What happens next should be a policy decision, not an operator's call. ADISA's Data Capability Requirements make the choice explicit:

• DIAL 2: "If PURGE commands are not supported by the firmware the software shall fall back to CLEAR."
• DIAL 3: "If PURGE commands are not supported by the firmware the software shall FAIL the sanitisation process."

Either way, the record has to tell the truth. A fallback overwrite is Clear, and the certificate must say Clear.

4. How to verify each method

Overwrite. You wrote a known pattern, so read sectors back and check for it. How much to read back is a policy decision; we covered the 5%, 10% and 100% figures in our verification guide.

Block erase. Read-back still works, because the drive is left in a known erased state. The catch is what that state is. Controllers differ: some return zeros after a block erase, others return all ones (0xFF). A check that assumes zeros will fail a correctly erased drive, and worse, can make a good erase indistinguishable from a wipe that never happened. Determine the erased state first, then verify against it.

Cryptographic erase. A byte comparison is the wrong check. After the key is destroyed the drive can return old ciphertext, zeros or anything else. NIST Rev. 1 described the most effective approach as reading pseudorandom locations before the erase and again after, then comparing, noting that the area covered "may be relatively small" but should span the drive. ADISA's DIAL 3 still requires purge plus verification of 100% of user addressable space, so check what your contract requires for crypto-erased drives.

5. Crypto erase needs more than a verification result

Verification shows the data you sampled is gone. It can't show the conditions that make cryptographic erase trustworthy in the first place. NIST Rev. 2 is explicit about these.

Its FAQ lists preconditions, including that "no sensitive data can have been stored on the ISM in plaintext prior to the encryption keys being established," a security strength of at least 128 bits, and keys "permanently sanitized using zeroization methods." Section 3.2.5, "Traceability of CE Operations," says the evidence "may need to be augmented" with details such as the encryption algorithm and key strength, how keys are generated and wrapped, which areas of the drive are encrypted, whether keys were ever escrowed or injected, and how the drive handles errors that stop the erase from completing.

Most of that comes from the drive manufacturer, not from any wiping tool. NIST's own advice, via ISO/IEC 27040, is to seek independent validation "or ask the ISM vendor." In practice, a crypto-erase record is strongest when it pairs the verification result with the drive model's documented cryptographic properties.

6. What the certificate should say

For every drive:

1. The method that actually ran (Clear or Purge) and the technique.
2. Why that method was chosen, including any fallback and its reason.
3. The verification method that fits the technique, and its result.
4. Who approved it.

A certificate that says "Purge" for a drive that was overwritten, or reports a byte read-back for a crypto erase, is wrong even if the drive is clean.

7. Where reCore fits

reCore chooses the method automatically. The station reads what each drive reports it supports and picks a hardware purge in a fixed order: NVMe crypto erase, NVMe format, NVMe sanitize, ATA Secure Erase, then SAS sanitize. Every drive gets its own decision, and the operator doesn't have to pick from a menu.

• Frozen drives are skipped, not forced. If ATA security is frozen, Secure Erase isn't attempted.
• Fallbacks are labelled. Without a hardware purge, reCore overwrites (with a random pattern on SSDs, since some controllers handle all-zero writes specially) and the certificate records Clear. Organizations that set ADISA DIAL 3 get no fallback: the wipe fails.
• Verification matches the method. Overwrites are read back against the pattern written. Block erases are read back against the erased state the drive actually returns, which reCore determines first. Crypto erases are checked by writing marker data before the erase and confirming afterwards that it can't be read.
• Coverage is set by policy. At least 10% of the drive by default, 100% at DIAL 3.

Limits worth knowing: NVMe purge runs from reCore's Linux boot environment, not its Windows one; SAS sanitize is in the order but hasn't been validated on hardware yet; and reCore doesn't record a drive's encryption state or the manufacturer's cryptographic details, so the Section 3.2.5 evidence for crypto erase has to come from the drive vendor. More on the data wipe page.

Conclusion

The verification percentage only means something once the method is right, and the method should come from the drive, not from whoever is at the bench. Choose per drive from reported capabilities, decide in policy what happens when purge isn't possible, verify each technique the way it can actually be verified, and make the certificate say what really happened.

---

Sources

• NIST, SP 800-88 Rev. 2, September 2025. Sections 3.1.1, 3.1.2, 3.2.4, 3.2.5 and 4.5.2.
• NIST, FAQ for SP 800-88r2, July 16, 2026, Q9.
• NIST, SP 800-88 Rev. 1, December 2014, Section 4.7.3 (superseded by Rev. 2).
• ADISA, Data Capability Requirements v6.3, sanitisation requirements by media type.