NVMe and ATA Sanitize Explained: Crypto Erase, Block Erase, Overwrite

The NVMe Sanitize command and the ATA Sanitize feature set tell a drive's own controller to erase user data everywhere it can live, including caches, spare blocks and space the host cannot address, using one of three methods: Crypto Erase (change the media encryption key), Block Erase (erase the flash blocks) or Overwrite (write a pattern). Older commands such as NVMe Format NVM with secure erase settings and ATA Security Erase do similar work with fewer guarantees, while software overwrites from the host only reach the blocks the host can see.

Below: what each method does inside the drive, how to check support, the exact commands with a device check before every destructive step, how to prove completion, and how it all maps to NIST SP 800-88 Rev 2.

This post goes one level deeper than our explainers on NIST SP 800-88 Clear, Purge and Destroy, why deleted files are recoverable, deep cleaning and secure delete on Linux and what a factory reset removes and what it leaves behind. If you only need the policy view, start with the NIST post. If you are about to wipe a drive today, keep reading.

Key takeaways

• An SSD does not overwrite in place. It writes new data to fresh flash pages and keeps spare capacity the host never sees, so a host side overwrite can leave old copies behind. NIST SP 800-88 Rev 2 says that for SSDs with overprovisioning, multi-pass overwrite "should be avoided as very little confidentiality protection is achieved."
• Sanitize is the device level answer. The NVMe Base Specification says a sanitize operation "purges or clears user data in the sanitization target" as defined by IEEE Std 2883, and its scope covers deallocated media, volatile and non-volatile caches and other internal memory.
• Crypto Erase changes the media encryption keys, so ciphertext stays on the flash but cannot be decrypted. It is fast, usually seconds, but only as good as the drive's encryption and only valid if the data was always encrypted.
• Block Erase applies the flash's own erase operation to every block that can hold user data. Overwrite writes a pattern, up to 16 passes in NVMe, and costs a lot of flash endurance.
• NVMe Format NVM with Secure Erase Settings 1 (User Data Erase) or 2 (Cryptographic Erase) is older and simpler. Sanitize adds a stronger scope, background processing that survives power loss and resets, and a log page that reports the result.
• On SATA, ATA Security Erase and Enhanced Security Erase need a temporary password and an unfrozen drive. ATA Sanitize is the newer feature set with the same three methods as NVMe.
• Confirm completion from the drive's sanitize log page, not the command's exit code.
• NIST SP 800-88 Rev 2 (September 2025) no longer lists device specific techniques. Apart from cryptographic erase, it points you to IEEE 2883 for which method counts as Clear or Purge.
• Wrong device is the most common catastrophic error. Identify the drive by model and serial, not by /dev/nvme0 or /dev/sda, and do it again immediately before each destructive command.

Why SSDs need a different kind of erase

A hard disk stores each logical block at a fixed place on a platter, so overwriting a block really does replace the old data. Host side overwrite tools grew up around that model.

Flash does not work that way. NAND flash is written in pages and erased in much larger blocks, and a page has to be erased before it can be written again. So the SSD controller runs a flash translation layer: when the host rewrites logical block 1,000, the controller writes the new data to a fresh page somewhere else and marks the old page as stale. The stale page holds the old data until garbage collection eventually erases its block. Wear levelling moves data around on top of that, and every SSD carries spare capacity for performance, endurance and replacing worn blocks.

The NVMe specification's informative Annex A on sanitize states the consequence plainly. Many SSDs contain more physical storage than the interface can address, and neither that extra capacity nor any retired storage can be reached from the host. NIST SP 800-88 Rev 2 makes the same point from the policy side: on flash devices with spare cells and wear levelling, a user cannot sanitize every earlier copy of the data by overwriting through the normal read and write interface.

So the only component that can reach every copy is the drive's own controller. That is what the device sanitize commands are for. The host asks; the firmware does the work across all the physical media it manages, including the parts the host cannot see.

The trade-off is trust. NIST notes that relying on dedicated sanitize commands means trusting the device maker to have implemented them as specified. You cannot inspect a spare block from the host. You can only pick the right command, confirm the drive reports success, and keep records.

A short timeline of the standards involved

Every date in this table comes from the issuing body's own page or document.

The NVMe specification's Annex A also records that the Sanitize command was introduced in NVMe Base Specification Revision 1.3, and that Revision 1.4 added extended capability reporting and configuration around the No-Deallocate After Sanitize option. The dates for 1.3 and 1.4 are not on the current specifications page, so they are not in the table.

Format NVM with secure erase versus the Sanitize command

NVMe has two admin commands that erase user data. They are easy to confuse because both can do a cryptographic erase.

Format NVM and its Secure Erase Settings

Format NVM was designed to change a namespace's low level format: the logical block size, metadata size and end to end protection information. Its Secure Erase Settings (SES) field adds an erase to the format. The NVMe Base Specification Revision 2.4 defines three values:

The specification says the erase covers all user data wherever it sits, giving exposed blocks, caches and deallocated logical blocks as examples. That is a strong statement, but Format NVM was not built with the reporting and failure semantics that Sanitize has.

Two Identify Controller fields shape what Format NVM does on a given drive. The Format NVM Attributes (FNA) field says whether a format, and whether a cryptographic erase, applies to one namespace or to all namespaces at once, and whether cryptographic erase is supported as part of a secure erase at all. The nvme-cli documentation adds a warning that matters for every destructive command in this guide: the number in /dev/nvme0 does not mean this controller is the parent of /dev/nvme0n1, and assuming so "may irrevocably erase data on an unintended device."

Sanitize

Sanitize was added in NVMe 1.3 as a dedicated command, and the 2.4 specification is explicit about its intent: a sanitize operation purges or clears user data in the sanitization target, using the definitions in IEEE Std 2883. The scope table in the specification (Figure 770) lists what an NVM subsystem sanitize operation must reach:

• all media allocated for user data, and all deallocated media;
• volatile caches and non-volatile caches that contain user data;
• other volatile memory such as internal buffers;
• media that can no longer be written (for example write protected), which must be made not retrievable;
• log pages and feature values, which are modified as needed to prevent recovery of user data;
• the Controller Memory Buffer and, where present, the Persistent Memory Region and the NVMe-MI persistent data area.

It does not touch firmware, boot partitions, the Replay Protected Memory Block, the serial number, or security credentials.

Revision 2.4 describes two scopes. An NVM subsystem sanitize operation, started by the Sanitize command, covers the whole subsystem. A namespace sanitize operation, started by a Sanitize Namespace command on drives that support it, covers one namespace. The specification warns that sanitizing every namespace one at a time is not equivalent to a subsystem sanitize, because namespace operations leave things like the Controller Memory Buffer alone.

The differences that matter in practice

The Arch Wiki passes on the NVM Express organisation's practical guidance: Sanitize gives more certainty that data was properly wiped, while Format suits everyday use and testing. Our recommendation is the same. Use Format NVM with SES when you are reusing a drive inside your own controlled environment and want a fast reset. Use Sanitize when the drive is leaving your control or the data is sensitive.

What Crypto Erase, Block Erase and Overwrite do inside an SSD

All three are background operations started by the same Sanitize command; the Sanitize Action (SANACT) field picks the method. In nvme-cli the values are 2 for Block Erase, 3 for Overwrite and 4 for Crypto Erase, with 1 reserved for Exit Failure Mode and, on newer drives and tools, 5 for exiting the Media Verification state.

Crypto Erase

Almost every modern SSD encrypts everything it writes to flash with a media encryption key, whether or not you set a password. The controller does this in hardware on every write, so it costs nothing in performance, and the key lives inside the drive.

A Crypto Erase sanitize operation, as the specification describes it, alters user data by changing the media encryption keys for every location on the media that may hold user data. The old ciphertext is still physically on the flash, but nothing can decrypt it.

Three details from the specification are worth knowing.

• Old key copies count. If the drive writes the new key to a different place and leaves the old key where it was, the specification notes that the old key could be recovered with advanced laboratory techniques and used to decrypt the data. It therefore requires the operation to fail if any location holding the old key is not altered.
• Unencrypted data is handled separately. A Crypto Erase cannot sanitize data that was never encrypted, for example data in some internal buffers or memory regions. The specification requires the drive to sanitize those areas by other means, such as block erase for flash or overwrite for volatile memory, as part of the same operation.
• It is fast. An erase that only replaces keys is usually done in seconds. The Arch Wiki shows one drive estimating 34 seconds for Crypto Erase and 174 seconds for Block Erase, with Overwrite not reported. Your drive will differ; the sanitize log reports its own estimates.

NIST SP 800-88 Rev 2 treats cryptographic erase as a purge technique with conditions. The encryption must be at least 128 bit security strength, the random number source must have at least as many bits of entropy as the keys, federal agencies must use FIPS 140 validated modules, and, as a precondition taken from ISO/IEC 27040, no sensitive data may have been stored on the media in plaintext since its last sanitization. NIST also warns that ciphertext stays on the media, so for data that must stay secret for decades, a future break of the cipher or of key protection is a real consideration, and cryptographic erase may not be acceptable for it.

Block Erase

NAND flash has a native erase operation that resets every cell in a block to the erased state. A Block Erase sanitize operation, per the specification, applies a low level, media specific block erase to every location on the media that may hold user data.

That means the controller erases every block that can hold user data, including spare and retired blocks it can still address. It takes longer than Crypto Erase, often minutes, and it costs one program and erase cycle per block, which is negligible for a drive being retired or redeployed.

Block Erase does not depend on the drive's encryption being sound, which is why some policies prefer it, or ask for a Crypto Erase followed by a Block Erase. Annex A notes an audit limitation: the specification does not let you check from the host that blocks which could not be erased (for example bad blocks) were removed from use, and any unencrypted data left in them could be read by removing the flash chips.

Overwrite

An Overwrite sanitize operation writes a 32 bit pattern that you supply to every location that can hold user data. nvme-cli exposes the controls:

• --owpass sets the number of passes, where 0 means 16;
• --ovrpat sets the 32 bit pattern;
• --oipbp inverts the pattern between passes.

Overwrite is the slowest method and the hardest on flash. The Arch Wiki describes it as very hard on NAND endurance and better suited to other memory types. Many consumer NVMe drives do not support it at all, which you can see in SANICAP. On flash, prefer Block Erase or Crypto Erase.

The states a sanitize operation moves through

The 2.4 specification models sanitize as a state machine. In practice you will see:

1. Restricted Processing or Unrestricted Processing. The work is under way. The Allow Unrestricted Sanitize Exit (AUSE) bit chooses which. In restricted mode, if the operation fails, the drive stays in a failed state until you run another sanitize. In unrestricted mode, you can also leave the failed state with the Exit Failure Mode action.
2. Media Verification (optional, newer drives). If you set Enter Media Verification State (EMVS), the drive pauses after sanitizing so you can read the media and check the result before it deallocates anything. In this state, Annex A explains, internal integrity check failures do not turn reads into errors, which is what makes inspection possible.
3. Post-Verification Deallocation. The drive deallocates user data after verification.
4. Idle, with the log page reporting Sanitized or Failed.

While sanitize is in progress, the controller restricts other admin and I/O commands. The specification also says the controller ignores critical warnings in the SMART log, such as read only mode, and still attempts to finish.

Deallocation, integrity checks and why reads can fail afterwards

By default, a drive deallocates the sanitized blocks at the end, so reads return zeros or a fixed pattern. The No-Deallocate After Sanitize option (--no-dealloc in nvme-cli) asks the drive to leave the physical result in place so you can inspect it.

Annex A explains why that is less useful than it sounds. After Block Erase or Crypto Erase, reading raw media can trip the drive's internal integrity checks and return errors instead of data. To keep the media readable, a controller may perform additional media modification, meaning extra internal writes, which adds wear and hides the physical result of the original sanitize operation from any later forensic audit. The SANICAP field's NODMMAS bits tell you whether your drive does this. If you need forensic level sampling, use Media Verification on drives that support it rather than relying on No-Deallocate.

ATA Security Erase, Enhanced Security Erase and ATA Sanitize on SATA drives

SATA drives speak the ATA command set, maintained by the T13 technical committee. They have two separate erase mechanisms.

The Security feature set: SECURITY ERASE UNIT

The older mechanism belongs to the ATA Security feature set, the same one that implements drive passwords. The Arch Wiki describes two commands, SECURITY ERASE UNIT and ENHANCED SECURITY ERASE UNIT. To use either, you must:

1. confirm the drive's security state is "not frozen";
2. set a temporary user password, which enables security on the drive;
3. issue the erase with that password;
4. confirm security is disabled again afterwards, which happens automatically on success.

The ATA standard describes the normal erase as replacing user data with zeros or ones, and the enhanced erase as writing a vendor specific pattern that also covers areas no longer in normal use, such as reallocated sectors. On an SSD, both are implemented by the drive's firmware, which may erase blocks or replace keys rather than literally write patterns. The Arch Wiki points out a useful tell: hdparm -I prints an estimated time for each. If both say 2 minutes on a large drive, the drive is almost certainly a self-encrypting design that replaces its internal key for both, and if the two times are equal the maker has implemented both commands the same way.

Frozen state, and why it blocks you

Many system firmwares send a SECURITY FREEZE LOCK command to every drive at boot, so that malware cannot set a drive password and hold the disk hostage. The hdparm man page describes the effect: a frozen drive "does not accept any security commands until next power-on reset."

hdparm -I /dev/sdX shows "frozen" or "not frozen" in its Security section. The Arch Wiki lists the usual ways out:

• suspend to RAM using S3 (not S0ix) and resume, which often clears the freeze because the drive powers off and the firmware does not re-freeze on resume;
• hot plug the SATA data or power cable with AHCI enabled in firmware setup (risky; it can crash the kernel);
• on some laptops, set a drive password in firmware setup and press Escape at the unlock prompt, which leaves the drive locked but not frozen;
• if none of that works, use the drive maker's own tool.

ATA Sanitize

The ATA command set also defines a Sanitize feature set that mirrors NVMe Sanitize: crypto scramble (the ATA name for crypto erase), block erase and overwrite, plus status, freeze lock and anti-freeze lock commands. Like NVMe Sanitize, it is designed to cover all user data areas, run to completion across power cycles and report status, and it does not need a security password.

hdparm supports it in recent releases, though the options are not described in the man page. Run hdparm --help and look for options that begin with --sanitize. Builds that include them list a status option and one option per method, and hdparm requires its --yes-i-know-what-i-am-doing flag before it will send them.

Side by side

How to check which operations a drive supports

Do this on every drive, every time, before you plan anything. Capabilities vary between models, firmware versions and even capacity points in the same product line.

Identify the drive first

These commands are read only. Run them and write down the model and serial number of the drive you intend to erase.

# Every block device with model, serial, size, transport and mount points
lsblk -o NAME,MODEL,SERIAL,SIZE,TRAN,TYPE,MOUNTPOINTS

# NVMe controllers and namespaces with model, serial and firmware
sudo nvme list

# Stable names that include model and serial; use these in your notes
ls -l /dev/disk/by-id/ | grep -v part

# Anything mounted from the target? This must print nothing for the target drive
findmnt -rn -o SOURCE,TARGET | grep -E 'nvme0|sdX'

Replace nvme0 and sdX with your candidates. If the target holds your running system, stop: boot a live USB image and erase it from there.

NVMe: SANICAP and the Format NVM attributes

nvme-cli 2.x uses nvme id-ctrl. nvme-cli 3.0 and later use nvme id ctrl, and keep the old spelling as a deprecated alias. The -H flag decodes bit fields into readable lines.

# nvme-cli 2.x
sudo nvme id-ctrl /dev/nvme0 -H | grep -E 'Format |Crypto Erase|Sanitize|Overwrite|Block Erase|sanicap|fna'

# nvme-cli 3.x
sudo nvme id ctrl /dev/nvme0 -H | grep -E 'Format |Crypto Erase|Sanitize|Overwrite|Block Erase|sanicap|fna'

The Arch Wiki shows typical output from a consumer drive:

 [1:1] : 0x1  Format NVM Supported
 [29:29] : 0  No-Deallocate After Sanitize bit in Sanitize command Supported
 [2:2] : 0    Overwrite Sanitize Operation Not Supported
 [1:1] : 0x1  Block Erase Sanitize Operation Supported
 [0:0] : 0x1  Crypto Erase Sanitize Operation Supported
 [2:2] : 0x1  Crypto Erase Supported as part of Secure Erase
 [1:1] : 0    Crypto Erase Applies to Single Namespace(s)
 [0:0] : 0    Format Applies to Single Namespace(s)

How to read it:

The specification also requires that if the Sanitize command is supported, SANICAP is non-zero; if it is zero, the drive has no Sanitize at all and Format NVM is your only device level option.

Also check the drive's own time estimates, which come from the sanitize log page:

# nvme-cli 2.x
sudo nvme sanitize-log /dev/nvme0
# nvme-cli 3.x
sudo nvme log sanitize /dev/nvme0

Look for the lines named Estimated Time For Overwrite, Block Erase and Crypto Erase. A value of 4294967295 means the drive reports no estimate for that method.

SATA: hdparm -I

sudo hdparm -I /dev/sdX | sed -n '/Security:/,/^$/p'
sudo hdparm -I /dev/sdX | grep -i -E 'sanitize|scramble|block.erase|overwrite'

A healthy, erasable SATA drive shows "supported", "not enabled", "not locked", "not frozen" and, ideally, "supported: enhanced erase", followed by the two time estimates. If the second command prints sanitize related lines, the drive supports the ATA Sanitize feature set as well.

Do not do this over USB, RAID or SAS bridges

The Arch Wiki warns against issuing Secure Erase, Format or Sanitize to a drive attached through USB or a SAS or RAID card, because doing so "could potentially brick the drive." Connect the drive directly to a SATA port or an M.2 or U.2 slot. If you only have a USB enclosure, check whether its bridge chip passes NVMe admin commands at all before trusting any result.

Step by step: NVMe Sanitize with nvme-cli

Warning: every command in this section destroys all data on the target drive, and once a sanitize operation starts it cannot be aborted. Back up anything you need, confirm the device path immediately before each block, and run from a live environment if the target holds the running system.

Step 1: preflight

# 1. Confirm the target by serial number, not by name
sudo nvme list
SERIAL_EXPECTED="PUT-THE-SERIAL-FROM-THE-DRIVE-LABEL-HERE"
sudo nvme id-ctrl /dev/nvme0 | grep -E '^sn ' # or: nvme id ctrl on 3.x

# 2. Make sure nothing on it is mounted, swapped or part of an LVM or RAID set
findmnt -rn -o SOURCE | grep nvme0 || echo "nothing mounted from nvme0"
swapon --show
sudo pvs 2>/dev/null | grep nvme0
cat /proc/mdstat

# 3. Check for a pending firmware activation; reboot first if you updated firmware
sudo nvme fw-log /dev/nvme0   # nvme-cli 2.x name; check `nvme help` for the 3.x spelling

The specification requires the controller to reject a sanitize command if a firmware activation with reset is pending. If you updated the drive's firmware without rebooting, do a full power cycle first.

Write the serial number, model, firmware version and capacity into your sanitization record now. You will need them for the certificate at the end.

Step 2: choose the method

Use this order unless your policy says otherwise:

1. Crypto Erase (action 4) if SANICAP shows it, the drive has always encrypted its media (all modern self-encrypting designs do), and your policy accepts cryptographic erase.
2. Block Erase (action 2) if you do not want to depend on the drive's encryption, or after a Crypto Erase for defence in depth.
3. Overwrite (action 3) only on media where block erase is not available and endurance does not matter.

Step 3: start the sanitize

Confirm the device path again, then start the operation. The --sanact values below work on nvme-cli 2.x and 3.x; 3.x also accepts names such as start-crypto-erase.

# DEVICE CHECK: the serial printed here must equal SERIAL_EXPECTED
sudo nvme id-ctrl /dev/nvme0 | grep -E '^sn '

# Crypto Erase
sudo nvme sanitize /dev/nvme0 --sanact=4

# or Block Erase
# sudo nvme sanitize /dev/nvme0 --sanact=2

# or Overwrite with one pass of zeros (0 passes would mean 16)
# sudo nvme sanitize /dev/nvme0 --sanact=3 --owpass=1 --ovrpat=0x00000000

Notes on options:

• Sanitize targets the controller character device (/dev/nvme0), not a namespace block device. It acts on the whole NVM subsystem.
• --ause selects unrestricted completion mode. Leave it off unless you want the option to use Exit Failure Mode after a failure.
• --preq (Purge Required), on nvme-cli builds that have it and drives that support Sanitize Purge Request and Reporting, makes the drive fail the operation if it would only clear rather than purge. That is the strongest assurance the interface offers.
• --emvs asks the drive to enter the Media Verification state on completion, on drives that support it, so you can sample before deallocation.
• --wait on newer builds blocks until the operation finishes.

The command returns in a fraction of a second. That only means the drive accepted it.

Step 4: monitor progress

# nvme-cli 2.x
watch -n 5 'sudo nvme sanitize-log /dev/nvme0'
# nvme-cli 3.x
watch -n 5 'sudo nvme log sanitize /dev/nvme0'

What to look at:

• Sanitize Progress (SPROG) is a fraction with 65,536 as the denominator. A value of 32,768 means half done. When the operation is not running, the drive reports 65,535 (FFFFh).
• Sanitize Status (SSTAT) shows the operation status: 0 never sanitized, 1 completed successfully, 2 in progress, 3 failed, with newer values for Media Verification.

nvme-cli also decodes the log page into readable lines. If you lose power or reboot while the status shows in progress, the drive resumes on the next power up. That is by design.

Step 5: confirm completion

When SSTAT reports success, read the log once more and record:

• the status (Sanitized, value 1);
• the Global Data Erased bit, which the nvme-cli documentation explains as meaning nothing has been written to non-volatile storage since the most recent successful sanitize;
• the Purged (PRGD) bit, if you set PREQ. Set means the drive purged user data as defined by IEEE 2883; clear means it cleared rather than purged, or PREQ was not used;
• the method, start time and end time.

If the status is Failed, run another sanitize. In restricted mode the drive will refuse normal I/O until a sanitize completes successfully. If you used --ause, you can instead send --sanact=1 (Exit Failure Mode), but the data has not been sanitized and the drive must not leave your control.

Step 6: optional sampling

NIST SP 800-88 Rev 2 says that unless your policy requires it, elaborate sampling of the media's contents after clear or purge is not necessary. Verification means checking the tool's completion status and the drive's health. If your policy does require sampling, read a few regions and confirm they do not contain recognisable data:

# DEVICE CHECK first
sudo nvme list

# First, middle and last 16 MiB of namespace 1, shown as hex
SIZE=$(sudo blockdev --getsize64 /dev/nvme0n1)
sudo dd if=/dev/nvme0n1 bs=1M count=16 status=none | hexdump -C | head -20
sudo dd if=/dev/nvme0n1 bs=1M skip=$(( SIZE/2/1048576 )) count=16 status=none | hexdump -C | head -20
sudo dd if=/dev/nvme0n1 bs=1M skip=$(( SIZE/1048576 - 16 )) count=16 status=none | hexdump -C | head -20

These reads are harmless. After a normal sanitize with deallocation, you will usually see a single repeated value, often zeros. Remember the Annex A caveat: the host can only audit the storage it can address.

Step 7: put the drive back into service

A sanitized drive has no partition table. Before you partition it, the Arch Wiki suggests checking whether it supports a better logical sector size, because that is easiest to change when the drive is empty:

sudo nvme id-ns -H /dev/nvme0n1 | grep 'LBA Format'

Step by step: NVMe Format NVM with secure erase

Use this when SANICAP is zero, or for quick internal reuse.

Warning: Format NVM with SES erases every namespace the FNA field says it applies to. Confirm the device path and serial immediately before running it.

# DEVICE CHECK
sudo nvme list
sudo nvme id-ctrl /dev/nvme0 | grep -E '^sn '

# Cryptographic Erase of namespace 1
sudo nvme format /dev/nvme0 --namespace-id=1 --ses=2

# User Data Erase of namespace 1 (the drive may implement it as a crypto erase)
# sudo nvme format /dev/nvme0 --namespace-id=1 --ses=1

# All namespaces
# sudo nvme format /dev/nvme0 --namespace-id=0xffffffff --ses=2

If you pass the character device and the drive does not support per-namespace formatting, nvme-cli formats every namespace. Without --force, nvme-cli warns you about the implications before sending the command. Do not add --force to scripts that might be run against the wrong machine.

There is no log page for Format NVM. The command's success status is the only record the drive gives you, so note it in your record together with the SES value.

Step by step: ATA Security Erase with hdparm

Warning: these commands destroy all data on the target drive. A password left set by a failed run can lock the drive, and some laptop firmwares compute drive passwords differently, so do not reboot between setting the password and finishing the erase.

Step 1: identify and check the security state

# DEVICE CHECK: model and serial must match the drive you intend to erase
lsblk -o NAME,MODEL,SERIAL,SIZE,TRAN /dev/sdX
sudo hdparm -I /dev/sdX | grep -E 'Model Number|Serial Number'

# Must say "not frozen" and "not enabled"
sudo hdparm -I /dev/sdX | sed -n '/Security:/,/^$/p'

If it says "frozen", suspend and resume:

sudo systemctl suspend
# after resume
sudo hdparm -I /dev/sdX | grep frozen

Step 2: set a temporary user password

# DEVICE CHECK again
sudo hdparm -I /dev/sdX | grep -E 'Model Number|Serial Number'

sudo hdparm --user-master u --security-set-pass Temp1234 /dev/sdX
sudo hdparm -I /dev/sdX | sed -n '/Security:/,/^$/p'   # should now say "enabled"

hdparm also offers --security-prompt-for-password so the password does not land in your shell history.

Step 3: erase

# DEVICE CHECK again, and confirm nothing is mounted
sudo hdparm -I /dev/sdX | grep -E 'Model Number|Serial Number'
findmnt -rn -o SOURCE | grep sdX || echo "nothing mounted"

# Enhanced, if "supported: enhanced erase" is shown
sudo time hdparm --user-master u --security-erase-enhanced Temp1234 /dev/sdX
# Otherwise normal
# sudo time hdparm --user-master u --security-erase Temp1234 /dev/sdX

The Arch Wiki warns that a secure erase issued while the device is mounted will not erase properly. The command blocks until the drive finishes, which can take from seconds to hours.

Step 4: confirm

sudo hdparm -I /dev/sdX | sed -n '/Security:/,/^$/p'

After success, security should read "not enabled". If it still reads "enabled", the erase did not complete; disable the password with --security-disable Temp1234 and investigate before the drive leaves your hands.

ATA Sanitize, where supported

If hdparm -I lists sanitize support and your hdparm build lists sanitize options in hdparm --help, prefer them over Security Erase: they need no password and report status. The pattern is the same. Check the device, read the sanitize status, start crypto scramble or block erase with the confirmation flag hdparm requires, then poll the status until it reports completion. Use the exact option names your build prints; they have changed across releases.

Watching progress and proving completion

A sanitization record is only as good as the evidence behind it. For each method, here is what the drive gives you.

NIST SP 800-88 Rev 2 splits assurance into two steps. Verification checks the outcome of the technique: for logical clear and purge, that means checking the tool's completion status and looking for errors, anomalies and signs of poor drive health. Validation is the decision to accept the result or redo it with a different technique. NIST's Appendix C gives a sample Certificate of Sanitization with fields for the device, the method, the technique, the tool, the verification method and who performed and checked it. Save the log page output and the hdparm -I output as attachments; they are the drive's own testimony.

Where TCG Opal self-encrypting drives and PSID revert fit

Most modern SSDs are self-encrypting by construction: the controller encrypts everything with a media encryption key. TCG Opal is the Trusted Computing Group specification that lets the host manage that encryption: define locking ranges, set credentials, require authentication before a range unlocks at power on, and erase a range by regenerating its key.

For sanitization, Opal matters in three ways.

Opal erase is crypto erase. Erasing a locking range or reverting the drive replaces the keys that protect the data. It is subject to the same NIST conditions as any cryptographic erase.

Opal locking can get in the way. A drive with an active Opal configuration from a previous owner, operating system or tool may refuse or misbehave under other erase commands. The sedutil project's documentation notes that some drives refuse to secure erase until a PSID revert has been performed.

PSID revert is the recovery path. The PSID, per sedutil's documentation, is a 32 character password printed on the drive label that proves you have physical access to the drive. A PSID revert resets the drive to its factory Opal state and, if the locking feature was active, erases all data. It exists for the case where you no longer have the Opal administrator credentials.

Warning: PSID revert destroys all data on the drive. Confirm the target before running it.

sedutil's documented sequence, shown here with Linux device paths, is:

# Find Opal capable drives and identify the target
sudo sedutil-cli --scan

# DEVICE CHECK: confirm model and serial for the target
sudo sedutil-cli --query /dev/nvme0

# Revert using the PSID from the label: capitals, no dashes
sudo sedutil-cli --yesIreallywanttoERASEALLmydatausingthePSID ABCDEFGHIJKLMNOPQRSTUVWXYZ123456 /dev/nvme0

sedutil reports "revertTper completed successfully" on success, and "NOT_AUTHORIZED" if the PSID was mistyped. Its README notes that on Linux, SATA drives need the kernel parameter libata.allow_tpm=1 for these commands to reach the drive.

After a PSID revert, run a normal NVMe Sanitize or ATA erase as well if your policy asks for a specific method on record. The revert's job is to get the drive out of a locked or misconfigured state; the sanitize log is the cleaner evidence.

One caution from NIST applies directly here: do not trust cryptographic erase on media whose keys were backed up or escrowed, unless you know exactly where those key copies are. Opal's own media keys normally never leave the drive, but a software encryption layer on top, such as a disk encryption volume with an escrowed recovery key, is a separate key hierarchy with its own copies.

Mapping each method to NIST SP 800-88 Rev 2 Clear, Purge and Destroy

NIST SP 800-88 Rev 2, published in September 2025, changed how this mapping works. Rev 1 had device by device tables. Rev 2's change log says that, apart from cryptographic erase, all technique and tool details were replaced with a recommendation to follow IEEE 2883, NSA specifications or an organisation's approved standard. The appendices with media specific techniques were removed.

What remains are three outcomes:

• Clear applies logical techniques to all user-addressable storage, protecting against simple, non-invasive recovery through the same interface the user has. Rev 2 clarifies that multi-pass overwrite is not needed.
• Purge makes recovery infeasible even with state of the art laboratory techniques, while leaving the media potentially reusable. For logical purge, NIST tells you to consult IEEE 2883, and names overwrite, block erase and cryptographic erase through dedicated, standardized device sanitize commands as examples. NIST adds that Purge should be preferred over Clear whenever possible.
• Destroy makes recovery infeasible and the media unusable. NIST lists disintegrate, incinerate, melt, pulverize and shred, warns that drilling or bending may only partly damage media, and says pulverize and shred should be reserved for the lowest security categories of data as density increases.

NVMe aligns with this directly. Its sanitize operations purge or clear using the IEEE Std 2883 definitions, and the PREQ and PRGD bits exist so the drive can tell you which one it achieved.

"Purge candidate" is deliberate: whether a given drive meets Purge is a question for IEEE 2883, the vendor's documentation and your organisation's standard.

What Windows and macOS offer without third party tools

Windows

Windows has no command line tool that sends NVMe Sanitize or ATA Security Erase, but it has several built-in ways to clear a disk, and one programming interface that offloads erasure to the drive.

The IOCTL is the interesting one. Microsoft documents it as handing the erase to the drive itself, supported from Windows 10 build 20348 and Windows Server equivalents, limited to data disks in normal Windows and available for boot disks in Windows PE. Microsoft also says plainly that there is "no guarantee as to the successful deletion or recoverability of the data" once the command completes. It is a building block for tools, not a user command.

For a Windows PC leaving your control, use Reset this PC with Clean data for a Clear, or boot a Linux live USB and follow the nvme-cli or hdparm steps above for a Purge.

macOS

On a Mac with Apple silicon or the Apple T2 Security Chip running macOS Monterey 12 or later, Apple provides Erase All Content and Settings: System Settings, General, Transfer or Reset, Erase All Content and Settings. Apple describes it as a quick, secure way to erase all data, settings and apps while keeping the installed operating system.

Apple Platform Security (August 2026) explains why it is quick. The file system key is additionally wrapped by an effaceable key held in a dedicated, directly addressable area of flash (or by a media key-wrapping key protected by the Secure Enclave), and that key exists to be erased quickly on demand, by Erase All Content and Settings or by a remote wipe. In Apple's words, "Erasing the key in this manner renders all files cryptographically inaccessible." The same guide notes that the key-wrapping key for file metadata changes every time a device is erased.

That is a cryptographic erase of the internal storage, implemented by Apple's own key hierarchy rather than by an NVMe Sanitize command from the host. Whether it meets your Purge requirement is a policy decision against NIST's CE conditions and your standard; for most organisations reusing or reselling Macs it is the intended method. On Intel Macs without a T2 chip, Apple's support article points to its separate steps for selling or recycling a Mac.

Repaired Macs have one extra step: Apple asks owners of Apple silicon Macs on macOS 26 or later to check for an unfinished repair with Repair Assistant before erasing.

Common mistakes

• Erasing the wrong drive. Device names are assigned at boot and can change; the nvme-cli documentation warns that controller and namespace numbers are not linked. Use model and serial numbers from /dev/disk/by-id or nvme list, and check again immediately before each destructive command.
• Trusting the command's exit code. NVMe Sanitize returns success as soon as the operation starts. The sanitize log page, not the shell prompt, tells you whether it finished.
• Overwriting an SSD from the host and calling it purged. Spare and retired blocks are out of reach. NIST says multi-pass overwrite on overprovisioned SSDs gives very little confidentiality protection.
• Leaving a temporary ATA password set. If the erase fails or the machine reboots, the drive may come up locked. Disable the password before you move on.
• Running Sanitize while a firmware update is pending. The drive will reject it. Power cycle after firmware updates.
• Assuming cryptographic erase covers data that was never encrypted. It only works if the data was always encrypted on that media since its last sanitization, and only if no other copy of the key exists.
• Forgetting the software encryption layer's escrowed keys. If the drive also carried an encrypted volume, its recovery keys in a directory or management service are copies of key material that NIST says need their own sanitization policy.
• Skipping the record. Without the serial number, method, tool output and a signed certificate, you cannot show later that a specific drive was sanitized.
• Drilling a hole and calling it destroyed. NIST notes that drilling may leave portions recoverable. Use a qualified destruction service with a particle size suited to flash.

FAQ

What is the difference between NVMe format and NVMe sanitize?

Format NVM changes a namespace's format and can optionally erase user data with a User Data Erase or a Cryptographic Erase. Sanitize is a dedicated command that purges or clears all user data in the subsystem, including caches and deallocated media, runs in the background, continues across power loss, cannot be aborted once started, and reports its result in a log page.

Is crypto erase secure enough to sell or recycle an SSD?

For most organisations, yes, if the drive supports it and the conditions hold: the data was always encrypted by the drive, the encryption is sound, and no copy of the key exists outside the drive. NIST SP 800-88 Rev 2 treats cryptographic erase as a purge technique under those conditions, and requires FIPS 140 validated modules for federal agencies. For data that must stay secret for decades, consider Block Erase as well, or destruction.

How long does an NVMe sanitize take?

Crypto Erase usually takes seconds, Block Erase minutes and Overwrite possibly hours. The sanitize log page reports the drive's own estimate for each method.

How do I fix a "frozen" SATA SSD so I can secure erase it?

Suspend to RAM (S3), resume and check hdparm -I again; the freeze usually clears. The ATA section above lists the fallbacks.

Can I sanitize an NVMe drive in a USB enclosure?

Generally no. Many USB bridges do not pass NVMe admin commands correctly. Install the drive in an M.2 or U.2 slot.

What does the sanitize log page tell me?

The status of the most recent sanitize operation (never started, sanitized, in progress, failed, or Media Verification states), progress as a fraction of 65,536, the Global Data Erased bit, the Purged bit if you required a purge, and the drive's time estimates for each method.

Does Windows have a secure erase command for SSDs?

Not as a user command. The built-in tools (format /p, diskpart clean all, Reset this PC with Clean data) are host side clears. Developers can call IOCTL_STORAGE_REINITIALIZE_MEDIA to hand the erase to the drive.

What is a PSID revert and when do I need it?

A PSID revert resets a TCG Opal self-encrypting drive to its factory state using the 32 character PSID printed on the label, erasing the data if locking was active. You need it when the drive was locked or configured by someone else and you do not have the administrator credentials, or when a drive refuses other erase commands because of a leftover Opal configuration.

Does NIST SP 800-88 Rev 2 still say which command to use for an SSD?

No. Rev 2 removed the device tables, gives detailed conditions only for cryptographic erase, and points to IEEE 2883 for everything else.

Is ATA Enhanced Secure Erase the same as ATA Sanitize?

No. Enhanced Secure Erase belongs to the older Security feature set, needs a password and is blocked by the security freeze. ATA Sanitize is a separate feature set with crypto scramble, block erase and overwrite, designed to cover all user data areas and to report status.

Where Safeguard fits, and where it does not

Safeguard does not sanitize drives, send NVMe or ATA commands, manage devices, scan firmware or produce hardware bills of materials. Everything in this guide is work you do with nvme-cli, hdparm, sedutil, util-linux, your firmware menu or the operating system's own reset. The honest connection is the software. nvme-cli, libnvme, hdparm, sedutil and util-linux are open source components with their own releases and fixes, and teams that build a live USB image or a wipe station image to run them are shipping a small operating system with a dependency tree. If you build that image from a repository or a container, Safeguard can scan the repository, image or SBOM that describes it (safeguard scan --dir ., --image, --sbom), show which of your projects carry a given component version, and match those versions against vulnerability data. That tells you when the tooling image itself needs an update. It does not tell you whether a given drive was sanitized.

A wiped and redeployed laptop or server starts its software life again: it pulls a fresh operating system, toolchains and dependencies, and every one of those is an open source supply chain decision. The fit with drive sanitization itself is indirect, but the hygiene below applies to everything that machine will build and run next.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

None of these demos touch drives, sanitize commands or firmware. They show the software side of a machine you have just wiped and rebuilt, and of the tooling image you use to wipe.

This is a real Safeguard CLI session: install, open the interactive terminal, ask it to fix a lodash CVE, and approve each command as it edits package.json and runs npm install and npm test, with nothing pushed. After a laptop is sanitized and reimaged, the same flow is how you would rescan and fix the projects you clone back onto it, approving every command yourself.

Click through it at your own pace, or open it full screen.

This demo sets up the Safeguard runner on your own machine, approves it with a device code, and runs a scan from the terminal. If you keep your wipe station or live USB image definition in a repository, the same runner can scan that repository or an SBOM of the image, so the nvme-cli, hdparm and kernel versions it ships are checked against vulnerability data.

Click through it at your own pace, or open it full screen.

Here Claude connects to the Safeguard MCP server with OAuth, and you choose which Safeguard tools Claude may use. That is useful when you want to ask, in plain language, which of your projects or images carry a given version of a disk tooling component, while keeping the assistant's access limited to the tools you picked.

Click through it at your own pace, or open it full screen.

To try it on your own projects, download Safeguard or read the CLI documentation.

Quick check

Sources

• NIST SP 800-88 Rev. 2, Guidelines for Media Sanitization (CSRC page)
• NIST SP 800-88 Rev. 2 (PDF)
• NVM Express Base Specification Revision 2.4 (PDF)
• NVM Express Base Specification page
• NVM Express specifications overview
• IEEE 2883-2022, Standard for Sanitizing Storage
• T13 Technical Committee, published standards
• nvme-cli: nvme-sanitize documentation
• nvme-cli: nvme-format documentation
• nvme-cli: nvme-log-sanitize documentation
• nvme-cli: nvme-sanitize-log (deprecated alias) documentation
• nvme-cli: nvme-id-ctrl documentation
• nvme-cli releases
• hdparm(8) man page, man7.org
• hdparm(8) man page, Debian
• blkdiscard(8) man page
• ArchWiki: Solid state drive/Memory cell clearing
• sedutil wiki: PSID Revert
• sedutil README
• Microsoft Learn: format command
• Microsoft Learn: cipher command
• Microsoft Learn: diskpart clean
• Microsoft Learn: Clear-Disk
• Microsoft Learn: IOCTL_STORAGE_REINITIALIZE_MEDIA
• Microsoft Support: Reset your PC
• Apple Support: Erase your Mac and reset it to factory settings
• Apple Platform Security guide (PDF, August 2026)

Last reviewed: 23 October 2026. Tool options change between releases; check the nvme-cli, hdparm and sedutil documentation for the version you run, and your drive maker's documentation for how it implements each method.