Firmware-Level Data Sanitisation Across Heterogeneous Drives: A Field Study

Background

NIST SP 800-88 Rev. 1 defines three levels of media sanitisation: Clear (overwrite through the normal interface), Purge (a state from which recovery is infeasible even with laboratory techniques, typically via a firmware operation), and Destroy (physical). The standard is careful and widely cited. What it does not — and cannot — tell you is which of these a specific drive in front of you will actually perform, or through which command.

This study grew out of building a sanitisation tool for an ITAD workflow where devices arrive already wiped and without an operating system, so erasure has to be driven from a bootable Linux environment reading the drives directly. The intention was one erase routine. What field testing produced was a dispatch problem.

The capability gap

The central finding is that a drive's sanitisation capability is not a single fact. It is different depending on which command set you ask through.

A Dell NVMe SSD, queried with nvme id-ctrl, reported that it did not support cryptographic erase via the FORMAT NVM command. A tool that trusted that answer would conclude the drive could not be purged and fall back to a full overwrite. But the same drive's sanitize-capability register advertised both crypto erase and block erase through the separate SANITIZE command. The capability was present; it was simply reachable through a different door.

This was not an isolated quirk. It reflects a general truth: many NVMe drives expose Purge-level operations only through SANITIZE, not through FORMAT. A sanitisation tool that implements one path and not the other will silently downgrade compliant hardware to a weaker method.

SATA presents a different obstacle. ATA Secure Erase is routinely blocked at boot because the host issues a security freeze during power-on specifically to prevent it. Lifting the freeze requires a controlled suspend/resume cycle. Worse, ATA Secure Erase sets a drive password before erasing; an erase that fails partway leaves the drive locked and, to a warehouse, indistinguishable from dead. The routine must therefore always run the password-disable cleanup, so a failure degrades to "not erased" rather than "bricked."

A dispatch model

The consequence is that a single erase command is the wrong abstraction. What is needed is a capability-ordered dispatch: for each drive, attempt the strongest supported method and fall back only as far as necessary.

1. NVMe — try FORMAT with cryptographic or secure-erase setting; if unsupported, try SANITIZE (crypto, then block erase); only then fall back to overwrite.
2. SATA/SAS — attempt ATA Secure Erase, handling the frozen state, with enhanced (crypto-on-SED) erase preferred where available; fall back to overwrite.
3. Overwrite — a single zero pass through the normal interface, as the universal floor (a NIST Clear).

Every command targets exactly one device explicitly. There is deliberately no whole-bus operation, because a routine that can act on several drives at once is a routine that can act on the wrong one.

Method-aware verification

The most consequential finding concerns verification, and it is counter-intuitive.

The obvious check after an erase is to read the drive back and confirm it is zeros. This is correct for an overwrite. Applied to a cryptographic erase it fails every time — and should. A crypto erase does not zero the medium; it discards the encryption key. What remains is the original ciphertext, now permanently undecryptable. It reads as high-entropy noise, because that is exactly what it is.

A verifier that checks all methods the same way will therefore either fail every crypto erase or, if relaxed to accept noise, pass a failed overwrite. Neither is acceptable. Verification must know which method ran:

• Overwrite — sample the medium (in this implementation, the first, middle and last regions) and confirm zeros. If a fast path such as TRIM does not read clean, force a full zero-overwrite and re-verify.
• Cryptographic erase — read-back cannot confirm the outcome. The strongest available evidence is the controller's own completion report, and the result should be recorded as controller-confirmed, not as verified, so the distinction survives onto any certificate issued.

This distinction is not pedantry. "Verified" and "controller-confirmed" are different epistemic claims, and a compliance document that conflates them overstates what is known.

Limitations

The verification here is sampled, not exhaustive; a genuinely audit-grade claim for an overwrite would read the entire surface. The firmware paths were tested on the hardware available and cannot be assumed to generalise to every controller. And the study is a field report from a working operation, not a controlled experiment — its value is in documenting the gap between specified and implemented behaviour, which is precisely the gap a standard cannot close.

Conclusion

Media sanitisation standards describe destinations, not routes. On real heterogeneous hardware the route matters: the same Purge-level guarantee may be reachable through one command and not another on the same drive, and the verification that a purge succeeded depends on how the purge was achieved. A sanitisation tool that treats erasure as one operation with one verification will, on a predictable subset of drives, quietly do less than it claims. Naming the method, and verifying it on its own terms, is what keeps the claim honest.