Troubleshooting
Applies To
Original publish date: March 19, 2026
KB ID: 5085046
In this article
Overview
This page guides administrators and support professionals in diagnosing and resolving Secure Boot–related issues on Windows devices. Topics include Secure Boot certificate update failures, incorrect Secure Boot states, unexpected BitLocker recovery prompts, and boot failures following Secure Boot configuration changes.
The guidance explains how to verify Windows servicing and configuration, review relevant registry values and event logs, and identify when firmware or platform limitations require an OEM update. This content is intended for diagnosing issues on existing devices. It isn’t meant for planning new deployments. This document will be updated as new troubleshooting scenarios and guidance are identified.
How Secure Boot certificate servicing works
Secure Boot certificate servicing on Windows is a coordinated process between the operating system and a device’s UEFI firmware. The goal is to update critical trust anchors while preserving the ability to boot at each stage.
The process is driven by a Windows scheduled task, a registry‑based sequence of update actions, and built‑in logging and retry behavior. Together, these components ensure that Secure Boot certificates and the Windows boot manager are updated in a controlled, ordered manner, and only after prerequisite steps succeed.
Where to start when troubleshooting
When a device doesn’t appear to be making expected progress applying Secure Boot certificate updates, start by identifying the category of the issue. Most problems fall into one of four areas: Windows servicing state, the Secure Boot update mechanism, firmware behavior, or a platform or OEM limitation.
Begin with the checks below, in order. In many cases, these steps are sufficient to explain the observed behavior and determine next actions without deeper investigation.
-
Confirm Windows servicing and platform eligibility
-
Verify that the device meets the basic requirements to receive Secure Boot certificate updates:
-
The device is running a supported version of Windows.
-
The latest required Windows security updates are installed.
-
Secure Boot is enabled in UEFI firmware.
-
If any of these conditions aren’t met, address them before continuing with further troubleshooting.
-
-
Verify the Secure-Boot-Update task status
-
Confirm that the Windows mechanism responsible for applying Secure Boot certificate updates is present and functioning:
-
The Secure-Boot-Update scheduled task exists.
-
The task is enabled and runs as Local System.
-
The task has run at least once since the most recent Windows security update was installed.
-
If the task is disabled, deleted, or not running, Secure Boot certificate updates cannot be applied. Troubleshooting should focus on restoring the task before investigating other causes.
-
-
Check registry settings for expected progression
Review the device’s Secure Boot servicing state in the registry:
-
Examine UEFICA2023Status, UEFICA2023Error, and UEFICA2023ErrorEvent.
-
Examine AvailableUpdates and compare it to the expected progression (see Reference and Internals).
Together, these values indicate whether servicing is progressing normally, retrying an operation, or stalled at a specific step.
-
-
Correlate registry state with Secure Boot events
Review Secure Boot–related events in the System event log and correlate them with the registry state. Event data typically confirms whether the device is making forward progress, retrying due to a transient condition, or blocked by a firmware or platform issue.
Together, the registry and event logs usually indicate whether the behavior is expected, temporary, or requires corrective action.
Secure-Boot-Update scheduled task
Secure Boot certificate servicing is implemented through a Windows scheduled task named Secure‑Boot‑Update. The task is registered at the following path:
\Microsoft\Windows\PI\Secure-Boot-Update
The task runs as Local System. By default, it runs at system startup and every 12 hours thereafter. Each time it runs, it checks whether Secure Boot update actions are pending and attempts to apply them in sequence.
If this task is disabled or missing, Secure Boot certificate updates cannot be applied. The Secure‑Boot‑Update task must remain enabled for Secure Boot servicing to function.
Why a scheduled task is used
Secure Boot certificate updates require coordination between Windows and UEFI firmware, including writing UEFI variables that store Secure Boot keys and certificates. A scheduled task allows Windows to attempt these updates when the system is in a state where firmware variables can be modified.
The recurring 12-hour schedule provides additional opportunities to retry updates if a previous attempt failed or if the device remained powered on without restarting. This design helps ensure forward progress without requiring manual intervention.
The AvailableUpdates registry bitmask
The Secure‑Boot‑Update task is driven by the AvailableUpdates registry value. This value is a 32‑bit bitmask located at:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot
Each bit in the value represents a specific Secure Boot update action. The update process begins when AvailableUpdates is set to a non‑zero value, either automatically by Windows or explicitly by an administrator. For example, a value such as 0x5944 indicates that multiple update actions are pending.
When the Secure-Boot-Update task runs, it interprets the set bits as pending work and processes them in a defined order.
Sequential updates, logging, and retrial behavior
Secure Boot certificate updates are applied in a fixed order. Each update action is designed to be safe to retry and completes independently. The Secure‑Boot‑Update task doesn’t advance to the next step until the current action succeeds, and its corresponding bit is cleared from AvailableUpdates.
Each operation uses standard UEFI interfaces to update Secure Boot variables such as the DB and KEK, or to install the updated Windows boot manager. Windows records the outcome of every step in the System event log. Success events confirm forward progress, while failure events indicate why an action couldn’t be completed.
If an update step fails, the task stops processing, logs the error, and leaves the associated bit set. The operation is retried the next time the task runs. This retrial behavior allows devices to recover automatically from temporary conditions, such as missing firmware support or delayed OEM updates.
Administrators can track progress by correlating registry state with event log entries. Registry values such as UEFICA2023Status, UEFICA2023Error, and UEFICA2023ErrorEvent, together with the AvailableUpdates bitmask, indicate which step is active, completed, or blocked.
This combination shows whether the device is progressing normally, retrying an operation, or stalled.
Integration with OEM firmware
Secure Boot certificate updates depend on correct behavior and support in a device’s UEFI firmware. While Windows orchestrates the update process, the firmware is responsible for enforcing Secure Boot policy and maintaining the Secure Boot databases.
OEMs provide two critical elements that enable Secure Boot certificate servicing:
-
Platform Key–signed Key Exchange Keys (KEKs) that authorize installation of new Secure Boot certificates.
-
Firmware implementations that correctly preserve, append, and validate Secure Boot databases during updates.
If firmware doesn’t fully support these behaviors, Secure Boot updates can stall, retry indefinitely, or result in boot failures. In these cases, Windows cannot complete the update without changes to the firmware.
Microsoft works with OEMs to identify firmware issues and make corrected updates available. When troubleshooting indicates a firmware limitation or defect, administrators may need to install the latest UEFI firmware update provided by the device manufacturer before Secure Boot certificate updates can complete successfully.
Common failure scenarios and resolutions
Secure Boot updates are applied by the Secure‑Boot‑Update scheduled task based on the AvailableUpdates registry state.
Under normal conditions, these steps occur automatically and record success events as each stage completes. In some cases, firmware behavior, platform configuration, or servicing prerequisites can prevent progress or lead to unexpected boot behavior.
The sections below describe the most common failure scenarios, how to recognize them, why they occur, and the appropriate next steps to restore normal operation. Scenarios are ordered from most commonly encountered to more severe boot-impacting cases.
When Secure Boot updates show no progress, it typically means that the update process never started. As a result, the expected Secure Boot registry values and event logs are missing because the update mechanism was never triggered.
What happened
The Secure Boot update process didn’t start, so no Secure Boot certificates or updated boot manager were applied to the device.
How to recognize it
-
No Secure Boot servicing registry values are present, such as UEFICA2023Status.
-
Expected Secure Boot events (for example, 1043, 1044, 1045, 1799, 1801) are missing from the System event log.
-
The device continues using older Secure Boot certificates and boot components.
Why it happens
This scenario typically occurs when one or more of the following conditions are true:
-
The Secure‑Boot‑Update scheduled task is disabled or missing.
-
Secure Boot is disabled in UEFI firmware.
-
The device doesn’t meet Windows servicing prerequisites, such as running a supported Windows version or having required updates installed.
What to do next
-
Verify that the device meets Windows servicing and platform eligibility requirements.
-
Confirm that Secure Boot is enabled in firmware.
-
Ensure that the SecureBootUpdate scheduled task exists and is enabled.
If the scheduled task is disabled or missing, follow the guidance in Secure Boot scheduled task disabled or deleted to restore it. After the task is restored, restart the device or run the task manually to initiate Secure Boot servicing.
In some cases, Secure Boot–related updates can cause a device to enter BitLocker recovery. The behavior can be transient or persistent, depending on the underlying cause.
Scenario 1: Onetime BitLocker recovery after Secure Boot update
What happens
The device enters BitLocker recovery on the first boot after the Secure Boot update, but boots normally on subsequent restarts.
Why it happens
During the first boot after the update, firmware doesn’t yet report the updated Secure Boot values when Windows attempts to reseal BitLocker. This causes a temporary mismatch in measured boot values and triggers recovery. On the next boot, firmware reports the updated values correctly, BitLocker reseals successfully, and the issue doesn’t recur.
How to recognize it
-
BitLocker recovery occurs once.
-
After entering the recovery key, subsequent boots don’t prompt recovery.
-
No ongoing boot order or PXE involvement is present.
What to do next
-
Enter the BitLocker recovery key to resume Windows.
-
Check for firmware updates.
Scenario 2: Repeated BitLocker recovery due to PXE first boot configuration
What happens
The device enters BitLocker recovery on every boot.
Why it happens
The device is configured to attempt PXE (network) boot first. The PXE boot attempt fails, and the firmware then falls back to the on-disk Windows boot manager.
This results in two different signing authorities being measured during a single boot cycle:
-
The PXE boot path is signed by the Microsoft UEFI CA 2011.
-
The on-disk Windows boot manager is signed by the Windows UEFI CA 2023.
Because BitLocker observes different Secure Boot trust chains during startup, it cannot establish a stable set of TPM measurements to reseal against. As a result, BitLocker enters recovery on every boot.
How to recognize it
-
BitLocker recovery is triggered on every restart.
-
Entering the recovery key allows Windows to start, but the prompt returns on the next boot.
-
PXE or network boot is configured ahead of the local disk in firmware boot order.
What to do next
-
Configure the firmware boot order, so the on-disk Windows boot manager is first.
-
Disable PXE boot if it’s not required.
-
If PXE is required, ensure the PXE infrastructure uses a 2023-signed Windows boot loader.
What happened
This reflects a firmware-level change rather than a Windows issue. The Secure Boot update was completed successfully, but after a later restart, the device no longer boots into Windows.
How to recognize it
-
The device fails to start Windows and might display a firmware or BIOS message indicating a Secure Boot violation.
-
The failure occurs after Secure Boot settings are reset to firmware defaults.
-
Disabling Secure Boot might allow the device to boot again.
Why it happens
Resetting Secure Boot to firmware defaults clears the Secure Boot databases stored in firmware. On devices that have already transitioned to the Windows UEFI CA 2023–signed boot manager, this reset removes the certificates required to trust that boot manager.
As a result, the firmware no longer recognizes the installed Windows boot manager as trusted and blocks the boot process.
This scenario isn’t caused by the Secure Boot update itself but by a subsequent firmware action that removes the updated trust anchors.
What to do next
-
Use the Secure Boot recovery utility to restore the required certificate, so the device can boot again.
-
After recovery, ensure the device has the latest available firmware installed from the device manufacturer.
-
Avoid resetting Secure Boot to firmware defaults unless the OEM firmware includes updated Secure Boot defaults that trust the 2023 certificates.
Secure Boot recovery utility
To recover the system:
-
On a second Windows PC with the July 2024 or newer Windows update installed, copy SecureBootRecovery.efi from C:\Windows\Boot\EFI\.
-
Place the file on a FAT32-formatted USB drive under \EFI\BOOT\ and rename it to bootx64.efi.
-
Boot the affected device from the USB drive and allow the recovery utility to run. The utility will add the Windows UEFI CA 2023 to the DB.
After the certificate is restored and the system restarts, Windows should start normally.
Important: This process will only reapply one of the new certificates. Once the device is recovered, ensure that it has the latest certificates reapplied, and consider updating the system’s BIOS/UEFI to the newest version available. This can help prevent a recurrence of the Secure Boot reset issue, as many OEMs have released firmware fixes for this specific problem.
What happened
After applying the Secure Boot certificate update and restarting, the device fails to boot and doesn’t reach Windows.
How to recognize it
-
The device fails immediately after the restart required by the Secure Boot update.
-
A firmware or Secure Boot error may be displayed, or the system can stop before Windows loads.
-
Disabling Secure Boot might allow the device to boot.
Why it happens
This issue might be caused by a defect in the device’s UEFI firmware implementation.
When Windows applies Secure Boot certificate updates, the firmware is expected to append new certificates to the existing Secure Boot allowed signature database (DB). Some firmware implementations incorrectly overwrite the DB instead of appending to it.
When this occurs,
-
Previously trusted certificates, including the Microsoft 2011 bootloader certificate, are removed.
-
If the system is still using a boot manager signed with the 2011 certificate at that point, the firmware no longer trusts it.
-
The firmware rejects the boot manager and blocks the boot process.
In some cases, the DB may also become corrupted rather than cleanly overwritten, leading to the same outcome. This behavior has been observed on specific firmware implementations and isn’t expected on compliant firmware.
What to do next
-
Enter the firmware setup menus and attempt to reset Secure Boot settings.
-
If the device boots after the reset, check the device manufacturer’s support site for a firmware update that corrects Secure Boot DB handling.
-
If a firmware update is available, install it before re‑enabling Secure Boot and reapplying Secure Boot certificate updates.
If resetting Secure Boot doesn’t restore boot functionality, further recovery likely requires OEM-specific guidance.
What happened
The Secure Boot certificate update isn’t completed and remains blocked at the Key Exchange Key (KEK) update stage.
How to recognize it
-
The AvailableUpdates registry value remains set with the KEK bit (0x0004) and doesn’t get cleared.
-
UEFICA2023Status doesn’t progress to a completed state.
-
The System event log repeatedly records Event ID 1803, indicating that the KEK update couldn’t be applied.
-
The device continues retrying the update without making forward progress.
Why it happens
Updating the Secure Boot KEK requires authorization from the device’s Platform Key (PK), which is owned by the OEM.
For the update to succeed, the device manufacturer must provide Microsoft with a PK-signed KEK for that specific platform. This OEM-signed KEK is included in Windows updates and allows Windows to update the firmware KEK variable.
If the OEM hasn’t provided a PK-signed KEK for the device, Windows cannot complete the KEK update. In this state:
-
Secure Boot updates are blocked by design.
-
Windows cannot work around the missing authorization.
-
The device can remain permanently unable to complete Secure Boot certificate servicing.
This can occur on older or out-of-support devices where the OEM no longer provides firmware or key updates. There’s no supported manual recovery path for this condition.
When Secure Boot certificate updates fail to apply, Windows records diagnostic events that explain why progress was blocked. These events are written when updating the Secure Boot signature database (DB) or Key Exchange Key (KEK) cannot be safely completed due to firmware, platform state, or configuration conditions. The scenarios in this section reference these events to identify common failure patterns and determine the appropriate remediation. This section is intended to support diagnosis and interpretation of issues described earlier, not to introduce new failure scenarios.
For a complete list of event IDs, descriptions, and example entries, see Secure Boot DB and DBX variable update events (KB5016061).
KEK update failure (DB updates succeed, KEK doesn’t)
A device can successfully update certificates in the Secure Boot DB but fail during the KEK update. When this occurs, the Secure Boot update process cannot be completed.
Symptoms
-
DB certificate events indicate progress, but the KEK stage isn’t completed.
-
AvailableUpdates remains set to 0x4004 and the 0x0004 bit isn’t cleared after multiple task runs.
-
Event 1795 or 1803 might be present.
Interpretation
-
1795 typically indicates firmware failure while attempting to update a Secure Boot variable.
-
1803 indicates that the KEK update cannot be authorized because a required OEM PK-signed KEK payload isn’t available for the platform.
Next steps
-
For 1795, check for OEM firmware updates and validate firmware support for Secure Boot variable updates.
-
For 1803, confirm whether the OEM has provided Microsoft with the PK-signed KEK required for the device model.
KEK update failure on Guest VMs hosted on Hyper-V
On Hyper‑V virtual machines, Secure Boot certificate updates require the March 2026 Windows updates to be installed on both the Hyper‑V host and the guest OS.
Update failures are reported from within the guest, but the event indicates where remediation is required:
-
Event 1795 (for example, “The media is write‑protected”) reported in the guest indicates the Hyper‑V host is missing the March 2026 update and must be updated.
-
Event 1803 reported in the guest indicates the guest virtual machine itself is missing the March 2026 update and must be updated.
Reference and internals
This section contains advanced reference information intended for troubleshooting and support. It isn’t intended for deployment planning. It expands on the Secure Boot servicing mechanics summarized earlier and provides detailed reference material for interpreting registry state and event logs.
Note (IT-managed deployments): When configured via Group Policy or Microsoft Intune, two similar settings shouldn’t be confused. The AvailableUpdatesPolicy value represents the configured policy state. Meanwhile, AvailableUpdates reflects the in-progress, bit-clearing work state. Both can drive the same outcome, but they behave differently because policy re-applies over time.
AvailableUpdates bits used for certificate servicing
The bits below are used for the certificate and boot manager actions described in this document. The Order column reflects the sequence in which the Secure‑Boot‑Update task processes each bit.
|
Order |
Bit setting |
Usage |
|---|---|---|
|
1 |
0x0040 |
This bit tells the scheduled task to add the Windows UEFI CA 2023 certificate to the Secure Boot DB. This allows Windows to trust boot managers signed by this certificate. |
|
2 |
0x0800 |
This bit tells the scheduled task to apply the Microsoft Option ROM UEFI CA 2023 to the DB. Conditional behavior: When the 0x4000 flag is set, the scheduled task will first check the database for the Microsoft Corporation UEFI CA 2011 certificate. It will apply the Microsoft Option ROM UEFI CA 2023 certificate only if the 2011 certificate is present. |
|
3 |
0x1000 |
This bit tells the scheduled task to apply the Microsoft UEFI CA 2023 to the DB. Conditional behavior: When the 0x4000 flag is set, the scheduled task will first check the database for the Microsoft Corporation UEFI CA 2011 certificate. It will apply the Microsoft UEFI CA 2023 certificate only if the 2011 certificate is present. |
|
Modifier (behavior flag) |
0x4000 |
This bit modifies the behavior of the 0x0800 and 0x1000 bits so that the Microsoft UEFI CA 2023 and Microsoft Option ROM UEFI CA 2023 are applied only if the DB already contains the Microsoft Corporation UEFI CA 2011. To help ensure that the device’s security profile remains the same, this bit only applies these new certificates if the device trusts the Microsoft Corporation UEFI CA 2011 certificate. Not all Windows devices trust this certificate. |
|
4 |
0x0004 |
This bit tells the scheduled task to look for a Key Exchange Key signed by the device’s Platform Key (PK). The PK is managed by the OEM. OEMs sign the Microsoft KEK with their PK and deliver it to Microsoft where it’s included in monthly cumulative updates. |
|
5 |
0x0100 |
This bit tells the scheduled task to apply the boot manager, signed by the Windows UEFI CA 2023, to the boot partition. This will replace the Microsoft Windows Production PCA 2011 signed boot manager. |
Notes:
-
The 0x4000 bit will remain set after all other bits are processed.
-
Each bit is processed by the Secure‑Boot‑Update scheduled task in the order shown above.
-
If the 0x0004 bit cannot be processed due to a missing PK signed KEK, the scheduled task will still apply the boot manager update indicated by bit 0x0100.
Expected progression (AvailableUpdates)
When an operation completes successfully, Windows clears the associated bit from AvailableUpdates. If an operation fails, Windows logs an event and retries when the task runs again.
The table below shows the expected progression of AvailableUpdates values as each Secure Boot update action completes.
|
Step |
Bit processed |
Available Updates |
Description |
Success Event Logged |
Possible Error Event Codes |
|---|---|---|---|---|---|
|
Start |
0x5944 |
Initial state before Secure Boot certificate servicing begins. |
- |
- |
|
|
1 |
0x0040 |
0x5944 → 0x5904 |
Windows UEFI CA 2023 is added to the Secure Boot DB. |
1036 |
1032, 1795, 1796, 1802 |
|
2 |
0x0800 |
0x5904 → 0x5104 |
Add Microsoft Option ROM UEFI CA 2023 to the DB if the device previously trusted the Microsoft UEFI CA 2011. |
1044 |
1032, 1795, 1796, 1802 |
|
3 |
0x1000 |
0x5104 → 0x4104 |
Microsoft UEFI CA 2023 is added to the DB if the device previously trusted the Microsoft UEFI CA 2011. |
1045 |
1032, 1795, 1796, 1802 |
|
4 |
0x0004 |
0x4104 → 0x4100 |
New Microsoft KEK 2K CA 2023 signed by the OEM platform key is applied. |
1043 |
1032, 1795, 1796, 1802, 1803 |
|
5 |
0x0100 |
0x4100 → 0x4000 |
Boot manager signed by Windows UEFI CA 2023 is installed. |
1799 |
1797 |
Notes
-
Once the operation associated with a bit completes successfully, that bit is cleared from AvailableUpdates.
-
If one of these operations fails, an event is logged, and the operation is retried the next time the scheduled task runs.
-
The 0x4000 bit is a modifier and isn’t cleared. A final AvailableUpdates value of 0x4000 indicates successful completion of all applicable update actions.
-
Events 1032, 1795, 1796, 1802 typically indicate firmware or platform limitations.
-
Event 1803 indicates missing OEM PK-signed KEK.
Remediation procedures
This section provides step‑by‑step procedures to remediate specific Secure Boot issues. Each procedure is scoped to a well‑defined condition and is intended to be followed only after initial diagnosis confirms that the issue applies. Use these procedures to restore expected Secure Boot behavior and allow certificate updates to proceed safely. Do not apply these procedures broadly or preemptively.
Enabling Secure Boot in firmware
If Secure Boot is disabled in a device’s firmware, see Windows 11 and Secure Boot for details on enabling Secure Boot.
Secure Boot scheduled task disabled or deleted
The Secure-Boot-Update scheduled task is required for Windows to apply Secure Boot certificate updates. If the task is disabled or missing, Secure Boot certificate servicing won’t progress.
Task details
|
Task Name |
Secure-Boot-Update |
|
Task path |
\Microsoft\Windows\PI\ |
|
Full path |
\Microsoft\Windows\PI\Secure-Boot-Update |
|
Runs as |
SYSTEM (Local System) |
|
Triggers |
At startup and every 12 hours |
|
Required state |
Enabled |
How to check task status
Run from an elevated PowerShell prompt: schtasks.exe /Query /TN "\Microsoft\Windows\PI\Secure-Boot-Update" /FO LIST /V
Look for the Status field:
|
Status |
Meaning |
|---|---|
|
Ready |
Task exists and is enabled. |
|
Disabled |
Task exists but must be enabled. |
|
Error / Not Found |
Task is missing and must be recreated. |
How to enable or recreate the task
If the status field for Secure-Boot-Update is Disabled, Error, or Not Found, use the sample script to enable the task: Sample Enable-SecureBootUpdateTask.ps1
Note: This is a sample script and isn’t supported by Microsoft. Administrators should review and adapt it to their environment.
Example:
.\Enable-SecureBootUpdateTask.ps1 -Quiet
Run guidance
-
If you see Access denied, rerun PowerShell as Administrator.
-
If the script will not run due to execution policy, use a process‑scope bypass:
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
Need more help?
Want more options?
Explore subscription benefits, browse training courses, learn how to secure your device, and more.
Communities help you ask and answer questions, give feedback, and hear from experts with rich knowledge.
