Updated Secure Boot status report in Windows Autopatch

Mai
19

by BlackRabbitZ | CVE | 0 Comments | 19 Mai 2026

Do more with the improved Secure boot status report in Windows Autopatch. Now, you can gain better device-level visibility into certificate status, trust configuration, and readiness for Secure Boot certificate updates. New interactive certificate-level details fit directly into your certificate rollout workflow:

From policy deployment to actual Secure Boot readiness

Secure Boot is a core Windows security feature that helps ensure devices start up using only trusted, digitally signed components. It helps protect against boot-level malware and enforces a root of trust during startup. As Secure Boot certificates evolve and older certificates approach expiration, visibility into device readiness becomes critical.

To deploy Secure Boot certificate updates, the recommended option is to enable the EnableSecurebootCertificateUpdates policy. When active, the policy automatically sends certificate updates to supported and eligible devices but requires a device restart to complete the process.

However, before enabling a Secure Boot policy, it’s important to understand:

Which devices have updated their certificates and are protected
Whether firmware configuration blocks updates
Whether devices are ready for rollout
When to take action

The Secure Boot status report addresses this gap by giving you a data-informed view of device readiness, not just policy assignment status. The report provides a device-level view of Secure Boot across your Windows Autopatch-managed devices. Let’s walk through how to quickly understand your fleet’s readiness.

Note: Certificate readiness presupposes devices with Secure Boot enabled. Devices with Secure Boot disabled are included for visibility only. They don’t require any action.

How to use the Secure Boot status report

The report includes several key signals designed to help you make informed decisions.

Ready to see it in action? Start here:

Go to the Intune admin center.
Open Reports > Windows Autopatch > Windows quality updates.
Select Reports.
Open Secure Boot status.

Identify devices that aren’t up to date by certificate status

Find the new column called Certificate status. See which certificates require action based on an aggregate view. Here’s what each status means:

Up to date: No action is required.
Not up to date: Devices require certificate updates.
Not applicable: Secure Boot isn’t enabled.

Drill into this field to see per-certificate details. No need for custom scripts or manual validation. Select the status cell for any device to see whether Secure Boot is enabled, its trust setting, and status for each of the four required certificates.

Use trust configuration and certificate details to understand applicability

Not all devices require the same set of Secure Boot certificates. The Secure Boot trust setting column shows whether a device trusts:

Microsoft-only components
Both Microsoft and non-Microsoft components

This is important because certificate applicability depends on how the device is configured, not just what exists on disk. For example, a device may be fully compliant even if certain certificates aren’t present. This happens if certificates aren’t required for that configuration.

Check confidence level to determine your rollout strategy

This is one of the most important additions in the new version of the report. The Confidence level column helps guide deployment decisions based on Microsoft-observed data across similar devices and firmware configurations. Select any cell to see a flyout summary for that device. Review the description of the status and the recommended action. It also states whether the high-confidence deployment policy is allowed.

Use this data to:

Confidently auto-deploy updates to high-confidence devices.
Manually validate devices with limited or no data.
Pause rollout where known issues exist.

Here are recommendations based on confidence level labels:

High confidence: Deploy the certificates depending on the policy setting:
- If the high-confidence policy is allowed: No action is required. Devices will automatically receive Secure Boot certificate updates through Windows Update.
- If the high-confidence policy isn’t allowed: Deploy certificate updates manually when ready.
  - Under observation: Test certificate updates in controlled rollout.
  - No data observed: Carefully validate certificate updates before broad deployment. Microsoft hasn’t observed this type of device in Secure Boot update data.
  - Temporarily paused: Don’t deploy. Devices in this group are affected by a known issue. Consult with your OEM for possible firmware updates.
  - Not supported: Exclude these devices from automation.

Use the confidence level data to take out guesswork from your Secure Boot certificate rollout strategy and turn it into data-informed deployment.

Use alerts and timestamps to prioritize action

A new Alerts column helps you validate reporting freshness and prioritize action. The report surfaces the following operational signals:

Devices missing diagnostic data
Devices requiring action
Timestamp of last reported diagnostic data

Important! To avoid false assumptions when validating rollout progress, note these important limitations:
Status updates can take up to 12 hours after restart to be reflected.
Devices must send required diagnostic data to appear correctly in the report.
Inactive devices might show up as Unknown.

Plan targeted remediation of Secure Boot certificates

Secure Boot certificate updates are not uniform across devices. They depend on firmware, configuration, and trust models. Due to this variation, applying Secure Boot updates sometimes sees unexpected results.

Without clear visibility, organizations risk:

Missing required updates
Deploying updates too broadly
Misinterpreting device readiness

The Secure Boot status report gives you a more precise, device-level understanding of readiness, so you can act confidently and help reduce risk across your estate. Together, these improvements focus on one thing: making the data actionable. If needed, make data-informed decisions on targeted remediations instead of broad deployments.

Note on Secure Boot updates and hotpatch updates

If you’re using hotpatch updates, plan for a one-time change in strategy. More devices become eligible for Secure Boot certificate updates over time based on high-confidence diagnostic data. High-confidence deployment relies on data included in monthly non-security preview updates, which are typically released the fourth week of the month. By definition, devices receiving hotpatch updates don’t receive these preview updates. As such, these devices might not progress at the same rate as other devices. Here’s the implication:

Devices might not receive updated high-confidence data in May or June.
Some devices might not become eligible for automatic deployment during that time.

In addition, applying Secure Boot updates requires device restarts to complete changes to:

Secure Boot certificates
The Windows Boot Manager

As a result of this design, devices receiving hotpatch updates will only receive updates automatically during the next baseline month (for example, April or July).

To move forward sooner, your organization can:

Install the latest monthly non-security preview update (instead of a hotpatch update) to pick up updated high-confidence data.
Restart the devices to complete the update process.
Optional: Temporarily pause hotpatch updates and plan maintenance windows during Secure Boot rollout. Then resume hotpatch updates.

Learn more or bookmark these resources:

Continue the conversation. Find best practices. Bookmark the Windows Tech Community. Looking for support? Visit Windows on Microsoft Q&A.

Quelle: Updated Secure Boot status report in Windows Autopatch