Multi-factor unlock

Windows Hello for Business supports multifactor authentication by combining a device-bound credential (possession factor) with either a PIN (knowledge factor) or a biometric gesture, such as facial recognition or fingerprint scan (inherence factor). In environments where device possession alone may not provide sufficient assurance, for example, if a user’s PIN can be observed by a nearby attacker—requiring an additional trust signal alongside the PIN or biometric gesture can help strengthen the Windows Hello for Business sign-in experience and reduce the risk of unauthorized access.

Windows Hello for Business can be configured with multi-factor unlock, by extending Windows Hello with trusted signals. Administrators can configure devices to require an additional trust signal “factor” that complements traditional Windows Hello authentication by layering on an additional signal, such as a connection to a familiar additional device or network.

Multi-factor unlock is ideal for organizations that:

• Have expressed that a Windows Hello device-bound credential authorized by a PIN alone doesn’t meet their security needs
• Want to mitigate the impact of information workers that share credentials
• Want to retain the familiar Windows sign-in user experience instead of deploying a custom solution

How it works

First unlock factor credential providers and Second unlock credential providers 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 policy setting has three components:

• First unlock factor credential providers
• Second unlock factor credential providers
• Signal rules for device unlock

Configure unlock factors

Supported credential providers include:

The default credential providers for the First unlock factor credential providers include:

• PIN (Required)
• Fingerprint scan
• Facial recognition

The default credential providers for the Second unlock factor credential providers include:

• Trusted Signal (Required)

Configure a comma separated list of credential provider GUIDs you want to use as first unlock factors. Listed credential providers don't need to be in any specific order.

Configure Signal Rules for the Trusted Signal Credential Provider

The Signal rules for device unlock setting contains the rules the Trusted Signal credential provider uses to satisfy unlocking the device.

Rule element

You represent signal rules in XML. Each signal rule has a starting and ending rule element that contains the schemaVersion attribute and value. The current supported schema version is 1.0.

Example

<rule schemaVersion="1.0">
</rule>

Signal element

Each rule element has a signal element. All signal elements have a type element and value. The values supported are:

• Bluetooth
• IP Configuration
• Wi-Fi

Bluetooth

You define the Bluetooth signal with more attributes in the signal element. The Bluetooth configuration doesn't use any other elements. You can end the signal element with short ending tag />.

For example:

<rule schemaVersion="1.0">
    <signal type="Bluetooth" scenario="Authentication" classOfDevice="512" rssiMin="-10" rssiMaxDelta="-10"/>
</rule>

The rssiMin attribute value signal indicates the strength needed for the device to be considered "in-range". The default value of -10 enables a user to move about an average size office or cubicle without triggering Windows to lock the device. The rssiMaxDelta has a default value of -10, which instruct Windows to lock the device once the signal strength weakens by more than measurement of 10.

RSSI measurements are relative, and lower as the Bluetooth signals between the two paired devices reduces. A measurement of 0 is stronger than -10. A measurement of -10 is stronger than -60, and indicates that the devices are moving further apart from each other.

IP Configuration

You define IP configuration signals using one or more ipConfiguration elements. Each element has a string value. IpConfiguration elements don't have attributes or nested elements.

IPv4Prefix

The IPv4 network prefix represented in Internet standard dotted-decimal notation. A network prefix that uses the Classless Inter-Domain Routing (CIDR) notation is required as part of the network string. A network port must not be present in the network string. A signal element may only contain one ipv4Prefix element. For example:

<ipv4Prefix>192.168.100.0/24</ipv4Prefix>

The assigned IPv4 addresses in the range of 192.168.100.1 to 192.168.100.254 match this signal configuration.

IPv4Gateway

The IPv4 network gateway represented in Internet standard dotted-decimal notation. A network port or prefix must not be present in the network string. A signal element may only contain one ipv4Gateway element. For example:

<ipv4Gateway>192.168.100.10</ipv4Gateway>

IPv4DhcpServer

The IPv4 DHCP server represented in Internet standard dotted-decimal notation. A network port or prefix must not be present in the network string. A signal element may only contain one ipv4DhcpServer element. For example:

<ipv4DhcpServer>192.168.100.10</ipv4DhcpServer>

IPv4DnsServer

The IPv4 DNS server represented in Internet standard dotted-decimal notation. A network port or prefix must not be present in the network string. The signal element may contain one or more ipv4DnsServer elements.

Example:

<ipv4DnsServer>192.168.100.10</ipv4DnsServer>

IPv6Prefix

The IPv6 network prefix represented in IPv6 network using Internet standard hexadecimal encoding. A network prefix in CIDR notation is required as part of the network string. A network port or scope ID must not be present in the network string. A signal element may only contain one ipv6Prefix element. For example:

<ipv6Prefix>21DA:D3::/48</ipv6Prefix>

IPv6Gateway

The IPv6 network gateway represented in Internet standard hexadecimal encoding. An IPv6 scope ID may be present in the network string. A network port or prefix must not be present in the network string. A signal element may only contain one ipv6Gateway element. For example:

<ipv6Gateway>21DA:00D3:0000:2F3B:02AA:00FF:FE28:9C5A%2</ipv6Gateway>

IPv6DhcpServer

The IPv6 DNS server represented in Internet standard hexadecimal encoding. An IPv6 scope ID may be present in the network string. A network port or prefix must not be present in the network string. A signal element may only contain one ipv6DhcpServer element. For example:

<ipv6DhcpServer>21DA:00D3:0000:2F3B:02AA:00FF:FE28:9C5A%2</ipv6DhcpServer

IPv6DnsServer

The IPv6 DNS server represented in Internet standard hexadecimal encoding. An IPv6 scope ID may be present in the network string. A network port or prefix must not be present in the network string. The signal element may contain one or more ipv6DnsServer elements. For example:

<ipv6DnsServer>21DA:00D3:0000:2F3B:02AA:00FF:FE28:9C5A%2</ipv6DnsServer>

dnsSuffix

The fully qualified domain name of your organization's internal DNS suffix where any part of the fully qualified domain name in this setting exists in the computer's primary DNS suffix. The signal element may contain one or more dnsSuffix elements. For example:

<dnsSuffix>corp.contoso.com</dnsSuffix>

Wi-Fi

You define Wi-Fi signals using one or more wifi elements. Each element has a string value. Wifi elements don't have attributes or nested elements.

SSID

Contains the service set identifier (SSID) of a wireless network. The SSID is the name of the wireless network. The SSID element is required. For example:

<ssid>corpnetwifi</ssid>

BSSID

Contains the basic service set identifier (BSSID) of a wireless access point. the BSSID is the mac address of the wireless access point. The BSSID element is optional. For example:

<bssid>12-ab-34-ff-e5-46</bssid>

Security

Contains the type of security the client uses when connecting to the wireless network. The security element is required and must contain one of the following values:

For example:

<security>WPA2-Enterprise</security>

TrustedRootCA

Contains the thumbprint of the trusted root certificate of the wireless network. You can use any valid trusted root certificate. The value is represented as hexadecimal string, where each byte in the string is separated by a single space. The element is optional. For example:

<trustedRootCA>a2 91 34 aa 22 3a a2 3a 4a 78 a2 aa 75 a2 34 2a 3a 11 4a aa</trustedRootCA>

Sig_quality

Contains numeric value ranging from 0 to 100 to represent the wireless network's signal strength needed to be considered a trusted signal.

For example:

<sig_quality>80</sig_quality>

Sample Trusted Signal Configurations

Example 1

The following example configures an IPConfig signal type using Ipv4Prefix, Ipv4DnsServer, and DnsSuffix elements.

<rule schemaVersion="1.0">
    <signal type="ipConfig">
        <ipv4Prefix>10.10.10.0/24</ipv4Prefix>
        <ipv4DnsServer>10.10.0.1</ipv4DnsServer>
        <ipv4DnsServer>10.10.0.2</ipv4DnsServer>
        <dnsSuffix>corp.contoso.com</dnsSuffix>
    </signal>
</rule>

Example 2

The following example configures an IpConfig signal type using a dnsSuffix element and a Bluetooth signal for phones. The example implies that either the IpConfig or the Bluetooth rule must evaluate to true, for the resulting signal evaluation to be true.

<rule schemaVersion="1.0">
    <signal type="ipConfig">
        <dnsSuffix>corp.contoso.com</dnsSuffix>
    </signal>
</rule>,
<rule schemaVersion="1.0">
    <signal type="Bluetooth" scenario="Authentication" classOfDevice="512" rssiMin="-10" rssiMaxDelta="-10"/>
</rule>

Example 3

The following example configures the same as example 2 using compounding and elements. The example implies that the IpConfig and the Bluetooth rule must evaluate to true, for the resulting signal evaluation to be true.

<rule schemaVersion="1.0">
<and>
  <signal type="ipConfig">
   <dnsSuffix>corp.microsoft.com</dnsSuffix>
  </signal>
  <signal type="Bluetooth" scenario="Authentication" classOfDevice="512" rssiMin="-10" rssiMaxDelta="-10"/>
</and>
</rule>

Example 4

The following example configures Wi-Fi as a trusted signal.

<rule schemaVersion="1.0">
  <signal type="wifi">
    <ssid>contoso</ssid>
    <bssid>12-ab-34-ff-e5-46</bssid>
    <security>WPA2-Enterprise</security>
    <trustedRootCA>a2 91 34 aa 22 3a a2 3a 4a 78 a2 aa 75 a2 34 2a 3a 11 4a aa</trustedRootCA>
    <sig_quality>80</sig_quality>
  </signal>
</rule>

Configure multi-factor unlock

To configure multi-factor unlock you can use:

• Microsoft Intune/CSP
• Group policy

The following instructions provide details about how to configure your devices. Select the option that best suits your needs.

Troubleshoot

Multi-factor unlock writes events to event log under Application and Services Logs\Microsoft\Windows\HelloForBusiness with the category name Device Unlock.

Events