Interpreting the script outputs

[cjee21]

Check UEFI PK, KEK, DB and DBX.cmd

The purpose of this script is to check the contents of the PK, KEK, DB and DBX UEFI variables.

For the PK, KEK and DB sections, certificates that are present will be indicated by a green checkmark while certificates that are known but not present will be indicated by a red cross. (revoked: True) at the end of a cert that is present indicates that that cert is found in the DBX as well which means it is effectively revoked. The green check marks and red crosses do not mean good and bad but merely indicates whether a cert is present.

A Windows-only PC with the most secure configuration may have an output similar to the following:

Current UEFI KEK
√ Microsoft Corporation KEK CA 2011 (revoked: False)
√ Microsoft Corporation KEK 2K CA 2023 (revoked: False)                                                                                                                                                                                        

Current UEFI DB
√ Microsoft Windows Production PCA 2011 (revoked: True)
X Microsoft Corporation UEFI CA 2011
√ Windows UEFI CA 2023 (revoked: False)
X Microsoft UEFI CA 2023
X Microsoft Option ROM UEFI CA 2023

or the following:

Current UEFI KEK
√ Microsoft Corporation KEK CA 2011 (revoked: False)
√ Microsoft Corporation KEK 2K CA 2023 (revoked: False)                                                                                                                                                                                         

Current UEFI DB
X Microsoft Windows Production PCA 2011
X Microsoft Corporation UEFI CA 2011
√ Windows UEFI CA 2023 (revoked: False)
X Microsoft UEFI CA 2023
X Microsoft Option ROM UEFI CA 2023

The 'Default' variables indicate which cert the system ships with and is useful for knowing what would happen if you reset the UEFI Secure Boot variables to default in the UEFI setup. Not all systems expose these 'default' variables. Default variables can only be updated by UEFI updates from the device manufacturer.

For the DBX section, the script checks if the current DBX content matches the latest DBX update file from Microsoft. It also checks if the SVNs that are in the DBX are equal or higher than the values publicly published by Microsoft as the latest.

For a PC that is secure and completely up-to-date, all values will be shown in green as follows:

SUCCESS: 431 successes detected indicates the result of comparing the DBX contents with the DBX update bin file provided by Microsoft. In this case, all 431 entries from the October 2025 patch Tuesday are successfully updated in the DBX.

Check Windows state.cmd

The purpose of this script is to check the current state of the specific Windows installation in regards to Secure Boot related items especially regarding the migration to 2023 signed boot manager. The first section checks the registry keys while below it, the version, signature cert issuer CA and SVN of Windows Boot Manager (bootmgfw.efi EFI Application and bootmgr.efi Windows Boot Application) located in the EFI System Partition are checked and displayed.

An up-to-date system that has completed the migration to 2023 certs and boot manager automatically via Windows Update from January 2026 onwards should have an output similar to the following:

Windows version: 25H2 (Build 26200.8037)

UEFISecureBootEnabled    : 1
AvailableUpdates         : 0x0000
UEFICA2023Status         : Updated
WindowsUEFICA2023Capable : Windows UEFI CA 2023 cert is in DB, system is starting from 2023 signed boot manager

bootmgfw version         : 10.0.26100.30227 (WinBuild.160101.0800)
bootmgfw raw version     : 10.0.28000.317
bootmgfw signature CA    : Windows UEFI CA 2023
bootmgfw SVN             : 7.0

bootmgr version          : 10.0.26100.30227 (WinBuild.160101.0800)
bootmgr raw version      : 10.0.28000.317
bootmgr signature CA     : Microsoft Windows Production PCA 2011
bootmgr SVN              : 7.0

memtest version          : 10.0.26100.1 (WinBuild.160101.0800)
memtest raw version      : 10.0.26100.7920
memtest signature CA     : Microsoft Windows Production PCA 2011

Only the bootmgfw.efi need to be signed with a cert issued by Windows UEFI CA 2023 as this is the EFI Application that is directly loaded by the UEFI. The other two EFI files are Windows Boot Applications that are not directly loadable by the UEFI. One should ensure that the bootmgfw signature CA is Windows UEFI CA 2023 before revoking the Windows Production PCA 2011 and that the SVNs are the latest before attempting to update the Bootmgr SVN in the DBX to the latest.

[algymc]

AvailableUpdates : 0x4000

Why above non-zero if on...

An up-to-date system that has completed the migration to 2023 certs and boot manager following Microsoft's procedure

do you think?

[cjee21]

AvailableUpdates : 0x4000

Why above non-zero if on...

An up-to-date system that has completed the migration to 2023 certs and boot manager following Microsoft's procedure

do you think?

According to Microsoft documentation:

If bit 0x4000 is set, it will not be cleared. After all other bits have been processed, the AvailableUpdates registry key will be set to 0x4000.

Bit 0x4000 is set in 0x5944. If we look at the table in readme, we will understand the reason. That bit controls the behaviour of the update and is not a pending update to be done that the other bits are.

[LRSFC-DanJ]

Are there versions of these scripts that are suitable for use in automated patch management systems? These look great but seem very manual, if I've got 1800+ endpoints I need to check for this issue then I don't have time to go round to each and every one and run this script manually, I need something that can produce machine readable output and then another script that can do necessary remediation based on the previously provided state information. Does that exist?

[cjee21]

Are there versions of these scripts that are suitable for use in automated patch management systems?

These scripts are meant to be user-friendly for people who are not familiar or do not want to deal with running scripts and are only designed for human-readable output. If you want scripting/automation use, look for Microsoft's official scripts or you may have to make your own. Windows actually has built-in checks/features that can be used for managing endpoints in large organizations in terms of deploying 2023 certs. You may not need to check manually all the items checked by the scripts here. The scripts here were made before Windows started having features for managing 2023 cert deployment and are not meant for this purpose only. For checking DBX, you may directly use Check-Dbx-Simplified.ps1 for automation use.

You may also refer to https://techcommunity.microsoft.com/event/windowsevents/ask-microsoft-anything-secure-boot/4486023 for answers to some of the questions you may have that are not in Microsoft's existing documentations.

[mikep12]

Hi,
while investigating my UEFI cert update problems I found your very helpful scripts
I'm still trying to wrap my head around this and I'd be glad if you have some ideas.

Problem: Systems are showing TPM-WMI event 1801: Certificates available but not applied yet...
I'm using MS registry key AvailableUpdates set to 0x5944 to start the automatic update process. After triggering the scheduled task I get event 1800: Before installation of the update for secure boot a reboot is required. Cause: Boot Manager (2023).

All of this is expected.

After the reboot the state of AvailableUpdates changes to 0x4100, UEFICA2023Status changes to InProgress and stays like this whatever I do. I continue to get event 1801 every time the scheduled task runs. Add'l reboots do not help. The system BIOS is the latest available.

"Check UEFI PK, KEK, DB and DBX.cmd"

Manufacturer: Dell Inc. 
Model: Dell Pro Micro QCM1250 
BIOS: Dell Inc., 1.12.2, 1.12.2, DELL   - 2 
Windows version: 24H2 (Build 26100.7840)                                                                                                        
Detected x64 UEFI architecture. Ensure that this is correct for valid DBX results.

Secure Boot status: Enabled

Current UEFI PK
√ Dell Inc. Platform Key

Default UEFI PK
√ Dell Inc. Platform Key

Current UEFI KEK
√ Microsoft Corporation KEK CA 2011 (revoked: False)
√ Microsoft Corporation KEK 2K CA 2023 (revoked: False)
√ Dell Inc. Key Exchange Key
√ Dell Inc. Key Exchange Key

Default UEFI KEK
√ Microsoft Corporation KEK CA 2011 (revoked: False)
√ Microsoft Corporation KEK 2K CA 2023 (revoked: False)
√ Dell Inc. Key Exchange Key
√ Dell Inc. Key Exchange Key

Current UEFI DB
√ Microsoft Windows Production PCA 2011 (revoked: False)
√ Microsoft Corporation UEFI CA 2011 (revoked: False)
√ Windows UEFI CA 2023 (revoked: False)
√ Microsoft UEFI CA 2023 (revoked: False)
√ Microsoft Option ROM UEFI CA 2023 (revoked: False)
√ Dell Bios DB Key
√ Dell Bios FW Aux Authority 2018

Default UEFI DB
√ Microsoft Windows Production PCA 2011 (revoked: False)
√ Microsoft Corporation UEFI CA 2011 (revoked: False)
√ Windows UEFI CA 2023 (revoked: False)
√ Microsoft UEFI CA 2023 (revoked: False)
√ Microsoft Option ROM UEFI CA 2023 (revoked: False)
√ Dell Bios DB Key
√ Dell Bios FW Aux Authority 2018

Current UEFI DBX
2025-10-14 (v1.6.0) [x64]   : SUCCESS: 431 successes detected
Windows Bootmgr SVN         : None
Windows cdboot SVN          : None
Windows wdsmgfw SVN         : None

Not sure I understand what the last 3 lines mean.

"Check Windows state.cmd"

Checking for Administrator permission...
Running as administrator - continuing execution...

Windows version: 24H2 (Build 26100.7840)

UEFISecureBootEnabled    : 1
AvailableUpdates         : 0x4100
UEFICA2023Status         : InProgress
WindowsUEFICA2023Capable : Windows UEFI CA 2023 cert is in DB

Get-BootMgrSecurityVersionBytes : Resource 'BOOTMGRSECURITYVERSIONNUMBER' not found in the file.
In C:\x\ps\Check Windows state.ps1:64 Zeichen:23
+ ... SVN_bytes = Get-BootMgrSecurityVersionBytes -Path S:\EFI\Microsoft\Bo ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
    + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Get-BootMgrSecurityVersionBytes

bootmgfw version         :
bootmgfw signature CA    : Microsoft Corporation UEFI CA 2011
Get-SVNfromBytes : Das Argument kann nicht an den Parameter "SVN_bytes" gebunden werden, da es NULL ist.
In C:\x\ps\Check Windows state.ps1:78 Zeichen:38
+ $bootmgfw_svn_ver = Get-SVNfromBytes $bootmgfw_SVN_bytes
+                                      ~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidData: (:) [Get-SVNfromBytes], ParameterBindingValidationException
    + FullyQualifiedErrorId : ParameterArgumentValidationErrorNullNotAllowed,Get-SVNfromBytes

bootmgfw SVN             :

bootmgr version          : 10.0.26100.30227 (WinBuild.160101.0800)
bootmgr signature CA     : Microsoft Windows Production PCA 2011
bootmgr SVN              : 7.0

memtest version          : 10.0.26100.1 (WinBuild.160101.0800)
memtest signature CA     : Microsoft Windows Production PCA 2011

Does that mean the bootloader hasn't been updated yet? But why...

Thanks
Michael

[cjee21]

@mikep12 something unusual with your bootmgfw as Check Windows state.cmd cannot get the version and SVN. The signing cert is also not expected: bootmgfw signature CA : Microsoft Corporation UEFI CA 2011 (this cert is for third party boot loaders). To find out more, I suggest you run the following commands as administrator to extract the bootmgfw for inspection.

mountvol s: /s
copy S:\EFI\Microsoft\Boot\bootmgfw.efi C:\Users\<username>\Desktop\
mountvol s: /d

Then right click the bootmgfw.efi that is copied to the desktop or another folder that you choose and properties to check the digital signatures. Then you can use Check EFI file info.cmd from this repository to inspect it too.

Also try the just updated Check Windows state.cmd which now shows more version information.

[mikep12]

@cjee21 Thanks for the quick reply. The modified Check Windows state.cmd gave the same results to me.
I copied the bootmgfw.efi from S: and checked with your script. Here's the output. It looks completely crippled, still its using this thing as a working bootloader says bcdedit /enum:

Path to EFI file: C:\Check-UEFISecureBootVariables-main\bootmgfw.efi


FilePath         : C:\Check-UEFISecureBootVariables-main\bootmgfw.efi
Machine          : x64
Subsystem        : EFI Application
SubsystemVersion : 1.0



File Information:


OriginalFilename  :
FileDescription   :
ProductName       :
Comments          :
CompanyName       :
FileName          : C:\Check-UEFISecureBootVariables-main\bootmgfw.efi
FileVersion       :
ProductVersion    :
IsDebug           : False
IsPatched         : False
IsPreRelease      : False
IsPrivateBuild    : False
IsSpecialBuild    : False
Language          :
LegalCopyright    :
LegalTrademarks   :
PrivateBuild      :
SpecialBuild      :
FileVersionRaw    : 0.0.0.0
ProductVersionRaw : 0.0.0.0



Authenticode SHA256: B98F468EAD35521DEEB0CE343FEC4E5835F1C7C5DDCB9C77C1B646A0AB040D1B



Signature Certificate(s):


Subject      : CN=Microsoft Windows UEFI Driver Publisher, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
Issuer       : CN=Microsoft Corporation UEFI CA 2011, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
Thumbprint   : 767A4EA7C333661BB9401C174662E24BE3DEE9BA
FriendlyName :
NotBefore    : 19.10.2023 21:53:24
NotAfter     : 16.10.2024 21:53:24
Extensions   : {System.Security.Cryptography.Oid, System.Security.Cryptography.Oid, System.Security.Cryptography.Oid,
               System.Security.Cryptography.Oid...}

bcdedit /enum

Windows-Start-Manager
---------------------
Bezeichner              {bootmgr}
device                  partition=\Device\HarddiskVolume1
path                    \EFI\Microsoft\Boot\bootmgfw.efi
description             Windows Boot Manager
locale                  de-DE
inherit                 {globalsettings}
default                 {current}
resumeobject            {38a7b090-0d6c-11f1-beb2-4ccf7cbb41bb}
displayorder            {current}
toolsdisplayorder       {memdiag}
timeout                 30

I'll have to find out where this boot loader comes from. Doesn't look like Microsoft's and its small (620 kB only).
Could be installed by Check Points FDE, but all systems are using it so why are some affected, others are not.

[cjee21]

CN=Microsoft Windows UEFI Driver Publisher

Ya it's from third party which asked Microsoft to sign.

NotAfter : 16.10.2024 21:53:24

and old too.

[mikep12]

So thats the reason why Microsoft's update process won't replace it, I guess. Fun...

[cjee21]

Could be installed by Check Points FDE, but all systems are using it so why are some affected, others are not.

@mikep12 Looks like it may really be Check Point FDE...

Note: When FDE is in BOOTMGFW mode, a file is replaced on the EFI System Partition (ESP) that will invoke the FDE's Preboot loader and OS, which then chainload Windows after a successful authentication.

We have seen issues with this feature in the past and certain Windows Updates that interfere with this approach. That is why we introduced the alternative BCDBOOT feature, which relies on bootstrapping via Windows BCD store instead. This is the recommended way from Microsoft.

The only problem with using the BCD store is that we have seen firmware (HP, Dell, Lenovo, etc.) that do not honor third party bootloaders in the UEFI environment. However, we are working actively with all major UEFI-firmware vendors to make them aware of this problem.

https://support.checkpoint.com/results/sk/sk120667

[mikep12]

@cjee21 Thanks for the Check Point link. Yes, sounds promising. But the version we're using is 88.xx (we started with it so no history of updates) and it should use BCDBOOT everywhere.

I confirmed that by running fdecontrol.exe on affected and non-affected systems, all show BCDBOOT. But that contradicts the findings of a foreign bootmgfw.efi in the EFI partition, probably installed by Check Point... oh what a mess. Again, thanks for all your help!

[mikep12]

In the meantime I expect all systems are affected by this... urgent need for a long vacation far far away from here...