Last updated: March 21, 2026

Deleting a file on a SSD does not erase the data. Neither does running shred or wipe. tools designed for magnetic hard drives that simply do not work correctly on solid-state storage. This is a well-understood problem with serious privacy implications that most guides still get wrong.

This article explains why, and gives you the methods that actually work.

Table of Contents

Why HDD Deletion Methods Fail on SSDs

On a traditional spinning hard drive, data lives at a known physical location on the platter. When you delete a file and overwrite that sector multiple times, the data is gone.

SSDs work differently. They use a technique called wear leveling: the controller spreads writes across all available flash cells to prevent any single cell from wearing out too fast. When you write to a “location” on a SSD, the controller may write to a completely different physical cell and just update a mapping table. The old data may remain in the original cell. unlinked from any filesystem path but physically present and readable with forensic tools.

Additionally, SSDs have over-provisioned space. reserved cells invisible to the operating system that the controller uses for wear leveling. Data written to this space is inaccessible via normal read commands but not cryptographically erased.

shred -v /path/to/file on a SSD overwrites the logical blocks the file currently occupies. Due to wear leveling, the old data may still sit in unmapped physical blocks.

Prerequisites

Before you begin, make sure you have the following ready:

Step 1 - Method 1: Full Drive Erasure with ATA Secure Erase

ATA Secure Erase is a command built into the SSD firmware that instructs the drive’s controller to reset all cells. including over-provisioned space. to their factory state. This is the gold standard for erasing an entire SSD.

This erases the entire drive. Back up anything you want to keep.

Install hdparm
sudo apt install hdparm   # Debian/Ubuntu
sudo dnf install hdparm   # Fedora

Identify your drive (look for the SSD, e.g. /dev/sda)
sudo hdparm -I /dev/sda | grep -i "security"

The drive must not be frozen. If it shows "frozen", you may need
to suspend the system briefly and resume to unfreeze it.
Set a temporary security password
sudo hdparm --security-set-pass temppassword /dev/sda

Issue the Secure Erase command
sudo hdparm --security-erase temppassword /dev/sda

After completion, the drive will be unlocked and all data erased.

NVMe drives

NVMe SSDs use a different command set. Use nvme-cli:

sudo apt install nvme-cli

List NVMe drives
sudo nvme list

Format with secure erase (ses=1 = user data erase, ses=2 = cryptographic erase)
sudo nvme format /dev/nvme0n1 --ses=1

Cryptographic erase (--ses=2) is preferred on NVMe drives. it discards the internal encryption key, making all data permanently unrecoverable without needing to overwrite anything.

Step 2 - Method 2: Encryption-Based Erasure (Most Practical)

If you encrypt the drive before writing any sensitive data, “erasing” becomes trivial: destroy the key and all data is cryptographically unrecoverable, regardless of wear leveling.

This is the recommended approach for ongoing use rather than one-time erasure.

Setup with LUKS on Linux

Encrypt the drive at setup time
sudo cryptsetup luksFormat /dev/sdb

Open and use normally
sudo cryptsetup luksOpen /dev/sdb secret_data
sudo mkfs.ext4 /dev/mapper/secret_data
sudo mount /dev/mapper/secret_data /mnt/secure

When done with the data permanently. destroy the key slot
sudo cryptsetup luksErase /dev/sdb

After luksErase, the LUKS header is wiped. The encrypted data on the drive is now computationally irretrievable.

macOS with FileVault

On macOS, enabling FileVault encrypts the entire system volume. To securely erase sensitive files:

  1. Store them only on the encrypted volume (FileVault must be enabled)
  2. To destroy everything: use Disk Utility → Erase → Security Options → “Most Secure” on an external drive, or for the boot drive, reinstall macOS which triggers a cryptographic erase on T2/Apple Silicon Macs

On Apple Silicon and T2 Macs, the storage controller handles encryption in hardware. Erasing the drive through Disk Utility performs a cryptographic erase by destroying the internal key. extremely fast and genuinely secure.

Step 3 - Method 3: Overwriting Individual Files (Limited but Sometimes Useful)

For cases where you need to delete specific files on an already-running unencrypted SSD and don’t want to erase the whole drive, your options are limited but not zero.

On Linux with fstrim support, you can write zeros to the file and then trim:

Overwrite file contents with zeros
dd if=/dev/zero of=sensitive_file bs=4K conv=notrunc

Remove the file
rm sensitive_file

Issue a TRIM to free the blocks (only on filesystems with trim support)
sudo fstrim -v /

This is not guaranteed. Wear leveling may have left copies of the data in unmapped cells. Treat this as best-effort, not forensic-grade erasure.

secure-delete with SSD awareness:

sudo apt install secure-delete
-l reduces passes (more appropriate for SSDs than default 38-pass HDD mode)
srm -l sensitive_file

Again, this overwrites logical blocks only. Acceptable for deleting data from a system you continue to use; not acceptable as your sole erasure method before device disposal.

Step 4 - Method 4: Physical Destruction

For the highest assurance. decommissioning a drive containing highly sensitive data. physical destruction is the only method that cannot fail:

This is overkill for most situations but appropriate for threat models involving well-resourced adversaries with physical access and forensic lab capabilities.

Step 5 - Verify the Erasure

After ATA Secure Erase or NVMe Format, you can spot-check that data is gone:

Read raw bytes from the drive. should be all 0xFF (erased NAND state)
sudo hexdump -C /dev/sda | head -50

Zeros or 0xFF values throughout confirm the erase completed. Any recognizable data patterns indicate the erase did not complete successfully.

Step 6 - Understand NAND Flash Cell States

SSDs store data in NAND flash cells, which exist in multiple voltage states representing different bit values. Understanding these states explains why simple overwriting fails.

A NAND cell can be erased (all bits to 1, appearing as 0xFF in memory), programmed (bits written to 0), or read. The key issue: program-erase cycles degrade cells. After many cycles, a cell may fail to reliably hold state. SSD controllers use wear leveling to distribute writes, but this creates the “ghost data” problem.

When you write to a logical block address, the controller may:

  1. Find an erased physical cell
  2. Program it with your data
  3. Update the logical-to-physical mapping table
  4. Later, move data to a different cell for wear leveling
  5. Leave the original cell unmapped but still programmed

Forensic tools can read these unmapped cells if they have direct flash chip access.

Step 7 - Wear Leveling Algorithms

Different SSD controllers use different wear leveling strategies, affecting erasure complexity:

Dynamic Wear Leveling - Distributes writes only among cells with similar erase counts. Fastest but leaves old data scattered.

Static Wear Leveling - Also moves static data to distribute wear evenly. Ensures more complete erasure over time.

Hybrid Wear Leveling - Combines both approaches.

Your only practical defense against wear leveling issues: encryption from the start. If data is encrypted and keys are destroyed, wear leveling becomes irrelevant.

Step 8 - Garbage Collection Behavior

SSDs perform background garbage collection, consolidating data and preparing blocks for reuse. This process is not visible to the OS:

Monitor garbage collection on Linux
iostat -x 1
Look for w_await (write await time). high values indicate GC activity

If you’re trying to selectively erase files without full-drive erase, understand that GC may copy your data before erasing it:

Disable GC temporarily before sensitive deletions (advanced)
This requires manufacturer-specific tools and risks data loss
nvme simple-trim /dev/nvme0n1  # Schedule blocks for deletion
sync  # Force filesystem flush

Most users should not attempt this. Full encryption with key destruction is far safer.

Step 9 - TRIM Command and Its Limitations

The TRIM command tells the SSD controller which blocks are no longer needed. The controller then performs garbage collection on those blocks. However, TRIM is not instantaneous:

Issue TRIM on Linux
fstrim -v /home/user  # Filesystem trim
blkdiscard /dev/sda1  # Low-level block discard

Monitor TRIM progress
watch -n 1 'iostat -x 1'

Even after TRIM, data may persist in:

Step 10 - Encrypted Filesystems vs Full-Disk Encryption

There’s a crucial difference between encrypting specific files/folders vs encrypting the entire drive:

Encrypted Folders (VeraCrypt, LUKS for specific partitions): Only new files written to that volume are encrypted. If the partition wasn’t encrypted from the start, old unencrypted data persists.

Full-Disk Encryption (FileVault, dm-crypt on root): Every new write is encrypted from day one, and old unencrypted data is gradually overwritten as the filesystem operates.

For maximum security, enable full-disk encryption before writing any sensitive data:

Linux - Enable encryption on new partition
sudo cryptsetup luksFormat /dev/sdb
sudo cryptsetup luksOpen /dev/sdb secure
sudo mkfs.ext4 /dev/mapper/secure

Verify all future writes are encrypted
sudo mount /dev/mapper/secure /mnt/secure
dd if=/dev/urandom of=/mnt/secure/testfile bs=1M count=10
hexdump -C /dev/sdb | head -20  # Should show ciphertext, not plaintext

Step 11 - Vendor-Specific Firmware Commands

Some SSD manufacturers provide proprietary secure erase commands beyond ATA Secure Erase:

Samsung drives
samsung-ssd-toolkit --secure-erase /dev/sda

Intel SSD Toolbox (cross-platform)
Download from Intel and run against your drive

Kingston FURY Controller Utility
Provides manufacturer-specific erase options

Check your SSD manufacturer’s website for vendor-specific tools. These often provide additional context about which data is actually erased.

Step 12 - Recovery Validation Through Data Carving

After erasing, verify nothing recoverable remains using data carving tools:

Install Autopsy or Foremost for recovery simulation
apt-get install foremost

Scan erased drive for recoverable data
sudo foremost -i /dev/sda -o /tmp/recovery

If foremost finds nothing, erasure was successful
ls /tmp/recovery

Finding even fragments of old data after ATA Secure Erase indicates a problem, contact the manufacturer.

Step 13 - Temperature Monitoring During Secure Erase

ATA Secure Erase and NVMe Format operations generate heat as the controller writes to all cells. Monitor temperature:

Install lm-sensors
sudo apt-get install lm-sensors

Monitor during erase
watch -n 1 'sensors | grep -A5 nvme'

If temperature exceeds 70°C, the operation is stressing the hardware. Most drives have thermal throttling, erase may pause temporarily.

Decommissioning Strategy for Enterprise

For organizations, erasure strategy depends on data sensitivity and threat model:

Low sensitivity, standard threat: Filesystem-level deletion sufficient.

Medium sensitivity, internal threat: Full-disk encryption with standard operating, then disposal (no erase needed).

High sensitivity, nation-state threat: ATA Secure Erase + physical destruction of NAND chips.

Audit script for BEFORE and AFTER secure erase
This demonstrates a complete workflow

#!/bin/bash
DRIVE=$1

Capacity check
echo "Drive size: $(blockdev --getsize64 $DRIVE) bytes"

Pre-erase validation
echo "Pre-erase scan:"
sudo foremost -q -i $DRIVE 2>/dev/null | wc -l

Perform secure erase
echo "Starting ATA Secure Erase..."
sudo hdparm --security-set-pass temppass $DRIVE
sudo hdparm --security-erase temppass $DRIVE

Post-erase validation
echo "Post-erase scan:"
sudo foremost -q -i $DRIVE 2>/dev/null | wc -l

Verify all bytes are uniform (0xFF or 0x00)
echo "Byte pattern verification:"
sudo hexdump -C $DRIVE | head -20

Step 14 - Cloning Before Secure Erase

If you need to preserve data during the erasure process, clone the drive first:

Clone SSD to external drive (does not bypass encryption)
sudo dd if=/dev/sda of=/path/to/external/backup.img bs=4M status=progress

Later, restore from backup if needed
sudo dd if=/path/to/external/backup.img of=/dev/sda bs=4M status=progress

Never erase the backup until you confirm the original erase worked

For SSDs, prefer ddrescue which handles bad sectors gracefully:

sudo ddrescue -D --force /dev/sda /path/to/backup.img

Cryptographic Erase Best Practices

When using encryption-based erasure, proper key management is critical:

LUKS key rotation (prepare for erase)
1. Create new passphrase
sudo cryptsetup luksAddKey /dev/sdb
2. Remove old passphrases
sudo cryptsetup luksRemoveKey /dev/sdb  # Enter old passphrase
3. Perform cryptographic erase of key slots
sudo cryptsetup luksErase /dev/sdb  # Wipes all key material

After luksErase, the encrypted data becomes mathematically irretrievable, no special erase needed.

Troubleshooting

Configuration changes not taking effect

Restart the relevant service or application after making changes. Some settings require a full system reboot. Verify the configuration file path is correct and the syntax is valid.

Permission denied errors

Run the command with sudo for system-level operations, or check that your user account has the necessary permissions. On macOS, you may need to grant terminal access in System Settings > Privacy & Security.

Connection or network-related failures

Check your internet connection and firewall settings. If using a VPN, try disconnecting temporarily to isolate the issue. Verify that the target server or service is accessible from your network.

Frequently Asked Questions

Who is this article written for?

This article is written for developers, technical professionals, and power users who want practical guidance. Whether you are evaluating options or implementing a solution, the information here focuses on real-world applicability rather than theoretical overviews.

How current is the information in this article?

We update articles regularly to reflect the latest changes. However, tools and platforms evolve quickly. Always verify specific feature availability and pricing directly on the official website before making purchasing decisions.

Are there free alternatives available?

Free alternatives exist for most tool categories, though they typically come with limitations on features, usage volume, or support. Open-source options can fill some gaps if you are willing to handle setup and maintenance yourself. Evaluate whether the time savings from a paid tool justify the cost for your situation.

Can I trust these tools with sensitive data?

Review each tool’s privacy policy, data handling practices, and security certifications before using it with sensitive data. Look for SOC 2 compliance, encryption in transit and at rest, and clear data retention policies. Enterprise tiers often include stronger privacy guarantees.

What is the learning curve like?

Most tools discussed here can be used productively within a few hours. Mastering advanced features takes 1-2 weeks of regular use. Focus on the 20% of features that cover 80% of your needs first, then explore advanced capabilities as specific needs arise.

Related Articles