Standards
There are three ways to sanitize storage, in increasing order of how hard recovery becomes: Clear, Purge and Destruct. WiporaErase performs Clear and Purge, verifies the result, and issues a signed certificate saying which was achieved and how.
A note on wording. We implement NIST SP 800-88r2 and IEEE 2883-2022. We are not “NIST certified” or “IEEE certified” — neither body certifies products, so nobody in this market can hold such a certification.
Clear
We perform thisIEEE 2883-2022 §6.2 · NIST SP 800-88r2 §3.1.1
Protects: Against someone plugging the drive in and reading it back.
How: A pattern written to every addressable location, through the host interface.
Limit: Cannot reach what the host cannot address — reallocated sectors, over-provisioning, caches. That is true of any overwrite, at any number of passes.
Purge
We perform thisIEEE 2883-2022 §6.3 · NIST SP 800-88r2 §3.1.2
Protects: Against a laboratory taking the drive apart.
How: The drive's own sanitize command — cryptographic erase, block erase, or a native sanitize overwrite — which reaches areas the host interface cannot.
Limit: The standard's own wording is that recovery becomes infeasible using state-of-the-art laboratory techniques. It is not a claim that the drive is destroyed.
Destruct
Not performedIEEE 2883-2022 §6.4 · NIST SP 800-88r2 calls it Destroy
Protects: The medium no longer exists as a usable device.
How: Disintegration, incineration, melting, shredding.
Limit: We are software and cannot perform it. Where no purge technique succeeds, the certificate states that destruction is required — we do not perform it and do not record that it happened.
r2 replaced r1 in September 2025 and did something unusual: it deleted its own technique tables and pointed at IEEE 2883 instead. Implementing IEEE 2883 is how you satisfy NIST SP 800-88r2 — which is why our NIST and IEEE methods run the same engine and differ only in how the certificate is worded.
| Topic | r1 (2014) | r2 (2025) |
|---|---|---|
| Technique detail | Appendices A and C held large per-media technique tables | Those appendices were removed. r2 defers the "how" to IEEE 2883 |
| Multi-pass overwrite | Implied acceptable | Explicitly countered. r2 notes DoD removed overwrite specifications from NISPOM in 2006 |
| Verification | Full or representative sampling recommended | Sampling not necessary unless organizational policy requires it |
| Validation | Not a concept | New. An explicit accept or reject decision on the sanitization |
| Degaussing | Purge and destroy | Purge only — not a destroy technique, even when it leaves the drive inoperable |
| Cryptographic erase | An appendix | Main body, with FIPS 140-3, ≥128-bit and ISO/IEC 19790 key zeroization requirements |
| Terminology | "electronic media" | ISM — information storage media, which includes cloud and logical storage |
Passes don’t make a purge. Reaching the whole medium does.
IEEE 2883-2022 §6.5.1
A software overwrite goes through the host interface, so it physically cannot reach a sector the drive has already retired. Under both IEEE 2883 and NIST SP 800-88r2 that makes it a Clear — on every media type, at three passes or thirty-five. Tools that run a multi-pass overwrite and print “Purge” on the certificate are mislabelling the result. We label it Clear.
We never downgrade silently.
IEEE 2883-2022 §6.1, §8.4.3.1
The engine tries the purge techniques in order — cryptographic erase, block erase, sanitize overwrite, ATA Enhanced Secure Erase. If every one fails the drive is marked FAILED and the certificate states that destruction is required. It does not quietly fall back to an overwrite and call the job done.
We prove the data was there, and then wasn’t.
IEEE 2883-2022 §8.4.2.2, §8.4.3.2
Offset-bound markers are written to sampled locations before sanitizing, then read back afterwards. Reading a drive afterwards and finding it blank proves little — a drive that was never written also looks blank. This proves that this specific data was destroyed.
Hidden areas are exposed before we start.
IEEE 2883-2022 §8.4.2.2(a)
Access limits are reset before sanitization begins: HPA, DCO, Accessible Max Address, Zone Activation, Storage Element Depopulation and TCG locking ranges. An overwrite that ignores a Host Protected Area leaves data behind while reporting success. This is not an optional setting.
Verification and validation are different, and we do both.
NIST SP 800-88r2 §4.5.1, §4.5.2
Verification asks what happened — command status, errors, anomalies, and drive health after the wipe. Validation asks whether that is good enough, and returns an explicit ACCEPTED or REJECTED. We re-read SMART after the wipe and will reject a sanitization when a host overwrite was used on flash, when sectors are pending reallocation, when HPA or DCO could not be removed, or when the drive reports a SMART failure. A rejected wipe is not certified as complete.
Sampling follows the standard’s own numbers.
IEEE 2883-2022 §7.1, §7.3, §7.4
10,000 subsections, at least two pseudo-random locations in each, plus the first and last addressable location — 20,002 locations per drive, deterministic per device so an auditor re-running it checks the same places. A Purge gets full verification of the addressable media rather than a spot check. The exception is honest: after a cryptographic or block erase the contents are unpredictable by design, so §7.4 says full verification is not effective — we fall back to the known-pattern check and say so on the certificate.
Published here rather than left for an evaluation to uncover. If one of these blocks a deployment you are planning, tell us — several are known gaps rather than refusals.
eMMC and UFS are not supported
We handle ATA, SCSI/SAS and NVMe. Embedded flash — common in laptops, tablets and Chromebooks — has no native purge path in our software today. On those devices only a host overwrite is possible, which is a Clear.
We do not perform destruction
We are software. Where no purge technique succeeds we state that the destroy method is required; we do not perform it, and we do not currently record an operator’s confirmation that it happened.
Crypto-erase conditions are recorded, not independently verified
To call a cryptographic erase a Purge, IEEE 2883 §6.5.3 requires encryption before write, cipher strength and key entropy of at least 128 bits, and all key copies sanitized. We record what the drive reports and mark everything else as “not reported by device” rather than guessing. No in-band command exists to verify those conditions — they come from the vendor’s datasheet. We do not claim FIPS 140-3 validated cryptographic erase.
Sampling is about distribution, not volume
The scheme checks every ten-thousandth of the drive plus both ends, which is a small percentage of total bytes by design. IEEE 2883 also offers a 5%-at-random option, which we have not implemented; if your policy requires it, that is a configuration change rather than a redesign.