For most of the past three decades, retiring a computer safely meant dealing with a spinning hard disk. The procedures were well understood: overwrite the platters several times, or run the drive through a degausser, or physically destroy it. Those methods worked because magnetic storage behaves in a predictable way. Data sits in known physical locations, and writing over those locations replaces what was there.
Solid state storage does not work like that at all, and the security practices built around magnetic media have quietly stopped being reliable. Many organizations have not updated their procedures to match, which means drives are being retired every day under the assumption that they have been sanitized when they have not.
The core issue is how flash memory manages itself. An SSD contains substantially more physical storage than it reports to the operating system, and its controller constantly moves data between cells to spread wear evenly. A conventional overwrite reaches the addresses the operating system can see, but not the reserved capacity holding remapped blocks. This is exactly why organizations handling regulated or confidential information increasingly turn to ssd destruction services rather than relying on software erasure alone, since destruction removes the uncertainty that overwriting leaves behind.
The Technical Reasons Overwriting Falls Short
Wear levelling is the first problem. Flash cells degrade with each write cycle, so the controller distributes writes across the full pool of available cells. When a file is modified, the new version is often written to a fresh location while the old version remains intact in a block the operating system no longer references. Overwrite software cannot address those blocks, because they are invisible above the controller layer.
Over-provisioning compounds it. Drives typically reserve somewhere between seven and twenty-eight percent of their raw capacity for wear management, bad block replacement, and garbage collection. That reserve is genuine storage holding genuine data, and no host-level utility can reach it.
Bad block retirement adds a third layer. When the controller detects a failing cell, it marks the block unusable and remaps the data elsewhere. The retired block still contains whatever was written to it, and it is now permanently out of reach of any software running on the host. Forensic techniques that read flash cells directly, bypassing the controller entirely, can recover data from these regions.
Degaussing, which was reliable for magnetic media, has no effect whatsoever. Flash stores charge in transistor gates rather than magnetic domains, so a magnetic field passes through without altering anything. A degaussed SSD comes out the other side fully intact, which has caught out more than one organization following an outdated checklist.
Where Built-In Sanitize Commands Fit
Modern drives implement cryptographic erase and secure erase commands that instruct the controller to sanitize the entire flash array, including reserved regions. When implemented correctly, these are effective and fast, particularly cryptographic erase on a self-encrypting drive, which destroys the encryption key and renders all stored ciphertext meaningless in seconds.
The qualification is significant, though. Implementation quality varies widely between manufacturers and firmware revisions, and independent testing has repeatedly found drives where the sanitize command reports success without fully clearing the array. Verification is difficult, because confirming that reserved regions were cleared requires reading the flash directly rather than through the controller.
There is also the practical problem of drives that will not respond. A drive that has failed, locked itself into read-only mode, or lost controller function cannot execute a sanitize command at all. Failed drives are precisely the ones most likely to be sitting in a bin awaiting disposal, and they are the ones software cannot touch.
Why Shred Particle Size Actually Matters
Physical destruction is the fallback that works regardless of drive state, but the standard applied to hard disks does not transfer directly. A hard drive holds data across large platter surfaces, so breaking it into sizeable fragments destroys the readable structure.
Flash is different. Data lives on small memory chips soldered to the board, and a fragment large enough to contain an intact chip is a fragment that may still hold recoverable data. Destruction standards for solid state media therefore specify much smaller particle sizes, commonly two millimetres or below depending on the classification of the information involved, to guarantee that every memory package is physically broken rather than merely separated from its board.
This is why running SSDs through equipment designed for hard disks is inadequate. The output looks convincingly destroyed while potentially leaving intact chips within the debris.
Building a Procedure That Holds Up
A workable approach starts with encryption from day one. Full disk encryption applied at deployment means that any drive leaving the organization is already ciphertext, which limits exposure even if the disposal step fails.
From there, drives should be inventoried by serial number at the point of removal so that the count leaving a site matches the count arriving at the processor. Every drive should have a recorded outcome tied to its serial number, and the resulting certificate should list individual drives rather than a bulk quantity.
Media should be secured between removal and processing, because the gap between decommissioning and disposal is where drives most often go missing. A locked container and a documented handover close that gap.
The Practical Conclusion
The safest posture treats solid state media as something to be destroyed rather than cleaned, unless there is a compelling reuse case and verified sanitize capability to support it. The value of a used drive rarely justifies the risk of an incomplete erasure, and the cost difference between the two approaches is small compared to the cost of a disclosure incident.
