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

anchamp65 · 2026-06-11T15:25:24-0400

FYI

I found why MS task Secure-Boot-Update was exiting with 0x800706D9 error code.
I have been disabling for years the service "Connected User Experience and Telemetry" (DiagTrack) on top of having OOShutUp10 disabling all diagnostics and telemetry. I started disabling it back in XP or 7 following BlackViper suggestions, so a while ago...

Well it seems that MS Secure-Boot-Update task requires DiagTrack to be enabled.
The moment I enabled it on both Dell 3910 and SP9 Pro, task started exiting with 0x0.
So DiagTrack is staying on from now on...
I still have OOShutUp10 disabling diagnostics and telemetry.

Ed Tittel · 2026-06-11T15:32:56-0400

Still trying to get the P16 Gen 3 up to SVN 9.0. Here is output from .\update_UEFI-CA2023.ps1 -stage
WARNING: Cannot confirm if W11 26H1 (28020.2236) has the latest files.

SUCCESS: NO UPDATES ARE REQUIRED.

Copilot says the SVN 9.0 stuff needs to come from Lenovo and is not yet forthcoming. What do you say?
Thanks for all your constant effort and assistance. Much, much appreciated.
--Ed--

garlin · 2026-06-11T15:34:05-0400

anchamp65 said:
Well it seems that MS Secure-Boot-Update task requires DiagTrack to be enabled.

That makes sense, Secure Boot task wants to forward telemetry data back to MS.

The whole point of the Confidence Bucket exercise was ~~guinea pigs~~ early adopters would take the risk and see if updates worked or not. The collected telemetry would give MS a better idea of whether it was safe to unlock automatic updates to everyone else

anchamp65 · 2026-06-11T15:50:35-0400

garlin said:
The whole point of the Confidence Bucket exercise was ~~guinea pigs~~ early adopters would take the risk and see if updates worked or not. The collected telemetry would give MS a better idea of whether it was safe to unlock automatic updates to everyone else

@garlin
Am I wrong to assume that the telemetry was only required for assigning the Confidence Bucket for 2023 certs and has no role in future boot loader or SVN upgrades, weither I send telemetry or not, those upgrades are going to get done normally by MS ?

But since I want Secure Boot task to complete successfully (0x0), I'll leave the DiagTrack running.

garlin · 2026-06-11T15:53:58-0400

Ed Tittel said:
Still trying to get the P16 Gen 3 up to SVN 9.0. Here is output from .\update_UEFI-CA2023.ps1 -stage
WARNING: Cannot confirm if W11 26H1 (28020.2236) has the latest files.

SUCCESS: NO UPDATES ARE REQUIRED.

Copilot says the SVN 9.0 stuff needs to come from Lenovo and is not yet forthcoming. What do you say?

Your CEO or CTO believes you can fire everyone, and replace them with AI. That's until your business falls behind, because AI is faulty. Or maybe every CEO runs the same AI, and everyone is suffering equally and you don't lose any competitive edge.

/sarcasm

The only thing controlled by the OEM is the PK and the signed KEK CA 2023. Beyond that, everything is owned by MS. SVN is a Windows-specific versioning system to prevent rollback of boot manager to older (insecure) builds. Lenovo has no role.

With Insider builds, I have no idea if the SecureBootUpdates folder is in sync. I hope so, but since I don't have time to run all of the Insider builds, I can't confirm it's true. Besides I would have to know the last time an Insider build was updated. Unlike the production Windows releases, they don't have a single portal which lists the current KB's, and most importantly provide a CSV file listing each file's contents.

With production builds, I can easily see when the file sizes change in the CSV for each month's update. Therefore the script can't check if you're using an outdated Insider build, since some people don't update them regularly.

The DBX update files are not specific to any Windows. I don't know if you've first tried "Update_UEFI-CA2023.ps1 -Revoke".

One thing you can do is if your Insider build is lagging is to stage your own private copy of SecureBootUpdates folder.

1. Create a ZIP of \Windows\System32\SecureBootUpdates folder from an updated Production Windows.

2. Extract the folder to any random location on the Insider PC. Don't overwrite the official \Windows\System32 folder!

3. Delete the SkuSiPolicy.p7b in this folder, because it's dangerous to mix & match SkuSiPolicy files from different builds. They are magically different even through they may report the same version number (ie. 3.0.0.15).

4. Run the update script, using the staged folder:

Code:

Update_UEFI-CA2023.ps1 -Revoke -UpdatesFolder \path\to\private\folder

This will run the script using the DBX update files provided by another Windows build. Just make sure the Windows boot manager is reported to be SVN 9.0 before trying this. Otherwise you'll be locked out because of a mismatch.

garlin · 2026-06-11T15:57:00-0400

anchamp65 said:
@garlin
Am I wrong to assume that the telemetry was only required for assigning the Confidence Bucket for 2023 certs and has no role in future boot loader or SVN upgrades, weither I send telemetry or not, those upgrades are going to get done normally by MS ?

But since I want Secure Boot task to complete successfully (0x0), I'll leave the DiagTrack running.

That's up to you. We know the update script can handle new changes, but someone has to run it when needed.

MS isn't trying to invade your privacy with a dependency on DiagTrack. They probably didn't want to write a whole new API to send data back to the Secure Boot teams. And DiagTrack was already there on every Windows box.

anchamp65 · 2026-06-11T16:10:33-0400

garlin said:
MS isn't trying to invade your privacy with a dependency on DiagTrack. They probably didn't want to write a whole new API to send data back to the Secure Boot teams. And DiagTrack was already there on every Windows box.

I could have been clearer...
DiagTrak is running and will remain running from now on.

But I'm guessing that future boot loader or SVN updates don't really need any telemetry to be sent back to MS.
They are more in sens of "here is an update, apply it to your computer and I don't need to know if you were successfull doing it or not"
And that's the main difference with 2023 certs where MS needed to know for the gradual rollout based on Confidence Bucket valu@ge.

@garlin Does that make sens ?

JamesSmith · 2026-06-11T16:41:22-0400

garlin said:
The Secure Boot task is the intended mechanism for applying all future changes. I can imagine MS is hesitant (for now) to allow the task to update revocation settings because of the non-zero risk of "bricking" your Windows.

It's relatively safe to add new CA 2023 certs, since that doesn't prevent you from using CA 2011 boot managers.

Anything that is a revocation action is by design restrictive. If you don't apply the changes in lockstep, Windows might stop booting until you temporarily disable Secure Boot. So MS may be slow rolling updates, like it appears the SVN isn't automatically applied to the DBX.

In short, for now there is no risk presented by the Secure Boot task. But then it's not always going to apply every security change right away. Again, I don't work for MS. The best I can do is provide tools to allow users to check their status, and do their own updates.

I will continue to look at this thread until Microsoft finally takes control of this whole process.

Is it better to do

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x200 /f
powershell Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

[OPTIONAL] To update SkuSiPolicy.p7b, run the command:
Update_UEFI-CA2023.ps1 -SkuSiPolicy

OR
Update_UEFI-CA2023.ps1 -Revoke -SkuSiPolicy

Thanks.
James.

garlin · 2026-06-11T17:40:02-0400

anchamp65 said:
I could have been clearer...
DiagTrak is running and will remain running from now on.

But I'm guessing that future boot loader or SVN updates don't really need any telemetry to be sent back to MS.
They are more in sens of "here is an update, apply it to your computer and I don't need to know if you were successfull doing it or not"
And that's the main difference with 2023 certs where MS needed to know for the gradual rollout based on Confidence Bucket valu@ge.

@garlin Does that make sens ?

Try enabling this reg key, and turning DiagTrack off to see if this stops the warnings:

Code:

reg add HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot /v LimitSecureBootRequiredServiceData /t REG_DWORD /d 1 /f

gunrunnerjohn · 2026-06-11T18:29:04-0400

garlin said:
Mosby and the update script operate on the same basic principle: You can't make certain changes while the vendor's PK is in place.

It's part of the UEFI security model. The PK's presence forces authentication of whatever new keys you're adding, which implies they must be properly signed. Only the vendor owns the private key for the PK, so you can't just add a KEK CA 2023 without their help.

If you're sitting in front of the BIOS, you can enroll a pre-signed cert file because it takes a physical presence. This cannot be scripted, so it's a trusted step. To counter attackers from using this method, you can assign a BIOS password.

Mosby or any other scripted method requires you to delete the default PK (since you didn't create it), thus removing the authentication problem. Mosby chooses to self-sign a randomly unique cert, which is a norm in the Linux community (lots of guides on how to do this). I choose to use the Windows OEM Devices certs (which includes a MS provided PK).

All I'm offering the user is an update solution using 100% MS-provided security files. For some users, they may prefer that choice.

One interesting question. Is there any downside to either the Mosby self-signed key or using the MS provided PK?

garlin · 2026-06-11T18:59:10-0400

Functionally it's not any different from creating your own privately-issued PK, and self-signing the pre-signed cert files that MS provides. If you had the same technical expertise and the right signing tools, you could do this yourself.

What Mosby accomplishes is the convenience of have an one-stop self-signing tool that works from a bootable USB. That's handy.

But with any crypto tool, you always have ask if your tools are secure. The source code for Mosby is available on GitHub for everyone to examine, but you might need to be a subject matter expert to fully understand the code. My approach is to use the MS-provided files, which are provided for PC vendors to use if they like. In my script, it's very transparent where we're downloading the keys from, and how it's installed.

Transparency is a big driver on how my scripts are done.

The Windows OEM Devices PK has already been used as an official mitigation for the "DO NOT TRUST - AMI Test" PK flaw. So there's previous precedent.

You can get into endless arguments over which approach is better (self-signed vs OEM delivery). But the Windows OEM Devices certs bundle is pre-packaged so it's known to work if you can get it correctly deployed. It doesn't change, so it's a more predictable outcome when dealing with Q&A. As you can tell, I can spend most of my day working with actual users.

Users can choose which way they want to replace their PK. But my update script will also take care of the Windows side of things (like dealing with a new version of the boot manager or SkuSiPolicy).

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

Active member

My Computer

Well-known member

My Computers

Well-known member

My Computer

Active member

My Computer

Well-known member

My Computer

Well-known member

My Computer

Active member

My Computer

Well-known member

My Computers

Well-known member

My Computer

Well-known member

My Computers

Well-known member

My Computer