What a Certificate of Data Erasure should actually prove

A Certificate of Data Erasure is a document saying a device's data was destroyed. Clients ask for them, auditors read them, and they turn up at the end of most IT asset disposition contracts.

The uncomfortable question is what the certificate is evidence of.

In a lot of workflows, the honest answer is: someone ticked a box. The wipe may well have happened. The certificate records that an operator asserted it did. Those are different claims, and only one of them is worth putting a signature on.

Three things that get conflated

The standards vocabulary — NIST SP 800-88 is the usual reference — separates things that everyday language mashes together.

Clear overwrites the drive through its normal interface. A single zero pass defeats any software-level recovery. It does not touch sectors the controller has remapped out of service.

Purge uses a firmware-level operation: a cryptographic erase that discards the drive's encryption key, or a sanitize command that the controller applies across all its media, including remapped blocks.

Destroy is physical. Shredding, disintegration.

A certificate that just says "wiped" tells the reader none of this. If the drive was overwritten but the client's threat model assumed a purge, the document has communicated something untrue by omission — without containing a single false sentence.

So the method goes on the certificate. Not "securely erased". The actual operation, on the actual drive.

Firmware erase is not one command

I built the erase path expecting to write one function. What field testing gave me was a dispatch table.

A Dell NVMe SSD reported through nvme id-ctrl -H that it did not support cryptographic erase via FORMAT — but its sanitize capability register showed both crypto erase and block erase available. Same drive, same feature, reachable through one command set and not the other. A tool that only tried FORMAT would have concluded the drive could not be purged and quietly fallen back to overwriting it.

SATA has its own obstacle. ATA secure erase is normally blocked at boot, because most systems issue a security freeze during POST specifically to stop it. Unfreezing means a suspend/resume cycle. There is also a genuinely nasty failure mode: ATA secure erase sets a drive password before erasing, so an erase that fails partway leaves the drive locked and, to a warehouse, bricked. Whatever else that path does, it has to always run the password-disable cleanup — a failure should degrade to "not erased", never to "unusable".

The result is four methods — NVMe format, NVMe sanitize, ATA secure erase, overwrite — tried in capability order, with the one that actually succeeded recorded by name.

Verification has to know which method ran

Here is the part I got wrong first.

The obvious verification is to read the drive back and confirm it is zeros. That works for an overwrite. Applied to a cryptographic erase it fails every single time — and correctly so. A crypto erase does not zero anything. It discards the key. What remains on the platters or in the NAND is the original ciphertext, now permanently undecryptable. It reads as noise, because that is exactly what it is.

So verification is method-dependent:

• Overwrite — sample the start, middle and end of the drive and confirm zeros. If a fast path such as TRIM was used and the sample does not read clean, fall back to a full zero-overwrite and check again.
• Crypto erase — you cannot read-back-verify. What you can do is confirm the controller reported the operation complete, and record it as controller-confirmed rather than claiming a verification you did not perform.

That distinction ends up printed on the certificate. "Wiped — verified" and "wiped — controller-confirmed" are different claims, and a reader who knows the difference deserves to see which one they are getting.

My sampling is exactly that: sampled, not exhaustive. Three 32MB windows, not a full-drive read-back. For a genuinely audit-grade claim you would want the whole surface. I would rather write that limitation down than let the word "verified" carry more weight than the check behind it.

The feature is the refusal

The generator produces a certificate from the erasure record: device identity, method, date, operator, issuer. If no completed wipe exists for that device, it returns an error and produces nothing.

That refusal is the entire point.

A certificate generator that will produce a document whenever it is asked is just a template with a database attached. It generates paperwork. The moment it cannot produce a certificate for a device that was not wiped, the document starts carrying real information — because the system's inability to lie about it is what the signature is standing on.

It is also the feature most likely to be quietly removed under commercial pressure, on a Friday, when a shipment is waiting. Which is a reasonable argument for making the refusal loud, logged, and awkward to route around.

What a good certificate says

Reading back over the ones my system now issues, the useful fields are:

• Device identity — manufacturer, model, serial, and the specific drive
• Method — the operation that ran, named precisely
• Verification — how it was checked, and by what standard
• When and by whom — timestamp and operator
• Issuer — the company standing behind the claim

And the field that is not there: any way to produce this document without the underlying event.