The Hidden Process That Undermines Traditional Wiping

Wear levelling is one of the most important concepts to understand when it comes to data destruction on solid-state storage. It is the reason that traditional overwrite methods, which work perfectly well on magnetic hard drives, cannot provide the same assurance on SSDs. Yet many organisations continue to apply HDD wiping methods to SSDs without understanding why the results may be inadequate.

Why Wear Levelling Exists

NAND flash memory cells have a finite lifespan. Each cell can endure a limited number of program/erase (P/E) cycles before it wears out and can no longer reliably store data. For consumer-grade TLC (Triple-Level Cell) NAND, this limit is typically around 1,000 to 3,000 P/E cycles. For enterprise-grade SLC (Single-Level Cell) NAND, the endurance is higher, around 50,000 to 100,000 P/E cycles.

Without wear levelling, cells in frequently written areas of the drive would wear out quickly while cells in rarely written areas would remain relatively fresh. This uneven wear would cause portions of the drive to fail prematurely, significantly reducing the drive’s overall lifespan.

Wear levelling solves this problem by distributing write operations as evenly as possible across all available cells. The SSD’s controller, through the flash translation layer (FTL), constantly moves data between physical cells to ensure that no single cell is written to disproportionately more than others.

How Wear Levelling Works

There are two main types of wear levelling. Dynamic wear levelling distributes new write operations across cells that are currently available (empty or marked for erasure). This prevents frequently updated data from repeatedly hitting the same cells. Static wear levelling goes further by also moving data that has been sitting unchanged in cells for a long time (cold data) to cells that have been used more frequently, and vice versa. This ensures that even cells holding static data share the overall write burden.

Both types of wear levelling are managed by the FTL, which maintains a mapping table that translates logical block addresses (what the operating system sees) to physical page addresses (where data actually resides on the NAND chips). This mapping changes constantly as the controller moves data around.

The Impact on Data Destruction

The core problem for data destruction is this: when you tell an SSD to write new data to a specific logical address, the FTL decides where that data physically goes. It may or may not write the new data to the same physical location where the old data resided. In fact, it almost certainly will not, because the FTL’s wear-levelling algorithm will direct the new write to whichever cell it determines is most appropriate for balancing wear across the drive.

This means that overwriting logical address 0 through to the last logical address does not overwrite all physical cells. The old data at the original physical locations may remain untouched while the new overwrite data is written to entirely different physical cells.

The result is that portions of the original data can survive a complete logical overwrite. These surviving data fragments exist in cells that the FTL has rotated out of active use as part of its wear-levelling operations. They are not accessible through the normal host interface, but they exist on the physical NAND and could potentially be recovered by someone with direct access to the flash chips.

The Scale of the Problem

The amount of data that could survive a logical overwrite depends on several factors, including how aggressively the SSD’s wear-levelling algorithm operates, the amount of over-provisioned space on the drive (which is not user-accessible and is reserved for wear levelling), how full the drive was before the overwrite, and the age and write history of the drive.

Research has shown that after a complete logical overwrite of an SSD, residual data can persist in anywhere from 1% to over 20% of the drive’s physical capacity, depending on the drive model and usage history. While this represents a fraction of the total data, for sensitive applications even a small amount of recoverable data is unacceptable.

Why Filling the Drive Does Not Help

A common workaround that people attempt is to fill the SSD completely with new data, reasoning that this will force the controller to write to every physical cell. While this approach does increase the likelihood of overwriting more cells, it does not guarantee complete coverage. The controller may still reserve some cells in the over-provisioned pool, and cells that have been retired as bad blocks are not touched regardless of how much data is written.

Additionally, filling an SSD to capacity can trigger aggressive garbage collection that moves data around unpredictably, potentially creating new copies of original data in cells that were previously clean.

The Correct Approach for SSDs

To properly sanitise an SSD despite wear levelling, you need to use methods that operate at the firmware level rather than the host interface level.

Firmware-level sanitise commands (ATA Secure Erase, NVMe Sanitize) instruct the drive’s own controller to erase all cells, including those in the over-provisioned pool and wear-levelled areas. Because the controller has direct access to all physical cells, it can reach areas that host-level overwrites cannot. See our guide to NIST 800-88 for how these commands map to sanitisation levels.

Cryptographic erasure sidesteps the wear-levelling problem entirely. If all data on the drive was encrypted, destroying the encryption key renders every physical cell’s contents unreadable, regardless of where the controller placed the data.

Physical destruction eliminates wear-levelling concerns by destroying the NAND chips themselves. When the physical medium no longer exists, the location of data on it is irrelevant. For more on physical methods, see our guide to hard drive destruction methods compared.

The essential point: Wear levelling means that overwriting an SSD’s logical address space does not guarantee that all physical cells have been overwritten. For reliable SSD sanitisation, use firmware-level sanitise commands, cryptographic erasure, or physical destruction. Never rely solely on host-level overwrites for SSDs containing sensitive data. For guidance on integrating SSD-specific procedures into your disposal workflow, see our guide to building an IT asset disposal policy.

Wear levelling is the single biggest reason that SSD data destruction requires different methods than HDD data destruction. Understanding this mechanism is the key to selecting effective sanitisation approaches for the solid-state storage that now dominates modern IT environments.