I was hoping someone would be able to give some advise on what would be the best way to verify that an SSD has been erased completely. We are currently using Blancco v5 and even though it says it has been successful is there a way to manually check the SSD ?

  • Does this SSD need to be reused? You could always go with physical destruction to be absolutely sure.
    – JAB
    Commented Oct 16, 2017 at 15:26
  • Indeed it will need to be reused, otherwise that would have been the first option.
    – Bradley
    Commented Oct 16, 2017 at 15:28
  • Due to how TRIM works, it is sufficient to create a big expanding file that writes anything until you run out of space. That way, all blocks have been overwritten and there is no way of knowing or determining what was there before.
    – Overmind
    Commented Oct 19, 2017 at 11:42
  • @Overmind not necessarily, you may have old sectors that are no longer usable for writing but are still readable.
    – JAB
    Commented Oct 26, 2017 at 16:53
  • Those you can't erase anyway.
    – Overmind
    Commented Oct 27, 2017 at 11:18

1 Answer 1


Because of the way SSDs manage writes, it is not possible to truly verify that data has been erased without modifying the low-level firmware on the drive itself. Below are the features SSDs have (wear leveling and overprovisioning) that make erasing data problematic. If you already know all that, skip down to "ATA Security Erase", which is the only solution to erasing all data.

Wear leveling

Data on SSDs is stored in "cells". A cell may only have a lifetime of 10,000 writes, so a way to allow you to write to a single file more than 10,000 times without breaking your drive is necessary. The technique used is called wear leveling, and the way wear leveling works is, when you send a command to write to sector A, the drive does not actually write to physical sector A. Instead, it picks a random sector (or a sector which has not seen much use lately), let's call it B, and writes the data there. It will remember that logical sector A maps to physical sector B, so accessing sector A retrieves the contents of B. However, if you try to write a second time to A, for example to overwrite it, the SSD finds a new free sector, C, and writes to that instead, merely updating its mapping to remember that A now points to C. The physical sector you wanted to erase is never touched until it happens to get chosen as the destination for another write down the line.

Note that this is a bit of a simplification, as modern SSDs actually use static wear leveling, which gives sectors under heavy writes a rest by exchanging their data with sectors that have not changed in a long time. What I described was dynamic wear leveling, but for the purpose of this answer, they are functionally equivalent.


Imagine your drive is so full that only a couple of sectors are free. Now what if you start heavily writing to the free space in the drive? The wear leveling would be ineffective because it only has a few cells to choose from, and those cells would rapidly break down. A way to prevent a full drive from breaking was needed, and it is called overprovisioning. Overprovisioning enhances wear leveling by making the drive report less storage capacity than it actually has. An N GB drive (drives are measured in GB, which is a multiple of 1000) may actually have N GiB (with GiB being multiples of 1024) worth of flash cells. By making some of it inaccessible, even when the drive is reporting it is 99.9% full, it may actually only be 80% full. This means that, even if you have only a few sectors free, you can still write heavily to the drive, and it will still be able to spread the wear out among many more cells. In other words, the number of physical sectors exceeds the number of logical sectors. Unfortunately for data erasure, this means that even filling up the whole drive does not overwrite everything.

In terms of implementation, the overprovisioned space is essentially equivalent to a version of the HPA (Host Protected Area) which contains nothing and who's size cannot be modified.


TRIM is a feature which allows the operating system to request that the physical sectors pointed to by a certain range of logical sectors be physically deleted ("flashed"). It is intended to mitigate an issue called write amplification by letting the SSD know which filesystem blocks have been deallocated and marked as free. Without TRIM, an SSD will faithfully keep even this unallocated data, as it has no idea if it's actually being used by the filesystem or not. When TRIM tells it to delete a range of sectors, it destroys them and marks them as free, making wear leveling more effective. However TRIM is also capable of securely overwriting data. Deleting a file on a filesystem marks all those blocks as free, and the corresponding sectors will be communicated to a TRIM-capable SSD by the operating system, which will securely erase them. In theory, you could even TRIM an entire drive, destroying all the data on it, but there is no guarantee that the SSD will behave the way you want it, rather than, say, ignoring the overprovisioning area or deferring erasure to a garbage collector later down the line.

ATA Security Erase

The only way to securely erase an SSD is to use the ATA Security Erase feature, present on all ATA6-compliant drives (i.e. virtually all modern ones). Attempting to overwrite data on an SSD will not actually remove everything due to overprovisioning space mentioned above. Unfortunately, because of this overprovisioning space, you cannot actually read everything which is present on the drive, as this space is always hidden, so you cannot verify if you have overwritten everything.

ATA Security Erase is designed to solve this problem by doing a low-level overwrite of every single sector. On some newer SSDs, an additional feature calld ATA Enhanced Security Erase can be used to destroy a master key which the drive uses to transparently encrypt and decrypt your data. Destroying the key is instantaneous, but renders all the encrypted content inaccessible.

There is no way to know whether or not ATA Security Erase succeeded or was implemented correctly, but modern, fairly well-regarded drives such as Intel SSDs are likely to implement it correctly. If you want, you can spray your drive with a constant pattern and initiate the security erase, then search through your drive for that string. While that won't tell you if the erasure worked, it will tell you if it did not work.

How to accomplish this on Linux

Linux has all the tools to do this. Here is how I would do it, assuming the drive is /dev/sda.

# it must say "not locked", "not frozen", and "supported: enhanced erase"
hdparm -I /dev/sda | grep -A8 "^Security:"

# overwrite the drive with a repeating pattern to check for after
yes "You should not see me" > /dev/sda

# begin the erasure, without using a password
hdparm --security-set-pass NULL /dev/sda
hdparm --security-erase-enhanced NULL /dev/sda

# check if the repeating pattern is anywhere to be found
strings /dev/sda | grep "You should not see me"

Writing a repeating string, erasing the drive, and checking for that string is not particularly fast, efficient, or reliable, but it's the closest thing to what you are looking for.

In some cases, the BIOS sets the drive to "frozen", which prevents various actions like ATA Security Erase. This is a poorly-thought out way to prevent malware from locking your drive. Because it's the BIOS which sets this, you can often unfreeze a drive by plugging it in after the system is already powered up (make sure it supports hotplugging!), connecting it to a SATA adapter (note that not all USB to SATA adapters support ATA commands), or, in some cases, suspending the computer and resuming from suspension. As long as it is not frozen or locked, the above commands should work.

  • Overwriting with a compressible pattern may not work as intended as drives may be using compression internally. If you want to be able to check for your pattern with the command shown, maybe concatenate 491 bytes from /dev/urandom with the 21-character test string to form 512-byte blocks and use different 491 random bytes for each block. Commented Jul 20, 2023 at 13:33
  • There is many things that can go wrong with ATA security erase that the above pattern check cannot find, e.g. insufficient randomness in the seeding of the internal keys. If you trust the implementation it should suffice to overwrite the first few KiB with a test pattern to have some kind of confirmation that you sent the erase command correctly. Commented Jul 20, 2023 at 13:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .