SSD, SED & NVMe Sanitization: What Actually Works on Flash

Why flash isn't a hard drive

Every sanitization method that works was designed around a model of storage where the address you write to is the place the data physically lives. On a hard drive that's roughly true. On flash it is not true at all, and that single fact is why so many "wiped" SSDs still hand back data.

A solid-state drive does not let the host touch the flash directly. A controller sits in between, running a flash translation layer (FTL) that maps the logical block addresses your operating system sees onto constantly-moving physical NAND cells. It does this for survival reasons: NAND cells wear out after a finite number of program/erase cycles, so the controller spreads writes across the whole chip — wear leveling — and quietly retires cells that start to fail, copying their contents elsewhere and mapping the bad ones out of reach.

Two consequences matter for sanitization. First, over-provisioning: every SSD ships with more physical NAND than its advertised capacity — commonly 7% to 28% more — held in reserve and never exposed in the user-addressable address space. Second, remapped and retired blocks: cells that held your data a moment ago may be marked "stale" and mapped out, still holding their contents, while the controller serves reads from a fresh copy somewhere else.

The methods that fail on flash

Four methods are still routinely applied to SSDs by people who believe they sanitize. On flash, each one fails for a specific, knowable reason.

Multi-pass (or single-pass) overwrite. The host writes patterns across the logical address space; the controller's wear leveling sends those writes wherever it likes and never touches the over-provisioned reserve or the remapped blocks. The classic three-pass and seven-pass rituals descend from guidance written for magnetic media that is decades obsolete — and on an SSD even a perfect logical overwrite can't reach the physical cells that matter.

Degaussing. A degausser destroys data by collapsing the magnetic field that stores it. Flash stores charge in transistors; there is no magnetic domain to collapse. Running an SSD through a degausser does nothing to the data — and NIST 800-88 Rev. 2 is explicit that degaussing is ineffective on flash. (Worse, a strong field can damage the controller enough that the drive won't power on, which people then mistake for "destroyed" while every cell is intact and readable on a bench.)

Factory reset / "reset this PC." An OS-level reset reinstalls the operating system and clears user-visible files. It is not a media sanitization operation, it does not invoke the drive's own erase, and it leaves prior data recoverable. The same is true of deleting partitions and re-imaging.

Quick format and file deletion. Both edit the filesystem's map, not the data. Off-the-shelf tools recover the "deleted" files in minutes.

NIST 800-88 Rev. 2 and the shift to IEEE 2883

NIST Special Publication 800-88 is the document HIPAA, GLBA, PCI DSS, and CMMC point to for "render the data unrecoverable." In September 2025 it was rewritten, and the rewrite changed how you choose a method.

Rev. 2 keeps the three familiar methods — Clear, Purge, Destroy — chosen by the sensitivity of the data and whether the media is leaving your control. What it removes is the cookbook. Rev. 1 contained per-media technique tables; Rev. 2 strips almost all of them and instead instructs organizations to select techniques from IEEE 2883-2022 (the current storage-sanitization standard), NSA specifications, or another organizationally approved standard. The one technique NIST still describes in detail is cryptographic erase, because it applies across all encrypted media.

Two other shifts matter. Rev. 2 is program-focused — it expects a documented sanitization program aligned with SP 800-53 and ISO/IEC 27040, not a one-off wipe. And it adds an explicit trust requirement: for Clear and Purge you must have a basis to trust that the vendor's (or tool's) implementation actually does what it claims. "We ran a wipe tool" is no longer a sufficient answer.

Cryptographic erase and self-encrypting drives

Cryptographic erase (CE) is the method NIST kept, and it's the one that makes fast, defensible flash sanitization possible — when its preconditions are actually met.

A self-encrypting drive (SED) encrypts everything it stores with a media encryption key (MEK) held inside the drive. The data on the NAND is ciphertext; the only thing that makes it readable is the key. Cryptographic erase works by destroying and regenerating that key. The instant the original MEK is gone, every cell of ciphertext — including the over-provisioned reserve and the remapped blocks — becomes unrecoverable noise in one operation, in seconds. This is why CE sidesteps the over-provisioning problem entirely: you're not trying to reach the cells, you're destroying the only thing that decodes them.

The TCG Opal family is the common SED standard in enterprise laptops and drives; many drives are SED-capable whether or not anyone enabled it. That last point is the catch. CE is only as strong as four preconditions:

• Encryption was actually on from first use. If full-disk encryption (or the drive's hardware encryption) was enabled only partway through the device's life, data written in the clear beforehand may still be physically present.
• The cryptography is sound. CE assumes a strong, correctly implemented cipher (e.g., AES-256). A weak or flawed implementation undermines the guarantee — which is exactly the "trust the implementation" point Rev. 2 now makes explicit.
• The key is truly destroyed, not just dereferenced — and any backup or escrow copy of the key (BitLocker recovery keys, MDM-escrowed keys, KMS copies) is accounted for.
• It's verified. The drive must confirm the key was replaced; a "we issued the command" with no confirmation is not evidence.

The native sanitize commands — and their traps

Modern drives can erase themselves through firmware commands far more effective than any host overwrite. They're the right tool — if you know which command, and what each one quietly doesn't do.

Across all of them the rule is the same: a firmware erase is a tool, not a guarantee. IEEE 2883-2022 — the standard Rev. 2 now points to — defines which technique meets Clear versus Purge for each media type, and pairs the command with a verification step. A drive that reports "sanitize complete" has made a claim; verification turns the claim into evidence.

NVMe, M.2, and soldered flash

Form factor decides your options as much as the standard does. The trend in modern hardware runs straight at the hardest case.

A removable 2.5" SATA SSD or an M.2 stick can be pulled, sanitized on a bench, and verified — or shredded to the particle size flash requires (flash needs a much smaller shred size than a hard-drive platter, because a single surviving chip fragment can hold data). But more and more endpoints solder the NVMe flash directly to the mainboard, and a growing number of laptops and tablets use embedded eMMC/UFS storage with no removable drive at all.

When the flash can't be removed and a verified firmware erase isn't available or trustworthy, Destroy is the only method that reaches the bar — and for soldered storage that means destroying the board, not just the device shell. This is why intake matters: a fleet that looks like "10,000 laptops" is really a mix of removable SSDs, soldered NVMe, and embedded flash, each routing to a different method. Sorting that at intake — not at the shredder — is what keeps the program both compliant and economical.

Verification: the step everyone skips

The difference between sanitization and hope is verification. Rev. 2 made this non-optional by adding an explicit requirement to establish trust in the technique's implementation.

Verification means confirming, after the fact, that the data is actually gone — by reading back the media and checking it returns no recoverable data, by confirming the drive reports the sanitize as completed and the key as replaced, or for destruction by inspecting that the medium was reduced to the required particle size. It is the control that catches the drive that reported success while silently doing nothing, the "frozen" SATA drive that never ran, and the crypto-erase that fired against a drive whose encryption was never on.

Under Rev. 2's trust requirement, this extends to the provider: you need a basis to trust that whoever sanitizes your media implements the technique correctly and verifiably. In practice that basis is third-party certification (NAID AAA, which audits process and chain of custody, including unannounced audits) plus per-device verification records — not a vendor's say-so.

Decision table: media and condition to method

The whole guide compresses to this. Match the media and its condition to the method, then verify and document.

Note the split that trips people up: degaussing is a valid Purge for magnetic media and useless on flash. The method follows the physics of the medium, not the shape of the drive.

The evidence a certificate must carry

A sanitization you can't prove is a sanitization an auditor won't accept. For flash specifically, the certificate has to answer "which method, on which device, verified how."

A defensible record captures, per serial number: make, model, and the media type (SATA SSD / NVMe / SED / embedded), because the valid method depends on it; the method applied (crypto-erase, NVMe Sanitize block erase, destruction) mapped to its NIST 800-88 Rev. 2 level and the IEEE 2883 technique; the verification result; the date and the technician; and an unbroken chain of custody from your dock to the point of sanitization. "One lot of assorted drives, wiped" is a receipt. A per-serial, method-by-media, verified record is evidence.

How this maps to your compliance frameworks

None of the major frameworks prescribe a wipe command. They point to NIST 800-88 and require that retired media be rendered unrecoverable — which, for the flash now in every endpoint, means this guide's methods.

• HIPAA requires ePHI be rendered unreadable, unusable, and indecipherable on disposal (45 CFR 164.310(d)(2)); NIST 800-88 is the accepted interpretation, with Purge or Destroy the practical bar for PHI-bearing media.
• GLBA / FTC Safeguards point to NIST 800-88 Destroy-level as the secure-disposal benchmark and require oversight of the disposal vendor.
• PCI DSS requires cardholder-data media be rendered unrecoverable when no longer needed.
• CMMC / NIST 800-171 (MP.L2-3.8.3) requires media sanitization before disposal or reuse, evidenced per device — and an assessor verifies the record, they don't take your word.

In every case the framework inherits NIST's method, and NIST now inherits IEEE 2883's techniques. Get the flash method right and the compliance answer follows.

How CyberCrunch sanitizes flash

Built for exactly the case this guide describes: mixed fleets of SSDs, NVMe, SEDs, and soldered embedded flash, each routed to the method that actually meets Purge — and documented to the serial.

Every engagement runs the decision in Section 08 at intake, by serial: removable flash that can be verifiably erased is crypto-erased or NVMe-sanitized and read-back-verified; flash that can't be trusted to a verified erase — soldered NVMe, embedded eMMC/UFS, drives whose encryption history can't be established — is physically destroyed to the particle size flash requires. Both paths run under chain of custody and produce a serialized certificate that names the media type, the method, the standard, and the verification, backed by NAID AAA process certification and a $10M cyber-liability policy.