With the June 24, 2026, expiration of the original Microsoft Secure Boot KEK certificate now days away, Microsoft held its second live “Ask Microsoft Anything” session on June 4 to address the flood of questions still coming in from IT administrators and enterprise customers.
The panel included Arden White (principal security engineer, Windows Servicing and Delivery), Kevin Sullivan (Windows ecosystem and commercial engagement), Richard Powell (engineering team), Scott Shell (enterprise and security, secure boot architecture and design), and Jason Sandys from the Intune product group.
If you missed our coverage of the first AMA, Microsoft already revealed what happens to Windows 11 PCs if you ignore the Secure Boot deadline. This second session went deeper into specifics that the first one left unanswered, particularly around enterprise rollouts, virtual machines, PXE boot scenarios, temporarily paused device buckets, and what IT admins should do in the next few days.
Here is our detailed look at everything that came out of Microsoft’s Secure Boot AMA session.
June 24 is not a hard stop for Secure Boot, but what changes that day is important
The most pressing question was whether June 24, the expiration date of the Microsoft Corporation KEK CA 2011 certificate, is a hard deadline after which the registry-based manual rollout method stops working. Scott Shell’s answer is that it is not.
The June 24 date applies specifically to the KEK key expiration. The DB key, which is a separate certificate, does not expire until October. And critically, all the update payloads that have already been signed, the DB update, the registry key and scheduled task mechanism, will continue to work exactly as they did before that date. “There is no end date where the registry key and the update stop working,” Shell confirmed.
What does change after June 24 is Microsoft’s ability to sign new DBX payloads, which are the revocation updates that blacklist compromised or malicious bootloaders. If a device does not have the new KEK installed, it may miss some of those future revocations, which means the device will gradually become less secure over time as Microsoft discovers and acts on new bootloader vulnerabilities, but it will not suddenly stop booting on the 25th.
The DB key does not expire until October, so Microsoft expects to sign a few more boot managers with that key in the meantime.
The June update will push the vast majority of mainstream devices to high confidence
One of the more encouraging points from the session was about what the June Patch Tuesday update will do for device coverage. The team confirmed that after the June update, the vast majority of systems that Microsoft has diagnostic data for will be classified as high confidence. Not all of them, but most.
Kevin Sullivan added useful context here. When Microsoft talks about device buckets, it is not simply grouping by manufacturer and model name. The confidence assessment goes down to the firmware version and the firmware date. So a mainstream PC that is otherwise identical may sit in a different bucket than a unit with a different BIOS revision, which means IT admins cannot assume that because one unit of a particular model is high confidence, every unit of that model is.
The Intune monitoring report, updated in mid-May, is the recommended way to see exactly where devices stand. Jason from the Intune team noted that the report shows whether a device is in the high confidence bucket, whether the update has already been applied, and which devices may still need manual intervention. The report and a companion PowerShell remediation script are both available, and they effectively do the same job through two different access paths.
What “temporarily paused” means in Secure Boot, and what to do about it
A number of enterprise customers said they were seeing devices stuck in a “temporarily paused” bucket, which is understandably alarming when the deadline is days away. The team’s explanation is that this status always points in the direction that a firmware update from the OEM is needed.
The mechanism behind this is that Microsoft’s rollout system sometimes detects a compatibility issue at the firmware level that would make applying the certificates risky on a particular device. Rather than risk a failed update, the system pauses. The OEM is expected to issue a firmware update that resolves the underlying issue. Once that firmware update is applied, the device moves into a new bucket because the firmware version has changed, and the new combination gets its own classification.
Scott Shell made an important point about how to track this. If you take a firmware update and the device moves to a new bucket, the old bucket does not change. Looking at a spreadsheet you exported last month and checking whether the old bucket transitioned will give you the wrong answer. The bucket itself stays paused forever, because that firmware version was paused. The device has simply moved to a new bucket, which may be under observation or high confidence. Checking live data from Intune or the GitHub CSV is the only reliable way to track actual device status.
The aka.ms/GetSecureBoot landing page includes a list of OEM support pages where firmware updates can be located for most major manufacturers. It is worth checking that first before attempting any manual overrides on a paused device.
For context, this issue is not entirely surprising. Windows Latest reported earlier this year that Secure Boot 2023 updates were failing across some PCs because of firmware incompatibilities, and the problem turned out to be wider than initially apparent. Shortly after, OEMs admitted that their own updates were bricking Windows 11 machines with BitLocker loops and BSODs as a direct result of rushing out firmware to meet the Secure Boot deadline. This is exactly why Microsoft’s phased rollout exists and why the temporarily paused status is a warning, not something to force through without a firmware update first.
Don’t wait for high confidence if you are already managing your own rollout
One of the clearest pieces of guidance from the session was aimed at admins who have been holding off on manual rollouts while waiting for their devices to reach high confidence. The team said do not wait any longer.
If a device is in the high confidence bucket, Intune will handle it automatically. No admin action is needed for those devices. But for anything that is not in high confidence, white box machines, less common OEM configurations, older servers, or units for which Microsoft has limited telemetry data, the recommended approach is to set the registry value or equivalent Intune settings catalog policy to force the update process to run.
The workflow the team described for Intune-managed environments is to pull the monitoring report, identify devices that have not yet applied the update, pick one representative device of each model or firmware variant, push the policy, and wait for it to show a successful state before expanding the rollout. Scott Shell’s advice on which devices to pick first was to prioritize devices that are active and accessible, avoid picking machines belonging to remote employees who are hard to contact, and do not pick devices that might get powered off for a week with no telemetry coming back.
As Jason Sandys from Intune mentioned, “If Microsoft has already put it in the high confidence database, it’s handled. But there are potential onesie twosies, white boxes and other things that have no way of making themselves known to us, so you are going to need to force that.”
Microsoft also encouraged admins to note that doing the manual rollout on devices that are not yet in the high confidence database helps Microsoft. The telemetry from successful updates gets fed back into the confidence system, which helps other organizations that have the same uncommon device.
Secure Boot off? You cannot update certificates, and turning them on later is risky
A question from someone managing Azure Virtual Desktop, Azure VMs, and Intune-managed endpoints asked what happens to machines where Secure Boot is currently turned off. The answer from Scott Shell was unambiguous.
When Secure Boot is disabled, Microsoft cannot update the certificates. The firmware simply will not allow it, and there is nothing Microsoft can do about that at the operating system level. These machines are already inherently vulnerable to the category of attacks that Secure Boot exists to prevent, and that situation does not change as a result of the certificate expiration.
The trickier question is what happens when you decide to turn Secure Boot back on later. Shell walked through the problem, saying that if a machine has Secure Boot disabled, Microsoft will still update the boot manager to the 2023-signed version. That boot manager is ready to run. But when you go to enable Secure Boot in UEFI, the certificate set that Secure Boot enforces has to match what is signed on the boot manager. If the firmware’s trust database only contains the 2011 certificate but the installed boot manager is signed by the 2023 certificate, the machine will not boot.
Recovering from that requires manually installing the 2023 certificate into the firmware, which is documented at aka.ms/GetSecureBoot. Shell advised anyone planning to turn Secure Boot on for the first time or re-enable it to test carefully first, because the failure mode is a machine that does not boot, and you need to have a hands-on keyboard to fix it.
For Azure Gen 2 VMs with secure launch or trusted launch enabled, Microsoft has already updated the default certificate set to 2023, so those should be in a better position by default. Gen 1 VMs are BIOS-era machines that cannot support Secure Boot at all.
What determines whether a device is in the high confidence bucket to get Secure Boot certificates
The team was asked why older models were getting high confidence classification faster than newer, supposedly mainstream ones. The explanation is counterintuitive but makes sense once you understand how the confidence system works.
Older models have smaller populations. A smaller pool of devices gets validated as high confidence more quickly because the statistical requirement for confidence is met sooner. Very large populations of newer, widely deployed models take longer because Microsoft needs enough successful update telemetry to be statistically confident that the rollout is safe across the full distribution of that device’s firmware variants.
The good news is that the June update is expected to dramatically expand the high-confidence bucket for many of those common newer models. The team expressed confidence that a significant addition of devices would follow the June Patch Tuesday release.
PXE boot environments need careful sequencing
One of the more technically precise questions in the session came from someone managing PXE boot infrastructure. The question asked whether PXE boot would still work for machines that have only the 2011 certificate, as long as that certificate is not yet in the DBX revocation list.
Scott Shell called it “a perfect question.” The answer is yes. As long as the 2011 certificate is not in DBX, machines that only have the 2011 certificate will continue to boot PXE images signed by that certificate. The expiration date of the certificate does not affect whether previously signed content is trusted. What matters is the signing timestamp.
The practical advice for PXE environments is not to update the PXE bootloader to one signed by the 2023 certificate until all machines in the environment that will boot from that PXE server have the 2023 certificate in their trust database. If you update the PXE bootloader before all machines have the new cert, machines that only trust the 2011 signature will fail to boot from PXE.
Kevin Sullivan flagged another thing to watch out for here. New devices are starting to ship from some OEMs with only the 2023 certificates, not both. Those machines will not be able to boot PXE media signed by the 2011 certificate. If you are imaging new hardware using older PXE bootloaders, you may already be hitting this issue. During the transition period, having two USB sticks, one signed by 2011 and one by 2023, may be the most pragmatic approach for organizations that need to handle both.
Windows 10 and older OS versions get the same update mechanism
A user asked whether the Secure Boot update behavior differs between Windows 10 under ESU and Windows 11. The answer is no. The underlying code that handles the certificate updates is identical across both. The same task that runs on Windows 11 also runs on Windows 10 and even on Windows Server 2012 and 2012 R2.
The one change for older servers is that many of them either did not ship with Secure Boot enabled by default or are running with configurations that do not report telemetry data. This means they are less likely to have been classified as high confidence, not because of any OS difference, but because Microsoft has less data on them. For those devices, the manual registry key approach is the recommended path.
Event logs and registry keys are your best diagnostic tools
Throughout the session, the team repeatedly pointed to event log entries as the most reliable way to understand what is happening on a specific device. The relevant event source is the TPM-WMI event log, and the entries to look for are numbered:
- 1801 indicates that the device is being tracked and the update is needed, but more data is required.
- 1802 points to a specific firmware-level issue, usually the reason a device is in a temporarily paused state.
- 1803 can show a failure to apply the KEK because there is no PK-signed KEK payload available.
For virtual machines where the Platform Key was set to an invalid or unsigned value, the 1803 event will help identify that the KEK cannot be updated, and the path forward is working with the hypervisor vendor to correct the PK configuration before retrying.
If KEK is the only thing that failed, but the 2023 DB certificates are already present, the device may still be in an acceptable state. The team’s guidance was to verify that both the KEK and the DB certificates are the 2023 versions. If the 2023 DB certificates are there, the device can still function securely, but it will not receive future DBX revocation updates until the KEK is also updated.
For everything mentioned in the session, Microsoft’s central resource is aka.ms/GetSecureBoot, which has the full playbook, diagnostic scripts, OEM firmware links, and detailed documentation for both home users and enterprise IT. The Intune monitoring report for Secure Boot is at the link that was shared during the session. Scripts shipped with the May update are in the System32 folder and also documented on that same page.
Given that HP’s firmware issues and wider Secure Boot failures have already shown how quickly this can go sideways, Microsoft’s “test one first” advice is the safest path to getting a large fleet updated before the KEK stops being useful for signing future security revocations. Microsoft also reiterated that the Driver Quality Initiative it announced at WinHEC 2026 is part of a more comprehensive commitment to prevent these kinds of ecosystem-wide disruptions in the future, though for now the Secure Boot deadline remains immediate.
