Microsoft has started to make the Secure Boot certificate transition in Windows more visible, a technical change that many users will see as a simple update, but which affects one of the most sensitive layers of the operating system: everything that happens before Windows starts.
The company had already warned that several Secure Boot certificates issued in 2011 would expire during 2026. That renewal has now moved from being a warning for manufacturers and administrators to appearing in Windows Update and in the Windows Security app. On most modern computers, the process will be automatic. But it is not a minor update: it keeps alive the chain of trust that validates boot loaders, signature databases, revocation lists and mitigations against malware that tries to run before the operating system.
Secure Boot is not exclusive to Windows, although Microsoft plays a central role in the PC ecosystem. It is a UEFI feature that checks digital signatures during startup to prevent untrusted code from running before the operating system. Windows introduced it with Windows 8 to strengthen protection against bootkits and rootkits, threats that try to load before the system itself and hide from traditional defenses.
From Classic BIOS to Verified Boot
To understand why this change matters, it is worth looking back. For decades, PCs started with the traditional BIOS. The firmware initialized the hardware, searched for a boot device and handed control to the operating system boot loader. That model was simple, but it offered little cryptographic protection against early-stage tampering.
UEFI changed that scenario. In addition to modernizing firmware, it introduced Secure Boot as a mechanism to validate every component loaded before the operating system through signatures. The firmware checks boot loaders, EFI applications and Option ROMs before handing over control. If the signatures match the trust database stored in the firmware, the process continues. If not, booting can be blocked.
Windows then adds its own layers. Secure Boot creates the trust path from UEFI to the Windows boot loader, and Trusted Boot continues that protection inside Windows by verifying system boot components and helping antimalware and other defenses start from a reliable state.
The current transition affects that first part of the chain. Microsoft is renewing certificates stored in databases such as KEK and DB. KEK allows updates to Secure Boot databases to be signed, while DB contains certificates that authorize code during startup. There is also DBX, the database of revoked signatures, which blocks vulnerable boot loaders or components.
| Old certificate | Expiration date | New certificate | Purpose |
|---|---|---|---|
| Microsoft Corporation KEK CA 2011 | 24/06/2026 | Microsoft Corporation KEK 2K CA 2023 | Signs updates to DB and DBX |
| Microsoft UEFI CA 2011 | 27/06/2026 | Microsoft UEFI CA 2023 | Signs third-party boot loaders and EFI apps |
| Microsoft UEFI CA 2011 | 27/06/2026 | Microsoft Option ROM UEFI CA 2023 | Signs Option ROMs |
| Microsoft Windows Production PCA 2011 | 19/10/2026 | Windows UEFI CA 2023 | Signs the Windows boot loader |
Microsoft explains that devices that do not receive the new certificates will continue to boot and receive normal Windows updates. The problem is that, over time, they will no longer be able to receive new protections for the early boot process, including Windows Boot Manager updates, Secure Boot databases, revocations or mitigations for low-level vulnerabilities.
What Changes for Windows Users
For home users, the recommendation is not especially dramatic: keep Windows Update enabled, install pending updates and restart when required. Microsoft is delivering the 2023 certificates automatically to consumer devices and to some enterprise devices managed through its own channels. Since April 2026, the Windows Security app has shown more information about the status of these updates under Device security > Secure Boot.
If a green check appears and the message says that Secure Boot is enabled and the certificate updates have been applied, there is nothing else to do. If a yellow badge appears, it may mean that the device is still using old certificates, needs more data to be classified, that the rollout has been paused for compatibility reasons or that an additional update is required. If a red warning appears, the situation deserves more attention: Microsoft associates it with cases where a security update for the boot experience cannot be delivered with the device’s current configuration.
The most important point for many users is not to touch BIOS or UEFI settings without a reason. Resetting keys, changing boot mode, enabling or disabling CSM, modifying TPM settings or manually changing Secure Boot can create problems if the device has an older installation, dual boot or BitLocker enabled.
Before applying a firmware update or changing boot settings, it is advisable to have the BitLocker recovery key available. Not because this transition is expected to break devices in general, but because some firmware, TPM or boot changes can make Windows request that key at startup. On a personal PC, it is usually linked to the Microsoft account; in companies, it may be managed through Intune, Active Directory, Entra ID or other internal tools.
Enterprises: Not Just Another Patch, but a Trust Rotation
In corporate environments, the change should be treated as a platform operation. Microsoft provides specific guidance for IT professionals and organizations, as well as registry keys to manage deployment on devices whose updates are controlled by IT departments. In enterprise deployments, Microsoft refers to the use of a registry bitmask to enable actions such as adding the 2023 certificates, updating KEK and installing the new boot manager.
The difference compared with a monthly patch is that persistent firmware variables are involved. A device may have Windows fully updated, but still depend on OEM firmware for certain default values or Secure Boot reset scenarios. That is why organizations should test by manufacturer, model, firmware version and boot configuration before rolling out the change across the entire fleet.
Virtual machines also need attention. In virtualized environments, Secure Boot depends on the virtual firmware provided by the hypervisor, and the update may come through the virtualization platform vendor, the base image or Windows itself if the long-lived VM allows active Secure Boot variables to be updated. For system administrators, this transition will require reviewing templates, golden images, BitLocker policies, dual-boot systems, corporate Linux deployments and unsupported devices.
Linux: The Awkward Role of Shim and Microsoft Keys
The comparison with Linux is necessary because many x86 computers running Linux also depend, indirectly, on Microsoft’s trust infrastructure. In distributions such as Ubuntu, the firmware first validates shim, a pre-bootloader signed by Microsoft. Then shim contains its own trust database, with Canonical certificates, to validate GRUB and the kernel signed by the distribution.
Red Hat follows a similar approach: shim contains Red Hat’s public key to authenticate GRUB and the kernel, while the kernel includes keys to authenticate drivers and modules. In some scenarios, a Machine Owner Key, or MOK, can also be used to add custom keys, for example when working with modules or versions not signed by the distribution vendor.
This shows an important difference between Windows and Linux on standard PCs. Windows controls its boot chain more directly within the Microsoft-OEM ecosystem. Linux, in order to remain compatible with the PC hardware base built primarily around Windows, has often had to rely on shim signed by Microsoft. That dependency has worked reasonably well, but it means that certificate expiration and rotation also matter for dual-boot users, x86 server administrators and distributions that want to keep Secure Boot enabled.
In advanced Linux setups there is more freedom to manage custom keys, but also more complexity. A user can disable Secure Boot, use MOK, sign modules or control their own chain. That offers flexibility, but increases the operational burden compared with the more guided Windows model.
macOS, Android and ChromeOS: More Closed Chains
Apple follows a different philosophy. On Macs with Apple silicon, secure boot begins with a chain of trust controlled by Apple from Boot ROM and verifies not only operating system code, but also security policies and extensions configured by authorized users. On Intel Macs with the T2 chip, the chip performs a secure boot from Boot ROM, verifies iBoot and continues the chain before going through UEFI.
Apple’s advantage is vertical control. Hardware, firmware, operating system and policies are much more integrated. The disadvantage is that there is less room for open models or heterogeneous configurations like those found in the PC world. For users and companies, that means fewer pieces to coordinate, but also less flexibility.
Android also uses a verified boot philosophy, adapted to mobile devices. Android Verified Boot establishes a chain of trust from a hardware-protected root to the bootloader, boot partition and other verified partitions such as system or vendor. It also includes rollback protection to prevent attackers from installing an older vulnerable version of the system.
ChromeOS follows a similar strong-control approach. Every time a device starts, it performs a check called Verified Boot; if it detects unknown code, the system can repair itself by returning to a previous version. Google’s operating system combines this with a read-only system model and more integrated recovery.
| System | Secure boot approach | Advantage | Trade-off |
| Windows on UEFI PCs | Secure Boot with Microsoft/OEM certificates and updates through Windows Update | Broad compatibility and automatic deployment | Dependence on OEM firmware and key state |
| Linux on UEFI PCs | Microsoft-signed shim, distribution keys and MOK | Flexibility and user control | More complexity and partial dependence on Microsoft keys |
| macOS on Apple silicon | Integrated chain from Boot ROM and Apple policies | Vertical control and less fragmentation | Less openness for non-standard configurations |
| Android | Verified Boot with hardware root and rollback protection | Strong protection on mobile devices | Depends on manufacturer and device support |
| ChromeOS | Verified Boot with automatic repair | Simple recovery and closed model | Less freedom than a general-purpose PC |
The Lesson: Boot Is No Longer a Formality
The Secure Boot renewal in Windows should not be seen as a scare, but it should not be treated as a minor update either. It is a trust rotation in a layer users normally do not see and that only attracts attention when something goes wrong. Modern security does not start when the desktop appears; it starts when the firmware decides which code is allowed to run.
The comparison with other systems leaves a clear idea. Windows tries to balance security, a huge installed base and a wide diversity of manufacturers. Linux maintains more freedom, but pays the price of managing shim, MOK and different signing policies. Apple, Android and ChromeOS protect more through closed and integrated chains, while reducing the user’s room for intervention.
For Windows users, the practical answer remains simple: update, restart, check Windows Security and do not touch UEFI without a reason. For administrators, the answer is more serious: inventory, model-by-model testing, up-to-date firmware, BitLocker control, VM review and status monitoring.
Secure Boot does not make a system invulnerable. But without a trusted boot chain, everything that comes afterward is built on a weaker foundation. That is why Microsoft is renewing certificates before they expire, and why this transition deserves attention in any operating systems publication.
Frequently Asked Questions
What is Microsoft changing in Secure Boot?
It is renewing 2011 certificates that expire in 2026 and replacing them with 2023 certificates to maintain the Secure Boot chain of trust.
Will Windows stop booting if Secure Boot is not updated?
Not immediately. Microsoft says devices will continue to boot and receive normal updates, but they will lose the ability to receive new early boot protections.
What is the difference between Secure Boot and Trusted Boot?
Secure Boot validates components before Windows starts, from UEFI. Trusted Boot continues verification inside the Windows boot process.
Why does this also affect Linux?
Many Linux distributions use shim, a Microsoft-signed pre-bootloader, to boot with Secure Boot enabled on PCs originally designed around Windows.
Does macOS work like Windows?
No. On Apple silicon and Macs with T2, Apple controls more of the boot chain through its own hardware and firmware, with tighter integration than on PCs.