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

cool59 · Jul 15, 2026

Hello,
Just out of curiosity:
Following Microsoft's latest update yesterday, the Secure Boot status message changed from "more data needed" to "High Confidence."
I wonder how this is possible, given that the last available BIOS update for my old Dell XPS 13 9360 was released in 2021, and i needed performed the update using @garlin's scripts, even having to set the BIOS to "Custom Mode," and leave it that way as the PC wouldn't boot otherwise.
I'm updated thanks to @garlin but how would Microsoft have performed the update if I required manual BIOS intervention to carry it out?

Best regards

MachineLanguage · Jul 15, 2026

garlin said:
Your BIOS has all of the CA 2023 certs installed, but CA 2011 has not been revoked (it's still optional for now). This PC is good for now.

Someone mentioned that a recent Beelink BIOS update added CA 2023 support. So it's always important to check for recent BIOS updates, in case your OEM has already added the CA 2023 certs into the firmware.

Very appreciative of your review and details .

garlin · Jul 15, 2026

cool59 said:
Following Microsoft's latest update yesterday, the Secure Boot status message changed from "more data needed" to "High Confidence."
I wonder how this is possible, given that the last available BIOS update for my old Dell XPS 13 9360 was released in 2021, and i needed performed the update using @garlin's scripts, even having to set the BIOS to "Custom Mode," and leave it that way as the PC wouldn't boot otherwise.
I'm updated thanks to @garlin but how would Microsoft have performed the update if I required manual BIOS intervention to carry it out?

MS could have changed the status on their end, if they were informed either a newer BIOS was released (less likely on a 2021 PC), or Dell submitted a signed KEK instead of a BIOS update (more likely).

A BIOS update is always preferred, since any factory reset means you still have the CA 2023 certs installed. But a signed KEK file effectively does the same thing, and the update process can be repeated.

But honestly the whole Confidence Bucket thing is a black box, because MS refuses to divulge any statistics on their collected data. Other than sharing a giant list of unique combinations of PC motherboards & BIOS versions they've observed in the wild. And they won't inform you why they suddenly decided your PC is now in High Confidence after months of being in More Data Needed.

IMO it's better just to update a PC using whatever means works, and if the vendor catches up later... great.

neldog · Jul 15, 2026

garlin said:
To prevent attackers from rolling back to an earlier file version, Windows has two different checks:

SVN -> Windows boot manager's SVN
SkuSiPolicy.p7b -> winload.efi's file version

If you have a SkuSiPolicy file deployed, this means you will have to rebuild your WinRE-based boot media (again). This is the price of keeping up with Windows boot security.

Hi Garlin, after installing this month's WU and then running the Check UEFI CA2023 script - verbose, I got "SkuSiPolicy.p7b Version: 3.0.0.15 and that was not matching. So, I ran the update script and got this below and it changed it to 3.0.0.16. Now all is good.

Is this what you mean when saying "we" will be required to rebuild the WinRE-based boot media "ourselves"? And that this will need to be done with each WU, (if the SkuSiPolicy.p7b Version changes)? Microsoft, in the future, will not do this automatically?

Thanks...

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

garlin · Jul 15, 2026

neldog said:
Hi Garlin, after installing this month's WU and then running the Check UEFI CA2023 script - verbose, I got "SkuSiPolicy.p7b Version: 3.0.0.15 and that was not matching. So, I ran the update script and got this below and it changed it to 3.0.0.16. Now all is good.

I don't know if the Secure Boot task has responsibility for pushing a new SkuSiPolicy, whenever a new version appears. There's a hidden AvailableUpdates value (0x20) that manually controls that behavior, but Windows may not do this update automatically.

As I've highlighted before, forcing a new SkuSiPolicy before you're ready has bad consequences

neldog said:
Is this what you mean when saying "we" will be required to rebuild the WinRE-based boot media "ourselves"? And that this will need to be done with each WU, (if the SkuSiPolicy.p7b Version changes)? Microsoft, in the future, will not do this automatically?

Why would MS update your boot media? It's not something created by MS, nor would it be expected that your boot drives are always plugged in. Also you could have an USB drive that's intended for another PC, which hasn't been updated in the same way.

Does updating your drives suck? Yes. But I've said this many times, Macrium and Hasleo (plus whoever else) has to get off their butts and adapt to the new world order. Rufus is already aware of SVN and SkuSiPolicy.

The backup vendors need to update their products to check once a day (in case you've just installed a new Monthly Update), and confirm if the SVN or SkuSiPolicy has changed since the last time you created a recovery drive. If either of them have changed, they should provide a courtesy notification to make a new recovery drive. And after you've recreated the drive, reset the check until the next time either one gets updated again.

None of this is MS's problem. The only major MS app that creates a bootable USB is MCT.

neldog · Jul 15, 2026

I'm sorry - I did a poor posting of what I am wondering about. I got "my" boot media part all straighten out, and that is not a problem for me. I check and do that easily enough when needed.

I guess what I was trying to ask about is the SkuSiPolicy version changing with this month's WU and then displaying as not being current in the -Verbose output I ran after the WU, requiring me to run the update SkuSiPolicy script once again to make the WU version match what is on my system after the WU update. This what I am not clear on. Will I need to update the policy version myself with each WU from now on out, that is my question. Thanks.

garlin · Jul 15, 2026

I believe the Secure Boot task is cautious, and doesn't automatically push the newer file unless you use a specific AvailableUpdate value of 0x20.

t2s50 · Jul 15, 2026

garlin said:
I believe the Secure Boot task is cautious, and doesn't automatically push the newer file unless you use a specific AvailableUpdate value of 0x20.

Does 0x20 work again?

That's still in kb5042562:

garlin · Jul 15, 2026

That might explain it, I missed that warning from the Dec 2025 release notes. Sigh, why can't a MS-written tool do this?

It's also interesting that MS's example tries to create a "\EFI\Microsoft\Boot" folder if needed. That would imply the original bcdboot action to provision the active EFI volume failed, or something clobbered it.

So you would have a worse problem on your hands than just have no (updated) SkuSiPolicy in place.

AK6DN · Jul 15, 2026

Not strictly on topic, but interesting given the subject matter of this thread ...

Microsoft’s Secure Boot has been broken for a decade and no one noticed until now

Old and forgotten "shims" Microsoft failed to revoke have made Secure Boot bypasses simple.

arstechnica.com

garlin · Jul 15, 2026

AK6DN said:
Not strictly on topic, but interesting given the subject matter of this thread ...

Microsoft’s Secure Boot has been broken for a decade and no one noticed until now

Old and forgotten "shims" Microsoft failed to revoke have made Secure Boot bypasses simple.

arstechnica.com

The UEFI Forum (an industry group) has designated MS one of their "keepers of the DBX list", where MS hosts the reference copy on their Secure Boot Objects GitHub. Other industry players are supposed to consult this list when creating an updated BIOS image.

There's several aspects to this problem:

1. Someone has to decide which boot files are banned, based on previous security reports. MS appears to work with some of the leading Linux folks (hughsie for example) to co-ordinate the list's contents. MS is primarily responsible for maintaining it's own list of banned Windows boot files, and originally added 151 examples after the Black Lotus rootkit was exposed.

It's up the Linux community to submit non-MS files to the DBX list. MS takes their submissions and makes periodic updates, which are published on GitHub. The bulk of the DBX list is mostly non-Windows boot files of various types.

2. Due to concerns about the exhaustion of limited NVRAM space in older flash EEPROM's, it's preferred that individual file entries be avoided if it can be handled by the SVN (Windows) or SBAT (Linux) versioning methods. Using SVN or SBAT allows you to ban a whole series of (newer) boot files if they're written to obey the SVN or SBAT version rules.

But that doesn't cover all of the older boot files which were published before SVN or SBAT were popularized. This is where a vulnerable shim loader can get overlooked (because it was supposed to be banned before the repo was started in 2023), and nobody notices it's missing.

If you look at the GitHub commit activity, there's a lot of back and forth with outsiders making recommendations on what entries should be published and how the list is to be presented. MS is spending a lot of effort on trying to automate the submission process, and making more of the metadata available in parseable form. So other folks can write tools to compare the repo's entries against their own reference lists.

It's probably not perfect, but MS seems to be moving in the right direction. Albeit the GitHub review process runs at a snail's pace. :sleepy:

gunrunnerjohn · Jul 16, 2026

Anyone that thinks any software as complex as Windows is totally "hack-proof" for all time is deluding themselves. It's inevitable that at some time someone will find a crack to wiggle through.

garlin · Jul 16, 2026

This wasn't a Windows problem. The DBX list is for all UEFI's, regardless of your OS. It can cover EFI tools that run without an OS, like a bootable BIOS updater or even something like Ventoy. If it boots directly from the EFI, then potentially it might need to banned.

It doesn't sound like there's a formal round table that meets regularly, where selected UEFI Forum reps and folks from MS and Linux (remember there isn't "one" Linux, so who would you invite?) vote on adding DBX entries. And it's perfectly understandable that non-MS folks don't want MS to completely own the entire process end-to-end.

The reason MS probably gets to be a keeper of the DBX is they can afford to keep more staff assigned to Secure Boot issues, and their outsized influence on PC OEM's to enforce changes. This oversight in forgetting the banned shim was more of a (people) process gap.

otnert · Jul 16, 2026

garlin said:
I believe the Secure Boot task is cautious, and doesn't automatically push the newer file

I don't get it, why introduce a newer SkuSiPolicy.p7b version and not automatically use it?

I don't recall any poster mentioning an auto upgrade.

garlin said:
unless you use a specific AvailableUpdate value of 0x20.

Maybe it was really meant for enterprise use only, where IT depts manage it in their OS images.

It's got me thinking, the importance of naming future backups, maybe something like 10.0.26200.8875-SVN9-3.0.0.16
Seems older backups will become redundant with each version bump.

garlin · Jul 16, 2026

otnert said:
I don't get it, why introduce a newer SkuSiPolicy.p7b version and not automatically use it?
I don't recall any poster mentioning an auto upgrade.

Probably because there isn't a Windows tool which checks whether a specific SkuSiPolicy.p7b file would ban the current winload.efi on your active EFI partition, or prevent a WinRE-based device from booting.

There's also the point of how would an user know there's a new SkuSiPolicy to begin with?

otnert said:
Maybe it was really meant for enterprise use only, where IT depts manage it in their OS images.

I'm sure. But MS doesn't clearly state that in their Secure Boot guidance. The current statements simply suggest users deploy SkuSiPolicy, without making any distinctions if you're in a work or home environment. It's one of those unanswered questions whether the threat level is high enough that normal users should follow the instructions.

t2s50 · Jul 17, 2026

garlin said:
Probably because there isn't a Windows tool which checks whether a specific SkuSiPolicy.p7b file would ban the current winload.efi on your active EFI partition, or prevent a WinRE-based device from booting.

winload.efi (osloader.exe) and winresume.efi (hiberrsm.exe) are located on the Windows partition, they're the first file loaded from this partition by the bootmanager.

I assume they're preparing for using more of the SkuSiPolicy.p7b- concept. Reagentc /info now gives the Winre.wim version number (no more need to mount it with DISM) and at least for Win11 25H2 it's now no longer some numbers behind, but got updated together with the July LCU:

MS is working quite a lot on the SkuSiPolicy.p7b. Compare the 3.0.0.10 version to the latest version and there are quite some additions. Version 3.0.0.10 focused solely on winload.efi (osloader.exe) and winresume.efi (hiberrsm.exe), version 3.0.0.16 has in addition
cbproxy.exe (10 entries)
ffuloader.efi (10 entries)
hvloader.efi (2 entries)
memdiag.exe (10 entries)
mmosloader.efi (10 entries)
Mobilestartup (10 entries)
resetphone.efi (10 entries)
SecConfig.efi (10 entries)
SfhRecovery.efi (8 entries)

Since there's the sideloading option (like loading memtest.efi from a correctly signed bootmanager) where memtest.efi still can be signed with a revoked cert, I assume they're going to / have to focus on those files, too.

garlin said:
There's also the point of how would an user know there's a new SkuSiPolicy to begin with?

Well, you already scripted it, didn't you. But the next question would be what was changed. From 15 to 16 the part with the recognizable filenames didn't change, for example.

x_1 · Jul 17, 2026

Hi Garlin, how can i fix this??

garlin · Jul 17, 2026

x_1 said:
Hi Garlin, how can i fix this??

Code:

Update-UEFI.bat -SkuSiPolicy

x_1 · Jul 17, 2026

garlin said:
Code:

Update-UEFI.bat -SkuSiPolicy

i'm unable to launch the command

, can you guide me further??

garlin · Jul 17, 2026

x_1 said:
i'm unable to launch the command , can you guide me further??

What error are you getting? Are you running this from a CMD or PowerShell session?

If you're in PowerShell, you may need to add the full path to the batch file.

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

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

Rancho Seldom Siesta

My Computers My Computers

At a glance

At a glance

Well-known member

My Computer My Computer

At a glance

Rancho Seldom Siesta

My Computers My Computers

At a glance

At a glance

Well-known member

My Computer My Computer

At a glance

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

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

New 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

Well-known 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

Well-known member

My Computer My Computer

At a glance

My Computer

My Computers

My Computer

My Computers

My Computer

My Computers

My Computer

My Computer

My Computer

My Computers

My Computer

My Computers

My Computer

My Computer

My Computer

My Computer

My Computer

My Computer

My Computer

My Computer