If you have a dual-boot system with Windows using BitLocker, DO NOT UPDATE if you see KEK firmware updates, or be prepared with your BitLocker recovery key.
What Happened
During today’s routine dnf upgrade (2025-06-10), fwupd automatically updated the UEFI KEK (Key Exchange Key) from version 2011 to 2023. This firmware change immediately triggered BitLocker recovery mode on my Windows installation, even though it’s on a completely separate NVMe disk.
Result: I’m now locked out of Windows without a recovery key.
Consider postponing updates until this is resolved
For Fedora:
Add warnings for firmware updates affecting other OS
Implement opt-out mechanisms for cross-OS updates
Document BitLocker compatibility issues
Provide recovery guidance
Bug Reports Filed
Fedora Bugzilla: [TO BE UPDATED]
fwupd GitHub: [TO BE UPDATED]
Discussion Points
Should firmware updates warn about BitLocker impacts?
How can we better handle cross-OS compatibility?
What recovery options exist for affected users?
Should fwupd detect other OS before UEFI security updates?
Recovery Attempts
Tried so far (unsuccessful):
Disabling Secure Boot
Changing boot order
Various BIOS settings
Still need recovery key to access Windows.
Call to Action
If you’re affected by this or have insights on recovery, please share. This is a significant issue that could lock many users out of their Windows installations.
Has anyone else experienced this? Any successful recovery methods?
Yes, changing the KEK does change the boot chain measurements (specifically PCR[7] in the TPM), and yes, this would happen to a Windows-only system as well. Windows systems using BitLocker or other TPM-based security features would be affected the same way.
Hi. @kigge Thanks for the heads up!
I’m dual booting Windows 11 pro and Fedora 42 mate in a system with 2 ssd for a short time (12 days) I’ve had only windows on this PC for 2 years. I received the kek 2011-2023 update about 10 days ago. Another uefi certificate updated later. Luckily I had no problems. I guess having 2 ssd and 2 efi helped me.
It might be safer to just let windows do all the secure boot stuff updates and not let fwupd or Gnome software touch it. It could imagine that WIndows have a way to fix the bitlocker when it updates the KEK or db database.
-disable Disables protection, which will allow anyone to access encrypted data by making the encryption key available unsecured on drive. No key protectors are removed. Protection will be resumed the next time Windows is booted unless the optional -disable parameters are used to specify the reboot count.
I hate to be that person, but dnf doesn’t do anything with firmware updates, and certainly never installs anything automatically. The KEK is updated using fwupd, so you would either have had to use “fwupdmgr update” or clicked “download” and then “update” on the update in gnome-software.
The issue is grub and the measurement of the boot chain when booting into Windows.
But if you boot from the UEFI BIOS menu then BitLocker will work in Windows as I understand it.