Repository navigation
Interpreting the script outputs #13
Description
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 without Option ROMs or discrete GPU with the most secure configuration may have an output similar to the following:
Current UEFI PK
√ Windows OEM Devices PK
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 PK
√ Windows OEM Devices PK
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 the current UEFI DBX variable's content.
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. The SVNs present in the current DBX is checked with both the publicly known version as well as the version staged in the current Windows. It will be red if it is older than any of those versions. Statistics line shows the statistics of the current DBX contents.
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. The staged SVNs, which are the SVNs that Windows will apply to the UEFI DBX if triggered, are also shown below.
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.8246)
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.28000.322 (WinBuild.160101.0800)
bootmgfw raw version : 10.0.28000.322
bootmgfw signature CA : Windows UEFI CA 2023
bootmgfw SVN : 8.0
bootmgr version : 10.0.28000.322 (WinBuild.160101.0800)
bootmgr raw version : 10.0.28000.322
bootmgr signature CA : Microsoft Windows Production PCA 2011
bootmgr SVN : 8.0
memtest version : 10.0.26100.1 (WinBuild.160101.0800)
memtest raw version : 10.0.26100.8115
memtest signature CA : Microsoft Windows Production PCA 2011
Staged BootMgr SVN : 8.0
Staged CDBoot SVN : 3.0
Staged WDSMgFw SVN : 3.0
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 equal or greater than the staged BootMgr SVN before attempting to update the BootMgr SVN in the DBX.
Activity
algymc commentedon Dec 14, 2025
Why above non-zero if on...
do you think?
cjee21 commentedon Dec 14, 2025
According to Microsoft documentation:
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 commentedon Feb 6, 2026
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 commentedon Feb 6, 2026
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 commentedon Mar 19, 2026
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"
Not sure I understand what the last 3 lines mean.
"Check Windows state.cmd"
Does that mean the bootloader hasn't been updated yet? But why...
Thanks
Michael
cjee21 commentedon Mar 19, 2026
@mikep12 something unusual with your bootmgfw as
Check Windows state.cmdcannot 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.Then right click the
bootmgfw.efithat is copied to the desktop or another folder that you choose and properties to check the digital signatures. Then you can useCheck EFI file info.cmdfrom this repository to inspect it too.Also try the just updated
Check Windows state.cmdwhich now shows more version information.mikep12 commentedon Mar 19, 2026
@cjee21 Thanks for the quick reply. The modified
Check Windows state.cmdgave the same results to me.I copied the
bootmgfw.efifrom S: and checked with your script. Here's the output. It looks completely crippled, still its using this thing as a working bootloader saysbcdedit /enum:bcdedit /enum
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 commentedon Mar 19, 2026
Ya it's from third party which asked Microsoft to sign.
and old too.
mikep12 commentedon Mar 19, 2026
So thats the reason why Microsoft's update process won't replace it, I guess. Fun...
cjee21 commentedon Mar 19, 2026
@mikep12 Looks like it may really be Check Point FDE...
https://support.checkpoint.com/results/sk/sk120667
mikep12 commentedon Mar 20, 2026
@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 commentedon Mar 20, 2026
In the meantime I expect all systems are affected by this... urgent need for a long vacation far far away from here...
cjee21 commentedon Apr 6, 2026
FYI There is now a Dump-SecureBootData script that will save Secure Boot related data to an XML file. This may be useful to gather data from multiple systems to be analyzed later.