Microsoft’s original 2011 Secure Boot certificates for Windows PCs begin expiring in June 2026, and Microsoft is rolling out 2023 replacement certificates through Windows Update so supported UEFI systems can keep validating trusted boot software without losing future early-boot security protections. That is the plain answer; the more interesting one is that Microsoft is trying to replace part of the PC trust fabric without making it look like a crisis. For most home users, the right move is boring: keep Windows and firmware updated. For IT departments, dual-boot users, and anyone managing older hardware, this is the kind of quiet platform transition that deserves attention before it becomes an outage story.
Secure Boot is one of those technologies that disappears when it works and becomes infamous when it does not. It sits below Windows, before the operating system has a chance to defend itself, and checks whether the early boot chain is signed by entities the machine already trusts. That chain includes firmware components, boot managers, EFI applications, and the operating system loader.
The certificates at issue date back to the first Windows 8-era Secure Boot rollout. Microsoft’s 2011 certificate authorities helped define which boot software was considered trusted across a huge range of PCs, servers, add-in cards, recovery tools, Linux bootloaders, and enterprise deployment environments. Fifteen years later, those certificates are reaching the end of their planned life.
That matters because Secure Boot is not simply a Windows feature in the user-interface sense. It is part of the UEFI ecosystem, implemented by firmware vendors, exposed through OEM settings screens, consumed by Windows, and depended on by third parties. When a certificate authority ages out, the replacement has to land across a messy hardware estate that was never designed to move in lockstep.
Microsoft’s public message is calibrated to avoid panic. PCs that have not yet received the new certificates are not supposed to suddenly stop booting the day the old certificates expire. The more realistic risk is subtler: systems left on the old trust chain may be unable to receive newer boot-level protections, leaving them in what Microsoft has described elsewhere as a degraded security state.
That distinction is important. This is not Y2K for laptops. It is closer to a root certificate migration for the lowest layer of the Windows security model, and those migrations are only invisible when everyone does the dull work early.
The answer was a chain of trust. Firmware would trust certain keys. Those keys would validate boot components. Boot components would hand off to the operating system. At each stage, unsigned or improperly signed software could be blocked before it gained control.
This model made sense, but it also concentrated enormous importance in certificate authorities that most users never see. The Microsoft Corporation KEK CA 2011, Microsoft UEFI CA 2011, and Microsoft Windows Production PCA 2011 became part of the practical plumbing of the Windows PC ecosystem. They helped sign or authorize updates to Secure Boot databases, third-party EFI applications, and Windows boot components.
The problem is not that the 2011 certificates suddenly became bad. The problem is that certificates have lifetimes, and long-lived trust anchors eventually collide with the calendar. A certificate system that never expires would be its own security failure. A certificate system that expires without a smooth replacement would be an operational failure.
Microsoft’s 2023 certificate set is meant to thread that needle. The new authorities include replacements for Windows boot components and third-party UEFI software, along with certificates used to update the Secure Boot databases themselves. The naming is bureaucratic, but the goal is straightforward: move the ecosystem from the old trust root to the new one while machines are still healthy enough to accept the change.
But the PC boot process is not owned by Windows alone. Secure Boot keys live in UEFI firmware databases, and firmware behavior varies by vendor, model, age, and configuration. Some systems may need OEM firmware updates before Microsoft’s certificate update can be applied cleanly. Others may have Secure Boot disabled, custom keys installed, unusual deployment images, or management policies that affect the rollout.
That is where the story stops being a consumer alert and becomes an IT operations issue. Microsoft can publish guidance and push updates, but it cannot rewrite every firmware implementation shipped over the past decade and a half. The PC market’s strength — its diversity — is also what makes platform-wide security transitions messy.
For home users, the practical instruction is simple: install current Windows updates, install firmware updates offered by the PC manufacturer, and do not treat Secure Boot warnings as cosmetic. For administrators, the work is more formal. Inventory which devices have Secure Boot enabled, which certificates are present, which machines are still on old firmware, and which systems rely on third-party bootloaders or recovery environments.
The awkward truth is that the machines most likely to need attention are also the machines least likely to get it. A 2024 Windows 11 laptop is probably fine. A fleet of older workstations, lab machines, point-of-sale systems, or lightly managed branch-office PCs is where calendar-based security maintenance becomes real.
Microsoft’s engineers have tried to draw the line carefully. Systems that do not receive the new certificates are not expected to lose ordinary Windows security updates solely because the certificate refresh has not landed. The immediate issue is narrower: they may not be able to support newer protections for the earliest parts of the boot process.
That is still meaningful. Bootkits, firmware rootkits, and boot-sector malware are not the most common threats faced by ordinary users, but they are serious precisely because they operate below the level where many defenses are strongest. Secure Boot is not a cure-all, but weakening its update path gives attackers more room in a part of the machine where defenders have fewer tools.
The risk profile also varies by environment. A single home PC behind automatic updates is different from a high-value enterprise endpoint, a developer workstation, a machine used for sensitive credentials, or a system exposed to physical access. For administrators, the question is not whether every unrefreshed machine will be attacked. The question is whether they are willing to leave part of the boot trust chain frozen in 2011 while the rest of the platform moves on.
This is how security debt often looks in practice. Nothing breaks immediately. The dashboard stays mostly green. Then a future mitigation, bootloader update, or incident response requirement assumes a newer trust chain, and the organization discovers that a quiet prerequisite was missed months earlier.
That does not mean such systems are protected in some alternative way. It means they are outside this particular trust model. Older machines that cannot use Secure Boot are not affected by this certificate rollover because they were never using the certificates in the first place.
The gray area is the Compatibility Support Module, or CSM. Some systems use UEFI firmware while presenting a legacy-style boot environment for compatibility. If the underlying machine is still UEFI-capable and Secure Boot-compatible, it may be eligible for the certificate update depending on configuration and vendor support.
This is why blanket advice fails. “Old PC” is not a technical category. A device may be old but UEFI-capable, new but misconfigured, supported by Windows but abandoned by its OEM, or perfectly current except for a disabled firmware setting. The only reliable answer is to check the system’s actual Secure Boot state and update status.
The 2023 certificate transition therefore matters to dual-boot users, recovery vendors, imaging tools, hypervisor environments, and hardware add-ins that load EFI drivers. Anything that expects to run in the Secure Boot path has to be signed in a way the firmware accepts. As the ecosystem moves from the 2011 trust chain to the 2023 one, lagging components can become operational hazards.
This does not mean Microsoft is using certificate expiration to squeeze out Linux, as the more conspiratorial corners of the internet will inevitably suggest. It means Secure Boot’s centralized trust arrangements have consequences. Microsoft is both the steward of a critical Windows security mechanism and, by historical accident and market power, a gatekeeper for a broader PC boot ecosystem.
For enthusiasts, the lesson is to check distribution guidance before assuming a dual-boot setup will behave exactly as before. For organizations, the lesson is broader: validate boot media, recovery images, endpoint encryption tools, and deployment workflows against systems that have already received the new certificates. The bad time to discover that a rescue USB no longer boots is during a ransomware recovery.
The challenge is that Secure Boot status lives across several layers. Windows can report whether Secure Boot is enabled. Firmware determines what keys are installed and how updates are accepted. OEM support channels determine whether older systems receive firmware fixes. Management tools determine whether the organization can see all of this clearly enough to act.
There is also a sequencing problem. Administrators may need to update Windows, update firmware, apply certificate changes, and then validate that boot components still work. In sensitive environments, they may need staged rings, rollback procedures, and test coverage for encrypted disks, virtualization-based security, device guard policies, and third-party preboot agents.
Servers add their own gravity. A laptop that needs a firmware update is annoying. A server that needs a maintenance window, vendor coordination, and application-owner approval is an entirely different proposition. Microsoft’s guidance for Windows Server has emphasized preparation because the cost of improvising at the firmware layer is high.
The irony is that the underlying change is routine in concept. Certificates expire; new ones replace them. But at PC scale, routine cryptography becomes logistics. That is why this story belongs not only in the security column but also in the asset-management column.
Windows Update trained users to expect operating-system servicing. It did not train them to expect the root of boot trust to be renewed like a browser certificate. Firmware updates, meanwhile, still carry a reputation for danger among ordinary users and inconvenience among administrators. Many people update drivers casually but hesitate when the word BIOS appears, even if the machine is actually UEFI.
Microsoft’s challenge is to make this feel normal without making it invisible. If the process is too visible, users panic or postpone. If it is too invisible, administrators miss dependencies and edge cases. The company’s Ask Microsoft Anything session, support documents, and phased rollout suggest it understands that the message has to be both calming and insistent.
The best version of this transition would be boring. Supported devices receive the new certificates, OEM firmware fills the gaps, administrators validate special cases, and June 2026 passes without becoming a folklore date. The worst version would be uneven: consumer PCs mostly glide through while older managed estates, dual-boot systems, and neglected firmware fleets accumulate avoidable risk.
That unevenness is not a Microsoft-only failure if it happens. It is the predictable result of a hardware ecosystem in which security depends on cooperation among Microsoft, OEMs, firmware vendors, peripheral makers, Linux distributions, enterprise administrators, and users who just want the laptop to wake from sleep.
The machines at the edge tell the real story. Windows 10 systems still in use after mainstream support changes, older UEFI devices whose OEMs have slowed firmware releases, specialized workstations with conservative update policies, and dual-boot machines with unusual loaders all deserve a closer look. None of these categories automatically means trouble, but each adds friction.
There is a temptation to read every Windows security transition through the lens of Windows 11 hardware requirements. Secure Boot, TPM 2.0, virtualization-based security, and modern CPU support have all been folded into the broader debate over Microsoft’s definition of a supported PC. The certificate rollover is not the same issue, but it rhymes with it: modern Windows security increasingly assumes modern platform plumbing.
That is uncomfortable for users who keep hardware running for a long time. It is also difficult for organizations with budget cycles longer than Microsoft’s preferred security cadence. The PC industry spent decades celebrating backward compatibility, and now the security model keeps asking whether old compatibility paths are still worth the risk.
Microsoft will say, correctly, that updating certificates is necessary. Critics will say, also with some justification, that ordinary users should not have to understand certificate authorities to keep a PC secure. Both things can be true. The modern PC is a consumer appliance built on infrastructure assumptions that still look very much like enterprise computing.
For enthusiasts, the advice is to document before tinkering. If you dual-boot Linux, use custom Secure Boot keys, rely on unsigned tools, or maintain old recovery media, test those workflows on an updated machine before the deadline becomes urgent. Secure Boot failures are often solvable, but they are much less fun when the only working search device is your phone.
For IT teams, the job is to turn the certificate refresh into a managed change. That means inventory, pilot groups, OEM coordination, and validation of boot-critical software. It also means deciding what to do with devices that cannot or will not receive the necessary firmware support.
The larger lesson is that early-boot security is now a lifecycle commitment. Buying a PC with Secure Boot is not the end of the story. Maintaining the trust chain over the life of the device is part of the cost of depending on it.
Microsoft Is Replacing a Trust Anchor, Not Flipping a Kill Switch
Secure Boot is one of those technologies that disappears when it works and becomes infamous when it does not. It sits below Windows, before the operating system has a chance to defend itself, and checks whether the early boot chain is signed by entities the machine already trusts. That chain includes firmware components, boot managers, EFI applications, and the operating system loader.The certificates at issue date back to the first Windows 8-era Secure Boot rollout. Microsoft’s 2011 certificate authorities helped define which boot software was considered trusted across a huge range of PCs, servers, add-in cards, recovery tools, Linux bootloaders, and enterprise deployment environments. Fifteen years later, those certificates are reaching the end of their planned life.
That matters because Secure Boot is not simply a Windows feature in the user-interface sense. It is part of the UEFI ecosystem, implemented by firmware vendors, exposed through OEM settings screens, consumed by Windows, and depended on by third parties. When a certificate authority ages out, the replacement has to land across a messy hardware estate that was never designed to move in lockstep.
Microsoft’s public message is calibrated to avoid panic. PCs that have not yet received the new certificates are not supposed to suddenly stop booting the day the old certificates expire. The more realistic risk is subtler: systems left on the old trust chain may be unable to receive newer boot-level protections, leaving them in what Microsoft has described elsewhere as a degraded security state.
That distinction is important. This is not Y2K for laptops. It is closer to a root certificate migration for the lowest layer of the Windows security model, and those migrations are only invisible when everyone does the dull work early.
The 2011 Secure Boot Era Is Finally Showing Its Age
Secure Boot arrived in the Windows mainstream at a moment when the PC industry was trying to push malware defense below the operating system. Traditional antivirus could inspect files and processes after Windows loaded, but bootkits and firmware-level malware sought to get there first. If malicious code could insert itself before Windows, it could tamper with the operating system’s view of reality.The answer was a chain of trust. Firmware would trust certain keys. Those keys would validate boot components. Boot components would hand off to the operating system. At each stage, unsigned or improperly signed software could be blocked before it gained control.
This model made sense, but it also concentrated enormous importance in certificate authorities that most users never see. The Microsoft Corporation KEK CA 2011, Microsoft UEFI CA 2011, and Microsoft Windows Production PCA 2011 became part of the practical plumbing of the Windows PC ecosystem. They helped sign or authorize updates to Secure Boot databases, third-party EFI applications, and Windows boot components.
The problem is not that the 2011 certificates suddenly became bad. The problem is that certificates have lifetimes, and long-lived trust anchors eventually collide with the calendar. A certificate system that never expires would be its own security failure. A certificate system that expires without a smooth replacement would be an operational failure.
Microsoft’s 2023 certificate set is meant to thread that needle. The new authorities include replacements for Windows boot components and third-party UEFI software, along with certificates used to update the Secure Boot databases themselves. The naming is bureaucratic, but the goal is straightforward: move the ecosystem from the old trust root to the new one while machines are still healthy enough to accept the change.
Windows Update Can Carry the Keys, but Firmware Still Owns the Door
The comforting part of Microsoft’s plan is that many supported Windows devices can receive the new Secure Boot certificates through Windows Update. That makes the transition look like just another servicing event, not a field trip through BIOS menus. For mainstream Windows 11 machines, especially those manufactured recently, the odds are good that the update either has arrived or will arrive without drama.But the PC boot process is not owned by Windows alone. Secure Boot keys live in UEFI firmware databases, and firmware behavior varies by vendor, model, age, and configuration. Some systems may need OEM firmware updates before Microsoft’s certificate update can be applied cleanly. Others may have Secure Boot disabled, custom keys installed, unusual deployment images, or management policies that affect the rollout.
That is where the story stops being a consumer alert and becomes an IT operations issue. Microsoft can publish guidance and push updates, but it cannot rewrite every firmware implementation shipped over the past decade and a half. The PC market’s strength — its diversity — is also what makes platform-wide security transitions messy.
For home users, the practical instruction is simple: install current Windows updates, install firmware updates offered by the PC manufacturer, and do not treat Secure Boot warnings as cosmetic. For administrators, the work is more formal. Inventory which devices have Secure Boot enabled, which certificates are present, which machines are still on old firmware, and which systems rely on third-party bootloaders or recovery environments.
The awkward truth is that the machines most likely to need attention are also the machines least likely to get it. A 2024 Windows 11 laptop is probably fine. A fleet of older workstations, lab machines, point-of-sale systems, or lightly managed branch-office PCs is where calendar-based security maintenance becomes real.
The PC Probably Will Still Boot, and That Is Exactly Why Some People Will Ignore It
The most dangerous sentence in this story is that unupdated PCs should continue operating normally. It is true, and it is also the kind of truth that encourages postponement. If a deadline does not come with smoke, sparks, and a help-desk ticket, it can be mistaken for a non-event.Microsoft’s engineers have tried to draw the line carefully. Systems that do not receive the new certificates are not expected to lose ordinary Windows security updates solely because the certificate refresh has not landed. The immediate issue is narrower: they may not be able to support newer protections for the earliest parts of the boot process.
That is still meaningful. Bootkits, firmware rootkits, and boot-sector malware are not the most common threats faced by ordinary users, but they are serious precisely because they operate below the level where many defenses are strongest. Secure Boot is not a cure-all, but weakening its update path gives attackers more room in a part of the machine where defenders have fewer tools.
The risk profile also varies by environment. A single home PC behind automatic updates is different from a high-value enterprise endpoint, a developer workstation, a machine used for sensitive credentials, or a system exposed to physical access. For administrators, the question is not whether every unrefreshed machine will be attacked. The question is whether they are willing to leave part of the boot trust chain frozen in 2011 while the rest of the platform moves on.
This is how security debt often looks in practice. Nothing breaks immediately. The dashboard stays mostly green. Then a future mitigation, bootloader update, or incident response requirement assumes a newer trust chain, and the organization discovers that a quiet prerequisite was missed months earlier.
Legacy BIOS Machines Are Outside the Tent
One source of confusion is the distinction between legacy BIOS and UEFI. Secure Boot is a UEFI feature. A machine booting through true legacy BIOS does not participate in Secure Boot at all, so there is no Secure Boot certificate update for Windows to apply.That does not mean such systems are protected in some alternative way. It means they are outside this particular trust model. Older machines that cannot use Secure Boot are not affected by this certificate rollover because they were never using the certificates in the first place.
The gray area is the Compatibility Support Module, or CSM. Some systems use UEFI firmware while presenting a legacy-style boot environment for compatibility. If the underlying machine is still UEFI-capable and Secure Boot-compatible, it may be eligible for the certificate update depending on configuration and vendor support.
This is why blanket advice fails. “Old PC” is not a technical category. A device may be old but UEFI-capable, new but misconfigured, supported by Windows but abandoned by its OEM, or perfectly current except for a disabled firmware setting. The only reliable answer is to check the system’s actual Secure Boot state and update status.
The Linux and Third-Party Bootloader Angle Is Not a Footnote
Secure Boot has always had a complicated relationship with non-Windows operating systems. Many Linux distributions support Secure Boot by relying on boot components signed through Microsoft’s third-party UEFI certificate path. That arrangement is pragmatic, but it also means Microsoft’s certificate lifecycle affects more than Windows.The 2023 certificate transition therefore matters to dual-boot users, recovery vendors, imaging tools, hypervisor environments, and hardware add-ins that load EFI drivers. Anything that expects to run in the Secure Boot path has to be signed in a way the firmware accepts. As the ecosystem moves from the 2011 trust chain to the 2023 one, lagging components can become operational hazards.
This does not mean Microsoft is using certificate expiration to squeeze out Linux, as the more conspiratorial corners of the internet will inevitably suggest. It means Secure Boot’s centralized trust arrangements have consequences. Microsoft is both the steward of a critical Windows security mechanism and, by historical accident and market power, a gatekeeper for a broader PC boot ecosystem.
For enthusiasts, the lesson is to check distribution guidance before assuming a dual-boot setup will behave exactly as before. For organizations, the lesson is broader: validate boot media, recovery images, endpoint encryption tools, and deployment workflows against systems that have already received the new certificates. The bad time to discover that a rescue USB no longer boots is during a ransomware recovery.
The Enterprise Problem Is Inventory, Not Understanding
Most IT teams do not need a lecture on what Secure Boot is. They need to know which devices are exposed, which firmware versions are required, which certificates are installed, and which exceptions will turn into business interruptions. This is less glamorous than a zero-day response, but it is exactly the kind of maintenance that separates managed environments from lucky ones.The challenge is that Secure Boot status lives across several layers. Windows can report whether Secure Boot is enabled. Firmware determines what keys are installed and how updates are accepted. OEM support channels determine whether older systems receive firmware fixes. Management tools determine whether the organization can see all of this clearly enough to act.
There is also a sequencing problem. Administrators may need to update Windows, update firmware, apply certificate changes, and then validate that boot components still work. In sensitive environments, they may need staged rings, rollback procedures, and test coverage for encrypted disks, virtualization-based security, device guard policies, and third-party preboot agents.
Servers add their own gravity. A laptop that needs a firmware update is annoying. A server that needs a maintenance window, vendor coordination, and application-owner approval is an entirely different proposition. Microsoft’s guidance for Windows Server has emphasized preparation because the cost of improvising at the firmware layer is high.
The irony is that the underlying change is routine in concept. Certificates expire; new ones replace them. But at PC scale, routine cryptography becomes logistics. That is why this story belongs not only in the security column but also in the asset-management column.
Microsoft Is Trying to Normalize a Security Maintenance Model the PC Never Fully Had
The certificate rollover is part of a larger shift in how Microsoft treats the Windows boot chain. The company increasingly wants firmware, bootloaders, virtualization security, TPM-backed identity, and cloud-managed policy to behave like a continuously serviced security platform. That is a reasonable goal, but it runs into the history of the PC as a loosely federated hardware ecosystem.Windows Update trained users to expect operating-system servicing. It did not train them to expect the root of boot trust to be renewed like a browser certificate. Firmware updates, meanwhile, still carry a reputation for danger among ordinary users and inconvenience among administrators. Many people update drivers casually but hesitate when the word BIOS appears, even if the machine is actually UEFI.
Microsoft’s challenge is to make this feel normal without making it invisible. If the process is too visible, users panic or postpone. If it is too invisible, administrators miss dependencies and edge cases. The company’s Ask Microsoft Anything session, support documents, and phased rollout suggest it understands that the message has to be both calming and insistent.
The best version of this transition would be boring. Supported devices receive the new certificates, OEM firmware fills the gaps, administrators validate special cases, and June 2026 passes without becoming a folklore date. The worst version would be uneven: consumer PCs mostly glide through while older managed estates, dual-boot systems, and neglected firmware fleets accumulate avoidable risk.
That unevenness is not a Microsoft-only failure if it happens. It is the predictable result of a hardware ecosystem in which security depends on cooperation among Microsoft, OEMs, firmware vendors, peripheral makers, Linux distributions, enterprise administrators, and users who just want the laptop to wake from sleep.
June’s Deadline Rewards the Machines That Were Already Being Maintained
The most reassuring part of this story is also the most revealing. Newer Windows 11 devices, particularly machines manufactured since 2024, are generally expected to have the 2023 certificates already or receive them through normal servicing. In other words, the systems that live on current hardware, current firmware, and current Windows builds are the least interesting ones.The machines at the edge tell the real story. Windows 10 systems still in use after mainstream support changes, older UEFI devices whose OEMs have slowed firmware releases, specialized workstations with conservative update policies, and dual-boot machines with unusual loaders all deserve a closer look. None of these categories automatically means trouble, but each adds friction.
There is a temptation to read every Windows security transition through the lens of Windows 11 hardware requirements. Secure Boot, TPM 2.0, virtualization-based security, and modern CPU support have all been folded into the broader debate over Microsoft’s definition of a supported PC. The certificate rollover is not the same issue, but it rhymes with it: modern Windows security increasingly assumes modern platform plumbing.
That is uncomfortable for users who keep hardware running for a long time. It is also difficult for organizations with budget cycles longer than Microsoft’s preferred security cadence. The PC industry spent decades celebrating backward compatibility, and now the security model keeps asking whether old compatibility paths are still worth the risk.
Microsoft will say, correctly, that updating certificates is necessary. Critics will say, also with some justification, that ordinary users should not have to understand certificate authorities to keep a PC secure. Both things can be true. The modern PC is a consumer appliance built on infrastructure assumptions that still look very much like enterprise computing.
The Practical Advice Is Boring, Which Is Usually a Good Sign
For an individual Windows user, the action plan should not be dramatic. Open Windows Update, install available updates, check the optional firmware or manufacturer updates if your OEM provides them through Windows or its own utility, and confirm Secure Boot status in Windows Security or System Information. If the machine is very old or configured for legacy boot, understand that Secure Boot may not apply at all.For enthusiasts, the advice is to document before tinkering. If you dual-boot Linux, use custom Secure Boot keys, rely on unsigned tools, or maintain old recovery media, test those workflows on an updated machine before the deadline becomes urgent. Secure Boot failures are often solvable, but they are much less fun when the only working search device is your phone.
For IT teams, the job is to turn the certificate refresh into a managed change. That means inventory, pilot groups, OEM coordination, and validation of boot-critical software. It also means deciding what to do with devices that cannot or will not receive the necessary firmware support.
The larger lesson is that early-boot security is now a lifecycle commitment. Buying a PC with Secure Boot is not the end of the story. Maintaining the trust chain over the life of the device is part of the cost of depending on it.
The Certificate Rollover Turns “Keep Your PC Updated” Into Specific Work
Microsoft’s Secure Boot certificate deadline is easy to summarize and easy to underestimate. The useful response is not panic, but neither is indifference. The calendar is forcing Windows users and administrators to verify whether the foundation under the operating system is still being serviced.- Supported Windows PCs should receive the 2023 Secure Boot certificates through Windows Update, but some systems may also require OEM firmware updates.
- Devices that miss the refresh are not expected to immediately stop booting, but they may lose access to newer early-boot security protections.
- True legacy BIOS machines are not eligible for Secure Boot certificate updates because Secure Boot is a UEFI feature.
- Dual-boot systems, recovery media, third-party bootloaders, and enterprise deployment tools should be tested against machines that have received the new certificates.
- Older hardware deserves the most attention because firmware support, configuration drift, and management visibility are often weakest there.
References
- Primary source: TechSpot
Published: Tue, 26 May 2026 16:26:00 GMT
- 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 - 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
- Official source: support.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: windowslatest.com
Microsoft reveals what happens to Windows 11 PCs if you ignore the Secure Boot deadline in June 2026
Microsoft warns Windows 11 PCs without the new Secure Boot certificates may lose future protections, boot security updates, and upgrades.
www.windowslatest.com
- Official source: techcommunity.microsoft.com
Act now: Secure Boot certificates expire in June 2026 - Windows IT Pro Blog
Get tips to prepare for the rollout of updated certificates across your organization.
techcommunity.microsoft.com
- Related coverage: notebookcheck.net
Windows Secure Boot 2026: Microsoft issues final warning over expiring certificates
Microsoft warns that 2011 Secure Boot certificates expire in June 2026. Is your PC ready? We look at the OEM roadmap and how to verify your firmware status.
www.notebookcheck.net
- Related coverage: anavem.com
Check if Your PC Has the New Secure Boot 2023 Certificates (Windows UEFI CA 2023) | Anavem
Verify whether your Windows PC has received the new Secure Boot 2023 certificates (Windows UEFI CA 2023, Microsoft UEFI CA 2023, KEK 2K CA 2023) before the June 2026 expiry deadline. Uses PowerShell, msinfo32, and UEFI firmware checks.www.anavem.com
- Related coverage: pcgamer.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: techradar.com
Linux users are about to face another major Microsoft Secure Boot issue
A signing key supporting Secure Boot on Linux is about to expirewww.techradar.com
- Related coverage: tomsguide.com
- Related coverage: cisco.com
