Updating Secure Boot certificates/keys

AlHill · ‎05-13-2026

This document is intended to help you update your Microsoft Secure Boot keys, specifically on Intel desktop and NUC motherboards running Windows 11. It should also help with non-Intel boards. It is just a guide, and the process that I followed when updating my machines. Success on your device(s) cannot be assured. I did not create the scripts referenced in this document and am providing the links only for your convenience.

To learn more about Microsoft Secure Boot Keys and when they expire in June 26, visit:

https://techcommunity.microsoft.com/blog/windows-itpro-blog/updating-microsoft-secure-boot-keys/4055324

Do you have Secure Boot turned on?

Do you have Secure Boot (SB) turned on? You can check by running:

MSINFO32

and looking for the Secure Boot State. If Secure Boot is off, you should turn it on. You will have to enter your BIOS to do so. If you do not have SB on, and want to turn it on, and are unfamiliar with entering the BIOS and changing settings, consult with your motherboard/system manufacturer.

The biggest issue with updating the SB certificates

The biggest issue, and I want to pin this on Intel since 18 of my 20 machines are Intel desktop or NUC, is the Secure Boot implementation and control in the BIOS. It appears that all controls over SB in the BIOS differ from board to board, meaning there is no consistent implementation for the SB on/off, enable/disable, clear/reset, standard/custom settings, and other settings. All of my machines range from 3rd gen to 13th gen, and all run W11. That covers fifteen years of Intel-provided BIOS on their hardware.

Again, I say that the BIOS settings are the challenge. In June, it will be very bad for a lot of users with good hardware that they will not be able to update and their certificates will expire without manual intervention. And, it is my position that a UEFI BIOS that cannot deal with updating certs in a consistent manner along with the BIOS implementation of SB is a failure of UEFI, and a failure of Intel for allowing this to happen across their desktop and NUC product lines and BIOS. I will even go so far as to say that there are likely differences in SB control from version to version of a BIOS update on a particular machine. To me, it is disturbing that Intel allowed or permitted this deficiency in the BIOS of all of their desktop and NUC products.

This lack of consistency in the implementation of SB is shameful and indicates it was not well-designed and thought-out. Furthermore, if the device manufacturers had implemented their Secure Boot settings and UEFI properly, there would be no need for the user to have to deal with this issue, regardless of the device manufacturer. Additionally, the amount of effort this imposes on organizations is costly and time-consuming. Enough of my rant. And, all this is just my opinion.

The scripts used for updating the Secure Boot certificates

I focused on using scripts from garlin and ceej21 that I found on github and elevenforum to accomplish this task. You can download these scripts from:

I found that I liked parts of garlin and ceej21, which I used to update all my machines. The garlin scripts are powerful, very well documented and have very useful options. It would be time well spent to review both script providers to gain a more in-depth understanding of the scripts and update process.

These scripts are updated frequently by their authors. Make sure you have the latest available.

The goal of this exercise?

The goal is to see this in Windows Security, Device Security, Secure Boot::

If you see something other than the above, like windows needing more information or your hardware has a problem, you need to update your certificates. Even if it says your hardware has a problem, you can still update the certificates. Some Windows machines may have updated the Secure Boot DB and/or KEK automatically. Others may have updated with a BIOS update, if one becomes available. But, many machines are not updated.

Now, the disclaimers:

It goes without saying that I ran everything in admin mode.

It also goes without saying that we are dealing ONLY with machines with SB and UEFI BIOS

BitLocker: The garlin script handles the suspension of BitLocker. I do not use BitLocker, so it did not concern me. I am not going to address BitLocker issues. If you are concerned about your data, have a backup prior to attempting the cert updates.

Macrium: if you use Macrium, you may have issues: Visit https://www.elevenforum.com/t/overwhelmed-macrium-reflect.46159/ for more information. I use both Macrium 8.x and 10, and have no issues with my backups. It appears the easiest solution, if you do have issues, is to uninstall and reinstall Macrium. At least, that is what I hear. Also, I re-ran a backup after I updated each machine without issue.

If you update your certificates and at some point in the future restore, recover or reload your BIOS, you may need to perform the certificate update again.

You should ALWAYS have a backup of your system/data.

The Secure Boot BIOS settings

Ideally, want you want to accomplish is this:

set SB to OFF
update the certificates
set SB to ON

It is very unfortunate that it is not this simple. As I stated in my rant earlier, the implementation of SB control in the BIOS is severely flawed.

You have to get to the SB settings in your BIOS. How do you get to the secure boot settings in the BIOS? The process for each device manufacturer/motherboard will be different. For Intel machines, boot to the BIOS with F2, go to boot settings, look for Secure Boot, and explore those settings. If you need help, contact your system/motherboard manufacturer for support.

After some combination of SB enable/disable or SB on/off in the BIOS, sometimes having to clear/reset SB keys, sometimes having to use standard/custom setting, sometimes disabling SB, clearing the keys, saving and reboot, and back to the BIOS to enable SB, I saved the BIOS config, and rebooted. My point here is that there is no process that can be followed that will work for every machine. The SB settings have to be changed to allow the scripts to run in the OS to update the certificates.

Now, to update the certificates.

With SB set to allow you to update the certificates, in Windows, run the garlin script:

Update-UEFI.bat

That worked almost every time. For the times that it did not work, I had the unzipped garlin in a temp folder in the root, and with PS admin:

CD\
CD temp
set-executionpolicy bypass
.\Update_UEFI-CA2023.ps1

If that was successful, fine. If not, you have to revisit the SB settings in the BIOS. For example, sometimes I had to disable SB, clear the keys, and RE-ENABLE SB. I know that sounds silly. Sometimes I had to clear the keys, and keep SB in custom mode. Getting the SB BIOS settings correct so you can run the scripts is the worst part of this exercise.

After getting the SB BIOS settings set to allow the garlin script to run, I rebooted, waited a couple of minutes, and checked the SB status in Windows Security as I stated earlier.

Check if you successfully updated the certificates

After updating the certs, and rebooting each machine, it sometimes took a couple of minutes for the SB status to update in Windows Security, which I attributed to Windows Security startup and checking. This only happened after the first reboot after the certs were updated.

Now, this is where the ceej21 scripts are used. The ceej21 zip contains the following command:

Check UEFI PK, KEK, DB and DBX.cmd

This command, to me, was invaluable. It showed the certs as all updated. That script produces this report:

*******************************************************************************
Checking for Administrator permission...
Running as administrator - continuing execution...

07 May 2026
Manufacturer: Intel(R) Client Systems
Model: NUC13RNGi9
BIOS: Intel Corp., SBRPL579.0067.2025.1030.1104, SBRPL579.0067.2025.1030.1104, INTEL - 43
Windows version: 25H2 (Build 26200.8328)

Detected x64 UEFI architecture. Ensure that this is correct for valid DBX results.

Secure Boot status: Enabled

Current UEFI PK
√ SBoot1

Default UEFI PK
√ SBoot1

Current UEFI KEK
√ Microsoft Corporation KEK CA 2011 (revoked: False)
√ Microsoft Corporation KEK 2K CA 2023 (revoked: False)

Default UEFI KEK
√ Microsoft Corporation KEK CA 2011 (revoked: False)
√ Microsoft Corporation KEK 2K CA 2023 (revoked: False)

Current UEFI DB
√ Microsoft Windows Production PCA 2011 (revoked: True)
√ Microsoft Corporation UEFI CA 2011 (revoked: False)
√ Windows UEFI CA 2023 (revoked: False)
√ Microsoft UEFI CA 2023 (revoked: False)
√ Microsoft Option ROM UEFI CA 2023 (revoked: False)
√ UEFIappl1

Default UEFI DB
√ Microsoft Windows Production PCA 2011 (revoked: True)
√ Microsoft Corporation UEFI CA 2011 (revoked: False)
√ Windows UEFI CA 2023 (revoked: False)
X Microsoft UEFI CA 2023
X Microsoft Option ROM UEFI CA 2023
√ UEFIappl1

Current UEFI DBX
2025-10-14 (v1.6.0) [x64] : SUCCESS: 431 successes detected
Windows Bootmgr SVN : 8.0
Windows cdboot SVN : 3.0
Windows wdsmgfw SVN : 3.0
Statistics : 22819 Bytes, 434 SHA256 hashes, 1 X.509 certs, 4 SVNs

Press any key to continue . . .
*******************************************************************************

The italicized text will be different on your machines, and is of no concern, and is probably only corrected by a BIOS update (which will not happen on older devices).

You are not done, yet...

Of particular interest in report above was:

Windows Bootmgr SVN : 8.0
Windows cdboot SVN : 3.0
Windows wdsmgfw SVN : 3.0

On all machines where I ran the report prior to updating, the SVN revisions (secure version number) were 0.0, and the SUCCESSes varied. After running the garlin script, the SUCCESSes were improved, but the three SVN revisions were still 0.0.

In the ceej21 zip, there were two other commands:

Apply DBX update.cmd
Apply revocations.cmd

I ran both of those, and re-ran:

Check UEFI PK, KEK, DB and DBX.cmd

Now, all of the SUCCESSes were consistent, either 431 or 428, and the bootmgr, cdboot, and wdsmgfw SVN were all updated as in the report above.

It was interesting that running this report BEFORE running the garlin script produced such varied results. After running garlin, and after running ceej21, the report is consistent across all 20 machines.

Garlin also provides a script if you require further confirmation of your SB status:

Check-UEFI.bat

Updating the certs on non-Intel boards and other strange things

Of my 20 machines, two were not Intel, but rather a Dell Latitude 6th gen, and a Microsoft Surface Pro 3 (4th gen). Their SB settings in their BIOS were equally confounding. The Surface, which is now reporting the certs correctly, has a strange issue. The Surface BIOS, if you are not in SB mode, displays a RED screen at boot time as a warning that SB is off. Even though the certs are all updated on the Surface, and SB is enabled in the BIOS, this RED warning screen still appears at boot time. However, MSINFO32 says SB is on, and Windows Security says SB is on. I am not concerned about that at this time.

Summarizing the steps to update the SB certificates/keys

The steps to update the certs are, basically:

Wrestle with the SB settings in the BIOS.
Run garlin Update-UEFI.bat in admin mode
Run ceej21 Apply DBX update.cmd in admin mode
Run ceej21 Apply revocations.cmd in admin mode
Run ceej21 Check UEFI PK, KEK, DB and DBX.cmd in admin to produce the report.
Re-visit the SB settings in the BIOS to determine if you can or need to re-enable or return to standard mode
Verify in Windows Security that secure boot is on and all certs are updated

Doing this will take some time, most of which is spent deciphering the SB BIOS settings. And, if your BIOS settings for SB are correct, you really need only to run the garlin command.

Postmortum

My positive takeaways on this is the garlin and ceej21 scripts. My thanks to ceej21 and garlin for their scripts, and the work they did to make this update process work.

I wish I had kept log of the specific BIOS settings for SB on all machines I updated so I could provide them as an example. A bad practice, but I kept changing the settings till I could run the scripts successfully. Even if I had documented the BIOS SB settings for a couple of machines, it would have helped only a couple of users. There are hundreds of machines out there that will be a challenge.

No part of this document was written with any AI or chatGPT.

And, speaking of AI, you may want ask your favorite AI what are the SPECIFIC SB settings for updating keys/certificates in your machine specific BIOS, and how to return the SB settings after a successful update. That should produce interesting responses.

Good luck with your updates!

Doc (not an Intel employee or contractor)
[CoPilot is a virus, W11 is a keystroke logger, all from MicroSlop]