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

gunrunnerjohn said:

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

Click to expand...

But it doesn't allow someone to use the update script on untouched PC if they really, really, really wanted to try. It would require an override option from the command-line.

I don't own the Confidence data nor do I understand why MS moved a PC into the "bad" buckets. There could be a false positive. If you're running the check script, the worse thing is you get nagged for something that isn't actually wrong. But for the update process, that's a different matter.

garlin said:

But it doesn't allow someone to use the update script on untouched PC if they really, really, really wanted to try. It would require an override option from the command-line.

I don't own the Confidence data nor do I understand why MS moved a PC into the "bad" buckets. There could be a false positive. If you're running the check script, the worse thing is you get nagged for something that isn't actually wrong. But for the update process, that's a different matter.

Click to expand...

Suggestion, instead of adding a new command line flag, how about requiring the user to uncomment a line in your code that would allow update script to run even on troublesome computers. Like a boolean that must be true, but the only way it can be true is for the user to uncomment a line. And you could write some text to explain the risk in the script.

That way, they have to make explicit changes inside the script in order to allow the update script to excute against their computer.
I would say this is safe enough and no end user could use command line argument not truly understanding what it means and brick their computer.

And add text to post #1 explaining how a user can decide to use the update at his/her own risk, so warned twice, post #1 and in the script...

Added bonus, if they get a new version, line is in comment again !

Thanks a lot for the valuable work @garlin. Worked on different systems (HP Z240 / HP 600 G1), where using Windows standard functionality was not sufficient (cjee21 scripts for ease of use). But for Lenovo Thinkpad X260 same problem and solution as stated here for T460:


Installing latest Lenovo bios (iso on stick, Windows tool won't do in in W11) and clearing all keys from within UEFI and afterwards using latest Mosby standard mode did work. Trying different scenarios with garlin's script led to a missing PK because of "Wrong signature for this UEFI variable" error. Trying to just update the 2023 KEK while keeping the default PK did't work either (cjee21 scripts).

garlin said:

But it doesn't allow someone to use the update script on untouched PC if they really, really, really wanted to try. It would require an override option from the command-line.

I don't own the Confidence data nor do I understand why MS moved a PC into the "bad" buckets. There could be a false positive. If you're running the check script, the worse thing is you get nagged for something that isn't actually wrong. But for the update process, that's a different matter.

Click to expand...

It may not be possible for you to cover every eventuality and to update every computer. Truthfully, you've done an immense amount of work and certainly helped a ton of people get secure boot updated, but there's likely a limit to how much one person can support.

I did like the suggestion of having an override that you could perform with several warnings about the risks.

bjrnx said:

Installing latest Lenovo bios (iso on stick, Windows tool won't do in in W11) and clearing all keys from within UEFI and afterwards using latest Mosby standard mode did work. Trying different scenarios with garlin's script led to a missing PK because of "Wrong signature for this UEFI variable" error. Trying to just update the 2023 KEK while keeping the default PK did't work either (cjee21 scripts).

Click to expand...

"Wrong signature" indicates you have NVRAM corruption after certs have been added. For certain PC's, users have noted you have to clear the keys twice (and also reboot while in Secure Boot mode), so the internal data is written correctly.

As @t2s50 likes to note, different vendors can do strange things with the way Secure Boot (or UEFI) data is written to the flash ROM's. While my script isn't 100% effective, it follows a high-level "by the the book" process that's generally safe.

cjee21's scripts call the Secure Boot task with different AvailableUpdates values. But the task is probably too cautious, and sometimes waits for certain conditions before executing. My update script obeys safety checks, but it applies the same signed .bin files without waiting around for you to reboot the system a few times like Windows does.

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...

Garlin, Many, many thanks for these changed scripts.
When I run the check-UEFI.bat with the changed ps1 script, I now get the following:
PS C:\Users\admin\Downloads\SecureBoot-CA-2023-Updates.v2026.07.26> .\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

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.

[OPTIONAL] SkuSiPolicy.p7b (for VBS) is MISSING.


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.26>

When I run chek-UEFI.at -Bootmedia, with the changed script, I get the following:
PS C:\Users\admin\Downloads\SecureBoot-CA-2023-Updates.v2026.07.26> .\check-UEFI.bat -Bootmedia
PowerShell 7.6.4
Secure Boot: ON
Virtualization Based Security: ON
BitLocker on (C:) OFF

UEFI KEK Certs
--------------
Microsoft Corporation KEK CA 2011
Microsoft Corporation KEK 2K CA 2023

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

UEFI DBX Certs
--------------
Microsoft Windows Production PCA 2011
Windows BootMgr SVN 9.0

EFI Files
---------
Windows Boot Manager [Windows UEFI CA 2023] is ALLOWED.

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

[OPTIONAL] SkuSiPolicy.p7b (for VBS) is MISSING.

Bootable Media
--------------
USB Drive I: "RECOVERY"
Windows Boot Manager [Windows UEFI CA 2023] is ALLOWED.

boot.stl is WRONG VERSION.


USB Drive J: "REINER-SCT"
J:\EFI\Microsoft\Boot\boot.stl is MISSING.



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.26>

and when I run update-UEFI.bat -Bootmedia, with the changed script, I get this:

PS C:\Users\admin\Downloads\SecureBoot-CA-2023-Updates.v2026.07.26> .\Update-UEFI.bat -Bootmedia
PowerShell 7.6.4
Updating WinRE boot media on USB Drive I: "RECOVERY"
Boot files successfully created.
SUCCESS: NO UPDATES ARE REQUIRED.

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

and the boot.stl file is now current on my recovery drive.

This is simply brilliant. You made my day. THANK YOU.

These particular Lenovo systems seem to be oddballs in regard to updating secure boot data. I resetted several (countless times the uefi complete, the secure boot keys complete or only PK, tried variations of BIOS setting enabled/disabled, flashed the BIOS and again resetted the options to factory defaults ... to no avail or I missed one potentially succesful combination. A pity is there is only the option for resetting PK or all keys and no way to manually load seperate parts of the secure boot data. Regards and again thanks for your effort.

@garlin
Another idea that you might like better in which people would not have to edit your script.
You could prompt them with the risks and have them type something like "I accept the risk" before proceeding.
If they do not type the exact phrase, your script does not change anything on their computer...

Just another idea...

Capricornus said:

Garlin, Many, many thanks for these changed scripts.

Click to expand...

In the previous version, I followed a logical order of grabbing the BIOS details before moving on to the cert lists. But that meant your cert status wasn't available before the BIOS was checked for compatibility.

By switching the run order of certain functions, I can now use your current cert status to ignore the BIOS check if you're already revoked. Everyone who doesn't fall into that specific requirement will get the original treatment as intended.

anchamp65 said:

@garlin
Another idea that you might like better in which people would not have to edit your script.
You could prompt them with the risks and have them type something like "I accept the risk" before proceeding.
If they do not type the exact phrase, your script does not change anything on their computer...

Just another idea...

Click to expand...

I'm adding a -Force flag to the update script. But you will still have to enter "YES" before it actually does anything.

I am trying to help a friend who has an Acer Extensa EX215-32. In the Acer Forum they state there is an update for his computer (V1.27 Bios) available via Windows Update. It would appear there is no Windows Update, nor is it listed in the Microsoft Update Catalogue.
Having run the Update script 6 weeks ago:

The result of the CheckUEFI reveals:
Windows 11 25H2 (26200.8894)

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

BIOS Firmware
-------------
Acer Extensa 215-32
Version: V1.23
Date: 2023-08-07

Factory Default UEFI PK Cert
----------------------------
Acer Platform Key

UEFI PK Cert
------------
Acer Platform Key
Manual update of [KEK CA 2023] is REQUIRED.

Factory Default UEFI KEK Certs
------------------------------
Microsoft Corporation KEK CA 2011
Acer Key Exchange Key

UEFI KEK Certs
--------------
Microsoft Corporation KEK CA 2011
Acer Key Exchange Key

Factory Default UEFI DB Certs
-----------------------------
Microsoft Corporation UEFI CA 2011
Microsoft Windows Production PCA 2011
ABO
Acer Database
DisablePW

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
ABO
Acer Database
DisablePW

Factory Default UEFI DBX Certs
------------------------------
Acer Database Forbidden
EFI_CERT_SHA256_GUID Signatures: 33

UEFI DBX Certs
--------------
Acer Database Forbidden
Windows BootMgr SVN is MISSING.
EFI_CERT_SHA256_GUID Signatures: 291

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

EFI Files
---------
Boot File [Windows UEFI CA 2023] is UNTRUSTED
\\.\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.

[OPTIONAL] SkuSiPolicy.p7b (for VBS) is MISSING.


REQUIRED ACTION
===============

Run the command:
Update_UEFI-CA2023.ps1 -Revoke

Finish the UEFI steps to manually add the [KEK CA 2023] cert, if the script provided instructions.

What does the Boot File is untrusted mean?

Also the Windows Security Device state reports:
"Secure Boot is on, but your device does not support the automate Secure Boot certificate update due to hardware or firmware limitations. Contact your device manufacturer for assistance"
The Acer website states that this means:

• Updates Blocked Due to Limitations: A notification indicating that updates are blocked means your current UEFI/BIOS firmware cannot automatically handle or write the larger certificate files.

If so, I don't understand that there is an update Bios available? One cannot download any Bios later than v1.23 from their support website.

Any ideas?

SaliesBuzz said:

I am trying to help a friend who has an Acer Extensa EX215-32. In the Acer Forum they state there is an update for his computer (V1.27 Bios) available via Windows Update. It would appear there is no Windows Update, nor is it listed in the Microsoft Update Catalogue.

Click to expand...

Based on a highlighted thread over in the Acer community forums, a BIOS update is needed for specific models because of outdated assumptions about how Secure Boot (or UEFI) data is stored internally in the NVRAM.

Normally Acer could submit a signed KEK CA 2023 file for older PC's, and call it a day. But because they didn't anticipate years ago how much space is needed to store the final size of the anticipated DBX updates, manual updates to those models could end up bricking them.

Therefore a new BIOS release is required. Windows Update has a specific provision for an UEFI Capsule update, where the OEM submits their new BIOS image in a specific format and Windows can deploy that on its own.

For strict safety reasons, only WU is allowed to perform this task. You will not find this BIOS in the Microsoft Update Catalog, and it's up to MS to gradually roll it out to the affected users. PC's will be specifically targeted based on their current motherboard/BIOS version. If your friend's PC is listed on the support site as "wait for WU", just be patient and allow MS to handle it.

SaliesBuzz said:

UEFI KEK Certs
--------------
Microsoft Corporation KEK CA 2011
Acer Key Exchange Key

Click to expand...

Unsupported PC, with no KEK CA 2023 yet.

SaliesBuzz said:

UEFI DBX Certs
--------------
Acer Database Forbidden
Windows BootMgr SVN is MISSING.
EFI_CERT_SHA256_GUID Signatures: 291

Click to expand...

It's made it this far to 291 EFI signature hashes, but applying the full set might put it over the limit (?). Only Acer's engineers would know if there's a risk, but it appears they're taking the same lesson to heart and applying fixes to multiple different BIOS'es.

Most of the time if you look in Confidence Level, you'll see "High Confidence" (updates are supported) or "More Data Need" (not sure, or waiting for more data samples). The problem is if MS tags a PC as "Temporarily Paused" or "Not Supported". That means MS and the OEM both know something can go wrong for a specific reason.

For now, I would be patient and check back with your friend once a week. Hopefully, one day Windows Update will report a BIOS update was installed. At that point, Secure Boot updates will take care of themselves. The fact that Acer is taking action at such a late date (summer 2026), means it's an important support issue for them.

ran the latest check UEFI and got on one of my other PCs

EFI Files
---------
Windows Boot Manager [Windows UEFI CA 2023] is ALLOWED.

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

[OPTIONAL] SkuSiPolicy.p7b (for VBS) is MISSING.

Click to expand...

ran this


PS C:\Users\asus> Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard

AvailableSecurityProperties : {1, 2, 7}
CodeIntegrityPolicyEnforcementStatus : 2
InstanceIdentifier : obscured here
RequiredSecurityProperties : {0}
SecurityFeaturesEnabled : {0}
SecurityServicesConfigured : {2}
SecurityServicesRunning : {2}
SmmIsolationLevel : 0
UsermodeCodeIntegrityPolicyEnforcementStatus : 0
Version : 1.0
VirtualizationBasedSecurityStatus : 2
VirtualMachineIsolation : False
VirtualMachineIsolationProperties : {0}
PSComputerName :

Click to expand...

does it mean anything ? next steps ?

botus said:

Code:

EFI Files
---------
Windows Boot Manager [Windows UEFI CA 2023] is ALLOWED.

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

[OPTIONAL] SkuSiPolicy.p7b (for VBS) is MISSING.

Click to expand...

VirtualizationBasedSecurityStatus = 2 says VBS is currently enabled and running.

The script would have reported "Virtualization Based Security: ON" for you.

If you don't have a SkuSiPolicy file deployed, there is no enforcement of banned boot files (ie. winload.efi). While it's recommended to be installed, it's optional because stricter enforcement can cause problems in a Windows dual-boot setup, or with USB recovery drives which get out of date with later Monthly Updates. Some users are fine with those restrictions, others get bothered by it.

SkuSiPolicy itself doesn't change any VBS settings; all it does is to enforce a lockout on boot files. But the policy is only activated if VBS is enabled from the registry or a hidden UEFI lock. The script doesn't care about any VBS details other than VBS is enabled.

Hi Garlin.

If I want to do a fresh install of Windows 11 will SkuskiPolicy be a problem? I usually use media creation tool put it all on a usb and run that from within windows. Or maybe restart my pc and boot from that usb. I can't remember. (old age)

Thanks!

JamesSmith said:

If I want to do a fresh install of Windows 11 will SkuskiPolicy be a problem? I usually use media creation tool put it all on a usb and run that from within windows.

Click to expand...

It depends. If you don't wipe the target disk before Windows Setup runs, it will re-use the existing partitions it finds. I don't believe the EFI volume is erased, but instead its contents are overwritten. So a previous SkuSiPolicy wouldn't be deleted in a clean install.

As long as you're always using the latest MCT download (keep moving forward), there wouldn't be any interference. The problem comes when you have a MCT ISO that'd older than the SkuSiPolicy from before, then the new system could get a boot problem. Using the latest created ISO will mean it's equal or newer than any SkuSiPolicy that can be found.

But honestly, I haven't tested this scenario. So that's my best guess on what happens. But you're welcome to see if a clean install (without deleting the previous disk layout) works out when a SkuSiPolicy was left behind from the previous install.

garlin said:

It depends. If you don't wipe the target disk before Windows Setup runs, it will re-use the existing partitions it finds. I don't believe the EFI volume is erased, but instead its contents are overwritten. So a previous SkuSiPolicy wouldn't be deleted in a clean install.

As long as you're always using the latest MCT download (keep moving forward), there wouldn't be any interference. The problem comes when you have a MCT ISO that'd older than the SkuSiPolicy from before, then the new system could get a boot problem. Using the latest created ISO will mean it's equal or newer than any SkuSiPolicy that can be found.

But honestly, I haven't tested this scenario. So that's my best guess on what happens. But you're welcome to see if a clean install (without deleting the previous disk layout) works out when a SkuSiPolicy was left behind from the previous install.

Click to expand...

So instead of "Create Windows 11 Installation Media"

I would want to "Download Windows 11 Disk Image (ISO) for x64 devices" instead? as this would probably have the newer version?

I don't think I want to test this out. ha. If anyone else wants to that would be good


James.

When you run MCT, it creates an updated 25H2 ISO every month, about a week after Patch Tuesday.

The direct download ISO is mostly intended for IT pro's (who do their own image updates), and is rarely updated and the last version was released in March 2026. For a home user, it's preferable to use the MCT to create an ISO right before you're ready to install.

How many times do you have to revoke this...PCA 2011

0x200 means your SVN (8.0) is behind.

What version of the script are you running? I though this bug (reporting the PCA 2011 as the wrong cause) was fixed months ago.

garlin said:

It depends. If you don't wipe the target disk before Windows Setup runs, it will re-use the existing partitions it finds. I don't believe the EFI volume is erased, but instead its contents are overwritten. So a previous SkuSiPolicy wouldn't be deleted in a clean install.

Click to expand...

Just to be clear. When I run setup and it asks me where do I want to install Windows to I usually delete and format everything in that table. Is this what you are talking about when you say don't wipe that target disk?