Sources

The Secure Erase Lab is an illustrative model, not vendor data. The trends are real. The exact numbers belong to no real drive. This file lists the claims the lab makes, says where each one comes from, marks the ones that are assumptions.

Checked on 2026-10-04 and reconfirmed against the primary texts the same day: the NVMe Base Specification 2.1 PDF at nvmexpress.org, Microsoft Learn pages, the hdparm 9.65 source (SourceForge), the nvme-cli source for v2.0 to v2.16 and v3.1 (GitHub), NIST SP 800-88 Rev. 2 and the Wei et al. paper. The ATA text is the T13 working draft ACS-3 (T13/2161-D revision 5, 2013-10-28, a copy at read.seas.harvard.edu) and the ATA8-ACS draft (T13/1699-D revision 4a). Added later the same day: the ACS-4 working draft rev 14 (T13/BSR INCITS 529, 2016-10-14), read from the archive.org snapshot 20170319195938 of the file t13.org then hosted openly at Documents/UploadedDocuments/docs2016/di529r14-ATAATAPI_Command_Set_-_4.pdf. It is a draft, not the final INCITS 529-2018. The ACS-5, ACS-6 and ACS-7 drafts are on t13.org but anonymous requests are refused (HTTP 403, “Please log into your account”) and the archive.org snapshots of those paths hold only that refusal page, so their wording was not read. The final ACS-3 and ACS-4 text, ACS-5, ACS-6, ACS-7 and IEEE 2883-2022 itself (sold by IEEE) were not read. Section numbers are from those documents. nvme-cli behavior is for the version a row names.

Rules the lab states

Claim	Source
Wei et al. tested 12 SSDs. Eight said they supported the ATA security feature set. One of those encrypted, so it could not be verified. Of the other seven, only four executed the erase command reliably.	Wei, Grupp, Spada and Swanson, Reliably Erasing Data From Flash-Based Solid State Drives, USENIX FAST ’11, section 3 and Table 1
One drive reported that sanitization succeeded and left all its data intact. The paper does not name vendors or models.	Wei et al., same paper
Overwriting a whole drive twice was enough on most drives tested, with three exceptions, so it is not universally reliable. Every single-file overwrite protocol failed on SSDs.	Wei et al., same paper, section 3 and Table 3
SSDs carry between 6% and 25% more physical flash than they advertise, and leftover stale copies were found in the spare area.	Wei et al., same paper
A built-in command should be tested before it is trusted, and standards offered no way to verify it.	Wei et al., conclusions
Clear applies logical techniques to all user-addressable storage with the interface the user has. Purge makes recovery infeasible with state-of-the-art laboratory techniques and can use overwrite, block erase or cryptographic erase through dedicated device commands. Destroy leaves the media unusable.	NIST SP 800-88 Rev. 2, Guidelines for Media Sanitization, sections 3.1.1 to 3.1.3
For SSDs with overprovisioning, multi-pass overwrite practices should be avoided because very little confidentiality protection is achieved. A simple overwrite can leave a substantial amount of user data unchanged.	NIST SP 800-88 Rev. 2, the discussion of overwrite and section 4.5.2. NIST also notes that multi-pass overwrite history ran from a single pass to as many as 39 and grew up around magnetic media.
Wei et al. doubted that vendors reliably sanitize the key store of an encrypting drive and saw no way to verify it.	Wei et al., same paper, discussion of encrypting drives
Cryptographic erase sanitizes keys. It only covers data that was never stored in plaintext, and escrowed or backed-up copies of the key must be dealt with.	NIST SP 800-88 Rev. 2, section 3.2
NIST lists disintegrate, incinerate, melt, pulverize and shred as destruction techniques. Drilling a hole through a device may only partly damage it, leaving portions accessible with laboratory techniques. NIST gives no particle size.	NIST SP 800-88 Rev. 2, destruction techniques
The scope of a sanitize operation is all locations in the NVM subsystem that can hold user data, including caches and unallocated or deallocated areas of the media. Only the accessible storage can be audited.	NVMe Base Specification 2.1, 8.1.24 and Annex A.2
A sanitize operation in the Restricted Processing, Unrestricted Processing, Media Verification or Post-Verification Deallocation state cannot be aborted and continues after a Controller Level Reset, including across power cycles. While one is in progress every I/O command other than Flush is aborted with Sanitize In Progress (Flush is handled as section 7.2 says), and so is any admin command not listed in the specification’s permitted-commands figure. Confirmed from the 2.1 text.	NVMe Base Specification 2.1, 8.1.24 and the Sanitize command
Format NVM with SES 001b erases all user data regardless of location (the text gives as examples an exposed LBA, a cache and deallocated logical blocks, and does not name overprovisioning). What the media holds afterwards is indeterminate, for example zero or one filled. A drive whose affected data is all encrypted may use a cryptographic erase for it. SES 010b erases it cryptographically by deleting the key. After a successful format the controller does not return previous user data. Confirmed from the 2.1 text.	NVMe Base Specification 2.1, Format NVM and Figure 189
FNA bit 1 (SENS, Secure Erase Namespace Scope) says whether a secure erase performed as part of a format applies to all namespaces in the subsystem. FNA bit 2 (CRYES) says whether cryptographic erase is supported. SANICAP bits 0, 1 and 2 are crypto erase (CES), block erase (BES) and overwrite (OWS). SANICAP bit 3 is Verification Support (VERS), which the lab does not use. Confirmed from the 2.1 text.	NVMe Base Specification 2.1, Identify Controller, Figure 312; wording matches the NVMe Identify decode on the Eyes on Flash site
SECURITY ERASE UNIT, normal mode, writes zeros or ones to LBA 0 through native max. ACS-3 says it does not write user data that was reallocated; the ACS-4 working draft (rev 14, which added the footnote through proposal f16134r1) says that data “may be written”. So the standards do not promise the normal erase reaches reallocated data. Enhanced mode writes a vendor-specific pattern up to the max address and does write reallocated user data. Enhanced mode is optional. The two are not the same operation.	ACS-3 7.39, Table 91; ACS-4 draft rev 14, 7.35, Table 97 and revision history item 90
On successful completion SECURITY ERASE UNIT disables Security and invalidates the User password. Any other result is command aborted, including when the data area is not successfully overwritten. A frozen drive aborts it (Table 11, Frozen column).	ACS-3 7.39 and Table 11; 4.18.5
The ATA specification gives no rule for what an interrupted SECURITY ERASE UNIT does. In ACS-3 the only path back to the Security Disabled state is a SECURITY ERASE UNIT that completes without error, and a power-down leaves a security-enabled drive locked. So what a drive does after a power cycle mid-erase is not specified. One vendor (SSSTC) says its drives restart the erase when power returns, which is that vendor’s design and not a requirement of the standard. ACS-4 draft rev 14 has the same text for power-down from the locked state, the command aborted if the data area is not successfully overwritten, and no resume rule, but it adds a second way out: the locked state also ends when the Sanitize state machine reaches SD4 (Sanitize Operation Succeeded), so a completed erase is the only exit in ACS-3 and one of two in the ACS-4 draft.	ACS-3 7.39, 4.18.11.7 and 4.18.11.8; ACS-4 draft rev 14, 7.35 and 4.21.11; SSSTC, Security Erase page
Sanitize Device (ATA) covers user data areas that are allocated and not allocated, including physical sectors that have become inaccessible, and makes cache contents unreachable. It shall resume after any interruption such as a power-on reset, and a sanitize in progress does not leave its state on a reset. ACS-4 draft rev 14 keeps all of this (4.19.2, 4.19.4, 4.19.10), including that sector reallocation is allowed during a sanitize operation, which ACS-3 already says.	ACS-3 4.17.2, 4.17.4, 4.17.9.4; ACS-4 draft rev 14, 4.19.2, 4.19.4, 4.19.10
Block erase leaves the user area indeterminate. Crypto scramble changes the internal encryption keys and is only reported as supported if all user data is covered. Overwrite fills each physical sector with a four-byte pattern for a pass count where zero means 16 passes, and the data is readable afterwards.	ACS-3 7.36.2, 7.36.3, 7.36.4
The hdparm options –sanitize-status, –sanitize-block-erase, –sanitize-crypto-scramble, –sanitize-overwrite PATTERN (hex:XXXXXXXX, exactly eight hex digits), –sanitize-overwrite-passes (0 to 7), –sanitize-freeze-lock and –sanitize-antifreeze-lock exist in hdparm 9.65. The three erase options need –yes-i-know-what-i-am-doing, and the status and freeze options do not. hdparm sends command B4h (sgio.h) with the feature codes 0000h, 0011h, 0012h, 0014h, 0020h and 0040h, and the key values “Cryp”, “BkEr” and “OW” that ACS-3 requires. hdparm refuses with “SANITIZE feature set is not supported” if IDENTIFY word 59 bit 12 is clear. No man page lists them (9.65 and master checked). The sanitize actions (like –security-erase) are handled in handle_standalone_longarg, which returns “no more flags allowed”, so hdparm stops with “Excess flags given” if any flag follows one. That is why the confirm flag and the passes option come first in every row.	hdparm 9.65, hdparm.c (option table, do_sanitize_cmd, confirm_i_know_what_i_am_doing, get_ow_pattern) and hdparm.h; ACS-3 7.36
On nvme-cli 2.0 through 2.16, `nvme id-ctrl` takes -H and prints the SANICAP and FNA decode. From 2.10 it also decodes with -v. In nvme-cli 3.1 the command is `nvme id ctrl`, the options are only -V and -b plus the global ones, -H is gone, and the decode (including the sanicap and fna lines) is printed under -v. The old `nvme id-ctrl` name is a deprecated alias that forwards its arguments to `id ctrl`, which has no -H. 3.1 still decodes SANICAP bit 0 crypto, bit 1 block erase, bit 2 overwrite and FNA bit 2 crypto erase supported. It labels FNA bit 1 “Crypto Erase Applies to All/Single Namespace” where NVMe 2.1 says secure erase scope.	nvme-cli source: v2.0, v2.4, v2.6, v2.8, v2.10, v2.16 nvme.c __id_ctrl; v3.1 src/nvme.c, plugins/id/id-plugin.c, src/nvme-cmds-deprecated.c, src/nvme-print-stdout.c and Documentation/nvme-id-ctrl.txt
No fixed time is given for crypto erase. NVMe reports the estimated seconds in the Sanitize Status log (ETCE, a count of seconds, 0 meaning the work finishes in the background by the time the command completes, FFFFFFFFh meaning no estimate). NIST says cryptographic erase is much faster than other techniques and “rapid”, and gives no figure. Wei et al. timed one encrypting drive: the sanitize command took under a second. One vendor datasheet (Viking Technology AN0010) says under 4 seconds for cryptographic secure erase on its drive. The lab states no time. No primary source found says “milliseconds”. A vendor press item (Microsemi, seen only in a search summary and not read in full) claims a key erase under 30 ms for its own product. The standards count in seconds.	NVMe Base Specification 2.1, Sanitize Status log page (ETCE); NIST SP 800-88 Rev. 2, 3.2; Wei et al., section 3.2.4; Viking Technology AN0010
Drives may report that a trimmed LBA reads deterministic data (DRAT) or deterministic zeros (RZAT), and ATA does not require either. So a drive that reads zeros after TRIM is allowed and one that does not is too.	ACS-3 7.5.3.2 (Table 33), IDENTIFY word 69 bits 14 and 5
NVMe records a reset that happens during a Format NVM (Reset During NVM Format, RDNF, in the Power-on or Reset Event of the Persistent Event Log), and has no rule to resume it. Only Sanitize is specified to continue after a Controller Level Reset.	NVMe Base Specification 2.1, Persistent Event Log, Power-on or Reset Event (Figure 234) and 8.1.24
Annex A.2 says sanitize operations purge all physical storage in the target that is able to hold user data, and that overprovisioned and retired storage is not accessible through the interface, so only the accessible storage can be audited. It does not say a sanitize reaches retired storage.	NVMe Base Specification 2.1, Annex A.2 (p. 674)
Annex A.4 (“Bad Media and Vendor Specific NAND Use”, informative) says NVMe cannot audit that “any media that could not be sanitized (e.g., bad physical blocks) has been removed from the pool of storage that is able to be used as addressable storage”, and lists “which media has been retired and cannot be sanitized” among the context a chip-off reader loses. So the spec itself allows that some retired media is not sanitized. The same text is in NVMe 1.4 (Annex A.4, “Bad Block and Vendor Specific NAND Use”, pp. 402-403) and 2.3.	NVMe Base Specification 2.1, Annex A.4 (p. 675)
The normative sanitize text (8.1.24) says the scope is all locations that can contain user data, and that if a portion of the user data was not altered and the sanitize completed successfully, the subsystem shall make that portion permanently inaccessible for future use and via any interface, including management interfaces. It does not mention retired media, and “inaccessible via any interface” is not a promise about a chip-off reader. Format NVM SES has no such fallback sentence: it says all user data shall be erased and the contents afterwards are indeterminate.	NVMe Base Specification 2.1, 8.1.24 “Sanitize Operations” (p. 567) and “Sanitize Operation Types and Support” (p. 569); Format NVM, SES; the 8.1.24 sentences are also in 2.3
NIST SP 800-88 Rev. 2 says the target of sanitization is all user data, and that an ISM with more physical capacity than user capacity can hold user data on all of it (2.3, p. 6). It warns that on partial sanitization it is hard to verify data did not spill over into other areas “(e.g., remapped bad blocks or overprovisioning)” (4.2, p. 19), and that a sanitize scoped too narrowly fails validation (4.5.2, pp. 24 to 25). It sends the choice of purge technique to IEEE 2883 and has no rule for retired blocks. Rev. 1 (2014) says the ATA standard requires Sanitize to address “physical sectors that have become inaccessible” (appendix glossary, p. 44).	NIST SP 800-88 Rev. 2, 2.3, 3.1.2, 4.2, 4.5.2; NIST SP 800-88 Rev. 1, Appendix A
In combined SLC-TLC flash storage, data is written to the SLC buffer first and migrated to the TLC region during idle time. If the buffer is exhausted without enough idle time, data is written directly to the TLC region and write speed falls to TLC speed. The study describes consumer flash storage (eMMC and similar), not NVMe SSDs, and its authors treat the sizes and policies as the maker’s choice. The lab’s cache behaves the same two ways.	Kwon, Kang and Eom, An Advanced SLC-buffering for TLC NAND Flash-based Storage, IEEE Transactions on Consumer Electronics 63(4), 2017, sections I, II and III-B (read from the paper)
TRIM tells the drive an address is free and does not erase anything on its own.	Eyes on Flash, Flash Foundations Part 7, TRIM section; TRIM Check
NVMe Sanitize has block erase, overwrite and crypto erase variants, and reports through the Sanitize Status log.	Eyes on Flash, Flash Foundations Part 6, NVMe Sanitize section
diskpart clean all sets every sector of the disk to zero. Plain clean only overwrites partition information (MBR or GPT structures). Confirmed on the live page.	Microsoft Learn, clean (diskpart)
Format-Volume with -Full writes to every sector, and a quick format does not. Confirmed on the live page.	Microsoft Learn, Format-Volume
format with /P zeroes every sector of the volume, then overwrites it count times with a different random number each time, and is ignored with /Q. /NoTrim skips the TRIM a format sends. Confirmed on the live page.	Microsoft Learn, format
cipher /w removes data from unused space on a volume. The page describes no pass count or pattern, so the lab gives none. Confirmed on the live page.	Microsoft Learn, cipher
Clear-Disk with -RemoveData removes the data on the disk. The page describes it as removing partition and volume information and erasing all data on the disk. It does not say how, or that it sends a secure erase. Confirmed on the live page.	Microsoft Learn, Clear-Disk
Deleting the last BitLocker protector disables protection. Suspending leaves the key available on the drive. manage-bde -off decrypts the drive. Recovery information can be backed up to a Microsoft account, Microsoft Entra ID or AD DS.	Microsoft Learn, manage-bde -protectors, manage-bde -off, BitLocker overview
Parted Magic lists ATA Secure Erase and Enhanced, ATA Sanitize (crypto, block, overwrite), NVMe Format with user data or cryptographic erase, and NVMe Sanitize. nwipe 0.43 can sanitize ATA and NVMe drives with the drive’s own commands (block erase, crypto scramble, overwrite) and also offers software overwrite methods such as zeros, DoD and Gutmann.	Parted Magic website; nwipe README
Samsung says its Secure Erase may not work where the BIOS has issued SECURITY FREEZE LOCK, and that the bootable solution needs AHCI mode.	Samsung Magician 8.0 installation guide
Overwrite sanitize is optional.	NIST SP 800-88 Rev. 1, Appendix A (the overwrite command, “if supported”)
Overwrite sanitize is media specific, and multiple passes on NAND may hurt endurance.	NVMe Base Specification 2.1, sanitize types
Samsung, Crucial, WD, Solidigm and Kingston tool behavior as stated in the Windows guidance.	Each vendor’s own documentation, named on the page beside each point

Methods the lab models

Method	Basis
ATA Secure Erase	ACS-3 7.39 Table 91 and ACS-4 draft Table 97 for what it writes; Wei et al., Table 1: the erase unit command, tested on seven drives that supported it
ATA Enhanced Secure Erase	ACS-3 7.39 Table 91: writes all user data and the reallocated data. It is not the same as the normal erase, so the lab no longer treats it as equal. The spare area and SLC cache cells stay assumed because ACS-3 names only reallocated sectors. Wei et al. (Table 1) did test the enhanced erase on the flash chips directly: it left no data on the four drives that supported it and were not encrypted (F to I), but they do not report spare area or SLC cache separately.
NVMe Format, user data erase (SES=1)	NVMe Base Specification 2.1, Format NVM Retired blocks: not guaranteed, from Annex A.4 and the SES text (see the rules table).
NVMe Format, cryptographic erase (SES=2)	NVMe Base Specification 2.1, Format NVM
NVMe Sanitize, block erase	NVMe Base Specification 2.1, 8.1.24 Retired blocks: not guaranteed, from 8.1.24 and Annex A.4.
NVMe Sanitize, overwrite	NVMe Base Specification 2.1, 8.1.24 Retired blocks: not guaranteed, from 8.1.24 and Annex A.4.
NVMe Sanitize, crypto erase	NVMe Base Specification 2.1, 8.1.24

Model values and assumptions

These are teaching values, not measurements. A value marked assumption rests on a modeling choice because no source settles it.

Value	What the lab does	Basis
Geometry	4 dies of 8 blocks of 8 pages, 256 pages in all. One LBA is one page.	Assumption, small enough to draw every page
User capacity	160 LBAs by default (37.5% overprovisioning). The other choices are 25% (192 LBAs) and 50% (128 LBAs).	Assumption. Wei et al. report 6% to 25% extra flash on real drives, so the lab’s spare area is deliberately large.
Write path	Writes take turns across the 4 dies and always go to a new page.	Assumption, the simplest striping
SLC cache	2 blocks that take host writes first and fold into the main blocks when the drive is idle. When both are full, host writes go straight to the main blocks.	Behavior: Kwon et al. 2017 (see the rules table), which describes both. Size of 2 blocks and the exact policy: teaching values, since sizes and policies differ by drive and no vendor document was found. Test 3’s result depends on it.
Garbage collection	Runs when fewer than 2 free blocks remain, taking the full block with the most stale pages.	Assumption. The 2 free blocks are a model value.
Idle collection	Folds the SLC cache, then reclaims blocks that are at least half stale.	Assumption. This is why an overwrite can leave pieces for a long time.
Secret	A file of 12 pieces, one per address.	Assumption
Used and worn drives	About 70% full after a seeded history of edits; the worn drive retires 2 blocks holding the most of the secret. A drive keeps at most 2 retired blocks.	Assumption
Passes	1 to 7 passes.	Assumption. NIST notes histories of 1 to 39 passes.
Trimmed reads	A trimmed address reads zeros.	Assumption as a drive behavior, with a source for the idea: ACS-3 lets a drive report deterministic or zero reads after TRIM (DRAT, RZAT) and does not require them. The lab says only that some drives do this.
Chip-off	Reads every page and the drive’s key store. A page written under a replaced key is unreadable.	Assumption
Retired blocks	A retired block is the lab’s version of a reallocated sector. The normal ATA erase is “Not guaranteed” and the model leaves them alone. The enhanced ATA erase reaches them. NVMe Format and Sanitize are “Not guaranteed”: the model leaves the data in them. Crypto erase covers them through the key.	Normal ATA erase: ACS-3 7.39 Table 91 says not written, ACS-4 draft rev 14 Table 97 says may be written, so it is not guaranteed (changed 2026-10-04 from “No”). Enhanced ATA erase: ACS-3 Table 91 and ACS-4 Table 97 both say written. NVMe Format and Sanitize: settled on 2026-10-04 as not guaranteed, see “Retired blocks, settled” below. It is no longer marked assumed, because the claim is what the spec text supports: no standard requires a sanitize or format to erase retired media, NVMe Annex A.4 says retired media cannot be sanitized, and 8.1.24 only requires unaltered data to be inaccessible through interfaces. Showing the data surviving is the worst case that claim allows. It is not a measured behavior of any drive.
Format NVM and overprovisioning	The lab lets Format SES=1 reach the spare area.	NVMe Base Spec, Format NVM, SES: the erase applies to all user data regardless of location, with examples (an exposed LBA, a cache, deallocated logical blocks) that are introduced by “e.g.” and do not name the spare area. Spare-area blocks are in service and hold user data, so the plain reading is that the scope sentence covers them. This is what the spec requires, not what any drive was seen to do: Wei et al. tested no NVMe drive.
ATA Secure Erase and the spare area	The normal ATA erase reaches the spare area.	Wei et al. filled as much of the spare area as they could, ran the command and read the chips, and four drives were clean. ACS-3 itself only requires LBA 0 to native max, so this is evidence on those drives and not a guarantee of the standard.
Enhanced erase	Reaches the main area and retired blocks from ACS-3. Reaches the spare area and SLC cache as the normal erase does.	The last two are assumptions. ACS-3 names reallocated sectors, not other spare area. Wei et al. tested the enhanced erase on four drives (F to I) with success, without breaking out spare area or SLC cache.
ATA power cycle	The table says “Not specified” for the ATA erase and for Format NVM, and “Yes” for Sanitize.	ACS-3, the ACS-4 draft and NVMe 2.1 give a resume rule only for Sanitize. A drive’s own behavior is its design.
Firmware faults	Two modeled: reports success and does nothing, and skips the spare area.	Wei et al. found the first kind. The second is an assumption.
Action log	Keeps the newest 20 lines.	Interface choice

The method table in the page lists every cell of “what each method reaches” and marks the assumed cells. assumptionCells() in src/lib/secure-erase-methods.ts returns them. The source behind each cell is in src/lib/secure-erase-method-sources.ts, which the tests read and the page bundle leaves out.

Commands

Every command string lives in src/lib/secure-erase-commands.ts. Placeholders are /dev/nvmeX (controller), /dev/nvmeXnY (namespace), /dev/sdX and PASSWORD. Each row cites the option it rests on.

Command	Checked against
`nvme list`	nvme-list(1)
`lsblk -o NAME,MODEL,SERIAL,SIZE`	lsblk(8) -o. The man page does not list column names; NAME, MODEL, SERIAL and SIZE were confirmed in the util-linux source (v2.40).
`nvme id-ctrl /dev/nvmeX -H`	nvme-id-ctrl(1), nvme-cli 2.x, where -H decodes the fields. The source of v2.0, v2.4, v2.6, v2.8, v2.10 and v2.16 has the -H option.
`nvme id ctrl /dev/nvmeX -v`	nvme-cli 3.1: the command is `nvme id ctrl`, there is no -H, and the decode is printed in verbose mode. From 2.10 on, `nvme id-ctrl ... -v` also decodes. The builder shows both forms and says which version each is for.
`nvme sanitize /dev/nvmeX --sanact=0x02`, `0x03`, `0x04`	nvme-sanitize(1). The device is the controller character device. 0x02 is start-block-erase, 0x03 start-overwrite and 0x04 start-crypto-erase. Numeric values are used because named values need nvme-cli 2.x or later.
`nvme format /dev/nvmeXnY --ses=1` and `--ses=2`	nvme-format(1). The device may be the controller or a namespace. The lab uses the namespace node. Without –force, nvme-cli 2.x (v2.16 checked) waits 10 seconds for Ctrl-C.
`nvme sanitize-log /dev/nvmeX`	nvme-sanitize-log(1). In nvme-cli 3.x it is a deprecated alias of `nvme log sanitize`.
`hexdump -C -n 512 /dev/nvmeXnY` and `/dev/sdX`	hexdump(1): -C canonical display, -n length. After a block erase or crypto erase the contents are indeterminate (ACS-3 7.36.2, 7.36.3, NVMe Format NVM), so the row says to expect none of your data, not zeros.
`hdparm -I /dev/sdX`	hdparm(8) -I. The Security lines come from hdparm’s identify code: not frozen, and supported: enhanced erase.
`hdparm --user-master u --security-set-pass PASSWORD /dev/sdX`	hdparm(8) –security-set-pass and –user-master. The man page marks it DANGEROUS.
`hdparm --user-master u --security-erase PASSWORD /dev/sdX` and `--security-erase-enhanced`	hdparm(8). The source requires no extra confirmation flag for these.
`hdparm --user-master u --security-disable PASSWORD /dev/sdX`	hdparm(8) –security-disable. ACS-3 7.39 says a successful erase disables Security and invalidates the User password, so the disable step is only needed if the drive still shows security enabled.
`hdparm --yes-i-know-what-i-am-doing --sanitize-block-erase /dev/sdX`, `--sanitize-crypto-scramble /dev/sdX`	hdparm 9.65 source (hdparm.c option table, do_sanitize_cmd, confirm_i_know_what_i_am_doing); ACS-3 7.36.2 and 7.36.3. Not in the hdparm man page.
`hdparm --yes-i-know-what-i-am-doing --sanitize-overwrite-passes 1 --sanitize-overwrite hex:00000000 /dev/sdX`	hdparm 9.65 source (get_ow_pattern needs exactly eight hex digits; passes 0 to 7, default 0 meaning 16); ACS-3 7.36.4 (pass count zero is 16 passes). Not in the hdparm man page.
`hdparm --sanitize-status /dev/sdX`	hdparm 9.65 source, which needs no confirmation flag for it; ACS-3 7.36.7. Not in the man page.

Checked, resolved on 2026-10-04

Each item below was open before. The result is stated, and none is “unconfirmed” any more.

hdparm ATA Sanitize flags. Confirmed in the hdparm 9.65 source and the ACS-3 text, and built as three method rows plus a status row. They are in no man page (9.65 and master), so the builder row sources say “hdparm 9.65 source, not in the man page”. --sanitize-freeze-lock and --sanitize-antifreeze-lock are real but no erase step uses them, so there is no row. The builder warns about the freeze state instead.
hdparm password cleared after an erase. ACS-3 7.39 says a successful SECURITY ERASE UNIT disables Security and invalidates the User password. No hdparm man page says it, and none was needed.
nvme-cli 3.x. nvme id ctrl, no -H, decode under -v. Both versions are in the builder.
ATA Secure Erase across a power cycle. The ATA text is silent. See the rules table. The table cell says “Not specified”.
Whether a Format NVM secure erase reaches overprovisioned or retired flash. Overprovisioned: the SES text says all user data regardless of location, so the cell is no longer marked assumed (it is a requirement of the spec, not a tested behavior). Retired: not guaranteed, see “Retired blocks, settled” below.
Whether NVMe Sanitize reaches retired blocks. Not guaranteed, see “Retired blocks, settled” below. The cells say “Not guaranteed” and are no longer marked assumed.
SLC cache folding. Settled for the two behaviors the lab models by Kwon et al. 2017: fold during idle time, direct write to the main flash when the buffer is full.
Whether a pending Format NVM resumes after power loss. No rule. NVMe records a reset during a format and does not resume it.
Crypto erase “within milliseconds”. No primary source. See the rules table. The lab gives no time.
Enhanced erase equals normal erase. Not so. ACS-3 Table 91 differs on reallocated data. The model changed.
DRAT and RZAT. ACS-3 7.5.3.2 has them. The lab still says only that some drives read zeros after TRIM.

Retired blocks, settled on 2026-10-04

The question: do NVMe Format (SES=1 or 2), NVMe Sanitize (block erase, overwrite, crypto erase) and the ATA erase and Sanitize commands reach retired (bad, grown-bad, remapped) blocks, and can data survive there?

Does any standard require or exclude retired blocks?
- ATA: both ways. ACS-3 7.39 Table 91: the normal SECURITY ERASE UNIT does not write reallocated user data. ACS-4 draft rev 14 Table 97 relaxes that to “may be written”, so the normal erase neither requires nor excludes them. The enhanced erase does write them. ACS-3 4.17.2: Sanitize Device covers physical sectors that have become inaccessible (quoted in NIST SP 800-88 Rev. 1, appendix glossary). Those are requirements on the command. They are not verified results on any drive.
- NVMe: neither. Sanitize 8.1.24 (2.1 p. 567) has the scope “all locations in the NVM subsystem that are able to contain user data” and, for unaltered data, a duty to keep it inaccessible through any interface. Format NVM SES says all user data is erased and has no such fallback. Neither mentions retired media. Annex A.2 and A.4 (informative) say retired storage is not accessible, cannot be audited, and that “media that could not be sanitized (e.g., bad physical blocks)” may exist. NVMe 1.4 (A.4, pp. 402-403) and 2.3 say the same. Crypto erase (Format SES=2, Sanitize crypto) reaches them through the key.
- NIST SP 800-88 Rev. 2: no rule for retired blocks. It names remapped bad blocks as a place data can spill into (4.2) and defers purge techniques to IEEE 2883.
- IEEE 2883-2022: the standard itself was not read (sold by IEEE). Its scope, as presented by its editor, is in “IEEE 2883 and ACS-4, settled” below.
- JEDEC JESD230C (read): a NAND interface standard that defines factory defect areas and a maximum number of bad blocks over device life. It says nothing about erasing them. JESD218/219/220 were not checked.
What the literature shows about data surviving in retired blocks after a purge.
- Wei et al., FAST 11, section 2.1: on disks, overwriting “may not digitally sanitize bad blocks that the drive has retired from use”. It is a caveat about overwriting. The paper reports no retired-block test, and its failures were firmware bugs.
- Garg et al., arXiv 2001.07424 (survey with software recovery tests), section III-B: when a block reaches its endurance limit the bad block manager remaps it and “data in old physical blocks remain intact”. That is about host-level deletion, not a sanitize.
- Micron, Data Sanitation: Securely Erasing Micron SATA SSDs (technical brief, Rev. B 2/17), pp. 2-3: its Sanitize sends BLOCK ERASE to all NAND including retired blocks, and “every effort is also made to erase data that may exist in retired NAND blocks”. It also keeps the retired-block mapping tables. This is one vendor’s SATA design, not a measurement, and not independent.
Why a retired block may keep its data. Micron’s brief says the most common reason a NAND block is retired is that it could not be successfully erased, and that when an erase fails, more than 90% of the bits in the block are erased and the rest are not consecutive. So a block retired for an erase failure is one the controller already could not clear, and a later erase command may fail the same way. This is one vendor’s statement. NIST SP 800-88 Rev. 2 (3.2.4 and 3.2.5, p. 16) makes the same kind of point for crypto erase: a defect where the key is stored can stop the operation completing.

What the lab says. The cell reads “Not guaranteed”, not “No”: the standards neither require nor exclude it, the NVMe spec says some retired media cannot be sanitized, and one vendor says it tries. The model leaves the data in retired blocks as the worst case that statement allows. Real drives may clean some of it. The lab does not claim any real drive keeps data there after a sanitize.

IEEE 2883 and ACS-4, settled on 2026-10-04

What could be read without a login, and what it settles. The IEEE 2883-2022 text is sold by IEEE and was not read. Everything below on 2883 is quoted in a public presentation by its editor, or is secondary.

IEEE 2883 scope and definitions: quoted in SNIA Security Summit 2022, “IEEE Std 2883 Standard for Sanitizing Storage”, Jim Hatfield (Seagate, chair of the IEEE Security in Storage WG and editor of 2883), slides 9, 26, 32 and 35 (snia.org, Security-Summit/2022/SNIA-SSS22-Hatfield-IEEE-2883-Standard.pdf). Slide 9: sanitization scope is all physical and logical locations that currently contain user data, that “used to contain user data (e.g., deallocated data, data reallocated because of media errors)”, that “could contain user data (e.g., overprovisioning, unused capacity, spare pools)”, and that hold data that discloses user data. Slide 26: Clear is logical techniques “on all addressable storage locations”; Purge uses logical or physical techniques that make recovery infeasible with state of the art laboratory techniques while keeping the device reusable. So for flash, 2883’s scope includes reallocated data and spare pools, and Clear is limited to addressable locations. This is the editor’s summary, not the standard’s text.
Which commands are Clear and which are Purge. Slide 35 lists SECURITY ERASE UNIT (ATA), FORMAT UNIT (SCSI) and Format NVM (NVMe) as “simple overwrite” with the note “there could be physical copies of data that are not erased”, and says the Sanitize commands of SCSI, ATA and NVMe do the “sanitize overwrite”. Slide 32 puts simple overwrite under Clear, and sanitize overwrite, block erase and cryptographic erase under Purge. So the lab’s ATA Secure Erase and NVMe Format SES=1 rows are Clear-tier techniques in 2883, as presented by its editor. A vendor blog (Returna, secondary) reports the same for ATA Secure Erase on SSDs. The lab’s page does not state any 2883 level.
Retired blocks in 2883. The scope list in item 1 names data “reallocated because of media errors”, which is the closest the editor’s slides get to retired blocks. No source read says that a particular command must reach them. NIST SP 800-88 Rev. 1 says Clear “applies logical techniques to sanitize data in all user-addressable storage locations”. So: 2883’s scope covers them, its Purge techniques are the Sanitize commands, and the Sanitize commands differ in what they promise (ATA: inaccessible physical sectors; NVMe: nothing explicit). The “Not guaranteed” cells for NVMe stay as they are.
ACS-4 working draft rev 14 (2016), the parts that bear on the lab. 4.19.2: sanitize operations affect user data areas “currently allocated” and “not currently allocated (e.g., previously allocated areas and physical sectors that have become inaccessible)”. 4.19.4: the operation “shall resume after any interruption (e.g., a power-on reset)”, and “Sector reallocation is allowed during sanitize operations”. 7.35 Table 97: normal erase “may be written” for reallocated data (ACS-3: not written), enhanced erase writes it. 7.35.5: command aborted if “the data area is not successfully overwritten”. 4.21.11: SEC4 (locked) goes to SEC3 on power-down and to SEC1 only when the erase completes without error; there is no resume or restart rule. So an interrupted SECURITY ERASE UNIT is not specified, in ACS-3 or in the ACS-4 draft.
Does ATA Sanitize or enhanced erase cover reallocated and inaccessible sectors in newer revisions? ACS-4 draft: Sanitize yes (4.19.2), enhanced erase yes (Table 97). Normal erase: may.

Myths the lab tests

The last test of the walkthrough runs seven of these on the model, and three are answered from the sources. The page lists each claim, its verdict and its source. The reasoning is here.

Emptying the Recycle Bin erases the file. No. Emptying the bin removes the file from the file table. In this model the drive is not told, so the data stays where it was written. A real file system with TRIM on may tell it (test 1). Source: Test 1 of this lab, the model run above.
A quick format wipes the drive. No. A quick format builds a new file system and leaves the data alone. Microsoft says a full format writes to every sector and a quick one does not. Source: Microsoft Learn, Format-Volume.
TRIM is a secure erase. No. TRIM tells the drive an address is free. The drive may read zeros afterwards, but the pieces stay on the chips until garbage collection erases their blocks. TRIM has no reliable effect on data security. Source: Wei et al., FAST 11, section 3.3 footnote 2; TRIM Check.
A 3-pass or 7-pass overwrite is safer on an SSD. No. Multi-pass habits come from magnetic media. NIST says that for SSDs with overprovisioning such practices should be avoided, because very little confidentiality protection is achieved. Wei et al. found that every single-file overwrite protocol they tried failed on SSDs. Extra passes cost NAND writes and do not target the old copy. Source: NIST SP 800-88 Rev. 2, section on overwrite; Wei et al., FAST 11, Table 3.
diskpart clean all or writing zeros with dd purges an SSD. Not by itself. Writing zeros to every address is a Clear in NIST terms (our reading, not a Microsoft statement). Wei et al. found that overwriting a whole drive twice was enough on most drives they tested, and not on all of them. NIST warns that on a drive with overprovisioning it can leave a substantial amount of data unchanged. For a Purge, use a command the drive runs itself. Source: Microsoft Learn, clean (diskpart); NIST SP 800-88 Rev. 2, 3.1.1 and 4.5.2; Wei et al., FAST 11.
An erase command always works. No. Wei et al. tested 12 SSDs. Eight said they supported the ATA security commands. One of those encrypted, so they could not check it, and of the other seven only four ran the erase reliably. One drive reported success and left all of its data in place. The paper says to test each implementation before trusting it. Source: Wei et al., FAST 11, section on built-in commands and Table 1.
Crypto erase is too fast to be real. Real, with a condition. It changes the media encryption key, so no block has to be erased and the old data becomes noise. NIST adds a condition: no sensitive data may ever have been stored unencrypted, and any other copy of the key has to be dealt with. Wei et al. doubted every vendor sanitizes the key store properly, and saw no way to verify it. Source: NIST SP 800-88 Rev. 2, 3.2; NVMe Base Specification 2.1, Format NVM SES 010b and Sanitize SANACT 100b; Wei et al., FAST 11.
Removing BitLocker protectors erases the drive. No. Deleting the last protector disables protection, and suspending leaves the key available on the drive. Turning BitLocker off decrypts the drive. Recovery keys can be backed up to a Microsoft account, Microsoft Entra ID or Active Directory. None of this is the drive erasing its own key. Source: Microsoft Learn, manage-bde -protectors and manage-bde -off; BitLocker overview.
A drilled hole destroys the drive. Not reliably. NIST lists disintegrate, incinerate, melt, pulverize and shred as destruction techniques. It says techniques like bending, cutting, or drilling a hole through a device may only partly damage it, leaving portions accessible using state-of-the-art laboratory techniques. Source: NIST SP 800-88 Rev. 2, section on destruction techniques.
Pulling the power stops a sanitize. No. The NVMe specification says a sanitize operation cannot be aborted and continues after a controller level reset, including across power cycles. Pulling the plug does not stop it. Source: NVMe Base Specification 2.1, 8.1.24.

What each method reaches

The table the lab page summarizes. A cell marked assumed rests on a modeling choice, because no source settles it. Not guaranteed means the standards neither require nor exclude it. For NVMe Format and Sanitize that is retired blocks: NVMe Annex A.4 says retired media cannot be sanitized, so the model leaves the data there.

Method	Main area	Spare area	SLC cache	Retired blocks	All namespaces	Survives a power cycle
ATA Secure Erase	Yes	Yes	Yes (assumed)	Not guaranteed	Not applicable	Not specified
ATA Enhanced Secure Erase	Yes	Yes (assumed)	Yes (assumed)	Yes	Not applicable	Not specified
NVMe Format, user data erase (SES=1)	Yes	Yes	Yes	Not guaranteed	Depends on FNA	Not specified
NVMe Format, cryptographic erase (SES=2)	Yes	Yes	Yes	Yes	Depends on FNA	Not specified
NVMe Sanitize, block erase	Yes	Yes	Yes	Not guaranteed	Yes	Yes
NVMe Sanitize, overwrite	Yes	Yes	Yes	Not guaranteed	Yes	Yes
NVMe Sanitize, crypto erase	Yes	Yes	Yes	Yes	Yes	Yes

Terms

LBA. An LBA is a logical block address: the number the computer uses for one block of the drive. In this lab one LBA is one page.
File table. The file table is the file system’s list of which files exist and where they live. Deleting a file removes its entry and does not touch the data.
Chip-off. Chip-off means desoldering the NAND chips and reading them without the controller. Here it also means anyone who can read raw pages and the key store.
TRIM. TRIM tells the drive that addresses no longer hold data in use, so it can reclaim the space. It has no reliable effect on data security.
Garbage collection. Garbage collection copies the valid pages out of a block and then erases the block, so the block can be written again.
Out-of-place write. NAND cannot overwrite a page in place. The drive writes new data to a free page and marks the old page stale.
Stale page. A stale page holds data the drive no longer maps to any address. The bytes stay on the chip until its block is erased.
Write amplification. Write amplification is the ratio of NAND writes to host writes. Extra copies raise it.
Overprovisioning. Overprovisioning is flash the drive keeps for itself, beyond the capacity the computer can address. The host cannot reach it.
SLC cache. An SLC cache is a few blocks written one bit per cell, which is fast. In this model the drive folds them into the main blocks when idle.
Retired block. A retired block is one the drive stopped using after it wore out. It keeps whatever it held, the host cannot address it, and an erase command may not clean it.
ATA Secure Erase. ATA Security Erase Unit is a command the drive runs itself to erase its user data. The drive decides how.
Format NVM. Format NVM is the NVMe command that reformats a namespace. Its secure erase setting asks the drive to erase user data, directly or by deleting an encryption key.
Sanitize. Sanitize is a drive command, defined for NVMe and ATA, that erases all user data, including caches, in the background and continues after a power cycle.
Namespace. A namespace is a slice of an NVMe drive that looks like its own disk to the computer.
Media encryption key. The media encryption key is the key a self-encrypting drive uses to scramble everything it stores. Without it, the stored data is noise.
Crypto erase. Crypto erase replaces or deletes the media encryption key. The old data stays on the chips but can no longer be decrypted.
Sanitize Status log. The Sanitize Status log is where an NVMe drive reports whether a sanitize is running, finished or failed.
Clear, Purge and Destroy. NIST SP 800-88 names three levels. Clear uses normal writes. Purge uses methods that go beyond them, such as block erase or crypto erase. Destroy makes the media unusable.