Data Sanitization & Wipe Certificate¶

Every device entering the Boot Up 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 Boot Up 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, Boot Up 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 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 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 Boot Up
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. NIST 800-88 Rev. 2 defers technical detail to this standard.
ISO/IEC 27040	2024 (rev)	International equivalent. Useful 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; Boot Up 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 Boot Up sanitization program¶

Per NIST SP 800-88 Rev. 2's structural requirements:

Policy¶

Every device that enters Boot Up and contains storage media is sanitized before award to a graduate (operational reuse), use as a parts donor (harvest before storage media is touched), or 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)¶

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 Boot Up 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 supported, a verification pass reads back and confirms zero/random pattern; for Cryptographic Erase, 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 spreadsheet (Phase 0–3) keyed to the Boot Up device ID, archived as a signed PDF (program signing key, kept offline) and as a JSON record for machine-readable audit, and retained for 7 years minimum (covers the longest applicable donor compliance retention requirement we are aware of as of 2026).

Building the bootable USB media¶

Boot Up uses two kinds of bootable USB stick, both built from the same free ShredOS image:

Shop sanitization stick — used by trained operators at the makerspace for the full method set below.
Donor wipe stick — an optional, single-purpose copy handed or mailed to donors who want to erase a machine before donating (see Donate a Laptop). A donor wipe is a courtesy only; Boot Up still performs a verified, certified wipe at intake.

Build steps¶

Download the latest ShredOS x86_64 release ISO from the official releases page.
Verify the checksum (SHA-256) published on the release before writing — never flash an unverified image (the wipe tool itself must be trusted).
Write it to a USB stick (8 GB+), with whichever tool is handy:
- Ventoy (recommended for shop sticks) — install Ventoy once, then simply copy the ShredOS ISO onto the stick. Multiple ISOs can live on one Ventoy stick and boot from a menu — handy for adding SystemRescue as a fallback Linux environment for manual hdparm / nvme-cli / sedutil-cli edge cases.
- balenaEtcher or Raspberry Pi Imager — simplest cross-platform single-ISO writers (good for donor sticks).
- dd (Linux/macOS) — sudo dd if=shredos.iso of=/dev/diskN bs=4M status=progress (triple-check the target disk).
Label and date each stick; record the ShredOS version on it.
Re-flash when ShredOS publishes an update, and re-verify the checksum.

Booting from the stick¶

Insert the stick, power on, and open the one-time boot menu — commonly F12, Esc, F2, or F10 (varies by manufacturer; often flashed briefly at power-on). Choose the USB device. If no USB option appears, enter firmware setup and temporarily disable Secure Boot and enable USB/legacy boot.

Operators: always boot from a known-clean ShredOS stick (re-flashed from a verified image) so the wipe tooling can't be tampered with. The drive-type-specific method that runs once you've booted is below.

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.

# inside ShredOS shell or via menu
nwipe --method=zero --verify=all --rounds=1 /dev/sdX

Method 2 — SATA SSD¶

Tool: hdparm (built into ShredOS). Operation: issue the drive's native ATA Secure Erase command — the firmware erases internal NAND, including over-provisioned cells 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 boot-up /dev/sdX
hdparm --user-master u --security-erase boot-up /dev/sdX

Caveat: some drives implement the command poorly. For drives that report TCG Opal, prefer Method 4 (cryptographic erase) — 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 — the 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 supported — 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 Boot Up 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
Boot Up 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 Boot Up 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)¶

┌─────────────────────────────────────────────────────────────┐
│  Boot Up — Data Sanitization Certificate                       │
│  https://bignerdidea.org/projects/boot-up                       │
├─────────────────────────────────────────────────────────────┤
│  Device ID            BU-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 the bad-block region is small and the 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: 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, Method 5.

What we explicitly do not do¶

Multi-pass overwrite on SSDs. SSD wear leveling means overwrite passes never reach all NAND cells. A 7-pass DoD wipe on an SSD is theater. Use Secure Erase or Cryptographic Erase.
Quick format or mkfs. Not sanitization. The data is recoverable.
dd to /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 the validation warning at the top).
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 Boot Up'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 a disciplined certificate process is technically equivalent for the categories Boot Up 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, and edge cases.
Pass a practical check on a deliberately-broken drive (the supervisor swaps in a problem case to verify correct handling).

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 Boot Up 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 certificate generator is needed
Whether 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