Support Tip: Using Device Health Attestation Settings as Part of Your Intune Compliance Policy
Published Nov 06 2018 10:04 AM 48.4K Views

By Rob Lane | Sr. Service Engineer on the Enterprise Mobility and Customer Experience Team

Intune Compliance policy for Windows devices allows an administrator to specify that a device should have one or more of three security-related elements supported and checked by the Windows Device Health Attestation (DHA) service. These include:

  • Require Code Integrity
  • Require Secure Boot
  • Require BitLocker Encryption


The measured state of these three critical security capabilities are all written into the Trusted Platform Mobile (TPM) of the device and the Windows Boot Configuration Logs (also known as TCG logs) very early in the Windows boot process.


This experience – that measurement of state checked by Device Health Attestation only takes place at boot time, does have implications for the use of Device Health Attestation (DHA) settings as part of Intune compliance policy. The main consideration to be aware of relates to the BitLocker encryption setting.


Consider the scenario where a new device, which does not have BitLocker enabled at the time of its last boot, is enrolled into Intune and is subject to compliance policy where the “Require BitLocker” element of the DHA settings is enabled. When Intune performs a Device Health Attestation evaluation, the measured state of BitLocker as of the last boot is validated. In this configuration the DHA state would report BitLocker as not enabled.


Even if the user subsequently enables BitLocker encryption on the device it cannot be deemed compliant with the BitLocker element of DHA compliance policy until after the next time the device is restarted and the state is re-evaluated. This is the direct effect of measurement of the DHA state only occurring during boot time.


This behavior can be confusing for an admin troubleshooting BitLocker as they will commonly see that:

  1. BitLocker IS enabled on the device
  2. Intune configuration policy reports that setting “Require Encryption” is Compliant
  3. Intune compliance policy reports that “Encryption of data storage on device” is Compliant
  4. Intune compliance DHA policy setting reports that “Require BitLocker” is Not Complaint


The same situation might occur for a device where BitLocker is already enabled but is suspended as part of a device update which requires multiple reboots such as a firmware change.


The key takeaway here is that a device restart, while in the desired configuration, is all that is needed to update the DHA state of the device and therefore may be required for Intune compliance policy to be satisfied.


The following screenshots show the changes of states for the scenario described above from the perspective of the device compliance in the Intune console:


Device state after BitLocker has been enabled and the next checkin with Intune has completed:

DHA-Bitlocker - after enrol and before encryption.JPG 

Device state after BitLocker has been enabled and the next checking with Intune has completed:

DHA-Bitlocker - after enrol and after encryption.JPG

After the device is restarted and the enrolled user signs in:


DHA-Bitlocker - after enrol and after encryption after restart.JPG

A point to note here is that there is a difference in the way in which the two settings, “Encryption of data storage on device” and “Require Bitlocker” are evaluated. The latter uses the DHA CSP while the former the Bitlocker CSP - this is the reason they have different reporting behaviors.


For some customer scenarios, the need to trigger a second restart can be achieved through user education or scheduling restarts remotely. Alternatively, if the risk is deemed acceptable the admin may choose to deselect the DHA setting “Require Bitlocker” element of the compliance policy and rely solely on the “Encryption of data storage on device” entity to determine if Bitlocker or 3rd party encryption is active on the device.


Hope this helps - let us know if you have any questions or feedback!

Version history
Last update:
‎Nov 06 2018 10:06 AM
Updated by: