Tutorials 11 min read

Windows Secure Boot Certificate Expiration June 2026: The Complete IT Preparation Guide

Windows Secure Boot certificates expire in June 2026. This guide covers how to audit your fleet, deploy the replacement 2023 certificates via Intune, Group Policy, or PowerShell, and verify the update — with ready-to-use scripts.

Editorial Team

The clock is ticking — and honestly, this one snuck up on a lot of us. Starting in June 2026, the cryptographic certificates that have underpinned Secure Boot on virtually every Windows device since 2012 will begin to expire. If your organization doesn't update to the replacement 2023 certificates before the deadline, affected machines will lose the ability to receive future boot-level security protections. That means they're exposed to bootkit malware like BlackLotus and can't install new pre-boot mitigations.

Not great.

This guide gives IT helpdesk and sysadmin teams everything you need: the exact certificates involved, how to audit your fleet, step-by-step deployment methods for Intune, Group Policy, and manual registry changes, plus real PowerShell commands you can run today. I've tried to make this as copy-paste-friendly as possible so you can get moving quickly.

What Is Happening and Why It Matters

Secure Boot is a UEFI firmware feature that verifies the digital signature of every component loaded during the boot process — from the bootloader to the kernel. It stops unauthorized or tampered code from running before the operating system starts, which makes it your first line of defense against firmware-level attacks.

Since 2012, every Secure Boot-enabled Windows PC has relied on the same set of certificates issued by Microsoft in 2011. After more than 15 years of continuous service (which is a remarkably long run for crypto certs), these certificates are reaching the end of their planned lifecycle:

  • Microsoft Corporation KEK CA 2011 — expires June 24, 2026
  • Microsoft Corporation UEFI CA 2011 — expires June 27, 2026
  • Microsoft Option ROM UEFI CA 2011 — expires June 27, 2026
  • Microsoft Windows Production PCA 2011 — expires October 19, 2026

Microsoft has issued replacement certificates under the 2023 Certificate Authority (Windows UEFI CA 2023, Microsoft Corporation KEK 2K CA 2023). All Windows devices must transition to these new certificates to maintain full Secure Boot protection.

What Happens If You Don't Update

Here's the thing that trips people up: devices that miss the update will not suddenly stop booting. Windows will continue to start, and standard monthly updates will still install. So it's easy to think everything's fine.

But the device enters a degraded security state:

  • No new security protections for the early boot process
  • No updates to Windows Boot Manager signatures
  • No updates to Secure Boot revocation lists (DBX)
  • No mitigations for newly discovered boot-level vulnerabilities
  • Potential compatibility issues with future operating systems and firmware

This is especially dangerous because of threats like the BlackLotus UEFI bootkit. Discovered in 2023, BlackLotus was the first bootkit to bypass Secure Boot on fully patched Windows 11 systems by exploiting CVE-2022-21894 and CVE-2023-24932. It could disable BitLocker, Hypervisor-Protected Code Integrity, and Windows Defender — all before the OS even loaded. Without updated certificates, your devices can't receive future protections against similar attacks.

Which Devices Are Affected

The scope is broad — broader than most people expect. Affected systems include physical and virtual machines running:

  • Windows 11 (all versions)
  • Windows 10 (all supported versions)
  • Windows Server 2025, 2022, 2019, 2016, 2012, and 2012 R2
  • Virtual machines on Hyper-V, VMware, and Azure
  • Windows 365 Cloud PCs and Azure Virtual Desktop

Devices manufactured since 2024 generally already carry the 2023 certificates. For everything else, you need to take action.

Step 1: Audit Your Fleet — Check Certificate Status

Before deploying anything, you need to know where you stand. Here are multiple methods to check whether a device already has the updated certificates.

Method A: PowerShell One-Liner (Run as Administrator)

Open an elevated PowerShell window and run:

# Check the active Secure Boot DB for the 2023 certificate
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023')

# Check the default DB as well
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbdefault).bytes) -match 'Windows UEFI CA 2023')

If the command returns True, the 2023 certificate is present and the device is ready. If it returns False, action is needed.

Method B: Registry Key Check

Windows tracks the deployment progress in the registry, which is handy for scripting. Query it with:

Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot" | Select-Object UEFICA2023Status

Possible values:

  • Not started — no certificate deployment has begun
  • In progress — deployment is underway but not complete
  • Updated — all new certificates and the new boot manager have been deployed

Method C: Windows Event Log

In Event Viewer, navigate to Windows Logs > System and filter for source TPM-WMI:

  • Event ID 1808 — Confirms that all required new Secure Boot certificates have been successfully applied to firmware
  • Event ID 1034 — Confirms the DBX (revocation list) update was processed

Method D: Fleet-Wide Audit with PowerShell Script

For larger environments (and let's be honest, that's most of us dealing with this), use a script to inventory multiple machines at once:

# Secure Boot Certificate Audit Script
# Run against remote machines via Invoke-Command or deploy via Intune

$results = @()

$certStatus = try {
    $dbBytes = (Get-SecureBootUEFI db).bytes
    $hasCA2023 = [System.Text.Encoding]::ASCII.GetString($dbBytes) -match 'Windows UEFI CA 2023'
    if ($hasCA2023) { "Present" } else { "Missing" }
} catch {
    "Error: $($_.Exception.Message)"
}

$registryStatus = try {
    (Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot" -ErrorAction Stop).UEFICA2023Status
} catch {
    "Registry key not found"
}

[PSCustomObject]@{
    ComputerName     = $env:COMPUTERNAME
    CA2023InDB       = $certStatus
    RegistryStatus   = $registryStatus
    OSVersion        = (Get-CimInstance Win32_OperatingSystem).Version
    BIOSVersion      = (Get-CimInstance Win32_BIOS).SMBIOSBIOSVersion
    Manufacturer     = (Get-CimInstance Win32_ComputerSystem).Manufacturer
    Model            = (Get-CimInstance Win32_ComputerSystem).Model
}

Deploy this via Intune Remediations (detection script only, no remediation) to collect status across your managed fleet without making any changes.

Step 2: Apply OEM Firmware Updates First

Before deploying the new certificates, make sure your devices have the latest BIOS/UEFI firmware from the manufacturer. I can't stress this enough — in the Secure Boot chain, firmware updates from OEMs are the foundation upon which Windows Secure Boot updates apply correctly. Skip this step and you might run into issues down the road.

Check with your hardware vendors (Dell, HP, Lenovo, ASUS, etc.) for firmware updates released specifically for the 2026 Secure Boot transition. Many OEMs have published guidance and updated firmware packages.

BitLocker Warning: This is the part that catches people off guard. Updating firmware can trigger a BitLocker recovery prompt, and nobody wants to deal with that at scale. Before applying any BIOS updates, make sure you have BitLocker recovery keys backed up and accessible. You can retrieve keys from:

  • Azure AD/Entra ID (for cloud-joined devices)
  • Active Directory (for domain-joined devices)
  • Microsoft Intune (for managed devices)
  • The user's Microsoft account (for personal devices)
# Export BitLocker recovery keys for the current machine
(Get-BitLockerVolume).KeyProtector | Where-Object { $_.KeyProtectorType -eq 'RecoveryPassword' } | 
    Select-Object KeyProtectorId, RecoveryPassword

Step 3: Deploy the 2023 Certificates

Microsoft provides three primary deployment methods. Choose one — and avoid mixing methods on the same device (trust me on this, it makes troubleshooting way harder).

Option A: Microsoft Intune (Settings Catalog)

This is the recommended approach for Intune-managed environments. Microsoft now exposes Secure Boot controls directly in the Intune Settings Catalog, which is a welcome change from the earlier days when this required custom scripts.

  1. In the Intune admin center, go to Devices > Windows > Configuration Profiles
  2. Create a new profile: Platform = Windows 10 and later, Profile type = Settings Catalog
  3. Browse for "Secure Boot" and configure these three settings:
  • Enable Secureboot Certificate Updates — Set to Enabled. This tells Windows to begin deploying updated certificates.
  • Configure Microsoft Update Managed Opt In — Set to Enabled to participate in Microsoft's controlled rollout, or leave Disabled to manage manually.
  • Configure High Confidence Opt-Out — Leave at default unless you need to prevent automatic deployment on specific device groups.

Assign the profile to a pilot group first, then expand to your full fleet after validation.

Known Issue: Secure Boot settings deployed via Intune were initially blocked on Windows Pro editions (Error Code 65000). Microsoft resolved this on January 27, 2026, by updating the Intune licensing service. Devices that received their license before that date needed a license renewal (automatic, monthly cycle). All devices should be unblocked by now, but if you're still seeing 65000 errors, it's worth checking the license date.

Option B: Group Policy (Domain-Joined Devices)

For environments using Active Directory and Group Policy:

  1. Open Group Policy Management Console
  2. Create or edit a GPO and navigate to:
    Computer Configuration > Administrative Templates > Windows Components > Secure Boot
  3. Set "Enable Secure Boot certificate deployment" to Enabled
  4. Link the GPO to the appropriate OU

After the policy applies, Windows will begin the certificate deployment process automatically. Allow approximately 48 hours and one or more restarts for updates to fully apply. I know — 48 hours feels slow, but that's the process.

Option C: Registry Key (Manual or Script-Based)

For unmanaged devices or environments without Intune or Group Policy, you can go direct:

# Deploy all needed certificates and update to the 2023-signed boot manager
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot" -Name "AvailableUpdates" -Value 0x5944 -Type DWord

# Optionally opt into Microsoft's managed rollout
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot" -Name "MicrosoftUpdateManagedOptIn" -Value 1 -Type DWord

Windows maintains a scheduled task that runs every 12 hours to process Secure Boot certificate updates. After setting the registry value, allow up to 48 hours and at least one restart for the full deployment to complete.

Step 4: Verify the Deployment

After deployment, verify success using the same audit methods from Step 1:

  1. Run the PowerShell one-liner — it should return True
  2. Check the registry — UEFICA2023Status should read Updated
  3. Check Event Viewer — look for Event ID 1808

Also check the UEFICA2023Error registry key. This key is only created when an error occurs during deployment, so its absence is actually a good sign.

# Full verification check
$db = ([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023')
$reg = (Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot").UEFICA2023Status
$err = (Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot" -ErrorAction SilentlyContinue).UEFICA2023Error

Write-Host "CA 2023 in DB: $db"
Write-Host "Registry Status: $reg"
Write-Host "Error Key: $(if ($err) { $err } else { 'None (good)' })"

Intune Reporting

For Intune-managed fleets, use the built-in reporting:

  1. Go to Reports > Windows quality updates in the Intune admin center
  2. Select the Secure Boot status report under the Reports tab
  3. Devices that have completed the update show as "Up to date" in the Certificate status column

One thing to watch out for: a device can have the correct Intune policy assigned and still show as "Not up to date" if the firmware doesn't yet support the updated certificates or the device hasn't rebooted. Don't panic — just verify the firmware is current and give it a reboot.

Step 5: Handle Edge Cases

Windows 10 End-of-Support Devices

Windows 10 reached end of support in October 2025, but let's be real — many organizations still have machines running it. These devices are affected by the certificate expiration too. If you can't upgrade them to Windows 11 (often due to TPM 2.0 requirements), prioritize getting the 2023 certificates deployed while they still receive updates, or plan for Extended Security Updates (ESU).

WSUS-Managed Environments

As of early 2026, there is no WSUS update package for the Secure Boot certificate deployment. This is a frustrating gap for WSUS-only shops. WSUS-managed devices will need an alternative deployment method — use the registry key approach or deploy a PowerShell script via your preferred management tool.

Dual-Boot and Linux Systems

If you have dual-boot configurations with Linux, heads up: the certificate update may affect third-party bootloaders that rely on the 2011 UEFI CA for Secure Boot signing. Check with your Linux distribution for updated shim bootloaders signed with the 2023 certificate before you roll this out.

Virtual Machines

VMs on Hyper-V, VMware, and Azure are subject to the same certificate expiration — they don't get a free pass just because they're virtual. For Azure VMs, Microsoft provides separate guidance. For on-premises Hyper-V VMs with Secure Boot enabled, apply the same certificate update procedures as physical machines.

Recommended Rollout Timeline

Treat this as a project with a hard deadline. Here's the timeline I'd suggest:

  1. Now through April 2026: Inventory your fleet, identify devices missing the 2023 certificates, and apply OEM firmware updates
  2. April 2026: Deploy certificates to a pilot group (5-10% of devices), monitor for issues for one week
  3. April–May 2026: Expand deployment in waves — 25%, 50%, then 100% of devices
  4. By May 31, 2026: Complete deployment across all devices, verify with reporting and PowerShell audits
  5. June 2026: Monitor for any remaining devices that slipped through and remediate

Frequently Asked Questions

Will my PC stop booting if I miss the Secure Boot certificate update deadline?

No. Devices that haven't received the updated 2023 certificates will continue to boot and operate normally after the 2011 certificates expire in June 2026. However, they'll enter a degraded security state and won't be able to receive future boot-level security protections, leaving them increasingly vulnerable to firmware-level attacks over time.

How do I check if my Windows 11 PC already has the new Secure Boot certificates?

Open PowerShell as Administrator and run: ([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'). If it returns True, your device has the updated certificate. You can also check the registry key HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\UEFICA2023Status — it should read "Updated" when complete.

Do I need to update the BIOS before applying the new Secure Boot certificates?

Microsoft recommends applying the latest OEM firmware/BIOS update before deploying the new certificates. Firmware updates make sure the Secure Boot infrastructure is ready to accept the new certificates correctly. Just be aware that BIOS updates may trigger a BitLocker recovery prompt, so have recovery keys accessible before proceeding.

Can I deploy the Secure Boot certificate update through WSUS?

Unfortunately, no — not yet. As of March 2026, there is no WSUS update package for the Secure Boot certificate deployment. WSUS-managed devices need an alternative method: either the registry key approach (setting AvailableUpdates to 0x5944), a Group Policy setting, or a PowerShell script deployed through your management platform.

What about older PCs that can't run Windows 11?

Devices running Windows 10 that can't meet Windows 11 hardware requirements (particularly TPM 2.0) are still affected by the certificate expiration. Deploy the 2023 certificates while these devices still receive updates. For devices on unsupported Windows versions, the certificate update may not be available, and these machines may never receive the fix — making them a long-term security risk that should be prioritized for hardware replacement.

About the Author Editorial Team

Our team of expert writers and editors.

Related Articles