Windows Hello for Business (WHfB) already gives you two factors: something you have (the device-bound key) and something you know or are (a PIN or biometric). For most organisations that is plenty. But if a user's PIN can be shoulder-surfed, or people share credentials, "device plus PIN" is weaker than it looks. Trusted signal unlock - the feature most admins have never configured - adds a third requirement: the device only unlocks when it can also see a trusted signal, like a specific Wi-Fi network or a paired phone in Bluetooth range. This post shows exactly how to configure it, GUIDs and signal XML included.
The problem: device plus PIN is not always enough
WHfB unlock normally succeeds on one factor from one category - a PIN, or a fingerprint, or a face. That is fine at a desk. It is not fine when the threat model includes an observed PIN, a shared workstation on a factory floor, or a high-assurance area where physical presence should be part of the check. What you want is: "unlock only if the user proves themselves and the machine is somewhere it is supposed to be." That is what trusted signal unlock delivers, without a custom credential provider and without leaving the familiar Windows sign-in.
Why it happens: two factor groups, one from each
The feature defines two categories of credential provider, and the user must satisfy at least one provider from each before Windows lets them to the desktop:
- First unlock factor - who the user is: PIN, fingerprint, or facial recognition.
- Second unlock factor - a trusted signal: the device is on a known network or near a paired device.
Each provider is identified by a globally unique identifier (GUID). These are the only supported ones - do not invent others:
| Category | Provider | GUID |
|---|---|---|
| First factor | PIN | {D6886603-9D2F-4EB2-B667-1971041FA96B} |
| First factor | Fingerprint scan | {BEC09223-B018-416D-A0AC-523971B639F5} |
| First factor | Facial recognition | {8AF662BF-65A0-4D0A-A540-A338A999D36F} |
| Second factor | Trusted Signal (Bluetooth, IP config, Wi-Fi) | {27FBDB57-B613-4AF2-9D7E-4FA7A66C21AD} |
How to verify: the Device Unlock event log
Trusted signal unlock writes to its own operational log: Applications and Services Logs › Microsoft › Windows › HelloForBusiness, category Device Unlock. The event IDs tell you exactly what happened at each unlock:
| Event ID | Meaning |
|---|---|
| 3520 | Unlock attempt initiated |
| 5520 | Unlock policy not configured |
| 6520 | Warning event |
| 7520 | Error event |
| 8520 | Success event |
Seeing 5520 ("Unlock policy not configured") on a device you targeted means the policy has not applied - check assignment and the credential-provider GUIDs before assuming the signal is at fault.
DontDisplayLastUserName security policy is known to interfere with trusted signal unlock - test them together.The fix: enable the policy and define the factors
Group Policy
| Group policy path | Setting | Value |
|---|---|---|
| Computer Configuration \ Administrative Templates \ Windows Components \ Windows Hello for Business | Configure device unlock factors | Enabled |
Then set the first-factor list to a comma-separated set of GUIDs (order does not matter) and the second-factor list to the trusted-signal GUID.
Intune
Use the Settings Catalog category Administrative Templates › Windows Hello for Business › Device Unlock Plugins, or a custom policy against the PassportForWork CSP node ./Device/Vendor/MSFT/PassportForWork/DeviceUnlock. Configure the first and second factor provider lists, then supply the signal rules.
Defining the trusted signal: the rules XML
The trusted-signal provider is driven by a signal rules XML document. Each rule opens with a rule element carrying schemaVersion="1.0" and contains one or more signal elements of type Bluetooth, ipConfig, or wifi. Here is a corporate-network rule - the device is "trusted" only when it sits on your internal subnet with your DNS suffix:
Prefer a paired phone as the presence check? Use a Bluetooth signal. The rssiMin and rssiMaxDelta attributes control how close "in range" means:
You can combine rules. Separate rule elements with a comma and either can satisfy the signal (a logical OR); wrap signals in an <and> element to require both (a logical AND). Wi-Fi rules match on ssid, and optionally bssid, security (for example WPA2-Enterprise), and a trustedRootCA thumbprint so an attacker cannot spoof your SSID on an open access point.
classOfDevice="512" is the Bluetooth class for phones. The RSSI values are relative - 0 is stronger than -10, and -10 is stronger than -60. Microsoft's advice is to keep the default rssiMin="-10" / rssiMaxDelta="-10" and test per environment, because the same numbers behave differently in different offices. When the XML is deployed it must be a single line - the multi-line examples here are only wrapped for readability.Proof it worked: a clean unlock in the event log
Success is a targeted device that opens only when both factors are satisfied, and a HelloForBusiness/Operational log showing a 3520 (attempt) followed by an 8520 (success) for each unlock - with no 5520 ("policy not configured") or 7520 (error). A user off the trusted network or away from the paired device is held at the lock screen, which is the whole point.
References
- Configure trusted signal unlock (multifactor device unlock)
- PassportForWork CSP - DeviceUnlock
- Windows Hello for Business policy settings
- Why do you need a PIN to use biometrics? (Windows Hello FAQ)
Script for this post is in Daily-Tasks.