UEFI Secure Boot 2011 Certificates Expire Oct 19—Use This Microsoft Script to Prepare

Microsoft’s July 15 Secure Boot Office Hours session confirmed that the final 2011-era certificate, the Windows Production PCA 2011, will expire on October 19, 2026. The event also revealed a previously little-known PowerShell script bundled in recent Windows 11 updates that lets IT admins check a device’s Secure Boot certificate status locally—offering a critical head start for fleet-wide transitions.

What Microsoft and OEMs Just Clarified

The 12-hour Tech Community discussion, reported by Windows Latest, brought together engineers from Microsoft and major PC manufacturers to field questions from IT administrators. While the deadline itself had been known, the session filled in crucial operational gaps that had left many fleets stuck between a looming expiration and incomplete deployment plans.

New local detection script ships with Windows Updates. After May 12, 2026, applicable Windows updates silently drop a set of PowerShell scripts into %systemroot%\SecureBoot\ExampleRolloutScripts. The key file is Detect-SecureBootCertUpdateStatus.ps1. It reads the local registry and event log, producing a full certificate status report without making any changes—ideal for auditing a single device before and after a rollout.

Registry keys demystified. Two similarly named values have been a source of confusion:
- AvailableUpdates (at HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot) is the one admins set to 0x5944 to trigger the full 2023 certificate chain deployment. It can be edited directly or through scripts, but only after proper testing.
- AvailableUpdatesPolicy is managed automatically by Group Policy or Microsoft Intune; Microsoft explicitly warns against manual registry edits for this value.

Offline devices aren’t left behind. Any machine still holding the 2011 certificates will pick up the 2023 chain the first time it reconnects to Windows Update, no matter how long it’s been idle. And devices that already have the 2023 certificates in firmware but still boot using the 2011 chain will switch automatically after the latest patches install.

BitLocker recovery isn’t expected—but it happens. Several admins reported recovery events during deployment. Microsoft’s Jason Sandys said BitLocker recovery is not a normal part of the certificate update; when it occurs, the cause is usually custom PCR configurations or firmware-specific issues, not the deployment method itself. That makes recovery-key escrow a non-negotiable first step.

Firmware readiness varies by OEM. Dell and HP representatives spelled out which enterprise models already carry the 2023 certificates in their latest BIOS releases. Surface devices released since 2024 ship with the 2023 certificates; older Surface Pro 3, Surface 3, and earlier Windows 8-era models are excluded. HP even offers a manual update package for its out-of-support EliteBook 840 G5, though it won’t survive a factory reset.

What This Means for You

If you’re a home user

Open Windows Security > Device security > Secure Boot. If it says Secure Boot is on and all certificate updates are applied, you’re set—Windows Update will keep your PC current. There’s no panic button for everyday users; the certificate transition is handled automatically for devices that routinely receive updates. If your device is older than a Surface Pro 3 (2014) or equivalent, it may be excluded, but those machines likely aren’t running Windows 11 anyway.

If you’re an IT admin or fleet manager

This is a fleet-readiness exercise, not a monthly patch cycle. The October 19 deadline is a planning goal—you need to know which devices are ready, which need firmware updates, and which will require manual intervention. The Office Hours session validated a staged approach:
1. Confirm every target device has its BitLocker recovery key escrowed in Entra, Intune, or your RMM before you touch Secure Boot settings.
2. Inventory your fleet by exact model, BIOS/UEFI version, Windows patch level, and current certificate state, not just “Dell laptops.”
3. Use the built-in Detect-SecureBootCertUpdateStatus.ps1 script (see below) to benchmark representative hardware cohorts.
4. Deploy through documented Group Policy Objects or Intune policies—not by editing the registry on production machines.

Intune may show generic errors (State Error, Error Type 2, Error Code 0). When it does, don’t assume the policy is broken; instead, capture the local script output, firmware version, and policy assignment to diagnose the specific cohort. A single success on one Latitude 5540 with BIOS 1.5.1 doesn’t mean every Latitude in your fleet is ready; group by BIOS version.

How We Got Here

Microsoft’s Secure Boot certificate chain has been using 2011-era roots for over a decade. In 2023, a new 2023 chain was introduced to eventually replace them. The transition has been rolling out gradually through multiple Windows updates and OEM firmware releases. Two of the three 2011 certificates—the Corporation KEK CA 2011 and the UEFI CA 2011—have already expired, and now the final one, the Windows Production PCA 2011, will expire on October 19, 2026.

The expiration itself doesn’t immediately brick devices. A certificate past its expiration date can still be used to validate existing boot components, but its long-term viability depends on how Microsoft, OEMs, and software vendors enforce revocation and use time-stamping. Microsoft has been pushing the industry to move to the 2023 chain well before that date, and the Office Hours session was designed to close the gap between official guidance and real-world deployment friction.

What to Do Now

For home users: Confirm your Secure Boot status as described above. If you’re up to date, you’re done.

For administrators, here’s a concrete, phased plan built from the session’s verified facts.

1. Lock down recovery keys

Before any Secure Boot change, verify that the BitLocker recovery key for each target device is stored in your organization’s approved escrow location and can be retrieved by your support staff. If a device enters recovery, this is your safety net.

2. Install the post–May 12 updates

Make sure devices you plan to pilot have installed Windows updates released after May 12, 2026. These contain the example scripts that serve as your local detection tool.

3. Run the detection script on a representative sample

On a handful of devices from each significant hardware/BIOS cohort, open an elevated PowerShell session and run:

Set-Location "$env:SystemRoot\SecureBoot\ExampleRolloutScripts"
.\Detect-SecureBootCertUpdateStatus.ps1

Capture the output along with the device’s OEM, model, BIOS version, Windows edition, and BitLocker status. Do this before and after any deployment.

4. Choose your deployment method—and stick to it

Microsoft supports three official paths. Pick the one that matches your management infrastructure:

Do not manually edit AvailableUpdatesPolicy. Its value is maintained by policy infrastructure. Direct registry manipulation of AvailableUpdates should be treated as a pilot-only, engineering-controlled step—not a broad deployment shortcut.

5. Roll out in cohorts

Use your inventory groupings (OEM, model, BIOS version, script result) to define successive pilot cohorts. After each cohort deployment:
- Re-run the detection script.
- Verify BitLocker doesn’t trigger recovery.
- Check device performance and application compatibility.
- If any device shows unexpected behavior, pause expansion and investigate.

6. Document exceptions for legacy or unsupported devices

Devices that can’t receive the 2023 certificates (e.g., older Surface models, out-of-service HP EliteBooks without the manual package) need a documented exception. Record:
- Exact model and BIOS version
- Reason for exclusion
- Business owner
- Intended retirement or replacement date

This keeps them from slipping through the cracks when auditors ask about compliance status.

7. Know what to do if BitLocker recovery fires

If a device enters recovery during deployment:
- Use the escrowed key to unlock.
- Collect the local detection script output, firmware version, and any error codes.
- Suspend the rollout for that cohort until you can rule out firmware mismatches or policy conflicts.

The Hidden Script That Changes the Game

The quietest but most impactful reveal from Office Hours is Detect-SecureBootCertUpdateStatus.ps1. Before this, admins had to rely on cobbled-together registry probes or third-party utilities. Now, a Microsoft-supplied, zero-change script lives right on every updated Windows machine. It outputs whether the 2011 or 2023 certs are in the database, the current confidence level, and any pending actions. For fleets already managed through Intune or Autopatch, the script can surface details that management reports might flatten into ambiguous status codes.

Outlook: Three Months and Counting

With the October 19 deadline now just over three months away, the clock is loudest for organizations that haven’t started. Microsoft hasn’t indicated plans to push the date again, and OEM partners have largely released the necessary firmware. The session showed that the underlying technology works—but success depends on methodical rollout, not on wishful thinking about a single update.

Watch for two things in the coming weeks: Microsoft may update the example scripts or publish an aggregated reporting tool as the deadline nears. And as more fleets hit the transition, real-world data will further clarify which firmware versions are truly low-risk. In the meantime, treat the scripts and policies as the foundation they are: tools that give you visibility and control, not magic that replaces testing.

For the complete list of affected Surface models, Dell BIOS versions, and HP SoftPaq IDs, consult the official OEM documentation linked below. And if you haven’t yet verified your recovery-key escrow, stop reading and go do that now—it’s the one step that turns a potential crisis into a routine support call.