The first Microsoft Secure Boot certificate from the Windows 8 era expires on June 24, 2026, beginning a staged retirement of 2011 trust anchors that still underpin boot security on many Windows PCs, servers, and embedded systems. The immediate danger is not a wave of unbootable laptops. It is subtler and more uncomfortable: machines that keep starting normally can slide into a degraded security state where future boot-level fixes no longer arrive. That makes this deadline less like a Y2K-style cliff and more like a warranty expiring on the part of Windows security most users never see.
Secure Boot was introduced to make the earliest moments of a PC’s startup less of a free-for-all. Before Windows loads, firmware checks whether the boot components it is about to execute are signed by trusted authorities. That design is meant to stop bootkits, malicious option ROMs, and tampered bootloaders from getting control before the operating system and its security stack are awake.
The problem is that trust is not timeless. The certificates that made sense in 2011 were never supposed to be immortal, and Microsoft is now trying to rotate the ecosystem to newer 2023 certificates before the old ones age out. That sounds routine until you remember where these certificates live: in firmware databases, OEM images, deployment media, server platforms, recovery environments, dual-boot setups, and machines that may not have had a BIOS update since the Obama administration.
Three Microsoft-provided certificates form the core of this transition. The Microsoft Corporation KEK CA 2011 expires first on June 24, 2026. The Microsoft UEFI CA 2011 follows days later, with reporting and vendor material placing the date around June 27 for many affected paths. The Microsoft Windows Production PCA 2011, the certificate associated with signing Windows boot manager components, reaches its more consequential deadline on October 19, 2026.
That October date is the one administrators should circle in red, but June is when the floor starts shifting. The Key Exchange Key is what authorizes updates to Secure Boot databases such as the allowed-signature database and the forbidden-signature database. If a device cannot accept new Secure Boot database updates, it cannot participate fully in the next round of boot-layer defense.
That surface calm is the trap. Boot security is a layer users notice only when it breaks, and Microsoft’s task here is to fix it without producing the very boot failures that would make the public pay attention. If the migration succeeds, most supported Windows 11 systems will quietly receive new certificates through Windows Update and never know anything happened.
But a machine that continues to boot is not necessarily a machine that remains fully protected. Once the relevant Secure Boot certificates expire, systems that did not receive the replacement chain may lose the ability to accept future Secure Boot database updates, including revocations and other mitigations for newly discovered boot-stage attacks. In other words, the machine can remain operational while its boot-defense channel becomes stale.
That distinction matters because Secure Boot is not merely a checkbox used to satisfy Windows 11 setup. It is a living trust mechanism. When Microsoft needs to revoke a vulnerable bootloader or push a database change after a real-world exploit appears, that update path is part of the response.
The BlackLotus episode exposed the operational fragility of boot security. Revoking vulnerable boot components too aggressively can strand legitimate systems. Moving too slowly leaves attackers with a known path beneath the operating system. Microsoft had to stage mitigations, provide management knobs, and give enterprises time to test because the Secure Boot trust chain is both a security boundary and a boot dependency.
The 2026 certificate rollover sits in that same uncomfortable category. Microsoft is not just replacing some paperwork. It is preserving the ability to respond to the next BlackLotus-like problem. A PC that misses the 2023 certificate update may still run today’s Windows, but it may be cut off from tomorrow’s Secure Boot remediation.
That is why the “your PC will still start” reassurance is only half the story. It is true, and it is useful, but it can also lull users into thinking there is no practical consequence. The consequence is deferred risk: the kind that becomes visible only when a new boot-layer vulnerability requires a revocation your machine can no longer consume.
That targeting language matters. Microsoft is not simply blasting every system with identical Secure Boot changes. The company has to decide which devices are eligible, which firmware configurations can safely accept updates, and which machines need OEM coordination. That is sensible engineering, but it also means users and administrators may see uneven behavior across fleets.
Some PCs will receive the new certificates through Windows Update without fuss. Some will need the latest cumulative update plus a firmware update from the manufacturer. Some will show ambiguous states until inventory and management tooling catches up. And some older systems may never receive the firmware-side support needed to make the transition clean.
This is the part of the story where Microsoft’s control ends. Windows Update can deliver operating-system payloads and, on many systems, firmware updates distributed through the same channel. But the Secure Boot trust store ultimately lives in firmware. OEMs decide whether older models get updated firmware defaults, whether enterprise platforms receive backported support, and how clearly they communicate the status of machines that are no longer in active support.
This is where the neat Microsoft narrative of a generational certificate refresh meets the messy reality of PC support. The Windows ecosystem has always sold hardware as long-lived and modular, but firmware support has rarely matched that promise. A desktop can accept more RAM, a new SSD, and a fresh Windows install; it may not receive a firmware trust update if the board vendor has moved on.
For consumers, that will look arbitrary. Two PCs of similar age may behave differently depending on vendor policy, firmware design, and whether the manufacturer shipped updated Secure Boot databases. One may show the 2023 certificate chain after routine updates. Another may remain stuck on 2011 entries even though Windows itself is fully patched.
For enterprises, the issue is less emotional and more expensive. A fleet inventory that says “Windows updated” is not enough. IT teams need to know whether Secure Boot variables in firmware contain the new authorities, whether boot media is compatible, whether recovery workflows still work, and whether any business-critical machines rely on older third-party boot components signed through the 2011 UEFI CA.
A supported Windows 11 system is the easiest case. Keep it updated, keep firmware current, and Microsoft’s phased rollout should handle most of the certificate transition. The hard cases are Windows 10 machines outside extended support, unsupported Windows 11 installations, and systems that sit in the gray zone between “still works” and “still protected.”
Microsoft’s guidance makes clear that support status matters. If a Windows 10 machine is no longer receiving the relevant updates, it should not be assumed to receive the new Secure Boot certificates or future boot-level mitigations. That does not mean the machine bricks itself in late June. It means its security story gets worse at precisely the layer where ordinary antivirus and user caution do the least good.
This is a familiar Microsoft pattern with a firmware twist. The company can say, accurately, that aging platforms cannot be supported forever. Users can say, accurately, that a functioning PC should not become a security orphan because of certificate plumbing most buyers never knew existed. Both statements are true, and neither makes the June deadline less real.
The fact that a Secure Boot servicing change can create visible filesystem artifacts and support threads is a reminder that this transition touches more than a hidden firmware setting. Microsoft is layering scripts, targeting logic, compatibility checks, and documentation around a process that must happen safely across a chaotic hardware universe. That is not the footprint of a trivial update.
It is also a preview of the support burden ahead. As the June and October dates approach, more users will discover that “Secure Boot enabled” is not the same as “Secure Boot certificate state is current.” Some will find they have the right Windows update but an old BIOS. Others will find an OEM page listing their model as out of scope for firmware updates. Still others will be told, correctly but unsatisfyingly, that the device should continue to boot but may not be eligible for every future Secure Boot protection.
Patch Tuesday has trained Windows users to think in terms of monthly fixes. Secure Boot certificate rotation asks them to think in terms of trust chains, firmware variables, and long-term revocation capacity. That is a much harder story to communicate in a notification badge.
That check is useful, but it should not be mistaken for a full enterprise audit. Windows Security can tell a user whether Secure Boot is enabled and may expose relevant update status, but administrators will want scriptable inventory. Microsoft’s Learn guidance includes management approaches for identifying whether the Windows UEFI CA 2023 certificate is present in the Secure Boot signature database and whether remediation has applied.
There is another practical caution: do not casually toggle Secure Boot settings in firmware while trying to “fix” the certificate issue. On some systems, changing Secure Boot mode, restoring factory keys, or flipping between standard and custom modes can alter the trust database. A user who goes spelunking through BIOS menus without a recovery plan can create more confusion than the certificate expiration itself.
For managed environments, the sane path is boring: update Windows, update firmware, inventory certificate state, test recovery media, and verify that critical boot-time software still works. That includes disk encryption workflows, endpoint security tools, hypervisors, Linux dual-boot configurations, and any appliance-like Windows deployments that rely on signed boot components outside the default Microsoft path.
The good news is that existing signed binaries do not necessarily stop working merely because a certificate reaches its expiration date, especially when the relevant trust anchor remains in the firmware database. The bad news is that future signing, revocation, and compatibility paths become more complicated. Distribution maintainers, encryption vendors, rescue-tool creators, and hardware vendors all have to align with the 2023-era authorities.
This is one reason Microsoft has moved cautiously. The Secure Boot databases are a shared surface across operating systems and hardware ecosystems. A revocation or certificate change that looks clean from a Windows-only perspective can break dual-boot systems, recovery environments, or older install media.
Administrators should treat bootable media as part of the audit. A fleet that has current certificates on installed systems but relies on old rescue ISOs, imaging tools, or network boot environments is only half prepared. The worst time to discover that recovery media depends on an obsolete boot path is during an outage.
But it would be a mistake to wait until October. Certificate rotations are infrastructure projects disguised as security updates. They require lead time, especially where firmware, vendor support, and fleet diversity are involved. If a device has not received the 2023 chain by late June, administrators should not assume the problem will solve itself by autumn.
The calendar also creates a communications problem. Users may hear “June 24” and expect catastrophe. When nothing happens, they may dismiss the whole issue as overblown. Then October arrives, and the systems that were quietly unprepared remain quietly unprepared.
Microsoft and OEMs need to be blunt about this: continued booting is not proof of completed remediation. The absence of a boot failure on June 25 should not be treated as a passing grade. The relevant question is whether the device can receive and validate future Secure Boot updates through the new chain.
That outcome would be a technical success, but it would not erase the stranded edge cases. Some older devices will lack OEM firmware updates. Some unsupported Windows installations will sit outside Microsoft’s servicing model. Some business systems will be trapped by application compatibility, regulatory validation, or vendor abandonment. Those machines may keep doing their jobs while accumulating a boot-layer risk that cannot be neatly patched away.
This is where the PC industry’s long tail becomes a security liability. Windows’ hardware diversity is one of its strengths, but Secure Boot depends on coordinated trust management across Microsoft, firmware vendors, OEMs, silicon providers, and software publishers. When that coordination fails, the user at the keyboard sees only a vague message, an unsupported model list, or no warning at all.
The charitable reading is that Microsoft is doing the responsible thing by rotating old certificates before attackers or cryptographic age make them a bigger problem. The less charitable reading is that the industry sold Secure Boot as a durable security foundation without making firmware lifecycle support durable enough to match. The truth is both.
The Boot Chain Is Having Its First Real Aging Crisis
Secure Boot was introduced to make the earliest moments of a PC’s startup less of a free-for-all. Before Windows loads, firmware checks whether the boot components it is about to execute are signed by trusted authorities. That design is meant to stop bootkits, malicious option ROMs, and tampered bootloaders from getting control before the operating system and its security stack are awake.The problem is that trust is not timeless. The certificates that made sense in 2011 were never supposed to be immortal, and Microsoft is now trying to rotate the ecosystem to newer 2023 certificates before the old ones age out. That sounds routine until you remember where these certificates live: in firmware databases, OEM images, deployment media, server platforms, recovery environments, dual-boot setups, and machines that may not have had a BIOS update since the Obama administration.
Three Microsoft-provided certificates form the core of this transition. The Microsoft Corporation KEK CA 2011 expires first on June 24, 2026. The Microsoft UEFI CA 2011 follows days later, with reporting and vendor material placing the date around June 27 for many affected paths. The Microsoft Windows Production PCA 2011, the certificate associated with signing Windows boot manager components, reaches its more consequential deadline on October 19, 2026.
That October date is the one administrators should circle in red, but June is when the floor starts shifting. The Key Exchange Key is what authorizes updates to Secure Boot databases such as the allowed-signature database and the forbidden-signature database. If a device cannot accept new Secure Boot database updates, it cannot participate fully in the next round of boot-layer defense.
Nothing Explodes, Which Is Exactly Why This Could Be Missed
The most important corrective to the panic version of this story is that PCs are not expected to stop booting on June 24. Microsoft’s guidance has repeatedly framed the transition as a security-maintenance problem, not an instant availability disaster. Devices with old certificates may continue to start, run Windows, install ordinary updates, and appear healthy to users who never inspect their firmware trust state.That surface calm is the trap. Boot security is a layer users notice only when it breaks, and Microsoft’s task here is to fix it without producing the very boot failures that would make the public pay attention. If the migration succeeds, most supported Windows 11 systems will quietly receive new certificates through Windows Update and never know anything happened.
But a machine that continues to boot is not necessarily a machine that remains fully protected. Once the relevant Secure Boot certificates expire, systems that did not receive the replacement chain may lose the ability to accept future Secure Boot database updates, including revocations and other mitigations for newly discovered boot-stage attacks. In other words, the machine can remain operational while its boot-defense channel becomes stale.
That distinction matters because Secure Boot is not merely a checkbox used to satisfy Windows 11 setup. It is a living trust mechanism. When Microsoft needs to revoke a vulnerable bootloader or push a database change after a real-world exploit appears, that update path is part of the response.
BlackLotus Made the Abstract Threat Concrete
For years, Secure Boot discussions had a theoretical feel outside firmware and Linux circles. Then BlackLotus showed why the boot chain is not academic. The bootkit targeted the pre-OS environment and forced Microsoft into a long, careful revocation process because fixing a bootloader vulnerability is not like patching Notepad.The BlackLotus episode exposed the operational fragility of boot security. Revoking vulnerable boot components too aggressively can strand legitimate systems. Moving too slowly leaves attackers with a known path beneath the operating system. Microsoft had to stage mitigations, provide management knobs, and give enterprises time to test because the Secure Boot trust chain is both a security boundary and a boot dependency.
The 2026 certificate rollover sits in that same uncomfortable category. Microsoft is not just replacing some paperwork. It is preserving the ability to respond to the next BlackLotus-like problem. A PC that misses the 2023 certificate update may still run today’s Windows, but it may be cut off from tomorrow’s Secure Boot remediation.
That is why the “your PC will still start” reassurance is only half the story. It is true, and it is useful, but it can also lull users into thinking there is no practical consequence. The consequence is deferred risk: the kind that becomes visible only when a new boot-layer vulnerability requires a revocation your machine can no longer consume.
Microsoft Is Trying to Rotate the Foundation While the House Is Occupied
Microsoft began preparing the replacement chain well before the 2026 dates. The 2023 certificates are intended to succeed the 2011-era authorities, and the company has been using Windows Update, firmware channels, and management guidance to push the ecosystem toward the new trust chain. The May 2026 Windows 11 update, KB5089549, continued that work by expanding device targeting for automatic certificate deployment.That targeting language matters. Microsoft is not simply blasting every system with identical Secure Boot changes. The company has to decide which devices are eligible, which firmware configurations can safely accept updates, and which machines need OEM coordination. That is sensible engineering, but it also means users and administrators may see uneven behavior across fleets.
Some PCs will receive the new certificates through Windows Update without fuss. Some will need the latest cumulative update plus a firmware update from the manufacturer. Some will show ambiguous states until inventory and management tooling catches up. And some older systems may never receive the firmware-side support needed to make the transition clean.
This is the part of the story where Microsoft’s control ends. Windows Update can deliver operating-system payloads and, on many systems, firmware updates distributed through the same channel. But the Secure Boot trust store ultimately lives in firmware. OEMs decide whether older models get updated firmware defaults, whether enterprise platforms receive backported support, and how clearly they communicate the status of machines that are no longer in active support.
The Old-PC Problem Is Really an OEM Accountability Problem
The machines most exposed by this transition are not necessarily obscure antiques. They include Windows 10-era PCs still in daily use, workstations kept alive for compatibility reasons, industrial systems, lab machines, point-of-sale boxes, and budget laptops that never received long firmware support in the first place. Many of these devices are perfectly capable of running useful workloads. Their problem is that their security foundation depends on vendor attention that may have expired years ago.This is where the neat Microsoft narrative of a generational certificate refresh meets the messy reality of PC support. The Windows ecosystem has always sold hardware as long-lived and modular, but firmware support has rarely matched that promise. A desktop can accept more RAM, a new SSD, and a fresh Windows install; it may not receive a firmware trust update if the board vendor has moved on.
For consumers, that will look arbitrary. Two PCs of similar age may behave differently depending on vendor policy, firmware design, and whether the manufacturer shipped updated Secure Boot databases. One may show the 2023 certificate chain after routine updates. Another may remain stuck on 2011 entries even though Windows itself is fully patched.
For enterprises, the issue is less emotional and more expensive. A fleet inventory that says “Windows updated” is not enough. IT teams need to know whether Secure Boot variables in firmware contain the new authorities, whether boot media is compatible, whether recovery workflows still work, and whether any business-critical machines rely on older third-party boot components signed through the 2011 UEFI CA.
Windows 10 Turns the Deadline Into a Policy Problem
Windows 10’s position makes the Secure Boot certificate story more politically loaded. The operating system is already at the edge of mainstream life, and Microsoft has been steering users toward Windows 11, paid Extended Security Updates, or replacement hardware. Secure Boot certificate expiration adds another pressure point, especially for machines that cannot meet Windows 11’s hardware requirements.A supported Windows 11 system is the easiest case. Keep it updated, keep firmware current, and Microsoft’s phased rollout should handle most of the certificate transition. The hard cases are Windows 10 machines outside extended support, unsupported Windows 11 installations, and systems that sit in the gray zone between “still works” and “still protected.”
Microsoft’s guidance makes clear that support status matters. If a Windows 10 machine is no longer receiving the relevant updates, it should not be assumed to receive the new Secure Boot certificates or future boot-level mitigations. That does not mean the machine bricks itself in late June. It means its security story gets worse at precisely the layer where ordinary antivirus and user caution do the least good.
This is a familiar Microsoft pattern with a firmware twist. The company can say, accurately, that aging platforms cannot be supported forever. Users can say, accurately, that a functioning PC should not become a security orphan because of certificate plumbing most buyers never knew existed. Both statements are true, and neither makes the June deadline less real.
The May Update Was a Warning Shot, Not Just Another Patch Tuesday
KB5089549 drew attention for the usual Patch Tuesday reasons: installation failures on some Windows 11 systems, user reports of odd behavior, and the appearance of a new SecureBoot folder that caused confusion before Microsoft and others clarified that it was related to certificate servicing. That noise should not obscure the larger point. The May 2026 update was part of Microsoft’s final sprint before the first certificate expiry.The fact that a Secure Boot servicing change can create visible filesystem artifacts and support threads is a reminder that this transition touches more than a hidden firmware setting. Microsoft is layering scripts, targeting logic, compatibility checks, and documentation around a process that must happen safely across a chaotic hardware universe. That is not the footprint of a trivial update.
It is also a preview of the support burden ahead. As the June and October dates approach, more users will discover that “Secure Boot enabled” is not the same as “Secure Boot certificate state is current.” Some will find they have the right Windows update but an old BIOS. Others will find an OEM page listing their model as out of scope for firmware updates. Still others will be told, correctly but unsatisfyingly, that the device should continue to boot but may not be eligible for every future Secure Boot protection.
Patch Tuesday has trained Windows users to think in terms of monthly fixes. Secure Boot certificate rotation asks them to think in terms of trust chains, firmware variables, and long-term revocation capacity. That is a much harder story to communicate in a notification badge.
The Check Is Simple; The Meaning May Not Be
For ordinary users, Microsoft’s recommended first stop is Windows Security. Open Windows Security, go to Device Security, and inspect the Secure Boot section. Microsoft’s support article KB5062710 explains the certificate-expiration issue and the status indicators users may see as the rollout progresses.That check is useful, but it should not be mistaken for a full enterprise audit. Windows Security can tell a user whether Secure Boot is enabled and may expose relevant update status, but administrators will want scriptable inventory. Microsoft’s Learn guidance includes management approaches for identifying whether the Windows UEFI CA 2023 certificate is present in the Secure Boot signature database and whether remediation has applied.
There is another practical caution: do not casually toggle Secure Boot settings in firmware while trying to “fix” the certificate issue. On some systems, changing Secure Boot mode, restoring factory keys, or flipping between standard and custom modes can alter the trust database. A user who goes spelunking through BIOS menus without a recovery plan can create more confusion than the certificate expiration itself.
For managed environments, the sane path is boring: update Windows, update firmware, inventory certificate state, test recovery media, and verify that critical boot-time software still works. That includes disk encryption workflows, endpoint security tools, hypervisors, Linux dual-boot configurations, and any appliance-like Windows deployments that rely on signed boot components outside the default Microsoft path.
Linux, Recovery Media, and Third-Party Bootloaders Complicate the Story
The Windows framing is only part of the Secure Boot ecosystem. The Microsoft UEFI CA has long been used to sign third-party bootloaders and UEFI components, including the shim loaders that make many Linux distributions boot smoothly on Secure Boot-enabled PCs. Any certificate transition at this level inevitably ripples beyond Windows.The good news is that existing signed binaries do not necessarily stop working merely because a certificate reaches its expiration date, especially when the relevant trust anchor remains in the firmware database. The bad news is that future signing, revocation, and compatibility paths become more complicated. Distribution maintainers, encryption vendors, rescue-tool creators, and hardware vendors all have to align with the 2023-era authorities.
This is one reason Microsoft has moved cautiously. The Secure Boot databases are a shared surface across operating systems and hardware ecosystems. A revocation or certificate change that looks clean from a Windows-only perspective can break dual-boot systems, recovery environments, or older install media.
Administrators should treat bootable media as part of the audit. A fleet that has current certificates on installed systems but relies on old rescue ISOs, imaging tools, or network boot environments is only half prepared. The worst time to discover that recovery media depends on an obsolete boot path is during an outage.
The Real Deadline Is October, but June Decides Who Is Ready
The June 24 expiry of the KEK certificate is the opening act because it affects the authority used to sign updates to Secure Boot databases. The June 27 window around the Microsoft UEFI CA matters for third-party UEFI components and non-Windows boot paths. The October 19 expiration of the Windows Production PCA 2011 is the deadline with the broadest symbolic and operational weight because it sits closest to Windows bootloader validation.But it would be a mistake to wait until October. Certificate rotations are infrastructure projects disguised as security updates. They require lead time, especially where firmware, vendor support, and fleet diversity are involved. If a device has not received the 2023 chain by late June, administrators should not assume the problem will solve itself by autumn.
The calendar also creates a communications problem. Users may hear “June 24” and expect catastrophe. When nothing happens, they may dismiss the whole issue as overblown. Then October arrives, and the systems that were quietly unprepared remain quietly unprepared.
Microsoft and OEMs need to be blunt about this: continued booting is not proof of completed remediation. The absence of a boot failure on June 25 should not be treated as a passing grade. The relevant question is whether the device can receive and validate future Secure Boot updates through the new chain.
Microsoft’s Smoothest Outcome Still Leaves Some Machines Behind
If this rollout goes well, the most common story will be anticlimax. Supported Windows 11 PCs will receive the new certificates automatically. Recent Surface and OEM devices will already have firmware support or receive it through normal channels. Many home users will never know the transition happened.That outcome would be a technical success, but it would not erase the stranded edge cases. Some older devices will lack OEM firmware updates. Some unsupported Windows installations will sit outside Microsoft’s servicing model. Some business systems will be trapped by application compatibility, regulatory validation, or vendor abandonment. Those machines may keep doing their jobs while accumulating a boot-layer risk that cannot be neatly patched away.
This is where the PC industry’s long tail becomes a security liability. Windows’ hardware diversity is one of its strengths, but Secure Boot depends on coordinated trust management across Microsoft, firmware vendors, OEMs, silicon providers, and software publishers. When that coordination fails, the user at the keyboard sees only a vague message, an unsupported model list, or no warning at all.
The charitable reading is that Microsoft is doing the responsible thing by rotating old certificates before attackers or cryptographic age make them a bigger problem. The less charitable reading is that the industry sold Secure Boot as a durable security foundation without making firmware lifecycle support durable enough to match. The truth is both.
The Machines That Need Attention Before the Calendar Wins
The practical lesson is not to panic, but to stop treating Secure Boot as a static BIOS checkbox. This certificate rollover is a reminder that boot trust is maintained, not merely enabled. The systems most likely to need human attention are the ones least likely to be checked by casual users.- Devices running supported Windows 11 builds should be brought fully up to date, including the latest cumulative updates and firmware offered through Windows Update or the manufacturer’s support tools.
- Windows 10 systems outside Extended Security Updates should be treated as security-risk exceptions rather than normal endpoints, especially if they remain exposed to sensitive workloads.
- Administrators should verify the presence of the 2023 Secure Boot certificates rather than relying only on whether Secure Boot is enabled.
- Older PCs with no recent OEM firmware should be checked against vendor guidance, because Windows Update alone may not resolve every firmware trust-state problem.
- Recovery media, imaging tools, dual-boot environments, and third-party boot components should be tested before October, not during the first incident after it.
- Users should avoid resetting Secure Boot keys or changing firmware trust modes unless they understand the recovery path and have BitLocker keys and backups available.
References
- Primary source: Notebookcheck
Published: Sun, 24 May 2026 09:29:00 GMT
Windows Secure Boot certificates start expiring June 24
Windows Secure Boot certificates from 2011 expire June 24. Devices without the update will lose boot-level security protections, with no fix for some older PCs.
www.notebookcheck.net
- Official source: learn.microsoft.com
Update Secure Boot Certificates for Windows Devices - Windows Client
Update your Windows devices to maintain Secure Boot protection with 2023 certificates before they expire in June 2026.learn.microsoft.com - Related coverage: notebookcheck.org
Microsoft fija el 2026 como fecha límite para la expiración del certificado Secure Boot
Microsoft ha publicado nuevas directrices advirtiendo de que los certificados Secure Boot de 2011 empiezan a caducar en junio de 2026. Las actualizaciones de Windows están desplegando certificados de sustitución de 2023, y algunos PC requieren actualizaciones de firmware OEM.
www.notebookcheck.org
- Official source: support.microsoft.com
Surface Secure Boot Certificates | Microsoft Support
Secure Boot in UEFI firmware verifies pre-boot software using trusted certificates. Microsoft will update expiring Windows Secure Boot certificates starting June 2026 to maintain device protection.
support.microsoft.com
- Official source: microsoft.com
Prepare your servers for Secure Boot certificate updates | Microsoft Windows Server Blog
The original Secure Boot certificates introduced in 2011 are approaching the end of their planned lifecycle, with expirations beginning in late June 2026.
www.microsoft.com
- Related coverage: windowscentral.com
Microsoft warns Secure Boot certificates will expire soon — what to expect
After 15 years, the original Secure Boot certificates that keep your PC secure during boot are expiring. Here's what you need to know.
www.windowscentral.com
- Related coverage: techspot.com
- Related coverage: tomshardware.com
Microsoft is refreshing Secure Boot certificates to plug security holes before they happen — if you bought a PC last year, you should be set
Be sure to keep Windows 11 systems updated to get refreshed security certificates.www.tomshardware.com
- Related coverage: pcgamer.com
- Related coverage: techradar.com
Microsoft's Secure Boot replacements could be bad news for Windows 10 users
Secure Boot certificate upgrades is bad news for Windows 10www.techradar.com
- Related coverage: tomsguide.com
- Related coverage: cisco.com
- Related coverage: windowslatest.com
Microsoft confirms the new Secure Boot folder in Windows 11 isn't a bug, you don't need to delete it
New “SecureBoot” folder created by Windows 11 KB5089549 is expected behavior for Secure Boot certificates update and not a known issue.
www.windowslatest.com
- Related coverage: pcworld.com
Windows 11's new SecureBoot folder isn't malware. Here's what it does
A new SecureBoot folder appeared in Windows 11 after May's update. Here's what it is, what it does, and why you shouldn't delete it.
www.pcworld.com
- Related coverage: windowsreport.com
- Related coverage: trndigital.com
Microsoft Update: Windows 11 Security Update (KB5089549) Released - TRN Digital
Microsoft has released the May 2026 cumulative update for Windows 11 versions 25H2 and 24H2 (KB5089549), delivering critical security fixes, performance
www.trndigital.com
- Related coverage: softantenna.com
