Microsoft is currently rolling out an update to Secure Boot keys that are set to expire this year. The update appears in Windows Update as "Secure Boot Allowed Key Exchange Key (KEK) Update." While the process is designed to be seamless for most users, a specific interaction with your motherboard's UEFI Fast Boot feature can cause noticeably longer startup times — and understanding why this happens is the first step to resolving it.
What Is the KEK Update and Why Does It Matter
Secure Boot is a UEFI feature designed to ensure that only trusted software loads during system startup. The Key Exchange Key (KEK) is part of the certificate chain that validates the integrity of boot components. Microsoft's current rollout updates these certificates because the existing ones are approaching expiration.
According to Microsoft, certain system updates — such as updates to the Windows Recovery Environment (WinRE) — cannot be delivered to machines with expired Secure Boot certificates. This makes applying the KEK update a functional prerequisite for continued system security and update eligibility, not just a routine maintenance task.
After the update is downloaded, the PC's UEFI firmware needs to re-validate the new key signatures. This re-validation step occurs at the firmware level, before the operating system loads — and this is where Fast Boot can become a complicating factor.
UEFI Fast Boot vs. Windows Fast Startup: A Critical Distinction
A common source of confusion in discussions around this update involves two features that share similar names but operate at entirely different layers of the system.
| Feature | Location | Function |
|---|---|---|
| Fast Boot | UEFI/BIOS firmware settings | Skips hardware initialization checks during POST to reduce time before OS handoff |
| Fast Startup | Windows power settings | Saves a hibernation-like system state on shutdown to speed up the next Windows load |
The issue described in this article is specific to UEFI Fast Boot. Adjusting or disabling Windows Fast Startup will have no effect on this particular problem. When troubleshooting, it is important to navigate to the correct setting in the UEFI/BIOS interface, not in Windows power options.
How UEFI Fast Boot Can Interfere with Key Validation
When UEFI Fast Boot is enabled, the firmware skips or abbreviates portions of the Power-On Self-Test (POST) process to reduce boot time. In some configurations, this abbreviated process may prevent the full Secure Boot key re-validation from completing after the KEK update is applied.
The result is that the system repeatedly attempts the validation on every startup without successfully completing it. The observable symptom is that the boot logo appears more slowly than usual, or remains on screen for an extended period — even across multiple restarts. This can ironically make startup times longer than before, despite Fast Boot being enabled.
This behavior has been observed particularly on DIY desktop builds, where motherboard firmware configurations vary widely. Laptops and pre-built systems tend to handle the process more consistently. Users with MSI and ASUS motherboards, among others, have reported encountering this situation depending on their specific firmware version and configuration.
How to Resolve the Slow Boot Issue
There are two primary approaches that have been found to allow the re-validation process to complete successfully.
- Cut main power to the system. Switching off the power supply's rear switch or unplugging the PC from the wall causes the motherboard to perform a full cold boot on the next startup. This bypasses the Fast Boot shortcut and allows the UEFI to complete the key signature validation. This is considered the simpler option as it requires no settings changes.
- Disable UEFI Fast Boot temporarily. Entering the BIOS/UEFI settings and disabling the Fast Boot option allows the next boot cycle to perform a full POST, during which the validation can complete. Fast Boot can be re-enabled afterward without issue.
It is worth noting that a standard Windows restart does not achieve the same result as cutting main power. The difference between restart and shutdown is a Windows-level behavior (related to Fast Startup), while this issue originates at the firmware level before Windows is involved at all.
How to Verify Whether Your Update Applied Successfully
Users who want to confirm whether the Secure Boot certificate update has been successfully applied to their firmware can run the following command in an elevated PowerShell session:
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023')If the output returns True, the updated certificate is present in the firmware and the process has completed successfully. If it returns False, the update has not yet been applied to the UEFI, and one of the resolution methods above may be necessary.
Some users have also reported seeing a Windows notification indicating: "Updated Secure Boot certificates are available on this device but have not yet been applied to the firmware." This message confirms a pending state and suggests that a full cold boot or BIOS update from the motherboard manufacturer may be required to proceed.
Do You Also Need a BIOS Update
For most users who receive the Windows KEK update, no separate BIOS or UEFI firmware update from the motherboard manufacturer should be required. The Windows update is designed to interface with the UEFI and apply the certificate changes automatically in the background.
However, eligibility for the Windows update depends on the system's current configuration. Users who do not receive the update through Windows Update may find that a BIOS update from their motherboard manufacturer is a prerequisite. In some cases — particularly with older or less frequently updated motherboards — manufacturer firmware support may be limited or absent.
Users with pre-built systems using rebranded retail mainboards should check both the system manufacturer's support page and the underlying motherboard manufacturer's page to determine whether applicable firmware updates exist.
Implications for Linux and Dual-Boot Configurations
For systems running only Linux, the certificate expiration is generally less likely to cause functional disruption, as Linux distributions do not enforce the same security posture around expired Secure Boot certificates during the boot process. Existing installations are expected to continue booting and receiving updates.
However, dual-boot configurations running both Windows and Linux introduce additional complexity. Because Windows requires valid Secure Boot certificates for certain update categories, and because the shared bootloader environment is involved, users in this configuration may need to take additional steps. The specific impact on bootloader updates in dual-boot environments is an area that warrants attention as the rollout continues.
Users in dual-boot setups are advised to monitor guidance from both Microsoft and their Linux distribution for any updates specifically addressing this scenario.
Post a Comment