Event details
Concerned about the inconsistent registry values we are seeing. In the Secure Boot Playbook, it mentions that the device should have a key of UEFI2023Status set to Updated if the device has been through the process. We have a high number of machines that don't have this but the value for WindowsUEFICA2023Capable is set to 2.
I cannot tell from experience here, but from the documentation of these keys I would assume this would happen if the original AvailableUpdates value included the 0x0004 bit and it is still there (i.e. it ended with 0x4004 or 0x0004), because there is no KEK update available for the machine's platform key. UEFI2023Status is (correct me if I am wrong) tracking KEK updates, but WindowsUEFICA2023Capable is not (it is only tracking DB and boot manager updates).
Can you share from one such machine:
- initial value of AvailableUpdates (as you set it)
- current value of AvailableUpdates
- Which related event IDs you are seeing in event log
In case the situation points to KEK, you might also want to check the contents of the KEK variable and the thumbprint of the platform key.
- Arden_White
Microsoft
mihi, I think you're right. If AvailableUpdates started at 0x5944 and is now 0x4004, that would indicate that a PK signed KEK from the OEM isn't yet available. There is an ongoing effort to work with the OEMs to fill in as many PK signed KEKs as possible.
A device with setting 0x4004 will continue retrying to apply the KEK until one shows up, which is okay. I believe it'll also emit an 1803 event each time it doesn't find one.
- Arden_White
UEFI2023Status and WindowsUEFICA2023Capable serve related but different purposes.
- WindowsUEFICA2023Capable was originally created to help validate the move to the 2023 signed boot manager. This was needed so the 2011 certificate authority (CA) that signs the older boot manager could be added to the DBX, which prevents 2011 signed boot managers from being trusted. This key only indicates that the 2023 CA used to sign the boot manager is present, and that the device is running the 2023 signed boot manager. When both conditions are true, the system can safely add the 2011 CA to the DBX. The primary purpose of this key is to help protect against boot manager rollback attacks.
- UEFI2023Status goes further. It accounts for the presence of the 2023 CA, the 2023 signed boot manager, the updated KEK (Key Exchange Key), and the third party CA certificates when those are required. When all of the new Secure Boot certificates and the 2023 signed boot manager are in place, this key reports “Updated.” Its primary purpose is to confirm that the device has the full set of updated certificates from Microsoft along with the correct boot manager in use.
More details on these registry keys can be found on
Registry key updates for Secure Boot: Windows devices with IT-managed updates
