Server TPM and Secure Boot Explained

A TPM is a component most people never think about until something will not install, an encrypted volume will not unlock, or a compliance questionnaire asks whether one is fitted.

On enterprise servers it is also frequently not fitted at all, because it is an optional module with its own part number rather than something soldered to the board. This guide covers what a TPM does, how it differs from Secure Boot, what needs one, and the specific traps that catch people buying or redeploying used server hardware.

What a TPM actually is

A Trusted Platform Module is a small dedicated chip that generates and stores cryptographic keys in hardware, in a way that software running on the machine cannot extract them.

That is the whole point. A key held in a file on disk can be copied by anything with sufficient privilege. A key sealed inside a TPM can be used by the machine but not read out of it, so an attacker who copies the disk gets ciphertext and no way to decrypt it.

It also keeps a running set of measurements — cryptographic hashes of the firmware, boot loader and configuration that were loaded on the way up. Those measurements can be checked later to establish whether the machine booted in the state it was expected to.

TPM 2.0 is the current specification and the one everything modern requires. TPM 1.2 is the older generation, and it is not a drop-in equivalent — software that requires 2.0 will not accept 1.2.

TPM and Secure Boot are different things

Constantly conflated, and worth separating because you can have either without the other.

Secure Boot is a UEFI firmware feature. It checks that each component in the boot chain carries a valid signature before executing it, and refuses to run anything unsigned or signed by a key it does not trust. It needs no TPM. It is on or off in firmware settings, and it either permits the boot or stops it.

The TPM does not block anything. It records what was loaded. That record is then available to something else — a disk encryption system, an attestation service, a hypervisor — which decides what to do about it.

The two combine well. Secure Boot prevents unsigned code from running, and the TPM provides a tamper-evident record proving that is what happened. Full disk encryption typically uses both: Secure Boot to establish the boot chain, the TPM to release the volume key only if the measurements match.

This is also why an encrypted volume can stop unlocking after a firmware update. The measurements changed, the TPM will not release the key, and the machine asks for the recovery key instead. That is the mechanism working, not failing.

What needs one

The list has grown, which is why this comes up more than it used to.

Full disk encryption on Windows Server and on Linux with a TPM-backed configuration. Without a TPM the key has to come from somewhere else — a passphrase typed at every boot, or a network key server — neither of which suits a server that must come back unattended after a power event.

Hypervisor host attestation and configuration encryption. Current versions of the major hypervisors either require or strongly recommend TPM 2.0 on hosts, and some security features are unavailable without it.

Hardened Windows Server configurations. The secured-core and virtualisation-based security feature sets depend on TPM 2.0 being present and enabled.

Compliance frameworks that require hardware-rooted key storage or measured boot. This is where it most often surfaces as a procurement requirement rather than a technical one.

Note what is not on the list. A TPM does not encrypt drives itself and is not a replacement for self-encrypting drives. The drive does the encryption. The TPM holds the key that unlocks it.

On servers it is usually an optional part

This is the practical point that catches people out, and it differs from laptops and desktops where a TPM is generally built in.

On most enterprise server platforms the TPM is a small module fitted to a dedicated header on the system board, ordered separately, with its own part number. A server configured without one has an empty header.

Three consequences.

The module is vendor and generation specific. A module for one manufacturer's platform does not fit another's, and modules frequently do not carry across generations within the same manufacturer. Order against the server model, not against the words TPM 2.0.

It is designed as a one-time installation. Server TPM modules are generally built to be tamper-evident, which in practice means removing one after it has been installed and enabled is likely to destroy it. Treat fitting a TPM as permanent, and do not plan to move one between machines.

Fitting it is not the end of the job. The module has to be enabled in firmware and, depending on the platform, the correct mode selected. A fitted but disabled TPM presents to the operating system as absent.

The traps on used and redeployed servers

Four things worth checking, and the first two cause real data loss.

Encrypted volumes and TPM changes. If a server has encrypted volumes whose keys are sealed to the TPM, and you clear the TPM, replace it, or replace the system board it sits on, those volumes will not unlock. You need the recovery key first. Retrieve and verify it before touching any of that hardware, not after.

A TPM carrying a previous owner's state. A used server may arrive with a TPM that has been provisioned and owned. It needs clearing in firmware before redeployment, and clearing it destroys anything sealed to it — which is exactly what you want on a machine being redeployed, and exactly what you do not want if the previous owner's data is still on the drives and someone still needs it.

Absent rather than disabled. A server listed without a TPM may have an empty header rather than a disabled module. Worth confirming which, because one is a firmware setting and the other is a part to source.

Version mismatch. Older servers may carry TPM 1.2 modules. If the target software requires 2.0, that module has to be replaced, and on some platforms the header itself only accepts the generation it shipped with.

Our used server checklist covers the wider set of questions worth asking before purchase, and TPM presence belongs on it for anything that will run encrypted volumes.

Firmware updates and measurement changes

Worth planning for, because it turns a routine maintenance task into an outage if it is not.

Firmware updates change the measurements the TPM records. On a machine with TPM-sealed encryption, that can mean the volume does not unlock on the next boot and the recovery key is required to get in.

Some platforms and encryption systems handle this automatically by suspending protection across the update and resealing afterwards. Not all do, and the behaviour depends on both the encryption software and how the platform reports the update.

The safe sequence is to have the recovery key in hand, suspend encryption protection if the system supports it, apply the update, confirm the machine boots, and re-enable. Our firmware update guide covers the surrounding order of operations.

Sourcing

We supply TPM modules for HPE, Dell and Lenovo server platforms against the exact manufacturer part number, and can confirm TPM presence on any server we quote before it ships.

Tell us the server model and generation and what the module is needed for, and we will confirm the correct part rather than supplying a generic TPM 2.0 module that will not seat. Send a bill of materials through the bulk quote page or email sarah.jane@techsellerusa.com.

Common questions

Send us the server model and we will confirm whether a TPM is fitted and which module the platform takes.