Encrypting a GPU server: LUKS2 with TPM2 unlock, self-encrypting NVMe and model files

What disk encryption on a GPU server protects

Encrypting a GPU server means encrypting its NVMe drives at rest, usually with LUKS2 on Linux and a TPM2 chip that releases the key at boot, so that the data is unreadable on a drive or a server that leaves your control. An AI server in a branch office, a server room without access control or a colocation rack holds fine-tuned models, vector indexes of internal documents and logs of questions and answers. Encryption covers theft of a drive, theft of the server if the unlock method is chosen for it, a failed drive sent back under warranty, and the drives at retirement.

It covers nothing on the running system. Once the volume is unlocked, the operating system, the inference engine and anyone with a shell read the data in plain text. Attacks on the BMC, the inference API, the container runtime or model files are the subject of our guide to securing a GPU server. Data in GPU memory during processing is a separate problem again, which our article on confidential computing with the H200 NVL and RTX PRO 6000 covers. And encrypting the server's disks does not encrypt its backups; our guide to backing up an AI server covers where the copies go.

The GDPR names encryption as an example of a risk-reducing measure: Recital 83 speaks of measures "such as encryption", and Recital 88 asks that rules on breach notification consider whether data "had been protected by appropriate technical protection measures". Whether your setup meets your obligations is for your data-protection officer to confirm.

What to encrypt on an AI server: models, indexes and logs

An AI server stores more sensitive data than its model files suggest, and some of it in places nobody planned.

Our classification; vector store and adapter contents as described in our guide to backing up an AI server.

A practical layout puts everything sensitive on one encrypted data volume (model store for fine-tuned weights, vector database, logs, traces) and decides about the operating system volume separately, because unlocking the root volume at boot needs support in the initramfs. Keeping public base weights unencrypted only helps if they sit on a volume of their own; on our reference configurations, with two, four or eight NVMe drives, encrypting every data drive is the simpler rule. A server that also runs a trace store such as Langfuse or a gateway query log stores the most personal data there, not in the models.

Unlocking at boot: TPM2, PIN or network

An encrypted server must get its key at every boot. A person typing a passphrase works for one server with a console, but not for a server that reboots after a kernel update at night. Three automatic methods are common, and they protect against different things.

Our comparison from the systemd-cryptenroll manual (systemd 262) and Red Hat's RHEL 9 documentation on policy-based decryption, read 25 October 2026.

TPM2 alone keeps the key inside the server's TPM chip. A drive taken out is useless, but a stolen server boots and unlocks itself, and its data is then as safe as its login and services. A PIN closes that gap: --tpm2-with-pin=yes requires it in addition to the PCR binding, and the PIN can be typed through the BMC's remote console when nobody is on site. The manual warns that wrong PIN entries can trigger the TPM's lockout. Network-bound disk encryption (NBDE) with Clevis and a Tang server, documented by Red Hat for RHEL 9, unlocks the volume only while the server can reach the Tang server in your network. A server carried out of the branch office no longer finds it and stays locked. Tang is installed from the tang package and listens on port 80 in Red Hat's minimal setup.

For a server in a locked data centre, TPM2 with PCR 7 is usually enough. For a server in an office or a branch, as in our guide to a GPU server in an office, a PIN or Tang is the method that matches the risk.

LUKS2 with TPM2 using systemd-cryptenroll

systemd-cryptenroll adds unlock methods to an existing LUKS2 volume; it "supports only LUKS2 volumes, as it stores token meta-information in the LUKS2 JSON token area". The steps for a data volume on an NVMe drive:

1. Create the volume with cryptsetup luksFormat --type luks2 and the device, with a passphrase. The cryptsetup manual leaves cipher, key size and key derivation to compiled-in defaults that cryptsetup --help shows; LUKS2 supports the memory-hard Argon2.
2. Enrol a recovery key first with systemd-cryptenroll --recovery-key and the device. It generates a high-entropy key that can be typed in or scanned as a QR code. Store it outside the server (see recovery keys below).
3. Enrol the TPM with --tpm2-device=auto --tpm2-pcrs=7 and the device. Without --tpm2-pcrs, the manual states that the key binds to "no PCRs at all", which means the TPM releases it to any boot of any software. Add --tpm2-with-pin=yes for a PIN.
4. Add a line to /etc/crypttab with the option tpm2-device=auto; the manual's example line gives the volume name, the device by UUID, none for the key file and tpm2-device=auto. The volume then unlocks at boot through the TPM, which decrypts the key stored in the LUKS2 token header.
5. Remove the initial passphrase if policy demands it, with --wipe-slot and the slot number; the tool refuses to wipe every slot. Keep at least the recovery key enrolled.

The crypttab option tpm2-device= was added in systemd 248, and the no-read-workqueue and no-write-workqueue options in the same release need kernel 5.9 or newer. For the root volume, the initramfs must perform the unlock. Red Hat's documentation does this for Clevis with the clevis-dracut package and a regenerated initramfs (dracut -fv --regenerate-all with --hostonly-cmdline), and binds a volume to Tang with clevis luks bind -d plus the device and the Tang URL. On other distributions, check that the initramfs supports TPM2 unlock before you encrypt the root volume.

We supply the AI servers this runs on; send us your encryption requirements with the request, for example a TPM 2.0 module and self-encrypting NVMe drives, and our team includes them in the configuration.

Secure Boot, firmware updates and the choice of PCRs

The TPM releases the key only if the PCRs, registers that record what booted, hold the values they had at enrolment. The choice of PCRs decides when unlocking breaks. The systemd-cryptenroll manual lists them:

systemd-cryptenroll manual, systemd 262, read 25 October 2026.

The manual calls it "typically not advisable" to bind to PCRs such as 0 and 2, because they change with firmware updates, and a GPU server can receive BIOS and BMC firmware updates several times over its life. PCR 7 is the choice we describe here: it stays stable across kernel and driver updates, and it changes when someone turns Secure Boot off to boot their own software. For PCR 11, which changes with every kernel, the manual offers signed PCR policies (--tpm2-public-key), where a signature on the expected values replaces the values themselves; that suits teams that build signed unified kernel images.

Secure Boot matters for a second reason on a GPU server: the NVIDIA driver is an out-of-tree kernel module that must be signed, often with a Machine Owner Key, as our guide to the NVIDIA driver and Secure Boot on Linux explains. Enrolling keys and changing Secure Boot settings can change PCR 7, so do it before you bind the TPM, or have the recovery key ready. Before every firmware update, check that the recovery key is at hand; if the TPM refuses after the update, unlock with it and enrol the TPM again. Red Hat gives the same warning for Clevis: PCR values can change and the volume then no longer unlocks, so keep a strong passphrase for manual unlock.

Self-encrypting NVMe drives (Opal)

Self-encrypting NVMe drives encrypt every block in hardware, and those that support the TCG Opal standard can be locked and unlocked by the host. cryptsetup can manage them: --hw-opal formats LUKS2 "with dm-crypt encryption stacked on top of HW-based encryption", so both layers apply, while --hw-opal-only uses the drive's encryption alone and LUKS2 manages only the unlock key of the locking range. OPAL support requires kernel 6.4 or later.

The manual carries two warnings. With --hw-opal-only, the drive's Opal administrator PIN "allows unlocking all configured locking ranges without LUKS keyslot decryption", so that PIN becomes as sensitive as the keys. And some drives need a PSID reset, which deletes all data, before they accept the LUKS Opal format. The PSID is printed on the drive; the erase manual warns that it lets anyone with access destroy the data and asks that it not leak "through transparent packaging during transport or images of the drive posted online".

Hardware encryption costs no CPU time, but its quality depends on firmware you cannot inspect. Software encryption with dm-crypt is open and auditable. Stacking both with --hw-opal means a weakness in one layer still leaves the other in place. Whether a drive supports Opal is in its datasheet; ask for it in the quote if you need it.

Recovery keys, header backups and escrow

A lost key means lost data, so key management comes before encryption. Three things belong in a company password vault or a sealed envelope in a safe, outside the server:

• The recovery key from systemd-cryptenroll --recovery-key, one per volume, labelled with the server's serial number and the volume's UUID.
• The LUKS header backup, made with cryptsetup luksHeaderBackup and --header-backup-file. The manual warns that "all data is permanently lost unless you have a header backup" if the header is damaged. It also warns that the backup "and a passphrase valid at the time of backup allow decryption of the LUKS data area, even if the passphrase was later changed or removed", so the backup is as sensitive as the key.
• For Opal drives, the administrator PIN, with the same care.

Decide who may retrieve them, under which procedure, and test a recovery once a year on a spare volume. If one person holds the only copy, the data depends on that person.

Failed drives, warranty returns and retirement

A drive that fails often cannot be wiped anymore, which is the case where encryption pays off most. An encrypted drive returned under warranty holds only ciphertext: the TPM-sealed key stays in the server's chip, and a recovery key or passphrase is not on the drive. The LUKS header on the drive does contain the keyslots, so a weak passphrase could be attacked offline; a generated recovery key and a strong passphrase close that path.

If the drive still responds, remove the keys before it leaves. cryptsetup erase removes all keyslots and the volume key. The manual says that this "operation is irreversible" and that all data "will be permanently irretrievable" unless a header backup exists, so destroy any header backups of that volume as well. The erase "does not wipe or overwrite the data area", which is unnecessary once the key is gone. On Opal drives, the PSID factory reset erases all data on the drive. At retirement, NVMe sanitisation with a crypto erase and a certificate per drive, as described in our guide to the GPU server lifecycle, completes the process.

Performance: model loading and vector stores

dm-crypt decrypts on the CPU, and a GPU server reads its largest files, the model weights, when an engine starts. A model such as gpt-oss-120b with 60.8 GiB of weights is read once per start; after that the Linux page cache holds the file, and the GPUs work from their own memory. Inference speed is not affected. Vector databases and logs make smaller, random reads and writes on the encrypted volume during operation.

We found no published measurement of dm-crypt throughput on current EPYC processors with PCIe 5.0 NVMe drives. cryptsetup benchmark measures the ciphers on your processors in memory, which gives the upper limit to compare with your drives' rated speed. Test the no-read-workqueue and no-write-workqueue options with your workload if the volume is slower than expected. The discard option passes TRIM through to the SSD and, as the crypttab manual puts it, "improves performance on SSD storage but has security implications", since it reveals which blocks are in use. Our guide to NVMe for an LLM server gives load times from NVMe, a NAS and the page cache.

What we supply

You can buy these servers from us: our team sizes the configuration to your workload and budget and replies within one business day. We build AI servers to order with two, four or eight RTX PRO 6000 Server Edition or H200 NVL cards, two AMD EPYC processors and NVMe storage, with out-of-band management through the BMC, assembled and tested before delivery, on one EU contract and invoice, with manufacturer warranty on every component handled through us; quantities and lead time are confirmed in writing with the quote. On request the server arrives with the operating system, the NVIDIA driver, CUDA and a container runtime. Tell us where the server will stand and who may unlock it, and we include the TPM module and drives that your encryption plan needs.

FAQ