Event details
- Do not use WindowsUEFICA2023Capable for determining anything
- UEFICA2023Status will track boot manager as well as DB and KEK contents. It will not track SVN and 2011 certificate revocation in DBX, nor does it track SBAT status. Those are triggered by AvailableUpdate flags 0x200, 0x80 and 0x400, and they are not included in the suggested AvailableUpdates flags, as they are not required to keep all components of Secure Boot servicable by Microsoft. They are recommended to harden against certain targeted attacks, but if you go that route be aware that you may need to recreate all boot media created before July 2025 as well as all that still contain the 2011 signed bootloader or they won't boot without disabling Secure Boot
- There are two bootmgfw.efi in Windows directory, one in C:\Windows\Boot\EFI and one in C:\Windows\Boot\EFI_EX. They are expected to be 2011-signed and 2023-signed, respectively, and are no indication which one got installed to your ESP
- I am not aware of a broken Get-SecureBootSVN cmdlet. To check the SVN manually (for bootmgfw.efi) you can run this:
Get-SecureBootUEFI dbx -decoded | Where-Object {$_.Hash.StartsWith("01612B139DD5598843AB1C185C3CB2EB92") }The resulting hash will, after the shown prefix, have a bunch of zeros, then the SVN as a hex digit, then another bunch of zeros. If no hash is shown, no SVN is recorded and the SVN is therefore 0.
Thank you mihi for clarifying that SVN (Secure Version Number), along with SBAT (Secure Boot Advanced Targeting) and the revocation of the 2011 certificate via DBX, are optional hardening measures that improve security posture but are not required or part of the current Secure Boot certificate update process. As you explained, applying these is currently a manual process that requires careful planning and testing and should not be rushed. An SVN value of 0 is therefore expected on machines that have only completed the mandatory certificate update steps, and I can confirm this is what we observe both via the Get-SecureBootSVN cmdlet and the manual PowerShell command you gave me.
Regarding my original question, I conclude that having UEFICA2023Status = Updated is a reliable way to confirm that the certificate update process completed successfully, meaning all required certificates are in place and the boot manager has been updated to one signed by the new CA, so once the 2011 certificates expire, Secure Boot will continue to function without issues.
Furthermore, as trevorjones pointed out, even if UEFICA2023Status does not yet show Updated, the process may still be complete, but this requires manual verification of the individual components: Windows UEFI CA 2023 and KEK 2023 present in the UEFI variables, and the boot manager on the EFI System Partition signed by the new certificate.