Enabling multi-factor authentication with Windows Hello: A practical guide

Multi-factor authentication with Windows Hello allows you to take Windows login security to the next level without compromising the user experience. Instead of relying solely on a PIN or biometrics, you can require a combination of factors and trust signals to unlock the device, while also complying with internal or industry regulations.

If you manage an environment with Microsoft Sign In ID (formerly Azure AD) or Microsoft 365, enabling multi-factor unlock (MFA) with Windows Hello for Business is a solid way to prevent prying eyes or credential sharing. Plus, gestures (PIN, face, or fingerprint) are tied to the device and don't travel outside of it, strengthening phishing protection and improving single sign-on. apps and browsers.

What exactly does multi-factor unlocking with Windows Hello for Business solve?

Windows Hello for Business supports a single credential (PIN or biometrics) to unlock the device. This is convenient, but if someone accidentally figures out the PIN, they could try to gain access. By enabling multi-factor unlock, you require the user to combine at least one gesture (e.g., fingerprint) with a trusted signal (e.g., corporate network or Bluetooth proximity) before granting access to the desktop.

The objective is to cover scenarios in which a single factor is not enough.: organizations that don't consider a PIN alone to be sufficient, devices where they want to prevent credential sharing, environments with two-factor requirements, and, very importantly, those who want to maintain the native Windows login experience without resorting to custom third-party solutions.

With MFA in Hello, you can express contextual policies (for example, the device is on corporate Wi-Fi or detects a paired phone nearby). This prevents logins outside the office unless the user provides a valid second factor defined in the policy.

In addition, Windows Hello offers practical benefits in everyday life.: Gestures are device-bound, phishing-resistant, and once in, facilitate SSO with browsers and VPN of the organization, reducing friction and tickets to support.

Architecture and Flow: First and Second Credential Provider

Multi-factor unlocking is supported by two categories of providers: The first unlock credential provider and the second unlock factor provider. Each provider is identified by a unique GUID, and Windows requires the user to satisfy at least one provider from each category to complete the login.

Politics is made up of three parts: 1) the list of providers for the first factor, 2) the list of providers for the second factor, and 3) the trust signal rules that, if included, will be evaluated as part of the second factor to determine if the environment is as expected.

In practice, the user presents a gesture for the first factor (e.g. fingerprint) and then the second factor (e.g. corporate network token or the PIN itself if allowed). Windows only unlocks the desktop when both are satisfied.

Beware of an important nuance: The same provider can be on both lists, but a given credential can only cover one of the factors during the same unlock; that is, each factor can only be used once per login attempt.

Supported Providers and GUIDs: PIN, Biometrics, and Trust Tokens

Windows Hello for Business recognizes multiple credential providers, each represented by a GUID. These are the supported ones, along with their identifiers:

Credential Provider	GUID
PIN	{D6886603-9D2F-4EB2-B667-1971041FA96B}
Fingerprint	{BEC09223-B018-416D-A0AC-523971B639F5}
facial recognition	{8AF662BF-65A0-4D0A-A540-A338A999D36F}
Trust signal (Bluetooth proximity, network, etc.)	{27FBDB57-B613-4AF2-9D7E-4FA7A66C21AD}

 

• Default values ​​by category: The first factor list includes a PIN, fingerprint, and face by default. The second factor list includes the trust token and PIN by default. This allows for very typical scenarios such as "fingerprint + corporate network" or "face + PIN."
• Comma-separated list of GUIDs: You can configure both lists with the GUIDs you want to enable. There's no mandatory order, and even if a provider appears on both lists, remember that its usage is only counted once per unlock attempt.
• Relevant restriction: The trusted signal provider can only be declared as part of the second factor; it is not valid to include it as the first unlocking factor.

Trusted Signal Rules: Bluetooth, IPConfig, and Wi-Fi

Trust signals are defined using XML rules that the signal provider evaluates to decide if the device meets the desired context. Each rule is enclosed in an element rule with the attribute schemaVersion (the current version is 1.0).

Basic structure of a rule (minimum):

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

Within each rule there is at least one element signal with a type or with a value or subelements depending on the type. The supported types are bluetooth, ipConfig y wifi.

Bluetooth: is defined with attributes on the element itself signal. It does not require nested elements and a short closing tag can be used.

Attribute	Price	Required
type	bluetooth	Yes
scenario	Authentication	Yes
classOfDevice	Number (e.g. 512 for Phone)	No
rssiMin	Number (e.g., -10)	No
rssiMaxDelta	Number (e.g., -10)	No

 

Example of Bluetooth signal with proximity to a paired phone:

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

classOfDevice It has Telephone as its default value and is based on this class table:

Description	Price
Others	0
Computer	256
Phone Number	512
LAN/Network Access Point	768
Audio Video	1024
Peripherals	1280
Images	1536
Wearable	1792
Toy	2048
Health/Status	2304
Not qualified	7936

 

rssiMin and rssiMaxDelta help determine when the device is “close enough.” The default value of -10 allows you to move around an office without blocking the equipment, and rssiMaxDelta=-10 tells Windows to block it when the signal weakens more than 10 measures.

Keep in mind the RSSI scale: It is relative and decreases as signal strength decreases. A value of 0 is stronger than -10; -10 is stronger than -60, suggesting that the devices are moving away.

IPConfig: Defined with one or more subelements, each with a string value. Ports and prefixes are not allowed where appropriate, and CIDR notation is often used where applicable.

<ipv4Prefix>192.168.100.0/24</ipv4Prefix>
<ipv4Gateway>192.168.100.10</ipv4Gateway>
<ipv4DhcpServer>192.168.100.10</ipv4DhcpServer>
<ipv4DnsServer>192.168.100.10</ipv4DnsServer>
<ipv6Prefix>21DA:D3::/48</ipv6Prefix>
<ipv6Gateway>21DA:00D3:0000:2F3B:02AA:00FF:FE28:9C5A%2</ipv6Gateway>
<ipv6DhcpServer>21DA:00D3:0000:2F3B:02AA:00FF:FE28:9C5A%2</ipv6DhcpServer>
<ipv6DnsServer>21DA:00D3:0000:2F3B:02AA:00FF:FE28:9C5A%2</ipv6DnsServer>
<dnsSuffix>corp.contoso.com</dnsSuffix>

Wi ‑ Fi: is declared with subelements like SSID (required), BSSID (optional), security type, trusted root certificate, and minimum signal quality.

Countryside	Description
ssid	Wireless network name (required)
bssid	Address MAC from the access point (optional)
security	One of: Open, WEP, WPA-Personal, WPA-Enterprise, WPA2-Personal, WPA2-Enterprise
trustedRootCA	Root certificate fingerprint (space-separated hex)
sig_quality	Required signal quality (0-100)

 

Example of Wi-Fi with enterprise security:

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

Combinations and examples of rules: You can define simple rules or compose several with OR (separate) or AND (composite element) type logic.

<!-- Ejemplo 1: IPConfig con prefijo y DNS -->
<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>

<!-- Ejemplo 2: OR entre IPConfig y Bluetooth para teléfonos -->
<rule schemaVersion=\"1.0\">
<signal type=\"ipConfig\">
<dnsSuffix>corp.contoso.com</dnsSuffix>
</signal>\n</rule>
<rule schemaVersion=\"1.0\">
<signal type=\"bluetooth\" scenario=\"Authentication\" classOfDevice=\"512\" rssiMin=\"-10\" rssiMaxDelta=\"-10\"/>
</rule>

<!-- Ejemplo 3: AND entre IPConfig y Bluetooth -->
<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>

<!-- Ejemplo 4: Wi‑Fi como señal de confianza -->
<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>

How to deploy: Intune/CSP, Group Policy, and enrollment experience

• You can set up multi-factor unlock with There are two main approaches: configuration profiles via Microsoft Intune (CSP) or Group Policy. Choose the method that best suits your device management needs and apply GUID lists for the first and second factors along with signal rules.
• Important: Windows Hello provisioning requires MFA During enrollment, make sure your users have an active method (authentication app, SMS, or FIDO2 key) to complete this step before creating the PIN and recording biometrics.
• Typical registration flow after logging in with password: if he hardware If supported, you're prompted to configure a biometric gesture (face/fingerprint). The wizard then asks you to use Windows Hello with your organization's account and activates the MFA challenge. Once validated, the PIN is created and confirmed, meeting the complexity policy.
• OOBE (over the top experience) scenario: The user joins the device to Microsoft Enter ID, is prompted for MFA during joining, Intune applies the Hello for Business policy, and before entering the desktop, Hello enrollment is completed.
• Once registered, users use their gesture (PIN, face, or fingerprint) to access the device and resources that require Hello for Business. These gestures only work on the device where they were registered, strengthening local security.

Windows Hello and 2FA settings in web services (WebAuthn)

If you already have 2FA with SMS, mobile app or security key, you can add Windows Hello devices as an additional login method. Supported logins will allow you to use the fingerprint sensor or facial recognition instead of physical passcodes or keys.

Setup is simpleAfter enabling 2FA with the base method, go to your security profile and add a “Use Windows Hello” method. This option only appears in browsers that support WebAuthn. During setup, assign a name to your device to distinguish it later.

At the next login you will be able to choose Hello as a second factor. If you prefer, you can opt out and use SMS, the authentication app, or your hardware key; flexibility is maintained at all times as permitted by policy.

technical note: Windows Hello is integrated using the WebAuthn standard, so you'll need a modern browser for it to work correctly on compatible portals and applications.

In university or corporate environments It is also noted that, when starting with Hello, the user is automatically authenticated in the main browsers and in the VPN, reducing the need for repetitive second factors in internal services.

To close the circleCombining Hello for Business with well-defined trust signals, requiring MFA on enrollment, and monitoring events gives you an excellent balance of security and convenience, while also aligning with regulatory requirements and providing a native Windows startup experience that users embrace without resistance.