SSD and NVMe Media Sanitization and Cryptographic Erase
Host-level overwrite does not prove SSD sanitization because logical blocks are decoupled from physical NAND by wear leveling, remapping and over-provisioning.
The magnetic-disk rule “overwrite the file several times” does not transfer cleanly to SSDs. Writing new bytes to the same logical block does not guarantee that the controller overwrites the same physical NAND cells.
From a digital-forensics perspective, deletion and making data non-recoverable are different operations.
LBA is not a physical cell
The operating system sees logical block addresses. The Flash Translation Layer maps them to physical flash while performing wear leveling, garbage collection, bad-block remapping and over-provisioning.
A host overwrite can therefore leave previous physical pages outside the current logical mapping.
Why overwrite is not proof
Overwriting confirms new logical content, not erasure of every stale physical representation. File-level multi-pass overwrite is consequently a weak sanitization claim on flash media.
TRIM is not sanitization
TRIM tells the device that logical blocks are no longer needed. It helps storage management but does not prove when or how underlying cells were erased.
Clear, Purge and Destroy
NIST SP 800-88 distinguishes sanitization strength. Clear addresses ordinary logical recovery; Purge applies stronger media-specific techniques; Destroy physically renders media unusable.
The method depends on media type, sensitivity, reuse and policy.
Cryptographic erase
On a correctly designed self-encrypting device, destroying the relevant media-encryption key can make ciphertext inaccessible without rewriting every NAND cell.
The guarantee depends on whether data was encrypted from the start, whether the key covers all relevant media and whether key destruction is implemented correctly.
NVMe capabilities
NVMe sanitize/format behavior is controller- and firmware-dependent. I verify advertised device capabilities and the relevant specification/vendor documentation instead of assuming that a generic delete command reaches the controller's sanitization layer.
Verification is separate
A sanitization workflow needs evidence of completion: controller status, post-operation checks, device identity and a recorded method/result.
File-level secure deletion has a boundary
An application normally cannot force an SSD controller to reveal and erase every stale physical copy of one file. Whole-device sanitization or cryptographic erase is the meaningful boundary when the requirement is strong non-recoverability.
The forensic view is the reverse of the same problem: controller indirection explains why remnants can survive normal deletion.
References
- NIST SP 800-88 Rev. 2, Guidelines for Media Sanitization
- NVM Express Base Specification