Microsoft has quietly rolled out a new Secure Boot status report for Windows Autopatch in the Intune admin center, arming IT administrators with critical visibility into which managed devices have received the 2023 UEFI Secure Boot certificates. The tool surfaces a long‑simmering firmware security challenge: every Windows device that relies on Secure Boot must be updated with the 2023 signing certificates before June 2026, or risk boot failures. For organizations still running large Windows 10 or Windows 11 estates, this report could be the difference between a smooth transition and a flood of help‑desk calls.

Why Secure Boot Certificates Matter Now

Secure Boot is a Unified Extensible Firmware Interface (UEFI) feature that validates the digital signature of every piece of boot software—from the firmware itself to the operating system loader. It relies on a chain of trust anchored by a set of platform keys and certificate authorities (CAs) stored in the firmware. When Microsoft’s original UEFI CA certificate was issued in 2011, it carried a 15‑year validity period. That certificate expired in 2026, prompting Microsoft to create a new Windows UEFI CA 2023 certificate to replace it.

The shift is not merely a paperwork exercise. Without the 2023 certificate in the firmware’s trusted CA store, a device will refuse to load the Windows boot manager or any other binary signed with the new key. That means after the enforcement date—currently June 2026—any PC that lacks the updated certificate could display a “Secure Boot violation” error and fail to boot. The problem is compounded by the fact that the certificate update is often delivered through a combination of Windows updates, firmware updates from OEMs, and sometimes manual remediation steps.

Microsoft has been rolling out the required changes in phases. The Security Update Guide tracked under KB5025885 introduced the boot manager revocations and the new certificate, but the actual activation of these revocations is staged. As of early 2025, most devices are in an audit phase—they can report their compliance without enforcing the changes. The June 2026 deadline marks the moment when enforcement flips on, and systems without the 2023 cert will be blocked at boot. For IT departments, the window to prepare is shrinking.

What the Autopatch Secure Boot Report Shows

The new report lives inside the Windows Autopatch blade of the Microsoft Intune admin center. Autopatch itself is a service that automates the deployment of Windows, Microsoft 365, and Edge updates, keeping organizations compliant with minimal manual overhead. Adding a Secure Boot readiness report to this console is a logical extension: it lets admins see, at a glance, whether the devices they are already managing with Autopatch are on track for the certificate migration.

Once enabled, the report categorizes each managed device into one of three states:

  • Ready – The device has the 2023 UEFI Secure Boot certificate present in its firmware. No action is needed.
  • Not ready – The device is missing the 2023 certificate. It requires remediation before the enforcement date.
  • Unknown – The report could not determine the certificate status. This often happens on devices that are offline, have reporting issues, or run an older Windows version that does not support the detection mechanism.

The report can be filtered by device name, operating system version, or status, and the results can be exported to CSV for offline analysis. For enterprises managing thousands of endpoints, that export function is essential for tracking remediation progress over time.

How to Access and Use the Report

To reach the Secure Boot report, an IT admin needs the appropriate roles in Intune—typically Intune Administrator or Global Administrator. The path is:

  1. Sign in to the Microsoft Intune admin center.
  2. Navigate to Reports > Windows Autopatch > Secure Boot report.
  3. The report loads a list of all devices enrolled in Autopatch. Use the filters to narrow down to “Not ready” devices.
  4. Export the list and cross‑reference it with your hardware inventory. Many organizations will find that older devices—particularly those from 2020 or earlier—are the primary offenders.

Because the report relies on telemetry from the Windows health monitoring agent, devices must be online and communicating with Intune for their status to update. If a device has been out of contact for an extended period, it will show as “Unknown” and should be investigated separately.

The 2023 Certificate Migration: A Refresher

To understand what the report is telling you, it helps to recall the sequence of events that led here. In February 2023, Microsoft published details about a bootloader vulnerability (CVE‑2023‑24932) that could allow an attacker to bypass Secure Boot. The fix required revoking trust in older, vulnerable boot manager binaries and signing a new generation of boot loaders with a fresh certificate. That fresh certificate is the Windows UEFI CA 2023.

Microsoft’s rollout plan, outlined in KB5025885, involves several steps:

  1. Device firmware update – The 2023 certificate must be added to the device’s Secure Boot database (the “db” variable). This typically arrives via a UEFI firmware update from the OEM.
  2. Boot manager revocation – Windows Update deploys a Secure Boot DBX (revocation list) update that blocks old boot managers signed with the pre‑2023 certificate.
  3. Enforcement timing – Initially, the revocation list is only advisory (audit mode). Microsoft has set the final enforcement for June 2026, when the DBX update will become mandatory and prevent booting from any binary not signed with the 2023 cert.

Many OEMs began shipping firmware updates with the 2023 certificate as early as 2023. However, the pace of adoption varies. Consumer devices that receive automatic firmware updates through Windows Update might already be compliant; enterprise devices that rely on IT-curated firmware repositories often lag behind. The Secure Boot report closes that visibility gap.

Real‑World Remediation Steps

For any device flagged as “Not ready,” the remediation path is straightforward but not always automatic. IT teams should follow a three‑stage process:

  1. Check for firmware updates – Visit the OEM’s support site for the specific make and model, and download the latest BIOS/UEFI firmware. Dell, HP, Lenovo, and other major vendors have published dedicated support pages listing models that require updates for the 2023 certificate. Apply the firmware update using your standard deployment tool (often integrated with Intune via Windows Driver and Firmware Management).
  2. Deploy the Windows Boot Manager revocation update – Ensure that KB5025885 (or its later cumulative successor) is installed on the device. This update must be present for the boot manager to be aware of the revocation list. Some devices may require a reboot after the firmware update before Windows can detect the new certificate.
  3. Validate compliance – After both the firmware and Windows updates are installed, force a reboot and let the device report back to Intune. Within a few hours (or after a manual sync), the Secure Boot report should update the status to “Ready.” If it does not, double‑check that the firmware update actually included the 2023 certificate. A small number of older systems may never receive a firmware update from their OEM, in which case the device may need to have Secure Boot disabled or be replaced.

For organizations with broad hardware diversity, the report becomes a project‑management dashboard. Start by grouping devices by OEM and model, then prioritize models with the highest “Not ready” counts. Some models may be end‑of‑life and will never receive an official firmware updates; those devices must either be retired before June 2026 or have Secure Boot turned off (which reduces security posture).

Impact on BitLocker and Other Security Features

Secure Boot is not an isolated security control. It forms the foundation for other features, most notably BitLocker drive encryption. BitLocker can use the Trusted Platform Module (TPM) to seal encryption keys, and one of the measurements stored in the TPM is the Secure Boot configuration. If Secure Boot fails or changes unexpectedly, BitLocker may enter recovery mode, requiring a 48‑digit recovery key to unlock the drive.

If a device’s Secure Boot certificate update goes wrong—say, a firmware update toggles Secure Boot from “Standard” to “Custom” mode, or the revocation list blocks a legitimate bootloader—the TPM measurements will change. That could trigger BitLocker recovery, locking users out of their own devices. The Secure Boot report helps IT teams preempt this scenario by identifying devices that need the certificate update and ensuring the update is applied in a controlled, sequenced manner.

Microsoft’s guidance emphasizes that both the firmware update and the OS‑level DBX update must be applied together. A device that receives only the firmware update might still boot, but once the DBX enforcement kicks in, it could fail if the OS update is missing. Conversely, applying the OS update without the firmware certificate leaves the device unable to boot any 2023‑signed binary. The Autopatch report can show exactly which piece is missing, helping admins avoid the common pitfall of partial remediation.

What’s Driving the June 2026 Deadline?

Why June 2026? The timeline traces back to the original UEFI CA certificate’s expiration date. The 2011 certificate, used to sign all Windows boot components, had a “Not After” date of October 19, 2026. To avoid a sudden cliff, Microsoft set the enforcement of the 2023 revocation list to a few months before that, in June 2026. This gives the industry a final transition window, after which any boot binaries signed only with the old certificate will be invalid.

Implicit in this schedule is a recognition that firmware updates take longer to deploy than software updates. Enterprises need time to test, pilot, and roll out firmware across heterogeneous fleets. The Autopatch report is one tool that should accelerate that timeline by exposing exactly which devices are lagging.

A secondary driver is the ever‑tightening regulatory landscape. Governments and insurers are increasingly mandating Secure Boot and hardware‑rooted trust. Organizations that fail to maintain compliant firmware could find themselves out of step with cyber‑insurance requirements or industry standards like NIST SP 800‑193 (Platform Firmware Resiliency). The new report, by making compliance transparent, helps address those governance demands.

Beyond the Report: Automating with Autopatch and Intune

The Secure Boot report is a diagnostic tool, but Autopatch itself can push the necessary updates. If an organization has already enrolled devices in Autopatch, the service will automatically deploy Windows quality updates that include the DBX revocation. The missing piece—firmware updates—remains a challenge because firmware is typically delivered by the OEM, not by Windows Update. However, Microsoft and OEMs have been working to increase the availability of firmware through Windows Update. An increasing number of devices now receive UEFI capsule updates via Windows Update, which Autopatch can orchestrate.

For devices that can receive firmware through Windows Update, once that firmware is published, Autopatch will make it available just like a driver update. Admins can check the Windows Driver and Firmware Management section in Intune to see if a firmware update is pending for specific models. When combined with the Secure Boot report, this creates an end‑to‑end workflow: the report identifies devices needing firmware, the driver management tool pushes the update, and the report verifies compliance afterward.

IT pros should also configure Windows Health Monitoring for Autopatch to ensure the telemetry data flows smoothly. Without health monitoring, device status may not populate in the Secure Boot report or may show as “Unknown.” This is configured in the Autopatch tenant settings, typically under “Devices” > “Windows Autopatch” > “Tenant management.”

Preparing for the Final Countdown

With roughly a year and a half until enforcement, IT teams have a window of opportunity. The Secure Boot report should be checked immediately for all Autopatch‑managed devices. Any “Not ready” or “Unknown” device represents a potential boot failure waiting to happen. The following timeline can serve as a rough guide:

  • Now – Q3 2025: Run the report in audit mode. Identify all non‑compliant devices and begin firmware updates for the most critical models. Work with OEMs if firmware is unavailable for older hardware.
  • Q4 2025 – Q1 2026: Complete firmware updates for all actively supported devices. Remove or replace any hardware that cannot be updated. Communicate the change to end users, emphasizing that they may see a firmware update prompt or an extra reboot.
  • Q2 2026: Run a final compliance sweep. Confirm that all devices show “Ready.” Test boot behavior on a representative sample after the DBX revocation update is applied. Prepare help‑desk scripts for BitLocker recovery scenarios.
  • June 2026: Monitor the transition. Microsoft will enforce the DBX revocation via the monthly cumulative update. The Autopatch report will continue to show post‑enforcement status, but by then it should show 100% readiness.

What About Co‑Managed and Non‑Autopatch Devices?

The Secure Boot report is currently limited to devices enrolled in Windows Autopatch. For organizations that use Intune without Autopatch, or that rely on Configuration Manager for co‑management, a similar report is available under the Endpoint security > Security baselines or as part of the Windows 11 readiness reports, but it may not be as directly actionable. Microsoft has indicated that the Secure Boot status data will eventually feed into the broader Intune reporting framework, but for now, Autopatch subscribers get the most integrated experience.

Admins managing a mix of management tools can still query Secure Boot compliance using the Microsoft Intune Graph API or by running custom PowerShell scripts that read the Get‑SecureBootUEFI cmdlet output. However, the Autopatch report remains the simplest method for most cloud‑first shops.

Conclusion

The late‑lifecycle certificate scramble is a familiar stress test for any IT organization. Microsoft’s addition of a dedicated Secure Boot report inside the Autopatch blade transforms a looming hardware‑security deadline from a blind leap into a managed transition. With the June 2026 enforcement date fast approaching, the time to act is now. The report is available for all Autopatch users at no extra cost; turning it into a routine compliance check today could prevent a wave of bricked devices tomorrow.

For organizations that have not yet enrolled in Autopatch, the Secure Boot report might be the catalyst to adopt the service. As the Windows ecosystem matures, tools that surface firmware‑level compliance are no longer optional—they are the foundation of a trustworthy modern workplace.