Windows Hello for Business with Microsoft Intune and CMMC/NIST

This post covers implementing Windows Hello for Business in an environment managed by Azure Active Directory and Microsoft Intune such that CMMC/NIST requirements are satisfied.

According to Microsoft in a blog post from February 12, 2021, Windows Hello for Business (WHfB) with certain configurations has all the capabilities to satisfy the multifactor authentication requirement of the CMMC 2.0, specifically those of Level 3 certification in control IA.3.083 (from the NIST 800-171 (r2) specification’s control 3.5.3). See that post for their details on how and why it satisfies the requirement.

At the time of writing, the pre-draft call for public comment for NIST 800-171 (r3) publication ended on September 16, 2022. Public comments are available on the NIST website, and the draft will be available at a later date.

These are the minimum settings for configuring Windows Hello for Business using Microsoft Endpoint Manager to satisfy the CMMC/NIST requirements for MFA with Windows devices:

A PIN at least 8 characters long
Use of TPM, security key, or smart card
Require that interactive logons use WHfB

Separate from policies easily defined in Intune, the following is also required:

Restrict privileged users to only access from secure workstations, requiring MFA for sign-in (possibly using WHfB where applicable)
Configure privileged user accounts to disallow password authentication

This post will focus on securing Windows endpoints using WHfB with use of TPM 2.0. Individual user configuration of WHfB will be required upon next interactive logon. Biometric options like fingerprint scanning will be allowed where applicable. Other areas such as securing RDP servers with WHfB are out of scope for this post. Links to those options from Microsoft’s blog are below.

Note: Allowing optional configuration of WHfB by a user requires a different administrative configuration design. This will be detailed in a later article and linked here when available.

Planning

Important

If you plan to require users to configure WHfB at logon, be aware of an issue where Intune’s Enrollment Status Page hangs at Account Setup at the time of the affected interactive logon. Whether your scale is ten endpoints or several thousand, if you plan to required WHfB configuration at logon (as this article demonstrates), have a plan to address this issue. The ESP often completes its function and moves on, but if it takes longer than 2-3 minutes, it’s likely gotten itself stuck and will even persist the behavior between device reboots.

Troubleshooting and workarounds for this and other scenarios will be detailed in a later article. In the meantime, use the DisablePostLogonProvisioning registry value detailed here through either a script or manually (using a local user account with admin privileges) as a workaround.

Ensure the following:

All target devices have at least one of these available:
- TPM 2.0 (most common)
- FIDO2 key
- Smart card
All target users have either:
- An existing MFA method OR
- The ability to create a new non-WHfB MFA method OR
- Have a Temporary Access Pass policy assigned to them
All Windows endpoints are running at least Windows 10 v1511 or Windows 11

TPM 2.0 is the minimum version required for use with WHfB. This is typically met by your average workstation device manufactured after 2016 or so. Run a check of your Windows endpoints to ensure this is the case. An easy way to do so at scale in MEM is to check the value in your Encryption report (requires the endpoint to be running at least Windows 10 v1607). There’s a column there for the TPM version that can list the version, Unknown, or Not applicable (common for non-Windows devices).

You can export the list to sort and query as needed as well.

Note: If the version shows as Unknown, this could be due to Windows not recognizing the TPM, which in turn could be due to bad firmware (I’ve experience this on some Acer TravelMate devices where even the UEFI didn’t recognize the TPM). There are surely other causes as well, but this is one are to investigate.

You can also query the TPM version from the endpoint itself. Here are a few ways:

Open tpm.msc as an administrator. (If opened without administrative privileges, it will give an access denied error.)
In cmd, run the following and note the first number in the returned value.
wmic /namespace:\root\cimv2\security\microsofttpm path win32_tpm get SpecVersion
In PowerShell, run the following, noting the same first number
(Get-WmiObject -Namespace "root\cimv2\security\microsofttpm" -Query 'Select SpecVersion from win32_tpm').SpecVersion

Lastly, be aware of an issue where Intune’s Enrollment Status Page hangs at Account Setup at the time of the affected interactive logon. Whether your scale is ten endpoints or several thousand, if you plan to required WHfB configuration at logon (as this article demonstrates), have a plan to address this issue. The ESP often completes its function and moves on, but if it takes longer than 2-3 minutes, it’s likely gotten itself stuck and will even persist the behavior between device reboots. Troubleshooting and workarounds for this and other scenarios will be detailed in a later article.

Configuration

Let’s address the software policy first.

Important

If you have Windows Hello for Business enabled under Windows enrollment in MEM, those settings will take precedence over the configuration profile and be automatically assigned to all users for all AADJ Windows devices. Do not enable WHfB here until you are ready to deploy it to all endpoints.

In MEM, head to Devices > Configuration profiles and create a new profile for Windows 10 and later using the Identity protection template.

Specify these settings in addition to any others you wish, staying mindful of any organization requirements.

Setting	Option to use	Considerations
Configure Windows Hello for Business	Enable	Required
Minimum PIN length	8 (up to 127)	Meets CMMC/NIST length requirement
Use a Trusted Platform Module (TPM)	Enable	If not set to Enable, Windows will fall back to software-based cryptography if no TPM can be used, and thus will not meet our requirements.

Here are various other settings you may find of particular interest. This list is NOT exhaustive.

Setting	Options	Considerations
PIN expiration (days)	Never or 1-730 days	Much like passwords, PINs are more likely to follow a simple pattern if changes are required at specified intervals.
Remember PIN history	No or 1-50 previous PINs
Enable PIN recovery	Enable or Not configured (default)	A PIN recovery is NOT to be confused with a PIN reset (more on that later).
Allow biometric authentication	Enable or Not configured (default)	Leaving this as Not configured disallows its use.
Use security keys for sign-in	Enable or Not configured (default)	This refers to physical devices such as FIDO2 keys or smart cards. Leaving it as Not configured disallows its use.

As noted above, PIN recovery and PIN reset are different functions. The user’s PIN is changed regardless of which is used. You can read Microsoft’s documentation on both here, but this is the main difference:

PIN reset

This is destructive, meaning the user’s WHfB container (including all keys & certificates) is deleted from the device. A new container is created in its place, but data within the container will not be.

PIN recovery

This is non-destructive (and is sometimes referred to by Microsoft as a non-destructive PIN reset). The user’s WHfB container (including all keys & certificates) is retained on the device.

These are the settings I will use. Settings required for our scenario are highlighted.

After assigning the profile to a device group, the devices will have the profile deployed to them.

User Experience

Once deployment is complete, the device will need to receive the configuration then have an interactive logon to a new user session triggered. This can be done by having the user sign out and back in or, more simply, by restarting the device and having the user log back in. The user will be prompted to configure WHfB after authenticating during the next interactive logon.

User configuration of WHfB requires first authenticating with a separate MFA method. If no other MFA method is found (assuming all other requirements above are met with regard to MFA), the user will be guided through registration of another MFA method before proceeding with WHfB configuration.

If no other MFA method is found and none can be registered, an administrator will need to create a Temporary Access Pass for the user and provide them with it.

If you chose to allow for biometrics, these options will be presented to the user at first if the required hardware (scanner for fingerprint, camera for face) is detected as usable by Windows. The user may choose to use or skip these functions, but will always be required to create a PIN regardless. Just as with a PIN, Fingerprint or Face can be configured by the user at a later time through the Settings app > Accounts > Sign-in options.

If you chose to allow use of alphabetical or special characters, note that due to how WHfB functions during PIN creation, users will need to check the box named Include letters and symbols before typing any string which includes those characters. Otherwise, the characters will not be entered. Checking or unchecking the box will also cause any previously entered characters to be cleared and require re-entering them. All of this can cause confusion for users and should be communicated prior to their configuring WHfB.

Rollout Monitoring

As with most potentially disruptive changes, I recommend a phased rollout. Find your pilot users in stakeholders and those who will be savvy enough to help coworkers if they have trouble. This can assist in both any triage with configuration questions or issues and avoid some shadow IT workarounds.

New MFA method registrations can be monitored in the Azure portal in Azure AD > Security > Authentication Methods > Registration and reset events.

If the user is not prompted to configure WHfB, like many device configurations, the new settings may not yet be applied to the device.

Tip

If the settings apply only after the user logs on (i.e., the Intune sync at startup did not complete by the time the user logged in), then the user may still setup an authentication method from the Settings app under Accounts > Sign-in options. without signing out and back in or restarting the device again.

Once any phased rollout is complete, mimic your settings in Intune’s Windows enrollment page under Windows Hello for Business to allow those settings to supersede the device configuration profile for all users. You may also opt to remove the deployment of the configuration profile created earlier.

Caveats

Windows Hello for Business policies deployed in this way do not apply to local users. They can continue to logon without any prompt to configure WHfB for themselves.
If users connected to servers via RDP using mstsc with default options, they will be prompted for a PIN instead of their password by default. Either the remote system must be configured to accept WHfB as an authentication source or the user must instead opt to use another authentication source the server can accept (such as username and password).