Microsoft is warning Windows 11 users and IT administrators in May 2026 to update Secure Boot certificates before 2011-era Microsoft certificates begin expiring in June 2026, with additional expirations stretching into October, so supported PCs can keep receiving boot-level security protections. The message is not that millions of machines will suddenly become bricks overnight. The more uncomfortable truth is that Windows’ trust chain is aging out in public, and the cleanup reaches into firmware, OEM support, BitLocker, Linux dual-boot setups, and enterprise change-control calendars. A certificate rollover sounds mundane until it is the thing standing between an operating system and the code it is willing to trust before Windows even starts.
Secure Boot was one of the flashpoints of the Windows 11 launch because Microsoft made it part of the platform’s minimum security baseline, alongside TPM 2.0. To many home users, that requirement looked like a blunt compatibility gate. To Microsoft, it was part of a broader attempt to drag the Windows PC ecosystem toward hardware-backed security, measured boot, virtualization-based defenses, and a world where malware cannot simply slide underneath the operating system before the kernel wakes up.
Now the same security layer is creating a different kind of test. Some Windows devices still rely on Microsoft Secure Boot certificates issued in 2011, and those certificates are reaching the end of their validity period in 2026. Microsoft’s current guidance is to move systems to the newer 2023 Secure Boot certificate authorities so that Windows can continue to validate and update early boot components using modern trust anchors.
That distinction matters. This is not a normal Patch Tuesday update that swaps out a DLL and asks for a reboot. Secure Boot trust lives partly in UEFI firmware variables, using databases that tell the machine which bootloaders, option ROMs, and pre-OS components are allowed to run. Updating that trust store means Windows, firmware, device makers, and enterprise management tools all have to agree on a sequence that does not leave machines in recovery screens at scale.
The Gizchina framing — “update before expiration” — captures the consumer-facing urgency, but it undersells the operational complexity. Microsoft is not just asking Windows 11 users to click “install.” It is asking the PC ecosystem to complete a trust-chain migration that has been theoretically inevitable since 2011 and practically awkward ever since Secure Boot became a default assumption.
The Key Exchange Key, or KEK, authorizes updates to Secure Boot databases. The database known as DB contains allowed signatures, while DBX contains revoked signatures. The Windows Production PCA is tied to signing Windows boot components. The UEFI CA has historically mattered not only to Windows but also to third-party bootloaders and EFI applications, which is why Linux distributions, recovery tools, and certain device utilities are also part of the blast radius.
This is why “the certificate expires next month” is a useful alarm bell but not a complete map. A Windows 11 PC may continue to boot after a certificate expires, and Microsoft has been explicit that regular Windows updates may still install on affected devices. The failure mode is subtler and, for security people, more serious: the device may no longer receive future Secure Boot protections for early boot components.
That is the kind of degradation that does not always announce itself with a crash. A machine can appear healthy, pass casual user inspection, and still be behind on boot-level protections that matter when the next bootkit or Secure Boot bypass emerges. In other words, the risk is less “your laptop dies in June” and more “your laptop’s pre-OS trust chain stops evolving when attackers do not.”
This is where Secure Boot differs from many Windows security features. Microsoft can ship an operating system update, but it cannot pretend every UEFI implementation behaves identically. Firmware has vendor-specific behaviors, board-specific histories, and, in the worst cases, abandoned update channels. The older the device, the more likely the clean Microsoft flow becomes a negotiation with the realities of hardware support.
Microsoft’s guidance points users and administrators toward updated firmware where needed, validation through event logs and registry signals, and staged deployment methods for managed environments. That is bureaucratic language for a simple truth: do not treat a firmware-adjacent security update like a routine browser patch. If Secure Boot updates collide with BitLocker, recovery partitions, old firmware, or unusual boot configurations, the symptom may be a machine that demands a recovery key at precisely the wrong moment.
For most home Windows 11 users on mainstream hardware, the correct advice remains boring. Keep Windows Update current, install firmware updates from the PC maker when offered, and do not disable Secure Boot because a forum post says it avoids a prompt. The machines most likely to suffer are not necessarily the newest Windows 11 systems but the messy middle: older supported hardware, managed fleets with update deferrals, dual-boot rigs, and systems that have been customized just enough to drift away from the happy path.
The Secure Boot certificate rollover gives both sides something to point at. Microsoft can argue that this is precisely why supported, modern, updateable hardware matters. If the boot trust chain needs a coordinated update, the company wants devices that can receive Windows servicing, firmware changes, and OEM validation without heroics. Security is not just a feature; it is a maintenance relationship.
But the critics also have a point. The PC ecosystem’s strength has always been its variety, and Secure Boot imposes a centralized trust structure on that variety. When Microsoft-controlled certificates are involved in whether operating systems and bootloaders run cleanly, a routine expiration becomes a platform event. Windows users may not care about certificate hierarchies, but they will care if a firmware update, boot manager change, or revocation rollout interferes with their machine.
The uncomfortable middle ground is that both are true. Secure Boot has become an essential layer against bootkits and early-boot tampering, and its certificate infrastructure gives Microsoft enormous influence over what the PC regards as trustworthy at startup. The 2026 certificate transition is therefore not a scandal, but it is a reminder that modern PC security is less decentralized than the beige-box mythology suggests.
The most dangerous assumption is that Windows Update alone will silently fix everything everywhere. Microsoft says many devices will receive the updated certificates automatically, depending on configuration and support status. “Many” is not “all,” and in enterprise language, the gap between those two words is where weekend maintenance windows go to die.
Managed environments often suppress, defer, or stage updates for good reasons. They also contain the machines vendors would rather forget: old conference-room PCs, lab systems, kiosks, point-of-sale endpoints, engineering workstations with custom boot chains, and servers that have not been touched because they have not yet failed. Secure Boot certificate status is the sort of inventory attribute many organizations did not historically track because it did not matter every month.
Now it does. Microsoft’s recommended methods include Intune, registry keys, Windows configuration tooling, and Group Policy, but the real work is validation. Administrators need to know not only whether the 2023 certificates are present, but whether the device can continue through the boot process cleanly after the change. BitLocker recovery prompts are not inherently catastrophic, but at fleet scale they are indistinguishable from an outage if users do not have keys and support desks do not have runbooks.
That does not mean the Secure Boot certificate update is “breaking BitLocker” in the usual sloppy sense. It means boot trust changes are exactly the kind of thing disk encryption is designed to notice. From the user’s perspective, however, the nuance will not matter if the laptop suddenly asks for a recovery key during a workday.
This is why the safest consumer advice is practical rather than dramatic. Before applying firmware or Secure Boot-related updates, users should make sure their BitLocker recovery key is backed up and accessible through their Microsoft account or organization. They should avoid interrupting firmware updates. They should not clear Secure Boot keys in firmware setup unless they know exactly what they are doing.
Power users should be even more careful. Dual-boot systems, custom bootloaders, self-signed Secure Boot keys, older Linux shims, and modified boot paths all deserve scrutiny before the certificate transition is treated as routine. The closer a PC is to a standard OEM Windows configuration, the more likely the update path is to be uneventful. The more the boot chain has been customized, the more the user has to become their own platform engineer.
That dependency has always been awkward. Linux can support Secure Boot, and advanced users can enroll their own keys, but the mainstream path has often run through Microsoft’s signing ecosystem. When certificates expire or are replaced, the question is not merely whether Windows Boot Manager is ready. It is whether the third-party boot chain has a valid, trusted path on the firmware in front of it.
The 2023 UEFI CA transition should not be treated as a conspiracy against alternative operating systems. Certificate lifetimes are normal, and old trust anchors have to be retired eventually. But the episode does show how Secure Boot turned the PC’s once-loose boot culture into a managed trust market, where OS vendors, OEMs, and certificate authorities have to coordinate before code can run at the earliest stage of startup.
For WindowsForum readers who keep Linux around for development, rescue work, or principle, the practical lesson is simple: test before the deadline becomes a crisis. Make sure distributions and bootloaders are current. Check whether firmware updates are available. Understand how to temporarily manage Secure Boot only if necessary, and avoid assuming that disabling it is a harmless long-term fix on a Windows 11 machine that relies on other hardware-backed protections.
This is the predictable consequence of tying security posture to servicing eligibility. A PC that bypassed Windows 11 requirements may run the operating system today, and it may appear perfectly usable. But when platform-level trust maintenance depends on Windows Update, OEM firmware, and validated hardware states, the unsupported status becomes more than a watermark in Settings. It can become a reason the machine is outside the intended remediation pipeline.
That does not automatically mean every unsupported or modified system stops booting when June arrives. Microsoft’s own messaging is more measured than that. The more likely issue is that such devices may not receive future Secure Boot protections reliably, or may require manual intervention that Microsoft and the OEM do not support.
This is the hidden cost of running around the Windows 11 gates. The bypass may solve the installer problem, but it does not make the hardware part of Microsoft’s supported security lifecycle. For enthusiasts, that tradeoff may be acceptable. For businesses, schools, clinics, and anyone else with compliance obligations, it should be a red flag.
Modern Windows breaks that model. A secure PC is no longer just a working motherboard, a supported CPU, and enough RAM. It is an actively serviced stack that includes firmware, boot trust, encryption state, cloud-backed recovery keys, OS policy, and vendor-maintained security baselines. The machine is still yours, but its security posture depends on institutions continuing to agree about what it should trust.
That reality is frustrating, but it is not optional. Bootkits and firmware-level attacks exploit the exact zone Secure Boot is meant to defend. The BlackLotus episode and related Secure Boot bypass research showed why Microsoft cannot simply let old boot components remain trusted forever. Revoking vulnerable components and moving to updated certificates is painful because it touches the bedrock of the system.
The alternative is worse. A Secure Boot ecosystem that never retires old trust anchors becomes a museum of yesterday’s assumptions. Attackers love museums when the exhibits still execute.
For home users, the path is mostly familiar: install Windows updates, accept OEM firmware updates from trusted channels, verify BitLocker recovery access, and avoid boot-chain tinkering during the transition window. For IT pros, the work is more formal: inventory certificate status, pilot on mixed hardware, monitor Microsoft’s signals, and document recovery procedures before users discover them under pressure.
The broader lesson is that boot security is not static. A PC that was secure by 2011 standards is not automatically secure by 2026 standards just because it still powers on. Certificate rollover is the maintenance tax that comes with trusting cryptographic roots for fifteen years.
Microsoft’s Oldest Windows 11 Requirement Is Becoming a Servicing Problem
Secure Boot was one of the flashpoints of the Windows 11 launch because Microsoft made it part of the platform’s minimum security baseline, alongside TPM 2.0. To many home users, that requirement looked like a blunt compatibility gate. To Microsoft, it was part of a broader attempt to drag the Windows PC ecosystem toward hardware-backed security, measured boot, virtualization-based defenses, and a world where malware cannot simply slide underneath the operating system before the kernel wakes up.Now the same security layer is creating a different kind of test. Some Windows devices still rely on Microsoft Secure Boot certificates issued in 2011, and those certificates are reaching the end of their validity period in 2026. Microsoft’s current guidance is to move systems to the newer 2023 Secure Boot certificate authorities so that Windows can continue to validate and update early boot components using modern trust anchors.
That distinction matters. This is not a normal Patch Tuesday update that swaps out a DLL and asks for a reboot. Secure Boot trust lives partly in UEFI firmware variables, using databases that tell the machine which bootloaders, option ROMs, and pre-OS components are allowed to run. Updating that trust store means Windows, firmware, device makers, and enterprise management tools all have to agree on a sequence that does not leave machines in recovery screens at scale.
The Gizchina framing — “update before expiration” — captures the consumer-facing urgency, but it undersells the operational complexity. Microsoft is not just asking Windows 11 users to click “install.” It is asking the PC ecosystem to complete a trust-chain migration that has been theoretically inevitable since 2011 and practically awkward ever since Secure Boot became a default assumption.
The Expiration Date Is Real, but the Panic Version Is Too Simple
The 2011 Secure Boot certificates do not all expire at the same instant. Microsoft’s published guidance identifies 2026 as the turnover year, with some certificates beginning to expire in June and others expiring later, including October. The important names include Microsoft Corporation KEK CA 2011, Microsoft UEFI CA 2011, and Microsoft Windows Production PCA 2011, each serving a different role in the Secure Boot trust model.The Key Exchange Key, or KEK, authorizes updates to Secure Boot databases. The database known as DB contains allowed signatures, while DBX contains revoked signatures. The Windows Production PCA is tied to signing Windows boot components. The UEFI CA has historically mattered not only to Windows but also to third-party bootloaders and EFI applications, which is why Linux distributions, recovery tools, and certain device utilities are also part of the blast radius.
This is why “the certificate expires next month” is a useful alarm bell but not a complete map. A Windows 11 PC may continue to boot after a certificate expires, and Microsoft has been explicit that regular Windows updates may still install on affected devices. The failure mode is subtler and, for security people, more serious: the device may no longer receive future Secure Boot protections for early boot components.
That is the kind of degradation that does not always announce itself with a crash. A machine can appear healthy, pass casual user inspection, and still be behind on boot-level protections that matter when the next bootkit or Secure Boot bypass emerges. In other words, the risk is less “your laptop dies in June” and more “your laptop’s pre-OS trust chain stops evolving when attackers do not.”
The 2023 Certificates Are a Security Migration, Not a Cosmetic Refresh
The new 2023 Secure Boot certificates are the replacement trust anchors Microsoft wants devices to use going forward. They are intended to preserve the ability to sign, validate, and revoke boot-level components after the 2011-era certificates age out. For supported Windows 11 machines, the migration can be delivered through Windows Update, though firmware readiness and OEM support can still matter.This is where Secure Boot differs from many Windows security features. Microsoft can ship an operating system update, but it cannot pretend every UEFI implementation behaves identically. Firmware has vendor-specific behaviors, board-specific histories, and, in the worst cases, abandoned update channels. The older the device, the more likely the clean Microsoft flow becomes a negotiation with the realities of hardware support.
Microsoft’s guidance points users and administrators toward updated firmware where needed, validation through event logs and registry signals, and staged deployment methods for managed environments. That is bureaucratic language for a simple truth: do not treat a firmware-adjacent security update like a routine browser patch. If Secure Boot updates collide with BitLocker, recovery partitions, old firmware, or unusual boot configurations, the symptom may be a machine that demands a recovery key at precisely the wrong moment.
For most home Windows 11 users on mainstream hardware, the correct advice remains boring. Keep Windows Update current, install firmware updates from the PC maker when offered, and do not disable Secure Boot because a forum post says it avoids a prompt. The machines most likely to suffer are not necessarily the newest Windows 11 systems but the messy middle: older supported hardware, managed fleets with update deferrals, dual-boot rigs, and systems that have been customized just enough to drift away from the happy path.
Windows 11’s Security Baseline Cuts Both Ways
Microsoft sold Windows 11’s hardware requirements as a security reset. TPM 2.0, Secure Boot, virtualization-based security, and modern CPUs were presented as the price of admission for a safer Windows ecosystem. Critics countered that the policy stranded capable PCs and pushed users toward workarounds that Microsoft would never fully bless.The Secure Boot certificate rollover gives both sides something to point at. Microsoft can argue that this is precisely why supported, modern, updateable hardware matters. If the boot trust chain needs a coordinated update, the company wants devices that can receive Windows servicing, firmware changes, and OEM validation without heroics. Security is not just a feature; it is a maintenance relationship.
But the critics also have a point. The PC ecosystem’s strength has always been its variety, and Secure Boot imposes a centralized trust structure on that variety. When Microsoft-controlled certificates are involved in whether operating systems and bootloaders run cleanly, a routine expiration becomes a platform event. Windows users may not care about certificate hierarchies, but they will care if a firmware update, boot manager change, or revocation rollout interferes with their machine.
The uncomfortable middle ground is that both are true. Secure Boot has become an essential layer against bootkits and early-boot tampering, and its certificate infrastructure gives Microsoft enormous influence over what the PC regards as trustworthy at startup. The 2026 certificate transition is therefore not a scandal, but it is a reminder that modern PC security is less decentralized than the beige-box mythology suggests.
Enterprise IT Does Not Fear the Certificate; It Fears the Reboot
For enterprise administrators, the certificate expiration is less a mystery than a scheduling problem with teeth. Updating Secure Boot certificates across a fleet means identifying affected devices, checking firmware readiness, piloting changes on representative hardware, monitoring event IDs and registry status, and sequencing updates so BitLocker and boot validation do not surprise the help desk.The most dangerous assumption is that Windows Update alone will silently fix everything everywhere. Microsoft says many devices will receive the updated certificates automatically, depending on configuration and support status. “Many” is not “all,” and in enterprise language, the gap between those two words is where weekend maintenance windows go to die.
Managed environments often suppress, defer, or stage updates for good reasons. They also contain the machines vendors would rather forget: old conference-room PCs, lab systems, kiosks, point-of-sale endpoints, engineering workstations with custom boot chains, and servers that have not been touched because they have not yet failed. Secure Boot certificate status is the sort of inventory attribute many organizations did not historically track because it did not matter every month.
Now it does. Microsoft’s recommended methods include Intune, registry keys, Windows configuration tooling, and Group Policy, but the real work is validation. Administrators need to know not only whether the 2023 certificates are present, but whether the device can continue through the boot process cleanly after the change. BitLocker recovery prompts are not inherently catastrophic, but at fleet scale they are indistinguishable from an outage if users do not have keys and support desks do not have runbooks.
The BitLocker Angle Is Where Users Will Actually Notice
For ordinary Windows users, Secure Boot is invisible until it breaks something adjacent. BitLocker is the obvious candidate. Because BitLocker can use measured boot signals to decide whether the machine’s startup environment has changed, firmware and Secure Boot database updates can cause recovery prompts on some systems.That does not mean the Secure Boot certificate update is “breaking BitLocker” in the usual sloppy sense. It means boot trust changes are exactly the kind of thing disk encryption is designed to notice. From the user’s perspective, however, the nuance will not matter if the laptop suddenly asks for a recovery key during a workday.
This is why the safest consumer advice is practical rather than dramatic. Before applying firmware or Secure Boot-related updates, users should make sure their BitLocker recovery key is backed up and accessible through their Microsoft account or organization. They should avoid interrupting firmware updates. They should not clear Secure Boot keys in firmware setup unless they know exactly what they are doing.
Power users should be even more careful. Dual-boot systems, custom bootloaders, self-signed Secure Boot keys, older Linux shims, and modified boot paths all deserve scrutiny before the certificate transition is treated as routine. The closer a PC is to a standard OEM Windows configuration, the more likely the update path is to be uneventful. The more the boot chain has been customized, the more the user has to become their own platform engineer.
Linux and Third-Party Bootloaders Sit in the Shadow of Microsoft’s Trust Chain
The Secure Boot transition is a Windows story, but it is not only a Windows story. Many Linux distributions have historically depended on Microsoft-signed components to boot on Secure Boot-enabled consumer PCs. That arrangement exists because Microsoft’s UEFI CA is widely enrolled by OEMs, making it the practical common denominator for third-party operating systems on Secure Boot hardware.That dependency has always been awkward. Linux can support Secure Boot, and advanced users can enroll their own keys, but the mainstream path has often run through Microsoft’s signing ecosystem. When certificates expire or are replaced, the question is not merely whether Windows Boot Manager is ready. It is whether the third-party boot chain has a valid, trusted path on the firmware in front of it.
The 2023 UEFI CA transition should not be treated as a conspiracy against alternative operating systems. Certificate lifetimes are normal, and old trust anchors have to be retired eventually. But the episode does show how Secure Boot turned the PC’s once-loose boot culture into a managed trust market, where OS vendors, OEMs, and certificate authorities have to coordinate before code can run at the earliest stage of startup.
For WindowsForum readers who keep Linux around for development, rescue work, or principle, the practical lesson is simple: test before the deadline becomes a crisis. Make sure distributions and bootloaders are current. Check whether firmware updates are available. Understand how to temporarily manage Secure Boot only if necessary, and avoid assuming that disabling it is a harmless long-term fix on a Windows 11 machine that relies on other hardware-backed protections.
Unsupported PCs Are Where Microsoft’s Policy Becomes Most Visible
The certificate rollover lands in the same era as Windows 10’s long goodbye and Windows 11’s stricter support model. That timing matters. Supported Windows 11 systems are the intended beneficiaries of Microsoft’s certificate update process. Supported Windows 10 systems, including certain Extended Security Updates scenarios, may also receive relevant updates. Unsupported systems are where the official path gets narrower.This is the predictable consequence of tying security posture to servicing eligibility. A PC that bypassed Windows 11 requirements may run the operating system today, and it may appear perfectly usable. But when platform-level trust maintenance depends on Windows Update, OEM firmware, and validated hardware states, the unsupported status becomes more than a watermark in Settings. It can become a reason the machine is outside the intended remediation pipeline.
That does not automatically mean every unsupported or modified system stops booting when June arrives. Microsoft’s own messaging is more measured than that. The more likely issue is that such devices may not receive future Secure Boot protections reliably, or may require manual intervention that Microsoft and the OEM do not support.
This is the hidden cost of running around the Windows 11 gates. The bypass may solve the installer problem, but it does not make the hardware part of Microsoft’s supported security lifecycle. For enthusiasts, that tradeoff may be acceptable. For businesses, schools, clinics, and anyone else with compliance obligations, it should be a red flag.
Microsoft Is Trying to Retire the Myth of the One-Time PC Purchase
The Secure Boot certificate story is really a story about the changing nature of PC ownership. For decades, users treated the PC as a device that could be bought once, upgraded piecemeal, and kept alive through stubbornness. Firmware existed somewhere below the waterline. Certificates, revocation databases, and measured boot logs were not part of the consumer relationship.Modern Windows breaks that model. A secure PC is no longer just a working motherboard, a supported CPU, and enough RAM. It is an actively serviced stack that includes firmware, boot trust, encryption state, cloud-backed recovery keys, OS policy, and vendor-maintained security baselines. The machine is still yours, but its security posture depends on institutions continuing to agree about what it should trust.
That reality is frustrating, but it is not optional. Bootkits and firmware-level attacks exploit the exact zone Secure Boot is meant to defend. The BlackLotus episode and related Secure Boot bypass research showed why Microsoft cannot simply let old boot components remain trusted forever. Revoking vulnerable components and moving to updated certificates is painful because it touches the bedrock of the system.
The alternative is worse. A Secure Boot ecosystem that never retires old trust anchors becomes a museum of yesterday’s assumptions. Attackers love museums when the exhibits still execute.
The Work Users Should Do Before the Deadline Gets Real
The useful response to Microsoft’s warning is neither panic nor dismissal. Users should treat the Secure Boot certificate transition as a maintenance event that deserves a few minutes of attention now rather than an emergency later. Administrators should treat it as a fleet-readiness project, not a footnote in a cumulative update.For home users, the path is mostly familiar: install Windows updates, accept OEM firmware updates from trusted channels, verify BitLocker recovery access, and avoid boot-chain tinkering during the transition window. For IT pros, the work is more formal: inventory certificate status, pilot on mixed hardware, monitor Microsoft’s signals, and document recovery procedures before users discover them under pressure.
The broader lesson is that boot security is not static. A PC that was secure by 2011 standards is not automatically secure by 2026 standards just because it still powers on. Certificate rollover is the maintenance tax that comes with trusting cryptographic roots for fifteen years.
The June Deadline Is a Trust Test for the Whole Windows Ecosystem
Microsoft’s Secure Boot certificate warning leaves users and administrators with a small number of concrete jobs, none of them glamorous and all of them easier before expiration pressure sets in.- Windows 11 users should install current Windows updates and pay attention to firmware updates offered by their PC maker.
- Administrators should identify machines still using 2011 Secure Boot certificates and validate that 2023 certificates have been applied successfully.
- BitLocker users should confirm their recovery keys are available before firmware or Secure Boot-related changes are deployed.
- Dual-boot and custom-boot users should update bootloaders and test Secure Boot behavior instead of assuming the Windows path covers them.
- Unsupported or heavily modified systems should be treated as higher risk because they may sit outside Microsoft’s intended servicing model.
- The likely failure mode is not instant mass bricking, but a degraded ability to receive future boot-level protections.
References
- Primary source: gizchina.com
Published: Tue, 26 May 2026 01:43:26 GMT
Loading…
www.gizchina.com - Official source: support.microsoft.com
- 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: techspot.com
Loading…
www.techspot.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: dell.com
- Related coverage: windowslatest.com
Loading…
www.windowslatest.com - Related coverage: notebookcheck.net
Microsoft sets 2026 deadline for Secure Boot certificate expiration
Microsoft has issued new guidance warning that 2011 Secure Boot certificates begin expiring in June 2026. Windows updates are rolling out 2023 replacement certificates, with some PCs requiring OEM firmware updates.
www.notebookcheck.net
- 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: tomshardware.com
Loading…
www.tomshardware.com - Related coverage: pcgamer.com
Loading…
www.pcgamer.com - Related coverage: cisco.com
Loading…
www.cisco.com