Which hardware platforms does Heads support for laptops and servers?

Updated

Heads targets specific laptop/workstation and server platforms rather than offering a universal build, and its protection depends on hardware-specific hardening baked into each port. The wiki's main menu splits support into two tracks — laptops/workstations on one side and servers (managed via BMC, SSH, or console) on the other — so the practical answer is to check the Heads wiki's board list for your exact model before assuming support. The project does not claim coverage of arbitrary hardware.

What "supported" means for Heads hardware

Heads is not a Linux distribution you install on anything with a CPU. It combines:

  • Physical hardening of specific hardware platforms — each port is built around a particular board's flash layout, write-protect mechanism, and recovery path.
  • Flash security features with custom coreboot firmware and a Linux boot loader stored in ROM.
  • A root of trust moved into the write-protected region of the SPI flash, which blocks later software modification of the boot code.

Because the root of trust lives in write-protected SPI flash, a platform only works if its flash can actually be protected and its boot path can be measured. That is why support is enumerated per board rather than per CPU family.

Laptop and workstation targets

Laptop/workstation support is the track most individual users care about. On these machines Heads:

  1. Controls the first instruction the CPU executes, which lets it measure every step of boot firmware and configuration into the TPM.
  2. Uses the TPM to attest to the user or a remote system that the machine has not been tampered with.
  3. Once the system is in a known good state, uses the TPM as hardware key storage to decrypt the drive.
  4. Requires the hypervisor, kernel, and initrd images to be signed by keys the user controls.

Some laptop platforms additionally support Bootguard-enforced verified boot of the firmware, but the wiki describes this as conditional — "on platforms that support it" — so it is a per-board property, not a Heads-wide guarantee.

Server targets

Servers are a separate track, accessed through BMC, SSH, or console rather than a local keyboard and screen. The same measurement-and-attestation model applies, but the operational entry points differ, which matters for how you verify a machine's state and how you recover from a failed update. If you are evaluating Heads for a server fleet, confirm the specific board's BMC and console workflow in the wiki rather than assuming the laptop procedure transfers.

Limitations to weigh before choosing hardware

Consideration What the project states
Binary blobs Modern Intel CPUs require binary blobs to boot; these non-Free components are included in the measurements and are "at least guaranteed to be unchanging"
Scope of protection Heads "aims to provide slightly better physical security and protection for data" — it does not secure the system against every possible attack vector
Threat model It addresses several classes of attacks against the boot process and physical hardware neglected in traditional installations, raising difficulty rather than eliminating risk
Data persistence Unlike Tails, Heads is intended for machines where you store data and state — it is not a stateless OS

The binary-blob point is the one most likely to affect a hardware decision: you cannot get a blob-free boot on modern Intel, and Heads' answer is to measure the blobs so any change is detectable, not to remove them.

How to confirm a specific machine is supported

  1. Identify the exact board model, not just the CPU generation — Heads ports are board-specific.
  2. Check the Heads wiki's platform list for that model and note whether it is a laptop/workstation or server target.
  3. Read that board's page for its flash write-protection method, recovery procedure, and whether Bootguard verified boot applies.
  4. Confirm your intended use fits the design: persistent data on the machine, with user-controlled signing keys for hypervisor, kernel, and initrd.

If your model is not listed, treat it as unsupported rather than assuming a nearby board's build will work — the write-protect and measurement steps depend on the specific flash and boot path.

Where to go next

The wiki is the authoritative source for the current board list and per-platform notes, and it is maintained as ongoing work; the project asks for support via GitHub Sponsors (tlaurion) or Open Collective (Insurgo), with details on the Community page. For background on why the design looks this way, Trammel Hudson's 33C3 talk introduces Heads and catalogues the attack classes it targets — including Thunderstrike, where DMA over Thunderbolt rewrites SPI flash, countered by enabling IOMMU/VT-d and coreboot disabling the relevant path. That talk is a useful filter when judging whether a candidate board's hardening actually covers the attacks you care about.