Microsoft Clarifies June 2026 Secure Boot Deadline as Certificate Expiration Nears

Last month, Microsoft explained what would happen if PCs missed the June 2026 Secure Boot update deadline, and the company has now provided additional guidance for IT administrators preparing for the certificate transition, clarifying that devices will continue functioning even if they have not completed updates before the June 24, 2026 expiration of the original Secure Boot Key Exchange Key (KEK) certificate.

The company addressed the issue during its second live Ask Microsoft Anything (AMA) session focused on Secure Boot certificate expiration, expanding on information it first shared last month. According to details reported by Windows Latest, the session centered on questions from enterprise customers and IT administrators responsible for managing large Windows deployments.

June 2026 Is Not a Hard Deadline

One of the key takeaways from the session was Microsoft’s reassurance that June 24, 2026 is not a hard stop for Secure Boot functionality.

The company emphasized that devices will not suddenly stop booting when the original Microsoft Secure Boot KEK certificate expires. Existing update mechanisms, including registry-based deployment methods, scheduled tasks, and Secure Boot database (DB) updates, will continue to function after the expiration date.

However, Microsoft noted that the expiration will affect its ability to sign new DBX revocation payloads using the older certificate. As a result, devices that do not receive the newer KEK certificate may eventually miss future revocation updates, potentially leaving them less secure over time.

Microsoft also pointed out that the Secure Boot DB certificate remains valid until October 2026, providing additional time to sign and distribute updated boot managers.

More Devices Expected to Receive Automatic Updates

Microsoft said the June Patch Tuesday release should move most mainstream devices into what it calls the “high-confidence” deployment category.

The confidence rating is determined by several factors, including device model, firmware version, and firmware release date. Devices classified as high confidence can receive Secure Boot updates automatically through Intune.

For devices that remain outside the high-confidence category, administrators may need to manually enable deployment using registry settings or Intune policies.

Microsoft advised organizations not to delay deployment while waiting for every device to reach high-confidence status.

Recommended Deployment Steps

The company recommends that administrators:

• Use Intune monitoring reports to verify Secure Boot update status.
• Test one representative device from each hardware model or firmware variation.
• Prioritize active and accessible devices during testing.
• Review OEM firmware updates before forcing deployment.
• Use live Intune reporting or Microsoft’s GitHub CSV data instead of outdated exported spreadsheets.

Firmware Compatibility Remains Critical

Devices marked as “temporarily paused” generally require firmware updates from their hardware manufacturers before Secure Boot updates can be safely applied.

Microsoft warned administrators against forcing updates on paused devices without first confirming that the necessary firmware fixes are available. Once firmware updates are installed, devices may move into a different deployment bucket and receive a new confidence rating.

The company stressed that firmware compatibility remains one of the most important factors in a successful Secure Boot migration.

Secure Boot Must Be Enabled During Updates

Microsoft also reminded administrators that Secure Boot certificates cannot be updated while Secure Boot is disabled.

Re-enabling Secure Boot after certificate updates have been applied can create compatibility issues if the firmware trust database does not match the installed boot manager.

For example, a device running a boot manager signed with the newer 2023 certificate may fail to boot if its firmware trusts only the older 2011 certificate.

Because of this risk, Microsoft recommends carefully planning update sequencing across managed environments.

Virtual Machines and PXE Boot Require Special Attention

The company provided additional guidance for virtualized environments.

Azure Generation 2 virtual machines configured with Secure Launch or Trusted Launch should already include the newer 2023 certificate configuration. Generation 1 virtual machines do not support Secure Boot and are therefore unaffected by the certificate transition.

PXE boot environments require additional planning. Microsoft advised organizations not to deploy PXE bootloaders signed with the 2023 certificate until all target devices trust the newer certificate.

The company also warned that some newer hardware may ship with only 2023 certificates installed, which could prevent those systems from booting older PXE media signed with the 2011 certificate.

Event Logs Can Help Troubleshoot Issues

For troubleshooting Secure Boot deployment problems, Microsoft recommends using TPM-WMI event logs alongside registry keys.

The company highlighted several important event IDs:

Event ID	Description
1801	Device requires the update, but Microsoft needs additional telemetry data.
1802	Typically indicates a firmware-related issue.
1803	May signal a failure while applying the KEK update.

Microsoft noted that Windows 10, Windows 11, and older Windows Server releases all use the same Secure Boot update mechanism. However, older server environments may require more manual intervention because Microsoft often has less telemetry data available for those systems.

Microsoft Urges Organizations to Begin Testing

Microsoft’s primary recommendation remains unchanged: organizations should thoroughly test Secure Boot certificate updates before deploying them across large fleets of devices.

Administrators are encouraged to validate firmware compatibility, monitor deployment progress through Intune, and ensure Secure Boot remains enabled throughout the migration process.

Documentation, deployment scripts, OEM firmware resources, and troubleshooting guidance are available through Microsoft’s Secure Boot migration portal at aka.ms/GetSecureBoot.

In related developments, Microsoft recently refreshed Windows 11 ISO files with updated Microsoft Defender definitions. The company has also moved Endpoint Detection and Response (EDR) updates to the Microsoft Update Service.