Architecting
Zero-Trust Sanitization FrameworkTechnical Guide to Verifiable Data Destruction
Establishing verifiable digital certainty at the hardware decommissioning edge through automated, hardware-bound cryptographic primitives.
Written by the D-Secure team
Global Security Research Unit
Framework Contents
Download the
Technical Blueprint
Request the full framework document from the D-Secure team by email.
1. The Sanitization Trust Gap
"Traditional IT Asset Disposition (ITAD) relies on extrinsic trust—trusting a third party, trusting a report, or trusting a process. In a Zero-Trust world, Trust is a Vulnerability."
The core objective of Zero Trust Architecture (ZTA) is: "Never Trust, Always Verify." While organizations have applied this to network traffic and user identity, the "Sanitization Edge"—where hardware leaves production environments—remains a critical blind spot in modern security perimeters.
D-Secure's 2026 Framework defines a new paradigm: The Zero-Trust Sanitization Model. This model shifts the focus from "process-based trust" (following a manual checklist) to "evidence-based certainty" (automated, hardware-bound cryptographic proof).
Per drive
Evidence
One signed report each
SHA-256
Integrity
Signed with a 2048-bit key
Ledger
Record
Every erasure logged
The framework in depth
How verifiable sanitization fits a zero-trust architecture
Zero-trust programmes usually begin with network access and user identity, because that is where attacks are most visible. Yet the zero-trust tenets in NIST SP 800-207 apply to every resource an organisation owns, and a storage device does not stop being a resource when it is unplugged. A retired laptop drive holds the same data it held the day before. What changes is that it is now outside most of the controls that protected it.
The Zero-Trust Sanitization Framework closes that gap by asking the same questions zero trust asks everywhere else: who is acting, on which resource, with what authority, and what evidence shows the result. It is built from six controls. None of them is exotic; the value comes from applying all six to every device, every time, and from refusing to treat an asset as safe until the evidence exists.
1. Operator identity
Zero trust starts with knowing who is acting. In most disposal processes the person who wipes a drive is the least visible actor in the chain: a technician at a bench, a contractor at a remote site, sometimes a temporary worker. The framework treats that person as unauthenticated until proven otherwise.
In practice this means erasure is run only under named, individual accounts with the minimum rights needed, never under a shared login. D-Secure users and licences are managed centrally in the admin console, so access can be granted for a project and removed when it ends. Your process should also record who ran each job, so that any report can be tied back to a person and a time.
2. Device identity
The second question is which device was sanitized. An erasure record is only useful if it identifies the exact drive, not just the computer it came out of. Drives are moved between chassis, swapped under warranty and pulled from arrays, so a record that only names the host can be wrong without anyone noticing.
Drive Eraser detects the drives connected over SATA, NVMe and USB and records the drive details in the report. Matching those details against your asset inventory before the job, and again when the report comes back, closes the gap between what you think you erased and what was actually erased.
3. Signed evidence for every device
A batch certificate that covers a pallet of equipment asks the reader to trust the batch. The framework asks for one record per device. Every D-Secure erasure produces a signed report: page 1 is the certificate, page 2 onward is the detailed summary of the drive, the method and the result. Reports are produced as PDF and JSON.
Each report is hashed with SHA-256 and signed with a 2048-bit key. That is what turns the report from a statement into evidence: if anyone changes a field after the fact, the signature no longer matches and the change can be detected.
4. Verification of the result
Running an erase command is not the same as proving the data is gone. The framework requires a verification step after every erasure, and requires the result of that step to be part of the record. Drive Eraser applies NIST SP 800-88 Clear and Purge methods; Purge uses the drive's own sanitize or cryptographic erase commands where the drive supports them, and the report records the method actually used and the verification status.
Verification also applies to the record itself. Anyone who receives a report, inside or outside your organisation, can check it on the D-Secure report verification page by entering the report ID. A failed verification is not hidden: the drive stays in a not-sanitized state until it is erased again or sent for physical destruction.
5. Chain of custody
Between the moment a device is decommissioned and the moment it leaves your control, it passes through several hands and places. Each hand-off is a point where trust is assumed. The framework replaces that assumption with recorded events: the asset is flagged for retirement, the erasure runs, the signed report is attached to the asset record, and only then is the asset released for reuse, resale or recycling.
Erasing at the point of origin, on the data centre floor or at the user's desk, shortens the chain because the device carries no readable data while it is in transit. Where that is not possible, the report still marks the point after which the drive no longer holds recoverable data.
6. Ledger and retention
Individual reports prove individual erasures. A ledger proves completeness. D-Secure keeps a ledger of erasures in its backend, and reports are stored in the report repository of the admin console, so an auditor can ask for every erasure in a period rather than the handful you choose to show.
Reconciling the ledger against your retirement list is the final control. Any asset marked as retired without a matching signed report is an open finding. How long reports are kept is a policy decision for your organisation and your regulators.
Zero-trust principles, applied to disposal
Never trust, always verify
No device is treated as sanitized until a verified, signed report exists for it.
Least privilege
Erasure runs under individual accounts with only the rights the job needs.
Assume breach
Every retired device is treated as holding sensitive data until proven otherwise.
Monitor asset posture
The asset inventory reflects sanitization status, and the ledger is reconciled against it.
Collect evidence continuously
Each erasure adds a signed record, so evidence accumulates as work is done rather than at audit time.
What the framework does not replace
Software sanitization covers the NIST SP 800-88 Clear and Purge levels. Destroy is physical: shredding, disintegration or incineration, carried out with hardware. Drives that are damaged, that fail verification, or that cannot be Purged with the commands they support belong on the physical destruction path, and the framework should record that decision just as carefully as a successful erasure.
The framework is also not a substitute for policy. It tells you how to produce trustworthy evidence; your policy decides which media classes need Purge rather than Clear, who may authorise disposal, and how long records must be kept. D-Secure reports help you document sanitization for internal audits, customers and regulators, and D-Secure methods follow NIST SP 800-88. Confirm your own legal obligations with your compliance team.
Questions to ask of any erasure record
- Does it identify the specific drive, not only the host computer?
- Does it state the sanitization method actually used and the verification result?
- Can you tell who ran the erasure and when?
- Is it signed, and can someone outside your organisation check that it has not been changed?
- Does it appear in a complete log, so missing devices can be found?
If the answer to any of these is no, that is where trust is still being assumed rather than verified.