Our Secure Boot explainer covers what it does. This covers making it verify your system rather than Microsoft’s signature.

What the default actually checks

Firmware ships trusting Microsoft’s keys. Linux distributions boot under Secure Boot through shim, a small bootloader Microsoft signs, which then verifies the distribution’s own key.

So the chain is: firmware trusts Microsoft, Microsoft signed shim, shim trusts your distribution.

That works, and what it verifies is “something Microsoft was willing to sign is booting.” Anything else Microsoft signed will also boot, which has periodically included vulnerable bootloaders that could be used to bypass the whole mechanism.

Enrolling your own keys means the firmware verifies exactly the binaries you signed.

Before you start

This can leave a machine unbootable. Some firmware handles key replacement poorly.

# back up the current keys
sudo apt install efitools
mkdir ~/secureboot-backup && cd ~/secureboot-backup
efi-readvar -v PK -o PK.esl
efi-readvar -v KEK -o KEK.esl
efi-readvar -v db -o db.esl
efi-readvar -v dbx -o dbx.esl

Three things to confirm first:

Your firmware has a “restore factory keys” option. Check the setup menu before you touch anything.

You know how to enter firmware setup, including if the machine will not boot.

You have installation media that can boot with Secure Boot off.

If your firmware has no reset option, do not do this on a machine you depend on.

The key hierarchy

Three levels, each authorising the one below.

PK, the Platform Key. One key, the root. Controls updates to KEK.

KEK, Key Exchange Key. Authorises updates to db and dbx.

db, the signature database. The keys and hashes the firmware accepts at boot.

dbx is the revocation list, holding signatures that must be rejected even if otherwise valid.

Keep dbx. Clearing it re-enables known-vulnerable bootloaders that were revoked for good reason.

sbctl

The tool that makes this tractable.

sudo pacman -S sbctl        # Arch
sudo dnf install sbctl      # Fedora

sudo sbctl status

Installed:      sbctl is not installed
Setup Mode:     Enabled
Secure Boot:    Disabled

Setup Mode must be enabled to enroll keys. Enable it in firmware setup, usually by clearing the existing keys, which is a menu option rather than something you do from Linux.

sudo sbctl create-keys
sudo sbctl enroll-keys --microsoft

--microsoft keeps Microsoft’s keys alongside yours. Consider this carefully.

Keep them if the machine dual-boots Windows, or if any firmware component, some option ROMs on add-in cards, is signed by Microsoft and will fail without them.

Drop them for a Linux-only machine where you want the firmware trusting only you. That is the stronger configuration and the one more likely to surprise you when a device stops initialising.

sudo sbctl sign -s /boot/vmlinuz-linux
sudo sbctl sign -s /boot/EFI/BOOT/BOOTX64.EFI
sudo sbctl sign -s /boot/EFI/systemd/systemd-bootx64.efi
sudo sbctl verify

-s adds the file to sbctl’s database so it is re-signed automatically on future updates. That matters, because every kernel update produces a new binary that needs signing, and doing it by hand will eventually be forgotten at the worst moment.

sbctl installs pacman and dpkg hooks to handle it.

Then enable Secure Boot in firmware and reboot.

sudo sbctl status
bootctl status | grep -i secure

Unified kernel images

The cleaner arrangement once keys are yours.

A UKI bundles the kernel, initramfs, and command line into one signed EFI binary.

sudo dnf install systemd-ukify
sudo ukify build \
  --linux=/boot/vmlinuz-6.18.0 \
  --initrd=/boot/initramfs-6.18.0.img \
  --cmdline="root=UUID=... rw quiet" \
  --output=/boot/EFI/Linux/linux-6.18.0.efi

sudo sbctl sign -s /boot/EFI/Linux/linux-6.18.0.efi

Why this is better: signing the kernel alone leaves the initramfs and the kernel command line unsigned. An attacker who can modify either can compromise the boot without touching the signed kernel, which substantially undermines the point.

The command line matters more than people expect. Our kernel parameters guide covers init=/bin/bash, which drops you to a root shell. If the command line is unsigned, an attacker with access to the ESP can add it.

A UKI puts all three inside the signature.

What it protects

Persistence. An attacker with root cannot install a bootkit that survives a reboot, because they cannot sign it.

Evil maid attacks. Someone with brief physical access cannot swap your bootloader.

The initramfs, with a UKI.

What it does not

Anything while the system runs. Root is root. Secure Boot has already finished its job by then.

Data at rest. That is LUKS. The two are complementary halves.

Someone who can enter firmware setup, unless you set a firmware password. Without one, an attacker with physical access disables Secure Boot in thirty seconds. Set a firmware password or this is largely decorative.

With TPM

The combination that makes it genuinely strong.

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

The TPM releases the disk encryption key only if the boot measurements match. Change the bootloader, the kernel, or Secure Boot state, and the measurements differ and the key stays sealed.

Keep a passphrase enrolled as well. A firmware update changes the measurements and the TPM will refuse to unseal. Without a fallback you have encrypted your data away from yourself, which is a genuinely common way to lose a system.

sudo cryptsetup luksDump /dev/nvme0n1p3 | grep -A2 Keyslots

Confirm more than one slot before relying on the TPM.

Frequently Asked Questions

Why replace the default Secure Boot keys?

By default the firmware trusts Microsoft, so Secure Boot verifies that something Microsoft signed is booting rather than that your system is booting. Enrolling your own keys means the firmware verifies exactly the kernel and bootloader you signed, which is what the feature is supposed to provide.

Can enrolling custom keys brick my machine?

It can render it unbootable, and some firmware handles key replacement badly enough that recovery is difficult. Always back up the existing keys first, confirm your firmware has a reset-to-defaults option, and know how to enter firmware setup before you start.

What are PK, KEK, and db?

PK is the Platform Key, the root of trust that controls updates to everything else. KEK is the Key Exchange Key, which authorises changes to the signature database. db is the signature database holding the keys and hashes the firmware will accept when booting.

Do I need to re-sign the kernel after every update?

Yes, because each new kernel is a new binary. sbctl and similar tools install pacman or dpkg hooks that sign automatically on kernel installation, which is the only practical way to keep up with it.

Does Secure Boot stop an attacker with root?

Not while the system is running. It protects the boot path, so an attacker with root cannot install a persistent bootkit that survives a reboot without your signing key. It does nothing about what they do to the running system.

What is the relationship between Secure Boot and encrypted disks?

They solve different halves. Secure Boot verifies the code that runs before your system, and full disk encryption protects the data at rest. Together they support measured boot with TPM-sealed keys, where the disk unlocks only if the boot chain is unmodified.