Secure Boot and a TPM are the cheapest hardening you will ever do - the silicon is already in the server, the licence is free, and the protection covers the one attack surface most defences ignore: the boot path before the operating system even loads. Yet they ship disabled or half-configured on a surprising number of UK servers. This is the practical, hands-on setup our engineers follow to turn them on properly and tie them to the compliance you actually need.
What Secure Boot and TPM each protect
Secure Boot and the TPM solve different problems and are stronger together. Secure Boot is a UEFI firmware feature that checks the cryptographic signature of every component in the boot chain - firmware drivers, the bootloader, the kernel - and refuses to run anything that is not signed by a trusted key. It blocks bootkits and unsigned tampering before the operating system loads. The TPM (Trusted Platform Module) is a hardware chip that securely stores keys and measurements; modern servers implement TPM 2.0, either as a discrete chip or firmware-based.
Together they enable measured boot: the TPM records a hash of each boot stage into its platform configuration registers, producing tamper-evidence that something downstream - disk encryption, attestation, your SIEM - can verify. Secure Boot stops bad code running; the TPM proves what did run. That combination is what auditors and frameworks are increasingly asking for.
Why this maps directly to UK compliance
Hardened boot is not just good practice - it is increasingly a control you can point at in an audit. Cyber Essentials Plus expects secure configuration and that default, insecure settings are changed; Secure Boot and TPM-backed encryption are concrete evidence of exactly that. For organisations in scope of NIS2 (and UK firms in EU supply chains), boot integrity and the ability to detect tampering support the technical risk-management measures the directive expects.
The TPM also underpins full-disk encryption: BitLocker on Windows Server and LUKS with TPM sealing on Linux can bind the decryption key to a known-good boot state, so a stolen or tampered drive will not unlock. That single capability turns a physical-theft risk into a non-event and gives you something tangible to show against data-protection obligations.
- •Secure Boot: signature-checks the boot chain - evidence for secure-configuration controls
- •TPM 2.0: hardware key store + measured boot - tamper-evidence for risk management
- •TPM-bound encryption: BitLocker / LUKS sealing - protects data at rest on stolen drives
- •Measured boot logs: attestation evidence auditors can verify
The setup sequence that avoids lock-outs
Order matters, because enabling Secure Boot carelessly can leave a server that will not boot. First update the system firmware so you have current Secure Boot key databases and TPM firmware. Confirm the TPM is present, enabled and set to TPM 2.0 mode in firmware - on some servers it ships disabled or in 1.2 compatibility mode. Then enable Secure Boot, but check first that your operating system and any add-in cards (HBAs, GPUs, NICs) use signed drivers, because an unsigned option ROM will refuse to load once Secure Boot is on.
Boot the OS, verify Secure Boot reports as active from inside the operating system, and only then enable TPM-bound disk encryption - and immediately escrow the recovery keys somewhere safe. The most common self-inflicted outage is enabling encryption sealed to the TPM, then changing firmware settings (which alters the measurements) without the recovery key to hand.
Choosing the right firmware state to start from
Servers arrive in one of a few states: TPM disabled, TPM enabled but Secure Boot off, or both on with default keys. The path differs for each, which is why a quick firmware audit before you start saves grief. Where a fleet is mixed, standardise on a target state - firmware current, TPM 2.0 enabled, Secure Boot on with signed drivers, encryption sealed and keys escrowed - and bring every server to it. Our engineers can set this state before delivery as part of the server configuration service so the box arrives hardened.
On Lenovo ThinkSystem and the other major platforms the menus differ but the principles are identical; build the exact model in our configurator and we will apply the hardened-boot baseline. For where this sits in a wider security posture, see our cyber security services.
Operating it without surprises
Once hardened, two operational habits keep it painless. First, always have escrowed recovery keys before any firmware change, because updating BIOS or toggling settings changes the TPM measurements and can trigger a recovery prompt. Second, treat Secure Boot key and firmware updates as a managed process, not an ad-hoc one, so a routine update never quietly breaks the boot chain on an add-in card. Done this way, hardened boot is invisible day to day and decisive the one time it matters.
This pairs naturally with broader hardening - out-of-band management lock-down, patching discipline and monitoring. We treat it as one baseline alongside our cyber security work rather than a standalone toggle.