An SSD does not let you write where you want to. Its controller spreads writes across the chips to even out wear, and it keeps a reserve of blocks the operating system cannot see at all. So when software overwrites 'the whole drive', it overwrites what the controller exposed — and the reserve keeps whatever was there.
That is why an overwrite pass can report complete success while the original data is still sitting in over-provisioned blocks, recoverable by anyone who reads the chips directly.
The correct approach is to stop writing and start commanding. Every modern SSD implements a sanitize or secure-erase instruction that clears the whole flash array, reserve included, and self-encrypting drives can simply have their key destroyed. We issue the right one for the drive in front of us, then verify.
The Risks This Removes
Over-Provisioning Keeps Your Data
Between 7% and 28% of an SSD is reserve capacity the OS cannot address. An overwrite never touches it, and neither does a format.
Wear Levelling Moves It Around
The controller decides where writes land. Overwriting a file does not overwrite the blocks that file used to occupy.
A Reset Is Not a Sanitize
Manufacturer reset tools often only clear the mapping table. The chips still hold the data until the drive gets around to garbage collection — if it ever does.
Identify, Erase, Verify, Report, Then Decide
On flash the first step carries the most weight: what the drive is decides which command can actually reach the data.
- 01
Identify
Interface, controller and whether the drive is self-encrypting. An SSD that lies about its geometry is common; the drive is asked directly.
- 02
Erase
Sanitize, format or cryptographic erase, whichever that drive implements, with an overwrite only as the fallback.
- 03
Verify
A read of the medium after the fact, rather than trust in the return code the controller handed back.
- 04
Report
A certificate naming the command that was issued, not just the standard it satisfies.
- 05
Reuse, Resell or Destroy
A verified SSD keeps its resale value. Shredding one that did not need it is the expensive option.
The Command the Drive Actually Supports
SATA drives take ATA Secure Erase or Sanitize. NVMe takes Format NVM or Sanitize as the specification defines them. Self-encrypting drives take a cryptographic erase, which destroys the key and makes every block on the drive meaningless in seconds. The software identifies the medium and issues what it supports.
Verified, Not Assumed
Issuing a command is not proof it worked — some drives report success and do nothing. After the erase we read back across the address space and check. If the drive fails verification it is marked for destruction and named on the report.
The Process, Step by Step
Read the Drive, Not the Label
Model, firmware, capacity and serial come off the drive. The firmware revision matters here, because it decides which erase commands the drive will actually honour.
Ask What It Supports
The drive is queried for the sanitize and secure-erase operations it implements. What it answers decides the method — not a setting chosen in advance.
Issue the Command
Block erase, crypto erase or overwrite, whichever the drive supports and your policy allows. The controller clears the whole medium, including the reserve an overwrite can never reach.
Read It Back
The drive is read after the erase and compared. A drive that reports success and still returns data is failed, not passed.
Destroy What Will Not Clear
A drive that refuses the command, is locked, or fails verification is not shipped as erased. It is shredded, and the certificate records that instead.
Certify per Drive
One signed document per SSD, naming the command that was issued and the result of the read-back.
Solid State Media We Process
Flash comes in more shapes than any other medium. What matters is the controller and the command set, not the connector.
Form factors
- 2.5in SATA solid state drives
- M.2 SATA and M.2 NVMe
- mSATA and half-height mSATA
- U.2 and U.3 enterprise drives
- Add-in PCIe cards
- Soldered eMMC and UFS storage
Command sets
- ATA Secure Erase and Enhanced Secure Erase
- ATA Sanitize block erase and crypto erase
- NVMe Format with secure erase settings
- NVMe Sanitize block and crypto operations
- TCG Opal and Pyrite key revocation
Special cases
- Self-encrypting drives with an active key
- Drives frozen by the host BIOS
- Drives locked with an ATA password
- Drives with failing or worn-out blocks
- Storage soldered to the mainboard
Which Method Applies
| Situation | What We Do |
|---|---|
| Drive is healthy and supports a sanitize command | Issue the drive's own sanitize operation, then verify by reading it back |
| Drive is self-encrypting with a live key | Cryptographic erase to revoke the key, verified, plus a block erase where policy asks for it |
| Drive supports only legacy secure erase | Issue secure erase, verify, and record which command was used |
| Drive is frozen by the host or password locked | Unlock where the owner can authorise it; otherwise the drive is destroyed |
| Drive fails verification after the erase | Reported as failed and physically shredded — never shipped as erased |
| Storage is soldered to the board | The board is processed as a whole, or the storage is destroyed with it |
What Makes an SSD Erase Trustworthy
Command First, Overwrite Second
The drive's own sanitize instruction reaches the whole flash array, including over-provisioned blocks. An overwrite aimed at logical addresses may never touch the cell that held your data.
Cryptographic Erase Explained
A self-encrypting drive stores everything encrypted. Destroying the key makes the ciphertext unreadable in an instant — fast and thorough, but only as good as the drive's own encryption, which is why we verify rather than assume.
Firmware Awareness
Different firmware revisions of the same model implement different commands. The drive is asked what it supports at the time of the erase, rather than looked up in a table written last year.
Failure Is Recorded, Not Hidden
Flash wears out. A drive that will not clear cleanly is marked failed and destroyed, and the certificate says which of the two happened.
No Degaussing
A degausser does nothing to flash — there is no magnetic pattern to disturb. Anyone offering to degauss an SSD is selling a process that cannot work.
Shredding to Flash Size
Where an SSD must be destroyed, the fragments have to be small enough that an individual memory chip cannot survive intact. Hard-drive shred sizes are not fine enough for flash.
Media We Handle
- SATA SSD — 2.5in, mSATA and M.2 SATA
- NVMe — M.2, U.2 and PCIe add-in cards
- Self-encrypting drives (SED, Opal, eDrive) via cryptographic erase
- Enterprise SAS SSDs, including dual-port
- Hybrid drives (SSHD), where both the flash cache and the platters are handled
- Embedded flash — eMMC and UFS in laptops, tablets and thin clients
What the Certificate Says About an SSD
The important line on an SSD certificate is which command was issued. A document that says only "wiped" does not tell an auditor whether the reserve blocks were reached, and on flash that is the whole question.
- Model, capacity, firmware revision and serial number
- The exact operation issued — sanitize, crypto erase, secure erase or overwrite
- Whether the drive was self-encrypting, and whether the key was revoked
- The verification read and its result
- Where verification failed, the destruction that followed instead
- Start and finish time, and the operator who ran it
- A digital signature, so an edited certificate no longer validates
- 5 interfacesSATA, SAS, NVMe, M.2 and U.2
Each one takes a different command. The software identifies the medium and issues what that medium actually implements.
- 25 methodsErasure Standards Built In
NIST SP 800-88 Clear and Purge, IEEE 2883, DoD 5220.22-M, BSI, DPDP and twenty more. The software issues what the medium actually supports.
- 0 blind passesOverwrites Issued Without Asking First
An SSD remaps blocks behind your back, so an overwrite aimed at a logical address may never touch the cell that held the data. The sanitize command is asked for first and the overwrite is the fallback.
- 100%Of Erased Drives Read Back
Verification is a separate read of the medium after the erase, not a reading of the return code the drive gave.
The Standards That Actually Cover Flash
Several widely quoted overwrite standards predate solid state storage. Where that is true of one, this says so rather than implying it still applies.
NIST SP 800-88 Rev. 2
Treats flash separately from magnetic media, and for Purge points at the drive's own sanitize or cryptographic erase rather than at overwriting. This is the guidance that says, in effect, stop writing and start commanding.
When it appliesThe default reference for SSD and NVMe sanitization, and the one worth naming in your own policy.
IEEE 2883-2022
Written after flash was already dominant. It defines Clear, Purge and Destruct with the physics of solid state storage in mind, and requires the result to be verified rather than assumed.
When it appliesWhere a policy is being written now, or where a customer asks for the most current sanitization standard.
ATA and NVMe Sanitize
Not policy but the command sets themselves — the instructions built into the drive by its manufacturer that clear the entire flash array, reserve blocks included. Everything above ultimately relies on these.
When it appliesEvery SSD erase we run. Which of them is available depends on the drive and its firmware.
TCG Opal
The specification behind most self-encrypting drives. It defines how the drive holds its encryption key and how that key is revoked, which is what a cryptographic erase actually does.
When it appliesSelf-encrypting drives, which is most enterprise SSDs shipped in the last decade.
DoD 5220.22-M
A multi-pass overwrite pattern designed for magnetic platters. On flash it wears the drive, takes far longer, and still cannot reach the blocks the controller has hidden. Supported because policies name it — but not the right tool here.
When it appliesOnly where a policy requires it in writing. We will run it, and we will also issue the sanitize command that does the real work.
DPDP Act and GDPR
Both require personal data to be erased when its purpose ends, and both expect evidence. Neither names a technical method, which is why the method you choose has to be defensible on its own terms.
When it appliesAny organisation holding personal data of people in India, the EU or the UK.
Where People Go from Here
Hard Disk Drive Sanitization
Where overwriting is the right tool, because every sector really can be written to.
Read moreErasing an SSD
The longer explanation of why overwriting flash misses data, written for people who have to justify the choice.
Read moreData Erasure Standards
Every method the software runs, with its pass count and the standard it implements.
Read moreFrequently Asked Questions
Why not just overwrite an SSD several times?
Because it does not reach the reserve blocks and it wears out the drive. Multi-pass overwriting on flash gives you a shorter drive life and no additional assurance. NIST SP 800-88 says the same thing.
Is cryptographic erase really enough?
On a properly implemented self-encrypting drive, yes — the data was only ever stored as ciphertext, and destroying the key leaves nothing that can be decrypted. It is NIST's defined Purge method for SEDs. We verify afterwards regardless.
What if the drive refuses the sanitize command?
Some older or firmware-locked drives do. Those are flagged and physically destroyed instead, with the reason recorded on the report. We do not fall back to an overwrite and call it done.
Can you erase soldered storage in a laptop?
Yes, for eMMC and UFS we boot the machine and sanitize the embedded device in place. Where the controller does not support it, the board is destroyed instead.
Ask What Your Drives Support
Send us the models and we will tell you which of them can be verifiably erased and which cannot.