Checking Secure Boot After the Certificate Expiry ── Confirming the Move to Windows UEFI CA 2023

On October 19, 2026, the certificate that has been signing the Windows Boot Manager, “Microsoft Windows Production PCA 2011”, expired. It is the last of the 2011 certificates, following the two that expired in June.

PCs keep booting after the expiry exactly as before. The trouble is that nothing breaks, so a missed update is easy to overlook. A PC that does not have the 2023 certificates in its firmware no longer receives new security fixes for the Boot Manager. If the 2011 certificate is later added to the revocation list, that PC will no longer be able to boot with a Boot Manager that carries the old signature.

This article explains how to check whether the Windows PCs and servers you use for business have moved to the 2023 certificates, and how to update the ones that have not. It covers Windows 11, Windows 10 with ESU, and Windows Server 2019 or later. It also covers points to watch for virtual machines and App Control for Business.

The commands, registry values and event IDs are based on Microsoft’s public documentation as checked on October 30, 2026. They were not run in the author’s environment, so check the actual output on your own PCs.

The Three Certificates That Expired

Secure Boot is the mechanism by which the firmware checks the signatures of the programs it loads during startup. The references used to check those signatures are stored in three areas inside the firmware.

• KEK: the keys that sign updates that change db and DBX.
• db: the list of signers that are allowed to boot.
• DBX: the list of signers and programs that are forbidden to boot.

According to the list of expiry dates and successors, the three 2011 certificates, their expiry dates, the areas they sit in and their successors are as follows.

The successor to Microsoft UEFI CA 2011 was split in two, so that a PC that needs to trust option ROMs does not also have to extend its trust to third-party boot loaders.

flowchart TB
        accTitle: The three Secure Boot areas and the 2023 certificates
        accDescr: Shows that KEK signs updates to db and DBX, and that the certificates in db check the signatures of the Boot Manager and third-party boot programs.
        KEK["KEK (KEK 2K CA 2023)"] -->|"signs updates"| DB["db (allowed list)"]
        KEK -->|"signs updates"| DBX["DBX (forbidden list)"]
        DB --> WIN["Windows UEFI CA 2023"]
        DB --> UEFI["Microsoft UEFI CA 2023"]
        DB --> OROM["Option ROM UEFI CA 2023"]
        WIN -->|"checks signature"| BM["Windows Boot Manager"]
        UEFI -->|"checks signature"| TP["Third-party boot loaders"]
        OROM -->|"checks signature"| OR["Option ROMs"]

Figure 1: KEK signs updates to db and DBX, and the certificates in db check the signatures of the programs that boot.

Windows Production PCA 2011 was used to sign not only boot loaders but also Windows binaries and security catalogs. According to KB5132953, since October 19, 2026 Microsoft has stopped using this certificate to sign either binaries or security catalogs.

In the diagram a solid line marks a relation that always holds and a dashed line marks a conditional one (the conditions are given per relation on the detail page). The full list of relations (27 in total, with evidence and certainty) and the definitions of the main concepts are collected on the knowledge map detail page (in Japanese). Data: JSON-LD / Turtle

Why PCs Still Boot After the Expiry, and Which Fixes Stop Arriving

Microsoft states that this expiry will not stop PCs from powering on or Windows from starting. Programs already signed with the 2011 certificates remain trusted on PCs whose db still contains those certificates.

What changes is the fixes released from now on. The last Windows Boot Manager signed with the 2011 certificate is frozen as it is, and it will receive no more fixes or security patches. All future boot loader fixes will be signed only through the Windows UEFI CA 2023 chain.

The explanation of what happens when the certificates expire lists the following consequences for a PC without the 2023 certificates.

• It cannot apply new Secure Boot and Boot Manager protections.
• It does not receive fixes for early-boot vulnerabilities, such as mitigations against BitLocker bypasses and updates to the Secure Boot revocation list.

flowchart TB
        accTitle: How booting and fixes differ depending on whether db has the 2023 certificate
        accDescr: Shows that with Windows UEFI CA 2023 in db the PC gets the new Boot Manager and fixes, and without it the PC keeps booting with the frozen 2011 Boot Manager.
        Q{"Is Windows UEFI CA 2023 in db?"}
        Q -->|"Yes"| A["Boots with the 2023 Boot Manager"]
        A --> A2["Receives boot-component fixes"]
        Q -->|"No"| B["Boots with the frozen 2011 version"]
        B --> B2["Boot-component fixes do not arrive"]
        B --> B3["Booting future media fails"]

Figure 2: A PC without Windows UEFI CA 2023 in db keeps booting but cannot receive boot-component fixes.

Future major releases of Windows will require Windows UEFI CA 2023 in db in order to boot from installation media and complete setup. The installation media Microsoft distributes will also switch to booting with a Boot Manager signed with the 2023 certificate. Booting such media on a PC whose db lacks the 2023 certificate fails with a Secure Boot violation. Microsoft has announced that it will provide a script that makes the media boot with the 2011 Boot Manager for such PCs.

The other scheduled step is the revocation of the 2011 certificate. According to KB5025885, Windows Production PCA 2011 will in the future be added to DBX and revoked on supported PCs, and users will not be able to prevent this. No date has been announced for this phase yet, and Microsoft says it will give at least six months’ notice before it starts. Once the certificate is in DBX, a Boot Manager that carries only the 2011 signature can no longer boot that PC.

flowchart TB
        accTitle: Expiry dates of the 2011 certificates and what comes next
        accDescr: Shows that the three certificates expire on June 24, June 27 and October 19, 2026, followed by revocation through DBX on a date not yet announced.
        D1["June 24, 2026: KEK CA 2011 expires"] --> D2["June 27, 2026: UEFI CA 2011 expires"]
        D2 --> D3["October 19, 2026: PCA 2011 expires"]
        D3 --> D4["Date not announced: PCA 2011 added to DBX"]
        D4 --> D5["2011 signatures can no longer boot"]

Figure 3: The three certificates expire in 2026, and no date has been announced for revocation through DBX.

There is still time to update after the expiry. Microsoft’s FAQ explains that cumulative updates containing the new certificates can be applied even if the existing certificates have expired. On a PC that boots Windows and can install updates, the published procedure writes the certificates to the firmware.

Checking Whether Your PCs Have Moved

Check in the following order. Run PowerShell as an administrator.

flowchart TB
        accTitle: Order for checking the Secure Boot certificate migration
        accDescr: Shows checking, in order, that Secure Boot is enabled, that db contains Windows UEFI CA 2023, and the value of UEFICA2023Status, and looking at the event log if the process has stopped.
        S1{"Does Confirm-SecureBootUEFI return True?"} -->|"False"| N1["Certificates do not arrive while it is off"]
        S1 -->|"True"| S2{"Is Windows UEFI CA 2023 in db?"}
        S2 -->|"No"| N2["Update has not started or has stalled"]
        S2 -->|"Yes"| S3{"Is UEFICA2023Status Updated?"}
        S3 -->|"Updated"| OK["Migration complete"]
        S3 -->|"NotStarted or InProgress"| N3["Find the stalled stage in the event log"]
        N2 --> N3

Figure 4: Check that Secure Boot is enabled, then db, then the update status, and look at the event log if it has stalled.

Is Secure Boot enabled?

First, check whether Secure Boot is enabled. If it returns True, it is enabled.

Confirm-SecureBootUEFI

On a PC with Secure Boot disabled, the new certificates are not written to the firmware. The FAQ explains that such PCs remain unprotected against malware that runs at boot time. If you find a PC with Secure Boot disabled, confirm where its BitLocker recovery key is stored before deciding whether to enable it. Why changing Secure Boot settings can put BitLocker into recovery mode is explained in the TPM article.

Is Windows UEFI CA 2023 in db?

Next, check whether Windows UEFI CA 2023 is in db. This is the command given in KB5025885; if it returns True, the certificate is there.

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'

On PCs that have the monthly cumulative update of April 14, 2026 or later, Get-SecureBootUEFI accepts the -Decoded parameter. According to the description of the Decoded parameter, it shows certificate names and expiry dates in a readable form.

Get-SecureBootUEFI -Name db -Decoded

If CN=Windows UEFI CA 2023 appears in the Subject field of the output, the 2023 certificate is in db. The ValidTo of CN=Microsoft Windows Production PCA 2011 is 2026-10-19 11:51:42Z. The 2011 certificate remaining in db is not in itself a problem.

Has the update finished completely?

Even after the certificate is in db, the KEK update and the Boot Manager replacement may still be outstanding. Check whether the whole process has finished with UEFICA2023Status in the registry.

(Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing").UEFICA2023Status

According to the registry documentation, the value changes as follows.

• NotStarted: the update has not run yet.
• InProgress: the update is in progress.
• Updated: all the new keys and the Boot Manager have been installed.

If an error occurs, UEFICA2023Error gets a nonzero code and the status stays at InProgress. WindowsUEFICA2023Capable, in the same key, is for reference only; Microsoft states explicitly that you should use UEFICA2023Status, not that value, to check the status.

flowchart TB
        accTitle: How the UEFICA2023Status value changes
        accDescr: Shows UEFICA2023Status changing from NotStarted through InProgress to Updated, and staying at InProgress with a code in UEFICA2023Error when an error occurs.
        NS["NotStarted (has not run yet)"] --> IP["InProgress (in progress)"]
        IP --> UP["Updated (all installed)"]
        IP -->|"an error occurred"| ER["A code is set in UEFICA2023Error"]

Figure 5: UEFICA2023Status changes from NotStarted to InProgress to Updated, and stops at InProgress on an error.

Finding the stalled stage in the event log

The progress of the update is recorded in the System log as events from the source “TPM-WMI”. Of the listed events, these are the ones you will look at most often when checking.

The following command lists these events, newest first.

Get-WinEvent -FilterHashtable @{ LogName = 'System'; Id = 1795, 1799, 1800, 1801, 1803, 1808 } -MaxEvents 20 |
    Where-Object ProviderName -like '*TPM-WMI*' |
    Select-Object TimeCreated, Id, Message

If 1808 appears, that PC has finished the update. What to do when 1801, 1795 or 1803 appears is explained later in “When the update does not progress”.

What the Windows Security app shows

The “Device security” page of the Windows Security app also shows the state of the Secure Boot certificates. However, Microsoft says that a green check mark alone does not mean the certificates have been updated. Also check whether the text “Secure Boot is on and all required certificate updates have been applied.” is shown.

On Windows 10, Windows 11 and Windows Server managed by an organization, notifications and badges about Secure Boot certificates are not shown by default. Administrators can show them by setting HideSecureBootStates to 0. With many PCs, collecting UEFICA2023Status and the events is more reliable than going around and looking at each PC’s screen.

Updating PCs That Have Not Moved

The update work starts with checking the BitLocker recovery keys.

Check the BitLocker recovery keys first

KB5132953 asks you to record the BitLocker recovery key in a safe place before installing updates that affect the boot path, the firmware or Secure Boot. Monthly quality updates are included in this. KB5025885 advises running the following command as an administrator and recording the 48-digit recovery password it shows.

manage-bde -protectors -get $env:SystemDrive

According to the manage-bde documentation, -get lists the protectors that are enabled on the drive and shows their type and ID. What it shows is information stored inside that PC, so this command cannot tell you whether a copy exists outside the PC. If your organization keeps a copy, confirm that its ID matches the ID shown and that you can retrieve it. If there is no copy, store the recovery password shown in a safe place before updating.

The troubleshooting guide lists two cases in which BitLocker enters recovery mode after a Secure Boot update.

1. It enters recovery mode only on the first boot after the update. The cause is that the firmware has not yet reported the new values, so BitLocker cannot reseal its key; from the next boot on, the PC starts normally.
2. It enters recovery mode on every boot. This happens on PCs configured to try network boot (PXE) first. The PXE path is signed with Microsoft UEFI CA 2011; if you do not need PXE, disable it, and if you do, use the Windows boot loader signed with the 2023 certificate on the PXE infrastructure.

flowchart TB
        accTitle: Two cases in which BitLocker enters recovery mode after a Secure Boot update
        accDescr: Shows the causes and remedies for entering recovery mode only on the first boot after the update and for entering it on every boot when PXE is tried first.
        R{"When does it enter recovery mode?"}
        R -->|"Only on the first boot after the update"| R1["Firmware has not reported the new values"]
        R1 --> R1A["Unlock with the recovery key; boots normally after that"]
        R -->|"On every boot"| R2["PXE goes through the UEFI CA 2011 path"]
        R2 --> R2A["Disable PXE if it is not needed"]
        R2 --> R2B["Use the 2023 loader for PXE"]

Figure 6: Recovery on the first boot only happens once; recovery on every boot calls for revisiting the PXE configuration.

How to find and manage recovery keys is explained in the BitLocker practical guide.

Leaving it to Windows Update

For many PCs, the certificate update arrives automatically with the monthly cumulative updates. Microsoft may automatically include groups of PCs that it judges to be “high confidence”, based on the diagnostic data collected so far, in the targets of the monthly updates. This path is enabled by default and works even if the PC is not configured to send diagnostic data. The October cumulative update also continues the rollout while refreshing which PCs are targeted.

The component that actually writes the certificates is the scheduled task \Microsoft\Windows\PI\Secure-Boot-Update. This task runs as SYSTEM at startup and every 12 hours. On a PC where this task has been disabled or deleted, the certificate update cannot be applied.

Starting the update does not in itself restart the PC. At stages that need a restart, it waits for the user to restart in the course of normal use. The Boot Manager may not be replaced until a restart has happened.

Microsoft states explicitly that this automatic rollout is assistance, not a guarantee, and that administrators remain responsible for confirming that every PC has been updated. Even if you rely on the automatic rollout, collect the status of all PCs with the checks in the previous section.

Having administrators direct the rollout

For PCs that are not included in the automatic rollout, administrators can direct the update. To try it on a single PC, write 0x5944 to AvailableUpdates in the registry and run the task immediately.

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

The value soon changes to 0x4100. Restart the PC at that point and run the task once more; the Boot Manager is replaced and the value becomes 0x4000. 0x4000 is the value that remains, and it indicates that the whole update has finished.

The bits of 0x5944 are cleared one at a time as the task processes each step. According to the troubleshooting guide, the order and the events recorded are as follows.

flowchart TB
        accTitle: Order in which the AvailableUpdates value changes from 0x5944 to 0x4000
        accDescr: Shows that processing starts by adding Windows UEFI CA 2023 to db and continues with Option ROM and UEFI CA 2023, the KEK and the Boot Manager, until the value becomes 0x4000.
        V0["0x5944 (update requested)"] -->|"Add Windows UEFI CA 2023 (1036)"| V1["0x5904"]
        V1 -->|"Option ROM UEFI CA 2023 (1044)"| V2["0x5104"]
        V2 -->|"Microsoft UEFI CA 2023 (1045)"| V3["0x4104"]
        V3 -->|"Update KEK (1043)"| V4["0x4100 (restart here)"]
        V4 -->|"Replace Boot Manager (1799)"| V5["0x4000 (all done)"]

Figure 7: The AvailableUpdates bits are processed and cleared in the order db, KEK, Boot Manager. The numbers in parentheses are the event IDs on success.

The 0x4000 bit puts a condition on adding Microsoft UEFI CA 2023 and Option ROM UEFI CA 2023. These two are added only to PCs whose db already contains Microsoft UEFI CA 2011.

With many PCs, distribute the same instruction through Group Policy or Intune.

• Group Policy: under “Computer Configuration”, go to “Administrative Templates”, open “Windows Components” and then “Secure Boot”, and configure “Enable Secure Boot Certificate Deployment”. You need to install the latest administrative templates from Microsoft’s download site first.
• Intune: deploy it with “Enable Secureboot Certificate Updates” in the settings catalog. “Configure High Confidence Opt-Out”, which excludes PCs from the high-confidence automatic rollout, is in the same settings catalog.

flowchart TB
        accTitle: Paths for directing the certificate update
        accDescr: Shows that whether the update is directed by the monthly cumulative update, Group Policy, Intune or writing the registry directly, the Secure-Boot-Update task writes the certificates to the firmware.
        P1["Monthly cumulative update"] --> T["Secure-Boot-Update task"]
        P2["Group Policy"] --> T
        P3["Intune settings catalog"] --> T
        P4["0x5944 in AvailableUpdates"] --> T
        T --> F["Writes certificates to db and KEK"]
        T --> BM["Replaces the Boot Manager"]

Figure 8: Whichever path directs the update, the Secure-Boot-Update task is what writes the certificates.

When the update does not progress

What to do next depends on the ID that appears in the event log.

• If 1800 appears, restarting continues the update.
• If 1801 appears, the certificates have not yet been applied to the firmware. As the event text says, check the published procedure and complete the application.
• If 1795 appears, the firmware is returning an error. Record the error code in the event and check for a firmware update from the manufacturer.
• If 1803 appears, this PC has no KEK signed with the PK. As the event text says, ask the manufacturer to provide the key. For older PCs whose manufacturers no longer release keys or firmware, there is no supported manual recovery method.

Even if the KEK cannot be updated, the task continues with the Boot Manager replacement. For that reason, the Boot Manager may already be the 2023 version even when 1803 appears.

flowchart TB
        accTitle: Event IDs when the update does not progress and the next action
        accDescr: Shows restarting for event 1800, completing the application with the published procedure for 1801, checking for a firmware update for 1795, and asking the manufacturer for 1803.
        E{"Which event ID appears?"}
        E -->|"1800"| A1["Restart"]
        E -->|"1801"| A2["Complete with the published procedure"]
        E -->|"1795"| A3["Check for a firmware update"]
        E -->|"1803"| A4["Ask the manufacturer for the key"]

Figure 9: When the update does not progress, choose the action by the event ID that appears.

Firmware defects also need attention. According to the troubleshooting guide, some firmware overwrites db instead of adding the new certificate to it. Also, if you reset the Secure Boot keys to factory defaults in the firmware settings after updating the certificates, the PC may become unable to boot. In that case, take SecureBootRecovery.efi from C:\Windows\Boot\EFI\ on another PC that has updates from July 2024 or later installed, and use it. The procedure is in the troubleshooting guide.

Do not disable Secure Boot just because the update is not going well. Microsoft states explicitly that Secure Boot must not be disabled as a way to deal with the certificate expiry. Disabling it removes the protection against malware that runs at boot time, and that PC will not receive the new certificates either.

Where Business Environments Are Most Likely to Be Affected

Environments that use App Control for Business, virtual machines, older operating systems, and environments that use PXE or Linux need more checks than ordinary PCs.

App Control for Business policies

Take care if an App Control for Business (formerly WDAC) policy has rules that allow Microsoft-signed code by a specific certificate authority or thumbprint. A rule that names Windows Production PCA 2011 is an example. According to KB5132953, updated Windows binaries and security catalogs are signed by a different certificate authority, so they do not match such rules and may be blocked in enforcement mode.

The symptoms listed include cumulative updates failing to install, services failing at startup, executables or DLLs being blocked, and Code Integrity event 3077 appearing. Look in the policy XML for signer rules that point to Microsoft certificate authorities, and deploy any changes in audit mode first, check the results, and only then switch to enforcement. How to build such policies is explained in the article on AppLocker and App Control for Business.

flowchart TB
        accTitle: App Control for Business rules and updated binaries
        accDescr: Shows that updated binaries are signed by a different certificate authority, so they do not match rules naming PCA 2011 and may be blocked in enforcement mode, and the remedy of finding the rules and checking in audit mode.
        U["Updated Windows binaries"] --> C["Signed by a CA other than PCA 2011"]
        C --> R{"Is there a rule naming PCA 2011?"}
        R -->|"Yes"| B["May be blocked in enforcement mode"]
        B --> F1["Find the rule in the policy XML"]
        F1 --> F2["Deploy in audit mode and check"]
        F2 --> F3["Enforce after reviewing the results"]
        R -->|"No"| OK["Not affected by this rule"]

Figure 10: Rules that name PCA 2011 do not match updated binaries, so check in audit mode before fixing them.

Virtual machines

According to KB5132953, Generation 2 Hyper-V virtual machines receive the new certificates through the normal cumulative updates. However, the troubleshooting guide says that updating the certificates in a Hyper-V virtual machine requires the March 2026 update on both the host and the guest. The event that appears in the guest tells you which one to update.

• If 1795 (for example, “The media is write-protected”) appears in the guest, the Hyper-V host does not have the March update.
• If 1803 appears in the guest, the guest itself does not have the March update.

flowchart TB
        accTitle: Isolating a failed KEK update in a Hyper-V virtual machine
        accDescr: Shows bringing the Hyper-V host up to the March 2026 update when event 1795 appears in the guest, and the guest when 1803 appears.
        G{"Which event appears in the guest?"}
        G -->|"1795"| H["Install the March 2026 update on the host"]
        G -->|"1803"| V["Install the March 2026 update on the guest"]

Figure 11: The event ID in the Hyper-V guest tells you whether to update the host or the guest.

For VMware vSphere, KB5132953 advises upgrading the ESXi host and the virtual machine hardware version to versions whose guest UEFI template includes the 2023 certificates. On Azure Trusted Launch virtual machines there is a known issue that produces event 1795, and Microsoft says no action is needed from users.

Windows 10 and unsupported operating systems

According to the FAQ, only supported versions of Windows can receive the new certificates. KB5132953 covers Windows 10 ESU and Windows 10 LTSB 2016 ESU. Windows 10 PCs without ESU cannot receive the certificates through this path. Whether to keep using Windows 10 is discussed in the article on Windows 10 after end of support.

Installation media and PXE

As explained earlier, future installation media will boot with a Boot Manager signed with the 2023 certificate. If you maintain USB media for kitting or a PXE deployment infrastructure in-house, first check whether the db of the target PCs contains Windows UEFI CA 2023. As seen in the BitLocker section, a loader signed with Microsoft UEFI CA 2011 left on the PXE path can also cause repeated recovery mode.

Linux and third-party boot loaders

According to Microsoft’s announcement for hardware developers, binaries that are already signed do not become invalid when Microsoft UEFI CA 2011 expires. On PCs whose db still contains the 2011 certificate, they remain trusted as before. On the other hand, the only binaries Microsoft signs and returns from June 26, 2026 onward are those signed with the 2023 UEFI CA.

For Linux virtual machines on Azure, according to the guidance for Linux on Azure, virtual machines without the 2023 certificates keep booting, but they cannot receive shim updates or future certificates and revocation lists.

flowchart TB
        accTitle: How binaries signed with Microsoft UEFI CA 2011 are treated
        accDescr: Shows that signed binaries remain trusted as long as db has the 2011 certificate, and that the only signatures Microsoft returns from June 26, 2026 onward are 2023 ones.
        S["Binaries signed with UEFI CA 2011"] --> Q{"Is UEFI CA 2011 in db?"}
        Q -->|"Yes"| T["Trusted as before"]
        N["Signatures from June 26, 2026"] --> N2["Signed only with the 2023 UEFI CA"]
        T --> L["New fixes such as shim arrive with 2023"]
        N2 --> L

Figure 12: Binaries signed with the 2011 certificate stay trusted, but new signatures are 2023 only.

Related Articles

• What Is the TPM in Windows?
• BitLocker Practical Guide
• Practical Options After Windows 10 End of Support

References

Microsoft’s support documents were checked on October 30, 2026. The certificate update procedure is still being revised, so check the latest version before you start work.

• Microsoft Support, Windows Production CA 2011 expiration and bootloader updates (KB5132953). The impact of the October 19 expiry, the freezing of the Boot Manager, installation media, and the notes on App Control and virtual machines.
• Microsoft Support, Windows Secure Boot certificate expiration and CA updates. The expiry dates of the three certificates, the areas they are stored in, and their successors.
• Microsoft Support, When Secure Boot certificates expire on Windows devices. The protections that stop arriving after the expiry, and the warning not to disable Secure Boot.
• Microsoft Support, Frequently asked questions about the Secure Boot update process. Applying updates after the expiry, delivery only to supported operating systems, and that the automatic rollout is not a guarantee.
• Microsoft Support, KB5025885: How to manage the Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932. The command for checking db, checking UEFICA2023Status, and the planned revocation through DBX.
• Microsoft Learn, manage-bde protectors. That -get shows the type and ID of each protector.
• Microsoft Support, Registry key updates for Secure Boot: Windows devices with IT-managed updates. AvailableUpdates, UEFICA2023Status, the procedure for trying it manually, and how restarts are handled.
• Microsoft Support, Secure Boot troubleshooting guide. The order of the AvailableUpdates bits, BitLocker recovery, KEK and firmware problems, and isolating Hyper-V issues.
• Microsoft Support, Secure Boot DB and DBX variable update events (KB5016061). The meaning of the TPM-WMI event IDs.
• Microsoft Support, Using the -Decoded parameter in Get-SecureBootUEFI. The parameter that shows the certificates in db in a readable form.
• Microsoft Support, Secure Boot certificate update status in the Windows Security app. What the Windows Security app shows, and the note that a green check mark alone is not enough.
• Microsoft Support, Secure Boot certificate updates: Guidance for IT professionals and organizations. Checking that Secure Boot is enabled, and the high-confidence automatic rollout.
• Microsoft Support, Group Policy Objects (GPO) method of Secure Boot for Windows devices with IT-managed updates. The location and name of the Group Policy setting.
• Microsoft Support, Microsoft Intune method of Secure Boot for Windows devices with IT-managed updates. The Intune settings catalog items.
• Microsoft Tech Community, Signing with the new 2023 Microsoft UEFI certificates: What submitters need to know. How already-signed binaries are treated, and signing from June 26, 2026 onward.
• Microsoft Support, Secure Boot certificate updates for Linux on Azure virtual machines. The impact on Linux virtual machines on Azure.

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These are topic pages close to this theme. Starting from the article, you can go on to related services and other articles.

Services Connected to This Topic

This article leads to the following service pages. Start from the entry point closest to your situation.

Frequently Asked Questions

Questions commonly asked at the time of consultation about the topic of this article.

Will a PC stop booting once its Secure Boot certificates expire?

No, it keeps booting. Microsoft states that the expiry will not stop a PC from powering on or Windows from starting. However, a PC without the 2023 certificates no longer receives new security fixes for its boot components.

Can the 2023 certificates still be installed after the expiry date?

Yes. Microsoft states that cumulative updates containing the new certificates can be applied even when the existing certificates have already expired. On a PC that boots Windows and can install updates, the published procedure writes the certificates to the firmware.

If Windows Security shows a green check mark, is the PC updated?

That alone does not confirm it. Microsoft notes that a green check mark does not by itself mean the certificates have been updated, and advises also checking for the text “Secure Boot is on and all required certificate updates have been applied.” On managed PCs, also check that UEFICA2023Status in the registry reads Updated.

If the certificate update fails, should I just turn Secure Boot off?

Do not turn it off. Microsoft explicitly says Secure Boot must not be disabled as a way to deal with the certificate expiry. A PC with Secure Boot disabled does not receive the new certificates and loses its protection against malware that runs at boot time.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and bug investigation, with particular strength in projects where existing assets remain and in investigating failures whose cause is hard to see.