When Windows Hello for Business (WHfB) misbehaves, the answer is almost always sitting in an event log - but across three different logs, with cryptic IDs and no index. Admins waste hours in the wrong log or reading the wrong events. This is the catalog: which log holds what, the event IDs that actually matter for WHfB, and what each one is telling you. Bookmark it and stop guessing which log to open.
The problem: WHfB logs to three places, none obvious
There is no single "Windows Hello" log. Provisioning writes to one place, device unlock to another, and token/PRT activity to a third. If you only know about one of them, you will miss the event that explains your problem. Worse, the most useful log - User Device Registration - is buried deep in the Applications and Services tree where nobody looks by default.
Why it happens: each component owns its own log
There is no single "Windows Hello" log because three different Windows components handle three different parts of the credential lifecycle, and each writes to its own operational channel: the device-registration engine records provisioning, the Windows Hello / Passport unlock provider records device unlock, and the Microsoft Entra token broker records PRT and token activity. Nobody consolidated them, so the story of a single Hello failure is split across three places - and the most useful one is buried deep in the Applications and Services tree.
How to verify: pull the events fast
You do not need to click through Event Viewer. Get-WinEvent pulls any of these logs directly - here is the User Device Registration provisioning log, newest first:
Get-WinEvent throws a non-terminating "No events were found that match the specified selection criteria" if a log is empty - which is normal on a healthy device (for example, the Device Unlock log is empty if you never configured trusted-signal unlock). That message is not an error in your query; wrap the call in a try/catch if you are scripting across a fleet so an empty log does not look like a failure.The fix: the three logs and the IDs that matter
Log 1 - User Device Registration (provisioning)
The provisioning story lives here: Event Viewer › Applications and Services Logs › Microsoft › Windows › User Device Registration › Admin. This is where you look when a user is not getting a PIN prompt, or provisioning is failing.
| Event ID | Meaning |
|---|---|
| 358 | Windows Hello for Business provisioning will be launched - the prerequisites passed and enrolment is starting |
| 360 | Windows Hello for Business provisioning will not be launched - a prerequisite failed (a Warning; the detail says which check) |
| 362 | Provisioning blocked because device authentication did not succeed ("User has successfully authenticated to the enterprise STS: No") |
| 363 | The Microsoft Passport (NGC) key is missing |
Event 360 is the one you will see most - and it is a Warning, not an Error, so it is easy to overlook. Its body lists the prerequisite results, mirroring the NGC Prerequisite Check block in dsregcmd /status. Read the two together:
Log 2 - HelloForBusiness (device unlock and Hello operations)
Multifactor / trusted-signal device unlock writes to its own operational log: Applications and Services Logs › Microsoft › Windows › HelloForBusiness › Operational, under the Device Unlock category. When you have configured trusted-signal unlock and want to know whether it is actually working, this is the log:
| Event ID | Meaning |
|---|---|
| 3520 | Unlock attempt initiated |
| 5520 | Unlock policy not configured |
| 6520 | Warning event |
| 7520 | Error event |
| 8520 | Success event |
A clean multifactor unlock is a 3520 followed by an 8520. A 5520 ("policy not configured") on a device you targeted means the policy did not apply - check assignment and the credential-provider GUIDs, not the signal.
Log 3 - AAD (token and PRT activity)
Primary Refresh Token (PRT) acquisition and cloud-auth activity is logged under Applications and Services Logs › Microsoft › Windows › AAD › Operational. This is where sign-in/token problems that underlie an SSO failure surface. In practice, though, the best-formatted PRT diagnostics are not an event ID at all - they are the AcquirePrtDiagnostics block in dsregcmd /status, which gives you the HRESULT, credential type, and exact server error in one place.
AcquirePrtDiagnostics / RefreshPrtDiagnostics block from dsregcmd /status first - it contains the Attempt Status HRESULT and the server error description in plain text. The AAD/Operational log is the deeper backup, not the starting point.Proof it worked: the catalog at a glance
| Symptom | Log to open | Look for |
|---|---|---|
| No PIN prompt / provisioning fails | User Device Registration / Admin | 360 (blocked) + its prerequisite detail; 362 / 363 |
| Provisioning started but stalled | User Device Registration / Admin | 358 (launched), then the following entries |
| Trusted-signal unlock not working | HelloForBusiness / Operational | 5520 (not configured), 7520 (error), 3520→8520 (success) |
| SSO / token failures | dsregcmd first, then AAD / Operational | AcquirePrtDiagnostics block; server error code |
dsregcmd /status, do not choose between them. The event log tells you what happened and when (a 360 at 09:14); dsregcmd tells you the current state and the prerequisite that failed. Together they turn "Hello is broken" into "provisioning was blocked at 09:14 because enterprise STS authentication failed" - which is an answer, not a symptom.References
- Windows Hello for Business known deployment issues (Event 360 / 362)
- Configure trusted signal unlock (Device Unlock event IDs)
- Troubleshoot devices by using the dsregcmd command (PRT diagnostics)
- How Windows Hello for Business provisioning works
Script for this post is in Daily-Tasks.