Solved Secure boot update HowTo

francisco94 · Dec 20, 2025

fg2001gf11F said:
I had to manually add the CA 2023 to my BIOS to finally get this Updated state. See Posts #138 and #140 in the link below.

How to check if your Secure Boot certs are updated. (three methods)

Yes! Everything looks fine. All current values do have Green checkmarks. UEFI PK, KEK, DB and DBX. You're done. Congratulations. (y) (Script writer forgot to issue a new-line statement in the Current UEFI KEK section. If you make the CMD-box bigger than the spacing is not correct. (Less...

www.elevenforum.com

View attachment 157545

View attachment 157547

I've read it but I still don't really understand how to do it, sorry but I've never updated something like secure boot in the BIOS.

fg2001gf11F · Dec 20, 2025

francisco94 said:
I've read it but I still don't really understand how to do it, sorry but I've never updated something like secure boot in the BIOS.

You may find instructions on the web on how to manually download and add "microsoft corporation KEK 2k 2023 CA.crt" to your BIOS.
The procedure may be slightly different depending on the PC vendor and BIOS.

I don't remember exactly where I downloaded it from, I think from the link below. You may need to be signed in to github.

secureboot_objects/PreSignedObjects/KEK/Certificates/microsoft corporation kek 2k ca 2023.der at main · microsoft/secureboot_objects

Secure boot objects recommended by Microsoft. Contribute to microsoft/secureboot_objects development by creating an account on GitHub.

github.com

Here is my UEFI_report after manually adding the "microsoft corporation KEK 2k 2023 CA" to my Dell XPS 8930 BIOS.

garlin · Dec 20, 2025

fg2001gf11F said:
I don't remember exactly where I downloaded it from, I think form the link below. You need to be signed in to github.

Anyone can download files from a public GitHub project, without using an account. This is the official MS repo for Secure Boot files, which includes contributed KEK files from different PC makers.

MysteryMachine · Dec 20, 2025

I have first updated my bios to one that contains the new 2023 Cert, then i did the steps explained and ended up with everything as it should be.
even revoked the 2011 to the dbx.

Yet i was still getting the error about firmware not being ready. Note i have my bios secure boot key management set to default, not custom, and it all updated by windows. I don't know if setting it to Custom is a requirement but it seems not since it worked.

Then i ran another update by setting the 5944 value to the AvailableUpdates Regkey. Started the update task and ended up with the 4000 Value on AvailableUpdates. Now i no longer seem to get the windows TPM-WMI errors about firmware update.

Now as i understand it the 0X4000 value is there ONLY on machines with bios that contain the old 2011 in DB (while keys can not be removed from the DB), and it kind of tells windows to ignore that i am guessing (the same as having that 2011 cert in the DBX). Someone with insight correct me if i am wrong.

Then i also question whether the 0X4000 Value is necessary when the 2011 is in the actual DBX or is it a mechanism from microsoft to make sure windows does not use the 2011 in case the dbx might not be appended with the 2011 cert to revoke it. If anyone has insight please comment if correct.

fg2001gf11F · Dec 20, 2025

garlin said:
Anyone can download files from a public GitHub project, without using an account. This is the official MS repo for Secure Boot files, which includes contributed KEK files from different PC makers.

What is the link? I had to login to get the file. I only found the .der, the .crt has been removed.
But when I compare them, they are identical.

garlin · Dec 20, 2025

fg2001gf11F said:
What is the link? I had to login to get the file. I only found the .der, the .crt has been removed.
But When I compare them, they are identical.

View attachment 157556

View attachment 157557

psssst.... They're the same file!

If you're very paranoid, the official MS copy of the KEK CA 2023 .crt file lives here:
https://go.microsoft.com/fwlink/p/?linkid=2239775

fg2001gf11F · Dec 20, 2025

garlin said:
psssst.... They're the same file!

If you're very paranoid, the official MS copy of the KEK CA 2023 .crt file lives here:
https://go.microsoft.com/fwlink/p/?linkid=2239775

Thanks for the clarification, and for the microsoft link.
I don't know why I had to sign in to github to get the .der file when I tried earlier.

DER vs. CRT vs. CER vs. PEM Certificates and How To Convert Them – RickyAdams.com

www.rickyadams.com

According to this explanation below, ".crt" can be encoded the same way as ".der".

.
Encoding methods

difference

The main difference between .crt and .der files lies in their encoding methods. .crt files are typically encoded as binary DER or as ASCII PEM, while .der files are binary DER encoded. The .crt file extension is often used for certificates, which can be encoded as binary DER or as ASCII PEM. The .cer and .crt extensions are nearly synonymous, and most common among *nix systems, CER is an alternate form of .crt (Microsoft Convention).
rickyadams.com+1
In summary, .crt and .der files are both X.509 certificate formats, but they differ in their encoding methods and file extensions. .crt files can be either binary DER or ASCII PEM encoded, while .der files are binary DER encoded.
rickyadams.com+1

garlin · Dec 20, 2025

MysteryMachine said:
Now as i understand it the 0X4000 value is there ONLY on machines with bios that contain the old 2011 in DB (while keys can not be removed from the DB), and it kind of tells windows to ignore that i am guessing (the same as having that 2011 cert in the DBX). Someone with insight correct me if i am wrong.

Then i also question whether the 0X4000 Value is necessary when the 2011 is in the actual DBX or is it a mechanism from microsoft to make sure windows does not use the 2011 in case the dbx might not be appended with the 2011 cert to revoke it. If anyone has insight please comment if correct.

0x4000 instructs the scheduled task not to install Microsoft UEFI CA 2023 (used for Linux) and the Option ROM certs, if Microsoft UEFI CA 2011 (also used for Linux) doesn't exist. Meaning, don't install the new 2023 cert for Linux systems if you didn't have the original 2011 cert for Linux.

It's intended as a security measure for paranoid folks.

Now the enterprise guidance for 0x5944 is just adding all the individual steps in one pass. So all the bitmask flags add up to hex 5944. Technically the 0x4000 instruction is optional. MS has no idea of whether you use Linux or not. It's easier or them to explain to busy IT admins, just use 0x5944 and be done instead of walking through the math.

Without 0x4000, then you could substitute 0x1944 in its place. (0x5944 - 0x4000 = 0x1944)

If you have a legacy GPU (which no longer gets firmware updates), you might need the Option ROM added to support an older video card.

NormanF · Dec 20, 2025

Let Windows Update manage it. As long as there isn't an issue, leave your BIOS/UEFI well enough alone.

MysteryMachine · Dec 20, 2025

garlin said:
0x4000 instructs the scheduled task not to install Microsoft UEFI CA 2023 (used for Linux) and the Option ROM certs, if Microsoft UEFI CA 2011 (also used for Linux) doesn't exist. Meaning, don't install the new 2023 cert for Linux systems if you didn't have the original 2011 cert for Linux.

It's intended as a security measure for paranoid folks.

Now the enterprise guidance for 0x5944 is just adding all the individual steps in one pass. So all the bitmask flags add up to hex 5944. Technically the 0x4000 instruction is optional. MS has no idea of whether you use Linux or not. It's easier or them to explain to busy IT admins, just use 0x5944 and be done instead of walking through the math.

Without 0x4000, then you could substitute 0x1944 in its place. (0x5944 - 0x4000 = 0x1944)

If you have a legacy GPU (which no longer gets firmware updates), you might need the Option ROM added to support an older video card.

Ah ok , clear.

So i did al the steps correct before, but ended up with that TPM-WMI error about firmware, 'UEFICA2023Status not started' but 'WindowsUEFICA2023Capable as' 2 and 'AvailableUpdates as 0000'. Did all the other steps to update boot manager, update svn and revoke the old 2011 to dbx. Same results.
Only after running the 5944 it ended up being AvailableUpdates 4000 and UEFICA2023Status to Updated. Seems to be an important number, but i have no care for Linux.

Thx for explaining.

garlin · Dec 20, 2025

AvailableUpdates is a "tell me what to do next" setting. The task tries (in a specific order) to process steps it's been taught to do. Whenever it completes a step, it subtracts the corresponding value from AvailableUpdates.

If there's nothing the task is able to do (because everything's done, or there's safety logic to stop it), then the task can't arbitrarily clear the reg value to zero. AvailableUpdates will stay forever at 0x4000 for you, unless you set to 0x0 (no pending actions).

francisco94 · Dec 21, 2025

NormanF said:
Let Windows Update manage it. As long as there isn't an issue, leave your BIOS/UEFI well enough alone.

I think I'll just do this then, simply wait for a Windows update.

Thank you.

Scott · Dec 23, 2025

So today I put together my old gen 8 system on a table with whatever spare parts I had.
Got 25H2 installed and updated. Upon checking my certificates, my 4 year old UEFi was
bone stock. Following this How-To guide step by step brought it up to date. I even went
ahead and revoked the old cert.

neldog · Dec 24, 2025

XxXxX said:
I have put this together as I had problems updating 2 desktops and 3 laptops.
which have now all had their Secure Boot Certs updated to the new 2023 secure boot cert
also, the other post about this were getting very long and confusing.
this is in two parts. part A and part B.
edit by me. please note, your system must be online for part A to update

The below images are my System One and pretty much the same for System Two.

I would like to get your view on one last thing if I may ask you. Is this, (the Italic text below) something I need to also do, or will that be done by Microsoft Windows Update at the appropriate time? You may not even know for sure the correct answer - it seems to be a gray area, and I am kind of scared to do it, as everything else seems good now. It would be easy to do... I am just not sure if that would cause me a problem, as all works well today. I guess I am just asking is if there is any way this could backfire on me, or is this extra step completely safe to do?

Thank you for taking your time to read this. I really appreciate all your, (and many others here) help with all this. You guys are all great! Merry Christmas to all...

You can get rid of those None values by Applying a SVN update to the firmware. You can initiate that by the following commands: (PowerShell as admin)

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x200 /f

Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

Everything else now is as it should. When SVN shows 7.0, 3.0, 3.0 then you are done! Current UEFI, PK, KEK, DB and DBX are already OK.

nikki605 · Dec 24, 2025

The 3 SVNs displayed as None on one of my 2 systems, so I did follow the instructions you posted and the SVNs were updated just as described. I've seen no problems so far. Other members may post their experience. YMMV

XxXxX · Dec 24, 2025

neldog said:
The below images are my System One and pretty much the same for System Two.

I would like to get your view on one last thing if I may ask you. Is this, (the Italic text below) something I need to also do, or will that be done by Microsoft Windows Update at the appropriate time? You may not even know for sure the correct answer - it seems to be a gray area, and I am kind of scared to do it, as everything else seems good now. It would be easy to do... I am just not sure if that would cause me a problem, as all works well today. I guess I am just asking is if there is any way this could backfire on me, or is this extra step completely safe to do?

Thank you for taking your time to read this. I really appreciate all your, (and many others here) help with all this. You guys are all great! Merry Christmas to all...

You can get rid of those None values by Applying a SVN update to the firmware. You can initiate that by the following commands: (PowerShell as admin)

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x200 /f

Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

Everything else now is as it should. When SVN shows 7.0, 3.0, 3.0 then you are done! Current UEFI, PK, KEK, DB and DBX are already OK.

View attachment 157941

View attachment 157940

View attachment 157942

leave everything in place for now as updates are still coming down the line
and this allows the system to check every 12 hours for updates.

it seems to take some systems, mainly older ones, several days and restarts to fully update
reason at this time 'unknown' as most manufacturers dont seem to be too forth coming with information.

best of luck Steve ..

fg2001gf11F · Dec 25, 2025

nikki605 said:
The 3 SVNs displayed as None on one of my 2 systems, so I did follow the instructions you posted and the SVNs were updated just as described. I've seen no problems so far. Other members may post their experience. YMMV

View attachment 157944

Which instructions?
Still shows none on my machines.

gunrunnerjohn · Dec 25, 2025

This was posted recently, worked for me on all four machines to populate the SVN's to the proper versions.

You have to worry if there are red crosses at "Current UEFI". Default UEFI are values if you reset the stuff which is not needed.
You can get rid of those None values by Appyling a SVN update to the firmware. You can initiate that by the following commands; (Powershell as admin)

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

fg2001gf11F · Dec 25, 2025

gunrunnerjohn said:
This was posted recently, worked for me on all four machines to populate the SVN's to the proper versions.

Thanks, looks like that worked on my 4 machines too.

Where was that posted? Post #180 in the thread below?

How to check if your Secure Boot certs are updated. (three methods)

Okay... one more little thing cleared up. I'm not sure why this wasn't showing up before that my system was using the Do Not Trust AMI test platform key. I was able to append the microsoft platform key without issues directly in the BIOS using the Windows OEM PK certificate.

www.elevenforum.com

neldog · Dec 27, 2025

XxXxX said:
Leave everything in place for now as updates are still coming down the line
and this allows the system to check every 12 hours for updates.

It seems to take some systems, mainly older ones, several days and restarts to fully update
reason at this time 'unknown' as most manufacturers don't seem to be too forth coming with information.

best of luck Steve ...

Thanks... That is what I am going to do. From all that I have read about the SVN update it looks as though MS thru Windows Update "should" take care of this later in 2026 sometime. I "think" I have got everything in place right now on both my machines and ready for Windows Update to take it from here. Thank you for all your help.

This is some of what I found on this issue:

Applying the SVN update to the firmware" refers to updating the Secure Version Number (SVN) in the UEFI firmware.

**Important Considerations
Irreversible: Once the SVN is updated in the firmware, downgrading to older, non-updated firmware or boot managers is no longer possible.

Compatibility: All bootable media (PXE, ISOs, USB drives) must be updated with the new boot manager that is signed with the 2023 CA, or they will fail to boot.

** Automatic updates:
For "most" users, Windows Update should handle this process automatically if Secure Boot is enabled. The manual steps are primarily for "system administrators managing enterprise environments" or troubleshooting issues.

Verification: The SVN update prevents an older boot manager (with a lower SVN) from running by comparing the boot manager's SVN with the one stored in the firmware. You can verify the status through PowerShell commands.

Solved Secure boot update HowTo

Active member

My Computer

Well-known member

My Computer

Well-known member

My Computer

Member

My Computer

Well-known member

My Computer

Well-known member

My Computer

Well-known member

difference​

My Computer

Well-known member

My Computer

Well-known member

My Computers

Member

My Computer

Well-known member

My Computer

Active member

My Computer

Well-known member

My Computers

Well-known member

My Computers

Well-known member

My Computers

Just a Computer User

My Computers

Well-known member

My Computer

Well-known member

My Computers

Well-known member

My Computer

Well-known member

My Computers

Similar threads

difference