Welcome to the Secure Boot AMA. Let’s get started! Our panelists and in-chat SMEs are ready to answer your questions. Drop your questions in the comments below—we’re looking forward to hearing from you!

I've got questions about ConfigMgr pxe booting. If we update our boot.wim to have the 2023 cert will systems that are not updated still be able to pxe boot? In other words, which order should we be going at this? Update systems first or update the pxe boot.wim?

Can we get direction how and when we should update our SCCM PXE non-wds environment during this process?       
Step 1 – Firmware Readiness Inventory and keep all the devices up to date OEM Firmware
Step 2 - SCCM ADK Upgrade to latest version and Dual Boot Image Configuration so we can support legacy and devices that are updated in progress

Step 3 - Enable Secure Boot Certificate Deployment GPO

Do the playbooks have guidance on how to fully utilize Intune in preparing for the Secure Boot deployment? 

Also, will we see the Secure Boot Reporting feature in Intune be more informative? 

I have several questions regarding devices that lack supported firmware (End-of-Life hardware or devices where the firmware hasn't been updated) and therefore do not have the Windows UEFI CA 2023 certificate integrated.

Q1: I understand these devices will continue to boot after June 2026 even with Secure Boot active. However, what happens if there are changes e.g. to bootmgfw.efi or the underlying hardware? What would be the impact? Can we let such a device live until HW dies to avoid replacemet still good working HW?

Q2: When does Microsoft plan to add the original 2011 certificate to the revocation list (DBX)? If/when this happens, what will the consequences be for these legacy devices?

Q3: If a firmware update for an older machine is released after June 2026, will it be possible to install/deploy the new certificate manually at that point?

Q4: Can we expect to see a Secure Boot certificate status report integrated into the Microsoft Defender for Endpoint console?

Rollout model clarification (Telemetry vs. Policy)

We observe that a significant number of devices already show “Certificate Status = Up to date” in the Intune Secure Boot Status Report, even though our Intune Secure Boot policies are currently still failing with the described error 65000.

Given this, we would appreciate clarification on the following:

Does Microsoft currently deploy the Secure Boot 2023 certificates using a hybrid rollout model (telemetry-based CFR combined with optional policy-based control)?

At what point will policy-based opt-in become the primary or required mechanism for IT-managed devices?

Will devices without an effective policy continue to receive the certificate updates automatically via telemetry-based rollout until Secure Boot enforcement begins in 2026?

Has MS encountered any known issues regarding certain 3rd party components and the certificate expiration?  We've been attempting to work specifically with NVIDIA to confirm if changes are required directly on any GPUs in support of this expiration, but I would like to hear MS's position on the potential for issues on 3rd party components as it pertains to the expiration of the 3rd party ROM cert.  Still waiting for official feedback from NVIDIA, but this Reddit article is what piqued my interest.

https://www.reddit.com/r/nvidia/comments/1n1jroi/psa_secure_boot_2026_june_cert_expiry_can_block/

We have an air gapped environment with Windows 2019 servers and on them some Hyper-V VMs.

Cause of air gapped we can only install patches once a year and we are on patch KB5062557 and try now with registry keys and starting of the scheduled task to refresh the certs on our boxes. Works fine on physical ones, but we have problems on VMs. Sometimes current KEK is updated, sometimes not (Microsoft Corporation KEK 2K CA 2023) , same for Current UEFI DB (here we do not get the 2023 certificates, sometimes). 

Is there a proven and let's say stable way for refreshing the certificates on the VMs and what has to be done to "avoid" the error "1795 - The system firmware returned an error The media is write protected"? We tested the switching of the SecureBootTemplate, but as I wrote it seems to work only sometimes.

Intune Secure Boot Status Report

The Secure Boot Status Report states:

“The affected devices have Secure Boot enabled but are using Microsoft Secure Boot certificates that expire in 2026.”

Given this scope, we would appreciate clarification on the following:

Why does the report include a Secure Boot enabled filter and values such as Unknown or Not applicable if the report is intended to cover devices with Secure Boot enabled?

Can Microsoft confirm the exact meaning of the following states:

Up to date

Not up to date

Not applicable

Secure Boot enabled = Unknown

Under which conditions can a firmware-ready device remain in Not applicable for an extended period (e.g., telemetry delays, firmware validation, recent BIOS changes)?

Our intent is to correctly interpret the report and align remediation actions with Microsoft’s expected behavior ahead of the Secure Boot enforcement milestones.

Does the Intune setting Configure Microsoft Update Managed Opt‑In only opt a device into receiving Secure Boot certificate updates, or does enabling it also activate any additional or hidden Microsoft Update features?