By Michael Branson

Quick answer. As of September 2026, two Secure Boot certificates Microsoft issued in 2011 have expired, the Microsoft Corporation KEK CA 2011 on June 24, 2026 and the Microsoft UEFI CA 2011 on June 27, 2026, and the Microsoft Windows Production PCA 2011 that signs the Windows boot loader expires on October 19, 2026, according to Microsoft’s Windows Secure Boot certificate expiration and CA updates page. Microsoft’s FAQ makes the customer ultimately responsible for the update, and its other pages call out the classes your team plans itself: Windows Server machines whose firmware does not already carry the 2023 certificates, Azure Trusted Launch and Confidential virtual machines created before March 2024, the golden images you build virtual machines from, and any device Microsoft’s automatic assist does not reach. A device left on the 2011 certificates still starts and still takes standard Windows updates, but in Microsoft’s words it “will no longer be able to receive new security protections for the early boot process”, and Microsoft says the cumulative updates that carry the new certificates “can still be applied even if the existing certificates have expired.” A machine whose firmware cannot take the update and that is no longer supported goes on a written exception list or is replaced, which is what Microsoft’s own guidance points to when it says “Document as exception” and “consider replacing the device”.

The June dates came and went, the laptops still booted, the servers still patched, and the item on the risk register was closed as done. That is the false comfort this certificate change creates: nothing visible breaks on the expiry date, so an estate can sit on the old certificates long after the date while it quietly stops receiving boot-level fixes. This guide sets out what Microsoft’s own support pages and its Windows Server playbook, read on 2026-09-24, say about each class of Windows machine, and where the i3solutions recommendation sits beside them.

Two Dates Have Passed and Nothing Broke: What an Unupdated Device Keeps and What It Loses

If the June dates passed without a single failed boot, that is what Microsoft said would happen, and it is not the end of the matter. Microsoft’s Windows Secure Boot certificate expiration and CA updates page lists three 2011 certificates, each with its own date and its own replacement:

Expiring certificate (Microsoft’s name) Expiration date in Microsoft’s table Replacement (Microsoft’s name) Stored in What it signs, per Microsoft Microsoft’s page
Microsoft Corporation KEK CA 2011 June 24, 2026 (passed) Microsoft Corporation KEK 2K CA 2023 KEK Updates to DB and DBX Windows Secure Boot certificate expiration and CA updates
Microsoft UEFI CA 2011 June 27, 2026 (passed) Microsoft UEFI CA 2023 DB Third-party boot loaders and EFI applications Windows Secure Boot certificate expiration and CA updates
Microsoft UEFI CA 2011 June 27, 2026 (passed) Microsoft Option ROM UEFI CA 2023 DB Third-party option ROMs Windows Secure Boot certificate expiration and CA updates
Microsoft Windows Production PCA 2011 October 19, 2026 Windows UEFI CA 2023 DB The Windows boot loader Windows Secure Boot certificate expiration and CA updates

One certificate appears twice: according to Microsoft, renewing the Microsoft UEFI CA 2011 separates boot loader signing from option ROM signing.

The same page says devices without the 2023 certificates “will continue to start and operate normally, and standard Windows updates will continue to install.” It goes straight on: “However, these devices will no longer be able to receive new security protections for the early boot process, including updates to Windows Boot Manager, Secure Boot databases, revocation lists, or mitigations for newly discovered boot level vulnerabilities.” Microsoft’s When Secure Boot certificates expire on Windows devices page names what that means in practice: “Vulnerability fixes for the early boot environment”, among them “BitLocker bypass mitigations or Secure Boot revocations”, “will not be available.”

Two more facts shape the plan. Both halves of the chain move: Microsoft’s certificate expiration page says “Both UEFI Secure Boot DB and KEK need to be updated with the corresponding new 2023 certificate versions.” And a passed date is not a closed door. Can the 2023 certificates still be applied after the old ones expire? Microsoft’s Frequently asked questions about the Secure Boot update process page says “The cumulative updates that contain the new Secure Boot certificates can still be applied even if the existing certificates have expired.” What is not an option is switching the feature off: the expiry page says “Secure Boot should not be disabled to work around certificate expiration.”

Whose Job It Is: Microsoft’s Assist Is Not a Guarantee

If the working assumption is that Windows Update will handle this, Microsoft’s own FAQ says otherwise. Its Frequently asked questions about the Secure Boot update process page says “The customer is ultimately responsible for updating the Secure Boot certificates.” It describes Microsoft’s updates as “provided as an assist, not a guarantee”, and says “IT administrators remain responsible for ensuring their entire fleet is updated”, using Microsoft’s “automated CFR and other documented deployment methods”.

The automatic route has limits Microsoft states itself. Its Secure Boot Certificate updates: Guidance for IT professionals and organizations page says that while Controlled Feature Rollout (CFR) “may assist in deployment of the new certificates”, organizations will not be able to rely on it “to remediate their fleets”. For servers the answer is plainer still. Microsoft’s Windows Server Secure Boot playbook for certificates expiring in 2026 says “Windows Server 2025 certified server platforms already include the 2023 certificates in firmware. For servers that do not, IT administrators must manually update the certificates, because Windows Server does not receive them automatically.”

For managed Windows PCs, the Intune route has its own states. Microsoft’s Microsoft Intune method of Secure Boot for Windows devices with IT-managed updates page describes a settings catalog setting, Enable Secureboot Certificate Updates, with two states: Enabled, where “Windows automatically begins deploying updated Secure Boot certificates.”, and Disabled, which Microsoft’s description marks as the default, where “Windows does not deploy certificates automatically.” The planning rule that follows is the i3solutions recommendation, not a Microsoft statement: treat every class of machine as your team’s until its own status reads updated.

Sort the Estate by Device Class Before Touching Firmware

If the inventory lists every Windows machine as one group, it cannot tell you who moves what, because Microsoft’s pages treat each class differently. Sort the estate first; each class below carries the Microsoft fact that decides how it is handled:

  • Devices with Secure Boot turned off. Microsoft’s Frequently asked questions about the Secure Boot update process page says “Devices with Secure Boot disabled will not receive the new Secure Boot certificates in firmware.” Each one is a finding of its own before it is part of this program.
  • Managed Windows PCs. They can take Microsoft’s assist, but the FAQ’s rule above still applies: the customer is ultimately responsible, and the status on each device is what counts.
  • Windows Server on physical hosts. Microsoft’s Windows Server Secure Boot playbook for certificates expiring in 2026 says certified Windows Server 2025 platforms already carry the 2023 certificates in firmware and that other servers are updated manually by IT administrators. For servers it adds: “You can use registry keys or Group Policy.”
  • Hyper-V hosts and guests. The same playbook says “Generation 1 Hyper-V VMs do not support Secure Boot.” and “Note: This guidance does not apply to Azure Local hosts, Windows PCs or Generation 1 Hyper-V VMs.” For Hyper-V virtual machines, the fix Microsoft documents for a failed KEK update logged as Event ID 1795, on its Known issues and resolutions for Secure Boot certificates updates page, carries the rule “To resolve this issue, you must deploy the fix on both the host and the guest.” For Azure Local, the same fix reads “For Azure Local devices, install the Azure 2603 security update or a later update.”
  • Other long-running virtual machines. Microsoft’s Secure Boot Certificate updates: Guidance for IT professionals and organizations page says “For Windows running long term in a VM, the updates can be applied through Windows like any other devices, if the virtualized firmware supports Secure Boot updates.” Whether it does is a question for your virtualization platform’s provider.
  • Azure Trusted Launch and Confidential virtual machines. Microsoft’s Secure Boot update from 2011 to 2023 certificates: Trusted Launch VMs (TVM) and Confidential VMs (CVM) page says “Virtual machines created after March 2024 typically already include the Secure Boot 2023 certificates in virtual firmware.” and “Long-running virtual machines created prior to March 2024 do not include the Secure Boot 2023 certificates in virtual firmware and require updates to both Secure Boot certificates and Windows Boot Manager.” It also says “Standard security-type VMs do not have Secure Boot enabled.”
  • Golden images and the machines built from them. The same Trusted Launch page says “Applying Secure Boot updates within a golden image advances the Windows Boot Manager but does not persist Secure Boot certificates to virtual machines provisioned from that image.” An updated image is not an updated fleet; the certificates are applied on each machine.
  • Session hosts and Cloud PCs. Microsoft’s Secure Boot Certificate Updates for Azure Virtual Desktop table lists a Trusted Launch session host with Secure Boot enabled with the action “Update certificates on the session host”, and its Secure Boot Certificate Updates for Windows 365 table lists a Cloud PC with Secure Boot enabled with the action “Update certificates on the Cloud PC”.
  • Fixed-function and instrument-attached machines. Microsoft’s When Secure Boot certificates expire on Windows devices page tells owners to “contact your OEM for information about required firmware updates, keeping in mind that such updates may only be available for devices that are still within their support period.” Put the equipment owner and the device maker in the plan from the start.
  • Out-of-support hardware. These are the likeliest entries on the exception list, covered below.

Stage It So Nothing Stops Booting

If the first push goes to every machine at once, a firmware that mishandles the update is found across the estate instead of in a test group. Microsoft’s Secure Boot Certificate updates: Guidance for IT professionals and organizations page says “To minimize risk, deploy Secure Boot updates in stages rather than all at once.” and “Recommended guidance on the number of sample devices to test for each unique category is 4 or more.” It also sets the clock for each device: “Estimate 48 hours and one or more restarts for the certificates to apply.”

The certificates are not the last step. The same page says “Applying this boot manager is a critical last step in the deployment for each device.” That step carries the boot risk. Microsoft’s Frequently asked questions about the Secure Boot update process page explains that if Windows already uses the 2023-signed boot manager and the firmware is then reset to defaults that do not include the Windows UEFI CA 2023 certificate, “Secure Boot will block the boot process.” Have recovery media and a firmware-reset plan ready for each class before its boot manager moves.

Microsoft names the channels: its IT professional guidance lists registry keys, Group Policy, the Windows Configuration System (WinCS) APIs and Microsoft Intune. For servers, Microsoft’s Windows Server Secure Boot playbook for certificates expiring in 2026 describes the registry route by the AvailableUpdates value: “Set its value to 0x5944 to deploy all needed certificates and update to the Windows UEFI CA 2023 signed boot manager.” The same playbook says “Avoid mixing deployment methods on the same device.” Which management tool carries the push is a separate decision, covered in SCCM vs Intune: An Endpoint Management Decision for Regulated Enterprises. Three planning rules, as the i3solutions recommendation:

  • Baseline every class’s certificate status before the first push, so progress is measured rather than assumed.
  • Use one deployment method per device, as Microsoft’s playbook advises.
  • Apply the device maker’s firmware update before the certificate push where the maker publishes one, following the playbook’s step “Apply any needed OEM firmware updates before updating certificates”.

The Exception List: What Cannot Take the Update and What You Write Down

If a machine cannot take the update, the answer is a written record, not a quiet gap. Microsoft’s Secure Boot Certificate updates: Guidance for IT professionals and organizations page carries a confidence table whose Not Supported level, a “Known Limitation”, means “Platform or hardware limitations” and carries the action “Document as exception”. The same page says “In cases where the firmware does not work correctly and the device is no longer in support, consider replacing the device to ensure Secure Boot protection across your fleet.”

The reasons a machine lands on the list come from Microsoft’s own pages: firmware updates that, in the words of the expiry page, “may only be available for devices that are still within their support period”; Windows versions that are out of support, because Microsoft’s FAQ says “Only supported Windows OS versions will get the certificates.”; and devices with Secure Boot turned off, which do not receive the certificates at all. Each exception row carries:

  • the device and its class;
  • the reason, in Microsoft’s category;
  • the compensating control your team relies on while the machine stays;
  • the named owner;
  • the review date or the replacement date.

Turning Secure Boot off is never the treatment for an exception; Microsoft’s expiry page says it “should not be disabled to work around certificate expiration.” Whether a given exception satisfies your security office or an assessor is their determination, and this guide does not make it.

What Microsoft Still Has Open, and What to Re-Check

If a cloud-hosted machine reports a stuck update, check Microsoft’s list before opening a ticket. Microsoft’s Known issues and resolutions for Secure Boot certificates updates page carries an open item, last clarified in its change log on July 14, 2026: “On some Azure Trusted Launch (Gen2) virtual machines”, the KEK update might not complete and Event ID 1795 is logged, an issue the page says also affects certain Windows 365 Cloud PCs and Azure Virtual Desktop. Its status reads: “At this time, there is no required customer action.” The same page records the Hyper-V item, whose fix includes the Azure Local update, as resolved, with the fix quoted in the device-class list above.

Further boot manager updates are not dated. Microsoft’s IT professional guidance says “Specific updates on Boot Manager will be in future releases.” and names no date for them. Re-read Microsoft’s certificate expiration page, its FAQ, its IT professional guidance and its known-issues page on October 19, 2026 and at each change-log entry, because parts of this guide move with them.

When This Is Not the Right Plan

If your estate does not look like the one above, the work may be smaller or belong elsewhere:

  • An estate made mostly of recent hardware may find most classes already carry the certificates. Microsoft’s playbook says certified Windows Server 2025 platforms already include them, and Microsoft’s Secure Boot Certificate updates: Guidance for IT professionals and organizations page notes that devices made in the past one to two years may already have the updated certificates but might not have the 2023-signed boot manager applied. There the work is verification and the boot manager step, not a program.
  • If the fleet decision is to replace hardware or move off an operating system soon, fold the exceptions into that plan rather than running a separate one.
  • Microsoft’s pages describe Microsoft’s process, not your compliance obligation. What an assessor expects is yours to confirm with your security office.
  • If Microsoft changes its guidance or dates its further boot manager updates, parts of this guide change with it.

What to Ask of Whoever Helps

If you bring in outside help, hold the work to these criteria:

  • A certificate status baseline by device class before any push.
  • A representative test set for each unique hardware and firmware category, 4 or more machines each, as Microsoft’s IT professional guidance recommends.
  • Recovery media and a firmware-reset plan before the boot manager moves.
  • Servers, Hyper-V hosts and guests, Azure virtual machines and golden images planned as separate classes.
  • A written exception list with named owners and review dates.
  • Senior, US-based people on the work.

Be plain about what stays with you. Running and patching the estate after the project remains your team’s ongoing work; i3solutions does not take it on as an ongoing managed service. An i3solutions engagement does not produce managed-service ownership, a replacement for the internal team, open-ended scope expansion, or vendor lock-in.

How i3solutions Answers

If you want an outside architect on this program, i3solutions takes on the certificate update as project work: the status baseline, the device-class map, the pilot and staged rollout through your existing channel, the server and virtual machine plan, and the exception list, with embedded specialists where your team needs them. i3solutions plans and runs Intune migrations for enterprises moving domain-joined Windows devices off on-premises Group Policy. i3solutions has been a Microsoft Partner with 30 years of enterprise technology delivery experience and has delivered 1,500+ Microsoft engagements across aerospace and defense, financial services, and health sciences. Its Intune work is described in Microsoft Intune Technology Readiness Services, and the wider practice in Enterprise Digital Transformation Solutions for Governed, Scalable Modernization. For moving Windows devices off Group Policy more broadly, see Intune Migration Checklist: 1,200 Windows Devices Off Group Policy.

Key Takeaways

  • According to Microsoft, the Microsoft Corporation KEK CA 2011 expired on June 24, 2026, the Microsoft UEFI CA 2011 on June 27, 2026, and the Microsoft Windows Production PCA 2011 expires on October 19, 2026.
  • A device left on the 2011 certificates keeps booting and patching but, according to Microsoft, stops receiving new early-boot protections; Microsoft says the update can still be applied after expiry.
  • Microsoft’s FAQ puts the responsibility on the customer, and Microsoft’s Windows Server playbook says Windows Server does not receive the certificates automatically, so servers whose firmware lacks them are updated by IT administrators.
  • Virtual machines, golden images, session hosts and Cloud PCs each follow their own Microsoft rule; sort the estate by class before the first push.
  • Stage the push, test each unique category, prepare recovery before the boot manager moves, and write every machine that cannot take the update onto an exception list with an owner.

Frequently Asked Questions

What happens to a device that still has the 2011 Secure Boot certificates?

It keeps working but loses early-boot protection. Microsoft says such devices “will continue to start and operate normally, and standard Windows updates will continue to install.” and adds “However, these devices will no longer be able to receive new security protections for the early boot process, including updates to Windows Boot Manager, Secure Boot databases, revocation lists, or mitigations for newly discovered boot level vulnerabilities.”

Can the 2023 certificates still be applied after the old ones expire?

Yes. Microsoft’s FAQ says “The cumulative updates that contain the new Secure Boot certificates can still be applied even if the existing certificates have expired.”

Does Windows Server get the new Secure Boot certificates automatically?

No. Microsoft’s blog post, the Windows Server playbook, says “Windows Server 2025 certified server platforms already include the 2023 certificates in firmware. For servers that do not, IT administrators must manually update the certificates, because Windows Server does not receive them automatically.”

Do Hyper-V and Azure virtual machines need the update?

By class. Microsoft says “Generation 1 Hyper-V VMs do not support Secure Boot.” and, for its fix to a failed KEK update logged as Event ID 1795 on Hyper-V virtual machines, “To resolve this issue, you must deploy the fix on both the host and the guest.” For Azure Trusted Launch and Confidential VMs, according to Microsoft, “Long-running virtual machines created prior to March 2024 do not include the Secure Boot 2023 certificates in virtual firmware and require updates to both Secure Boot certificates and Windows Boot Manager.”, while “Standard security-type VMs do not have Secure Boot enabled.”

Should we turn off Secure Boot on devices that cannot take the update?

No. Microsoft says “Secure Boot should not be disabled to work around certificate expiration.” and “Devices with Secure Boot disabled will not receive the new Secure Boot certificates in firmware.” Microsoft’s guidance for a device with platform or hardware limitations is “Document as exception”.

Planning the Update

If your Windows estate needs a certificate status baseline by device class, a staged rollout plan that tests each device class before it moves, or an exception list your security office can sign, the next step is a conversation about your estate.

Contact a senior architect