Troubleshooting: Secure Boot Compliance Issues on Windows 10 Intune Devices

Table of Contents

Symptom¶

Administrators leveraging Microsoft Intune for device management may encounter a specific compliance issue regarding Secure Boot. You have configured a compliance policy targeted at Windows 10 devices within your Intune environment. A key setting in this policy, Require Secure Boot to be enabled on the device, is set to the Require state to enforce a higher security posture.

Unexpectedly, several Windows 10 devices that physically have Secure Boot enabled in their UEFI firmware are reported as Not Compliant within the Intune portal. This discrepancy occurs despite verification that the Secure Boot feature is indeed active on the affected devices when checked locally. The inconsistent status report hinders accurate compliance reporting and device management efforts.

Cause¶

The root cause of this specific compliance reporting discrepancy lies in the underlying hardware requirements supporting the Health Attestation feature utilized by Intune. The Require Secure Boot to be enabled on the device compliance setting relies on the device’s ability to successfully perform device health attestation. This attestation process has specific dependencies on the Trusted Platform Module (TPM) and the system’s firmware type.

Specifically, while the setting can function with some TPM 1.2 devices, full and reliable support for Health Attestation, particularly for features like Secure Boot validation, is significantly enhanced with TPM 2.0. Crucially, TPM 2.0 requires the system to be running in Unified Extensible Firmware Interface (UEFI) mode. Devices operating with a legacy BIOS, even if equipped with a TPM 2.0 chip, may not be capable of providing the necessary attestation data in a format consumable by the Health Attestation Service and subsequently by Intune. Consequently, devices failing to meet the TPM 2.0 and UEFI firmware requirements are often flagged as Not Compliant for this specific policy setting, regardless of whether Secure Boot is superficially enabled.

More Information¶

Understanding and troubleshooting this issue requires a deeper dive into the interaction between Secure Boot, TPM, UEFI, the Health Attestation Service, and Intune. Let’s explore how to diagnose the problem and the underlying technologies involved.

Verifying Device Hardware and Configuration¶

The first step in troubleshooting is to confirm the device’s hardware capabilities and configuration, as this is the primary cause identified. You need to check three key areas: Secure Boot status, TPM version, and BIOS mode (UEFI vs. Legacy).

1. Check Secure Boot Status:

   • Open the System Information tool (msinfo32.exe).
   • Look for the “Secure Boot State” entry. It should show “On”.
   • Also check the “BIOS Mode” entry. This is critical; it must show “UEFI” for proper Health Attestation with TPM 2.0.

2. Check TPM Status and Version:

   • Open the TPM Management console (tpm.msc).
   • Verify that the TPM is initialized and ready for use.
   • Look for the “TPM Manufacturer Information” section. It will list the Specification Version. For full compatibility with the Intune policy and Health Attestation, version 2.0 is strongly recommended, especially when Secure Boot is required. While TPM 1.2 might technically support some health attestation features, the reliability and scope are greater with 2.0.

If msinfo32 shows “BIOS Mode” as “Legacy” or “Secure Boot State” as “Off”, or if tpm.msc shows a TPM version older than 2.0 (and the policy specifically requires TPM 2.0 capabilities implicitly through Health Attestation) or the TPM is not ready, then the device does not meet the necessary prerequisites for this specific Intune compliance check, explaining the “Not Compliant” status.

The Role of Health Attestation¶

Intune’s compliance policies, especially those related to device security posture like Secure Boot, BitLocker, and Code Integrity, often rely on the Windows Health Attestation Service. This service, leveraging the TPM, provides a cryptographic verification of the device’s boot state and configuration.

Here’s a simplified flow:
* During boot, the device’s UEFI firmware, Secure Boot, and components measure system files and configuration into the TPM.
* The Health Attestation Service on the device collects this data.
* It communicates with a remote Microsoft Health Attestation Service endpoint to get a cryptographic attestation report confirming the integrity and security state.
* This report is then made available to MDM solutions like Intune via the MDM client on the device.
* Intune evaluates the policy requirements against the information provided in the attestation report.

If any step in this chain fails – for instance, if the TPM version is incompatible with the required attestation level, if the system is in Legacy BIOS mode preventing proper UEFI/TPM 2.0 interaction for attestation, or if the Health Attestation Service itself encounters an issue – the compliance check based on attestation will fail, resulting in a “Not Compliant” status in Intune.

Troubleshooting Steps Beyond Hardware Checks¶

Assuming your device should be compliant based on hardware specs (TPM 2.0, UEFI, Secure Boot enabled), but still shows “Not Compliant”, consider these additional troubleshooting steps:

1. Ensure Firmware is Up to Date: Outdated BIOS/UEFI firmware can sometimes cause issues with TPM functionality or Health Attestation reporting. Check the manufacturer’s website for updates.
2. Review BIOS/UEFI Settings:
   • Confirm Secure Boot is not just enabled, but properly configured with standard keys.
   • Ensure Compatibility Support Module (CSM) is disabled, as this can interfere with UEFI native mode and Secure Boot.
   • Check any specific settings related to TPM visibility or functionality.
3. Clear and Re-initialize TPM: Sometimes, the TPM state can become problematic. Clearing the TPM (perform with caution, ensure you have backups and recovery keys) and then re-initializing it via tpm.msc might resolve underlying issues.
4. Check Health Attestation Service:
   • Verify the “Health Attestation” service is running on the device (services.msc).
   • Check Windows Event Logs (under Applications and Services Logs > Microsoft > Windows > HealthAttestation) for any errors related to the service.
5. Review Device Sync Status in Intune: Ensure the device is actively communicating with Intune and policies are being received and processed. Force a sync from the Company Portal app or System Settings.
6. Examine Intune Management Extension Logs: On Windows 10 devices managed by the Intune Management Extension, logs located typically in C:\ProgramData\Microsoft\IntuneManagementExtension\Logs might provide clues if policy application or reporting is failing.

Conceptual Diagram: Intune Compliance Flow (Simplified)¶

Here’s a conceptual flow illustrating how Intune receives compliance information, particularly for settings relying on Health Attestation:

```mermaid
graph TD
A[Windows Device] → B(UEFI/Secure Boot);
A → C(TPM);
B → D(Boot Process Measurements);
C → D;
D → E(Health Attestation Service - Local);
E → F(Microsoft Health Attestation Service - Cloud);
F → G(Attestation Report);
G → H(Intune Agent/Client);
H → I(Microsoft Intune Service);
I → J(Intune Admin Console);
J → K{Compliance Status};

style A fill:#f9f,stroke:#333,stroke-width:2px
style K fill:#ccf,stroke:#333,stroke-width:2px
click I "https://learn.microsoft.com/en-us/mem/intune/"

```
Diagram illustrating the flow of device health information from a Windows device through the Health Attestation Service to Microsoft Intune.

This diagram highlights that Intune doesn’t directly query Secure Boot status in a simple registry check for this specific policy. It relies on the integrity and cryptographic validation provided by the Health Attestation Service, which in turn depends heavily on a correctly configured UEFI environment and a functional TPM, ideally version 2.0.

Table: Hardware Requirements Summary¶

Feature	Recommended/Required for Policy	Notes
Secure Boot	Required (Enabled)	Must be enabled in UEFI firmware settings.
BIOS Mode	UEFI	Essential for TPM 2.0 and proper Secure Boot integration for attestation.
TPM Version	2.0	Provides robust support for Health Attestation. Some 1.2 may work but less reliable.
TPM State	Initialized/Ready	TPM must be functional and owned by the OS.
CSM (Compatibility Support Module)	Disabled	Should be disabled in UEFI settings to ensure native UEFI boot.

Summary of key hardware and configuration requirements for Windows 10 devices to be compliant with the “Require Secure Boot to be enabled” Intune policy via Health Attestation.

Simulated Video: Troubleshooting Workflow¶

Imagine a short tutorial video covering this scenario. It would walk you through:

1. Identifying the “Not Compliant” status in the Intune portal for a specific device.
2. Switching to the affected device.
3. Opening msinfo32 to check “BIOS Mode” and “Secure Boot State”. Crucially demonstrating a device showing “Legacy” mode or “Off” status.
4. Opening tpm.msc to check the TPM version and status. Demonstrating checking the Specification Version.
5. Explaining that if BIOS is Legacy or Secure Boot is off, the hardware doesn’t meet the implicit policy requirements (which rely on UEFI/TPM 2.0 Health Attestation).
6. Briefly showing how to access UEFI/BIOS settings (requires reboot) to change from Legacy to UEFI and enable Secure Boot (cautioning about data loss risks if converting from MBR to GPT).
7. If hardware seems correct, demonstrating checking the “Health Attestation” service status and relevant Event Logs.
8. Showing how to force an Intune sync from the device.

(Note: This is a description of a potential video tutorial, not an actual embed.)

By systematically checking these areas, administrators can quickly determine if the “Not Compliant” status is due to a hardware/firmware limitation not meeting the Health Attestation requirements, or if it’s a software/service issue on a capable device. In many cases for this specific error, the root cause is the system operating in Legacy BIOS mode or having an older TPM that doesn’t fully support the required level of attestation.

Have you encountered this issue in your environment? What steps did you take to resolve it? Share your experiences in the comments below!