Solved garlin's PowerShell scripts for updating Secure Boot CA 2023

VERBOSE: Perform operation 'Enumerate CimInstances' with following parameters, ''className' = Win32_ComputerSystem,'namespaceName' = root\cimv2'.
VERBOSE: Operation 'Enumerate CimInstances' complete.
InvalidOperation: C:\Users\Public\Public Scripts\SecureBoot-Scripts\SecureBoot-CA-2023-Latest\Update_UEFI-CA2023.ps1:1749
Line |
1749 | '*LENOVO*M700*' { $Unsafe_Model = $true }
| ~~~~~~~~~~~~~~~
| The regular expression pattern *LENOVO*M700* is not valid.
VERBOSE: Perform operation 'Enumerate CimInstances' with following parameters, ''className' = Win32_OperatingSystem,'namespaceName' = root\cimv2'.
VERBOSE: Operation 'Enumerate CimInstances' complete.
VERBOSE: Perform operation 'Enumerate CimInstances' with following parameters, ''className' = Win32_DeviceGuard,'namespaceName' = root\Microsoft\Windows\DeviceGuard'.
VERBOSE: Operation 'Enumerate CimInstances' complete.
VERBOSE: Firmware SVN (from DBX): 9.0
VERBOSE: Using specified boot manager: \\.\HarddiskVolume1\EFI\Microsoft\Boot\bootmgfw.efi
VERBOSE: Boot Manager SVN: 9.0
VERBOSE: Staged SVN: 9.0
VERBOSE: Compliance Status: Compliant (Boot Manager SVN meets staged SVN)
Successfully appended "DBUpdateOROM2023.bin" to UEFI DB.
Get-ItemPropertyValue: C:\Users\Public\Public Scripts\SecureBoot-Scripts\SecureBoot-CA-2023-Latest\Update_UEFI-CA2023.ps1:1547
Line |
1547 | … Integrity = Get-ItemPropertyValue -Path 'HKLM:\Software\Policies\Micr …
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Property HypervisorEnforcedCodeIntegrity does not exist at path HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\DeviceGuard.
Applying SBAT update for Linux.

REQUIRED ACTION
---------------
Restart Windows, for UEFI updates to take effect.

PS C:\Users\Public\Public Scripts\SecureBoot-Scripts\SecureBoot-CA-2023-Latest>

From my 2025 Asus Rog Strix G16

Asus272 said:

InvalidOperation: C:\Users\Public\Public Scripts\SecureBoot-Scripts\SecureBoot-CA-2023-Latest\Update_UEFI-CA2023.ps1:1749
Line |
1749 | '*LENOVO*M700*' { $Unsafe_Model = $true }
| ~~~~~~~~~~~~~~~
| The regular expression pattern *LENOVO*M700* is not valid.

Click to expand...

This is a known bug (but doesn't impact the script).

Asus272 said:

Get-ItemPropertyValue: C:\Users\Public\Public Scripts\SecureBoot-Scripts\SecureBoot-CA-2023-Latest\Update_UEFI-CA2023.ps1:1547
Line |
1547 | … Integrity = Get-ItemPropertyValue -Path 'HKLM:\Software\Policies\Micr …
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Property HypervisorEnforcedCodeIntegrity does not exist at path HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\DeviceGuard.

Click to expand...

Some instances of Get-ItemPropertyValue don't ignore an error when a queried reg key doesn't exist on the system. I'll add another fix.
Thanks.

Thank you for your all your help and scripts. I've successfully updated a 2013 Dell 8700 and two 2018 Intel Nucs 8i5 & 8i7 to 2023 Windows certs. I used your CA2023 update script to obtain new certs from github. No issues with any of them. Intel Nucs have Intel Visual Bios which is the best example of a GUI bios that I've ever seen.

For your information: yesterday I checked the laptop of a friend, a Lenovo E595 thinkpad (20NF0000GE), bought in Jan 2020, and happily I can say it received the new secure boot certificates automatically. Using the Garlin scripts I checked and everything was fine.

Having read this article <Microsoft admits it can't fix Windows 11 Secure Boot problems, and older PCs are hit hardest> the updates of the secure boot certificates are a true mess, and the MS and the OEM's dropped the ball completely on this one. Hence, a big thank you to Garlin for his continued support and scripts. Much appreciated.

UPDATE: 2026-07-24

1. Check for presence and correct version of \EFI\Microsoft\Boot\boot.stl on removable media
2. Check Macrium WinRE and Hasleo WADK staging folders for the correct Windows boot manager
3. Add Samsung 300E4C/300E5C/300E7C to the unsafe list
4. Exception created when "HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\DeviceGuard" is missing

After the June 2026 CU, MS recommends a current version of boot.stl be copied to your boot media. The check script will inform you when boot.stl is missing, or the wrong version. Update-UEFI.bat -BootMedia will push the boot.stl if required.

If you're using Macrium or Hasleo backup software, "-BootMedia" will now check the boot file versions in the app's WinPE or WinRE cache folders. This provides a clue if you're about to make a new recovery USB drive that may be banned from booting. Typically it's because the cache folder has an outdated version of WinPE or WinRE.

In the different Macrium or Hasleo threads, there's some discussion about manually copying the latest version of bootmgfw.efi or bootx64.efi into the cache folders, so you don't have to wait for Macrium or Hasleo to catch up.

Fixed the dreaded "Lenovo M700" reporting bug. As I didn't have the actual model string, I had to guess what it might looked on a real M700. But I found different M700 models listed in the HighConfidenceBucket CSV's, so we can avoid some questionable regex matching.

This is nit picking but lots of new pc's have this status.

PS C:\Users\Public\Public Scripts\SecureBoot-Scripts\SecureBoot-CA-2023-Latest> .\Check_UEFI-CA2023.ps1 -Audit -Verbose
Windows 11 25H2 (26200.8894)

Secure Boot: ON
Virtualization Based Security: ON
BitLocker on (C:) OFF

BIOS Firmware
-------------
ASUSTeK COMPUTER INC. ROG Strix G16 G615LM_G615LM
Version: G615LM.338
Date: 2026-06-03

Factory Default UEFI PK Cert
----------------------------
ASUS Secure Boot PK

UEFI PK Cert
------------
ASUS Secure Boot PK

Factory Default UEFI KEK Certs
------------------------------
Microsoft Corporation KEK CA 2011
Microsoft Corporation KEK 2K CA 2023
ASUS Secure Boot KEK

UEFI KEK Certs
--------------
Microsoft Corporation KEK CA 2011
Microsoft Corporation KEK 2K CA 2023
ASUS Secure Boot KEK

Factory Default UEFI DB Certs
-----------------------------
Microsoft Corporation UEFI CA 2011
Microsoft Windows Production PCA 2011
Microsoft UEFI CA 2023
Windows UEFI CA 2023
ASUS Secure Boot DB

UEFI DB Certs
-------------
Microsoft Corporation UEFI CA 2011
Microsoft Windows Production PCA 2011
Microsoft UEFI CA 2023
Windows UEFI CA 2023
ASUS Secure Boot DB

Factory Default UEFI DBX Certs
------------------------------
(NONE)
EFI_CERT_SHA256_GUID Signatures: 371

UEFI DBX Certs
--------------
Microsoft Windows Production PCA 2011
Windows BootMgr SVN 9.0
EFI_CERT_SHA256_GUID Signatures: 447

UEFI Variables
--------------
Credential Guard: ON

EFI Files
---------
Windows Boot Manager [Windows UEFI CA 2023] is ALLOWED.
\\.\HarddiskVolume1\EFI\Microsoft\Boot\bootmgfw.efi
File Version: 28000.352, SVN 9.0

Registry: "WindowsUEFICA2023Capable" = 2
WIndows UEFI [CA 2023] in UEFI DB, and Windows starting from CA 2023 Boot Manager.

SkuSiPolicy.p7b is CURRENT.
\\.\HarddiskVolume1\EFI\Microsoft\Boot\SkuSiPolicy.p7b
Version: 3.0.0.16


AUDIT REPORT
============

I revoked the 2011 certs to ensure that it would still run... I'm not happy with Microsoft or Asus. I'm sure I will have lots of company,

1. [Microsoft Option ROM UEFI CA 2023] is missing from UEFI DB (This is not an option when waiting for Confidence Level Under Observation
new firmware and bios. 1801 error in Event Manager.

REQUIRED ACTION
===============
To install [UEFI CA 2023] certs, run the commands: Certs are installed but in a 'not finished' state.

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REGCert_DWORD /d 0x4800 /f
powershell Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

Asus272 said:

This is nit picking but lots of new pc's have this status.

UEFI DB Certs
-------------
Microsoft Corporation UEFI CA 2011
Microsoft Windows Production PCA 2011
Microsoft UEFI CA 2023
Windows UEFI CA 2023
ASUS Secure Boot DB

Click to expand...

Asus272 said:

AUDIT REPORT
============
1. [Microsoft Option ROM UEFI CA 2023] is missing from UEFI DB (This is not an option when waiting for Confidence Level Under Observation
new firmware and bios. 1801 error in Event Manager.

REQUIRED ACTION
===============
To install [UEFI CA 2023] certs, run the commands: Certs are installed but in a 'not finished' state.

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REGCert_DWORD /d 0x4800 /f
powershell Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

Click to expand...

This another example of "left hand of MS doesn't talk to its right hand".

Option ROM is considered optional, since your PC may not have any HW devices which have their own signed firmware. Typically that's some NVIDIA graphics card or a Thunderbolt storage controller. Does it hurt to install it? Probably not.

But TPM-WMI keeps throwing "errors" like it's supposed to be present. And if you don't have Option ROM, then Security Center doesn't give you the best possible rating. While it's optional, my opinion is to install it so Windows stops throwing these warnings. Technically they're informative messages, but everything gets categorized by TPM-WMI as a "serious problem".

Sometimes the trouble is because 0x4000 value added to AvailableUpdates is interpreted as "don't add Option ROM CA 2023" unless your BIOS already had the Option ROM 2010. And not surprisingly, some older PC's don't never had the Option ROM 2010 and so the update fails when 0x4000 is used.

i got this. i have never used Macrium.

Warre1 said:

i got this. i have never used Macrium.

Click to expand...

Let me know if this version fixes the problem.

garlin said:

Let me know if this version fixes the problem.

Click to expand...

It Does. Thank you.

You fix one bug, and forgot you duplicated it somewhere else... I'll update the ZIP file after lunch.

UPDATE: 2026-07-24
Fixed new bug when you don't have Macirum installed.

Thank you !!!

@garlin thanks for the updated scripts.
In regards to boot.stl, where does the script get the date/time stamp?

boot.stl is a strange critter, it's basically a Certificate Trust List (CTL) like the ones Windows downloads once a week to revoke entries in your Certificate Store. CTL's don't really have a formal method of encoding version details for itself.

Instead I'm using "certutil -dump boot.stl" and extracting the ThisUpdate field.

When you use certutil, many of the details belong to the individual certs that the CTL is bundling, but the CTL doesn't say much about itself. The OID's (or those long digits with dots in between) represent organized nodes in a tree structure, so you can't use them for identification.

If there's a better method of identifying boot.stl files, I'll take it.

all seems fine to me as always, Thank you again for all your hard work into this @garlin

Seems boot.stl has a list of winload.efi/osloader.exe and winresume.efi/hiberrsm.exe. Looks quite similar to SkuSiPolicy.p7b?

An Update on my HP Z440:
I started my HP Z440 without problem, and having seen that there were new scripts, I downloaded them, and checked with .\check-UEFI.bat - Verbose:
PS C:\Users\admin\Downloads\SecureBoot-CA-2023-Updates.v2026.07.24> .\check-UEFI.bat -Verbose
PowerShell 7.6.4
Windows 11 25H2 (26200.8894)

Secure Boot: ON
Virtualization Based Security: ON
BitLocker on (C:) OFF

BIOS Firmware
-------------
Hewlett-Packard HP Z440 Workstation
Version: M60 v02.62
Date: 2024-01-04
This BIOS may be corrupted by updating Secure Boot certs.

Factory Default UEFI PK Cert
----------------------------
Hewlett-Packard UEFI Secure Boot Platform Key

UEFI PK Cert
------------
Hewlett-Packard UEFI Secure Boot Platform Key

Factory Default UEFI KEK Certs
------------------------------
Microsoft Corporation KEK CA 2011
Hewlett-Packard UEFI Secure Boot Key Exchange Key

UEFI KEK Certs
--------------
Microsoft Corporation KEK CA 2011
Microsoft Corporation KEK 2K CA 2023
Hewlett-Packard UEFI Secure Boot Key Exchange Key

Factory Default UEFI DB Certs
-----------------------------
Microsoft Corporation UEFI CA 2011
Microsoft Windows Production PCA 2011
Hewlett-Packard UEFI Secure Boot DB Key

UEFI DB Certs
-------------
Microsoft Corporation UEFI CA 2011
Microsoft Windows Production PCA 2011
Microsoft Option ROM UEFI CA 2023
Microsoft UEFI CA 2023
Windows UEFI CA 2023
Hewlett-Packard UEFI Secure Boot DB Key
HP UEFI Secure Boot 2013 DB key

Factory Default UEFI DBX Certs
------------------------------
(NONE)
EFI_CERT_SHA256_GUID Signatures: 14

UEFI DBX Certs
--------------
Microsoft Windows Production PCA 2011
Windows BootMgr SVN 9.0
EFI_CERT_SHA256_GUID Signatures: 298

UEFI Variables
--------------
Credential Guard: ON
SBAT (Linux only): sbat,1,2024010900 / shim,4 / grub,3 / grub.debian,4

EFI Files
---------
Windows Boot Manager [Windows UEFI CA 2023] is ALLOWED.
\\.\HarddiskVolume1\EFI\Microsoft\Boot\bootmgfw.efi
File Version: 28000.352, SVN 9.0

Registry: "WindowsUEFICA2023Capable" = 2
[Windows UEFI CA 2023] in UEFI DB, and Windows starting from CA 2023 Boot Manager.

SkuSiPolicy.p7b is CURRENT.
\\.\HarddiskVolume1\EFI\Microsoft\Boot\SkuSiPolicy.p7b
Version: 3.0.0.16


STATUS REPORT
-------------
Registry: "UEFICA2023Status" = Updated

SUCCESS: UPDATES ARE FINISHED.
UEFI CA 2023 certs are present, PCA 2011 cert is revoked.

PS C:\Users\admin\Downloads\SecureBoot-CA-2023-Updates.v2026.07.24>

Although it says the bios may be corrupted by updating the secure boot certs, I updated them in june and have had no issue with my HP Z440 using secure boot since.
Then, I wanted to check if the boot.stl was good on my recovery drive, using check-UEFI.bat -Bootmedia
It told me boot.stl was the wrong version. On using update-UEFI.bat -Bootmedia I got the following error: "Model may be corrupted by updating secure certs. Exiting."
On restarting my computer, the recovery drive threw the following message:see attached photo
On restarting the computer without the recovery drive, I got the same message.
I then disabled secure boot, and rebooted my computer. I then started to search in the postings here for problems with winload.efi. I found a posting from Garlin to mount S: .....etc, then delete the file skusipolcy.p7b, and del mount, and on reboot reactivate secure boot. That worked.
So, now my HP Z440 boots again with secure boot activated, the newer 2023 certs, and without the skusiPolicy.p7b, but I still have a boot.stl version that is wrong on my recovery drive.
I can't use the script to update the recovery drive, as it believes my HP Z440 is at risk, although it has worked properly with the cert updates since june.
I had a look at the script itself to see if I could change it, but I came to the conclusion my knowledge is far too limited to try it.

I also had a look at the HP website. the HP Z440 is not supported anymore. The latest Bios is from 2024, and which I installed in 2024, but it did not include any new secure boot certs. I did not find any info, why the HP Z440 may have problems with the new secure boot certs.
What is the best way to proceed? I could deactivate secure boot, which I do not like. Or keep secure boot with the newer sec boot certs running, but with the chance I run into problems in the future due to the boot.stl version, or any other stuff that an incompetent MS and HP may add in the future?

Capricornus said:

Although it says the bios may be corrupted by updating the secure boot certs, I updated them in june and have had no issue with my HP Z440 using secure boot since.

Click to expand...

This is one of those annoying balancing acts I need to follow.

There's been 3 (?) confirmed reports of bricked PC's when people run the update script. It's presumed that it's not the fault of the actual process of clearing certs, or how to apply new certs. But there is a hidden and fundamental flaw in how certain BIOS'es or BIOS flash ROM's store the Secure Boot data. When data corruption occurs, not all PC's can be restored to working order (some can be reset to factory defaults, others are "bricked" and need to be reflashed by a qualified repair tech).

In a best effort to not intentionally allow users to get into trouble, I'm borrowing parts of the the Confidence Level data. While I don't believe the "More Data Needed" is conclusive, the "Temporarily Paused" and "Not Supported" categories are probably derived from something serious that MS knows about.

This version of the script will check if your Confidence Level falls into either category, and try warning you beforehand. I suspect your PC model is tagged "Temporarily Paused", indicating HP is supposed to work a BIOS fix (least that's what this category is for). Whether that's actually true, or MS is wrong or nobody's changed the status is unknown to me.

So it's better to get a false positive, than have someone else get a bricked PC because they didn't know their BIOS had a hidden flaw. The user isn't going to know unless someone tells them. The next best info would be MS's own list of blocked PC's because they have some info I don't have.

Capricornus said:

Then, I wanted to check if the boot.stl was good on my recovery drive, using check-UEFI.bat -Bootmedia
It told me boot.stl was the wrong version. On using update-UEFI.bat -Bootmedia I got the following error: "Model may be corrupted by updating secure certs. Exiting."

Click to expand...

I put the same check in the update script. So you're getting a false positive in two different places

Capricornus said:

On restarting my computer, the recovery drive threw the following message:see attached photo
On restarting the computer without the recovery drive, I got the same message.
I then disabled secure boot, and rebooted my computer. I then started to search in the postings here for problems with winload.efi. I found a posting from Garlin to mount S: .....etc, then delete the file skusipolcy.p7b, and del mount, and on reboot reactivate secure boot. That worked.
So, now my HP Z440 boots again with secure boot activated, the newer 2023 certs, and without the skusiPolicy.p7b, but I still have a boot.stl version that is wrong on my recovery drive.
I can't use the script to update the recovery drive, as it believes my HP Z440 is at risk, although it has worked properly with the cert updates since june.
I had a look at the script itself to see if I could change it, but I came to the conclusion my knowledge is far too limited to try it.

Click to expand...

You can just copy the same boot.stl by hand:

I'll have to add some override to the command-line, in case you have a fully updated UEFI but MS still thinks your BIOS should not be touched.

I have a compromise solution, which isn't 100% perfect but should work for most users.

The script will only issue a warning if your UEFI doesn't already have both the KEK CA 2023 installled and PCA 2011 in the DBX. My thinking is if you've already gotten that far, it's too late now to give you a warning not to update the UEFI.

@Capricornus, try this version of both scripts.

garlin said:

I have a compromise solution, which isn't 100% perfect but should work for most users.

The script will only issue a warning if your UEFI doesn't already have both the KEK CA 2023 installled and PCA 2011 in the DBX. My thinking is if you've already gotten that far, it's too late now to give you a warning not to update the UEFI.

@Capricornus, try this version of both scripts.

Click to expand...

Well, that makes sense! If all that is done, you're finished, right?