Data Sanitization & Wipe Certificate¶
Every device entering the Second Boot pipeline that contains or might contain data is sanitized before reuse, parts harvest, or recycling. Every sanitized device receives a wipe certificate logged against its unique Second Boot device ID. This document specifies the program.
Validation status
[HYPOTHESIS] This procedure is designed to align with NIST SP 800-88 Rev. 2 (finalized September 26, 2025) and to use IEEE 2883-2022 for technical sanitization specifications. Alignment is claimed only after the program documentation has been reviewed by a qualified information-security professional. Until that review is complete and recorded, Second Boot describes its procedure as "secure overwrite or cryptographic erase with per-device wipe certificate" — not as "NIST 800-88 r2 compliant." This is a [HYPOTHESIS] → [EXPERT REVIEWED] gap that must be closed before Phase 1 corporate donor onboarding.
Why this matters¶
A donor handing over a corporate laptop is trusting that the data on it is destroyed before the device leaves their chain of custody. Overclaiming on data destruction is one of the few failure modes that could end the program: a single donor incident where their data resurfaces would burn corporate trust in the pipeline indefinitely. This procedure is the program's load-bearing safety system, not paperwork.
The wipe certificate is also the program's strongest donor-acquisition asset. ITAD (IT Asset Disposition) is a real budget line at any organization that retires hardware. A Second Boot program that produces certificates of the same form and rigor a paid ITAD provider would — at no cost — is operationally meaningful to a corporate donor's compliance team.
2026 standards landscape¶
| Standard | Year | Role for Second Boot |
|---|---|---|
| NIST SP 800-88 Rev. 2 | 2025 (final) | Primary alignment target. Org-level program framework: policy, roles, verification, documentation. Withdrew Rev. 1. |
| IEEE 2883-2022 | 2022 | Technical specification for sanitization techniques per media type. Rev. 2 of NIST 800-88 defers technical detail to this standard. |
| ISO/IEC 27040 | 2024 (rev) | International equivalent. Useful if working with non-US donors. |
| ~~DoD 5220.22-M~~ | retired | The famous "DoD 7-pass wipe" — deprecated. SSD wear-leveling makes multi-pass overwrite a placebo on modern drives. Do not claim DoD compliance. |
| ~~NIST SP 800-88 Rev. 1~~ | 2014, withdrawn | Still cited by many donor compliance docs. Note in donor conversations that Rev. 2 supersedes; Second Boot aligns to Rev. 2. |
The key Rev. 2 shift: the standard moved from prescribing techniques to requiring an organizational sanitization program with policies, roles, verification, and records. Using the right tool is no longer enough — you must have a documented program around it.
The Second Boot sanitization program¶
Per NIST SP 800-88 Rev. 2's structural requirements:
Policy¶
Every device that enters Second Boot and contains storage media is sanitized before:
- Award to a program graduate (operational reuse)
- Use as a parts donor (harvest before storage media is touched)
- Responsible recycling (sanitization before chain-of-custody transfer)
There is no exception path. A device is sanitized or it does not leave the makerspace.
Roles¶
| Role | Responsibility |
|---|---|
| Sanitization Operator | Performs the wipe and signs the certificate. Trained per the operator-training section below. |
| Sanitization Verifier | Independent confirmation for high-stakes donor lots (hospital, bank, law firm). Different person than the operator. Not required for general donations. |
| Program Director | Owns the policy, reviews certificates monthly, approves exceptions. |
| Donor liaison | Issues the per-device certificate to the donor on request. |
Categories (NIST 800-88 Rev. 2 classification)¶
Each device's procedure is classified by sanitization category:
- Clear — logical sanitization. Resists keyboard-attack and basic file-recovery. Adequate for low-confidentiality donations.
- Purge — physical or logical sanitization that resists laboratory-grade recovery. The default Second Boot category for any donation from a corporate, hospital, financial, legal, or government donor.
- Destroy — physical destruction. Used only when a device cannot be sanitized to Purge (failed drive, no firmware support) but the data classification requires it.
Every certificate states the category achieved.
Verification¶
Every sanitized device is verified before the certificate is signed:
- Tool exit status reports success
- Where the tool supports it, a verification pass reads back and confirms zero/random pattern
- For Cryptographic Erase: the key destruction is confirmed via the drive's reporting (TCG status, sedutil-cli output)
- A 2% sample of every operator's monthly output is independently spot-checked by the Sanitization Verifier role
Records¶
Each certificate is:
- Stored in the inventory database (Phase 4) or the inventory spreadsheet (Phase 0–3) keyed to the Second Boot device ID
- Archived as a signed PDF (program signing key, kept offline)
- Archived as a JSON record for machine-readable audit
- Retained for 7 years minimum (covers the longest applicable donor compliance retention requirement we are aware of as of 2026)
Drive classification — the first decision¶
Sanitization method depends on the storage media. The operator's first job is to identify which type each drive is, before picking a method:
flowchart TD
A[Drive in hand] --> B{Type?}
B -->|Spinning HDD| C[Method 1: nwipe single-pass overwrite + verify]
B -->|SATA SSD| D[Method 2: hdparm ATA Secure Erase]
B -->|NVMe SSD| E[Method 3: nvme-cli sanitize / format with secure-erase]
B -->|Self-encrypting / TCG Opal| F[Method 4: sedutil PSID revert — cryptographic erase]
B -->|Failed / unreadable| G[Method 5: physical destruction]Identification reference:
| Indicator | Likely drive type |
|---|---|
| 2.5" or 3.5", makes noise on spin-up | HDD |
| 2.5" form factor, silent, SATA cable | SATA SSD |
| Gum-stick M.2 module, no SATA cable | NVMe SSD |
Drive reports TCG Opal in hdparm -I output |
Self-encrypting drive |
| eMMC chip soldered to board (cheap Chromebooks, some convertibles) | Treat as NVMe SSD or Destroy if no firmware support |
Methods¶
Method 1 — Spinning HDD¶
Tool: nwipe via ShredOS bootable USB
Pattern: Single-pass overwrite with verification, per NIST 800-88 Rev. 2 guidance (multi-pass on modern HDDs is unnecessary)
Category: Purge
Typical time: 1.5–4 hours per drive depending on capacity
Method 2 — SATA SSD¶
Tool: hdparm (built into ShredOS)
Operation: Issue the drive's native ATA Secure Erase command — the drive's firmware erases internal NAND, including over-provisioned cells that overwrite tools cannot reach.
Category: Purge
Typical time: Seconds to minutes (the drive does it internally)
# verify drive supports it and is not frozen
hdparm -I /dev/sdX | grep -i 'erase'
# set temp password and execute
hdparm --user-master u --security-set-pass second-boot /dev/sdX
hdparm --user-master u --security-erase second-boot /dev/sdX
Caveat: some drives implement the command poorly. For drives that report TCG Opal, prefer Method 4 (cryptographic erase) — it is faster and more thorough.
Method 3 — NVMe SSD¶
Tool: nvme-cli (built into ShredOS)
Operation: Native NVMe sanitize or format-with-secure-erase command
Category: Purge
Typical time: Seconds
# inspect drive
nvme id-ctrl /dev/nvmeXn1 | grep -E 'fna|sanitize'
# preferred: sanitize (newer drives)
nvme sanitize /dev/nvmeXn1 --sanact=2 # block erase
# fallback: format with secure-erase setting
nvme format /dev/nvmeXn1 --ses=1 # user data erase
Method 4 — Self-encrypting drive (TCG Opal)¶
Tool: sedutil-cli (bundled in ShredOS)
Operation: PSID revert — destroys the drive's internal encryption key, instantly rendering all stored ciphertext irrecoverable. This is cryptographic erase per NIST 800-88 Rev. 2 / IEEE 2883.
Category: Purge
Typical time: Seconds. Fastest method available.
# verify Opal support
sedutil-cli --scan
# PSID is printed on the drive label
sedutil-cli --PSIDrevert <PSID-from-label> /dev/nvmeXn1
This method is preferred over Methods 2 and 3 when the drive supports it — faster, more thorough, and the verification (key destruction) is unambiguous.
Method 5 — Physical destruction¶
When: Drive cannot be sanitized to Purge — failed firmware, fully unresponsive, or a donor classification requires it. Operation: Drilling through platters (HDD) or shredding the NAND chips (SSD) at the makerspace, witnessed and photo-documented. Category: Destroy Note: Destroyed drives are recycled responsibly. The device chassis can still be parts-harvested.
Per-device workflow¶
flowchart TD
A[Device enters intake] --> B[Log device ID + donor reference]
B --> C[Power on, identify drives present]
C --> D[Drive classification per type]
D --> E[Boot ShredOS USB]
E --> F[Run drive-type-specific method]
F --> G{Tool reports success?}
G -->|Yes| H[Verification step]
G -->|No| I[Retry once with fresh tool / Method 5 if retry fails]
H --> J[Generate certificate PDF + JSON]
J --> K[Operator signs certificate]
K --> L[Archive certificate; tag device with wipe-complete flag]
L --> M[Device proceeds to OS install]What the operator does, step by step¶
- Receive the device from triage with its assigned Second Boot device ID and donor reference (if known).
- Identify drives. Open the device if needed. Note SATA, NVMe, eMMC, and whether any are removed before refurb.
- Classify each drive per the table above.
- Boot ShredOS USB. Confirm the drive(s) are detected.
- Run the drive-type-specific method. Do not deviate without supervisor approval.
- Wait for completion. Do not interrupt. A killed wipe is worse than no wipe — it leaves the drive in an undocumented state.
- Read the tool report. Confirm success category. Save the report to USB or directly into the certificate generator.
- Generate the certificate (next section).
- Sign and archive. Operator signature, date, certificate to PDF + JSON, log to inventory.
The wipe certificate¶
Every certificate contains the following fields. This list is the program's [HYPOTHESIS] for certificate completeness as of Phase 0; expect it to evolve after first donor onboarding feedback.
Required fields¶
| Field | Notes |
|---|---|
| Second Boot device ID | Unique program-assigned identifier |
| Donor reference | Donor org name + their internal asset tag if provided (optional, only with donor permission) |
| Date & time of sanitization | ISO-8601, UTC |
| Operator | Name and Second Boot operator ID |
| Verifier (if applicable) | Name and ID — for high-stakes donor lots |
| Device manufacturer + model | |
| Device serial number | The chassis serial, not just the drive |
| Drive(s) present | For each drive: type (HDD/SSD/NVMe/SED), manufacturer, model, serial, capacity |
| Sanitization method | Per drive: Method 1–5 from above |
| Tool & version | e.g. "nwipe 0.37 / ShredOS 2026.05.01" |
| NIST 800-88 r2 category | Clear / Purge / Destroy — per drive |
| IEEE 2883 reference | The specific 2883 technique mapped to the method, if alignment is being claimed |
| Tool exit status | Success / failure / partial — per drive |
| Verification result | What was checked and result — per drive |
| HPA/DCO handling | Whether Host Protected Area / Device Configuration Overlay was detected and removed before wipe |
| Edge cases | Any anomalies (e.g. "1 of 256GB drive bad blocks unreadable; physically destroyed per Method 5") |
| Signature | Operator's digital signature (program signing key) |
| Document hash | SHA-256 of the certificate body for integrity |
Sample certificate (PDF first page)¶
┌─────────────────────────────────────────────────────────────┐
│ Second Boot — Data Sanitization Certificate │
│ https://bignerdidea.org/programs/second-boot │
├─────────────────────────────────────────────────────────────┤
│ Device ID RB-2026-00042 │
│ Donor Acme Corp IT (asset #LT-1387) │
│ Sanitization date 2026-05-18T14:22:00Z │
│ Operator K. Sample (op-007) │
│ │
│ Device │
│ Manufacturer Dell │
│ Model Latitude 5420 │
│ Serial ABC123XYZ │
│ │
│ Drives present 1 │
│ │
│ Drive 1 │
│ Type NVMe SSD (TCG Opal capable) │
│ Mfr / Model Samsung PM981 256GB │
│ Serial S3ABCD0R000123 │
│ Capacity 256 GB │
│ Method 4 — PSID revert (cryptographic erase) │
│ Tool sedutil-cli 1.20.1 │
│ NIST 800-88 r2 Purge │
│ IEEE 2883 Cryptographic Erase │
│ Verification Key destruction confirmed via TCG │
│ status; post-revert read returned │
│ random data (sample of 1 GB) │
│ Exit status SUCCESS │
│ │
│ HPA/DCO handled n/a (NVMe) │
│ Edge cases none │
│ │
│ ───────────────────────────────────────── │
│ Operator signature [digital signature block] │
│ Document SHA-256 a3f7…b2c1 │
└─────────────────────────────────────────────────────────────┘
Where the certificate goes¶
- Inventory database (Phase 4) or inventory spreadsheet (Phase 0–3) — primary record, queryable
- Archived PDF — signed, retained 7 years
- Archived JSON — machine-readable, retained 7 years
- Donor copy — issued on request via donor liaison
Edge cases worth documenting¶
| Case | Handling |
|---|---|
| HPA / DCO present | nwipe and ShredOS support HPA/DCO removal before wipe — log on certificate. If removal fails, escalate to Method 5. |
| Frozen security state (hdparm reports "frozen") | Power-cycle the drive with the system on (sleep/wake), retry. If still frozen, USB-adapter the drive into another machine. |
| Bad blocks during wipe | Tool reports partial success. If bad-block region is small and drive is parts-bound, log and proceed. If award-bound, retire the drive and replace. |
| Drive does not support Secure Erase | Fall back to multi-pass overwrite (Method 1 with --method=random --rounds=2). Log the fallback on the certificate. |
| Encrypted drive, unknown key | TCG Opal: PSID revert (Method 4). Bitlocker without TPM: drive contents are already cryptographically inaccessible — record this, proceed with Method 2/3/4 per drive type. |
| eMMC soldered storage on a Chromebook-class device | Use mmc tool sanitize commands where supported; if not supported, Method 5. |
What we explicitly do not do¶
- Multi-pass overwrite on SSDs. SSD wear leveling means overwrite passes never reach all NAND cells. Tools like 7-pass DoD wipe on an SSD are theater. Use Secure Erase or Cryptographic Erase.
- Quick format or
mkfs. Not sanitization. The data is recoverable. ddto /dev/zero as the sole method. Has its uses (sparse drives, post-wipe verification reads) but is not the primary tool for any drive type.- Claim "NIST 800-88 r2 compliant" in donor materials before the program documentation has been reviewed by a qualified information-security professional. (See validation warning at the top of this page.)
- Wipe a drive we did not boot from a clean ShredOS USB. Always boot from a known-clean medium so the wipe tool itself isn't compromised.
Tool stack¶
All open-source. All bundled in ShredOS.
| Tool | Purpose | License |
|---|---|---|
| ShredOS | Live USB OS dedicated to sanitization; bundles everything below | GPL |
| nwipe | HDD overwrite + verify; PDF certificate generation built in (Method 1) | GPL |
| hdparm | ATA Secure Erase for SATA SSDs (Method 2) | GPL |
| nvme-cli | NVMe sanitize / secure-erase format (Method 3) | GPL |
| sedutil-cli | TCG Opal PSID revert / cryptographic erase (Method 4) | GPL |
| smartmontools | Pre-wipe and post-wipe SMART reads (informational) | GPL |
Why open-source, not Blancco or WhiteCanyon¶
[HYPOTHESIS] At Second Boot's projected volume (100 devices/year early; 500/year aspirational), the per-license cost of commercial sanitization software exceeds the budget headroom of the entire program. ShredOS + nwipe with disciplined certificate process is technically equivalent for the categories Second Boot operates in (Purge), produces auditable open-source-tool records, and aligns with the program's open-source-first mission.
Risk to monitor: certain enterprise donors (federal, defense-adjacent) may require certificates from a brand-name tool with audit history. If that comes up in real donor conversations, evaluate a hybrid approach — Blancco for that subset, ShredOS for the bulk — rather than wholesale tool change.
Operator training¶
Sanitization Operators — typically Hardware Technician Trainees — complete training before solo operation:
- Read this document end-to-end. Comprehension check with the Program Director.
- Observe a Sanitization Verifier perform 5 sanitizations across all 4 drive types.
- Perform supervised 10 sanitizations with the Verifier present.
- Pass a written check on: drive classification, method selection, certificate fields, edge cases.
- Pass a practical check on: a deliberately-broken drive (the supervisor swaps in a problem case to verify the operator handles it correctly).
After certification, operators perform sanitizations independently. Their first 3 months of certificates are audited at 10% sample rate by the Verifier; subsequent months at the 2% standard rate.
The training pathway is itself a workforce-development milestone — a Second Boot Sanitization Operator certification is a real, transferable skill for the IT operations job market. This is a [HYPOTHESIS] to validate with workforce outcome tracking.
Known unknowns¶
In keeping with the Epistemic Honesty directive:
- Whether the certificate format above satisfies actual corporate donor compliance teams — only validatable in real donor conversations
- Whether 7-year retention is the right window — the longest applicable requirement we know of in 2026, but donor compliance regimes vary
- Whether ShredOS's built-in PDF certificate is sufficient as the authoritative artifact, or whether a custom Second Boot certificate generator is needed
- Whether the cryptographic signing of certificates is necessary at Phase 0–2 scale, or whether it can be deferred to Phase 4 when the inventory software lands
- Operationally: average wipe time per device across the real donor mix — will affect throughput modeling