Support Tip: Using Device Health Attestation Settings as Part of Your Intune Compliance Policy

Microsoft - you should consider making some sort of toast where users could get status on when BitLocker are in progress in order for the device to become Compliant. 

Just saying 🙂

awesome

Hello Hrvoje Kusulja, great question! We have a couple of docs where you can leverage 'Require Secure Boot to be enabled on the device' setting within device compliance settings. Once applied, you can then check secure boot status on your PC for validation purposes. Here are a couple of docs to assist further: Windows compliance settings in Microsoft Intune | Microsoft Docs & Enable Secure Boot on Windows devices - Microsoft Intune | Microsoft Docs Hope this helps! ^IH

Since Azure VM Gen2 supports Security Type, with running Secure Boot and vTPM and is shown correctly on destination Windows 11 Azure VM in System information as Secure boot enabled etc. Can you confirm that Intune / MDM supports using compliance policy then?

roblane_msft are you able to provide some guidance on whether I should assign the Bitlocker and Encryption compliance policies to a Device or User group? My scenario is for Autopilot where the main user is also the user that enrolled the device through Autopilot.

Thanks,

Jan

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.

roblane_msft 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!

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...

https://docs.microsoft.com/en-us/intune/compliance-policy-create-windows

Mark.

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.

Thanks

Rob