Every Windows device in your fleet with Secure Boot enabled is running on borrowed time. The Microsoft Corporation UEFI CA 2011 and Microsoft Windows Production PCA 2011 certificates—the cryptographic root of trust that lets your machines boot securely—expire starting June 24, 2026. Miss the deadline and your devices won’t brick, but they’ll be frozen in a security dead zone: unable to receive boot-level security updates, unable to revoke vulnerable bootloaders, and wide open to exploits like BlackLotus. The deadline is June 24, 2026. Here’s exactly how to fix every machine before it arrives.
What’s Actually Expiring (And Why You Should Care)
Secure Boot works through a chain of trust. Your UEFI firmware holds a database of trusted certificates (the DB), and every bootloader, driver, and OS component must be signed by one of those certificates to execute. The three original certificates Microsoft issued in 2011—the KEK CA, UEFI CA, and Windows Production PCA—were given a 15-year lifespan. That lifespan expires on June 24, 2026.
| Certificate | Expiration Date |
|---|---|
| Microsoft Corporation KEK CA 2011 | June 24, 2026 |
| Microsoft Corporation UEFI CA 2011 | June 24, 2026 |
| Microsoft Windows Production PCA 2011 | October 19, 2026 |
Once these certificates expire, Windows can’t sign new boot components with them. Your devices won’t stop booting—existing signed components still work—but you lose the ability to update the Secure Boot Forbidden Signature Database (DBX). That’s the revocation list that blocks compromised bootloaders. Without DBX updates, every known boot-level vulnerability stays exploitable forever on that device.
Reality Check: Your machines won’t go dark on June 25. They’ll keep booting normally—they just won’t be patchable at the firmware level anymore. That’s worse than a visible failure because nobody will notice until it’s too late.
Prerequisites
Before you touch anything, confirm these are in place. Skipping any of them will create problems mid-deployment.
-
Windows 10 (version 1507 or later) or Windows 11 on all target devices
-
March 2026 cumulative update or later installed (this delivers the 2023 certificate definitions)
-
Administrative access to target devices (local admin or Intune enrollment)
-
UEFI firmware updated to the latest version from your OEM (more on this in a moment)
-
BitLocker recovery keys accessible—you will need them
Phase 1: Inventory Your Fleet
You can’t fix what you can’t measure. Your first move is finding out which devices already have the Windows UEFI CA 2023 certificate and which ones are stuck on the 2011 chain.
The key registry location is HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing. The UEFICA2023Status value tells you where each device stands.
Run this on any device to check its status:
$servicing = "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing"
$status = Get-ItemProperty -Path $servicing -Name "UEFICA2023Status" -ErrorAction SilentlyContinue
if ($status.UEFICA2023Status -eq "Updated") {
Write-Output "COMPLIANT: 2023 CA is enrolled"
} elseif ($status.UEFICA2023Status -eq "InProgress") {
Write-Output "IN PROGRESS: Enrollment running—reboot to complete"
} elseif ($status.UEFICA2023Status -eq "NotStarted") {
Write-Output "NOT STARTED: Enrollment has not begun"
} else {
Write-Output "ACTION REQUIRED: Device needs firmware update or certificate enrollment"
}
For a more thorough check that confirms the certificate is actually present in the UEFI DB:
$db = Get-SecureBootUEFI -Name db
$has2023CA = [System.Text.Encoding]::ASCII.GetString($db.Bytes) -match "Windows UEFI CA 2023"
if ($has2023CA) {
Write-Output "VERIFIED: 2023 CA found in UEFI Secure Boot database"
} else {
Write-Output "MISSING: 2023 CA not in UEFI database"
}
| Status Value | Meaning | Action |
|---|---|---|
Updated |
2023 CA enrolled in firmware | None—device is compliant |
InProgress |
Enrollment running | Reboot to complete the process |
NotStarted |
Enrollment hasn’t begun | Trigger enrollment (Phase 3) |
| Missing/absent | Firmware may need OEM update first | Update BIOS, then proceed |
Pro Tip: If you’re running Microsoft Intune, deploy the detection script above as a Proactive Remediation detection-only script. You’ll get fleet-wide visibility without touching a single device.
Phase 2: Update OEM Firmware First
Here’s where most guides skip a step. If your device firmware doesn’t already include the 2023 CA in its certificate store, setting the registry key won’t help. The Windows update process writes the new certificate into the UEFI DB, but the firmware itself needs to support it.
Most hardware manufactured after 2021 already ships with 2023 CA support. Anything older—particularly devices from 2015 to 2020—almost certainly needs a BIOS update from the OEM before the Windows-side certificate enrollment will succeed.
Each vendor has its own update tool:
| Vendor | Tool | Command |
|---|---|---|
| Dell | Dell Command Update | dcu-cli.exe /applyupdates -reboot=enable |
| HP | HP Client Management Script Library | Get-HPBIOSUpdates -Flash -Bitlocker Suspend |
| Lenovo | Thin Installer | ThinInstaller.exe /CM -search A -action INSTALL |
Warning: BIOS updates and Secure Boot certificate changes frequently trigger BitLocker recovery prompts. Suspend BitLocker for one to two reboots before deploying firmware updates. If you skip this, your helpdesk will hate you by lunchtime.
Phase 3: Deploy the 2023 Certificate
With firmware current, you can trigger the certificate enrollment. Microsoft gives you four deployment methods—pick one and stick with it per device. Mixing methods on the same device causes problems.
Option A: Microsoft Intune (Recommended)
If you manage devices through Intune, three new settings exist under the Secure Boot category in the Settings Catalog:
-
Enable SecureBoot Certificate Updates — Triggers the enrollment
-
Configure Microsoft Update Managed Opt In — Allows Microsoft to manage the rollout timing
-
Configure High Confidence Opt-Out — Prevents automatic enrollment on devices Microsoft deems ready
Create a configuration profile, assign it to a pilot group first, then expand after validation.
Option B: Registry Key (PowerShell)
For direct control, set the AvailableUpdates registry value to 0x5944 (decimal 22852). This tells Windows to deploy all needed certificates and switch to the 2023-signed boot manager:
$sbPath = "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot" Set-ItemProperty -Path $sbPath -Name "AvailableUpdates" -Value 0x5944 -Type DWord # Trigger the scheduled task immediately instead of waiting up to 12 hours Start-ScheduledTask -TaskPath "\Microsoft\Windows\PI\" -TaskName "Secure-Boot-Update"
The update requires at least two full reboots to complete. The first reboot stages the certificate, and the second writes it into the UEFI variables.
Option C: Group Policy
Group Policy is the right choice for environments using GPO-based configuration management. Under the hood it sets the same AvailableUpdates registry key as Option B—this is the UI path if your team prefers to manage it through GPMC rather than direct registry scripts. Navigate to Computer Configuration > Administrative Templates > Windows Components > Secure Boot and enable “Enable Secure Boot certificate deployment.” If you’d rather script it, use the PowerShell approach in Option B instead.
Option D: Windows Configuration System (WinCS)
For domain-joined Windows 11 devices (23H2, 24H2, or 25H2), you can use WinCS with the feature name Feature_AllKeysAndBootMgrByWinCS and configuration key F33E0C8E002.
Phase 4: Validate and Monitor
After deployment, you need to confirm the update actually stuck. Don’t assume—verify.
Check the registry status again:
$servicing = "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing"
$status = (Get-ItemProperty -Path $servicing -Name "UEFICA2023Status").UEFICA2023Status
$error = Get-ItemProperty -Path $servicing -Name "UEFICA2023Error" -ErrorAction SilentlyContinue
Write-Output "Certificate Status: $status"
if ($error) {
Write-Output "ERROR DETECTED: Check event logs"
Get-WinEvent -LogName "Microsoft-Windows-SecureBoot-Updates/Operational" -MaxEvents 10 |
Format-Table TimeCreated, Id, Message -AutoSize
}
Success and failure events log under Applications and Services Logs > Microsoft > Windows > SecureBoot-Updates in Event Viewer. Event ID 1808 means success. Event ID 1801 or the presence of the UEFICA2023Error registry key means something went wrong—likely a firmware compatibility issue that needs an OEM update.
For fleet-wide monitoring, Windows Autopatch includes a Secure Boot status report that shows compliance across your entire environment.
What You Can’t Undo
One thing to know before you pull the trigger: this is a one-way operation. Once the 2023 CA is enrolled and the DBX revocation list is updated, you cannot roll back to a state where only the 2011 CA is trusted. That means older bootable media—think Windows 10 recovery USBs created before the update, old deployment images, that one WinPE stick in your server room drawer—won’t boot on updated devices.
Update your deployment images and recovery media before or immediately after rolling out the certificate update. Future you will thank present you.
The Remediation Timeline
You have a narrow window. Here’s a practical schedule:
| Week | Action |
|---|---|
| Now | Inventory fleet, identify non-compliant devices |
| Week 1-2 | Deploy OEM firmware updates to pilot group |
| Week 2-3 | Trigger certificate enrollment on pilot group, validate |
| Week 3-4 | Expand to production, monitor for errors |
| Week 5-6 | Remediate stragglers, update recovery media |
| Before June 24 | Final compliance sweep |
Key Insight: The biggest risk isn’t the certificate expiry itself—it’s the devices you forget about. Kiosks, conference room machines, that laptop in the CEO’s home office that hasn’t connected to VPN since January. Start your inventory now and chase down every edge case.
Wrapping Up
The Secure Boot certificate expiry is a rare event where Microsoft gives you a clear deadline, detailed documentation, and multiple deployment paths. The technical work is straightforward—inventory, update firmware, enroll certificates, validate. The hard part is doing it across every device in your environment before June 24, 2026. Start with your inventory, pilot on a small group, and expand methodically. Every device you miss is a device that can’t receive boot-level security patches ever again.
