You enabled the Secure Boot certificate update in Intune, waited a couple of days, and the Secure Boot status report still says Not up to date for a chunk of devices. The update is a chain of firmware writes driven by a scheduled task, and every step leaves a trace in the registry and the System log. In this post I'll show you how to read those traces, map them to the Intune report, and decide whether the fix is a restart, a setting, a firmware update or a call to the OEM.
Status (October 2026): Microsoft's Secure Boot troubleshooting guide (KB5085046, March 2026) and the event reference (KB5016061, last revised June 2026) are the official sources for the states described here. Two of the three 2011 certificates passed their expiry dates in June 2026 and the Windows Production PCA 2011 expires on 19 October 2026; devices still boot and update, but miss new boot-level protections. Microsoft updates these pages as new failure scenarios are identified, so re-check them.
Symptoms#
- The Secure Boot status report (Reports › Windows Autopatch › Windows quality updates › Reports) shows Not up to date, Unknown or Not applicable long after the policy applied.
- The detection-only remediation from Microsoft's KB5080921 flags the device With issue, and its JSON output shows
UEFICA2023StatusasNotStarted,InProgressorNoValue. - The System log keeps logging Event ID 1801, or shows 1795, 1796, 1802 or 1803 errors from source
TPM-WMI. - The Settings catalog profile itself reports an error; Microsoft lists a known issue about error code 65000 on Pro editions on its Intune method page.
Why it happens#
Windows applies the update through the scheduled task \Microsoft\Windows\PI\Secure-Boot-Update, which runs as SYSTEM at startup and every 12 hours. The task reads the AvailableUpdates bitmask under HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot and works through the set bits in a fixed order: add the Windows UEFI CA 2023 to the DB (0x0040), add the Option ROM CA 2023 (0x0800) and the Microsoft UEFI CA 2023 (0x1000) if the device trusted the 2011 UEFI CA, apply the OEM's PK-signed KEK 2K CA 2023 (0x0004), and finally install the boot manager signed by the Windows UEFI CA 2023 (0x0100). A step must succeed before the next one runs; if it fails, the task logs an event, leaves the bit set and retries next time. The firmware does the actual writing and the OEM must have supplied a PK-signed KEK, so a stalled device usually comes down to eligibility, a disabled task, a firmware error, a missing KEK, a BitLocker conflict, a pending restart, or plain latency.
How to fix it#
1. Confirm the device is eligible#
Confirm-SecureBootUEFI must return True, the device must run a supported Windows version with the latest security update, and Secure Boot must be enabled in firmware. If it returns False or errors because the device boots in legacy BIOS mode, no certificate work is possible until Secure Boot is enabled; Microsoft's "Windows 11 and Secure Boot" page covers that, and converting the disk from MBR to GPT first is general guidance, not something these KBs walk through.
2. Check the scheduled task#
schtasks.exe /Query /TN "\Microsoft\Windows\PI\Secure-Boot-Update" /FO LIST /VReady is good. Disabled, an error or "not found" means nothing will ever be applied; Microsoft's troubleshooting guide links a sample Enable-SecureBootUpdateTask.ps1 to restore it.
3. Read the registry#
| Value | Key | Meaning (as documented) |
|---|---|---|
AvailableUpdates | …\Control\SecureBoot | Bitmask of pending work. 0 or missing: not triggered. 0x5944: everything pending. 0x4000: all applicable steps complete (that bit is a modifier and never clears). |
AvailableUpdatesPolicy | …\Control\SecureBoot | The state set by Intune or Group Policy, for reference only; don't edit it. |
HighConfidenceOptOut | …\Control\SecureBoot | 1 means opted out of the automatic monthly-update deployment for high-confidence devices. |
MicrosoftUpdateManagedOptIn | …\Control\SecureBoot | Non-zero means opted in to Microsoft's Controlled Feature Rollout. |
UEFICA2023Status | …\SecureBoot\Servicing | NotStarted, InProgress or Updated. If the Servicing key doesn't exist, the update hasn't been initiated. |
UEFICA2023Error | …\SecureBoot\Servicing | 0 on success; a non-zero code is the first error hit, and your cue to go to the event log. |
UEFICA2023ErrorEvent | …\SecureBoot\Servicing | Listed by the troubleshooting guide alongside the error code; examine it together with the events. |
Microsoft's expected progression of AvailableUpdates is 0x5944 → 0x5904 (Event 1036) → 0x5104 (1044) → 0x4104 (1045) → 0x4100 (1043) → 0x4000 (1799). Whatever value you see tells you which step is stuck. The DeviceAttributes subkey under Servicing holds the OEM name, model, firmware version and a CanAttemptUpdateAfter timestamp.
4. Read the events#
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='TPM-WMI'} -MaxEvents 40 |
Where-Object Id -in 1032,1795,1796,1799,1800,1801,1802,1803,1808 |
Format-Table TimeCreated, Id, LevelDisplayName -AutoSize| Event ID | What Microsoft says it means | Your next move |
|---|---|---|
| 1808 (Information) | All needed certificates applied and the 2023-signed boot manager installed. The device is fully updated. | Nothing; wait for the report to catch up. |
| 1801 (Error) | Certificates updated in Windows but not yet applied to firmware; includes device attributes, bucket ID and confidence level. | Normal mid-process. A problem only if it persists after restarts. |
| 1800 (Warning) | A restart is required before the named update can be installed. | Restart. |
| 1795 (Error) | The firmware returned an error writing DB, DBX or KEK; Windows retries at the next restart. | Check the OEM for a firmware update. |
| 1796 (Error) | An unexpected error with an error code; retried at next restart. | Note the code; if it repeats, treat it like 1795. |
| 1802 (Error) | Update intentionally blocked because the device matches a known firmware or hardware issue (SkipReason gives the known issue ID). | OEM firmware update; the bucket shows as Temporarily Paused. |
| 1803 (Error) | No PK-signed KEK for this device was found in the cumulative update, so the KEK step can't proceed. | Ask the OEM about KEK provisioning for the model. The boot manager step still runs. |
| 1032 (Error) | The BitLocker configuration would send the device into recovery if the update were applied. | Suspend BitLocker for two restarts (step 6). |
| 1036, 1044, 1045, 1043, 1799 | Success events for each stage: DB, Option ROM CA, UEFI CA, KEK and boot manager. | Progress markers. |
5. Interpret the Intune report#
The report has no explicit "error" state. Not up to date means action is required; select the value to see which certificates are missing, but read it together with the Secure Boot trust configuration column, because a device configured for Microsoft-only trust does not need the third-party CAs and can be Up to date without them. Unknown or Not applicable usually means missing diagnostic data (check for a DeviceDiagnosticDataNotReceived alert), a device inactive for more than 28 days, the Data Processor Service for Windows not enabled, or a status change that hasn't propagated yet, since the report can lag a restart by up to 12 hours. In the remediation's Overview tab, Devices with failed detection is the only true error bucket, and it means the script itself failed, not the certificate update.
6. Clear the common blockers#
| Blocker | Source | Fix |
|---|---|---|
| Secure Boot disabled or legacy BIOS | Microsoft | Enable Secure Boot in firmware; nothing else applies until then. |
| Firmware needs an OEM update (1795, 1802, 1803) | Microsoft | Install the latest UEFI firmware from the manufacturer, then let the task retry. |
| Not on the required servicing update | Microsoft | Install the latest cumulative update; the PK-signed KEKs ship inside it. |
| Diagnostic data below Required | Microsoft | Needed for the CFR opt-in, for high-confidence classification and for the report; the Enable setting itself still works without it. |
HighConfidenceOptOut set to 1 | Microsoft | Expected if you opted out; you must trigger the update yourself with the Enable setting. |
| Policy conflict | Microsoft | Don't mix Intune, Group Policy, registry and WinCS on one device; AvailableUpdatesPolicy reflects policy while AvailableUpdates is the live work state. |
| Reboot pending (Event 1800, boot manager step) | Microsoft | Restart; the boot manager swap waits for a natural restart. |
| BitLocker conflict (Event 1032) | Microsoft | manage-bde -protectors -disable %systemdrive% -RebootCount 2, restart twice, then confirm protection resumed. |
| Just too early | Microsoft | 12-hour task cadence plus report latency; Microsoft estimates 48 hours and one or more restarts. |
7. Re-run and re-check#
After a fix you don't have to wait 12 hours. Start the task, restart when prompted and re-read the registry:
Start-ScheduledTask -TaskPath '\Microsoft\Windows\PI\' -TaskName 'Secure-Boot-Update'
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing' -Name UEFICA2023Status, UEFICA2023Error -ErrorAction SilentlyContinue8. When to involve the OEM#
Persistent 1795, 1802 or 1803 events, a confidence level of Temporarily Paused or Not Supported, and firmware that overwrites the DB after an update are all firmware-side problems that Windows cannot work around. Microsoft's guidance for devices the manufacturer no longer supports is blunt: if the firmware cannot process the update, consider replacing the device.
Verify the fix#
A healthy device shows Event 1808 as its latest Secure Boot event, UEFICA2023Status of Updated with no non-zero error, AvailableUpdates at 0x4000, Without issue in the remediation and Up to date in the report within 12 hours of the restart. If you want to look at the firmware directly, this returns True when the Windows UEFI CA 2023 is present in the DB:
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'Key takeaways#
- Registry first, events second, report last: the report is a lagging indicator of what the device already knows.
- 1801 is progress, not failure, until it repeats across restarts; 1795, 1802 and 1803 are firmware conversations you need the OEM for.
- Keep the Secure-Boot-Update task enabled and leave
DisableOneSettingsDownloadsoff, or neither the update nor the report will move.