A BIOS update that resets secure boot keys is one of the most disorienting hardware events a Linux user can run into. You boot the machine, the BIOS loads, and suddenly every bootloader entry you had on the disk is rejected as untrusted. The Debian installer puts its bootloader on the EFI System Partition (the small FAT32 partition on a UEFI machine that holds bootloaders and signed binaries) and signs it with a key the BIOS does not know about. When the BIOS firmware erases its database of trusted platform keys, that signature is no longer valid. The fix is to re-enroll the right keys in the firmware, and the path is mostly the same on every Debian-family distribution. The detail that catches people off-guard is that there is a difference between “reset to factory default keys” and “delete all custom keys,” and only one of those fixes the situation.
A Thinkpad BIOS update wiped the secure boot keys on a Debian 13 installation that had been booting cleanly for weeks. The firmware update was uneventful, but the next reboot dropped into the firmware setup with a red warning that secure boot had been disabled because no valid signature chains remained. Here is what worked, what did not, and what to know before you start clicking around in firmware menus.
What secure boot keys actually are
Secure boot is a chain of trust rooted in keys burned into the firmware at manufacture (the PK, or Platform Key), with one or more Key Exchange Keys (KEKs, used to sign updates to the database of allowed keys), and a database of authorized signatures (db) and forbidden signatures (dbx). When the firmware sees a bootloader, it checks the signature chain. If the chain leads back to a key in db, the bootloader runs. Otherwise, the firmware refuses to load it and either falls back to a non-secure boot path or refuses to boot entirely.
Most Linux distributions sign their bootloaders with their own keys and rely on Microsoft’s UEFI CA key (a signing certificate Microsoft provides so multiple vendors can ship keys Windows will accept) being present in db by default. That is how a Debian ISO can boot on a fresh machine that has never seen a Debian key before. The Microsoft UEFI CA is a third-party signer, which is also why some users opt to disable it and enroll only their distro’s key.
When a BIOS update “resets” secure boot, what usually happens is that the firmware wipes the db, KEK, and PK databases back to factory state. If you were already using the defaults (Microsoft UEFI CA in db, no custom keys), the reset is invisible. If you had enrolled your own keys, the reset silently breaks your boot chain.
How to find out which case you are in:
- Check what is in db right now. Boot into Linux and run
sudo mokutil --db(MOK stands for Machine Owner Key, the standard mechanism Linux distros use to enroll distro- or user-owned keys in firmware). If the list is empty or contains only Microsoft keys, your firmware is in factory-default state. - Check whether your distro’s key is enrolled. For Debian, run
sudo mokutil --list-enrolledand look for entries withSubject: CN=Debian Secure Boot CA. If the entry is there, your Debian key is enrolled. If not, the firmware does not trust your bootloader. - Read the BIOS event log if you can. Most UEFI firmware has an event log under the secure boot menu that records when the key databases were last modified. That tells you whether the reset was a factory wipe or something else.
The fix that actually works
If your situation is the common one (BIOS reset wiped custom keys, you cannot boot Debian anymore because the bootloader signature chain is broken), the path is to boot from a Debian installer USB, chroot into the installed system, and re-enroll the Debian key with mokutil. The Debian Secure Boot CA key ships with the shim-signed package and is referenced by the mmx64.efi shim that is already on your EFI System Partition. Re-enrolling it adds it back to db without touching the existing Microsoft entries.
Step-by-step recovery from an installer USB:
- Boot the Debian installer in rescue mode. From the boot menu of the USB stick, choose “Rescue mode” or “Advanced options > Rescue.” This drops you into a shell with the installed system mounted.
- Find your EFI System Partition. It is usually
/dev/sda1or/dev/nvme0n1p1, formatted as FAT32. Mount it under/mnt/boot/efiif the rescue shell does not do that automatically.ls /mnt/boot/efi/EFI/debianshould showshimx64.efi,grubx64.efi, and the MOK certificate files. - Re-enroll the MOK (Machine Owner Key). Run
sudo mokutil --import /mnt/boot/efi/EFI/debian/MokManager.efi --root-pwto import the Debian MOK from the EFI partition. The--root-pwflag means you will need to type the root password at the next reboot to confirm the enrollment. If--root-pwdoes not work because the rescue shell is not chrooted, omit it and provide a one-time password instead. - Reboot and confirm the enrollment. On the next boot, the shim should display a blue MOK manager screen. Choose “Enroll MOK,” then “Continue,” then type the password you set. After that, the firmware trusts the Debian signature chain and the installed system boots normally.
The recovery takes about five minutes once you have the installer USB ready. The slowest part is usually finding the right EFI partition if you have multiple disks.
When the fix is not enough
If the BIOS update also wiped the Microsoft keys from db (some firmware updates do, especially on older Lenovo and HP machines), the recovery is more involved. You will need to manually re-enroll the Microsoft UEFI CA certificates, which are downloadable from Microsoft’s documentation site. The exact files vary by firmware generation, but you need the “Microsoft UEFI CA” certificate and the “Microsoft UEFI CA 2023” certificate as a minimum. Both are DER-encoded X.509 files (a standard public-key certificate format) that you can enroll through the firmware setup menu or by dropping them into /boot/efi/EFI/debian/ and re-running mokutil --import.
A second complication is when the BIOS update changed the firmware to “setup mode” but did not actually wipe db. In setup mode, the firmware is willing to accept new keys, and you can re-enroll without an installer USB by booting into the existing Linux installation in permissive mode (some firmware menus have a “secure boot: setup” toggle for this exact case). Check your firmware setup for a “Restore Factory Keys” or “Reset to Secure Boot Defaults” option before going down the installer USB path, because that menu-driven reset is often faster.
Trade-offs
Re-enrolling the Debian MOK is the right answer for a Debian installation that was previously booting with secure boot. The trade-off is that you are explicitly trusting a third-party certificate (the Debian Secure Boot CA) at the firmware level. If that key is ever compromised, an attacker who signs a malicious bootloader with the Debian key can boot it on your machine. The risk is small because the Debian key has been kept in a hardware security module (a tamper-resistant device that stores signing keys so they cannot be extracted), but it is non-zero.
For a corporate fleet, the trade-off is different. If your IT department manages its own MOK hierarchy, re-enrolling the distro default key without coordination breaks the audit chain. The correct path in that case is to import the corporate MOK rather than the Debian default, and that is a job for the IT team rather than a one-person recovery.
For a single home machine, the Debian default is fine. The recovery path above is what the upstream Debian wiki documents and what the shim-signed package is designed for. There is no faster path that is also correct, and there are several faster paths that look correct but leave the system in a half-broken state where the next kernel update cannot boot because the new kernel image was signed with a key the firmware does not know about.
Bottom line
If a BIOS update broke secure boot on a Debian machine, boot from an installer USB in rescue mode, mount the EFI System Partition, and run mokutil --import against the Debian MOK. Reboot, confirm the enrollment in the blue MOK manager screen, and the system boots normally. The whole flow is about five minutes if you have the installer USB ready. If the firmware also wiped the Microsoft keys, download them from Microsoft’s docs and enroll them through the same path before importing the Debian MOK. Skip the “reset to factory defaults” firmware menu option if you previously enrolled custom keys. It will not undo the firmware’s wipe, and you will be back at the same starting point.