boot to BIOS secure boot off, expert key mode on,
delete all pk keys
select KEK delete all KEK keys
what idiot writes - delete all keys - when he actually means delete the selected keys !!!!
left expert on, reboot to windows
ran update-UEFI.bat
Basically there's two different approaches to manual updates:
1. Manually enrolling KEK CA 2023 (by itself). Most Dells have a BIOS quirk where they cannot accept the DER-encoded cert file and only expect an ESL file (raw bytes exported from the UEFI variable). That's how a lot of Dells are implemented. Other vendors, and some other Dell models don't have this restriction.
Normally if you tell me you have a certain model Dell, I expect it wants the ESL file which we cannot provide. ESL files (for the KEK) must be signed by the PK's key holder (or Dell). Dell doesn't want to support this PC, so this option is useless.
2. Barring manual KEK key enrollment, we wipe out all the keys so we can replace them with a new set. Technically you could just delete the PK at a bare minimum, but my instructions are to delete all the keys so we don't end up with some weird UEFI variables glitch (it's happened before on other PC's).
We don't need to perform both options for all cases. You try the first option, and if it fails we move to the second. But we already know the first option never works on specific Dell's. Sorry if that whole thing sounds confusing.
Anyway, you're done on adding CA 2023 certs. Revocation has not happened, and you can wait for Windows to revoke CA 2011 later this year, or follow the commands to finish it now.
Basically there's two different approaches to manual updates:
1. Manually enrolling KEK CA 2023 (by itself). Most Dells have a BIOS quirk where they cannot accept the DER-encoded cert file and only expect an ESL file (raw bytes exported from the UEFI variable). That's how a lot of Dells are implemented. Other vendors, and some other Dell models don't have this restriction.
Normally if you tell me you have a certain model Dell, I expect it wants the ESL file which we cannot provide. ESL files (for the KEK) must be signed by the PK's key holder (or Dell). Dell doesn't want to support this PC, so this option is useless.
2. Barring manual KEK key enrollment, we wipe out all the keys so we can replace them with a new set. Technically you could just delete the PK at a bare minimum, but my instructions are to delete all the keys so we don't end up with some weird UEFI variables glitch (it's happened before on other PC's).
We don't need to perform both options for all cases. You try the first option, and if it fails we move to the second. But we already know the first option never works on specific Dell's. Sorry if that whole thing sounds confusing.
Anyway, you're done on adding CA 2023 certs. Revocation has not happened, and you can wait for Windows to revoke CA 2011 later this year, or follow the commands to finish it now.
I have a Dell 2017 XPS-15 model 9560 with the latest bios (1.21.0 from 2021). I was having problems with deleting all keys part. I finally got it to work with going to custom mode and then rebooting and going into bios again and then deleting the keys. It wouldn't work without the reboot between the steps.
I have a Dell 2017 XPS-15 model 9560 with the latest bios (1.21.0 from 2021). I was having problems with deleting all keys part. I finally got it to work with going to custom mode and then rebooting and going into bios again and then deleting the keys. It wouldn't work without the reboot between the steps.
I have heard that story too. Sometimes you have reboot once or twice (or reset and get back into the BIOS screens).
Each BIOS can have its weird quirks. There are some BIOS'es where you can only makes changes if Secure Boot is always on.
I think it depends on which generation of BIOS was shipped with your Dell. Dell's FAQ lists at least five different screen layouts. If you're a fan of TV sci-fi, there are 5 different Cylons
I have heard that story too. Sometimes you have reboot once or twice (or reset and get back into the BIOS screens).
Each BIOS can have its weird quirks. There are some BIOS'es where you can only makes changes if Secure Boot is always on.
I think it depends on which generation of BIOS was shipped with your Dell. Dell's FAQ lists at least five different screen layouts. If you're a fan of TV sci-fi, there are 5 different Cylons
Technical enough to be able to make assumptions but experienced enough to ask in case I’m making a big mistake! I’ve also seen the BitLocker information from Microsoft and I think a lot must be down to the vendors implementation. Different motherboards, different TPM, different firmware. You can’t write scripts for the smoothest scenario only and I have several manufacturers and models from each to update. Incidentally a large amount updated on their own between the 11th June and today. Maybe MS are getting more confident (or aggressive) changing systems to “High Confidence” as a number were models that showed the “Require more information” entry 8 days ago.
Technical enough to be able to make assumptions but experienced enough to ask in case I’m making a big mistake! I’ve also seen the BitLocker information from Microsoft and I think a lot must be down to the vendors implementation. Different motherboards, different TPM, different firmware. You can’t write scripts for the smoothest scenario only and I have several manufacturers and models from each to update.
Incidentally a large amount updated on their own between the 11th June and today. Maybe MS are getting more confident (or aggressive) changing systems to “High Confidence” as a number were models that showed the “Require more information” entry 8 days ago.
In the June 2026 Secure Boot AMA, they said this update would re-assign most PC's from "More Data Needed" to "High Confidence", which would unblock a large wave of stragglers. For everyone else, you're kinda screwed because they admitted there might not be enough telemetry data to know.
Honestly, MS probably knew the true eligibility months ago. You can detect from the UEFI's KEKdefaults whether OEM support was already added, or cross-check the PK's thumbprint against their list of submitted KEK files to reasonably know if you have any chance for success.
@garlin Hi Garlin thanks again for the help yesterday. I wanted to give some input - after running the Update script with -Revoke it said follow README_UEFI.txt for instructions. I then went on a wild goose chase trying to install the certs in BIOS but ended up only needing to turn secure boot back on since the certs were already installed (unless there's something I don't remember). Am I missing something? If not just an area that could use some improvement. Also I've done this on several computers so far and in Part A here UEFICA2023Status shows 'in progress' not 'updating.' Thanks.
@garlin Hi Garlin thanks again for the help yesterday. I wanted to give some input - after running the Update script with -Revoke it said follow README_UEFI.txt for instructions. I then went on a wild goose chase trying to install the certs in BIOS but ended up only needing to turn secure boot back on since the certs were already installed (unless there's something I don't remember). Am I missing something? If not just an area that could use some improvement. Also I've done this on several computers so far and in Part A here UEFICA2023Status shows 'in progress' not 'updating.' Thanks.
I added a new bug with the Trusted PK check. It's triggering an unnecessary duplication of effort of copying the WindowsOEMDevicesPK.der cert file when the DefaultPK.bin was already accepted. After you copy the cert file, it always instructs you to perform some required action.
I got figure out which logic combination prevents it from repeating the extra steps. Thanks for the heads up.
Rufus does that dynamically. But we "clamp" the max SVN to the version that was last released as retail ISO (which currently is 25H2 v2), which means 7.0 instead of the actual current 8.0.
This is because, with many, many people using the retail ISOs for install, which Microsoft doesn't update even when it knows its bootloaders are vulnerable, we don't want to have those same people complaining that the very latest full retail ISO they can publicly download from Microsoft is flagged as revoked.
But really, if I wanted to, I could have Rufus instantly tell everyone that the 25H2 v2 Windows 11 ISO they use has out of date bootloaders, as it's just a matter of updating the separate file we maintain (so that we have finer control than fetching it from secureboot_objects), that is fetched by Rufus on session startup, which we purposefully hold back for the reason described above (and which we actually inadvertently updated to v8.0 a couple days ago and had to revert precisely so that people weren't alarmed that pretty much all their Windows ISO were flagged by Rufus).
It's really unfortunate that Microsoft does treat bootloader security as a joke, by not instantly updating the release ISOs from Download Windows 11 the minute they fix a vulnerability in their bootloaders, because it forces utilities like Rufus to not be as accurate as they could be when it comes to notifying about out of date ISO images. But it's a choice of the application, rather than an actual limitation/oversight.
For the last two months, I've been working on new PowerShell scripts to automate the Secure Boot CA 2023 update process. A number of contributed scripts or guides presented on various ElevenForum threads (including a few of my earlier scripts) are lacking in clarity. There's simply too much confusion and guesswork to what's going with updates. The whole process should be easier to follow.
Why should you use these scripts?
Find out if your BIOS is currently supported by MS or not
Find out if your Secure Boot update is completed right now, without the need to run other commands or looking at the Event Viewer logs
Force an immediate update to CA 2023 certs, and optionally revoke the CA 2011 cert at this time
Update your boot files on USB removable media (including Macrium recovery drives)
The scripts are written in PowerShell so any technical user can examine the code, and determine if there are any security problems presented.
All the UEFI security certificates and policy files are either sourced from the \Windows\System32\SecureBootUpdates folder, or the Microsoft GitHub repo for Secure Boot Objects. The MS GitHub is referenced by the UEFI Forum group as the official site for downloading Secure Boot CA 2023 updates.
W10 22H2 and all W11 releases, which have the July 2025 (or later) Monthly Update are supported. Including x64, x86, arm64 and arm architectures.
DO I NEED TO READ EVERYTHING BELOW?
No. If you want to just get started, first run the Check_UEFI-CA2023.ps1 script. If it doesn't suggest you to run the Update_UEFI-CA2023.ps1 script, then you have the option to do nothing (wait for MS to safely upgrade your PC in 2026), or follow the onscreen instructions. The instructions mirror the current MS guides.
Whenever you see the MS instructions for "reg add"..., you can always run the Update_UEFI-CA2023.ps1 and skip the waiting. The upgrade script does everything at the same time, so there's no need to check any Windows event logs. Run the Check_UEFI-CA2023.ps1 script again, and see if there are no more instructions left.
You have the option to stop right now, after adding the CA 2023 certs. The revocation of CA 2011 isn't expected to happen until early-mid 2026.
Before we get started, let's review an important requirement for the CA 2023 update:
When Secure Boot is enabled, your UEFI must have a signed KEK CA 2023 certificate in order to properly install the CA 2023 certs and updated boot files.
In the UEFI security model, Micorosoft provides the PC or motherboard maker a signed Key Exchange Key (KEK) signed by MS. The OEM in turn signs the KEK with their Platform Key (PK) to bless the KEK as authenticated by the vendor. The OEM has the option to provide one of two solutions:
Recent BIOS firmware update which includes the CA 2023 certs as factory defaults
Submit a re-signed KEK for inclusion in the MS GitHub repo (and Windows can perform the update by itself)
A problem happens when the OEM doesn't follow either solution, because they don't want to support older PC's.
Fortunately, another option is available. Most UEFI's have a Setup Mode, where the user clears the UEFI of all existing certs and signature hashes, and allows a tool to write certs directly into UEFI. This is what Mosby tries to do. But we don't actually need Mosby (and its requirement to format an USB drive) if you have a script or tool that runs on Windows.
There are three scripts in the release:
Check_UEFI-CA2023.ps1
Checks the current state of your UEFI certs, and the boot files for Windows and any bootable DVD or USB media. The script can provide an Audit Report, listing what steps need to be completed to be in compliance with the CA 2023 update, and what commands to run.
Update_UEFI-CA2023.ps1
Updates the UEFI certs and boot files for Windows and any bootable USB media. You have the option to only install the UEFI CA 2023 certs, and not revoke the PCA 2011 cert; or to complete the entire process in one pass.
Check_DBXUpdate.bin.ps1
Compares any submitted DBXUpdate.bin file against the current UEFI DBX variable, and informs you if there are any EFI or SVN signatures that need to be installed.
USAGE
Check_UEFI-CA2023.ps1
Report on the current UEFI certs enrolled in the KEK, DB, and DBX variables, Secure Boot and Virtualization-Based Security modes, BitLocker encryption status, and if the Windows Boot Manager is allowed by the current UEFI setup. Each command-line option may be used on its own, or in combination with any or all of them.
Supported options:
- Audit
Report what UEFI CA 2023 steps have not been completed. Check the Windows Boot Manager as if Secure Boot is enabled (in case you're running with Secure Boot as disabled).
- Verbose
Extended details including Windows build, BIOS versions, factory defaults for PK, KEK, DB and DBX variables, Windows BootMgr SVN, and count of EFI signature hashes for the DBX list.
- BootMedia
Check the boot file and Windows install image are allowed by the current UEFI setup.
- Log
Save output to a log named after the current date, and PC model.
Check_UEFI-CA2023.ps1
Code:
Secure Boot: ON
Virtualization Based Security: ON
BitLocker on (C:) ON
UEFI KEK Certs
--------------
Microsoft Corporation KEK CA 2011
UEFI DB Certs
-------------
Microsoft Corporation UEFI CA 2011
Microsoft Windows Production PCA 2011
UEFI DBX Certs
--------------
(NONE)
EFI Files
---------
Disk 0: Windows Boot Manager [Production PCA 2011] is ALLOWED.
Registry: WindowsUEFICA2023Capable = 0
[Windows UEFI CA 2023] not in UEFI DB.
Disk 0: SkuSiPolicy.p7b (for VBS) is NOT PRESENT.
REQUIRED ACTION
===============
OPTION 1: DO NOTHING. Windows will apply the UEFI updates in 2026 (supported BIOS).
OPTION 2: To install [UEFI CA 2023] certs WITHOUT REVOKING the [PCA 2011] cert, run the commands:
manage-bde -Protectors -Disable C: -RebootCount 1
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x5944 /f
powershell Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
OPTION 3: To install [UEFI CA 2023] certs and REVOKE the [PCA 2011] cert, run the commands:
manage-bde -Protectors -Disable C: -RebootCount 1
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x5be6 /f
powershell Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
Check_UEFI-CA2023.ps1 -Audit
Code:
Secure Boot: ON
Virtualization Based Security: ON
BitLocker on (C:) ON
UEFI KEK Certs
--------------
Microsoft Corporation KEK CA 2011
UEFI DB Certs
-------------
Microsoft Corporation UEFI CA 2011
Microsoft Windows Production PCA 2011
UEFI DBX Certs
--------------
(NONE)
EFI Files
---------
Disk 0: Windows Boot Manager [Production PCA 2011] is ALLOWED.
Registry: WindowsUEFICA2023Capable = 0
[Windows UEFI CA 2023] not in UEFI DB.
Disk 0: SkuSiPolicy.p7b (for VBS) is NOT PRESENT.
AUDIT REPORT
============
1. Secure Boot is DISABLED
2. [Microsoft Corporation KEK 2K CA 2023] is missing from UEFI KEK
3. [Windows UEFI CA 2023] is missing from UEFI DB
4. [Microsoft UEFI CA 2023] is missing from UEFI DB
5. [Microsoft Option ROM UEFI CA 2023] is missing from UEFI DB
6. [Production PCA 2011] is missing from UEFI DBX
7. DBX Updates are missing from UEFI DBX
8. Windows BootMgr SVN is missing from UEFI DBX
9. Windows Boot Manager [Production PCA 2011] is wrong version
10. SkuSiPolicy.p7b (for VBS) is missing
REQUIRED ACTION
===============
OPTION 1: DO NOTHING. Windows will apply the UEFI updates in 2026 (supported BIOS).
OPTION 2: To install [UEFI CA 2023] certs WITHOUT REVOKING the [PCA 2011] cert, run the commands:
manage-bde -Protectors -Disable C: -RebootCount 1
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x5944 /f
powershell Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
OPTION 3: To install [UEFI CA 2023] certs and REVOKE the [PCA 2011] cert, run the commands:
manage-bde -Protectors -Disable C: -RebootCount 1
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x5be6 /f
powershell Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
Update_UEFI-CA2023.ps1
Install the UEFI CA 2023 certs, and optionally revoke the CA 2011 cert if desired; copy the CA 2023 boot manager file to the EFI (ESP) partition, and any removable USB drives which have an \EFI\boot\bootx64.bin boot file. SkuSiPolicy.p7b file will be copied to EFI, if Virtualization-Based Security (VBS) is currently enabled.
Before the script runs, it checks if your Windows release is July 2025 or later, in order to have the latest Secure Boot files. When BitLocker is enabled, it's suspended for 1 or 3 reboots (depending on VBS), so changes in the UEFI don't require you to provide a BitLocker recovery key.
The script is smart enough to only perform the missing steps. If you partially updated the UEFI before running the script, it will finish whatever is expected. If you want to perform the entire upgrade in one pass, you can use the -Revoke flag.
If you have a supported BIOS (where the OEM has submitted a signed KEK to MS), then Update_UEFI-CA2023.ps1 can run without needing any help.
If you have any unsupported BIOS, you have two options:
For PC's with an UEFI that supports manual key management, the script copies the KEK CA 2023 certificate to the EFI partition. You can use your UEFI's menu options to manually enroll the KEK file, from the EFI partition's \EFI\Certs folder.
If your PC has an untrusted PK cert ("DO NOT TRUST" or "TEST"), the script will copy the "Windows OEM Devices PK" cert to the EFI partition. Enroll this PK cert from the \EFI\Certs folder.
For PC's that don't support manual key management of individual keys, you can choose Setup Mode (which deletes all certs). After clearing the certs, and restarting Windows, run the Update_UEFI-CA2023.ps1 script. It will complete the process without further help from you. This does almost the same thing as Mosby, except you're using the MS recommended "Windows OEM Devices PK" instead of self-signing the KEK cert.
Each command-line option may be used on its own, or in combination with any or all of them.
-Audit
Report what UEFI CA 2023 steps have not been completed. Check the Windows Boot Manager as if Secure Boot is enabled (in case you're running with Secure Boot as disabled).
-Revoke
Revoke the PCA 2011 cert, banning all old boot files. By default, the script only installs the CA 2023 certs, and will not revoke PCA 2011 unless requested.
-Latest
Check the MS GitHub, if later version of DBXUpdate.bin and DBXUpdateSVN.bin exist. Only apply changes if the bin files are newer.
-SBAT
Apply the optional Secure Boot Advanced Targeting (SBAT) update, if you're sharing EFI with a Linux system. Not required for a pure Windows setup.
-BootMedia
Replace the EFI bootfile (\EFI\Microsoft\Boot\bootx64.efi) on mounted USB drives, if the file is present.
-Log
Save output to a log named after the current date, and PC model.
Update_UEFI-CA2023.ps1
Code:
Suspending BitLocker for one reboot.
Successfully appended "dbupdate2024.bin" to UEFI DB.
Successfully appended "DBUpdate3P2023.bin" to UEFI DB.
Successfully appended "DBUpdateOROM2023.bin" to UEFI DB.
Downloading "KEKUpdate_Microsoft_PK3d8660c0.bin" from GitHub.
Successfully appended "KEKUpdate_Microsoft_PK3d8660c0.bin" to UEFI KEK.
Copying EFI boot files.
Boot files successfully created.
REQUIRED ACTION
---------------
Restart Windows, for UEFI updates to take effect.
Update_UEFI-CA2023.ps1 -Revoke
Code:
Successfully appended "dbxupdate.bin" to UEFI DBX.
Successfully appended "DBXUpdate2024.bin" to UEFI DBX.
Successfully appended "DBXUpdateSVN.bin" (SVN 7.0) to UEFI DBX.
Deployed SkuSiPolicy.p7b (for VBS).
REQUIRED ACTION
---------------
Restart Windows, for UEFI updates to take effect.
Check_DBXUpdate.bin.ps1
For normal users, this script isn't needed for the update process. When Windows releases a new DBXUpdate or SVN, it will be part of the usual Monthly Updates and eventually pushed to the UEFI. If you want to confirm that the DBX variable contains all signatures in a provided DBXupdate or DBXupdateSVN bin file, run this script. The script will report how many matched or missing EFI or SVN signatures from the submitted file are found in the Release v2026.06.14 · garlin-cant-code/SecureBoot-CA-2023-UpdatesDBX variable.
By default, the script compares the DBX files in \Windows\System32\SecureBootUpdates (refreshed by the Monthly Updates). You can provide a list of individual files or folders to be searched for *DBX*.bin named files. After a successful update (or revoke), there should be no missing signatures.
-Verbose
Download the "dbx_info_msft_latest.json" from MS GitHub, and extract the filename and vendor info for the missing EFI certs. If the missing signature is a SVN, report on the SVN.
Check_DBXUpdate.bin.ps1
Code:
FAILED: Missing 404/431 EFI signatures from "dbxupdate.bin"
FAILED: Missing 3/3 SVN signatures from "DBXUpdate2024.bin"
FAILED: Missing 3/3 SVN signatures from "DBXUpdateSVN.bin"
Signed up for the forum to thank you for this. I had to swap out my CMOS battery and could not boot up with Secure Boot enabled on an Alienware. This tool solved all my issues and now have Secure Boot enabled with the latest keys. Please let me know how to donate!
@joshray, glad to hear your PC is updated. There's no need to donate, except I hope everyone will share their positive and negative experiences about the specific PC models they're updating. The more that's learned will help other later users out.
Even if you thought the experience was simple, it might give confidence to someone else to try it on their machine.
I came here from a recommendation from Reddit. My custom-built system has been running since early September 2024. I have recently been made aware of the recent deadline to update secure boot systems and I would like to perform an update on my motherboard’s BIOS/UEFI BIOS to prepare for it. However, in Windows Security, it doesn’t show anything related to secure boot, only stating “Standard Hardware Security is not Supported”. In the BIOS Settings menu, secure boot is enabled but not utilized. It was not like this before. Currently, I am using an ASRock B660M Pro RS (Full set-up below) with the BIOS version 14.05. The most contemporary version ASRock released is 16.01, and it features the update to the security keys that I need. If you’re curious, I am using the “Instant Flash” method. I am a Windows 11 Home user, and the BIOS update instructions (Link) mention disabling TPM-related services and using a different login method since the Windows Hello PIN method I currently use might rely on the TPM (Should I use the USB/Security Key Method to sign in after or something else?). Previously, I was curious about updating the BIOS version, but expressed hesitation that it might affect my set-up. Additionally, I have used the Powershell script provided in the thread and it recommended I manually update the BIOS. Could you share how to properly update the system to hopefully not run into TPM/Security-related issues? How should I go about this?
1. BIOS version 16.01 explicitly adds the CA 2023 certs to the factory defaults.
1. Optimized system compatibility.
2. Enhance platform security with Control IOMMU Pre-boot Behavior, VT-d, and the IOMMU option.
3. Update Secure Boot Key (2023 KEK/DB/PK).
This is your best option, in case you need to reset the BIOS (for any reason) in the future. You may be able to manually enroll a KEK certificate file (instead of updating the BIOS), but 16.01 is guaranteed to handle the new certs and free of any possible Secure Boot quirks from an earlier version.
2. When you flash the BIOS or update certain Secure Boot certs, your BIOS may treat it as an one-time integrity event. For security reasons, it wants you to re-validate credentials which may have been kept in the TPM. Like your BitLocker key or Windows Hello PIN.
Some users are not prepared for this event. So they get locked out. The usual advice is to have everyone temporarily disable BitLocker and Windows Hello PIN so you're not inconvenienced. After you've finished the changes, you can re-enable both features.
3. Secure Boot itself is not directly related to TPM. You can have one, either, none or both of them at the same time. Secure Boot certs are stored in the protected NVRAM space of the BIOS, outside of TPM.
