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

nikki605 · Jun 7, 2026

garlin said:
It's great that Lenovo has refreshed the BIOS (even this late in the game), and tried to make the UI more presentable. I believe Acer has a round of BIOS updates scheduled for mid-June.

@garlin I just noticed that updating the T490 UEFI BIOS to 1.85 Enabled VBS which was previously OFF under version 1.84. The 5/31 version of your check script now shows it ON and the optional SkuSiPolicy.p7b missing. Should I now install this and if so, how? Will this affect my USB boot drives? Should I just turn OFF VBS since it was off anyway prior to the 1.85 update?

PowerShell 7.6.2
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 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>

garlin · Jun 7, 2026

nikki605 said:
@garlin I just noticed that updating the T490 UEFI BIOS to 1.85 Enabled VBS which was previously OFF under version 1.84. The 5/31 version of your check script now shows it ON and the optional SkuSiPolicy.p7b missing. Should I now install this and if so, how? Will this affect my USB boot drives?

While SkuSiPolicy is recommended, it's still optional for the very reason that it can block some boot devices (USB drives). Don't add the policy file if you don't feel comfortable about trying to fix your USB drives.

Sometimes a BIOS update will unlock more HW security features, and Windows will recognize those changes and automatically enable VBS for you. There are different shades of VBS policy rules, depending on what your HW supports.

It's sort of like BitLocker (or Device Encryption on Windows Home). Originally the security requirements were very strict, and few PC's supported it. But then MS adjusted the requirements and PC vendors added more HW features, and so now BitLocker is more likely to be turned on by default.

nikki605 · Jun 7, 2026

garlin said:
While SkuSiPolicy is recommended, it's still optional for the very reason that it can block some boot devices (USB drives). Don't add the policy file if you don't feel comfortable about trying to fix your USB drives.

Sometimes a BIOS update will unlock more HW security features, and Windows will recognize those changes and automatically enable VBS for you. There are different shades of VBS policy rules, depending on what your HW supports.

It's sort of like BitLocker (or Device Encryption on Windows Home). Originally the security requirements were very strict, and few PC's supported it. But then MS adjusted the requirements and PC vendors added more HW features, and so now BitLocker is more likely to be turned on by default.

I think I will leave it set the way it is and not fool with SkuSiPolicy.p7b since I have a Macrium 8 Free boot USB drive that works after running your Update Script using -BootMedia. This is what SysInfo shows right now:

Thanks for the info.

garlin · Jun 7, 2026

The row "Available Security Properties" represents what the HW can do. Not everyone will have the same list of attributes.

Hypervisor enforced Code Integrity (HVCI) is the highest level of security Windows can provide. It builds a VM security layer inside Windows to protect Windows from driver-based tampering.

anchamp65 · Jun 7, 2026

@garlin
I'm thinking of trying to apply SkuSiPolicy.p7b on my Dell 3910 and Surface 9 Pro where I use Macrium X
I've already applied it on the older computers where I use Veeam Agent for Microsoft Windows Free and updated the boot media with bcdedit, and it all works without issues.
So I was thinking that it will probably work on my Dell and Surface, but just in case I want to know how to revert it if I need to.

I have read this web page from MS Guidance for blocking rollback of Virtualization-based Security (VBS) related security updates

They mention that you can revert the policy by simply: (PS: I do not use BitLocker)

Disable Secure Boot in BIOS
Boot Windows
Remove SkuSiPolicy.p7b from EFI partion
Enable Secure Boot in BIOS
Restart device

But when I look at your "Clear-UEFI_Lock.bat" you do a bunch of things to unlock the UEFI.

Code:

@echo off
mountvol X: /s
copy %WINDIR%\System32\SecConfig.efi X:\EFI\Microsoft\Boot\SecConfig.efi /Y
bcdedit /create {0cb3b571-2f2e-4343-a879-d86a476d7215} /d "DebugTool" /application osloader
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} path "\EFI\Microsoft\Boot\SecConfig.efi"
bcdedit /set {bootmgr} bootsequence {0cb3b571-2f2e-4343-a879-d86a476d7215}
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} loadoptions DISABLE-LSA-ISO
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} device partition=X:
mountvol X: /d

Is what you do in your script taken care by the "disable Secure Boot" in MS instrcutions ?
What am I missing or what is MS not telling in their documentation...

garlin · Jun 7, 2026

Virtualization Based Security (VBS) and Code Integrity are umbrella terms for a set of kernel-level security features sitting on top of Secure Boot. If you have Secure Boot enabled, it guarantees a certain baseline of security (booting from a trusted Windows file) and VBS checks if your CPU has specific security features available at the HW level.

After recognizing these HW features are available, VBS/CI can then operate in certain ways because they know those HW features can assist them in maintaining system integrity (tamper proofing).

Normally these features are managed at the UI level (from the Security Center) or by GPO or reg values. The problem with GPO's or reg values is an attacker could gain admin rights and silently disable DeviceGuard (VBS) or CredentialGuard (LSASS). If you have HW support, Windows can transfer control over enabling/disabling these features to the UEFI. Instead of allowing an attacker to change settings on the running Windows, Windows will consult the UEFI variables at boot time and decide whether to run in enhanced security mode.

This is the "UEFI lock". Control over running DeviceGuard or CredentialGuard is determined by UEFI settings, and not by Windows. Which means if you want to return control back to the user, the UEFI lock must be cleared.

A special bootable EFI file was created, which can be queued and executed by the boot manager. This program confirms if you want to remove the UEFI lock. Because the EFI app requires human input (you must hit F3 to confirm), it can't be scripted by attackers.

The batch file follows the MS directions to make an one-time change to the boot manager, and boot into the EFI security tool. After the EFI program exits, we return to our normal boot settings. So if you fail to hit F3 and cancel out, there's no way to return. You must run the script again to add another on-time boot record as before.

Disable Credential Guard with UEFI lock

In the past, you wouldn't have to worry about these matters because only highly technical security pros would manage these settings. But with a new focus on improving Windows baseline security, it's far easier on modern CPU's to have all of these protections activated by default. You didn't decide to enable UEFI lock, but Windows did because your PC matched the higher HW requirements.

Do you need this batch file to help remove the SkuSiPolicy file? No, but it's useful in cases when UEFI lock is detected and you want to disable the lock. All the lock does is take the option to disable security away from Windows, and hide the setting in the UEFI variables.

anchamp65 · Jun 7, 2026

garlin said:
Do you need this batch file to help remove the SkuSiPolicy file? No, but it's useful in cases when UEFI lock is detected and you want to disable the lock. All the lock does is take the option to disable security away from Windows, and hide the setting in the UEFI variables.

Thanks for the explanations.
So...

Apply SkuSiPolicy.p7b with your update script, flag -SkuSiPolicy
Build new WinRE Macrium X boot media and patch it with bcdedit
Test to see if it works
- Works: great, done !
- Fails: copy SkuSiPolicy.p7b to EFI\Microsoft\Boot on Macrium boot media
  - If still not working, revert SkuSiPolicy.p7b changes on Windows
    - Remove SkuSiPolicy.p7b from Windows EFI partition
    - Run UEFI unlock script and reboot to press F3 to confirm

Did I get it right ?

garlin · Jun 7, 2026

You don't have to copy the SkuSiPolicy file to the USB drive. There's no point in trying to restrict yourself.

The batch file is only needed if you know UEFI lock is enabled. It doesn't hurt to run it.
But if you don't have the batch file, you can disable Secure Boot and restart Windows TWICE in a row.

Klaver7 · Jun 7, 2026

garlin said:
don't have to copy the SkuSiPolicy file to the USB drive

Thanks for comfirming that as I didnt think it was needed. But lately with all the feedback here I was in doubt.

anchamp65 · Jun 7, 2026

garlin said:
You don't have to copy the SkuSiPolicy file to the USB drive. There's no point in trying to restrict yourself.

The batch file is only needed if you know UEFI lock is enabled. It doesn't hurt to run it.
But if you don't have the batch file, you can disable Secure Boot and restart Windows TWICE in a row.

Ok, then I'm missing something...

If appliing SkuSiPolicy.p7b to a computer can prevent boot media by solutions like Macrium, how are we to resolve the issue other then removing SkuSipolicy.p7b and unlocking the BIOS and not being as secure as can be ?

Or I've completely misunderstood all your explanations on SkuSiPolicy.p7b............

Again, I need your wisdom

Or more realistically and less wizardly... your knowledge

garlin · Jun 7, 2026

Normally, the enforced SkuSiPolicy file lives on the same EFI volume as your active boot manager.

This way the boot manager can use the SkuSiPolicy for any device that's booting, whether it's an internal drive or external USB. It wouldn't make sense to locate a SkuSiPolicy on a bootable USB device, because why would you install a policy file that could block yourself from booting?

The boot manager shouldn't be hunting around for random devices to find its policy file. That would be an open security risk.

Typically if you have installed Windows on a system, there is a boot manager entry in the BCD store. If the system is wiped out, there isn't a working boot manager entry so the BIOS has to go searching the next available devices looking for the first valid boot manager or boot file. You would not want to interfere with that process since booting from the install or recovery media is designed to be a temporary step.

wabbit · Jun 7, 2026

garlin said:
It's been there for months. If you don't have it configured, the SBatLevel reg variable is filled with fake data ("!SBATnotfound").

I got the SBAT key in the registry on the HP laptop. I just ran it from a command prompt and opted out. I'm lot likely to ever use Linux on that laptop.

anchamp65 · Jun 7, 2026

garlin said:
Normally, the enforced SkuSiPolicy file lives on the same EFI volume as your active boot manager.

This way the boot manager can use the SkuSiPolicy for any device that's booting, whether it's an internal drive or external USB. It wouldn't make sense to locate a SkuSiPolicy on a bootable USB device, because why would you install a policy file that could block yourself from booting?

The boot manager shouldn't be hunting around for random devices to find its policy file. That would be an open security risk.

Typically if you have installed Windows on a system, there is a boot manager entry in the BCD store. If the system is wiped out, there isn't a working boot manager entry so the BIOS has to go searching the next available devices looking for the first valid boot manager or boot file. You would not want to interfere with that process since booting from the install or recovery media is designed to be a temporary step.

Ok, then the boot process, even when booting from Macrium recovery USB media, still uses the EFI partition on my internal SSD, understood !

Then how would appliing SkuSiPolicy.p7b interfere with recovery boot media of software like Macrium if it's always on the EFI partition ?

I do understand that if I use Macrium to restore a system that brings it back to a state before SkuSiPolice.p7b is applied to the EFI partitation, then I would need to clear the BIOS lock to be able to boot. But in what circumstances would it interfere with Macrium recovery boot media not being able to boot ?

I'm probably still missing the point... sorry...

Or maybe when you mentioned multiple times "SkuSiPolicy.p7b can interfere with external USB boot media" you always ment it can become more trouble if we restore to an image (backup) that includes the EFI partition in state that it did not have the SkuSiPolicy.p7b applied to it

garlin · Jun 7, 2026

You could have a messed up Windows volume that doesn't work, but as a long as your EFI volume has a working boot manager then it has priority when booting from a device.

Read this thread, and try to understand the problem description.
Macrium Reflect X Home Rescue USB Fails to Boot Without C Drive Present (Dell Optiplex 7070, CA 2023)

C: drive present -> EFI present -> EFI boot manager present -> looks for SkuSiPolicy
no C: drive present -> no EFI present -> USB boot file used

The USB drive has no free will as long as the boot manager listed in the UEFI is functional.

anchamp65 · Jun 8, 2026

garlin said:
Read this thread, and try to understand the problem description.
Macrium Reflect X Home Rescue USB Fails to Boot Without C Drive Present (Dell Optiplex 7070, CA 2023)

garlin said:
2. Check if you have a SkuSiPolicy file, the script will report if you have one. This might need to be removed, as it can interfere with bootable USB drives when the base version of WinRE/WinPRE isn't what the policy file allows.

First, thanks for taking time to answer my questions

I read the other thread you suggested.
It was getting clearer until you responded "2. Check if you have a SkuSiPolicy file, the script will report if you have one".
I assume you assumed the user might have copied the SkuSiPolicy to the USB recovery drive...

Here's what I understand so far, tell me if I'm getting it:

If you try and restore an image to a different computer, it could failt if the SkuSiPolicy was present on the source computer and not present on the target computer, policy check mismatch. But still not sure about this if the target computer has never had SkuSiPolicy applied to it, why would it block the Marcrium recovery USB drive... ?
If you try and restore an image on the same computer but you removed/disconnected the drive that contains the EFI partition that the boot manager expects to find, the boot will fail. That's because the computer's UEFI is looking for the SkuSiPolicy and it's nowhere to be found.
You could mess with having the SkuSiPolicy on the USB drive, but much simpler in situtations where SkuSipolicy is blocking boot for the USB drive to just temporarily disable Secure Boot.

So as long as I restore a Macrium Image (or any other imaging solution) on the same computer that still has the EFI partition that contains the SkuSiPolicy, Macrium's recovery USB drive will boot properly. But I still need to be carefull not to restore an image with the EFI partition before I added the SkuSiPolicy or I will need to unlock the BIOS with the unlock script or disable secure boot and boot Windows twice in a row. And re-enable Secure Boot once I've reapplied the SkuSiPolicy the the EFI partition.

In my case, if I ever have to move to another computer, I would never use an image restore and simply reinstall Windows on the new hardware.

PS: I placed a ticket with Macrium over 2 weeks ago and they just replied. They also suggested I place a feature request ticket which I just did.

To confirm what you're experiencing: the May 2024 Windows Secure Boot update (which revoked the CA 2011 certificate and enforced CA 2023) has broken the boot process for rescue media created by Reflect X unless the BCD is manually corrected using the steps you've outlined. We are aware of this compatibility issue.

For now, your workaround is the correct approach, and we'd recommend others in the same situation follow those steps:

```
copy X:\EFI\MICROSOFT\BOOT\BCD X:\EFI\MICROSOFT\BOOT\BCD.BAK
bcdboot c:\windows /f UEFI /s X: /bootex
copy X:\EFI\MICROSOFT\BOOT\BCD.BAK X:\EFI\MICROSOFT\BOOT\BCD
```

Regarding your feature suggestions: automatic SVN checking and rescue media validation are well-considered proposals, and we will pass them to our engineering team.

garlin · Jun 8, 2026

UPDATE: 2026-06-08

1. Scripts don't properly recognize when BIOS is configured for CSM mode
2. Update_UEFI-CA2023.ps1 will fail to replace CA 2011 boot manager, whenever the staged boot manager has a higher SVN
3. Optimize Match-DBXSignatureData performance by determining SVN's only when needed
4. May 2026 Preview may have removed [HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\SBAT]

garlin · Jun 8, 2026

anchamp65 said:
Here's what I understand so far, tell me if I'm getting it:

If you try and restore an image to a different computer, it could failt if the SkuSiPolicy was present on the source computer and not present on the target computer, policy check mismatch. But still not sure about this if the target computer has never had SkuSiPolicy applied to it, why would it block the Marcrium recovery USB drive... ?

If you try and restore an image on the same computer but you removed/disconnected the drive that contains the EFI partition that the boot manager expects to find, the boot will fail. That's because the computer's UEFI is looking for the SkuSiPolicy and it's nowhere to be found.

You could mess with having the SkuSiPolicy on the USB drive, but much simpler in situtations where SkuSipolicy is blocking boot for the USB drive to just temporarily disable Secure Boot.

So as long as I restore a Macrium Image (or any other imaging solution) on the same computer that still has the EFI partition that contains the SkuSiPolicy, Macrium's recovery USB drive will boot properly. But I still need to be carefull not to restore an image with the EFI partition before I added the SkuSiPolicy or I will need to unlock the BIOS with the unlock script or disable secure boot and boot Windows twice in a row. And re-enable Secure Boot once I've reapplied the SkuSiPolicy the the EFI partition.

In my case, if I ever have to move to another computer, I would never use an image restore and simply reinstall Windows on the new hardware.

1. Your source PC has a SkuSiPolicy deployed to the EFI, so it must enforce the policy.

2. Your imaging software captures the EFI, either within an entire raw disk image or specifically capturing the EFI volume. There is a SkuSiPolicy captured in the backup image.

3. Your target PC may or may not have a working boot manager. If the PC's boot manager works, then it checks for a local SkuSiPolicy file on the EFI volume.

When none exists, there is no restriction on booting from your recovery USB (other than normal Secure Boot cert rules). When one exists, this PC's SkuSiPolicy doesn't have to be the same as the source PC's version. It could be an older or newer policy. Your USB drive could be blocked because this boot manager is following a different set of policy rules (file versions).

4. Assuming you're allowed to boot the recovery media and begin a restore, the application will overwrite the target PC's EFI volume and restore the source PC's files. Which may or may not have been different from the target PC's original setup.

That restored SkuSiPolicy (if captured in the backup and restored) only takes effect when you reboot into the restored Windows.

A SkuSiPolicy file doesn't randomly show up in the EFI volume. Something or someone has to put it there. In all cases , temporarily disabling Secure Boot gets you out of trouble because there is no policy enforcement without Secure Boot mode.

anchamp65 · Jun 8, 2026

garlin said:
A SkuSiPolicy file doesn't randomly show up in the EFI volume. Something or someone has to put it there. In all cases , temporarily disabling Secure Boot gets you out of trouble because there is no policy enforcement without Secure Boot mode.

So bottom line, I can enable SkuSiPolicy on my computers and gain even more security.
If I get stuck for whatever reason with SkuSiPolicy, I can simply disable Secure Boot temporarily get everything working and reapply SkuSiPolicy afterwards if needed.

All instructions are here: Guidance for blocking rollback of Virtualization-based Security (VBS) related security updates

Got it !
Thanks

Klaver7 · Jun 8, 2026

Code:

mountvol z: /s

copy /y z:\EFI\Boot\bootx64.efi f:\EFI\Boot\bootx64.efi

copy /y z:\EFI\Microsoft\Boot\bootmgfw.efi f:\EFI\Microsoft\Boot\bootmgfw.efi

mountvol z: /d

This still works fine for me but couple a weeks ago I ran Parted Magic to Secure Erase Drive C: and afterwards I wanted to boot up with Macrium to let a backup loose Yeah Right = No GO, No USB with UEFI 2023 cert would boot, even worse nothing would boot till I turned Secure Boot Off! After that I could release my backup and rebooted into the BIOS to turn Secure BOOT back on / Custom to Standard etc.
Booted back into Windows and ran Update_UEFI-CA2023.ps1 -Revoke to get back to "normal". My question is" without an OS on the PC - turning off Secure Boot is the way ?
Running 25H2 26200.8457

garlin · Jun 8, 2026

You're in a similar situation with @anchamp65.

1. Secure Boot OFF -> No boot enforcement based on the signing certs. If you have a SkuSiPolicy on the EFI pointed to by BCD store as your boot manager, it's not enforced.

2a. Secure Boot ON -> Boot enforcement based on your signing certs. Your boot manager or boot file may be blocked.

2b. Secure Boot ON -> Boot manager is allowed, and it wants to run winload.efi as the next step in the boot process. winload.efi is the one actually starting Windows itself. Boot manager is sort of a broker. SkuSiPolicy enforcement may kick in and block winload.efi because it's the "wrong" version as determined by the SkuSiPolicy.p7b file. Often this is caused by a mismatch of your outdated WinRE image used to create the USB drive.

In your case, I would guess deleting SkuSiPolicy.p7b from the EFI would have allowed the recovery USB to boot, without having to touch Secure Boot certs. These are two different security strategies, which happen in close proximity to each other.

UEFI cares that the current set of Secure Boot certs allows your signed boot manager to run.
Windows boot manager may need to enforce SkuSiPolicy and not allow the winload.efi in your Windows system drive or USB recovery drive to run.

In a lot of security work, there is defense-in-depth. Which means you don't just trust one security restriction to protect you, but you depend on a series of restrictions to provide better protection in case one of them isn't enough to stop an attacker.

If your USB drive was based on a fully compliant WinRE image (the right file versions), then you wouldn't be blocked by having SkuSiPolicy. This is my complaint about the backup vendors, they're slow to catch up to this new world whether these details matter. It's not just Secure Boot any more, it's also if SkuSiPolicy will show up in the user's environment.

This is why I wrote another script to check for this.

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

Well-known member

My Computers My Computers

At a glance

At a glance

Well-known member

My Computer My Computer

At a glance

Well-known member

My Computers My Computers

At a glance

At a glance

Well-known member

My Computer My Computer

At a glance

Active member

My Computer My Computer

At a glance

Well-known member

My Computer My Computer

At a glance

Active member

My Computer My Computer

At a glance

Well-known member

My Computer My Computer

At a glance

Member

My Computer My Computer

At a glance

Active member

My Computer My Computer

At a glance

Well-known member

My Computer My Computer

At a glance

Well-known member

My Computers My Computers

At a glance

At a glance

Active member

My Computer My Computer

At a glance

Well-known member

My Computer My Computer

At a glance

Active member

My Computer My Computer

At a glance

Well-known member

My Computer My Computer

At a glance

Well-known member

My Computer My Computer

At a glance

Active member

My Computer My Computer

At a glance

Member

My Computer My Computer

At a glance

Well-known member

Attachments

My Computer My Computer

At a glance

My Computers

My Computer

My Computers

My Computer

My Computer

My Computer

My Computer

My Computer

My Computer

My Computer

My Computer

My Computers

My Computer

My Computer

My Computer

My Computer

My Computer

My Computer

My Computer

My Computer