Skip to main content

Secure Boot Certificate Expiration 2026: What IT Pros Need to Do

Three Microsoft Secure Boot certificates that have been baked into device firmware since around 2012 are expiring this year. Devices that don't get updated before the deadlines will keep booting normally, but they lose the ability to receive any future boot-level security content: DBX revocations, Boot Manager updates, and protections against firmware exploits like BlackLotus. The UEFI CA 2011 certificate also covers Option ROMs for add-in cards including NVIDIA and AMD GPUs, so systems with discrete GPUs that miss the update may fail to validate GOP firmware at boot after June 2026.

This is a guide for IT pros managing Windows fleets of any size. I cover how to check where your devices stand, how to push the update using registry keys, GPO, or Intune, what to watch out for during rollout, and how to handle the common failure modes.

What's Expiring​

CertificateExpiresReplaced By
Microsoft Corporation KEK CA 2011June 24, 2026Microsoft Corporation KEK 2K CA 2023
Microsoft UEFI CA 2011June 27, 2026Microsoft UEFI CA 2023 + Microsoft Option ROM UEFI CA 2023
Microsoft Windows Production PCA 2011October 19, 2026Windows UEFI CA 2023

Source: KB5062710

Device Scope​

Not all devices get these updates automatically. Know what you have before you start.

Device TypeAuto-Updated?Notes
Windows 11 (all supported versions)ConditionallyRolling out via monthly CUs from Jan 2026. Telemetry must be enabled; CFR targeting is not guaranteed.
Windows 10 22H2ConditionallyRegistry key method confirmed. Same telemetry dependency.
Windows 10 LTSC 2021 / 2019VerifyMonitor LTSC release notes. Manual targeting likely needed.
Windows 10 EOL (no ESU)NoNo cert update without ESU.
Windows Server 2016 through 2025NoManual push required on all versions. See the Windows Server section.
Windows Server 2012 / 2012 R2 (ESU)NoOnly if ESU enrolled.
Hyper-V Gen 2 VMsVia guest OSMarch 2026 patch required on both host AND guest. Gen 1 VMs are exempt.
Azure VMs / Windows 365 / AVDMicrosoft managedNo action required.
Legacy BIOS / CSM modeN/ANo UEFI, no Secure Boot. Not affected.
Windows Server admins

Windows Server never receives these updates through Controlled Feature Rollout. Every server requires explicit manual action before June 2026. Skip to the Windows Server section.

Step 1: Check Device Status​

Before you push anything, check where your devices actually stand. The fastest way is a PowerShell one-liner you can run locally or through your RMM:

$sb = Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot" -ErrorAction SilentlyContinue
$svc = Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing" -ErrorAction SilentlyContinue

[PSCustomObject]@{
    AvailableUpdates   = if ($sb.AvailableUpdates) { "0x{0:X4}" -f $sb.AvailableUpdates } else { "Not set" }
    UEFICA2023Status   = if ($svc.UEFICA2023Status) { $svc.UEFICA2023Status } else { "Not started" }
    HasFirmwareError   = [bool]$svc.UEFICA2023Error
}

Interpreting the output:

UEFICA2023StatusAvailableUpdatesWhat it means
Updated0x4000Compliant. Done.
InProgress0x5904 or decreasingUpdate running. Wait 48 hours and reboot.
InProgress0x4100Certs written. Reboot required to finish Boot Manager update.
Not started / absent0x0000Not targeted yet. Push the registry key.
Any0x4104Stuck. OEM KEK missing. See Troubleshooting.

You can also check the System event log under source TPM-WMI: Event 1808 means fully compliant, Event 1801 means update in progress.

note

HasFirmwareError = True alongside AvailableUpdates = 0x4100 is a false positive. The cert writes succeeded; the device just needs a reboot to finish the Boot Manager update. This clears after the next restart.

Step 2: OEM Firmware First​

Before you push any registry key or policy, check OEM firmware status. Pushing certificates to devices with outdated firmware causes preventable failures.

HP and Fujitsu: These platforms have a documented firmware dependency for Secure Boot DB updates. Pushing AvailableUpdates = 0x5944 to HP or Fujitsu devices without a current OEM BIOS produces persistent Event 1795 errors. Update OEM BIOS before any registry push on these manufacturers.

Dell: Windows updates the Active DB (what the device boots from), but Dell's Default DB may retain only 2011 certs until a BIOS firmware update is applied. If a technician resets BIOS defaults, the device can silently revert to non-compliant. Install current Dell BIOS firmware (late 2024 or newer) to persist the 2023 certs to the Default DB. Dell documents this in their Secure Boot Transition FAQ.

Dell Default DB regression

Even after a successful update, a BIOS reset on older Dell firmware can silently revert the device. Get Dell BIOS current before or alongside the cert push.

General rule: Check for a BIOS update before pushing certs, especially if you see Event 1795, 1796, or 1802 on any device. Event 1802 specifically indicates a known firmware/hardware compatibility block.

Step 3: Deploy​

Pick one method and stick with it. Microsoft explicitly says not to mix deployment methods on the same device.

Registry Key (Most Reliable)​

Set AvailableUpdates to 0x5944 under HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot. A scheduled task (Secure-Boot-Update) picks this up and runs every 12 hours, processing the update in stages.

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot" `
    -Name "AvailableUpdates" -Value 0x5944 -Type DWord

This is the most reliable method across all editions and works regardless of telemetry status or CSP licensing. Use this as your fallback if other methods aren't working.

AvailableUpdatesPolicy for persistence

For GPO or Intune-managed devices, write to AvailableUpdatesPolicy instead. This key persists across reboots and is intended for management systems. Do not set both.

Group Policy​

  1. Download the latest ADMX templates for Windows 11 / Windows Server from Microsoft
  2. Import the templates to your Central Store
  3. Navigate to: Computer Configuration > Administrative Templates > Windows Components > Windows Update > Manage updates offered from Windows Server Update Service
  4. Enable "Enable Secure Boot certificate deployment"

GPO sets AvailableUpdatesPolicy under the hood. Monitor actual rollout status via registry or event log, not the GPO report, since the policy only controls initiation.

Microsoft Intune​

Avoid the Settings Catalog CSP

The Settings Catalog "Enable Secureboot Certificate Updates" policy fails silently with Error 65000 on Windows Pro editions and on devices upgraded from Pro to Enterprise via subscription activation (even if they show as Enterprise in Intune). Microsoft deployed a licensing fix in January 2026, but many tenants still see this error. The CSP also gives you zero visibility into actual cert rollout status since it only reports whether the profile applied, not whether certs updated.

Use a Platform Script or Remediations package instead.

Recommended: Platform Script

  1. In Intune admin center, go to Devices > Scripts and remediations > Platform scripts
  2. Upload a PowerShell script that sets AvailableUpdates = 0x5944
  3. Set Run as: SYSTEM
  4. Enable 64-bit PowerShell host
  5. Assign to your device groups

Better for ongoing monitoring: Remediations

A detection + remediation script pair lets you run daily checks, report non-compliant devices, and auto-remediate without re-pushing to already-compliant devices. Microsoft's own monitoring guidance uses this approach: Monitoring Secure Boot certificate status with Intune remediations.

Deploy in rings: pilot group first, validate BitLocker behavior and firmware compatibility, then broaden.

Windows Server​

No automatic updates for any Windows Server version

Windows Server does not participate in Controlled Feature Rollout. Every server across every version requires explicit manual action before June 2026. Windows Server 2025 certified platforms may already have 2023 certs in firmware, so verify before pushing.

All four deployment methods work on Windows Server:

  • Registry key: same AvailableUpdates = 0x5944 approach, works on all supported versions
  • Group Policy: same ADMX-based policy, available for all domain-joined servers
  • WinCS tools: command-line utilities (traditional exe + PowerShell module) available for Server 2022 and later. See KB5062713 for the WinCS reference.
  • Intune/MECM: Platform Script or Remediations, same caveats as client

Check firmware status first. Servers are more likely to have outdated BIOS than managed workstations, and the same HP/Fujitsu and Dell caveats apply.

Microsoft recommends treating servers as a separate change management track: verify firmware, pilot a subset, confirm no BitLocker or boot issues, then roll broadly. The Windows Server Secure Boot Playbook has the full step-by-step.

Step 4: Monitor and Verify​

After pushing, expect about 48 hours and one or more reboots for the full update to complete. The scheduled task runs every 12 hours, so it won't finish in minutes.

Bitmask progression:

AvailableUpdatesStageAction
0x5944Triggered, task queuedWait
0x5904 or lower (decreasing)Update in progressWait + reboot
0x4100Certs written, Boot Manager pendingReboot
0x4000CompliantDone
0x4104Stuck, KEK blockedSee Troubleshooting

Success signals:

  • UEFICA2023Status = Updated
  • AvailableUpdates = 0x4000
  • Event ID 1808 in System log (source: TPM-WMI)
Hotpatch environments

Devices on a hotpatch update cadence reboot far less frequently than standard-patched devices. A device can sit at 0x4100 (one reboot away from compliant) for weeks with no one noticing. If you run hotpatch, set up a separate reboot enforcement policy alongside the cert push, or you will miss the June deadline on a meaningful portion of your fleet.

Don't rely on automatic delivery

Real-world deployments have seen fully patched, compliant devices go 36+ days without receiving certs via Windows Update even with daily scans running. The automatic CFR path exists, but in managed environments you should treat it as a bonus, not the plan. Push explicitly.

Virtual Machines​

Azure VMs, Windows 365, Azure Virtual Desktop: Microsoft managed. No action required.

Hyper-V Gen 2 VMs: Apply the March 2026 Windows update to both the Hyper-V host AND each guest VM. Patching only one side does not resolve the KEK write failure (Event 1795: "media write protected"). Gen 1 VMs are not affected.

VMware: VMs created before ESXi 8.0.2 (VM hardware version 21+) may have a NULL Platform Key in NVRAM. Windows cannot authorize the KEK update on these VMs, and the standard registry push has no effect. Check Broadcom's guidance for NVRAM remediation options:

BitLocker + VM firmware changes

Any NVRAM or UEFI variable change alters PCR 7 measurements and triggers BitLocker recovery mode. Suspend BitLocker and verify recovery key escrow before making any VMware NVRAM or UEFI changes.

WinPE and Boot Media​

Rebuild your boot media before June 2026

Boot media created before the cert rotation is signed with PCA 2011. Once DBX revocations are applied to an updated device, old WinPE USBs, PXE images, and imaging ISOs will fail to boot on that device. Rebuild all boot media using ADK 10.1.26100.2454 (December 2024) or later before June 2026. This includes imaging sticks, PXE servers, and any offline recovery tools.

Troubleshooting​

Stuck at 0x4104 (KEK blocked)​

The device completed DB writes but the KEK step (0x0004 bit) won't clear. This means the OEM has not provided a PK-signed KEK for this platform. Re-pushing the registry key does nothing. Contact the OEM. This is not fixable by any software-side action until the OEM delivers a BIOS update with the correct KEK.

Event 1795 or 1802: Firmware blocking the write​

Event 1795 is a firmware-rejected Secure Boot variable write. Event 1802 is a known firmware/hardware compatibility block. Both mean the same thing in practice: the BIOS needs updating before the cert push will work. Install the latest OEM firmware, then re-run the remediation.

On HP and Fujitsu, this is expected behavior if you pushed before updating firmware. On other platforms, check the OEM's support site for a BIOS update targeting Secure Boot compatibility.

Event 1803: Missing PK-signed KEK​

Either the OEM has not delivered a PK-signed KEK to Microsoft (physical device), or the VM's NVRAM has a NULL or invalid Platform Key (VMware). On physical hardware, contact the OEM. On VMware, see the Virtual Machines section.

Intune Error 65000​

The Settings Catalog CSP hit a licensing gate. This happens on Windows Pro devices and on devices upgraded from Pro to Enterprise via subscription activation. Switch to a Platform Script or Remediations package instead. The CSP approach is not worth debugging.

Telemetry-blocked devices never receive automatic targeting​

Environments with telemetry blocked via GPO, firewall, or WSUS settings will not receive automatic high-confidence cert targeting from Microsoft. Detect blocked devices by checking:

Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\DataCollection" -Name AllowTelemetry -ErrorAction SilentlyContinue

If AllowTelemetry = 0, treat that device as requiring 100% manual registry push. This is common in healthcare, legal, and government environments.

Key Takeaways​

  • Certificates start expiring June 24, 2026. Start now: 48-hour completion windows and firmware updates add up fast across a fleet.
  • Windows Server gets nothing automatically. Every server needs a manual push before June.
  • Update OEM firmware before pushing certs, especially on HP, Fujitsu, and Dell hardware.
  • In Intune, use Platform Scripts or Remediations instead of the Settings Catalog CSP. The CSP silently fails on Pro and Pro-upgraded devices.
  • Rebuild any WinPE or PXE boot media using ADK December 2024 or later before June 2026.

Additional Resources​

Microsoft:

OEM:

VMware / Broadcom:

Community:

Get this done before June. The cert chain for boot-level security updates is not something you want to discover is broken when the next BlackLotus variant drops.