Documentation

1. Quick start

The full journey — account → licence → boot → report → certificate — is covered in sections 3–10 below.

1. Boot the tScrub appliance image from USB or PXE and run it.
2. Enter a 5-digit Chain of Custody ID (COCID) when prompted.
3. tScrub connects to the network, captures the machine's hardware profile and MDM/BIOS lock status, submits its diagnostics to the dashboard, and starts its online heartbeat — then shows the triage screen.
4. Press Shift+T to erase: pick the drives, watch live progress; each drive ends with a status (COMPLETED, FROZEN, BLOCKED, or FAILED).
5. Collect the report files, which are written to the report directory.

2. System requirements

• x86-64 machine with USB or PXE boot
• 1 GB RAM (erasure runs in parallel)
• Dependencies are bundled in the appliance image: nvme-cli, hdparm, software overwrite (SCSI), sedutil-cli (SED/OPAL), smartctl (SMART), curl (dashboard upload), lftp (FTP/SFTP), openssl (signing)
• Directly attached NVMe, SATA, or SCSI drives, plus USB-attached drives (software overwrite only — the report records Bus=USB and no firmware-erase or IEEE 2883 claim is made over a USB bridge)

3. Download the appliance

tScrub ships ready to boot — there is nothing to compile. Download the appliance from the Download page (no account needed), then create an account, verify your email, and issue your licence from the Licences page:

• The appliance ISO — a hybrid ISO that boots on BIOS and UEFI, with sedutil-cli, curl, lftp and the report tooling built in.
• A .lic file — every appliance needs one (the free tier is included).

tScrub ships only inside the appliance image (at /usr/bin/tscrub.sh) — there is no standalone download. Security teams can extract it from the ISO to audit it line by line. That auditability covers the appliance. The hosted dashboard — how an origin is resolved, how a certificate is rendered, how accounts and keys are handled — is not published, and this page describes what the service does rather than how it is built.

4. Run a sanitisation job

There is nothing to run manually — tScrub starts automatically as the appliance boots (from USB or PXE). It asks for the 5-digit Chain of Custody ID first, because that ID identifies the whole session: the machine's diagnostics snapshot, its presence on the dashboard and any erasure report are all filed under it. A supplied tscrub_cocid= skips the prompt, and the answer is kept for the rest of that boot, so restarting the appliance does not ask again. It then lands on a triage screen while it captures the machine's hardware profile and BIOS lock status, and heartbeats online:

• Hardware triage & grading — system/board serials, SKU and asset tag, BIOS and firmware revisions, TPM and Secure Boot, CPU spec, per-DIMM memory, display panel, battery health, Wi-Fi and PCI/USB peripherals, plus a per-drive inventory (firmware, sector size, SMART, self-test). This becomes a printable ITAD diagnostics report on the dashboard (see section 14).
• MDM & BIOS lock — a Windows Autopilot (MDM) check reports Locked/Unlocked from Microsoft; it runs from the device's page in the dashboard, using the hardware hash captured with the diagnostics report. BIOS admin-password lock is detected from firmware/SMBIOS.
• LAN IP — shown on the triage screen so you can reach the machine remotely.

Press Shift+T to erase the selected drives in parallel; frozen, locked, or blocked drives are flagged rather than marked clean. With an appliance token set, the triage screen also accepts remote commands (shut down, restart, or a staged remote wipe) from the dashboard.

If discovery finds no storage — or only media that is protected as the appliance's own boot/licence volume — the appliance holds a NO STORAGE DETECTED screen instead of restarting, and says what it actually saw: a card reader with no card, a drive protected as tScrub's own media, controllers present with no disks behind them. F rescans on demand, D runs diagnostics, Q restarts the appliance. The dashboard shows such a machine as No storage, which is its own state — not Erased (nothing was) and not Failed (nothing failed), and no certificate is produced. On the triage screen F also rescans, which is the way to confirm “did it see the drive I just plugged in?”. The COCID stays on the screen, so a machine that finds nothing is still reported under its job rather than anonymously.

If the machine will not boot tScrub at all — no POST, no USB or PXE boot, a firmware password, a dead board — then no boot can be recorded, and the appliance knows nothing about it. Pull the media item, erase it on a bench machine, and declare where it came from: see section 15, A device that will not boot.

The same screen carries the software-overwrite standard: press m to cycle it (zero fill, PRNG stream, DoD 5220.22-M, DoD Short, Gutmann, HMG IS5 Enhanced) and p to cycle the rounds. The footer shows the choice and the resulting number of pattern passes, and the drive selection screen shows it again next to the selected count. It applies to the software-overwrite fallback only — a drive with a working firmware erase is never overwritten — and an overwrite is always recorded as Clear, never Purge. To fix the standard for a whole fleet, set tscrub_method= and tscrub_passes= instead (see section 13).

Before wiping, tScrub removes any hidden HPA/DCO area so the full native capacity is sanitised, and after the wipe it verifies the result by reading back sample sectors — both on by default (see section 8).

For unattended fleet runs, pre-set tscrub_cocid= to skip the prompt and add tscrub_autonuke=1 to skip the triage screen and wipe every drive automatically (see section 13).

5. Boot the appliance from USB

The appliance download is a hybrid ISO (boots on both BIOS and UEFI, ~168 MB). Always verify its SHA-256 against the .sha256 file published next to it before writing it to a stick.

Secure Boot supported: the appliance boots with UEFI Secure Boot on, via a signed shim + MOK chain. On the first boot on a machine, shim opens MokManager — choose Enroll MOK → Continue → Yes, then reboot. After that it boots normally. (You can also simply disable Secure Boot or enable CSM/Legacy boot.)

diskutil list                          # identify your stick, e.g. /dev/disk2
diskutil unmountDisk /dev/disk2
sudo dd if=<downloaded-iso> of=/dev/rdisk2 bs=4m && sync

lsblk                                   # identify the stick, e.g. /dev/sdX
sudo dd if=<downloaded-iso> of=/dev/sdX bs=4M status=progress && sync
# equivalent: sudo cp <downloaded-iso> /dev/sdX && sync

6. Boot over the network (PXE)

The appliance kernel is self-contained (its initramfs is embedded, gzip-compressed, inside bzImage), so PXE needs only the kernel file plus a standard DHCP → TFTP → iPXE chain. This is the same two-stage HTTP-boot pattern used to netboot ShredOS (see the tadvaas/pxe reference setup).

• DHCP — set next-server and boot filename: undionly.kpxe (legacy BIOS) or ipxe.efi / snp.efi (UEFI; use snp.efi if an HP or multi-NIC system picks the wrong adapter).
• TFTP (tftpd-hpa) — serves the iPXE firmware only.
• HTTP (nginx) — serves bzImage (extracted from the ISO).

#!ipxe
:tscrub
dhcp
kernel ${base-url}/tscrub/bzImage console=tty3 loglevel=3
tscrub_api_token=YOUR-64-HEX-TOKEN
boot

There is no initrd line — the initramfs is inside bzImage. Append any tScrub kernel parameters (report destination, licence) directly to the kernel line. The licence can be served over the LAN too: tscrub_license_url=http://pxe-host/tscrub/Acme-ITAD-Ltd-2027-09-12.lic.

Getting the kernel (bzImage)

bzImage is inside the appliance ISO at /boot/bzImage (shown as /BOOT/BZIMAGE in some listings). Extract it on any OS, then put it on your HTTP server.

# mount the ISO, then copy the kernel out
hdiutil attach <downloaded-iso>
cp /Volumes/TSCRUB/boot/bzImage ./bzImage
hdiutil detach /Volumes/TSCRUB

# or extract without mounting (bsdtar ships with macOS)
bsdtar -xOf <downloaded-iso> boot/bzImage > bzImage

# from the ISO, without mounting (note the ";1" Rock Ridge version suffix)
isoinfo -x /BOOT/BZIMAGE.;1 -i <downloaded-iso> > bzImage

# or mount it and copy
mkdir -p /mnt/iso && mount -o loop,ro <downloaded-iso> /mnt/iso
cp /mnt/iso/boot/bzImage /srv/pxe/tscrub/bzImage
umount /mnt/iso

Place bzImage on your HTTP server (e.g. nginx /srv/pxe/tscrub/bzImage) and point ${base-url} at it in boot.ipxe.

7. Report destinations (USB · FTP · dashboard)

Where the report lands is chosen at boot time, on the kernel command line (the same place for every boot method). You can combine them — tScrub writes locally first, then uploads.

Preconfigure with a tscrub.conf file

You don't have to edit GRUB or the kernel command line — drop a tscrub.conf on the stick (next to your .lic) and tScrub reads it at boot:

On the Licences page you can download a ready-made tscrub.conf preconfigured with your appliance upload token — just drop it on the stick.

tscrub_api_token=YOUR-64-HEX-TOKEN
tscrub_verify=sampled
tscrub_method=zero
tscrub_passes=1
tscrub_hpa=on
tscrub_cocid=12345
tscrub_license_url=http://192.168.1.10/Acme-ITAD-Ltd-2027-09-12.lic
tscrub_output=ftp:backup.example.com:incoming/tscrub:itad:s3cret
tscrub_operator=Jane Doe
tscrub_validator=John Roe
tscrub_asset_tag=IT-2041
tscrub_media_source=IT decommissioning
tscrub_media_destination=resale

Keys mirror the kernel parameters: tscrub_api_token pushes reports to your dashboard, tscrub_cocid pre-fills the COCID (no prompt), tscrub_license_url fetches the licence over the LAN, and tscrub_output points reports at a local path or an ftp: / sftp: server. The report metadata keys — tscrub_operator, tscrub_validator, tscrub_asset_tag, tscrub_media_source and tscrub_media_destination — record who performed and validated the erasure and where the media came from / is going; unlike the kernel command line, tscrub.conf values may contain spaces. tscrub_operator is optional — if you leave it out, the certificate's "Generated by" line names the account holder who generated the certificate. Editing the GRUB entry on the stick also works when the boot partition is writable (Rufus ISO mode or Ventoy), but tscrub.conf works however you wrote the stick.

Full details and examples are in section 8, The report.

8. The report

Each job produces a CSV report plus a JSON manifest; a signature sidecar is written whenever OpenSSL is available (always, on the appliance image):

tScrub_48213_20260912T103000Z.csv    # human-readable report (one row per drive)
tScrub_48213_20260912T103000Z.json   # manifest (SHA-256, public key, drive summary)
tScrub_48213_20260912T103000Z.csv.sig  # base64 Ed25519 signature (vendor key on paid, appliance key on free)

The CSV records one row per drive: identity (Model, Serial, Size, Bus, Type, Device), the outcome (Class, Certification, Method, FinalStatus), SMART before and after (SMART … PowerOnHoursPost), hidden-area state (HPA, DCO, HPAResult, DCOResult), the verification outcome (Verify, VerifySectors, VerifyResult), the verification technique (VerifyTechnique, VerifyCoveragePct), the software-overwrite provenance (OverwriteStandard, Passes, EraseEngine), the reuse formatting (Format, FormatFS, FormatScheme, FormatLabel, FormatResult), the lock handling (FreezeLock, BlockSID, FLRAttempts, PSIDRevert, LockKind, PPIRequested, PPICleared, PPIResumed), and the machine profile (System, SystemSerial, BaseboardSerial, CPU, GPU, RAM) repeated on every row.

The erasure report is only one of two reports tScrub writes. At boot, before any wipe, tScrub captures a hardware diagnostics report — the full machine profile (system and board serials, SKU/asset tag, BIOS, motherboard, TPM, Secure Boot, CPU spec, per-DIMM memory, display panel, Wi-Fi adapter, battery) plus a per-drive inventory (firmware, sector size, SMART health, self-test result, reallocated sectors). It is delivered to the same destinations as the erasure report (USB, dashboard, or LAN) and renders as a printable two-page ITAD triage PDF on the dashboard's Devices tab.

Drive final status

Every drive ends a run with one of the following statuses, shown live on the console and recorded in the report's FinalStatus column:

Post-erasure verification & hidden areas

Two safeguards close the gaps a plain firmware erase can leave:

• HPA/DCO removal (before the erase). A drive can hide a tail of sectors behind a Host Protected Area (HPA) or a Device Configuration Overlay (DCO) that an erase of only the visible capacity never touches. tScrub resets both to the drive's native capacity first, re-reads the visible capacity to confirm the reset took, and records the outcome per drive as removed, firmware-erased (the erase command already covers the area), none, or failed — a failed removal on a standard secure erase is flagged data may remain on the report and certificate. On by default; tscrub_hpa=off disables it.
• Post-erasure verification (after the erase). Before wiping, tScrub writes a unique per-run sentinel into a fixed set of eight-sector zones spread across the address space — 40 sectors in total — and flushes it; after the wipe it reads those same sectors back and confirms the sentinel is gone. sampled (default) checks those five windows, full re-reads every sector, none skips it. The result (passed / failed / unreadable) is recorded per drive. The honest claim is "N sectors re-read, sentinel not found" — never "entire drive verified".
• What kind of evidence that is. Every drive also records a VerifyTechnique, because a single word "passed" hides three different proofs. sentinel is the check above. overwrite-sample means a percentage of the whole address space was read back and found zero (VerifyCoveragePct) — only possible after a software overwrite, where the entire drive once held a known pattern; requested with --verify-coverage N and off by default. ce-exempt marks a crypto erase, where the media key was destroyed, so reading the platters back can neither confirm nor refute anything. A firmware erase leaves undefined content behind, so it always records sentinel and never a percentage.

Sanitisation standard claim (opt-in)

By default a report names the technique and the evidence and stops there. That is the honest default: it says what we did and what we saw, and leaves the reader to judge it against whichever standard they are held to.

If you need the report to name a standard, add tscrub_standard=ieee2883 at boot (or --standard ieee2883 interactively). Each drive is then tested against five gates and labelled IEEE 2883-2022 only where all five pass:

• Technique. The method must map to a real 2883 technique, and only methods that reach non-addressable locations may claim Purge. An ATA normal secure erase and an NVMe Format reach only the addressable area, so they are Clear — even though both are irreversible.
• Coverage. On the software-overwrite path, Clear needs a read-back sample of at least 5%. That figure is our house policy, not a quoted requirement — we do not own the standard and will not put a number in its mouth. A firmware erase cannot be sampled at all, so it never carries a coverage figure either way.
• Verification. The sentinel must be gone after the wipe. A crypto erase is exempt by design — the media key is destroyed, so reading the platters can neither confirm nor refute the result — and the exemption is recorded rather than assumed.
• Completion and scope. The erase must have finished, and only HDD, SATA SSD, NVMe and SAS carry the claim. A USB-attached drive is refused at this gate and records the shortfall: its erase is a software overwrite, which can never carry a Purge claim.

A drive that fails any gate keeps NIST 800-88 and records why in SanitizationShortfall (for example G2 coverage 2% < 5%) — so a refusal is visible in the CSV, not just an absence. The certificate's Standard row names the standard only when every scored drive earned it, and prints the achieved levels: IEEE 2883-2022 (Clear, Purge).

One thing this is not: tScrub is not certified to IEEE 2883, and no third party has audited it against that standard — just as no product is "NIST 800-88 certified". Certificates therefore carry the line "IEEE 2883-2022 methods described, not IEEE certified". What the claim asserts is narrower and checkable: these methods were used, and this evidence was captured for each drive.

At the end of a run tScrub writes the report files locally, then optionally uploads them. Everything is configured at boot time on the kernel command line (PXE, GRUB, or the appliance boot entry) — not baked into the image.

Where the report is written — tScrub saves to the same volume it found your .lic on (with dd/Etcher that's the TSCRUB-USB partition; with Rufus ISO mode it's the single writable partition), then falls back to a FAT/exFAT scan, then RAM. Reports are grouped under reports/<COCID>/, and the partition is synced and unmounted before reboot so nothing is lost on power-off. Override the location with tscrub_output=:

tscrub_output=/mnt/usb

Layout on the stick:

reports/
└── 11111/
    ├── tScrub_11111_20260922T161328Z.csv
    ├── tScrub_11111_20260922T161328Z.json
    └── tScrub_11111_20260922T161328Z.csv.sig

Push to the dashboard (network) — send the report straight to your tScrub account. The token comes from the Licences page of your dashboard. The appliance image ships curl and a CA-certificate bundle, so this works out of the box:

tscrub_api_token=YOUR-64-HEX-TOKEN

Upload via FTP or SFTP — upload the report files to an FTP or SFTP server. Both run over lftp, which is built into the appliance image:

tscrub_output=ftp:host:path:user:password
# e.g. tscrub_output=ftp:backup.example.com:incoming/tscrub:itad:s3cret
# SFTP (encrypted):
tscrub_output=sftp:backup.example.com:incoming/tscrub:itad:s3cret

ftp or sftp is the protocol. host is the server, path is the remote directory (relative to the user's home, no leading slash), then the username and password.

The password must not contain spaces, and credentials are visible in the boot configuration — use a dedicated upload account.

9. Verify a report

Verification is automatic — there is nothing to run. When you upload a report to the dashboard, its SHA-256 is checked and any Ed25519 signature is validated; a tampered report is flagged MISMATCH or INVALID. Certificates verify online via their QR code, which confirms the issuance record and the PDF's own hash.

A report with no signature simply records its SHA-256 checksum, so tampering is still detectable.

10. Certificate of Destruction

Turn one or more tScrub reports into a single, printable Certificate of Destruction. Upload the .csv files (and, if you have them, the matching .json and .csv.sig sidecars) on the dashboard Media page, then select the Chain of Custody ID on the Certificates page to generate a consolidated certificate.

What happens when you upload

1. Each .csv is hashed (SHA-256) and, when a manifest is present, checked against its recorded checksum.
2. Where a report is signed, the Ed25519 signature is verified against the key embedded in the manifest.
3. Media from every report with the same COCID are merged into a single certificate, sorted by wipe time.
4. A tamper-evident PDF is generated with a unique Certificate ID, a device annex (Annex A), a pre/post-wipe SMART annex (Annex B, when the report includes it), and a verification QR code. Signed (paid) certificates also carry a digital signature.

If the Chain of Custody ID was typed wrong

A mistyped COCID (12354 for 12345) either invents a job or joins an unrelated one: an offline appliance has no way to know which job an ID belongs to, so a transposed digit is only caught by the person holding the paperwork. Read it back at the prompt. It is corrected in the report itself:

• open the report — a media item's View on the Media page, or Log and then the entry's View on the Devices page — and use Correct COCID in its footer;
• that covers a machine's diagnostics report as well as its erasure reports, and the record view closes and refetches afterwards so the list never shows the old ID.

Nothing is deleted: the report keeps its data, hashes and signature, every correction is recorded against the report (who, when, from, to and why), and a correction is refused once a certificate has been issued for that job, since the certificate already cites that evidence. Issue a corrected certificate instead.

The certificate states how the data was destroyed, not just that it was. Page 1 carries a Technique line and a Media disposition line (for example "3 media sanitised in place (data destroyed; hardware reusable); 1 media physically destroyed"), the outcome banner reads DATA DESTROYED ON ALL N DEVICE(S) — or an amber "N not destroyed" when a drive failed — and Annex A opens with a Destruction Method Summary: one line per method giving its label, NIST SP 800-88 level, technique and device count. Drives that failed are never counted as destroyed.

Devices that never reach the appliance

Plenty of kit has to be destroyed without ever being wiped: phones and tablets with soldered storage, machines that will not power on or boot, sealed units, and media a wipe cannot address at all. Those items can be recorded by hand on the Devices and Media pages, so one job can carry both kinds of evidence instead of splitting the record across a certificate and a spreadsheet.

An attested item is recorded with its category or media type, make, model and serial, the reason it was destroyed rather than sanitised, the destruction method, and optionally the vendor, date, witness and the vendor's own evidence reference. The person who attested it is taken from the signed-in account, never from the form.

What such a record does and does not claim. It appears on the certificate in its own section, every line carrying the qualifier "operator-attested — not instrument-verified". It is never counted as sanitised, never mixed into the per-drive wipe evidence, and never implied to have been erased by tScrub: there is no scan data behind it, so no wipe result, no NIST level and no pre/post-wipe SMART data are attributed to it. The dashboard badges the row Attested and reports how many of the total are attestations, so a destroyed phone cannot inflate the count of machines the appliance actually saw. When an attestation rests on a vendor's certificate, record its reference so a reader can go to the source.

Media removed and erased on another machine

Storage that will not erase in its own chassis — a failing drive, a firmware erase the controller refuses, or media that was already pulled — can be erased on a bench machine. The erasure is instrument-verified wherever it ran; what the certificate must also state is where the media item came from. Open the media item’s record on the Media page and choose Reassign origin. The origin is operator-declared provenance and is labelled as such; the erasure evidence is not changed by it. The step-by-step procedure, including a device that never boots at all, is section 15.

Where the appliance itself saw the media item — in the device's boot snapshot, or in a failed erase attempt on that device — the link is derived automatically and needs no declaration. A device that had no data-bearing media at all is recorded from its boot snapshot, so it is accounted for rather than silently missing.

Annex A of the certificate gains a DEVICE ACCOUNTING block for exactly these cases: media removed and sanitised on another host, a device with no data-bearing media, or a device whose media did not complete. It also adds an Origin device column beside Machine SN — the host that ran the erase — only when the two differ. The certificate never says a device was sanitised in place when only its media were.

If the machine that ran the erase is your own bench machine, mark it as a processing host from its Ops panel on the Devices page. It carries a Bench badge and is excluded from the customer's fleet and from certificate device counts; the evidence it produced is still used.

What the QR code carries

There is exactly one QR code on a certificate, bottom-right of page 1, and it always holds a single URL — never a bare number. A camera that reads plain text just shows the operator a string; a URL opens the verifier. Which URL it is depends on when the certificate was issued, and the caption printed under the code tells you without scanning it.

The offline code is a small pipe-separated message carried in the URL fragment: a format version (2, so a future change is a clean rejection rather than a wrong verdict), the key ID (tscrub-vendor-1, so key rotation retires an old kid instead of breaking every printed certificate), the Certificate ID, the issue timestamp, and an Ed25519 signature over those three. That is roughly 189 characters, which is why it is drawn at error-correction level Q (65 modules) rather than H (73) — cheap phone cameras decode it reliably at 30 mm.

What it deliberately leaves out. No customer name, no drive serials or models, no PDF hash, no email address. A QR on a printed certificate is public forever and gets photographed by strangers, so it carries the minimum needed to prove issuance and nothing that identifies the device or its owner. The Certificate ID inside the code is also what lets the verifier offer the online lookup once it has passed, so one scan reaches both checks.

Older certificates are not second class. A certificate carrying the record link verifies exactly as it always did — it simply needs a connection to do it. And no certificate ever ships with nothing to check: if the vendor key was unavailable when the document was generated, the record link is drawn instead, which is the only way a certificate issued today can still say Verify online.

Verifying a certificate online

Each certificate carries a unique Certificate ID (COD-…). The QR code contains a link to the verifier, so scanning it with an ordinary phone camera opens that page with the certificate's signed code already filled in. The same record is reachable directly at tscrub.com/verify?cert=COD-…. Either way it confirms:

• the Certificate ID, Chain of Custody ID, and sanitisation window;
• device, method, and run counts;
• the integrity and signature status recorded at issuance;
• a SHA-256 hash of the PDF itself, so the document can be checked for alteration since issue.

Verifying a certificate with no network

The same QR opens tscrub.com/verify-offline, which checks the signature on the device using the public key built into the page. Load it once and it keeps working with the network switched off, which is what an auditor with a segregated laptop or a phone in aeroplane mode needs. The code sits after the # in the link, so it is never sent to us: the check happens locally.

• What a pass proves: the code was issued by tScrub for that Certificate ID at that time, and has not been altered since. The signing key's fingerprint is shown on the page, and is published at /.well-known/tscrub-cert-key.json.
• What it does not prove: that the drive was erased, or that the details printed on the page are the ones the certificate records. A verifier page holds no database. Send the auditor the online link as well if they need the recorded content, or let them compare the printed Certificate ID with the one the page reports.
• Camera or keyboard: where the browser supports it, the page can scan the code directly. A copy of the page saved to a file cannot use the camera (browsers only allow that over https), so it falls back to the paste box.

Machine-readable certificate (JSON-LD)

The same certificate is available as a signed JSON-LD document — add &format=jsonld to the verification URL. It carries the Certificate ID, COCID, every drive and report, the PDF's SHA-256, and the same destruction evidence as the PDF (per-drive sanitizationTechnique and nistLevel, plus the chain-level mediaDisposition), signed with a detached Ed25519 signature (public key published at /.well-known/tscrub-cert-key.json) plus an RFC 3161 timestamp. Any script can verify it offline without calling tScrub.

11. Licensing

Free licences are self-serve — sign in at tscrub.com and issue one from the Licences page of your dashboard. Paid licences (pay-as-you-go, Team, Enterprise) are issued by the tScrub team, so contact us. You'll receive a .lic JSON file. Free licences carry no report key, so the appliance self-signs reports with its own generated key (tamper-evident, not attributable); paid licences embed a vendor-signed report key, so the appliance signs reports with that key, the licence verifies against the tScrub vendor key, and uploaded reports are matched back to that key so they are attributable.

Attaching a licence

The appliance looks for a licence on the boot USB first — drop your .lic file at the root of the stick (any *.lic name) and it is picked up automatically. Failing that it falls back to a .lic file in /etc/tscrub/, or you can point at it explicitly with tscrub_license=:

tscrub_license=/etc/tscrub/Acme-ITAD-Ltd-2027-09-12.lic

The licence can also be fetched over the local network instead of a filesystem path, using the URL form of the kernel parameter:

tscrub_license_url=http://192.168.1.10/Acme-ITAD-Ltd-2027-09-12.lic

Fetching uses curl, which is built into the appliance image. Because a .lic contains the private report-signing key, host it on an authenticated or isolated LAN endpoint — not a public URL.

Every appliance requires a valid licence — even the free tier. Without one, tScrub exits with an error.

12. Supported media

13. Kernel parameters & boot configuration

Everything tScrub needs at boot is set on the kernel command line; these parameters are read from /proc/cmdline at startup.

Defaults: the licence is read from the boot USB (a *.lic file at the stick's root), then /etc/tscrub/, unless tscrub_license= / tscrub_license_url= is set; the report is written to a volume identifiable as tScrub's own — the one holding the licence, the one carrying boot/version.txt, or one labelled TSCRUB/TSCRUB-USB — then RAM, unless tscrub_output= overrides it. An unrelated FAT stick is never claimed as the report destination, because a mounted volume cannot be selected for erasure.

Where to set them

The kernel command line is supplied by the bootloader, so how you set it depends on how you boot:

• USB (persistent) — the boot partition is a writable FAT32 volume, so after writing the image you can edit /boot/grub/grub.cfg (BIOS) or /EFI/BOOT/grub.cfg (UEFI) on the stick, appending your parameters to the linux line.
• USB (one-off) — edit the entry at boot instead: highlight it, press e, append your parameters after console=tty3 loglevel=3, then press Ctrl+X. This affects that boot only.
• PXE (best for fleets) — put the parameters on the kernel line of your boot.ipxe (see Boot over the network).

Diagnostics on the console

For diagnostics you can invoke tScrub directly on the appliance (for example tscrub --dry-run); these flags mirror the kernel parameters above and are not needed for a normal run.

14. Dashboard: devices, remote commands & organisations

With an appliance token (tscrub_api_token=) set, every boot reports to your tScrub dashboard. Beyond storing reports and generating certificates, the dashboard gives you a live view of the machines you have booted and lets you drive them remotely while they are online.

Devices & the ITAD diagnostics report

At boot, before any wipe, tScrub captures a full hardware profile — system and board serials, SKU/asset tag, BIOS and firmware revisions, TPM and Secure Boot, CPU spec, per-DIMM memory, display panel, battery health, Wi-Fi adapter, PCI/USB peripherals and full SMBIOS detail — plus a per-drive inventory (firmware, sector size, SMART health, self-test result, reallocated sectors, HPA/DCO and SED/OPAL lock state). It lands on the dashboard's Devices tab, where each machine's snapshot renders as a printable two-page ITAD triage and grading PDF (download it from the device's detail view).

The Latest event column carries the newest thing recorded for a machine — its last report submission or its last appliance heartbeat — and sorts the whole fleet by recency, so the unit you have just booted is the first row rather than something you find by opening logs. A device's full event list stays in its Log.

Remote commands

While the appliance sits on the triage screen it polls the dashboard, so you can send commands without touching the keyboard:

• Shut down / restart — power the machine off or reboot it from the device's detail view.
• Remote erase — stage a wipe from the dashboard; the appliance shows a short grace countdown on the triage screen, then wipes the selected drives.
• Clear a BIOS password — see Remote BIOS unlock below.

All commands go through one queue, and every one is recorded. Each device has a Log that lists its events in one place — report submissions, remote commands and their outcomes, Autopilot checks, registrations, and issued certificates — and a remote command's outcome is stamped with the Chain of Custody ID of the session that ran it, so a remote erase or BIOS clear is attributable next to the report it belongs to.

Remote BIOS unlock

On supported Dell, Lenovo and HP business machines, the device's detail view has a BIOS-unlock action that queues a clear command to the online appliance — including HP models whose Setup Password can be cleared from Linux through the firmware's own interface. When a clear does not succeed the dashboard says why: a wrong password (retry with the correct one), a password rejected by the firmware's policy, or a firmware that exposes no reset path from Linux (where retrying can never help). A retry is only offered where a different password could change the outcome, and tScrub never retries a password automatically — repeated wrong attempts can trigger a BIOS lockout.

Organisations & seats

Team and Enterprise accounts can create an organisation on the dashboard and invite colleagues as members — one licence covers several operators who share the same devices, reports, certificates and remote-command queues. Seats scale with the tier: 2 on Free, 10 on Pay-as-you-go, 50 on Team, 100 on Enterprise.

15. A device that will not boot

Some machines cannot run tScrub at all: no POST, no USB or PXE boot, a firmware password that blocks booting, a dead board. That is a different situation from a wipe that failed, and it is not the end of the job. The data-bearing media item can be pulled and erased on a bench machine, and the certificate can still name both devices truthfully — the device the media item came from, and the host that actually sanitised it.

What changes is the class of evidence. Everything stated about the erase is instrument-verified, because the appliance saw it. Everything stated about where the media item came from is operator-declared, because the appliance never saw the two together. The record keeps those apart, and so should the workflow.

The workflow

1. Read the identity off the chassis before anything is removed. The device is tracked by its OEM system serial — the one on the chassis label or in firmware — not by the asset tag and not by a Windows licence sticker. Note the model and the customer's asset tag too, and photograph the label. The certificate names the device by the serial you enter, so read it twice.
2. Use one COCID for the whole job. The bench erase runs under the same Chain of Custody ID as the device intake. The COCID is cached for the whole boot, so one bench boot belongs to one customer's job; do not batch two customers under one ID.
3. Mark the bench machine as a processing host, once. Devices → the bench machine's row → Ops → Mark as our bench machine. It carries a Bench badge, is excluded from the customer's fleet and from certificate device counts, and the evidence it produces is still used. Bench hosts are shown by default; Filters → Processing host → Hide bench hosts keeps them out of the customer rows, and the choice is remembered.
4. Label the media item, then pull it. Write the device serial and the COCID on the drive before it leaves the chassis — six drives on a bench look identical afterwards.
5. Erase it on the bench under the same COCID. A USB caddy works, but a USB bridge is a software overwrite only: the report records Bus=USB and makes no firmware-erase or IEEE 2883 claim.
6. Link the erase to the device. On the Media page, open the media item's row → Reports → View → Reassign origin. Enter the device serial, the Chain of Custody, a reason (media_removed by default) and an optional note, then Save.
   • The device has to be in Devices first. It usually is not, because it never booted: the save is refused and the form offers Record device <serial> and link?. Press Record device and link to add it to Devices as a declared device and record the origin in one step. Nothing is written until that button is pressed, so a mistyped serial cannot become a certificate line.
   • Put the model, the customer's asset tag and did not boot in the note. That note is what explains, to whoever reads the certificate later, why the device has no diagnostics behind it.
7. Read the provenance back. The row states it in one line: Origin device: <serial> (declared by operator). Erased on <bench serial>. A declared origin is never presented as instrument-verified. Reassign origin again replaces the earlier declaration, so a typo is corrected the same way; Remove this link deletes the declaration and leaves both the erasure evidence and the device row untouched. The media item's Reports list states this for every submission, in its status column exactly as the row does: a report is tagged bench while its job has no declared origin, and origin once one has been assigned, so a blocked attempt on the device and the bench erase that followed are told apart at a glance.
8. Correct the register if you need to. A declared device carries a Declared badge, and its card offers Edit details (model and note) and Remove from Devices. The serial is the key: it is not editable, because a different serial is a different device.
9. Review the job before issuing. The Certificates page flags N devices to review where a device is not the ordinary in-place case — this workflow is what that flag is for.
10. Generate the certificate. Page 1 counts 1 device with media removed. Annex A carries a DEVICE ACCOUNTING block naming the device, its media items, the host that sanitised each one and how the origin was established, and an Origin device column beside Machine SN only where the two differ. Neither the PDF nor its signed JSON-LD twin ever says a device was sanitised in place when only its media were.

If the machine boots but the drive will not erase

Do not pull the drive first. Let the run finish: BLOCKED, FROZEN, FAILED and STALLED are terminal states, so a report is written with both the device and the drive serial on the row, and the origin is derived automatically because the appliance saw them together. Pull the drive afterwards and erase it on the bench under the same COCID; nothing needs declaring. The boot snapshot and the failed attempt are already on file, so the job accounts for the device either way.

What this does not cover

A unit scrapped with its data-bearing media still inside has no erasure to point at, so this workflow does not apply — it attributes a real erase to the right device, it does not imply that one happened. Record that unit as an operator attestation instead, from Add on the Devices or Media page (see section 10, Devices that never reach the appliance). The certificate shows it in its own section, every line qualified operator-attested — not instrument-verified.