Deleting a file on an 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.

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 an 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 an SSD overwrites the logical blocks the file currently occupies. Due to wear leveling, the old data may still sit in unmapped physical blocks.

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.

Warning: 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.

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.

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.

Method 4: Physical Destruction

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

• Remove the SSD from the device
• Open the enclosure (usually Torx screws)
• Expose the NAND flash chips
• Sand, grind, or crush the chips individually

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

Verifying 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.

Understanding 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.

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.

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.

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:

• Over-provisioned space
• Unmapped blocks in wear-leveling tables
• Cache memory in the controller
• Backup copies created during garbage collection

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

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.

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.

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

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.

Related Articles

• Best Secure File Sharing Tools for Teams Handling.
• How to Set Up Secure File Sharing for Sensitive Documents
• How To Use Age Encryption For Secure File Sharing Command Li
• Onionshare Secure File Sharing Over Tor Network Setup And Us
• Secure File Sharing Tools Comparison: E2E Encrypted.

Built by theluckystrike — More at zovo.one