Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
What is Secure Boot?
Secure Boot is a core Windows security feature that helps protect devices from malicious software during startup. When Secure Boot is enabled, the system firmware (UEFI) verifies that only trusted, digitally signed components are allowed to load as the device starts. This helps prevent boot-level malware and ensures that Windows starts using known good, securely signed code.
Secure Boot relies on digital certificates that are stored in the system firmware. These certificates must remain up to date to ensure continued protection and compatibility with Windows security updates.
Why Secure Boot status matters
As Windows security evolves, some Secure Boot certificates are updated or replaced to address emerging threats and strengthen platform protections. Devices that have Secure Boot enabled but are missing required certificate updates may encounter compatibility or security issues over time.
The Secure Boot status report in Windows Autopatch is designed to help IT admins understand the Secure Boot posture of their fleet and identify devices that may require attention—before issues occur.
Learn more about Windows Secure Boot certificate expiration and CA updates.
Secure Boot status report overview
The Secure Boot status report provides a device-level view of Secure Boot across your Windows Autopatch-managed devices. It helps answer three key questions:
- Which devices have Secure Boot enabled?
- Which Secure Boot-enabled devices are fully up to date?
- Which Secure Boot-enabled devices need certificate updates?
For each device, the report shows whether Secure Boot is enabled or not. Devices that do not have Secure Boot enabled do not require any action.
To locate this report:
- Go to the Intune admin center.
- Navigate to Reports > Windows Autopatch > Windows quality updates.
- Select the Reports tab.
- Select Secure Boot status.
Devices with Secure Boot enabled
For devices where Secure Boot is enabled, the report further indicates whether the device’s Secure Boot certificates are up to date.
- If Secure Boot is enabled on the device, and certificates are up to date, no action is required.
- If Secure Boot is enabled on the device, but certificates are out of date, action is required. Update the device’s Secure Boot certificates to the 2023 versions. Learn more about guidance for IT professionals and organizations for Secure Boot certificate updates.
Devices without Secure Boot enabled
If Secure Boot isn't enabled on a device, no action is required from a Secure Boot certificate readiness perspective. These devices are included in the report for visibility, but Secure Boot certificate updates apply only to devices where Secure Boot is enabled.
How this report helps IT admins
The Secure Boot status report helps you as an IT admin do the following:
- Understand Secure Boot adoption across your environment.
- Identify Secure Boot-enabled devices that need certificate updates.
- Plan firmware and BIOS update strategies with confidence.
- Reduce risk by addressing Secure Boot readiness proactively.
By centralizing this information in Windows Autopatch, you can more easily monitor Secure Boot readiness. Take informed, targeted action where needed, without unnecessary remediation or guesswork.
Interpreting Secure Boot certificate status
As you use this report to assess Secure Boot readiness across your environment, it’s important to understand how Secure Boot certificate status is evaluated and how to interpret the results.
If you compare Secure Boot certificate readiness shown in this report with results from custom scripts or firmware inspection tools, you might notice differences. These differences are often expected and don't indicate an issue with the report.
Secure Boot certificate readiness is determined by a device’s firmware trust configuration, not only by device manufacturer. Windows Autopatch evaluates certificate applicability based on how the device is configured to trust boot components, rather than requiring a uniform set of Secure Boot certificates across all devices.
For example, a device that's configured to trust only Microsoft‑signed boot components might be reported as up to date, even if Microsoft certificates for non-Microsoft firmware components are absent. In this scenario, non-Microsoft firmware components don't apply to that device’s boot configuration.
When validating Secure Boot certificate status, make sure to account for the device’s firmware trust configuration. If you compare certificate presence without considering the active boot configuration, you might reach incorrect conclusions about device readiness.
No action is required if a device is reported as up to date in the Secure Boot status report.
How Secure Boot trust configuration affects certificate status
The device’s Secure Boot trust configuration is essential to correctly interpret certificate status.
The report now includes a Secure Boot trust configuration column to make this relationship explicit.
Specifically:
- Devices configured to trust only Microsoft‑signed components might not require non-Microsoft firmware components.
- Devices configured to trust both Microsoft and non-Microsoft firmware components require a broader set of certificates.
When evaluating certificate status:
- Check the device’s trust configuration.
- Use the certificate status details (by selecting the value) to understand which certificates are applicable and which are missing.
Interpreting confidence level
The Confidence level column provides guidance based on Microsoft analysis of similar devices and firmware configurations. It’s intended to help you make safer rollout decisions for Secure Boot certificate updates. Consider it especially when planning staged deployment across diverse hardware.
What confidence level value represents
- A confidence classification based on observed outcomes across similar devices and firmware configurations.
- A recommended action: you can either automatically deploy or manually roll out some Secure Boot certificate updates for a device.
What confidence level value doesn't represent
- It does not replace Certificate status. A device can be Up to date regardless of confidence classification.
- It does not necessarily mean that action is required. In some cases, the confidence level is informational (for example, high confidence with automatic deployment allowed).
Important
A device can be reported as Up to date while showing No Data Observed. This reflects limited data coverage for similar devices, not a problem with the device or its current certificate state.
Automatic versus manual deployment
Automatic Secure Boot certificate deployment requires both conditions to be true:
- The device is classified as high-confidence.
- The High confidence deployment policy is allowed (not blocking automatic deployment).
If automatic deployment is blocked by policy, devices require manual deployment, even if they're high-confidence.
Learn more about Microsoft Intune method of Secure Boot for Windows devices with IT-managed updates.
Recommended admin action by confidence level
| Confidence level | Description | Recommended admin action |
|---|---|---|
High confidence (and ConfigureHighConfidenceOptOut == 0) |
Observed data for this device group suggests that they can successfully update firmware using the new Secure Boot certificates. | No action is required. Devices will automatically receive Secure Boot certificate updates through Windows Update. |
High confidence (and ConfigureHighConfidenceOptOut == 1) |
Observed data for this device group suggests that they can successfully update firmware using the new Secure Boot certificates. However, automatic deployment is disabled by policy. | Deploy certificate updates manually when ready. |
| Under Observation - More Data Needed | Devices in this group aren't blocked, but there isn't yet enough data to classify them as high-confidence. Secure Boot certificate updates might be deferred until sufficient data is available. | You can choose to test and deploy certificate updates in a controlled manner to validate compatibility. |
| No Data Observed - Action Required | Microsoft hasn't observed this type of device in Secure Boot update data. This classification only appears when the device isn't found in the high-confidence database. As a result, automatic certificate updates can't be evaluated for this device, and administrator action is likely required. | Carefully test certificate updates and plan a rollout before deploying updates widely. |
| Temporarily Paused | Devices in this group are affected by a known issue. To reduce risk, Secure Boot certificate updates are temporarily paused while Microsoft and partners work toward a supported resolution. This might require a firmware update. | Do not deploy certificate updates. Check for OEM firmware updates and monitor Microsoft guidance. See Event ID 1802 for more details. |
| Not Supported - Known Limitation | Devices in this group don't support the automated Secure Boot certificate update path due to hardware or firmware limitations. No supported automatic resolution is currently available for this configuration. | Exclude these devices from automated deployment and document them as an exception. |
Note
The confidence level reflects Microsoft data coverage for similar devices. If devices aren't high-confidence, it doesn't indicate that the device is out of date.
Secure Boot status report columns
The Secure Boot status report includes a set of default columns that are shown for all users. You can also add optional columns to the view for deeper hardware and firmware insight.
Default columns
These columns are shown by default and are designed to help IT admins quickly understand Secure Boot coverage and certificate readiness across their devices.
| Column name | Description |
|---|---|
| Device name | The name of the device |
| OS version | The Windows operating system version running on the device |
| Microsoft Entra device ID | The Microsoft Entra device ID associated with the device |
| Secure Boot enabled | Indicates whether Secure Boot is enabled on the device. |
| Device model | The commercial model of the device |
| Certificate status | An aggregate status showing whether Secure Boot certificates on the device are Up to date, Not up to date, or Not applicable. You can select this value to view detailed per-certificate status for the device. |
| Secure Boot trust configuration | Indicates how Secure Boot trust is configured on the device: Microsoft only or Microsoft and non-Microsoft. This configuration determines which certificates are applicable. |
| Confidence level | Indicates Microsoft level of confidence that Secure Boot certificate updates can be applied safely. This value is based on observed data from similar devices. It helps guide deployment decisions and might indicate whether automatic or manual deployment is required. |
| Date last reported | The date and time when Secure Boot data was last received from the device. Helps identify reporting latency or stale data. |
| Alerts | Displays alerts associated with the device, such as missing diagnostic data or devices requiring action. |
Optional columns
You can add optional columns to the report to see more detailed hardware and firmware context. They are helpful for troubleshooting, hardware correlation, and advanced analysis, but aren't required for understanding Secure Boot status.
| Column name | Description |
|---|---|
| Device manufacturer | The device manufacturer reported by the OEM |
| System board manufacturer | The manufacturer of the device’s system board (motherboard) |
| Model family | The device product family or product line |
| System board model | The specific system board model used in the device |
| System board version | The version or revision of the system board |
| Device SKU | The OEM SKU that identifies a specific hardware configuration |
| Firmware manufacturer | The manufacturer of the device’s firmware (BIOS/UEFI) |
| Firmware version | The currently installed firmware (BIOS/UEFI) version |
Data freshness, reporting latency, and diagnostic data requirements
The Secure Boot status report is based on Secure Boot related events. Devices report these events after startup. As a result, changes to Secure Boot state or certificate status might not appear immediately in the report.
After Secure Boot certificates are updated and the device is restarted, it can take up to 12 hours to process and reflect the updated status in the Secure Boot status report.
If a device shows Not up to date, Not applicable, or Unknown shortly after remediation, this doesn't indicate a failure. Allow time for the device to complete reporting before taking additional action.
The Secure Boot status report also depends on successful reporting and processing of Secure Boot diagnostic data. If a device isn't configured to share the required (basic) Windows diagnostic data, Secure Boot events might not be reported. As such, the device might appear as Unknown or Not applicable in the report. In this case, the report doesn't indicate an error or misconfiguration; it indicates that there's no Secure Boot diagnostic data for the device.
In addition, devices that haven't reported diagnostic data for an extended period might also appear as Unknown. Specifically, if a device has been inactive for more than 28 days, it might no longer have recent Secure Boot diagnostic data available. As a result, the device can appear as Unknown in the report even if no configuration issues exist.
To ensure accurate reporting, verify that devices are active and regularly reporting Secure Boot diagnostic data. Check that the tenant has enabled the Data Processor Service for Windows (DPSW).
Alerts in the Secure Boot report
The Alerts column provides visibility into issues affecting individual devices.
- Devices with missing diagnostic data might show a DeviceDiagnosticDataNotReceived alert.
- Devices that aren’t up to date might show alerts indicating required action.
Use alerts to:
- Quickly identify impacted devices.
- Prioritize investigation and remediation.
Additional reporting requirements
Secure-Boot-Update scheduled task
The Secure-Boot-Update scheduled task is required for Windows to apply Secure Boot certificate updates.
If this task is disabled or deleted:
- Secure Boot certificate updates won't progress.
- Devices might continue to report outdated or incomplete status.
Learn more about how to troubleshoot the secure boot scheduled task.
DisableOneSettingsDownloads policy
Don't enable the DisableOneSettingsDownloads CSP.
Windows periodically connects to the OneSettings service to retrieve configuration data required for reporting. If this policy is enabled, required reporting data might not be downloaded. Therefore, device status can appear incomplete or stale.
For more information about this policy, see the Policy CSP System documentation.
What’s new in the Secure Boot status report
The Secure Boot status report has been enhanced since launch. Improvements provide additional visibility into device configuration, update readiness, and reporting accuracy.
The following improvements are now available:
- Certificate status values are now interactive, allowing detailed per-certificate insights.
- A new Secure Boot trust configuration column shows which certificates are applicable for each device.
- A new Confidence level column provides guidance based on Microsoft data about update success for similar devices.
- A new Date last reported column shows when the device last reported diagnostic data.
- A new Alerts column surfaces issues impacting each device directly in the report.
- Report columns now have improved sorting and filtering.
For each device, the report shows whether Secure Boot is enabled or not. Devices that don't have Secure Boot enabled don't require any action.