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

garlin · 2026-06-03T19:04:43-0400

I'm wondering if that's left over from my script. It creates an \EFI\Certs folder, so it's easier to manually find a cert file than browsing through multiple subfolders and scrolling past other random filenames.

After you're done installing the CA 2023 certs, \EFI\Certs and its files can be safely removed. They're not part of the normal EFI filesystem.

Bree · 2026-06-03T20:38:58-0400

garlin said:
I'm wondering if that's left over from my script. It creates an \EFI\Certs folder, so it's easier to manually find a cert file than browsing through multiple subfolders and scrolling past other random filenames....

That seems likely. I've only ever run your script to try and update one laptop, my System One below. For my others I've only needed to run the Check-UEFI script, they all say that they don't need a manual update, I can just let Microsoft handle it for me. None of them have that \EFI\Certs folder.

I've subsequently retired my System One from active duty due to a broken hinge, and restored its system image to my System Seven (in Other Info). That too won't need a manual update, it's already at the stage where all that's left it to revoke PCA 2011 (I'm in no hurry, I'll leave that to MS). It has however inherited that \EFI\Certs folder from the system image of System One. Should I delete it, or will it do no harm to leave it?

Klaver7 · 2026-06-03T21:16:34-0400

I dont have "Certs" on 2 machines that I used Garlin' script on to update c2023

D519D51B249349f38D79D76488950CB5.EXC = Hasleo so it seems, I deleted it.

garlin · 2026-06-03T21:52:21-0400

Bree said:
That seems likely. I've only ever run your script to try and update one laptop, my System One below. For my others I've only needed to run the Check-UEFI script, they all say that they don't need a manual update, I can just let Microsoft handle it for me. None of them have that \EFI\Certs folder.

I've subsequently retired my System One from active duty due to a broken hinge, and restored its system image to my System Seven (in Other Info). That too won't need a manual update, it's already at the stage where all that's left it to revoke PCA 2011 (I'm in no hurry, I'll leave that to MS). It has however inherited that \EFI\Certs folder from the system image of System One. Should I delete it, or will it do no harm to leave it?

Klaver7 said:
I dont have "Certs" on 2 machines that I used Garlin' script on to update c2023

Not everyone gets a "Certs" folder created on the EFI partition.

In the best case, you already have the KEK CA 2023 installed from a recent BIOS update. Then we don't need to copy any certs to the EFI partition, everything can be updated directly from Windows. When no KEK CA 2023 is found, we can try matching your PK's thumbprint against the list of vendor-submitted KEK bin files on the MS GitHub repo. If there's a match, we can try applying the submitted KEK file from Windows.

If the previous attempt fails, the fallback is to ask the user to try manual enrollment.

Now the script creates "\EFI\Certs" (to keep the certs organized in one place, instead of randomly copying them to \EFI\Microsoft\Boot), and copies the cert files to make this task easier for the user. Normally, you're asked to copy files to a writeable FAT32 volume (because most EFI's can only natively read FAT32). By copying the files to the EFI partition, I'm saving you the time of finding a spare USB drive.

In some cases, manual enrollment is unsuccessful and we have to proceed to the nuclear option of wiping all keys. For Setup Mode, we don't need to copy files to the EFI since any UEFI without a working PK doesn't have security restrictions. We can perform the update from Windows.

Why doesn't the script clean up the folder? I figured just in case you have a situation where you needed to reset the UEFI for something, retaining the files there would make it easier to repeat the process.

Both cert files consume less than 8 KB, so they're not taking up too much disk space. You can delete them if you like. They don't interfere with the EFI's functions, which is why I created a "Certs" folder so you don't have to worry about deleting the wrong folder of files.

JamesSmith · 2026-06-04T01:36:29-0400

Just a quick question for you Garlin I did this on my Wifes laptop (system2 in my pc specs)

Code:

mountvol S: /s
del S:\EFI\Microsoft\Boot\SkuSiPolicy.p7b
mountvol S: /d

Because I was just curious and after I rebooted I got stuck where it said the boot manager was banned and it asked me to insert media to boot from. I can't remember exactly what it said but it mentioned " detected changes in configuration to boot" or something like that. I was stuck in a loop because every time I restarted the laptop it wanted me to provide a bootable drive. Wouldn't boot from the SSD or any usb I had.

Anyway so I was able to quickly go into the BIOS and turn Secure Boot off then I was able to load Windows. I restarted again went into BIOS turned secure boot ON and was able to boot back into windows like nothing had happened.

Strange. All is good now. I have run all your scripts and they came back perfect. I wonder what the heck happened there.

garlin · 2026-06-04T02:12:23-0400

This is known as an UEFI lock. If you have a deployed SkuSiPolicy.p7b, there is a set of reg keys in Windows which controls whether enforcement is enabled. One of the risks is the reg keys can be modified by anyone with Admin privileges, so an attacker could disable enforcement by modding values.

To prevent this scenario, Windows can write authenticated variables to the UEFI (which are hidden from normal Windows) which declares enforcement will happen, regardless of what the registry calls for. When the UEFI lock is in place, deleting the SkuSiPolicy file from the EFI confuses Windows, since it's expecting to enforce policy by reading rules from a policy file that no longer exists.

This is why the script now has the UEFI Variables section to report whether DeviceGuard (SkuSiPolicy) or CredentialGuard (LSASS) are "UEFI locked".

The current guidelines instruct to you disable Secure Boot, reboot, and then delete the SkuSiPolicy. After you've removed SkuSiPolicy, shutdown and re-enable Secure Boot. I should probably expand the instructions for removing SkuSiPolicy so it's more clear.

Guidance for blocking rollback of Virtualization-based Security (VBS) related security updates - Microsoft Support

JamesSmith · 2026-06-04T02:34:10-0400

garlin said:
This is known as an UEFI lock. If you have a deployed SkuSiPolicy.p7b, there is a set of reg keys in Windows which controls whether enforcement is enabled. One of the risks is the reg keys can be modified by anyone with Admin privileges, so an attacker could disable enforcement by modding values.

To prevent this scenario, Windows can write authenticated variables to the UEFI (which are hidden from normal Windows) which declares enforcement will happen, regardless of what the registry calls for. When the UEFI lock is in place, deleting the SkuSiPolicy file from the EFI confuses Windows, since it's expecting to enforce policy by reading rules from a policy file that no longer exists.

This is why the script now has the UEFI Variables section to report whether DeviceGuard (SkuSiPolicy) or CredentialGuard (LSASS) are "UEFI locked".

The current guidelines instruct to you disable Secure Boot, reboot, and then delete the SkuSiPolicy. After you've removed SkuSiPolicy, shutdown and re-enable Secure Boot. I should probably expand the instructions for removing SkuSiPolicy so it's more clear.

Guidance for blocking rollback of Virtualization-based Security (VBS) related security updates - Microsoft Support

Thanks for the explanation. I wasn't expecting the UEFI lock. Thanks it makes sense now.

I also ran your script and re added SkuSiPolicy policy back onto the laptop.
Script comes back clean.

I hope there's no issues from what I did.

*EDIT* I am seeing a million error logs

"Code Integrity determined that a process (\Device\HarddiskVolume3\Windows\System32\svchost.exe) attempted to load \Device\HarddiskVolume3\Program Files\Malwarebytes\Anti-Malware\mbamsi64.dll that did not meet the Windows signing level requirements."

Chrome, Firefox a lot of applications showing this exactly around the time I removed SkuSiPolicy

Configure added LSA protection

See how to configure added protection for the Local Security Authority (LSA) process to prevent code injection that can compromise credentials.

learn.microsoft.com

Scroll down to Devices that use Secure Boot and UEFI

When I googled how to fix this issues it says disable Added LSA protection. (not a good idea)

I think I broke something.

Could this be a result of removing SkuSiPolicy with Secure Boot on? It seems to be a conflict with (LSASS)
?

EB2XR6 · 2026-06-04T06:00:26-0400

garlin said:
Normally, flashing the BIOS should not change the current certs (which are stored in NVRAM).

A new BIOS can have a different set of factory default certs. But it can only go in one direction (factory certs added to NVRAM), but not in the other direction. If updating the BIOS corrupts the NVRAM, you can always reset to factory defaults and repeat the same update process you successfully performed the first time.

Thank you Garlin,
Updated the BIOS, just the usual hassles with resetting the Windows PIN, also I hate how this Gigabyte Board goes back to Factory Defaults.
Certificates were good just had to re enter a reg command in terminal.

xiojin · 2026-06-04T08:22:13-0400

hello i have my certificates updated and all is fine but i wanted to report that newer versions of the check-UEFI script after 2026.05.08.01 do not work for me, even latest 2026.05.31 do not work but it give a different error, i think i have something to do with me having 2ssd with windows installs plugged in and the partition used for bootmanager.

SecureBoot-CA-2023-Updates2026.05.08.01

Code:

PowerShell 7.6.2
Secure Boot: ON
Virtualization Based Security: ON
BitLocker on (C:) ON
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 8.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.
STATUS REPORT
-------------
    Registry: UEFICA2023Status = Updated
    SUCCESS: UPDATES ARE FINISHED.
    UEFI CA 2023 certs are present, PCA 2011 cert is revoked.
PS C:\Windows\System32>

SecureBoot-CA-2023-Updates2026.05.11

Code:

PowerShell 7.6.2
Secure Boot: ON
Virtualization Based Security: ON
BitLocker on (C:) ON
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 8.0
Command cannot find any of the specified files.
PS C:\Windows\System32>

SecureBoot-CA-2023-Updates.2026.05.31

Code:

PowerShell 7.6.2
Secure Boot: ON
Virtualization Based Security: ON
BitLocker on (C:) ON
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 8.0
ERROR: EFI folder "$EFI_Path" cannot be found.
PS C:\Windows\System32>

Code:

PS C:\Windows\System32> bcdedit
Windows Boot Manager
--------------------
identifier              {bootmgr}
device                  partition=\Device\Harddisk1\Partition2
path                    \EFI\MICROSOFT\BOOT\BOOTMGFW.EFI
description             Windows Boot Manager
locale                  en-US
inherit                 {globalsettings}
default                 {current}
resumeobject            {4444***********************}}
displayorder            {current}
toolsdisplayorder       {memdiag}
timeout                 30
Windows Boot Loader
-------------------
identifier              {current}
device                  partition=C:
path                    \WINDOWS\system32\winload.efi
description             Windows 10
locale                  en-US
inherit                 {bootloadersettings}
recoverysequence        {eeee***********************}
displaymessageoverride  Recovery
recoveryenabled         Yes
isolatedcontext         Yes
allowedinmemorysettings 0x15000075
osdevice                partition=C:
systemroot              \WINDOWS
resumeobject            {4444***********************}
nx                      OptOut
bootmenupolicy          Standard
hypervisorlaunchtype    Auto

Code:

DISKPART> sel dis 1
Disk 1 is now the selected disk.
DISKPART> lis par
  Partition ###  Type              Size     Offset
  -------------  ----------------  -------  -------
  Partition 1    Recovery           499 MB  1024 KB
  Partition 2    System             100 MB   500 MB
  Partition 3    Reserved            16 MB   600 MB
  Partition 4    Primary            225 GB   616 MB
  Partition 5    Recovery           866 MB   233 GB

DISKPART> sel dis 3
Disk 3 is now the selected disk.
DISKPART> lis par
  Partition ###  Type              Size     Offset
  -------------  ----------------  -------  -------
  Partition 1    System              99 MB   530 MB
  Partition 2    Reserved            16 MB   629 MB
  Partition 3    Primary            838 GB   645 MB
  Partition 4    Recovery          1024 MB   839 GB

Disk 1 is my older PC windows OS disk that i don't really use or ever tried to boot from, disk 3 my newer PC windows install, pc still boot correctly when i remove disk 1

garlin · 2026-06-04T10:26:57-0400

xiojin said:

Code:

PS C:\Windows\System32> bcdedit
Windows Boot Manager
--------------------
identifier              {bootmgr}
device                  partition=\Device\Harddisk1\Partition2
path                    \EFI\MICROSOFT\BOOT\BOOTMGFW.EFI
description             Windows Boot Manager

xiojin said:
Disk 1 is my older PC windows OS disk that i don't really use or ever tried to boot from, disk 3 my newer PC windows install, pc still boot correctly when i remove disk 1

If there are multiple boot disks, the script has to carefully determine which EFI partition is the active one.

Your BCD store is pointing to Disk 1, instead of Disk 3. We need to correct this config.

Code:

select disk 3
select part 1
assign letter=s
exit

Code:

bcdedit /set {bootmgr} device partition=S:

Code:

select disk 3
select part 1
remove letter=S
exit

Now run the check script.

garlin · 2026-06-04T10:37:04-0400

JamesSmith said:
"Code Integrity determined that a process (\Device\HarddiskVolume3\Windows\System32\svchost.exe) attempted to load \Device\HarddiskVolume3\Program Files\Malwarebytes\Anti-Malware\mbamsi64.dll that did not meet the Windows signing level requirements."

Code Integrity (or VBS) is running, and has invoked the stricter driver signing requirements. Older drivers may now fail the security, where they passed before. Typically it means you need to upgrade MBAM.

JamesSmith said:
Chrome, Firefox a lot of applications showing this exactly around the time I removed SkuSiPolicy

Configure added LSA protection

See how to configure added protection for the Local Security Authority (LSA) process to prevent code injection that can compromise credentials.

learn.microsoft.com

Scroll down to Devices that use Secure Boot and UEFI

When I googled how to fix this issues it says disable Added LSA protection. (not a good idea)

I think I broke something.

SkuSiPolicy strictly enforces the version of winload.efi. There are no other rules in the policy file (other than another Windows file) to prevent 3rd-party apps from running. LSASS prevents sophisticated credential stealing from previously known hacking methods.

Neither of them relate to normal user apps. It's most likely your MalwareBytes is conflicting with VBS, and all your browsers have to pass through MBAM before they're allowed to do anything. Check if you have the latest version of the security software.

gunrunnerjohn · 2026-06-04T11:43:11-0400

Klaver7 said:
I dont have "Certs" on 2 machines that I used Garlin' script on to update c2023

D519D51B249349f38D79D76488950CB5.EXC = Hasleo so it seems, I deleted it.

View attachment 173348

What program is this you're using to display the partitions?

Klaver7 · 2026-06-04T11:46:33-0400

MiniTool Partition Wizard

garlin · 2026-06-04T11:51:55-0400

@JamesSmith
MBAE64.DLL causing Windows Event ID 3033 (Code Integrity)

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

Well-known member

My Computer

Well-known member

My Computers

Member

My Computer

Well-known member

My Computer

Well-known member

My Computers

Well-known member

My Computer

Well-known member

My Computers

Active member

My Computer

New member

My Computer

Well-known member

My Computer

Well-known member

My Computer

Well-known member

My Computers

Member

My Computer

Well-known member

My Computer