From power-on to signed evidence, step by step.
This is the pipeline the DataPurix station is built around, for every storage device. Each step is written to a crash-safe journal before it happens, and anything the station cannot prove moves to quarantine instead of continuing. The development status below shows which parts already run.
- STEP 01Boot DataPurixOS
The station starts a minimal, read-only Linux image from a USB stick; network boot (PXE) is planned. The image is signed and reports its own digest, so a modified image can be refused.
- STEP 02Discover, never mount
The station reads the computer's identity (manufacturer, model, serial, asset tag) from firmware tables. It reads every drive's transport, model, serial, firmware and capacity from the kernel. Customer file systems are never mounted or read, and the disk the station booted from is recognised and never targeted.
- STEP 03Bind the identity
Each drive is bound to its serial, model and firmware plus its physical position (PCI function or SATA port). A device name such as
/dev/sdais never used for this, because names can change between boots. The identity is checked again after the operation. - STEP 04Decide by policy
The policy engine combines four inputs: the customer profile (Clear, Purge or Destroy), what the drive reports it can do, the security state (frozen or locked), and an Approved Device & Firmware Registry. Operators never pick wipe patterns.
- STEP 05Confirm deliberately
Before anything irreversible happens, the screen shows the computer serial, every drive serial, the technique and the policy version. The operator confirms by typing the last characters of the drive's serial.
- STEP 06Sanitize with the drive's own mechanism
NVMe drives use NVMe Sanitize (Block Erase or Cryptographic Erase), and SATA drives use ATA Sanitize. Host overwrite is reserved for magnetic disks. The command is recorded in the journal before it is issued, so a power cut can never cause a silent repeat or an ambiguous result.
- STEP 07Verify from the controller
The station polls the drive's own sanitize status log until it reports completion or failure. A tool exiting without an error is never taken as proof that the data is gone. Raw tool outputs are kept as evidence with their SHA-256 hashes.
- STEP 08Validate separately
A second, independent rule set asks whether the result is acceptable for this job. It checks five things: the technique meets the required class, the registry approval is still valid, the re-read identity is unchanged, the operation started inside its authorization window, and every required evidence file exists. Any failure means no certificate.
- STEP 09Seal the evidence
The result becomes one canonical JSON record (RFC 8785), hashed with SHA-256 and signed with Ed25519. Failed runs are sealed too: they are evidence, just never certificate-eligible.
Every device leaves evidence you can check yourself.
The signed record is the source of truth. A certificate PDF or a report is just a view of it, and anyone holding the public key can check the record without trusting our software, our database or our website.
- Structured evidence is captured at execution time: device identity, policy and technique, timestamps (UTC), tool versions, controller results and the hash of every raw tool output.
- Verification (did the operation complete?) and validation (is that result acceptable?) are recorded as two separate decisions, as NIST SP 800-88 Rev.2 requires.
- The record is canonicalised with RFC 8785 before signing. What is signed is exactly what gets verified, so editing a single character breaks the signature.
- Keys can be rotated without invalidating old records, and a revoked key makes everything it signed fail verification.
- The
dpx-verifycommand checks a record offline and exits with a code scripts can rely on: 0 means valid and certificate-eligible, 3 means validly signed but not eligible (a failed run), 1 means invalid.
{
"evidence": {
"schema": "itad.sanitization.evidence/1.0",
"asset": { "system_serial": "J83FN72", "model": "Latitude 7440" },
"media": { "model": "SAMSUNG PM9B1", "serial": "S64TEST0001",
"firmware": "GXA7401Q", "transport": "nvme" },
"policy": { "classification": "PURGE",
"technique": "NVME_BLOCK_ERASE",
"registry_entry": "adfr_pm9b1_gxa7401q" },
"verification": { "result": "PASS",
"profile": "vp-nvme-sanitize-log/1" },
"validation": { "result": "PASS",
"ruleset": "vr-default/1",
"rationale_codes": ["ALL_RULES_PASSED"] },
"artifact_hashes": [
{ "name": "nvme-id-ctrl.json", "sha256": "6f968f…" },
{ "name": "nvme-sanitize-log.json", "sha256": "92f56f…" }
]
},
"integrity": { "alg": "Ed25519", "key_id": "…",
"canonical_sha256": "dd495f…", "value": "…" }
}The example shows the format with test data. Planned: a PDF certificate rendered only from the signed record, with a QR code that opens a verification page showing VALID, SUPERSEDED or REVOKED and a minimal set of fields.
Failure never becomes a false success.
Sanitization is irreversible, so the platform is built to stop and ask rather than guess. Each rule is enforced in code, with automated tests. The trust core and the station agent already enforce them in the lab, where the erase itself is still simulated.
- Fail closed
Unknown firmware, an ambiguous RAID controller, a USB bridge, a frozen or locked drive, an unreadable probe or a missing identity each produce a quarantine with a reason code. None of them is ever quietly worked around.
- Two checks, two records
A run can only reach PASS after a successful verification and a separate successful validation, and both decisions are stored. The state machine makes "executing → passed" impossible.
- No access to customer data
The station never mounts file systems, never lists files and never uploads content. Automated tests reject any code that could mount a file system.
- The right disk, only
The disk the station booted from is excluded. Every other drive is bound to serial, firmware and physical position, and a changed or swapped drive fails validation.
- Crash-safe journal
Each step is written and flushed to an append-only, hash-chained journal before it happens. After a power loss the station reads the drive's status instead of repeating the operation.
- Read-only by default
Probing uses a fixed list of read-only commands with exact argument shapes. Destructive commands will run only through a small privileged helper with a fixed command grammar.
- Separated keys
Evidence, policy packs and licences are signed by different keys. A licence key cannot sign a policy, and lab keys are never trusted in production.
- Licensing never weakens a wipe
A licence can stop new work from starting, but it cannot change which technique is chosen. A licence that expires mid-operation never interrupts it.
Sanitization built around the device, not a generic wipe.
Each technique is allowed only when the customer policy requires it, the drive reports it, and the exact model and firmware are approved in the registry.
| Media | Technique | Outcome | Notes |
|---|---|---|---|
| NVMe SSD | NVMe Sanitize: Block Erase, or Cryptographic Erase when its prerequisites are met | Purge | Completion read from the drive's sanitize status log. |
| SATA SSD | ATA Sanitize (Block Erase / Crypto Scramble) | Purge | Host overwrite is never used on flash media. |
| Magnetic HDD | ATA Sanitize, or verified overwrite where policy allows | PurgeClear | No obsolete multi-pass patterns. |
| Frozen or locked drive | None automatically | Quarantine | Security state is reported, never forced. |
| Behind RAID or a USB bridge | None automatically | Quarantine | The host cannot reach the drive's own controller. |
| Unknown model or firmware | None automatically | Quarantine | Needs engineering review and a registry entry. |
| Unreadable or damaged | Physical destruction route | Destroy | Witnessed, with its own evidence record. |
| SAS / SCSI, Apple silicon & T2 Macs | Planned, separate workflows | Planned | Not treated as generic drives. |
One trust core, at the station and in the cloud.
The code that decides techniques, checks results and verifies signatures is a single library, compiled into both the station and the cloud service. Both sides reach the same decision, even when a station is offline.
- Offline by design. A station keeps signed policy packs (profiles plus the device registry) and a time-limited, signed licence lease. Work already authorised finishes and is spooled locally, then synchronised when the network returns.
- Tenant isolation (planned). Every record will belong to a tenant, with isolation enforced by the server and by the database, not by the user interface.
- Keys stay protected (planned). Production signing keys will live in a separate key service, never on stations or in the application database.
- EU hosting. datapurix.com is served from Frankfurt, Germany, and the control plane will run there too.
- Built in Go. Small static binaries for the station and the service, the same language on both sides, and pinned versions of every storage utility.
Where the build is today.
We would rather show you honest progress than promise features we don't have yet. Each milestone ships tested software before the next one begins.
- TRUST CORECompletePolicy engine, run state machine, signed evidence, licence leases, offline verifierTest-covered and code-reviewed, including adversarial tests against evidence tampering.
- STATION AGENTComplete in the labDiscovery, read-only probes, crash-safe journal, simulated lab runsRuns in an isolated lab mode whose keys are never trusted in production.
- DATAPURIXOSComplete in the labSigned, read-only boot image for USB with the station operator screenBoots on emulated x86-64 and arm64 machines. Operators have no shell. Real laptops are tested together with real sanitization.
- CLOUDNextControl plane, station identity, PDF certificates, verification page, operations portalEU-hosted, tenant-isolated, with protected signing keys.
- ITAD WORKFLOWPlannedCustomers, jobs, chain of custody, quarantine, release gate and dispositionAn asset is released only when every drive in it has passed.
- NETWORK BOOTPlannedPXE boot, offline hardening and failure-injection testsPower and network loss tested at every step of a run.
- REAL SANITIZATIONPlannedPrivileged helper and NVMe / ATA sanitize on dedicated lab drivesOnly on labelled test media, never on customer devices.
- PILOTPlannedA controlled pilot on approved hardwareAfter forensic validation and an external security review.
For the people who need to know how it works.
Why not a 3-pass or 7-pass overwrite?
On SSDs, the host can't reach every flash cell. Spare and overprovisioned areas sit behind the controller, so writing over the visible drive doesn't clean them. The drive's own sanitize commands do. NIST SP 800-88 Rev.2 treats multi-pass overwrite requirements as obsolete. DataPurix uses the device-native mechanism and allows host overwrite only for magnetic disks, where it is effective.
What happens if the power fails in the middle of an erase?
Before a sanitize command is issued, the station writes a record to an append-only journal and flushes it to storage. After a restart it finds that record. It never re-issues the command. Instead it checks the physical identity again and reads the drive's own sanitize status. If the drive reports completion, the run continues to verification. If the status is ambiguous, the run fails into quarantine. It never turns into a pass.
How is a certificate protected against forgery?
The authoritative record is canonical JSON signed with Ed25519, and production signing keys are designed to be held in a separate key service, never in the application database. Verification re-computes the canonical form, checks the hash and the signature, and checks that the decoded record re-canonicalises to exactly what was signed, which closes subtle parser tricks. Key rotation keeps old records verifiable, and revoking a key invalidates everything it signed.
Can I verify a record without trusting DataPurix's systems?
Yes. Given the evidence file and the public key ring, dpx-verify checks the signature and the record's completeness entirely offline. Its exit codes are stable for scripting: 0 means valid and certificate-eligible, 3 means validly signed but not eligible, 1 means invalid, and 2 means a usage or file error.
What personal data does DataPurix process?
Only what sanitization accountability needs: company and job references, device and drive identifiers, technical results and operator IDs. The station never reads files, file names or user accounts on the drives it processes, and certificates never show the previous user's name. Retention periods come from approved policy and are not hard-coded. What this website itself processes is described in the privacy notice.
Which drives are supported?
A drive is processed automatically only if its exact model and firmware are in the Approved Device & Firmware Registry and the drive reports the required sanitize capability. Anything else goes to quarantine for engineering review. Until coverage is broad enough, an established commercial tool remains available as a fallback for unsupported hardware.
Is DataPurix "NIST certified" or "GDPR certified"?
No. Those claims are made about products all the time, but neither NIST nor GDPR certifies erasure software that way. DataPurix is designed to support a sanitization programme aligned with NIST SP 800-88 Rev.2 and applicable IEEE 2883 methods, operated under GDPR security and accountability controls. We'll say "certified" only for independent assurance we have actually obtained, for the exact version and scope it covers.
Go beyond erase.
Transform secure data sanitization into a complete, auditable IT asset disposition workflow.
Or write to demo@datapurix.com