Enable Windows 10 Multifactor Authentication with Windows Hello Multifactor Device Unlock & Microsoft Intune
In this blog post I’ll explain how to configure and enable Windows Hello Multifactor Device Unlock using Microsoft Intune. Windows Hello Multifactor Device Unlock provides multifactor device authentication for login or unlocking Windows 10 devices.

Windows Hello for Business
Windows Hello for Business is a private/public key or certificate-based authentication approach for organizations and consumers that goes beyond passwords. This form of authentication relies on key pair credentials that can replace passwords and are resistant to breaches, thefts, and phishing. With Windows Hello, biometric authentication and recognition is easy with a face or fingerprint.
Windows Hello credentials address many of the inherent problems with passwords. Passwords can be difficult to remember, can be reused on multiple sites, and can sometimes be easy to guess. Server breaches can expose symmetric network credentials, or users can inadvertently divulge their passwords to phishing attacks. Because PINs are tied to the device and are stored locally, they are more secure than a password.
Windows, today, natively only supports the use of a single credential (password, PIN, fingerprint, face, etc.) for login or unlocking a device. Therefore, if any of those credentials are compromised (shoulder surfed), an attacker could gain access to your local device only. Since Windows 10 (1709) Windows offers Multifactor device unlock by extending Windows Hello with trusted signals. You can configure Windows 10 to request a combination of factors and trusted signals to unlock your Windows 10 devices.
The Basics: How it works
First unlock factor credential provider and Second unlock credential provider are responsible for the bulk of the configuration. Each of these components contains a globally unique identifier (GUID) that represents a different Windows credential provider. With the policy setting enabled, users unlock the device using at least one credential provider from each category before Windows allows the user to proceed to their desktop.

The Multifactor Device Unlock policy consists of three components:
- First unlock factor credential provider (primary authentication);
- Second unlock factor credential provider (second factor authentication);
- Signal rules for device unlock (defines second unlock credential provider);
The credential providers included in the default policy settings are:
Credential Provider | GUID |
PIN | {D6886603-9D2F-4EB2-B667-1971041FA96B} |
Fingerprint | {BEC09223-B018-416D-A0AC-523971B639F5} |
Facial Recognition | {8AF662BF-65A0-4D0A-A540-A338A999D36F} |
Trusted Signal | {27FBDB57-B613-4AF2-9D7E-4FA7A66C21AD} |
Note: Multifactor unlock does not support third-party credential providers or credential providers not listed in the above table.” That makes for example FIDO2 not supported as unlock factor.
The default credential providers for the First unlock factor credential provider includes the following credential providers:
- PIN
- Fingerprint
- Facial Recognition
In the example below first unlock factor credential provider, PIN will be the first unlock provider followed by Facial Recognition and Fingerprint as fallback.
{D6886603-9D2F-4EB2-B667-1971041FA96B},{8AF662BF-65A0-4D0A-A540-A338A999D36F},{BEC09223-B018-416D-A0AC-523971B639F5}
For the Second unlock factor credential provider includes the following unlock providers:
- Trusted Signal
- PIN
In the example below second unlock factor credential provider, trusted signals will be the first unlock provider followed by PIN as fallback.
{27FBDB57-B613-4AF2-9D7E-4FA7A66C21AD},{D6886603-9D2F-4EB2-B667-1971041FA96B}
Based on your preference you can change the order of the unlock factor credential providers. Trusted Signal will be the first unlock provider followed by PIN as fallback.
Now we explained the first two components of Multifactor Unlock (Unlock Factor Credential Providers) the final component is Signals rules for device unlock. The Signal rules for device unlock setting contains the rules the Trusted Signal credential provider uses to satisfy unlocking the device and works similar as Dynamic Lock works
The default signal rules for the policy setting include the proximity of any paired Bluetooth smartphone.
<rule schemaVersion=”1.0″>
<signal type=”bluetooth” scenario=”Authentication” />
</rule>
The classofDevice attribute defaults Phones and uses the values from the following table
Description | Value |
Miscellaneous | 0 |
Computer | 256 |
Phone | 512 |
LAN/Network Access Point | 768 |
Audio/Video | 1024 |
Peripheral | 1280 |
Imaging | 1536 |
Wearable | 1792 |
Toy | 2048 |
Health | 2304 |
Uncategorized | 7936 |
To successfully reach their desktop, the user must satisfy one credential provider from each category. The order in which the user satisfies each credential provider does not matter.

Therefore, using the default policy setting a user can provide:
- PIN and Fingerprint
- PIN and Facial Recognition
- Fingerprint and PIN
- Facial Recognition and Trusted Signal (Bluetooth paired smartphone)
Important!
- PIN must be in at least one of the groups
- Trusted signals must be combined with another credential provider
- You cannot use the same unlock factor to satisfy both categories. Therefore, if you include any credential provider in both categories, it means it can be used to satisfy either category, but not both.
Configuration
Now we have the basic understanding of how Windows Hello Multifactor Unlock works, it is time to configure it using Microsoft Intune.
The configuration of Multifactor Device Unlock has been described here using Group Policy. The Configure device unlock factors policy setting is located under Computer Configuration\Administrative Templates\Windows Components\Windows Hello for Business.

As explained Windows Hello Multifactor Device Unlock consists of 3 components which will be configured each using a custom OMA-URI policy setting, as the configuration can’t be done (yet) using the Intune UI.
- Open the Azure Portal and select Microsoft Intune service;
- Create a new profile in Device Configuration blade;
- Provide a name and description and select Windows 10 and later as platform;
- As profile type select Custom;
- On the Custom OMA-URI settings blade select Add to add the first unlock credential provider;
Name: Windows Hello Multifactor Unlock – First Unlock Factor
OMA-URI: ./Device/Vendor/MSFT/PassportForWork/DeviceUnlock/GroupA
Data Type: String
Value: {D6886603-9D2F-4EB2-B667-1971041FA96B},{8AF662BF-65A0-4D0A-A540-A338A999D36F},{BEC09223-B018-416D-A0AC-523971B639F5}

- On the Custom OMA-URI settings blade select Add to add the second unlock credential provider;
Name: Windows Hello Multifactor Unlock – Second Unlock Factor
OMA-URI: ./Device/Vendor/MSFT/PassportForWork/DeviceUnlock/GroupB
Data Type: String
Value: {27FBDB57-B613-4AF2-9D7E-4FA7A66C21AD},{D6886603-9D2F-4EB2-B667-1971041FA96B}

- On the Custom OMA-URI settings blade select Add to add the unlock signals rules;
Name: Windows Hello Multifactor Unlock – Unlock Signals Rules
OMA-URI: ./Device/Vendor/MSFT/PassportForWork/DeviceUnlock/Plugins
Data Type: String
Value: <rule schemaVersion=”1.0″> <signal type=”bluetooth” scenario=”Authentication” classOfDevice=”512″ rssiMin=”-10″ rssiMaxDelta=”-10″/> </rule>

- Now the configuration of Windows Hello Multifactor Device Unlock has completed we save the configuration and deploy the custom policy to Windows 10 devices.

User Experience
The configuration of Windows Hello Multifactor Device Unlock has completed, however there is one final step left which must be completed by the end-user. As we’ve configured Bluetooth smartphone as unlock signal, we have to pair a smartphone via Bluetooth to your Windows 10 device.
- Use Search and enter “Blue”, search will give a result “Bluetooth and Other Device settings” or via Windows Start select Settings;
- In the Windows Settings menu select Devices;
- Select Add Bluetooth or other device;
- In the Add a device wizard select Bluetooth
- That’s it!
Now we successfully paired our smartphone as Trusted Signal we’re ready to use Windows Hello Multifactor Device Unlock, using Facial Recognition as first unlock factor followed by a smartphone (connected with Bluetooth) as second factor.
In the first video I’m log in to my Windows 10 device…
…where the second video I’m unlocking my Windows 10 device.
When it comes to user experience, the response we received so far are very positive. Based on notes from the field, users are very enthusiast: “It just works. It is seamless and intuitive in use”.
Requirements
- Windows Hello for Business deployment (Native, Hybrid or On-premises)
- AD-, Azure AD- or Hybrid Azure AD deployments
- Windows 10, version 1709 or later
- Bluetooth, Bluetooth capable devices (optional)
Under the hood
When logging in or unlocking your device Windows Hello processes the Multifactor MulgiUnlock policy. The First Unlock Factor Credential provider determines which unlock options are available (PIN, Facial and Fingerprint).
As Facial Recognition meets the policy First Unlock Factor Credential Provider we are successfully logged in.
Now the Second Unlock Factor Credential Provider is challenged which is Trusted Signals.
Because we paired our smartphone the Second Unlock Factor Credential Provider is met as well challenged as well after which we are logged in successfully on the basis of 2 factors.
Throubleshooting
In case of issues with Windows Hello for Business, the Windows Eventlog is a valuable startpoint to start your troubleshooting journey.
Windows Logs>>Applications and Service Logs>>Microsoft>>Windows>>HelloForBusiness>>Operational
Event ID |
Details |
3520 |
Unlock attempt initiated. Example: Attempting device unlock using provider {8AF662BF-65A0-4D0A-A540-A338A999D36F}. The list of acceptable providers are: Group A: {D6886603-9D2F-4EB2-B667-1971041FA96B}, {8AF662BF-65A0-4D0A-A540-A338A999D36F}, {BEC09223-B018-416D-A0AC-523971B639F5} Group B: {27FBDB57-B613-4AF2-9D7E-4FA7A66C21AD}, {D6886603-9D2F-4EB2-B667-1971041FA96B} |
5520 |
No Policy Example: Device unlock policy is not configured on this device. |
6520 |
Warning Example: Provider is not in the acceptable provider list. |
7520 |
Failure Example: Failed to authenticate the user’s credential. Error: The user name or password is incorrect. (0x8007052E) Correlation vector: qf/ugLLYq0Wp+e7K.1.0 Processing time: 50 milliseconds.
|
8520 |
Success Example: Successfully authenticated the user’s credential. Processing time: xx milliseconds. |
Recap
By enhancing Windows Hello for Business with Multifactor Device Unlock, the user (logon/unlock) experience on Windows 10 is taken to a higher level. Besides the use experience Multifactor Device Unlock addresses many of the inherent problems with passwords including reduces the chance get compromised (e.g. shoulder surfed).

Organizations can take advantage of Windows Hello Multifactor Device Unlock when:
- Have expressed that PINs alone do not meet their security needs;
- Want to prevent Information Workers from sharing credentials;
- Want their orgs to comply with regulatory two-factor authentication policy;
- Want to retain the familiar Windows logon UX and not settle for a custom solution.
Sources
Special thanks to Pieter Wigleven (Microsoft) & Karanbir Singh (Microsoft) for reviewing and providing valuable input.
Windows Hello for Business
Windows Hello for Business Features
Enabling remote access with Windows Hello for Business in Windows 10
https://msdn.microsoft.com/en-us/library/mt728163.aspx
Extending Windows Hello with trusted signalshttps://channel9.msdn.com/Events/Ignite/Microsoft-Ignite-Orlando-2017/BRK2075
Hello! Can you provide a link or more details how to configure trusted signals based on network location? Does it use a gateway address, a default DNS domain name via DHCP or what? thanks!
Hi there,
Yes, you can use your network properties like gateway, subnet, DNS suffix, etc. to configure as trusted signals. Will follow this up with a detailed blogpost soon. Stay tuned!
Hi Ronny, thanks for this post. Awesome. I was playing around with this today and a couple of questions came to mind :
1. What if I configured the user to authenticate with PIN and Phone, but the user has not configured the device via BT yet ?
2. Can I prevent users logging on with their passwords, once this PIN is enabled? In other words, how do I prevent that users can still log in to their machines with one single password ?
Hi Jan, you’ll always have a fall back using your password. Besides I expect it’s not possible, I wouldn’t recommend as the same reason as explained for you first question.
Hi Ronny,
Why do we need an on-prem AD to leverage it?
Hi Martony, you don’t. It can ben configured for both AD or Azure AD joined devices. Thanks for pointing out, updated the prerequisites.
Hi Ronny, how do I remove MFA after deploying it?
I followed the guide but didn’t realise you can’t completely remove the single password log on.
I’ve removed the policy on Azure and disconnected my PC from my Microsoft Azure(Work) account. But it still says “Your organisation requires multiple authentication methods”.
I thought maybe the changes have stayed locally but the Group Policy says none of the Windows Hello for Business settings are configured.
Hi Jim, just removing the policy might not sort effect as the settings will remain active on the client as it’s not an integer data value which can be turned on or off (0/1). I’m owe you an instant answer, have to get back on this.
I have exactly the same issue after doing this in which my client still requires multiple authentication methods?
Perhaps you can update this article with GUID for FIDO2 tokens as a factor? I’m missing that, and I’d like to test that in addition to biometric.
Hi Reidar, thank you for taking the time and dropping a line. Based on your feedback I’ve updated the post with the information below. As per Microsoft official support statement “Multifactor unlock does not support third-party credential providers or credential providers not listed in the above table.” FIDO2 tokens aren’t supported as unlock factor.
https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/feature-multifactor-unlock#configuring-unlock-factors
“The proof is in the pudding” I tested this recently and have added FIDO2 credential provider as unlock factor. The unlock factor is just ignored as it’s not on the list of acceptable unlock providers “Provider is not in the acceptable provider list”.
I actually found out, but I had to go into the registry on my computer after logging in with a token I set up locally.
In HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI there’s a key called LastLoggedOnProvider, which holds the CLSID for the provider last used. If you set up a test machine with any provider and log on, the CLSID will be in that key.
BTW, this is the CLSID for FIDO2 tokens: {F8A1793B-7873-4046-B2A7-1F318747F427}
In July (shortly after windows hello received FIDO authentication), Microsoft announced they were supporting FIDO authentication devices with azure and office 365 logon. This should go a long way towards their intention of removing passwords as an authentication factor.
Hello, Wondering if you have tested this across multiple accounts on one device? Seems that the multi factor unlock doesn’t work for multiple accounts – the initial account that set’s up the PC is fine, but any account after that can just get in with a password. Any ideas?
Hi Daniel, thank you for leaving a comment. No, unfortunately I didn’t test it in a multi-user scenario as you mentioned. I couldn’t find any reference in the Microsoft Docs regarding multi-user. Given the nature of WHfB Hybrid I wouldn’t surprised this scenario isn’t supported.