Fix Secure Boot Certificate Update Failures Before the June 2026 UEFI Deadline

A lot of Windows estates are about to run into a problem that does not look urgent until you check the firmware and event logs. Some devices still rely on Secure Boot certificates issued in 2011. Microsoft says those older certificates expire in June 2026, and devices that stay on the old trust chain might keep booting and keep taking normal cumulative updates, but they can miss future Secure Boot protections for early boot components.

That is the dangerous part. This does not always start with a blue screen or a mass outage. In many environments, the first clues are quieter: UEFICA2023Status never reaches Updated, Windows Autopatch marks devices as needing certificate updates, or the System log starts showing TPM-WMI Event ID 1795 or Event ID 1801. If you wait until a firmware edge case turns into a BitLocker recovery loop or an unbootable pilot ring, you waited too long.

This is the practical admin workflow that matters: identify devices still tied to the old certificate path, update firmware first, validate registry and event evidence, pilot the 2023 Secure Boot update on real hardware, and only then widen deployment through Intune, Group Policy, CSP, or controlled registry-based rollout.

Quick triage: what to check first

If you need a fast answer on whether you have work to do, start with these checks:

1. In Windows Autopatch, open Reports > Windows Autopatch > Windows quality updates > Reports > Secure Boot status.
2. Look for devices where Secure Boot is enabled but certificate status is not current.
3. On affected devices, check HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing for UEFICA2023Status.
4. In the System log, filter on source TPM-WMI and review Event IDs 1032, 1033, 1795, 1796, 1797, 1798, 1801, and 1802.
5. Confirm whether UEFICA2023Status is still NotStarted or InProgress, or whether UEFICA2023Error is non-zero.
6. Check OEM firmware currency before you touch broad deployment.

If you already see Event ID 1801, Microsoft is telling you the certificates were updated in Windows but have not yet been applied to device firmware. That is not a cosmetic warning. It means your rollout is incomplete.

Why this issue is showing up now

Microsoft published two admin signals that line up on the same problem.

First, the Windows troubleshooting guidance says some devices still use Secure Boot certificates issued in 2011 and need to move to the 2023 certificates before June 2026. Microsoft also says that if you do nothing, devices may still boot and continue to receive normal Windows updates, but they might not receive future Secure Boot protections for boot manager and other early boot components.

Second, Microsoft added dedicated deployment and monitoring controls for managed estates:

• a Secure Boot status report in Windows Autopatch
• registry-based deployment and monitoring guidance in KB5068202
• a public event reference for Secure Boot DB, DBX, and KEK update failures

That combination matters because this is not just a documentation refresh. It is Microsoft giving enterprise admins a detection and rollout path before older trust anchors become a support problem.

The exact operational risk depends on the hardware and firmware in your fleet. Microsoft notes that higher-risk environments can see:

• Secure Boot validation errors
• BitLocker recovery prompts or loops
• startup hangs
• boot failures on devices where firmware or boot components do not handle the update cleanly

That is why this should be handled like a staged boot-chain remediation, not like a routine registry tweak.

The logs and registry evidence that actually matter

Do not start by checking random BIOS screenshots. Start with the Windows evidence Microsoft documents.

1. UEFICA2023Status

Microsoft says the primary deployment state lives here:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing

The UEFICA2023Status value is the cleanest first check:

• NotStarted: the update has not yet run
• InProgress: the update is actively running
• Updated: the new keys and boot manager were deployed successfully

If UEFICA2023Status is anything except Updated on a device that should already be remediated, that device belongs in your backlog.

UEFICA2023Error is the next key to read. Microsoft says it stays 0 on success and becomes non-zero when the process hits the first error. If that happens, Microsoft recommends correlating it with Secure Boot events in the Windows event log.

2. AvailableUpdates and the enterprise deployment bitmask

For registry-driven enterprise deployment, Microsoft documents this path:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot

The AvailableUpdates value is the trigger bitmask. Microsoft’s KB says the enterprise deployment value is:

0x5944

That value enables the relevant certificate and boot manager updates for the 2023 Secure Boot path. Microsoft also notes that AvailableUpdatesPolicy is used by Intune or Group Policy to communicate policy to Windows and should be treated as reference state, not a value you manually edit.

3. TPM-WMI events in the System log

The System log is where field troubleshooting becomes concrete.

High-value events include:

• Event ID 1795: firmware returned an error while Windows tried to update a Secure Boot variable such as DB, DBX, or KEK
• Event ID 1801: certificates were updated in Windows but are not yet applied to firmware
• Event ID 1032: BitLocker configuration would cause recovery if the Secure Boot update is applied
• Event ID 1033: a potentially revoked boot manager was detected in the EFI partition
• Event ID 1797: DBX revocation step failed because Windows UEFI CA 2023 is not present in Db
• Event ID 1796: generic Secure Boot update failure with an error code

Two event patterns deserve immediate escalation.

If you see Event ID 1795, Microsoft says the firmware itself returned an error during the update. That usually points to an OEM firmware dependency, not an Intune assignment problem.

If you see Event ID 1032, Microsoft says to suspend BitLocker for two restart cycles before retrying the Secure Boot update. The documented command is:

Manage-bde -Protectors -Disable $env:SystemDrive -RebootCount 2

After two restarts, re-enable protection if needed:

Manage-bde -Protectors -Enable $env:SystemDrive

A practical remediation workflow for Intune and Windows admins

This is the sequence I would use for a real enterprise rollout.

Step 1: Build your affected device list

If you have Windows Autopatch, use the Secure Boot status report first. Microsoft built that report to answer three questions fast:

• which devices have Secure Boot enabled
• which of those devices are already up to date
• which Secure Boot-enabled devices still need certificate updates

If you do not use Autopatch, collect the data directly from devices. A quick PowerShell check looks like this:

$servicingPath = 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing'
$rootPath = 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot'

[PSCustomObject]@{
    ComputerName        = $env:COMPUTERNAME
    UEFICA2023Status    = (Get-ItemProperty -Path $servicingPath -Name UEFICA2023Status -ErrorAction SilentlyContinue).UEFICA2023Status
    UEFICA2023Error     = (Get-ItemProperty -Path $servicingPath -Name UEFICA2023Error -ErrorAction SilentlyContinue).UEFICA2023Error
    AvailableUpdates    = (Get-ItemProperty -Path $rootPath -Name AvailableUpdates -ErrorAction SilentlyContinue).AvailableUpdates
}

If UEFICA2023Status is missing or not Updated, keep digging. Then pull the matching TPM-WMI events:

Get-WinEvent -FilterHashtable @{
    LogName = 'System'
    ProviderName = 'TPM-WMI'
    Id = 1032,1033,1795,1796,1797,1798,1801,1802
} -MaxEvents 100 |
Select-Object TimeCreated, Id, LevelDisplayName, Message

Step 2: Update firmware before blaming Windows

Microsoft’s support article is blunt here: deploy OEM firmware updates, especially for older models, before broad certificate rollout. If you skip this step, you waste time chasing policy behavior when the real problem is firmware that cannot accept the Secure Boot variable update cleanly.

For pilot selection, include:

• multiple OEMs
• multiple firmware revisions
• BitLocker-enabled laptops
• devices in your lowest-latency update ring
• at least one older model family that is common in the fleet

If the same hardware family repeatedly throws Event ID 1795, stop rollout for that model and check vendor guidance before continuing.

Step 3: Fix BitLocker blockers before retrying

If you hit Event ID 1032, suspend BitLocker for two restart cycles exactly as Microsoft documents. Do not leave BitLocker suspended indefinitely, and do not use this as a blanket setting across the fleet. Use it only where the log proves it is needed.

This is one place where pilot discipline matters. If you suspend BitLocker broadly without confirming the reason, you can create unnecessary audit noise and lose track of which machines actually needed intervention.

Step 4: Use one deployment method per device

Microsoft supports several deployment methods: Intune, Group Policy, Windows Configuration system/CSP, and registry keys.

Pick one control plane per device group and stay consistent. Mixing direct registry writes, Intune policy, and GPO on the same pilot set is a good way to make state harder to explain.

If you are using a script-driven pilot, the documented enterprise trigger is to set AvailableUpdates to 0x5944. If you are using Intune or Group Policy, validate the resulting policy state through AvailableUpdatesPolicy and the servicing keys rather than assuming assignment equals success.

Step 5: Verify completion, not just policy delivery

A completed rollout should show all of the following on the device:

• UEFICA2023Status = Updated
• UEFICA2023Error = 0
• no recurring TPM-WMI error events related to Secure Boot variable updates
• no unexpected BitLocker recovery prompts after the test restarts

That last point matters. A device can receive the configuration and still fail at the firmware handoff stage. Microsoft’s Event ID 1801 exists specifically because Windows-side delivery is not enough.

Limitations and gotchas you should plan for

A few traps are easy to miss.

Devices can look healthy until they are not

Microsoft says affected devices may continue to boot and continue receiving standard updates even when the Secure Boot certificate remediation is incomplete. That makes this a poor candidate for reactive help-desk detection. You need reporting and pilot validation, not ticket volume, to tell you where the risk is.

WindowsUEFICA2023Capable is not your primary health signal

Microsoft explicitly says not to use WindowsUEFICA2023Capable as the main status check for update health. Use UEFICA2023Status instead. The capable value is useful in narrow deployment scenarios, but it is not the best enterprise success criterion.

DBX failures can be intentional safety blocks

Microsoft’s event documentation shows some failures are deliberate protections. For example, Event ID 1797 can occur when Windows refuses to push the DBX revocation because the Windows UEFI CA 2023 certificate is not yet present in Db. That is Windows preventing a worse outcome.

Noisy data across mixed hardware is normal

If you run Dell, HP, Lenovo, Surface, and older specialty hardware in the same tenant, expect different event patterns across the fleet. Do not build a single one-size-fits-all remediation script without a pilot. Firmware behavior is the variable that makes this rollout different from a normal Windows setting change.

Conclusion

The Secure Boot certificate deadline is not just a security note for your backlog. It is a boot-chain readiness project with real endpoint risk if you ignore the evidence Microsoft already exposed.

The fastest way to stay out of trouble is simple: use the Windows Autopatch Secure Boot status report if you have it, check UEFICA2023Status, investigate TPM-WMI Event ID 1795 and Event ID 1801 immediately, patch firmware before broad rollout, and treat BitLocker-related blocks as a logged exception instead of a blanket policy change.

If your fleet is already standardized on Intune, this is a good week to create a pilot group, validate the 0x5944 deployment path on representative hardware, and document which models need vendor firmware before you widen scope. June 2026 is close enough now that silent laggards should be treated as production risk, not future cleanup.