As the expiration date of the original Microsoft Secure Boot KEK certificate approaches on June 24, 2026, Microsoft has taken proactive measures to address the myriad of inquiries from IT administrators and enterprise customers. On June 4, the company hosted its second live “Ask Microsoft Anything” session, featuring a panel of experts including Arden White, Kevin Sullivan, Richard Powell, Scott Shell, and Jason Sandys.
During the session, Microsoft delved into the implications of the impending deadline, particularly for enterprise rollouts, virtual machines, and PXE boot scenarios. The discussion aimed to clarify what IT administrators should prioritize in the coming days.
June 24 is not a hard stop for Secure Boot, but what changes that day is important
The most pressing concern addressed was whether June 24 marks a definitive end to the registry-based manual rollout method. Scott Shell clarified that it does not. The expiration specifically pertains to the KEK key, while the DB key, a separate certificate, remains valid until October. Importantly, all previously signed update payloads will continue to function as they have. “There is no end date where the registry key and the update stop working,” Shell confirmed.
However, after June 24, Microsoft will no longer be able to sign new DBX payloads, which are essential for revoking compromised bootloaders. Devices lacking the new KEK may miss future revocations, leading to a gradual decline in security, though they will not cease to boot immediately.
The June update will push the vast majority of mainstream devices to high confidence
One of the more optimistic takeaways from the session was the anticipated impact of the June Patch Tuesday update. The team indicated that most systems for which Microsoft has diagnostic data will be classified as high confidence post-update. Kevin Sullivan elaborated that device classification is nuanced, taking into account firmware versions and dates, meaning that even identical models may fall into different buckets.
For accurate tracking, IT administrators are encouraged to utilize the Intune monitoring report, which provides insights into device status and necessary updates. Jason Sandys noted that this report, along with a PowerShell remediation script, serves as a vital tool for managing device compliance.
What “temporarily paused” means in Secure Boot, and what to do about it
Concerns were raised regarding devices stuck in a “temporarily paused” status, especially with the deadline looming. The panel explained that this status indicates a required firmware update from the OEM due to detected compatibility issues. Rather than risk a failed update, the system pauses until the necessary firmware is applied.
Scott Shell emphasized the importance of tracking these changes accurately. If a device transitions to a new bucket following a firmware update, the old bucket remains unchanged. Thus, relying on outdated data could lead to misinterpretations of device status. The aka.ms/GetSecureBoot landing page offers resources for locating OEM firmware updates, which should be checked before attempting any manual interventions.
Don’t wait for high confidence if you are already managing your own rollout
For administrators who have been delaying manual rollouts while awaiting high confidence status, the team advised against further procrastination. Devices classified as high confidence will be automatically managed by Intune, but those outside this classification require proactive measures.
The recommended approach involves identifying devices that have not yet received updates and initiating the update process for them. Scott Shell advised prioritizing devices that are active and accessible, while avoiding those belonging to remote employees or those likely to be powered off for extended periods.
Secure Boot off? You cannot update certificates, and turning them on later is risky
In response to inquiries about machines with Secure Boot disabled, Scott Shell provided a clear warning: when Secure Boot is off, Microsoft cannot update the certificates. This leaves these machines vulnerable to attacks that Secure Boot is designed to prevent. Furthermore, re-enabling Secure Boot later poses risks if the firmware’s trust database does not match the installed boot manager.
For Azure Gen 2 VMs with secure launch enabled, Microsoft has updated the default certificate set to 2023, enhancing their security posture. However, Gen 1 VMs, which are based on older BIOS technology, do not support Secure Boot.
What determines whether a device is in the high confidence bucket to get Secure Boot certificates
Questions arose regarding why older models received high confidence classification more rapidly than newer ones. The explanation lies in the statistical requirements for confidence; smaller populations of older models can be validated more quickly. In contrast, larger populations of newer models require more telemetry data to ensure a safe rollout across various firmware variants.
PXE boot environments need careful sequencing
For those managing PXE boot infrastructure, Scott Shell confirmed that machines with only the 2011 certificate can still boot PXE images signed by that certificate, as long as it is not in the DBX revocation list. However, caution is advised: updating the PXE bootloader to one signed by the 2023 certificate should only occur after all machines in the environment have the new certificate in their trust database.
Windows 10 and older OS versions get the same update mechanism
It was clarified that the Secure Boot update behavior is consistent across Windows 10 and Windows 11, as well as Windows Server 2012 and 2012 R2. The main difference lies in the telemetry reporting of older servers, which may not have been classified as high confidence due to limited data.
Event logs and registry keys are your best diagnostic tools
Throughout the session, the panel emphasized the importance of event log entries as diagnostic tools. Key entries to monitor include:
- 1801: Indicates the device is being tracked and needs an update, but more data is required.
- 1802: Points to a specific firmware-level issue, often the reason for a temporarily paused state.
- 1803: Shows a failure to apply the KEK due to the absence of a PK-signed KEK payload.
For virtual machines with invalid or unsigned Platform Keys, the 1803 event can help identify issues that need resolution. If the KEK update fails but the 2023 DB certificates are present, the device may still function securely, albeit without future DBX revocation updates until the KEK is updated.
For comprehensive guidance, Microsoft directs users to aka.ms/GetSecureBoot, which contains diagnostic scripts, OEM firmware links, and detailed documentation for both home users and enterprise IT. The session underscored the importance of a cautious approach, especially given the potential for complications arising from firmware issues and the urgency of the Secure Boot deadline.
