Secure Boot certificate update stuck: decode AvailableUpdates and events 1795–1808

When to Use This Guide

Use this guide when a Windows device has started the Secure Boot certificate update but doesn't seem to finish it. You might see one of these:

• AvailableUpdates sits at the same value for days, often 0x4004 (16388) or 0x4100 (16640)
• UEFICA2023Status stays at InProgress
• UEFICA2023ErrorEvent shows 1800, 1795, 1801 or 1803
• Event 1801 keeps appearing in the System log and 1808 never does
• Your Intune remediation report or inventory script shows the same device as "not updated" week after week
• A device went into BitLocker recovery, or stopped booting, after a Secure Boot change

The question to answer is not "has the update installed?" It's "which of the five servicing steps is this device on, and what is stopping the next one?" Windows records both, in the registry and in the System log. You just have to read them together.

This is the troubleshooting companion to Secure Boot CA 2023 Rollout Readiness for Enterprise Windows Fleets. That guide covers planning, inventory, rings and Intune deployment. This one starts from a single stuck device.

Scope and Assumptions

This guide covers supported Windows 10, Windows 11 and Windows Server devices that boot with UEFI Secure Boot, including Hyper-V Generation 2 virtual machines. It assumes:

• The device has the current monthly cumulative update installed.
• You can run elevated PowerShell on the device, or through a remote session or Intune remediation.
• The BitLocker recovery key for the system drive is escrowed and you can retrieve it before you restart anything.

It covers the certificate servicing sequence that Microsoft documents in the Secure Boot troubleshooting guide: the three DB certificates, the KEK and the 2023-signed boot manager. It doesn't cover DBX revocation planning, Linux shim chains, or OEM-specific firmware menus.

Limitation: expected outputs below are shapes, not captures from a specific machine. Firmware behaviour varies by manufacturer, model and firmware version. A fix that works on one model is not evidence for another.

Prerequisites

Before you diagnose a stall, rule out the three conditions that stop servicing from ever starting. Microsoft lists these as the first checks:

1. Supported Windows with current updates. Check the build against the latest cumulative update for that release.
2. Secure Boot is on. Confirm-SecureBootUEFI should return True. If it returns False, there's nothing to update until Secure Boot is enabled in firmware.
3. The Secure-Boot-Update scheduled task exists and is enabled. It lives at \Microsoft\Windows\PI\Secure-Boot-Update, runs as SYSTEM, and runs at startup and every 12 hours.

Confirm-SecureBootUEFI
schtasks.exe /Query /TN "\Microsoft\Windows\PI\Secure-Boot-Update" /FO LIST /V

Expected output shape:

True

TaskName:        \Microsoft\Windows\PI\Secure-Boot-Update
Status:          Ready
Last Run Time:   <date and time after the last restart>
Last Result:     0
Run As User:     SYSTEM

If the task shows Disabled, or the query returns an error because the task doesn't exist, start with Step 4. Nothing else in this guide will move until the task runs.

Symptoms

Pick the first check from what you're seeing.

Likely Causes

In the order I check them:

1. The device is waiting for a restart. The boot manager step and some variable writes need a reboot, and users who only shut down may never give the device one. Event 1800 says so directly.
2. The scheduled task isn't running. It was disabled by a hardening or clean-up script, or it's missing.
3. The firmware has no OEM-signed KEK. The KEK step needs a Key Exchange Key that the manufacturer signed with its Platform Key and gave to Microsoft. If that doesn't exist for the model, the KEK step can't finish (event 1803).
4. The firmware rejected the write. Event 1795 includes the firmware's own error code. That's a firmware update question for the OEM.
5. Microsoft has paused or blocked this hardware bucket. Event 1802 or a 1801 confidence level of "Temporarily Paused" means the update is being held on purpose.
6. A BitLocker configuration would trigger recovery. Event 1032 means Windows stopped before writing the firmware because BitLocker would have gone into recovery.
7. Hyper-V host or guest is missing the March 2026 update. Both sides need it.
8. Someone reset Secure Boot keys to factory defaults after the device had moved to the 2023 boot manager, or the firmware overwrote DB instead of appending to it.

How servicing moves through the steps

The Secure-Boot-Update task reads a bitmask called AvailableUpdates. Each set bit is a pending action. The task works through them in a fixed order. When a step succeeds, Windows clears its bit and writes a success event. When a step fails, Windows logs an error, leaves the bit set and stops. It tries again at the next task run, which is the next startup or the next 12-hour cycle.

That gives you a reliable root-cause method. The lowest-order bit still set is the step the device is stuck on. The newest error event tells you why.

What I do on the desk

These are the notes I work from when a "Secure Boot not updated" ticket comes in.

First three checks, in this order:

1. Is the recovery key escrowed? I confirm this before I restart anything. If it isn't, I fix that first with BitLocker Recovery Key Not Backed Up to Entra ID.
2. Run the read-only script in Step 1 and write down AvailableUpdates in hex, the three UEFICA2023* values and the last boot time.
3. Read the newest TPM-WMI event, not the oldest. A device that is now done still has older 1801 errors in its log.

What decides the call: the lowest pending bit in AvailableUpdates plus the newest error event for that step. Those two values tell you whether the device needs a restart, a firmware update, an OEM answer, or nothing.

The mistake that wastes a week: treating every 1801 as a failure. Event 1801 means "certificates updated but not yet applied to firmware". On its own it often means "not finished yet" or "waiting for a restart". It needs action only when the confidence level or a 1802/1803 says the device can't progress.

Step 1: Capture the state before you touch anything

Run this as administrator. It only reads the registry, the scheduled task and the System log. It changes nothing.

# Read-only Secure Boot servicing snapshot. Changes nothing on the device.
$sb  = Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot' -ErrorAction SilentlyContinue
$svc = Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing' -ErrorAction SilentlyContinue
$au  = [int]$sb.AvailableUpdates

# Processing order documented in KB5085046
$steps = @(
    [pscustomobject]@{ Order = 1; Bit = 0x0040; Action = 'Add Windows UEFI CA 2023 to DB';      SuccessEvent = 1036 }
    [pscustomobject]@{ Order = 2; Bit = 0x0800; Action = 'Add Option ROM UEFI CA 2023 to DB';   SuccessEvent = 1044 }
    [pscustomobject]@{ Order = 3; Bit = 0x1000; Action = 'Add Microsoft UEFI CA 2023 to DB';    SuccessEvent = 1045 }
    [pscustomobject]@{ Order = 4; Bit = 0x0004; Action = 'Apply OEM PK-signed KEK 2K CA 2023';  SuccessEvent = 1043 }
    [pscustomobject]@{ Order = 5; Bit = 0x0100; Action = 'Install 2023-signed boot manager';    SuccessEvent = 1799 }
)
$pending = @($steps | Where-Object { $au -band $_.Bit })
$other   = $au -band (-bnot 0x5944)

$secureBoot = try { Confirm-SecureBootUEFI } catch { "Unknown: $($_.Exception.Message)" }
$lastBoot   = (Get-CimInstance -ClassName Win32_OperatingSystem).LastBootUpTime

[pscustomobject]@{
    SecureBootEnabled    = $secureBoot
    LastBoot             = $lastBoot
    AvailableUpdates     = '0x{0:X4} ({0})' -f $au
    FirstPendingStep     = if ($pending.Count) { $pending[0].Action } else { 'None' }
    OtherBitsSet         = if ($other) { '0x{0:X4}' -f $other } else { 'None' }
    UEFICA2023Status     = $svc.UEFICA2023Status
    UEFICA2023Error      = if ($null -ne $svc.UEFICA2023Error) { '0x{0:X8}' -f $svc.UEFICA2023Error } else { $null }
    UEFICA2023ErrorEvent = $svc.UEFICA2023ErrorEvent
    ConfidenceLevel      = $svc.ConfidenceLevel
} | Format-List

$task = Get-ScheduledTask -TaskPath '\Microsoft\Windows\PI\' -TaskName 'Secure-Boot-Update' -ErrorAction SilentlyContinue
if ($task) {
    $info = $task | Get-ScheduledTaskInfo
    [pscustomobject]@{
        TaskState      = $task.State
        RunAs          = $task.Principal.UserId
        LastRunTime    = $info.LastRunTime
        LastTaskResult = '0x{0:X8}' -f $info.LastTaskResult
        NextRunTime    = $info.NextRunTime
    } | Format-List
} else {
    Write-Warning 'Secure-Boot-Update scheduled task not found'
}

$ids = 1032,1036,1043,1044,1045,1795,1796,1797,1798,1799,1800,1801,1802,1803,1808
Get-WinEvent -FilterHashtable @{ LogName = 'System'; Id = $ids; StartTime = (Get-Date).AddDays(-30) } -ErrorAction SilentlyContinue |
    Where-Object ProviderName -match 'TPM-WMI' |
    Select-Object -First 20 TimeCreated, Id, LevelDisplayName,
        @{ n = 'FirstLine'; e = { ($_.Message -split "`r?`n")[0] } } |
    Format-Table -AutoSize -Wrap

Expected output shape for a device stuck at the KEK:

SecureBootEnabled    : True
LastBoot             : <date and time>
AvailableUpdates     : 0x4004 (16388)
FirstPendingStep     : Apply OEM PK-signed KEK 2K CA 2023
OtherBitsSet         : None
UEFICA2023Status     : InProgress
UEFICA2023Error      : 0x<non-zero code>
UEFICA2023ErrorEvent : 1803
ConfidenceLevel      : <bucket confidence text>

TaskState      : Ready
RunAs          : SYSTEM
LastRunTime    : <after LastBoot>
LastTaskResult : 0x00000000
NextRunTime    : <about 12 hours after LastRunTime>

TimeCreated   Id LevelDisplayName FirstLine
-----------   -- ---------------- ---------
<newest>    1803 Error            A PK-signed Key Exchange Key (KEK) cannot be found for this device...
<older>     1799 Information      Boot Manager signed with Windows UEFI CA 2023 was installed successfully
<older>     1045 Information      <Microsoft UEFI CA 2023 applied to DB>

The event filter matches the provider by name pattern instead of an exact provider string. That way it works whichever form of the TPM-WMI provider name your build reports. If OtherBitsSet isn't None, the device also has other Secure Boot servicing actions queued, such as DBX work. Don't guess what they mean. Read the matching events in KB5016061.

For a fleet, run the same reads as an Intune remediation detection script and output one line per device. Microsoft publishes a monitoring pattern in Monitoring Secure Boot certificate status with Intune remediations.

Step 2: Decode AvailableUpdates

Get-ItemProperty and many inventory tools show AvailableUpdates in decimal. Regedit shows both, for example 0x00004000 (16384). Microsoft documents the full sequence as 0x5944 (22852). That's the value the registry method sets to start servicing. Bits clear one at a time as each step succeeds.

How to read the edge cases:

• 0x4000 (16384) is finished, not stuck. 0x4000 is a modifier bit and Windows never clears it. It tells the task to add the two third-party CAs only if the DB already trusts Microsoft UEFI CA 2011. A final value of 0x4000 means every step that applies to this device is done.
• 0x4004 (16388) is the classic KEK stall. If the KEK step can't run because there's no OEM PK-signed KEK, Windows still installs the boot manager. Bit 0x0100 clears and 0x0004 stays. So the device boots on the 2023 boot manager but hasn't taken the new KEK.
• Third-party CAs that never appear can be correct. With 0x4000 set, a device that never trusted Microsoft UEFI CA 2011 doesn't get Microsoft UEFI CA 2023 or the Option ROM CA. That keeps its security profile the same. It's by design, not a failure.
• 0 with no servicing values means nothing started. That's the "no progress" case. Go back to the prerequisites.
• Status beats the bitmask. Microsoft's registry reference says to use UEFICA2023Status as the status signal. If UEFICA2023Status is Updated and the newest event is 1808, treat the device as done.

Step 3: Read UEFICA2023Status, UEFICA2023Error and UEFICA2023ErrorEvent

These three values live under HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing. Windows writes them. Read them; don't edit them.

UEFICA2023Error holds the first error code Windows hit. UEFICA2023ErrorEvent holds the event ID Windows used to report it. That makes UEFICA2023ErrorEvent the fastest way into the event log. Filter the System log on that ID and read the newest instance.

Two values to ignore for status:

• WindowsUEFICA2023Capable. Microsoft labels it reference only. 0 means the Windows UEFI CA 2023 isn't in DB, 1 means it's in DB, and 2 means it's in DB and the device is booting from the 2023-signed boot manager. It's useful context, but Microsoft says to use UEFICA2023Status for status.
• AvailableUpdatesPolicy. This is the policy value written by Intune or Group Policy. AvailableUpdates is the working value whose bits clear. Policy re-applies over time, so the two can differ on a healthy device. Don't hand-edit either one to "unstick" a device.

Step 4: Confirm the Secure-Boot-Update task is alive

If the task is disabled or missing, nothing in this guide will move.

Get-ScheduledTask -TaskPath '\Microsoft\Windows\PI\' -TaskName 'Secure-Boot-Update' |
    Select-Object TaskName, State, @{ n = 'RunAs'; e = { $_.Principal.UserId } }

Expected output shape:

TaskName           State RunAs
--------           ----- -----
Secure-Boot-Update Ready SYSTEM

• Disabled: find out what disabled it before you re-enable it. Hardening baselines, "debloat" scripts and scheduled-task clean-up policies are the usual suspects. If you re-enable it and the policy turns it off again, you've fixed nothing. Once the cause is removed, run Enable-ScheduledTask -TaskPath '\Microsoft\Windows\PI\' -TaskName 'Secure-Boot-Update'.
• Missing: Microsoft's troubleshooting guide links a sample script, Enable-SecureBootUpdateTask.ps1, that recreates it. Microsoft labels it a sample, not a supported tool, so review it before you run it.
• Ready, but last run is before the last restart: check the task's history and the Task Scheduler operational log. A task that should run at startup but doesn't is its own problem, separate from Secure Boot.

Step 5: Match the event to the fix

All of these are in the System log from the TPM-WMI source.

Event 1808 also carries a BucketConfidenceLevel. Microsoft notes that on a 1808 it reflects data coverage for similar devices. It doesn't mean the device needs more work.

Step 6: Stuck at the KEK (0x4004, events 1803 or 1795)

The KEK is the only step that needs something from the hardware manufacturer. Windows can only write a new KEK if it's signed by the device's Platform Key, and the OEM owns that key. OEMs sign the Microsoft KEK with their PK and give it to Microsoft, which ships it in the monthly cumulative update.

Event 1803 means the update has no PK-signed KEK for this platform. Microsoft is explicit that Windows can't work around the missing authorisation. There's no supported manual recovery path either. This is common on older and out-of-support models.

Event 1795 at the KEK stage means a KEK exists, but the firmware returned an error when Windows tried to write it.

What to do:

1. Confirm the device is on the latest cumulative update. Newer updates can carry KEKs for more models.
2. Update the UEFI firmware to the OEM's latest release.
3. Group the stuck devices by manufacturer, model and firmware version, then ask the OEM whether a PK-signed KEK exists for that model. Microsoft's OEM pages for Secure Boot list manufacturer guidance.
4. If there is no KEK and won't be, record the device as a hardware lifecycle exception. It keeps booting and it got the 2023 boot manager, but it can't take future DB and DBX updates signed under the new KEK. That's a replacement-planning decision, not a ticket to keep re-opening.

When not to keep retrying: if 1803 appears on every task run for a model, more restarts won't change anything. Close the per-device tickets and track it as one model-level issue.

Step 7: Event 1800 and the restart that never happens

If UEFICA2023ErrorEvent reads 1800, or the newest event is a 1800 warning, the device isn't broken. Windows has decided that applying the next update in the current boot could conflict with a recent change, so it's waiting for a restart. Microsoft gives two examples: a boot manager update in the same boot cycle, or Secure Boot variable updates on devices that use virtualisation-based security. The event text names the pending update type, for example KEK 2023 or Windows UEFI CA 2023 (DB).

What to do:

1. Compare the 1800 timestamp with LastBoot from Step 1. If there has been no restart since the 1800, that's the whole problem.
2. Use Restart, not Shut down. With Fast Startup on, a shut-down-and-power-on isn't a full restart, so a user who powers off every evening may never give the device the reboot it's waiting for.
3. After the restart, let the startup run of the task finish, or start it manually (Safe Retry Steps), then run Step 1 again.
4. A device that shows a fresh 1800 after each restart, and whose bits do move, is working through steps that each need their own boot. That's normal. A device that logs 1800 for the same update type after several genuine restarts while its bits stay the same needs a closer look at what keeps changing in each boot. Collect the event detail before you escalate.

For a fleet, the fastest win is often a scheduled restart in the maintenance window for devices whose newest event is 1800.

Step 8: Event 1801 and the confidence buckets

Event 1801 includes DeviceAttributes, a BucketId and a BucketConfidenceLevel. The bucket groups equivalent hardware. A device can move to a different bucket when its attributes change, for example after a firmware update. UpdateType is either 0 or 22852 (0x5944). 0x5944 marks a High Confidence update.

The decision that matters is whether to trigger the update yourself. For High Confidence and piloted Under Observation models, the documented IT-managed method is fine: set AvailableUpdates to 0x5944 through the registry method, Group Policy or Intune. For Temporarily Paused and Not Supported, triggering it yourself goes around the protection Microsoft put there.

Step 9: BitLocker recovery after the update

Two patterns look the same on the help desk but have different causes. Microsoft's troubleshooting guide describes both.

One-time recovery. The device asks for the recovery key on the first boot after the update, then boots normally. On that first boot the firmware hasn't yet reported the updated Secure Boot values when BitLocker tries to reseal. Enter the key once. No further action is needed.

Recovery on every boot. The firmware boot order tries PXE (network) first. The PXE attempt fails and the firmware falls back to the disk. In one boot the TPM measures a PXE path signed by Microsoft UEFI CA 2011, then a boot manager signed by Windows UEFI CA 2023. BitLocker can't get stable measurements to reseal against, so it asks every time. Fix the boot order:

1. Put the Windows Boot Manager on the internal disk first in the firmware boot order.
2. Disable PXE boot if you don't use it.
3. If you need PXE, make sure your PXE infrastructure serves a 2023-signed Windows boot loader.

Event 1032 before anything is written. If Windows logs 1032, it stopped before the firmware write because BitLocker would have gone into recovery. Microsoft's fix is to suspend protectors for two restarts. Microsoft's page shows the command with en dashes, which break if pasted. Type plain hyphens:

manage-bde -protectors -disable %systemdrive% -RebootCount 2

Or in PowerShell:

Suspend-BitLocker -MountPoint $env:SystemDrive -RebootCount 2

Then restart twice. Protection resumes on its own after the second restart. Confirm it with manage-bde -status, which should show Protection On again after the second restart.

Step 10: Device won't boot after a Secure Boot reset or firmware DB overwrite

These are the severe cases. Neither is a Windows bug. Both remove the trust the 2023 boot manager depends on.

Secure Boot reset to factory defaults. On a device already running the Windows UEFI CA 2023-signed boot manager, resetting the Secure Boot keys to firmware defaults removes the 2023 certificate from DB. The firmware no longer trusts the installed boot manager and blocks boot, often with a Secure Boot violation. Microsoft's recovery:

1. On another Windows PC with the July 2024 or newer Windows update, copy C:\Windows\Boot\EFI\SecureBootRecovery.efi.
2. Put it on a FAT32 USB drive as \EFI\BOOT\bootx64.efi.
3. Boot the affected device from that USB drive. The utility adds Windows UEFI CA 2023 back to DB.
4. After Windows starts, check servicing with Step 1. The utility restores only that one certificate, so let servicing reapply the rest. Then install the OEM's latest firmware.

Firmware overwrote the DB instead of appending. Some firmware replaces DB when Windows adds a certificate. The Microsoft 2011 certificate disappears while the device still boots a 2011-signed boot manager, so the next restart fails. Microsoft's guidance is to try a Secure Boot reset in firmware setup. If the device then boots, install the OEM firmware that fixes DB handling before you re-enable servicing. If the reset doesn't restore boot, you need OEM-specific recovery.

Do not use "disable Secure Boot" as the fix in either case. It may get the device booting, but it leaves the device unprotected and hides the real fault.

Step 11: Hyper-V guests

Hyper-V virtual machines need the March 2026 Windows updates on both the Hyper-V host and the guest. The guest reports the failure, and the event tells you which side to fix:

• 1795 in the guest, for example "The media is write-protected": the host is missing the March 2026 update. Patch the host.
• 1803 in the guest: the guest is missing the March 2026 update. Patch the guest.

Patch the host before you spend time on the guests. One unpatched host makes every Generation 2 VM on it look like a firmware problem. For VM templates and Generation 2 settings, see the Hyper-V section of the rollout readiness guide.

What not to do

• Do not clear bits in AvailableUpdates by hand to make a report go green. You'd be hiding a stall, not fixing it, and the firmware state wouldn't change.
• Do not set 0x5944 on a model that logs 1802, 1803 or a Temporarily Paused bucket. Those are deliberate stops.
• Do not hand-edit AvailableUpdatesPolicy. It belongs to Intune or Group Policy.
• Do not reset Secure Boot keys to factory defaults on an updated device unless the OEM confirms its defaults include the 2023 certificates.
• Do not use WindowsUEFICA2023Capable as the status signal. Use UEFICA2023Status and event 1808.
• Do not restart devices to retry before the recovery key is escrowed.

Safe Retry Steps

Use these once you've matched the stall to a cause you can fix: a missing restart, a re-enabled task, or new firmware.

1. Confirm the BitLocker recovery key is escrowed and retrievable.
2. Restart the device with Restart, not shut down.
3. Let the startup run of the task finish, or start it manually:

Start-ScheduledTask -TaskPath '\Microsoft\Windows\PI\' -TaskName 'Secure-Boot-Update'

4. Wait a few minutes, then run the Step 1 script again.
5. Validation: AvailableUpdates should be lower than before, a new success event (1036, 1044, 1045, 1043 or 1799) should appear, or the device should reach 0x4000 with 1808. If the same bit and the same error event come back, stop retrying and go to the matching step above.
6. If the boot manager bit (0x0100) just cleared, or a 1800 appeared, restart once more and re-check.

Safe Rollback Steps

Microsoft doesn't document an undo for certificates written to DB or KEK, and you don't want one. Those are the trust anchors that replace the expiring 2011 certificates. What you can roll back is your own rollout:

1. Stop expansion. Remove the Intune or Group Policy assignment from the next ring if a model starts failing. This stops new devices from being queued. It doesn't undo what the firmware already holds, and it may not clear bits already queued on a device.
2. Recover boot, not certificates. For boot failures, use Step 10. It restores trust so Windows can start.
3. Recover BitLocker. Enter the recovery key, then fix the boot order (Step 9) so the prompt doesn't come back.
4. Record the model. Add the manufacturer, model, firmware version, event ID and BucketId to your exceptions list, so the next ring excludes it until the OEM ships a fix.

Prevention Checklist

• The Secure-Boot-Update task is excluded from scheduled-task clean-up and hardening scripts
• BitLocker recovery keys are escrowed for every device before it enters a Secure Boot ring
• Devices in the ring get a real restart in the maintenance window, not only shutdowns
• PXE isn't first in the firmware boot order on devices that don't need it
• PXE infrastructure serves a 2023-signed Windows boot loader where PXE is required
• Hyper-V hosts are patched to the March 2026 updates or later before their guests
• OEM firmware is current on each model before you trigger servicing on it
• Help desk instructions say not to reset Secure Boot keys to defaults
• Your inventory reports AvailableUpdates in hex as well as decimal, plus UEFICA2023Status, UEFICA2023ErrorEvent and the newest TPM-WMI event ID
• Models that log 1802 or 1803 are tracked as one model-level exception, not as individual tickets

Related Resources

• Secure Boot CA 2023 Rollout Readiness for Enterprise Windows Fleets
• BitLocker Recovery Key Not Backed Up to Entra ID
• Endpoint Security hub
• Windows Server hub

Primary sources used for this guide:

• Secure Boot troubleshooting guide (KB5085046)
• Secure Boot DB and DBX variable update events (KB5016061)
• Registry key updates for Secure Boot on Windows devices with IT-managed updates
• Windows Secure Boot certificate expiration and CA updates
• Microsoft Intune method of Secure Boot for IT-managed updates
• Monitoring Secure Boot certificate status with Intune remediations

Correction record

18 October 2026. First published. Values, event meanings, processing order and recovery steps are from Microsoft's KB5085046, KB5016061 and the Secure Boot registry key reference as published in October 2026. Nothing in this guide was captured from a lab device.