Use custom compliance settings in Microsoft Intune to require Windows Hello enrollment


Custom compliance settings in Intune, is a relatively new feature and is still in preview. However, the potential in this feature is enormous, and extends the possibilities for compliance policies almost endlessly.

A similar feature released to ConfigMgr 2 years ago, and is something I also blogged about here:

To demonstrate how awesome this really is, I will give you something I intend to use in production once the feature goes GA.

The use case here, is to ultimately use this in combination with Conditional Access. We don’t force the Windows Hello for Business enrollment via the built-in and full-screen wizard. We believe that’s too intrusive. Instead we send out Toast Notifications to those users/devices, where WHfB is still not in use.

Custom Compliance Policy

The custom compliance policy consist of 2 parts; 1) a PowerShell script used for detecting the compliance state, and 2) a JSON file used to verify the compliance state. I suggest you have both of these ready, before moving on with the actual configuration in Intune.


The PowerShell detection script used for detecting if Windows Hello has been enrolled, can be found on my GitHub repository: PowerShell/Get-WindowsHelloStatus.ps1 at master · imabdk/PowerShell (


The JSON file used for verifying the Windows Hello enrollment status is found below:

             "Title":"Windows Hello for Business must be enrolled",
             "Description": "Windows Hello for Business must be enrolled"

Microsoft Endpoint Manager

The further configuration of this, takes place in the Microsoft Endpoint Manager admin center in the Endpoint security -> Device compliance blade.

Create Detection Script

Start off by creating the mentioned PowerShell detection script:

Paste in the PowerShell code from my GitHub repository into the script area, and remember to configure the script to run as the logged on user:

Create Compliance Policy

Next up, create a new compliance policy based on custom settings:

Configure the newly created compliance policy similar to below:

  • Select the Get-WindowsHelloStatus.ps1 (from my GitHub repo) script
  • Upload the WHfB.json (copy/pasted from above) file
  • Verify that EnrollmentStatus is equals ENROLLED


Assign the compliance policy as you prefer. In my test scenario, I assigned it to a group containing my own user:

Compliance Results


Once compliance is evaluated with Windows Hello properly enrolled, and the PIN provider therefore in use, you will notice your device reporting Compliant on the newly created compliance policy:

The compliance status is also logged into the IntuneManagementExtension.log located in: C:\ProgramData\Microsoft\IntuneManagementExtension\Logs.

As per defined in our PowerShell script and JSON file, you will find the status ENROLLED when the device is compliant.

Not Compliant

Similar to when compliant, the IntuneManagementExtension.log  will also tell you if the device it Not compliant and therefore produce an output of NOTENROLLED.

Final Notes


In the official documentation on custom compliance setting, it’s currently and specifically mentioned that AADJ devices are required. It doesn’t tell if HAADJ devices works as well, but according to my testing both types of AAD join works just fine.

Pursuing true passwordless

If pursuing true passwordless, you can take additional measures in Windows, and disable the password credentials provider once the user/device is finally enrolled with Windows Hello for Business. More on that topic here: Passwordless Strategy – Windows security | Microsoft Docs


2 thoughts on “Use custom compliance settings in Microsoft Intune to require Windows Hello enrollment”

  1. Martin,

    Awesome post! You don’t happen to have the content of that other script/ json to go with what is listed as your first custom compliance script? I don’t see it in that github.

  2. Great article! Thanks for the good info
    Would you happen to have any scripts\json available for simple detection of an exe? We are attempting to validate our antivirus exe is running on a device for compliance and possibly virus definition version.

    The only caveat for this situation would be detection runs every 8 hours.


Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.