SSD sanitization: why TRIM and a successful command are not enough

Published 10 October 2026 · Evidence review, not an erasure certificate

Deleting a file, releasing its blocks and sanitizing its data are different operations. Before releasing an SSD, identify the required assurance, the exact operation and the evidence that it finished successfully.

The address you overwrite is not the flash page you remember

An SSD's flash translation layer maps logical addresses to physical pages. An update can place the new version elsewhere while leaving the previous bytes outside the host-visible mapping. Reading the new value through that mapping does not inspect the old location. [1, section 2.2]

The practical question is therefore not simply whether a file can still be opened. It is which recovery path the chosen process is meant to resist. NIST SP 800-88 Rev. 2 distinguishes clear, purge and destroy; its September 2025 edition replaces Rev. 1. Clear addresses recovery through the ordinary interface, purge targets more capable recovery while potentially preserving reuse, and destroy makes the medium unusable. These are assurance categories, not interchangeable button labels. [2, section 3.1]

Four operations, four different questions

Engineering comparison, not a product certification or a universal command recipe.
Operation	Question it addresses	Evidence still needed
File deletion	Is the file still named in this filesystem?	Whether target data remains elsewhere.
Ordinary discard / TRIM	Which logical ranges may the device reclaim?	A separate sanitization assurance.
Device sanitize	Did the supported device operation run?	Its final status and suitability for the medium.
Cryptographic erase	Can target ciphertext still be decrypted?	Encryption coverage and sanitization of applicable keys.

Even Linux's terminology distinguishes ordinary discard from secure discard. The latter requests erasure of copies created by garbage collection and requires device support. A tool accepting an option is not a reason to assume every drive or intervening storage layer supports it. Direct block-device discard is destructive; it is not a harmless diagnostic. [4]

What the FAST experiment actually established

Wei, Grupp, Spada and Swanson wrote identifiable patterns, applied erasure procedures, then read raw flash chips using custom hardware. Of 12 SSDs examined, eight advertised ATA SECURITY support; one encrypted drive could not be verified. Four of the remaining seven executed ERASE UNIT reliably. One reported success while data remained intact. [1, section 3.2.1 and Table 1]

The denominator matters: seven verifiable implementations, not twelve modern drives. This 2011 laboratory sample is not a present-day NVMe failure rate, and unverified encryption is not a demonstrated failure. The durable lesson is methodological: distinguish an implementation's report from independently established behavior.

NVMe: the command can finish before the operation

The cited NVMe Base Specification 2.0e defines Block Erase, Overwrite and Crypto Erase actions, subject to controller support. Sanitization runs in the background. A successful command completion does not establish that the operation finished. [3, section 5.24]

Progress alone is insufficient. In its Sanitize Status log, SPROG is FFFFh whenever the status is not in-progress, including failure or no prior sanitization. Inspect SSTAT, not just an apparently full progress counter. [3, section 5.16.1.25, Figure 272]

The nvme-cli project documents a read-only sanitize-log query. Its current documentation uses nvme log sanitize; older releases use nvme sanitize-log. Match documentation to the installed version. Retrieving the log is distinct from starting a destructive operation. We did not issue either operation to a drive. [6]

Readback has another subtlety: NVM Express explains that post-sanitize reads can encounter integrity-check behavior, and deallocation can determine what the host sees. A page of zeros is not a direct photograph of NAND. Conversely, a read error alone does not establish that an otherwise documented sanitize operation failed. Interpret it using the selected operation and device documentation. [5]

Crypto erase moves the proof obligation to the keys

Cryptographic erase can make target data inaccessible without rewriting every ciphertext block. But the encryption must have covered the sensitive data, the cryptography and key management must be suitable, and the required key copies must be sanitizable. Enabling encryption immediately before disposal cannot retroactively protect plaintext remnants. NIST explicitly discusses earlier plaintext and backed-up or escrowed keys. [2, sections 3.2.2-3.2.3]

A password reset is not automatically destruction of the data-encryption key. Nor does a drive-local action erase a separate backup. Inventory the relevant data and key copies, then assess each within its own storage and retention boundary. Long-lived confidentiality also matters because ciphertext may remain after key sanitization. [2, section 3.2]

A useful release record contains evidence, not just a green tick

NIST separates verification, checking the operation's outcome, from validation, deciding whether that outcome is acceptable. Rev. 2 does not call for elaborate post-sanitization sampling unless organizational policy requires it. The historical chip-reading experiment is not a requirement to dismantle every drive. [2, section 4.5]

The following checklist is Hesela's operational synthesis of those distinctions:

Identify the asset, model, serial number, firmware and intended destination. Establish the target data and whether the medium will be reused.
Record the approved method, specific technique, tool version and supported device capability. A missing capability is a reason to choose another approved route.
Preserve the final operation result, errors and anomalies. Keep command acceptance separate from operation completion.
For cryptographic erase, record encryption coverage and the treatment of relevant key copies. Include backups and escrow in the assessment.
Document the validation decision and responsible operator. Quarantine a failed or uncertain result instead of treating it as ready for transfer.

Use an organization-approved procedure and device-specific documentation before any destructive action. The intended consequence is permanent data loss; this review deliberately provides no executable erase command.

Method, limits and the next unanswered question

We reviewed the full FAST paper's mechanisms, experiment design and erasure results, NIST's method and assurance guidance, and the named NVMe sections. We collected no new device measurements and did not reproduce the chip-level experiment. No manufacturer is rated here, and no universal recovery probability is inferred.

A valuable follow-up would test whether a deployment workflow records command acceptance and final operation status as separate events, using a disposable test fixture. That could validate the workflow without claiming to validate physical erasure. A hardware assurance study would require a separate design, suitable equipment and explicit authorization.

Corpus: data sanitization, NVMe Sanitize, cryptographic erase, TRIM. Related: what NVMe health logs do and do not show.

Primary sources

Accessed 10 October 2026. NIST DOI: 10.6028/NIST.SP.800-88r2. NVMe 2.0e is the explicitly cited revision, not a claim that it is the newest specification.