Will MSFT be providing guidance on how to validate the Secure Boot certs on platforms such as RHEL?

Welcome to the Secure Boot AMA! Let's get started. Post your questions here-- our experts are standing by, ready to answer!

Update: Never mind, I was a goof, I was querying the wrong registry key. 

To follow up on asaund28's comment, when I looked at my environment even brand new devices are showing that registry the UEFICA2023Status regkey is NotStarted. Even on brand new devices we've deployed. Does NotStarted also mean the device may not need it? 

or was i querying the wrong registry key?

Hello, 

When reviewing https://support.microsoft.com/en-us/topic/registry-key-updates-for-secure-boot-windows-devices-with-it-managed-updates-a7be69c9-4634-42e1-9ca1-df06f43f360d

Towards the bottom it gets into detail regarding the registry keys and their values. I want to get an idea of what my environment looks like. It states that the WindowsUEFICA2023Capable is not recommended for general use. However, can it be used to query devices in my environment to get an accurate picture of how many devices have the certificate in the DB already? 

Thank you, 

I have a few questions on this:

1.) We have diagnostic data turned on in our intune environment, but I'm not seeing the registry key "MicrosoftUpdateManagedOptIn". Should I be worried about this? If this key does not exist, MS will not push the certificates down, correct?

2.) When will the certificates come down with Windows Updates? Is there a expected month they will be delivered ?

3.) Am I right to say if the "HighConfidenceOptOut" registry key does not exist, this means we have opted in?

4) if the key "WindowsUEFICA2023Capable" is set to 1 instead of 2? This means the device is still not in a "secure state". The key needs to be set to 2?

How will the WinPE boot image (from the ADK) be affected by these changes? If it will be updated, will it continue to work on systems that have not yet installed the updated certificates?

I'm curious when checking to see if the new 2023 certs for Secure Boot get updated, why would we only be checking this cert?  [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match ‘Windows UEFI CA 2023’.  This is the "How to Audit Secure Boot Configuration" portion on this page https://support.microsoft.com/en-us/topic/windows-configuration-system-wincs-apis-for-secure-boot-d3e64aa0-6095-4f8a-b8e4-fbfda254a8fe

Several questions:

1. If the computer manufacturer is not planning on supporting or releasing a BIOS/firmware update to include the new certificate and we have Secure Boot enabled, what happens when the certificate expires in 2026 and we are unable to update it and policy states we are not permitted to disable Secure Boot nor is that feasible across the number of devices?
   
   1. Will the computer no longer boot to Windows?
   2. Computer will still continue to function as normal as it is today?
   3. Can we still reimage the device using SCCM?
2. If we apply the 0x5944 registry value on updateable systems, are we still able to network boot them with our existing WinPE to image them with SCCM?
   1. If WinPE needs updating, which version of the Windows 11 ADK/WinPE add-on will include the updated certificate or is this a manual process?
      1. If this is a manual process to update WinPE/WDS/SCCM, what is the MS supported documented process for doing so?
   2. Somewhere I read indicated that it wasn't WinPE that needs updating but the SCCM RemoteInstall boot files needs updating, but not sure where to get the required files containing the new certs to update WDS/SCCM or how to do so in a supported manner across multiple DPs.
3. If we update the WinPE or WDS/SCCM files to support the new certificate, does that mean only the devices that got the new certificate will be network bootable for reimaging with SCCM and those devices that did not get the certificate will stop imaging or will both be supported and working?
   1. Our SCCM needs to support imaging of devices both with the new certificate and those older vendor unsupported devices that aren't getting the firmware updates. This should not include deploying any additional WDS/DP servers for supporting these hardware.

• If we are deploying the AvailableUpdates 0x00005944 registry value (either directly or indirectly via admx / AvailableUpdatesPolicy) and everything applies successfully, leaving (as stated in the IT Pro guidance) just the 0x00004000 "modifier" for the potential Microsoft Corporation UEFI CA 2023 and Microsoft Option ROM UEFI CA 2023 cert installation - how important is it that that value stays at 0x00004000 after the process is done? For example, if, months later, we want to take the extra step of adding the Microsoft Windows Production PCA 2011 cert to the DBX (BlackLotus mitigation), which requires setting AvailableUpdates to 0x00000080, after which it would end up back to 0x0. Does it matter?
• If the addition of the Microsoft Corporation KEK 2K CA 2023 cert is being denied and a BIOS update is not available from the OEM, is it possible that it will start working over the next few months without a BIOS update needed as a result of an update to KEKUpdateCombined.bin via monthly Windows Update?
• Will any devices that have the same Platform Key behave the same in terms of accepting / denying the new KEK cert update, irrespective of BIOS version?
• Our main OEM, Lenovo, has said they will provide BIOS updates for all commercially supported devices. For Lenovo that support period is about 6 1/2 years after release, meaning there are several generations of devices out there that still meet all the requirements for Win 11 (including CPU minimum) but possibly won't be able to take the updated KEK cert? What will happen to those devices after June 2026? If they cannot sign updates to the DB and DBX, what is the implication? Will regular Windows Cumulative Updates fail to install if they have a DB or DBX update piece?

Is it true that Hyper-V Gen 1 VMs are not affected by this issue?