7 min read<\/p>\n
Starting in June 2026, Microsoft\u2019s Secure Boot certificates issued in 2011 will expire. Windows devices that haven\u2019t installed the 2023 certificate update will no longer be able to apply new Secure Boot updates and will lose trust in newly signed third-party software. IT teams have roughly two months left to complete inventory assessments, testing, and deployment. Those who wait until June to begin will be too late.<\/strong><\/p>\n Secure Boot is a UEFI mechanism that verifies at system startup whether the loaded firmware, bootloader, and operating system originate from a trusted source. This chain of trust relies on cryptographic signatures issued by so-called Certificate Authorities (CAs). In 2011, Microsoft established three central CAs: the Microsoft Corporation KEK CA 2011 for the Key Exchange Key database, the Microsoft Windows Production PCA 2011 for signed Windows components, and the Microsoft Corporation UEFI CA 2011 for third-party software.<\/p>\n These three certificates will expire starting in June 2026. The transition isn\u2019t an abrupt failure but a phased process extending through October 2026. Microsoft introduced their successors in 2023 and has been gradually deploying them to existing devices via Windows Updates. PCs shipped since early 2024 include the 2023 CAs preinstalled-a strategic advantage for organizations with newer hardware fleets, but a risk for all others.<\/p>\n The change is driven by both technical and regulatory considerations. The 2011 certificates date from an era when SHA-1 was still widely used and Secure Boot involved far fewer manufacturers than today. By migrating to the 2023 CAs, Microsoft aligns its cryptographic practices with current standards and shortens certificate lifetimes to a duration better suited for production environments.<\/p>\n Definition<\/p>\n UEFI CA 2011 vs. UEFI CA 2023<\/strong> refers to two generations of Secure Boot certificates. The 2011 CAs have secured the trust chain for Windows and third-party firmware for over a decade. Starting in June 2026, the 2023 CAs replace them with updated signature algorithms and a clearer lifetime structure. Both CA sets can coexist-but only devices with the 2023 set installed will be able to trust new updates after the 2011 certificates expire.<\/p>\n<\/div>\n The simple rule is this: anything produced before 2024 requires an active update. In practice, this affects the majority of devices in a typical enterprise, as the average laptop lifespan ranges from four to six years-and desktops often remain in service even longer. Servers are also impacted, though virtualization hosts and VMs are handled differently.<\/p>\n Physical Windows devices receive the 2023 certificates through standard Windows Update channels. However, deployment isn\u2019t automatic in the sense that \u201cevery computer is guaranteed to get it.\u201d Microsoft rolls out updates in phases. Certain device classes are still awaiting OEM approvals. Dell, HP, Lenovo, and Fujitsu each follow different timelines for firmware updates that embed the CA changes at the hardware level. IT teams must verify the status per device model and cannot assume Windows Update alone will resolve the issue.<\/p>\n Virtual machines represent a special case. Hyper-V, VMware, and KVM all support Secure Boot, but certificate updates here are managed through virtualized firmware-not the guest operating system. VMware has published guidance for transitioning vSphere environments, while Microsoft delivers Hyper-V updates via host patches. For Linux-based KVM environments, the process is more complex and often requires manual intervention on each VM host.<\/p>\n Particularly tricky are older devices that have reached end-of-service from the OEM\u2019s perspective. For such hardware, there may no longer be compatible firmware available that anchors the 2023 CAs. Microsoft and manufacturers likely won\u2019t support all legacy devices. In an analysis published in late March 2026, XDA Developers noted that some pre-2020 Windows PCs probably won\u2019t ever receive the fix. For IT teams, this means those devices should be inventoried, prioritized, and either replaced early or operated in isolated network segments with reduced privileges.<\/p>\n Good news for IT teams: a device\u2019s status can be verified with minimal effort. Microsoft provides two methods. The first is a registry entry located at The second method is a PowerShell query published by Microsoft on its Tech Community blog. It lists the currently installed Secure Boot database entries and enables automated comparison against the desired state. For fleet-wide inventory, combining this approach with Microsoft Intune, Configuration Manager, or a comparable endpoint management tool-capable of querying the registry value across all devices-is strongly recommended. Manually checking hundreds of devices is simply impractical.<\/p>\n It\u2019s crucial to distinguish between \u201ccertificate installed\u201d and \u201ccertificate active.\u201d A device might have the 2023 certificate present in its UEFI database without actually using it. Only when the status shows \u201cupdated\u201d and the firmware actively uses the 2023 CAs to validate bootloaders is the device truly prepared. Completing the full transition typically requires multiple reboots and, in some cases, manual UEFI configuration. Therefore, IT teams should thoroughly test the process on a small set of pilot devices per model before launching a fleet-wide rollout.<\/p>\n Microsoft recommends a structured approach that IT teams can implement over the next six to eight weeks. The process consists of four sequential steps that build logically on one another and cannot be run in parallel:<\/p>\n Inventory and Grouping<\/p>\n Assess the status of all Windows devices via registry check or PowerShell query. Group devices by manufacturer model, age, and firmware version. The output is a list categorizing devices as \u201calready updated,\u201d \u201cupdate available,\u201d or \u201cno OEM support.\u201d<\/p>\n<\/div>\n<\/div>\n Pilot Rollout to Test Group<\/p>\n Select at least five to ten devices per device class as pilots. Deploy the update, perform a reboot, and verify the registry status. Document edge cases-especially devices with dual-boot configurations or custom firmware settings.<\/p>\n<\/div>\n<\/div>\n Phased Fleet Rollout<\/p>\n Roll out departmentally or by location. Coordinate reboot windows with business operations. Continuously monitor deployment via Configuration Manager or Intune, document exceptions, and escalate issues as needed.<\/p>\n<\/div>\n<\/div>\n Verification and Remediation<\/p>\n After rollout, verify that each device shows an \u201cupdated\u201d status. Identify devices that failed to update, analyze root causes (missing firmware, disabled Secure Boot, UEFI lockouts), and for legacy devices without a fix, conduct a risk assessment and plan alternatives.<\/p>\n<\/div>\n<\/div>\n<\/div>\n The consequences of missing this update aren\u2019t catastrophic in the sense of a total system failure, but they are technically inconvenient and organizationally burdensome. Windows devices without the 2023 CAs remain functional-they continue to boot, can be operated normally, and run applications. However, two key changes occur.<\/p>\n First: New Secure Boot revisions released by Microsoft after the cutoff date will no longer be trusted for installation. This primarily affects updates designed to counter emerging classes of boot-level malware, such as BlackLotus or CoSign-based attacks. Devices without the update gradually lose protection against threats targeting the Secure Boot chain. While not an immediate danger, this represents a slowly growing risk.<\/p>\n Second: Third-party software signed with the new 2023 CAs after the cutoff date will no longer be recognized as trustworthy by older devices. This includes Linux bootloaders like Shim and GRUB, which are frequently re-signed, as well as specialized security tools that include their own kernel components. IT teams managing mixed environments or specialized applications will encounter issues very quickly.<\/p>\n From a compliance standpoint, this matters because regulations like the EU\u2019s NIS2 Directive and standards such as ISO\/IEC 27001 require up-to-date security patches and robust vulnerability management. Auditors reviewing endpoint security architecture will not overlook questions about Secure Boot certificate status. Organizations unable to demonstrate a documented, compliant state risk not only technical complications but also regulatory non-compliance.<\/p>\n Organizations running Linux environments or dual-boot devices must account for an additional step. Red Hat published official guidance for RHEL environments in early 2026 outlining the transition to the 2023 CAs. The key point: the Red Hat Shim bootloader is signed by Microsoft using the UEFI CA 2011. Once this CA expires, RHEL and Fedora systems on non-updated devices will no longer boot securely. Red Hat provides new Shim versions signed with the UEFI CA 2023-but these require the corresponding CA to already be present on the target device.<\/p>\n For dual-boot devices running both Windows and Linux, this creates a clear sequence of actions. First, Windows must install the 2023 CAs via its update mechanism. Next, the UEFI firmware must anchor these new CAs into the trust chain. Only then can a RHEL or Fedora Shim signed with the 2023 CA boot successfully. Reversing this order won\u2019t work-a failed update could render the Linux partition unbootable. Affected teams should defer RHEL updates until the Windows-side transition is complete.<\/p>\n For the remaining weeks until June 2026, six concrete action steps can be prioritized:<\/p>\n The Secure Boot transition isn\u2019t a regulatory requirement with a vague deadline-it\u2019s a hard technical cutoff with a fixed date. Organizations that complete the update by June 2026 won\u2019t face immediate disruption. Those who miss the deadline will be left with devices that gradually stop trusting new Secure Boot updates and newly signed software-precisely at a time when boot-level attacks from groups like BlackLotus are on the rise.<\/p>\n The work is manageable, but it demands priority. Taking inventory is the most critical first step, as it forms the foundation for every subsequent decision. After that comes a structured rollout that clearly separates pilot, testing, and production phases. For IT teams, this means: start the inventory this week, deploy pilot devices next week, update all standard devices by end of April, and tackle edge cases in May. Teams that stick to this plan will enjoy a stress-free June.<\/p>\n Yes, both tools support deployment. Microsoft provides specific deployment rings distributed through Windows Update for Business or WSUS. Intune also offers compliance policies that monitor UEFICA2023Status and trigger alerts if deviations are detected. For Configuration Manager, Microsoft recommends combining an inventory task sequence with automated rollouts per device group. Manual intervention is only required for devices with custom UEFI settings or locked firmware.<\/p>\n For devices where Secure Boot was disabled for compatibility reasons, nothing changes in the short term. The expiring certificates only affect active Secure Boot functionality. However, IT teams shouldn\u2019t consider these devices \u201cdone.\u201d Disabling Secure Boot poses a security risk that should no longer be acceptable by 2026. The certificate transition is therefore an ideal opportunity to audit existing Secure Boot deactivations and re-enable them wherever possible.<\/p>\n The easiest source is the manufacturer\u2019s support website. Dell, HP, Lenovo, and Fujitsu have published lists of supported devices. For devices not listed there, contact the vendor\u2019s support team directly. If even that inquiry yields no positive response, the device is considered end-of-service from the OEM\u2019s perspective and will no longer receive the fix. Microsoft also maintains a dedicated landing page at aka.ms\/GetSecureBoot featuring a collection of tools and vendor references.<\/p>\n Hyper-V VMs on Windows Server receive the update automatically via host patches. VMware vSphere requires ESXi firmware updates provided directly by VMware. KVM-based environments on Linux hosts are more complex, as the OVMF firmware must be updated separately. For production virtualization platforms, we recommend a separate rollout wave ahead of the deadline, distinct from client updates. Using test VMs as pilots helps identify edge cases early.<\/p>\n Microsoft rolls out the 2023 CAs gradually to avoid overloading production systems. A manual override is possible using the registry key MicrosoftUpdateManagedOptIn, which accelerates rollout for a specific device. Set the value to 0x5944 for individual pilot devices. This method is primarily useful for dedicated test machines and compliance audits-not for broad-scale deployment.<\/p>\n Microsoft has not announced any extension and, on the contrary, signaled through its playbook publication that the deadline is firm. Planning should therefore strictly target the June cutoff date. Even if Microsoft were to introduce a grace period at the last minute, the benefits of completing the rollout on time are significant enough that teams shouldn\u2019t rely on potential leniency. Treat the deadline as fixed.<\/p>\n Source, cover image: Pexels \/ panumas nikhomkhai<\/p>\n","protected":false},"excerpt":{"rendered":"Starting June 2026, Microsoft’s 2011 Secure Boot certificates will expire. IT teams have two months to complete inventory and deployment.","protected":false},"author":55,"featured_media":12036,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_yoast_wpseo_focuskw":"Secure Boot certificates expiration","_yoast_wpseo_title":"Secure Boot Certificates Expire in June 2026: What IT Teams Must Prepare for The","_yoast_wpseo_metadesc":"Secure Boot Certificates: Microsoft retires 2011 CAs starting June 2026. What IT teams need to implement now for Windows fleets, UEFI, and Linux dual-boot setups.","_yoast_wpseo_meta-robots-noindex":"","_yoast_wpseo_meta-robots-nofollow":"","_yoast_wpseo_meta-robots-adv":"","_yoast_wpseo_canonical":"","_yoast_wpseo_opengraph-title":"","_yoast_wpseo_opengraph-description":"","_yoast_wpseo_opengraph-image":"","_yoast_wpseo_opengraph-image-id":0,"_yoast_wpseo_twitter-title":"","_yoast_wpseo_twitter-description":"","_yoast_wpseo_twitter-image":"","_yoast_wpseo_twitter-image-id":0,"_evm_translation_lang":"","featured_post":0,"featured_post_sortierung":0,"_wp_old_slug":["windows-secure-boot-certificates-expire-in-june-2026-what-it"],"footnotes":""},"categories":[251],"tags":[],"class_list":["post-12592","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-news"],"evm_reading_time_minutes":14,"wpml_language":"en","wpml_translation_of":12032,"_links":{"self":[{"href":"https:\/\/www.securitytoday.de\/en\/wp-json\/wp\/v2\/posts\/12592","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.securitytoday.de\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.securitytoday.de\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.securitytoday.de\/en\/wp-json\/wp\/v2\/users\/55"}],"replies":[{"embeddable":true,"href":"https:\/\/www.securitytoday.de\/en\/wp-json\/wp\/v2\/comments?post=12592"}],"version-history":[{"count":5,"href":"https:\/\/www.securitytoday.de\/en\/wp-json\/wp\/v2\/posts\/12592\/revisions"}],"predecessor-version":[{"id":15483,"href":"https:\/\/www.securitytoday.de\/en\/wp-json\/wp\/v2\/posts\/12592\/revisions\/15483"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.securitytoday.de\/en\/wp-json\/wp\/v2\/media\/12036"}],"wp:attachment":[{"href":"https:\/\/www.securitytoday.de\/en\/wp-json\/wp\/v2\/media?parent=12592"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.securitytoday.de\/en\/wp-json\/wp\/v2\/categories?post=12592"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.securitytoday.de\/en\/wp-json\/wp\/v2\/tags?post=12592"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Key Takeaways<\/h2>\n
\n
What Specifically Expires in June 2026<\/h2>\n
Which Devices Are Affected<\/h2>\n
The Inventory Check: PowerShell and Registry<\/h2>\n
HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\SecureBoot\\UEFICA2023Status<\/code>. This entry should ultimately read \u201cupdated.\u201d Other values, such as \u201cNotStarted\u201d or \u201cInProgress,\u201d indicate that deployment is still underway.<\/p>\nThe Update Process in Four Steps<\/h2>\n
What Happens If the Update Isn\u2019t Applied in Time<\/h2>\n
Special Case: Linux Dual-Boot and RHEL Environments<\/h2>\n
Six-Point Checklist for IT Teams<\/h2>\n
\n
Conclusion<\/h2>\n
Frequently Asked Questions<\/h2>\n
Can we deploy the update centrally via Intune or Configuration Manager?<\/h3>\n
What happens to devices that already have Secure Boot disabled?<\/h3>\n
How can I tell whether my hardware vendor still provides the update?<\/h3>\n
What does this mean for our virtualization environment?<\/h3>\n
Is there a way to force the update if Windows Update doesn\u2019t offer it?<\/h3>\n
Will the deadline be extended?<\/h3>\n
Editor\u2019s Picks<\/h2>\n
\n
More from the MBF Media Network<\/h2>\n
\n