Found I also had to go into registry and manually set HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\AvailableUpdates to hex: 5944, then reboot twice. A scheduled task then did the rest. Now Windows Security shows that Secure Boot has been updated and no other changes need to be made.
Secure boot is using an older boot trust configuration even though I updated firmware and reset security keys
I have a PC with an Asus motherboard. I updated the BIOS to the most recent version, which had the updated certs for Secure Boot. Following the BIOS update I then went into the BIOS to Secure Boot and reset factory keys to factory default. Once Windows started up, I went to Powershell and ran:
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbdefault).bytes) -match 'Windows UEFI CA 2023'
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI KEK).Bytes) -match 'Microsoft Corporation KEK 2K CA 2023'
and got 'true' to each of the above.
Yet when I go to Windows Security > Device Security > Secure boot, it shows:
"Secure boot is on, but your device is using an older boot trust configuration that should be updated. There is not yet enough data to classify your device for automatic update."
Is this just a misleading message? I'm wondering if the message is only referring to secure boot updates deployed via Windows Update.
I just don't understand why Powershell is showing that it sees the new certs, but Windows Security itself doesn't see them.
Windows for home | Windows 11 | Security and privacy
1 additional answer
Sort by: Most helpful
-
Thomas4-N 22,050 Reputation points Microsoft External Staff Moderator
2026-06-20T10:08:59.42+00:00 Hello Sir Timbit,
Thanks for circling back and posting your fix. Your read was on the right track, and what you landed on lines up with how the rollout actually applies:
- The PowerShell checks confirm the certs are physically present in db/KEK, but Windows Security reports the rollout/servicing state separately — which is why the two looked like they disagreed.
- Setting
HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\AvailableUpdatesto0x5944is the documented trigger that tells the scheduled Secure-Boot servicing task to actually apply the 2023 DB/KEK updates — and it works across a couple of reboots, exactly as you saw. So that last step is what flipped Windows Security over to "updated."
On your earlier worry about resetting the Secure Boot keys — since you're now showing fully updated and booting normally, you're in a good spot, nothing else to undo.
Glad it's sorted, and thanks again for sharing the registry detail.