Data destruction · How it works
Purge is not one command. It is a menu, and the wrong choice still passes.
Erasure tools read what a drive can do. The difference is what happens next. Some check that the method somebody already chose is supported, others simply attempt it. Ours decides which method is correct for that specific device, and then proves it worked.
The only company we can find anywhere in the world that warrants the outcome and guarantees permanent, irretrievable data destruction.
A new standard nobody has yet been able to match, backed by £10 million of professional indemnity insurance. If you find another vendor whose licence warrants that the data is gone, we would like to see it, and we will say so publicly.
The failure everyone inherits
A support check cannot catch a supported but wrong method
In the conventional model the erasure method is a setting. An operator or a configuration picks it before the drive is processed. Some products then confirm the drive supports that method before running, others simply attempt it. Where that check exists it sounds like a safeguard, and it is not one.
A support check can only reject a method the drive cannot run. It can never reject a method the drive can run but which is wrong for it. And the most wrong method of all, plain overwrite, is supported on effectively every drive in service, even though on a modern drive it leaves large parts of the media untouched. So the one check standing between an operator and a bad erasure, where it exists at all, is structurally incapable of flagging the actual problem, because the problem is always a supported method. The check passes precisely when it matters least.
Change the setting from overwrite to a purge and you meet the real difficulty immediately, because purge is not a command. It is a family of them, and which one is correct depends on the exact interface and media of the drive in front of you.
| Interface | Media | Correct purge command |
|---|---|---|
| SAS / SCSI | HDD | SCSI SANITIZE (Overwrite) |
| SAS / SCSI | SED or ISE | SCSI SANITIZE (Cryptographic Erase) |
| SAS / SCSI | SSD | SCSI SANITIZE (Block Erase), or Cryptographic Erase, or Overwrite where supported |
| SATA / ATA | HDD | ATA SECURITY ERASE UNIT (Enhanced), where the implementation meets purge requirements |
| SATA / ATA | SED | Cryptographic erase or key sanitisation, where correctly implemented |
| SATA / ATA | SSD | ATA SANITIZE (Block Erase), (Crypto Scramble) or (Overwrite) |
| NVMe | SSD | NVMe Sanitize (Block Erase), (Crypto Erase) or (Overwrite) |
| NVMe | SSD | Format NVM (User Data Erase) or (Cryptographic Erase), where the implementation satisfies the purge outcome |
No operator holds that in their head and selects correctly from it, by hand, across thousands of drives a shift. The operator would still have to interrogate every individual device, correctly interpret its interface, media, security and sanitisation capabilities, and then choose the correct method from the several methods that device may validly support. At production volume that is precisely the judgement the engine removes.
So the real choice is not between selecting correctly by hand and selecting correctly automatically. It is between one wrong setting applied to everything, or interrogating each drive in place and selecting for it automatically. Put those two in front of an operator working to a quota and the outcome is not in doubt.
What the engine does
Interrogate, select, prove
Interrogate
The engine establishes a link to the device and reads its actual characterisation parameters: interface, media type, capability, security layer, health. Not the model number, the device itself.
Select
From those parameters it determines the single correct media-appropriate command for that unit and applies only that one. The operator is given no method to choose and no list to choose from. Where the correct method cannot be executed and proven, the device fails closed and no certificate is issued.
Prove
A known random pattern is written to random sectors before the erase, then read back afterwards. If it is gone, the operation did what it claimed. If it is still there, the drive is failed.
Certify or fail
Only a proven result produces a certificate. Anything else is quarantined for firmware remediation or physical destruction.
Correct command completed, known pattern unrecoverable, every readable region including remapped sectors reported clear. Certificate issued, warranted, indemnity behind it.
Device failed closed and quarantined. No certificate. No partial pass, no substitute method, nothing recorded as erased with warnings.
The proof
We do not ask the drive whether it worked
The interface standards, NVMe, TCG, ATA, SCSI and SATA, do not expose the encryption key and do not prove what happened to the data. They return a flag on the command’s outcome and a progress indicator. Taking that flag on trust is what most of this industry calls verification.
Instead we write a known random string into random sectors before the erase, run the media-appropriate command, and read those exact sectors back. That is an empirical before and after test of the actual result.
On a self-encrypting drive it is a complete proof, and the chain is worth setting out in full. The engine has already established that the device is a self-encrypting drive and has selected cryptographic erase as the correct method for that verified implementation. The marker is therefore written under the same media encryption regime that protects the user data. The erase destroys the governing key. Reading those sectors back afterwards is the empirical check that data written under that key can no longer be recovered. Because all user data on the drive is protected by that same media key, the result applies to the user-addressable area and to encrypted data in the remapped, spare and over-provisioned areas alike, including the regions no interface can reach.
You do not read the hidden cells. Nobody can, ours included, because they are not exposed to the host. You prove the single thing that governs all of them. On a drive without encryption the block erase or native sanitize clears every block from inside the controller, where the host cannot reach, and the marker confirms the operation executed on the media that can be sampled.
In 2018 researchers at Radboud University published Self-Encrypting Deception, showing that hardware encryption in a range of widely used SSDs was broken: the key was not tied to the password, data was recoverable without it, and on some drives an old copy of the key survived in flash after erasure. Their conclusion was that you must not rely on a drive’s own encryption on its word. Meijer and van Gastel, Radboud University
That is exactly what the engine is built not to do. It does not accept a drive’s report that it erased. Where a model or firmware is known to implement encryption or erasure unsafely, the device is failed closed and referred for firmware remediation rather than certified. The drives that study compromised are either caught, because the data survives the erase, or rejected, because the implementation cannot be trusted. Neither leaves with a certificate.
What irretrievable means here
Three things together, not a claim
It is not a claim to have read cells that no interface can reach, because that claim would be false from anyone who made it. It is verification of the operation that makes those cells unreadable, together with the physical evidence from every area that can be read.
Coverage and protection
Media, standards and IP
This is not a gap a competitor closes with a settings change or in the next release, and for a partner that matters as much as the engineering, because the capability at the centre of the proposition is the subject of our published patent claims.