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

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

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.

Click to expand...

Very appreciative of your review and details .

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?

Click to expand...

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.

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.

Click to expand...

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

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.

Click to expand...

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?

Click to expand...

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.

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.

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.

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.

Click to expand...

Does 0x20 work again?

That's still in kb5042562:

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.