Dell, HP, Lenovo (and other OEMs…)Enterprise and consumer oriented PC and laptop vendors (including also Acer, ASUS, Dynabook, etc.) generally did better, but even they had:
• staggered rollouts
• inconsistent BIOS/UEFI update timing
• some systems that required multiple reboots to apply DBX changes
As I looked at read forum posts at answers.microsoft.com, TenForums.com, ElevenForum.com, and TechPowerUp.com, I saw hundreds upon hundreds of forum threads that sought help in dealing with Secure Boot issues. Many involved laptops, and many more involved desktops, particularly DIY home-brew builds or those from boutique builders who assemble best-of-breed commercial parts to build bespoke PCs for well-heeled buyers (see next section).
Custom‑built PCsMotherboards from the same vendor might behave differently depending on:
• actual chipsets installed
• firmware branch
• release year
• OEM vs retail SKU
Overall, the lack of standardization has been obvious. The Secure Boot problems users encountered have been all over the place. Some have ultimately yielded to Windows Update or manual changes. Others have stubbornly resisted all attempts at repair or correction. I’ve personally been all over this problem space, with failures recently overtaken by successes (but failures, nonetheless).
What users can do if Secure Boot updates fail
Checking the System Information (msinfo32) utility is the quickest way to verify if Windows recognizes your Secure Boot state as active.There are all kinds of ways in which Secure Boot can fail. Windows update may report success, but the DBX (revocations list) never changes. Firmware may report that Secure Boot is “enabled,” but it isn’t being enforced (the PowerShell confirm-SecureBootUEFI will report false in that case).
Systems may boot but fail compliance checks (see Garlin Scripts section later in this story for more details). Bootloaders may not match DB entries, or systems may boot only reluctantly or not at all after updates (as happened on my ASRock B550 Extreme4 system). There’s a lot going on here, so there are lots of things to try should one need to fix them. Let’s march through a list of possibly poignant causes and related fixes.
Mismatched Keys (PK/KEK/DB/DBX)If the PK or KEK is outdated, firmware may reject database updates into the list of valid credentials and values (DB) or its list of revoked items (DBX). If that happens, it’s worth trying one or all of these fixes:
• Reset to factory or default keys (usually available as a selectable action in UEFI, when Secure Boot is in Custom mode)
• Re-enroll Microsoft keys (usually requires re-applying a Microsoft update, which entails an uninstall/reinstall maneuver, possibly via DISM—WU offers time-limited rollback)
Firmware Ignores DB or DBX UpdatesOn some PCs and laptops, UEFI won’t apply DB or DBX updates except under certain conditions. Secure Boot may need to be disabled. The Compatibility Support Module (CSM, which enables “dual boot” into either BIOS or UEFI modes; modern PCs are UEFI-only, but older models often go both ways) must be turned off. Sometimes, Secure Boot keys must be cleared (another UEFI option) must be cleared before updates will take. Experimentation may be needed to see what’s what; if you’re lucky, you’ll find info from other intrepid explorers who’ve already seen and solved your particular problem.
Outdated BootloadersOlder Windows install media or repair/recovery disks may incorporate bootloaders that are too old to work with Secure Boot. Indeed, this mismatch will accelerate later in 2026 after Microsoft gets more deeply into revoking CA-2011 (which is what most older bootloaders incorporate). If a bootloader is too old, DBX may block it. Fixes are fairly straightforward because bootloaders don’t interact with firmware (UEFI). Try any of the following repairs in this case:
• Run Windows Update: it may replace an outdated bootloader with a current one
• Rebuild boot files using the bcdboot utility
• Make sure the EFI partition is healthy (and rebuild it if it isn’t)
Firmware Bugs or OdditiesEspecially on older PCs, it’s a good idea to update (flash) the UEFI before getting into Secure Boot. For old enough PCs, though, updates into 2023 and newer may simply not exist. But for systems that require multiple reboots, specific firmware versions, or manual Secure Boot database (DB, DBX) imports, a few techniques will be helpful:
• Update the firmware to the latest stable version (consider beta versions only if all other options have failed: you don’t want to trade one cause of instability for another)
• Wherever available, use vendor-supplied capsules or updates to apply Secure Boot database changes (e.g., my MSI MAG Tomahawk didn’t work properly until I’d flashed its UEFI, which included Secure Boot and CA-2023 elements built right in)
• Let Windows Update do its thing only AFTER the firmware is current: new updates and old firmware make for a volatile and issue-prone environment, as I learned on the ASRock B550 Extreme4 build
All in all, if users attempt Secure Boot compliance work from firmware updates to Windows updates, and only get into manual UEFI operations if necessary, they’re far less likely to get stuck in some pothole along that road.
How the scripts help solve Secure Boot update issuesSome of the most interesting developments during the CA-2023 rollout has been the emergence of community-driven tooling and diagnostics. In particular, Eleven Forum VIP and Guru user Garlin has provided a
50-page+ thread with useful PowerShell scripts, and backed them up with incredibly useful support and discussion. His scripts do the following:
• enumerate Secure Boot keys
• validate DB/DBX entries
• detect mismatches
• identify outdated bootloaders
• verify enforcement status
• generate detailed reports
For many users, Garlin’s scripts were the first clear window into what their firmware was actually doing. As an illustration of what the Garlin scripts illuminate, Figure 1 shows the output of his script named
Check_UEFI-CA2023.ps1, captured from my recently rebuilt MSI MAG Tomahawk B550 desktop:
Output from Check_UEFI-CA2023.ps1 on the MSI MAG B550 desktop PCCareful examination of the screenshot above shows the PC has both CA 2011 and CA 2023 Key Exchange Keys (KEKs) installed, with DB certs for UEFI CA 2011, Windows PCA 2011, and three flavors of CA 2023. The DBX certs list is empty (if you look below, you’ll see that CA 2011 hasn’t yet been revoked; once that happens, those entries should move here).
EFI files show that the boot manager allows UEFI CA 2023, as does the registry, and the latest Secure Boot code integrity policy is in place. MS uses this policy to block vulnerable or rollback-susceptible boot-critical binaries, particularly for Virtualization Based Security (VBS, as mentioned in the second item in the script’s overall output).
Finally, the script output shows the older CA-2011 certification hasn’t yet been revoked. That’s deliberate: I’m waiting to see how and when Microsoft will handle this through Windows Update, as they’ve promised to do sometime in the second half of 2026. We’ll see how that turns out…
Why these Scripts matterVendors rarely expose a PC’s full Secure Boot state. Windows surface only part of this picture. Firmware UIs are inconsistent and often call the same things by different names. Garlin’s scripts show us what’s going on inside the Secure Boot sphere, and tell us what actions might need to be taken to complete the overall process of updating and catching up.
What to do when Secure Boot won’t apply updatesHere’s a practical, step-by-step recovery workflow.
Step 1: Verify Current StateUse PowerShell or Garlin’s scripts to check:
• PK
• KEK
• DB
• DBX
• Enforcement status
• Bootloader versions
Step 2: Update FirmwareInstall the latest BIOS/UEFI update.
Step 3: Reset Keys to Factory DefaultsDisable Secure Boot, set Mode to Custom, then reset or install factory default keys (different UEFIs use varying terminology). Whatever they call it, this often clears mismatches.
Step 4: Re-enable Secure BootEnsure CSM is disabled (it often gets turned on when UEFI gets updated; it must be turned off for Secure Boot to be enabled).
Step 5: Apply DBX Update(s)Use Windows Update or vendor capsule(s), as available. Check the system (or motherboard) vendor’s support pages to look for UEFI and related updates. That’s what did the trick for my MSI MAG Tomahawk B550 motherboard.
Step 6: Rebuild Boot Files (if needed)You can use built-in commands to recreate your boot files by running the bcdboot C:\Windows /f UEFI command. Sometimes, it may be necessary to boot to a repair or rescue disk and run this from the Windows Recovery (WinRE) environment. It is always safer to take this approach, and it will get you past boot problems or secure boot policy blocks if and when they should pop up.
Step 7: Re-verify StateConfirm DBX contains CA 2023 entries. Indeed, this would be a good time to run Garlin’s Check_UEFI-CA2023.ps1 script. (Note: if you look inside the file’s Properties window and check the Unblock option, you can run this script in PowerShell without changing or bypassing local execution policy. This is depicted in the screenshot below)
IMO, the Secure Boot Ecosystem needs reformThe gradual rollout of CA 2023 and recent efforts to catch systems up to current Secure Boot compliance have been interesting. But it has also exposed a wide range of systemic issues and problems. For one thing, firmware vendors lack consistent implementations and terminology, so it falls on IT pros and other installers to make things work. To exacerbate things, documentation is often poor, and fails to address remediations when things break or don’t work properly.
Right now, update pipelines are fragile. One misstep (such as failing to set Secure Boot to Custom mode before seeking to reinstall default keys) can cause the update process to get stuck, and can interfere with normal boot behaviors. On one of my ASRock desktops, I couldn’t restart that PC normally, and could only use a deep, cold boot to get into UEFI or run through the boot cycle (this lasted two weeks before I switched motherboards to get things working normally again). This also drives my observation that OEMs and motherboard vendors vary widely in quality of Secure Boot implementation and handling. At the same time that the ASRock mobo was driving me bonkers, I had no problems with any of my Lenovo systems (some dating back to 2018), nor my Dell mini-PC or an ASUS Snapdragon laptop, either.
What I learned during this process is that Secure Boot is only as strong as its weakest link. Some systems, alas, have weak links. Many of those weak links turn what should be a routine update into a struggle. Some of them can require even more drastic measures, like a system replacement or motherboard swap.
What Microsoft, OEMs, and users must doAll the kids on this playground need to do certain things to improve the current Secure Boot morass. In my opinion, here’s how this shakes out across Microsoft, OEMs and the user community. To begin with, Microsoft should enforce stricter certification, with improved diagnostics and better tools (Garlin’s scripts are pretty straightforward in hindsight; there’s no reason why MS can’t offer more polished implementations to help things along).
Next, the OEMs could do a lot to standardize firmware behavior and adopt consistent terminology. They can test their DB update more and more thoroughly, and provide more insight and clarity into Secure Boot state and values in their UEFI interfaces. A robust, automated rollback tool would also help undo incorrect or bad choices.
And finally, users should take security more seriously. This means updating firmware as new updates emerge, and resolving to use (not disable) Secure Boot except when installs, configuration changes, or updates demand it be turned off (temporarily). Users should also verify their Secure Boot databases periodically to make sure they’re current and correct, and make sure their EFI partitions are healthy and up-to-date.
If everybody does their part, Secure Boot can do its job of protecting systems from boot and root-level compromise and attack. That’s pretty important, so I think it’s worth doing.
Secure Boot still matters, but it needs workSecure Boot remains an important defense mechanism in the Windows security model. But the CA 2023 saga shows that this ecosystem is fragile, inconsistent, and overdue for modernization. The good news is that the industry is learning. Firmware vendors are improving. Microsoft is tightening requirements. Community tools are filling gaps. But the lesson is clear: trust is no set-it-and-forget-it thing. Trust must be maintained, verified, and occasionally repaired. Secure Boot is no exception.
My closing advice is to watch the time ticking as you work to solve Secure Boot problems, should they present themselves. If a problem takes half a day to fix, that’s tolerable. Any longer than that, and it’s time to start thinking about alternatives, workarounds, and replacements. While you’re thinking, you can turn Secure Boot off: Windows still works without it. But you may, as I did, decide to replace balky, stuck hardware components rather than keep fighting, with no certain resolution in sight. It’s up to you!
■source
