Microsoft Secure Boot Transition June 2026

Secure Boot is a UEFI firmware security feature that ensures only trusted, digitally signed software can execute during the startup process, blocking bootkits and malware before the operating system loads. The original Microsoft Secure Boot certificates, issued in 2011, will begin expiring in late June 2026. To maintain platform security, the industry is rolling out new 2023 certificates to replace the aging credentials

Any Windows device manufactured since 2012 with Secure Boot enabled is likely in scope. This includes Windows 10 and 11 clients, Windows Server environments, and Virtual Machines (VMs) running on platforms like Hyper-V, VMware, and Azure.

The computer will not crash and will continue to boot normally. Existing software will keep running, but the device will enter a “degraded security state”. This means the system will permanently lose the ability to receive future security updates for the bootloader and will be exposed to new boot-level vulnerabilities. 

While Microsoft is automating this refresh through Windows Update for many modern devices, older systems or specific firmware configurations may require manual BIOS updates from manufacturers. A significant risk exists for users who reset BIOS settings or toggle Secure Boot, as these actions can “forget” the new certificates and trigger a “Secure Boot Violation” that prevents the computer from booting. 

To mitigate this, experts recommend creating Secure Boot recovery media on a USB drive to manually re-inject the 2023 keys if a lockout occurs. Organizations are advised to inventory hardware and validate recovery workflows well before the October 2026 final deadline to ensure continued platform integrity.

Linux distributions frequently rely on a “shim”—a small bootloader signed by Microsoft—to load on PCs with Secure Boot enabled. As part of the transition, Microsoft is providing a specific “Microsoft UEFI CA 2023” certificate designed to sign third-party bootloaders and EFI applications. Alternatively, Linux users can manually enroll their own Machine Owner Keys (MOK) to bypass the need for Microsoft’s certificates entirely.

For most home users and unmanaged business devices, the new certificates will be installed automatically through standard monthly Windows Updates. However, enterprise IT administrators managing fleets with tools like Intune or Configuration Manager will need to explicitly deploy the updates using registry keys, Group Policy Objects (GPOs), or Windows Configuration System (WinCS) scripts.

Yes, older devices or those unsupported by their manufacturer may require a manual firmware (BIOS) update before they can successfully process the Secure Boot updates. If the firmware cannot complete the update and the device is past its End of Service Life, the device may need to be replaced to maintain compliance.

Microsoft is rolling out visual status indicators directly inside the Windows Security App to help users track their device’s readiness. IT admins can check Windows Event Logs, where Event ID 1801 indicates a pending or failed update, and Event ID 1808 confirms the new certificates have been successfully applied to the firmware. Admins can also run the PowerShell command Confirm-SecureBootUEFI to verify if Secure Boot is currently active.

No, it does not affect all virtual machines. The transition only impacts Virtual Machines (VMs) that have Secure Boot enabled in their virtual firmware (UEFI). If your VM is configured to use legacy BIOS instead of EFI, or if Secure Boot is simply turned off, the VM is not impacted at all.

Additionally, the operating system inside the VM does matter. This transition specifically applies to VMs that rely on the Microsoft Secure Boot ecosystem to verify their boot process. Therefore, it affects:

• VMs running Windows and Windows Server (such as Server 2016, 2019, 2022, and Azure VMs).
• Linux distributions that rely on Microsoft’s third-party UEFI “shim” certificate to successfully load while Secure Boot is enabled.

If a VM is running an OS that does not utilize the expiring 2011 Microsoft certificates, it will not be affected. For the VMs that are in scope, the hypervisor providing the virtual environment (such as VMware, Hyper-V, Azure, or Nutanix) must be able to support and process the virtualized firmware updates so the new 2023 certificates can be applied.

No, it is not guaranteed to trigger a lockout. In many real-world tests, particularly on modern hardware with Entra ID-backed key escrow and a properly configured TPM, the transition happens seamlessly without prompting for a recovery key. However, because this behavior is heavily dependent on specific hardware and firmware implementations, IT teams are still strongly advised to verify that all BitLocker recovery keys are safely backed up before initiating a broad rollout

You can manage this via an elevated command prompt or PowerShell.

• To suspend BitLocker: Run the command manage-bde -protectors -disable C: (or %systemdrive%). You can also append -RebootCount 2 to have the system automatically resume protection after two restarts.
• To re-enable BitLocker: Once the Secure Boot changes are complete, run the command manage-bde -protectors -enable C:

It is possible. Applying the new Secure Boot certificates changes the firmware measurements (specifically PCR 7) during the boot process. While modern hardware with Entra ID-backed key escrow usually handles this seamlessly, Microsoft recommends temporarily suspending BitLocker during the update process or thoroughly verifying that all recovery keys are safely backed up before initiating a broad rollout.

You must enter your 48-digit BitLocker recovery key, which may be saved in your Microsoft Account, printed out, or stored in Azure AD/Active Directory if it is a work device. Without this key, there is no supported way to bypass the screen. Once you enter the key and Windows boots normally, you should immediately suspend BitLocker, correct your Secure Boot settings in the BIOS, and then re-enable BitLocker