Event details
114 Comments
Are machines no longer supported by the OEMs going to get the new cert? After running the registry key to set to 0x5944 it goes to in progress but checking the event viewer states the following: The Secure Boot update KEK 2023 was blocked due to a known firmware issue on the device. Check with your device vendor for a firmware update that addresses the issue. This device signature information is included here.
will these devices get updated by microsoft eventually?
IvanCardimMicrosoft
This event indicates that Windows can't apply the KEK 2023 due to a known limitation in the firmware - the new key can only be applied if new firmware is installed.
This can be something else, MS provide a KEK that is refused by the Firmware, but a correct one exist and can be install with a script.
Hi Can you please tell me what is the model of computer ?
I may have a solution for you. :)
Do you have any update regarding VMWARE's issue with PK not being able to allow the SecureBoot certificates to install?
Absolutely interested in an answer to this - please
The 0x4000 "Conditional CA 2023 application" guard bit
The AvailableUpdates registry value includes the bit 0x4000, which we understand acts as a guard bit: a given CA 2023 certificate is only injected into the Active db store if its 2011 equivalent is already present in the Default store.
Two questions on this:
- Is the behavior of this guard bit documented publicly anywhere? We have only been able to infer it from field observation, not from official documentation.
- Is this conditional mode permanent, or is it scheduled to transition to an unconditional mode at a specific date (for example, around or after the June 2026 PCA 2011 expiration)? If so, what is the timeline, and what should administrators expect in terms of behavior change on machines that have not completed the migration by then?
Is documented at
https://support.microsoft.com/en-us/topic/secure-boot-troubleshooting-guide-5d1bf6b4-7972-455a-a421-0184f1e1ed7d#bkmk_availableupdates_bits_used_for_certificate_servicing
Conditional mode is permanent. The third-party certificates are not needed for running Windows, so if the old ones were not there, the new ones would only increase security posture for no good reason.
If, for some reason, you want to get the others too, you can manually run the job without the flag.
Is there a report in intune/Entra that show the state of devices in the fleet for the updated certs?
For Surface devices - the bios update is not a required step - so for surface devices we just need to wait for the udpated certificate to show up?
Also for surface devices, we see 2 options for secureboot - 1. Microsoft only 2. Microsoft & thirdparty CA
Is there any guideline MS gives to select one to get the certificate updated?1 - What's the best way to automate certificate verification across 500+ machines?
2 - How to deal with legacy devices that don't support automatic updates?
3 - What are the best practices for dual-boot environments or VMs?
If using Option 1 in the Playbook to Deploy certificates using Microsoft Intune does this only apply Mitigation 1 and 2? Is Mitigation 3 and 4 applied automatically via enabling the CFR option? If I want to control Mitigation 3 and 4 rollout, I'm guessing I need to deploy the regkeys manually/separately from enabling CFR?
By mitigation 3 and 4 I assume you refer to the SVN update and the revocation of 2011 cert?
No automatic process (CFR or any else) will apply those. You can only apply them by manually setting the required AvailableUpdates flags in registry.
You assumed correctly. Thank you for the response. We will continue to rollout the revocation of 2011 (mitigation 3) cert and SVN update (mitigation 4) manually.
Why do HP state "If your HP Commercial PC is listed as a supported platform, update the BIOS to the minimum version to ensure that the SMBIOS Type1 version field contains the SBKPFV3 substring on Secure Boot-enabled PCs. This substring allows cumulative updates from Microsoft to append the KEK and DB with new certificates throughout 2026." - Is this a string that the Windows OS process is looking for, or something that the BIOS needs in order to accept the update? thanks
- IvanCardim
It is something the Windows OS is looking for - this was coordinated with HP to indicate the firmware supports the operations to be attempted on specific devices.
For devices currently sitting in vendor storage awaiting deployment, do we need to update all of them before June?
For example, if a device remains in storage until the end of the year and is then shipped to a user, would we still be able to update the Secure Boot Certificate by scoping that device into the remediations? Or would the certificate be too far expired at that point to be remediated if the BIOS is up to date?
- IvanCardim
Answered live - when they come out of storage you will still be able to update the certificates.
If I roll out the Intune configuration profile to enable the download of the Secure Boot, would that be sufficient if test cases across our laptop models show promising results?
On test cases across existing computer models in our environment, allowing it to download the latest cert and restart the machines after the task runs shows that most of them are showing the following outputs:
[System.Text.Encoding] : :ASCII.GetSTring( (Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'
True
[System.Text.Encoding] : :ASCII. GetString( (Get-SecureBootUEFI dbx).bytes) -match 'Microsoft Windows Production PCA 2011'
False
Am I missing anything?
