Full-disk encryption with LUKS protects your data if a laptop is stolen or a drive is thrown out. Its usability cost is a long passphrase at every boot, and on a server, someone physically present to type it.

Most modern PCs have a TPM (Trusted Platform Module), a small security chip that can hold a key and release it only when the machine boots in a known-good state. systemd-cryptenroll binds a LUKS volume to it in one command, giving you automatic unlock or a short PIN, while the disk remains unreadable anywhere else.

How TPM sealing works

During boot, each stage measures the next before running it: firmware measures the bootloader, the bootloader measures the kernel, and so on. Each measurement is a hash, folded into one of the TPM’s Platform Configuration Registers (PCRs). PCRs can only be extended, never set directly, so their final values summarise exactly what booted.

When you seal a key to the TPM, you tell it: “release this only if PCRs X and Y have these values.” If anything in the measured chain changes, such as a different bootloader or Secure Boot being turned off, the PCRs differ and the TPM refuses.

Which PCRs matter

PCR	Measures	Changes when
0	Firmware code	Firmware (BIOS/UEFI) updates
4	Bootloader	Bootloader updates
7	Secure Boot state and keys	Secure Boot is toggled or its keys change
11	Unified kernel image (systemd-stub)	Kernel updates, when using UKIs
15	System identity, measured by systemd (machine ID, mounted filesystems, volume keys)	The OS identity or unlocked volumes change

PCR 7 is the usual choice. It confirms that Secure Boot is on with the expected keys, which means only signed bootloaders and kernels can run, and it changes rarely. Binding to PCR 0 or 4 as well is stricter but means firmware and bootloader updates lock you out until you re-enroll.

Before you start

You need:

• A LUKS2 volume (check with sudo cryptsetup luksDump /dev/nvme0n1p3 | head)
• A TPM 2.0 chip, enabled in firmware
• Secure Boot enabled, if you bind to PCR 7, which you should
• systemd 248 or newer, and an initramfs that supports TPM unlock (covered below)

systemd-cryptenroll --tpm2-device=list
# PATH        DEVICE     DRIVER
# /dev/tpmrm0 MSFT0101:00 tpm_crb

Step 1: add a recovery key

Do this first. If the TPM ever refuses, this is how you get in.

sudo systemd-cryptenroll --recovery-key /dev/nvme0n1p3

It prints a long, high-entropy key made of simple characters. Store it somewhere that is not this computer, such as a password manager or printed paper. Your existing passphrase keeps working too; LUKS has multiple key slots, and enrollment only adds new ones.

Step 2: enroll the TPM

For automatic unlock bound to PCR 7:

sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7 /dev/nvme0n1p3

For unlock with a PIN, strongly recommended on laptops:

sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7 --tpm2-with-pin=yes /dev/nvme0n1p3

The TPM rate-limits PIN guesses in hardware, so a short PIN is far stronger here than it would be as a passphrase.

Step 3: tell the boot process to use it

Edit /etc/crypttab and add tpm2-device=auto to the volume’s options:

# name       device                                     password  options
cryptroot    UUID=3f1c2e4d-...                          none      tpm2-device=auto,discard

Then make sure the initramfs can talk to the TPM, and rebuild it. Our initramfs guide covers why this step exists.

Fedora (dracut): TPM support is included when systemd-cryptsetup is used, which is the default.

sudo dracut -f

Arch (mkinitcpio): use the systemd-based hooks, systemd and sd-encrypt, not encrypt:

# /etc/mkinitcpio.conf
HOOKS=(base systemd autodetect microcode modconf kms keyboard sd-vconsole block sd-encrypt filesystems fsck)

sudo mkinitcpio -P

Ubuntu and Debian use initramfs-tools by default, which does not support systemd-cryptenroll’s TPM tokens. The options are switching to dracut, using Clevis (a separate framework that also binds LUKS to the TPM), or choosing TPM-backed encryption in recent Ubuntu installers.

Reboot. The disk should unlock without the passphrase, or with your PIN.

Checking what is enrolled

sudo systemd-cryptenroll /dev/nvme0n1p3
# SLOT TYPE
#    0 password
#    1 recovery
#    2 tpm2

When it stops unlocking

After a firmware update, a change to Secure Boot keys, or anything else that alters a bound PCR, the TPM will refuse, and boot falls back to asking for a passphrase. That is the system working as designed. Unlock with your passphrase or recovery key, then re-enroll:

sudo systemd-cryptenroll --wipe-slot=tpm2 --tpm2-device=auto --tpm2-pcrs=7 /dev/nvme0n1p3

Tools like fwupd and some distributions can predict PCR values ahead of firmware updates, and systemd supports signed PCR policies (--tpm2-public-key) so that kernel updates signed by your distribution do not require re-enrollment. Those are worth exploring once the basics work.

The security trade-offs

Be clear about what each mode protects against:

Threat	Passphrase	TPM only	TPM + PIN
Drive removed and read in another machine	Protected	Protected	Protected
Machine booted from a USB stick	Protected	Protected (with PCR 7 and Secure Boot)	Protected
Whole laptop stolen, powered on	Protected	Boots to login screen	Protected
Brute force	Depends on passphrase	N/A	TPM rate-limits guesses

TPM-only unlock is a reasonable choice for servers in a locked room, where it provides unattended reboots and protects decommissioned drives. On a laptop, it means a thief gets a running system at the login screen, protected only by your login password and whatever bugs the running system has. TPM plus PIN is the better laptop default.

There are also hardware attacks to know about. Discrete TPM chips talk to the CPU over a bus that can, with physical access and equipment, be sniffed to capture the released key. Firmware TPMs built into the CPU avoid that bus. These attacks require significant time with the device, which matters for high-value targets more than for most people.

For servers that must unlock without a TPM, remote LUKS unlock over SSH with Dropbear is the classic alternative.

Frequently Asked Questions

What does TPM unlocking of LUKS do?

It stores a LUKS key inside the TPM chip, sealed so the TPM only releases it when the machine boots in an expected state. At boot the key is released automatically, or after a PIN, so you do not type the full passphrase, but the disk still cannot be read in another computer.

Which PCRs should I bind to?

PCR 7, which records the Secure Boot state and keys, is the common choice because it changes rarely. Binding to more PCRs, such as PCR 0 for firmware or PCR 4 for the bootloader, is stricter but causes more unlock failures after firmware and bootloader updates.

Is TPM-only unlock secure?

It protects a disk that is removed and read elsewhere, and a machine booted from other media if PCR 7 is bound with Secure Boot on. It does not protect a stolen laptop as well as a passphrase does, because the machine boots to a login screen on its own. Adding a TPM PIN closes most of that gap.

What happens if the TPM stops unlocking the disk?

The boot falls back to asking for another key slot, so you type your passphrase or recovery key. This happens after firmware updates or Secure Boot changes that alter the bound PCRs. Once booted, you wipe and re-enroll the TPM slot.

Do I lose my passphrase when I enroll the TPM?

No. LUKS supports multiple key slots. The TPM enrollment adds a new slot alongside your existing passphrase, and you should keep the passphrase or a recovery key permanently as a fallback.

Does this work on Ubuntu?

systemd-cryptenroll works on any distribution with systemd 248 or later, but the initramfs must support TPM unlocking. Fedora and Arch with the sd-encrypt hook support it directly. Ubuntu’s default initramfs-tools does not, so Ubuntu users typically use dracut, Clevis, or the TPM-backed option in the Ubuntu installer.