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!


Thanks! Just asked some time ago in Docs when this policies are evaluated.

Senior Member

I appreciate you're trying to make a disctinction between "“Require Encryption” and "Require Bitlocker."


But.. I don't get it.. Sorry. :-)

So.. "Require Bitlocker".. I get that.. I assume when bitlocker completes to 100%.. then.. this flag or whatever is set / readable.

Got it.


But what is "Require Encryption?" When is that flag FALSE, and when does it flip to TRUE?


Thanks in advance.. 


-Jeremy Moskowitz, 15 Year MVP.

Senior Member

+1 for Jeremy's questions.

I got one question about the "Require Bitlocker". I understand that because of DHA it requires a reboot. At the time of the reboot, does the encryption need to be at 100% complete for it to report compliant or will it be enough if it's simply in an encrypting or decrypting state?




Hi Jeremy and Jan


Good questions  -  let me rephrase and provide answers based on my testing this morning (Surface pro 4 / 1803)


 What does the  "require encryption" setting do?

 This setting prompts the device user to enable encryption of the local drive, typically using Bitlocker.


When would a query on the "require Encryption" setting switch from False (not encrypted) to True (encrypted)?

 Checking the state of "Require Encryption" – would return False until the completion of encryption on the drive.


I think this behaviour may be agnostic of the type of drive encryption employed - be it Bitlocker or another vendor type but have not tested.



Does it matter if Bitlocker encryption has not completed on the system drive in order for Require Bitlocker to report as True (Enabled)?

 DHA Setting "Require Bitlocker" - will report  False (not enabled)  until 1) Bitlocker encryption is started  AND 2) The device is restarted.


There appears to be no requirement for encryption of the drive to be 100% complete at the point of measurement by the DHA client during boot in order for "require Bitlocker" to report as enabled.


Does that help?

Ta Rob

Senior Member

Hi Rob

Thanks for the additional Info on the DHA. I am still not sure I fully understand how the "require encryption" compliance works though. You seem to indicate that it causes a prompt for the user to encrypt the Win10 device? I thought that this kind of behavior was controlled through Configuration Policies and not Compliance Policies.

In any case, there is still some room for MS to provide additional guidance on the 2 settings and which one (or both?) to use and why.

Regards, Jan


Hi Jan,


For a long time I thought exactly the same as you - that compliance policy would only check the current setting of interest, mark the device as compliant or not  and not be involved in its enforcement  at all. However that is not the case. For many settings, of which "require encryption" is one, it does prompt the user to perform the necessary remediation steps. So on Windows it puts up the notification for the user that encryption is needed.


Another example would be say a compliance policy for device pin length - if your iPad had a 6 digit pin and you change iOS compliance policy to require 8 digits then when  that policy lands the device will prompt the user about the  new passcode requirement. 


So in many cases the compliance policy is both measuring the current value and prompting the end user to remediate as necessary.


I'll have look to see if there is any internal guidance along the lines you suggest for DHA Bitlocker  and or "Require Encryption but the one thing that strikes me immediately is that the DHA setting is purely for measurement.






Senior Member

Hi Rob,


Compliance settings such as encryption and PIN do support auto remediation, other things like Jailbreak detection don't (for obvious reasons :-)).  In my own testing "require encryption" does prompt the user unless the process is already completed.


According to the docs using DHA for Bitlocker compliance as opposed to "require encryption" is a more robust mechanism...





Regular Contributor

@Rob Lane This is great information, thank you!  I know that I've seen many people wondering why Intune shows a computer as non-compliant for "Require Bitlocker" but Bitlocker is enabled and active on the computer.  SCCM suspends bitlocker protection automatically when restarting a computer to apply updates, which given this new information about the compliance setting would seem to explain exactly why so many computers often show non-compliant.  


I understand better now the difference between the Require Encryption and Require Bitlocker settings, but I'm still left with a couple of questions. 

  • Does it make sense to enable *both* of these settings?  From your article, it seems that the require encryption setting is evaluated more frequently, and perhaps would at least indicate if the state reported by DHA is outdated.
  • I'm seeing cases where Intune reports a computer as compliant with the Require Bitlocker setting, but shows an Error status for the Require Encryption setting, with 'remediation failed'.  If bitlocker was enabled at boot time (per DHA), and hasn't been suspended since, what would cause this Error status for the Require Encryption setting?

Thanks again!

Regular Visitor

Thanks for the clarifications and confirmations in the previous comments.


I'd been hoping, based on statement in the original post: "Alternatively, if the risk is deemed acceptable the admin may choose to ... rely solely on the “Encryption of data storage on device” entity to determine if Bitlocker or 3rd party encryption is active on the device."  that a compliance policy could be configured to show whether any encryption was enabled, and had been testing with a device encrypted with a 3rd party product.


(My aim was see how effectively I could manage to filter out devices which were encrypted with a 3rd party product in advance of pushing a configuration profile to [prompt the user to] enable BitLocker / doing it silently via PS. My grail is to be able to silently enable BitLocker on devices but only if there's no 3rd party encryption in place, and I'm liking the PS approach since limited testing suggests that doing it via configuration profile disables the Recovery Environment in some scenarios, and that looks like it scuppers remote wipes until it's re-enabled, which in turn can be convoluted and necessitate a partition resize if the device shipped with something earlier than Windows 10...)


After going round in circles for a few hours to try and figure out where on earth the prompt to enable BitLocker was coming from I eliminated possibilities other than the “Encryption of data storage on device” setting, and only then came back to this post and read through all the comments....


As for the filtering - it would appear that whatever “Encryption of data storage on device” is checking, it doesn't notice VeraCrypt, and compounded with the fact that it then merrily suggests enabling BitLocker, I'm going to abandon any idea of using that setting and go back to the drawing board.