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

1. Bucket Confidence Data is for IT admins, who manage large pools of PC's. It's not intended to be read by home users because it's a telemetry report. This event indicates you have installed all CA 2023 certs.

2. I don't support this script, it's not mine. I know why the other script is wrong, and my output has more correct details. Please install the ZIP file (not the GitHub from post #1).

garlin said:

1. Bucket Confidence Data is for IT admins, who manage large pools of PC's. It's not intended to be read by home users because it's a telemetry report. This event indicates you have installed all CA 2023 certs.

2. I don't support this script, it's not mine. I know why the other script is wrong, and my output has more accurate details.

Click to expand...

My bad! right now it is from your script.

Thanks. You have all of the CA 2023 certs, but not revoked CA 2011 (no DBX entries).

1. You have the option to wait for Windows to revoke the certs this summer, or run the commands now.

2. SkuSiPolicy is an optional policy which can be copied to the EFI partition for extra security, but some users have experienced problems if they use a dual-boot setup with a different Windows version, and sometimes with an USB recovery drive from Macrium or other backup vendors.

If you don't have this setup, then you can apply the SkuSiPolicy using the update script:

3. April 2026's Monthly Update released newer versions of DBXupdate.bin with only 278 EFI signatures instead of the old 431. MS deleted 151 signatures which are no longer needed if you're revoking the CA 2011 cert. This saves space in the NVRAM on older BIOS'es. The missing signatures are all owned by obsolete Windows boot files.

garlin said:

In some boot scenarios, the UEFI is looking for bootmgfw.efi and when it cannot find it, looks for bootx64.efi.

Click to expand...

You probably know this, but many users wonder why there are two similar files in the EFI partition with different names.

In short:
- \EFI\Microsoft\Boot\bootmgfw.efi is launched via a firmware boot entry stored in NVRAM.
- \EFI\Boot\bootx64.efi is the standard fallback path defined by the UEFI specification, used when no suitable boot entry is found.

---

How does Windows boot from a GPT disk without a "Windows Boot Manager" entry in the system's UEFI firmware?

Google Gemini:

It might feel like a bit of a magic trick — the computer starts up, finds Windows, and launches it, even though the UEFI boot menu looks empty. Usually, Windows creates a specific "Windows Boot Manager" entry in the NVRAM (non-volatile RAM) during installation, but it doesn't actually need it to function.

Here is how your system manages to boot without that specific pointer.

1. The "Fallback" Path: The Default Boot Loader

UEFI systems are programmed with a standardized search order. If no specific boot entries (like "Windows Boot Manager") are found in the NVRAM, the firmware looks for a "fallback" file on any FAT32 partition marked as an EFI System Partition (ESP).

The firmware searches for a file at this specific hardcoded path:

\EFI\BOOT\BOOTX64.EFI

When Windows is installed, it places a copy of its bootloader at that location. Even if the firmware "forgets" the formal Windows entry, it will eventually stumble upon this file during its hardware scan and execute it, which then kicks off the Windows startup process.

2. The EFI System Partition

For a GPT disk to be bootable, it must contain an EFI System Partition. This is a small partition — typically 100–500 MB — formatted as FAT32. The UEFI firmware can read FAT32 natively, allowing it to browse the files on the drive before any operating system is loaded.

Inside this partition, Windows stores:

Code:

\EFI\Microsoft\Boot\bootmgfw.efi — Windows Boot Manager
\EFI\Boot\bootx64.efi            — Fallback bootloader
\EFI\Microsoft\Boot\BCD          — Boot Configuration Data (boot settings database)

3. Removable Media Logic

The reason this "fallback" exists is primarily for USB drives and installation media. Since a thumb drive doesn't have a permanent entry in your computer's motherboard memory, the UEFI spec requires that the firmware can find an OS just by looking for that BOOTX64.EFI file. Windows simply uses this same logic on your internal drive to ensure the system remains bootable even if the NVRAM is cleared (e.g., after a BIOS update or a CMOS battery failure).

Click to expand...

How to Fix a Missing "Windows Boot Manager" Entry

While the system will boot correctly using the fallback method, you can manually restore the standard "Windows Boot Manager" entry using the bcdboot command from within Windows.

Open Command Prompt as Administrator, and run the following command:

bcdboot c:\windows

This command scans the Windows installation on C:, copies the necessary boot files to the EFI system partition, and re-registers the "Windows Boot Manager" entry in your UEFI firmware.

According to Microsoft: "By default, BCDBoot creates a Windows Boot Manager entry in the NVRAM on the firmware to identify the boot files on the system partition. If the /s option is used, then this entry is not created. Instead, BCDBoot relies on the default firmware settings to identify the boot files on the system partition. By the UEFI 2.3.1 spec, the default firmware settings should open the file: \efi\boot\bootx64.efi in the EFI System Partition (ESP)."

BCDBoot Command-Line Options - Microsoft Learn

Sometimes you have to be careful about running bcdboot. It can accidentally destroy the WinRE boot entries so your WinRE is "gone". The partition and its files are there, but Windows forgot where it went. I discovered this the hard way while testing my scripts.

Run "reagentc /info" to check if WinRE can find itself.

If your WinRE has gone missing, run this PS script to recreate the missing WinRE entry. The script requires a reboot, so reagentc can register itself after the boot manager has updated itself.

Hey @garlin

After reading this page from Microsoft, I think people using imaging software like Macrium, Veeam, Paragon, etc, should probably not enforce SkuSiPolicy.p7b policy. This would avoid a case where we would want to revert Windows to a previous state saved by our imaging software and not be able to boot because the policy is not up to date on the image used to restore Windows to a previous state.

Also, due to the fact that once the policy is actvated, Windows update could update it anytime (but more likely on monthly updates) and render an image taken just a few days or weeks before unbootable.

What's your take on this ?

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

On the plus side, at the very bottom the page shows how to remove the policy if we ever get stuck...

Thanks in advance...

garlin said:

I discovered this the hard way while testing my scripts.

Click to expand...

Hard lessons, no one escapes it !
Even you !

While SkuSiPolicy has good intentions, it can create new problems.

It provides a backup solution in case something disables Secure Boot. Windows is still restricted by policy to only allow certain types of boot files to work.

But it's an opaque file. Most people can't read the policy that's encoded, nor can they tell that a given boot file passes the test. The only way to find out is to trying booting from a system disk or USB drive, and finding out whether it works. That's a terrible situation.

We don't have a simple online method of checking (from your current SkuSiPolicy) that your current boot file (maybe it's a little older) passes the test. So everyone who uses a recovery drive ends up playing whack-a-mole and constantly replaces their boot files every few months. Whenever MS quietly fixes a security hole in the boot manager.

For some users, the SkuSiPolicy won't lock you out. The combination of policy rules and your boot file are compatible.

It's not for other people, as the many stories confirm. Even worse is when Windows adds an UEFI lock, to prevent the casual replacement or removal of the SkuSiPolicy.p7b file from the EFI partition. Anyone who gets Admin rights, can modify the EFI filesystem including attackrs. If you try bypassing the lock, it stops you from booting.

This can be fixed by temporarily disabling Secure Boot, and rebooting. Windows will detect Secure Boot wasn't enforced (you disabled it) and clear out the locking mechanism because a non-Secure Boot mode means users can "tamper" with security settings. So your current state can't be trusted, and the lock is removed.

Right now, the only simple solution is to check the boot media's boot file matches whatever is in the SecureBootUpdates folder. That's where Windows gets the SkuSiPolicy file. When the boot manager gets a security fix then the boot files, SkuSiPolicy and the SVN number get updated in sync.

The problem is there's not a standardized strategy across the backup vendors to keep track of these changes. It would be nice if Macrium started up and reminded you "Hey the boot manager changed since last time, do you want to create/update your USB drive?"

Users probably want MS to fix its security issues, including the boot manager. But the cost of fixing it means other tools need to adopt better automation so you're not required to read ElevenForum and be told "time to update again".

anchamp65 said:

Hey @garlin

After reading this page from Microsoft, I think people using imaging software like Macrium, Veeam, Paragon, etc, should probably not enforce SkuSiPolicy.p7b policy. This would avoid a case where we would want to revert Windows to a previous state saved by our imaging software and not be able to boot because the policy is not up to date on the image used to restore Windows to a previous state.

Also, due to the fact that once the policy is actvated, Windows update could update it anytime (but more likely on monthly updates) and render an image taken just a few days or weeks before unbootable.

What's your take on this ?

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

On the plus side, at the very bottom the page shows how to remove the policy if we ever get stuck...

Thanks in advance...

Click to expand...

I do not use that in MR X.

Josey Wales said:

I do not use that in MR X.

Click to expand...

You mean that since you use Macrium X, you do not apply the SkuSiPolicy ?

garlin said:

Users probably want MS to fix its security issues, including the boot manager. But the cost of fixing it means other tools need to adopt better automation so you're not required to read ElevenForum and be told "time to update again".
...

Click to expand...

I kept a bookmark on your post #1380 where you suggest to check ourself
I might just do that since I rely heavily on my images saving my ass if I have brain fog and paint myself in a corner

anchamp65 said:

You mean that since you use Macrium X, you do not apply the SkuSiPolicy ?

Click to expand...

I do not use VBS

Josey Wales said:

I do not use VBS

Click to expand...

That screen is referring to VBScript, a programming language that's deprecated and going away. Some tools like to use VBScript to create "silent" batch files that don't show anything on-screen while they're running in the background. Otherwise you may see a CMD window flash on the desktop.

Virtualization Based Security (also referred to as VBS) has other names like Core Integrity and Device Guard. It's the part of Windows that handles file security at the boot level. Sadly, unrelated to VBScript.

garlin said:

That screen is referring to VBScript, a programming language that's deprecated and going away. Some tools like to use VBScript to create "silent" batch files that don't show anything on-screen while they're running in the background. Otherwise you may see a CMD window flash on the desktop.

Virtualization Based Security (also referred to as VBS) has other names like Core Integrity and Device Guard. It's the part of Windows that handles file security at the boot level. Sadly, unrelated to VBScript.

Click to expand...

I have read that since I am using MR X Paid that I am OK.

Some PC's will not get a BIOS update. But your OEM was kind enough to sign the KEK CA 2023, and submit it to MS.

Windows searched its database of known KEK's, and matched one against your BIOS. Now the entire update process is guaranteed to work unless you have some bizarre BIOS glitch. Your PC is now eligible to complete the update process, entirely driven by the Secure Boot task.

If you take no action, all the CA 2023 certs and a new boot manager will be added for you. Revocation hasn't happened on your PC. Right now, either boot file is eligible (old CA 2011 and new CA 2023). Until the day CA 2011 is revoked (this summer), you can happily boot anything without worries.

When revocation comes, you'll have to mind what boot file version is on your USB drives.

@garlin,

Just wanted to take a moment & say thanks for posting the scripts, they did help.

Don't know if this will help some folks out or not, but even after I d/l ed the new cert, (I went with option 2), the PC still booted from the old cert. After a few reboots, I revoked the permissions for the old one to finally get it to boot from the new one.

So if Microsoft start revoking 2011 certs, will devices start failing to boot if they haven't been updated?

saint_david said:

So if Microsoft start revoking 2011 certs, will devices start failing to boot if they haven't been updated?

Click to expand...

PCA 2011 cert will only be revoked if Windows can install the CA 2023 certs. They're not going to brick your Windows.

If you're stuck with an unsupported PC and take no action, Windows will probably install a series of more annoying reminders in future updates that your PC is insecure and you should fix it. What MS really means is if your vendor has dropped support... maybe buy a new PC.

Setup Mode is available for most brand name PC's (they have the most normal version of BIOS'es). I've heard some off-brand PC's don't allow users to play around in the BIOS. But those are usually ultra cheap mini PC's.

@garlin

Applying certificates to an Hyper-V VM Win11 Pro 25H2 build 26200.8246 and all windows updates applied.

Check_UEFI said to set regkey to 0x5944, so everything needs to be done
Set regkey and ran task, copiing your suggested commands to avoid typos
Applied regkey and ran Secure-Boot-Update task multiple times and rebooting after each time

Check-UEFI kept saying to set regkey to 0x5800
After every reboot, regkey would be at 0x4000, so as your script checks:

I finally ran Update-UEFI which fixed it.

Any idea why just setting the regkey and running the task did not do all the updates ?
Should I have waited a few hours / days for Windows to perform all updates ?

PS: if you need me too, I can bring the VM back to what it was before and send you the check -verbose -audit output...

anchamp65 said:

After every reboot, regkey would be at 0x4000, so as your script checks:

​

[Microsoft UEFI CA 2023] is missing from UEFI DB​

[Microsoft Option ROM UEFI CA 2023] is missing from UEFI DB​

I finally ran Update-UEFI which fixed it.

Any idea why just setting the regkey and running the task did not do all the updates ?
Should I have waited a few hours / days for Windows to perform all updates ?

Click to expand...

0x4000 is the troublemaker that makes Secure Boot task get "stuck" on pending updates, and it never clears the 0x4000 when it's done...

Windows only needs KEK CA 2023 and Windows UEFI CA 2023 to properly boot.

Microsoft UEFI CA 2023 is for Linux, and Option ROM supports some HW devices. They're optional certs which aren't required to run Windows (except for the Option ROM if you have a GPU that has signed ROM's).

MS doesn't want to blast those certs to everyone since in managed environments (large companies), they may object to having Microsoft UEFI CA 2023 for security reasons. They want to prevent unauthorized OS'es, which means no unregulated Linux systems. 0x4000 forces the Secure Boot task to confirm whether the older CA 2011 versions of the same certs were registered in DB, and only install them if the old certs were present.

Secure Boot task will sometimes sit around waiting for the next reboot, before taking action. And once it's done, it won't clear the 0x4000 from AvailableUpdates. These actions are by deliberate design from MS. If I were doing it manually, I wouldn't bother adding the 0x4000.

So why does my check script instruct you to include the 0x4000? To make it backwards compatible with MS.

There is always someone who thinks they understand the update process more than you, who wants to argue over the necessity of including 0x4000. Because MS says so. I got tired of explaining it. The update script says "this is utter nonsense" and just applies the certs without delay, because it doesn't depend on the Secure Boot task like other update scripts.