What an erase command
can prove.

An erasure claim needs a defined target, a recovery threat and evidence that the operation reached the relevant storage. Counting overwrite passes answers only part of that question.

Consider a hypothetical laboratory retiring a drive. Its technician runs an erasure tool, receives a successful completion message and records the device as ready for reuse. What has the laboratory learned? The answer depends on the relationship between the command, the physical storage and the information the laboratory intended to remove.

That relationship connects an older forensic debate with a continuing engineering problem: deciding which observation justifies releasing a device from control.

Keep the original question in view

My 2008 conference paper with Dave Kleiman and Shyaam Sundhar R.S., Overwriting Hard Drive Data: The Great Wiping Controversy, examined claims about recovering overwritten hard-drive data and the supposed need for many overwrite passes. The publisher's abstract identifies head positioning and residual magnetic information as central to that debate.

The paper belongs to a particular technological setting. Carrying its question forward means identifying what was overwritten, how it was stored and which recovery mechanism is being considered. A claim about magnetic recording cannot silently become a guarantee about every device presenting a familiar disk interface.

A method travels with its assumptions

Peter Gutmann makes a related distinction in the later commentary on his 1996 secure-deletion paper. The well-known 35-pass sequence combined patterns aimed at several recording technologies. His epilogue rejects treating the entire sequence as a universal ritual, irrespective of the encoding actually used.

His further commentary also separates magnetic media from solid-state drives. Repeating a host-level write does not establish that every earlier physical location holding the data was reached. The flash translation layer can place new writes elsewhere while older physical contents remain outside the address space exposed to ordinary software.

This is a useful way to read historical security research. Preserve the mechanism and its conditions when carrying a result into a new setting. A familiar operation name does not preserve the underlying hardware.

Test beneath the interface

Michael Wei, Laura M. Grupp, Frederick E. Spada and Steven Swanson investigated that boundary in their 2011 USENIX study of SSD sanitisation. They inspected raw flash contents after applying erasure techniques, rather than relying only on what the drive returned through its normal interface.

In their tested devices, built-in sanitisation commands could work, but some implementations were incorrect. Overwriting the entire visible address space twice usually succeeded, yet did not always do so. The hard-drive-oriented individual-file techniques they examined failed to sanitise those SSDs.

These are historical experimental findings, with the scope of the tested hardware and methods. Their continuing methodological value is the separation between issuing an operation and examining the storage beneath the interface that issued it. They do not supply a failure rate for present-day drives.

Separate completion from adequacy

NIST SP 800-88 Revision 2, published in September 2025, frames sanitisation around making recovery infeasible at a specified level of effort. It distinguishes verification of an operation's outcome from validation of whether that outcome adequately protects the target data.

A successful status can therefore leave the choice or scope of the method unresolved. Sections 4.5.1–4.5.2 address completion, errors, anomalies and suitability. Revision 2 does not require elaborate post-erasure content sampling unless organisational policy requires it.

Cryptographic erasure introduces another boundary. Sections 3.2.2–3.2.3 require attention to prior plaintext storage and all relevant key copies. Removing one key cannot support a complete confidentiality claim while another usable copy survives. The history of encryption and key management becomes part of the erasure assessment.

Spend assurance effort on the unresolved claim

Return to the hypothetical laboratory. Suppose its record contains only a device identifier, elapsed time and the word “successful”. Those fields may be accurate, but they leave the release decision difficult to audit. A reviewer cannot reconstruct which recovery threat the operation was meant to address or why its scope was sufficient.

The research question is where an additional unit of checking changes that decision. If uncertainty concerns an inaccessible storage region, another observation of the same visible region may add little. If it concerns an unexamined implementation, a longer runtime alone supplies no direct evidence about that implementation. This is an inference from the distinctions above, rather than a new measured result.

A useful comparative study would state the device and firmware population, the target data, the permitted recovery effort and the acceptance rule before testing. It would record incomplete operations and ambiguous outcomes alongside successful ones, then compare total effort with the assurance actually established. No such new experiment is reported here.

The practical contribution of this perspective is a more precise question for security engineering: which uncertainty has the procedure reduced enough to justify the next action? A defensible erasure decision connects its evidence to that action, with its remaining limits visible.