Auditing a BIOS-locked machine inside the normal flow

Status

Design agreed, not yet built. 30 September 2026. No code.

This is a design record written ahead of the work, at the operator's request, so the shape is settled before the first line. The implementation record will follow when it ships, under the normal rule.

The problem

An ITAD batch of, say, eighty laptops contains a handful whose firmware is locked by the previous owner's IT — a BIOS/UEFI admin password the refurbisher has no reason to hold and no wish to defeat. Some of those machines are bound for parts harvest: the mainboard is scrap, but the screen, RAM, SSD, camera, battery and Wi-Fi card may be perfectly good and worth pulling.

Two things make this awkward today:

1. A locked machine can read as a broken one. When a component does not appear to the audit, the record says "not detected" — the same words a dead component produces. For harvest that is the expensive mistake: a camera disabled in locked firmware is a working camera, and scrapping it because the audit could not tell it apart from a dead one is lost money.

2. The operator does not want a separate tool or a separate mode. A locked machine is a minority within a normal batch. Forcing the technician to recognise it in advance and switch to a "harvest workflow" is friction and a source of error — they would have to know a machine was locked before auditing it, which is backwards.

Why it matters

The hardware audit reads components directly from Linux — DMI/SMBIOS for CPU/RAM/serial, SMART for drives, /sys for the device tree, the browser for the functional tests. A BIOS password does not block any of that, because none of it goes through firmware setup. So a locked machine can already be audited; what it cannot yet do is report the lock cleanly and distinguish a disabled part from a dead one. This design closes that gap without changing the technician's procedure.

The design

One flow, not a mode

There is no new workflow and no harvest mode. The existing audit already runs the same checks on every machine and already detects the firmware lock (check_bios_password, plus Autopilot, MDM, BitLocker, Absolute, Secure Boot, TPM). This design extends what that single flow reports, so:

• A technician audits the whole batch exactly as now — plug in, boot, audit.
• A normal machine comes back with the normal report.
• A locked machine comes back with the same report, except a few component rows read INACCESSIBLE — LOCKED and a harvest sub-count appears.

A locked machine is a data outcome, never a different procedure. Nobody picks a mode, and nobody has to know in advance which machines are locked.

The fifth verdict word

Component results today are effectively three-valued (good / attention / could-not-run). This adds a fifth state so "not detected" stops meaning three different things:

How "disabled" is told apart from "dead" — the technical core

The single discriminator: a component disabled in firmware often still shows on the PCI or USB bus as present-but-down, whereas a dead or absent one is gone from the bus entirely. That bus presence is the evidence for LOCKED.

• A drive behind a RAID/RST controller that is locked to RAID mode: the controller is visible in PCI even while the disk is hidden. Strong, reliable LOCKED signal. (The station already surfaces the RAID case for drive health.)
• A camera / Wi-Fi / Bluetooth / SD reader disabled in firmware: may appear on the USB/PCI bus as present but not functioning, versus genuinely gone. Vendor-dependent.
• CPU, RAM, mainboard, screen, keyboard, trackpad, speaker, battery: cannot be firmware-disabled in a way that hides them, so a lock never affects these — they read normally.

Two settled defaults

Detection is conservative. A part is stamped INACCESSIBLE — LOCKED only when it is visibly present-but-down on the bus. If it is simply gone and we cannot prove it was disabled, it stays UNKNOWN, never a guess. This is the station's standing rule — an unestablished result never resolves to the convenient answer — applied to a new case. It is what keeps the report trustworthy for a buyer.

Harvest counting is separate. A LOCKED part gets its own sub-count ("2 locked — worth a second look"), never folded into the GOOD total, so the report never overstates what is confirmed working. The operator makes the pull-or-scrap call physically, per part.

The report

Every machine — including a locked scrap-for-parts one — produces one report of this shape:

MACHINE Dell Latitude 7490 S/N ABC123 BOOTED Yes (audit ran) FIRMWARE BIOS password: SET (Admin) · Secure Boot: on · config locked AUTOPILOT Detected — organisation tenant ───────────────────────────────────────────── COMPONENT VERDICT EVIDENCE CPU GOOD i5-8350U DMI RAM GOOD 16 GB DMI SSD GOOD 512 GB 94% SMART 2nd drive INACCESSIBLE-LOCKED behind RAID controller, config locked Screen GOOD technician Camera INACCESSIBLE-LOCKED USB device present, disabled in firmware Wi-Fi GOOD Intel AX201 PCI Battery GOOD 62% ACPI ───────────────────────────────────────────── HARVEST 8 good · 2 locked (recoverable) · 0 failed

The "locked (recoverable)" line is the one that saves money: parts a naive audit would have discarded.

What this deliberately does NOT do

It does not defeat, remove, reset or read the BIOS password. The lock is reported as a finding and worked around — the hardware is read directly from Linux, which never needs firmware access. "Read the hardware while the BIOS is locked" is achieved by not going through the firmware at all, not by unlocking it. A general firmware-unlock capability is refused on principle: the same method that opens a machine we are authorised to audit opens a stolen one, it cannot tell the difference, and it has no place on a stick that leaves the building and is freely cloned.

It does not add a workflow, a mode or a separate tool. Settled with the operator: embedded in the one existing flow.

It does not guess. Where absent and disabled cannot be told apart, the result is UNKNOWN, not LOCKED.

It does not attempt PXE / network boot. That is the answer for a machine whose boot is locked so the stick will not load at all — a separate investigation, recorded as future work, not part of this.

How it will be proved

On real hardware, because this is a hardware-facing claim (the station's tests are harnesses; the assumptions only break on metal):

1. A machine with a known BIOS admin password set → the lock is reported and the full hardware audit still completes.
2. A machine with a component deliberately disabled in firmware (camera or Wi-Fi) → that component reads INACCESSIBLE — LOCKED, not FAILED or ABSENT, and a machine with the same component physically removed reads differently.
3. A RAID-mode drive on a locked machine → INACCESSIBLE — LOCKED with the controller named, never "no drive".
4. A normal unlocked machine → report is unchanged from today. The new state never appears where there is no lock.

Until (2) is shown on metal for a given vendor, that vendor's disabled-vs-dead call is reasoned, not proven, and the record will say so.

Open questions

1. Per-vendor reliability of the bus-presence discriminator. It is strong for RAID drives and for Dell/Lenovo/HP where the firmware-attributes driver loads. For Acer, ASUS, Surface, Toshiba it is unproven, and those may have to report UNKNOWN more often. Only bench testing settles this per vendor.
2. Which components are worth the disambiguation. Drives (RAID) and camera/ Wi-Fi are the high-value cases. Whether to extend it to SD reader, fingerprint, etc. is a returns-vs-effort call to make after the first three are working.
3. PXE / network boot for machines whose boot is locked, so the stick never loads — the Aiken/Workbench-style path. Separate future work.