Event ID 360: Every Prerequisite That Blocks Windows Hello for Business Provisioning

The Windows Hello for Business provisioning prompt never appears. No error. No toast. The user just never gets asked to set up a PIN. You check Event Viewer and find Event ID 360 in Microsoft-Windows-User Device Registration/Admin: "Windows Hello for Business provisioning will not be launched." Then comes a list of prerequisites — some yes, some no — and one of those failed lines is the entire reason provisioning is blocked.

Event 360 is the most actionable event in the WHfB troubleshooting toolkit because it tells you exactly which condition failed. The message body has up to a dozen distinct prerequisite lines, each with its own cause and fix. This post goes through every one of them.

The problem: WHfB provisioning silently blocked

When a user signs into a device that meets WHfB requirements, Windows evaluates a set of prerequisites in the background. If all are met, it launches the provisioning flow — the "Set up a PIN" prompt appears. If any prerequisite fails, Windows logs Event 360 and silently exits without showing anything to the user.

The user experience is identical whether provisioning was never attempted or was blocked: the Sign-in options page still shows "Windows Hello is not set up" and no prompt ever appears. Without checking Event Viewer, there is no way to know the evaluation happened and failed.

How to find Event 360 in Event Viewer and PowerShell

Option 1 — Event Viewer (GUI)

Open Event Viewer and navigate to the User Device Registration log. This is not a standard Windows Logs path — it lives under Applications and Services Logs:

Filter for Event ID 360. The most recent entry is the one to read first — it reflects the current state. The General tab in the bottom pane shows the full prerequisite list. The lines are plain English in the event itself — for example “Device is Azure Active Directory-joined ( AADJ or DJ++ ): Yes” and “User has successfully authenticated to the enterprise STS: No”. The camelCase names you may have seen elsewhere (IsDeviceJoined, PolicyEnabled, CertEnrollment, PreReqResult) come from the NGC Prerequisite Check section of dsregcmd /status, which is a different surface reporting the same conditions.

Here is Event 360 captured from a Hybrid-joined Windows 11 device. The blocked lines are immediately visible — post-logon provisioning is disabled and the user signed in with domain credentials rather than Entra credentials:

Option 2 — PowerShell (faster for remote or bulk)

This command pulls the last 5 Event 360 entries and colour-codes each prerequisite line so No values stand out immediately:

# Run as the signed-in user (not SYSTEM)
$events = Get-WinEvent -LogName 'Microsoft-Windows-User Device Registration/Admin' |
    Where-Object { $_.Id -eq 360 } |
    Select-Object -First 5

foreach ($e in $events) {
    Write-Host "=== Event 360 @ $($e.TimeCreated.ToString('yyyy-MM-dd HH:mm:ss')) ===" -ForegroundColor Cyan
    $e.Message -split "\`n" | ForEach-Object {
        $line = $_.Trim()
        if (-not $line) { return }
        if     ($line -match ': No$')   { Write-Host "  $line" -ForegroundColor Red   }
        elseif ($line -match ': Yes$')  { Write-Host "  $line" -ForegroundColor Green }
        else                            { Write-Host "  $line" -ForegroundColor Gray  }
    }
}

=== Event 360 @ 2026-09-17 09:54:06 ===
  Windows Hello for Business provisioning will not be launched.
  Device is Microsoft Entra joined (or hybrid joined): Yes
  User has logged on with Microsoft Entra credentials: No
  Windows Hello for Business policy is enabled: Yes
  Windows Hello for Business post-logon provisioning is enabled: No
  Local computer meets Windows Hello for business hardware requirements: Yes
  User is not connected to the machine via Remote Desktop: Yes
  User certificate for on premise auth policy is enabled: No
  Machine is governed by none policy.
  Cloud trust for on premise auth policy is enabled: Yes
  User account has Cloud to OnPrem TGT: Not Tested

Primary blockers: no Entra sign-in (no PRT) + post-logon provisioning disabled by policy.

Every prerequisite line decoded

Every line in Event 360 is a prerequisite check. The output below simulates a typical blocked state — two lines show No and provisioning will not launch until both are fixed. Use the table beneath to decode every line.

• Red = hard blocker   • Amber = context-dependent (may not apply to your deployment model)

The fix: force provisioning to re-evaluate after resolving a prerequisite

WHfB provisioning re-evaluates automatically at the next user sign-in. If the user is already signed in when you fix a prerequisite, they must sign out and sign back in. There is no "trigger now" button from the admin side.

Fix 1 — User signed in with domain credentials (most common on Hybrid)

The user must sign out and sign back in using their work/Entra account. Then verify a PRT was issued:

# Force Entra to issue a new PRT for the current user
dsregcmd /refreshprt

Start-Sleep -Seconds 25

# Check whether a PRT was issued
$prt = (dsregcmd /status | Select-String 'AzureAdPrt\s*:').Line
Write-Host $prt -ForegroundColor (if ($prt -match 'YES') { 'Green' } else { 'Red' })
# If still NO: device cannot reach Entra ID. Check network, VPN, Conditional Access.

Fix 2 — No policy reaching the device

Force a policy sync and confirm the WHfB profile has applied:

# Force Intune MDM sync
Get-ScheduledTask | Where-Object { $_.TaskName -eq 'PushLaunch' } | Start-ScheduledTask

# Force Group Policy refresh (Hybrid only)
gpupdate /force

# Confirm WHfB policy arrived via registry
Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\PassportForWork' -ErrorAction SilentlyContinue
# Enabled = 1 means policy arrived and WHfB is on
# Key absent = Not Configured (policy not reaching device yet)
# Enabled = 0 = policy arrived but WHfB is explicitly disabled

Reading dsregcmd /status — what healthy looks like

Run dsregcmd /status as the signed-in user to confirm the join state. On a healthy Hybrid-joined device you should see both AzureAdJoined: YES and DomainJoined: YES:

The User State section confirms WHfB is enrolled: NgcSet: YES means the NGC container exists and Windows Hello for Business keys are provisioned for this user:

The SSO State section confirms the Primary Refresh Token is valid and Cloud Kerberos Trust is working — both required for WHfB provisioning to succeed on a Hybrid-joined device:

Proof it worked: Event 362

After the user signs out and back in following your fix, watch for Event ID 362 in the same log. Event 362 means provisioning completed successfully and the NGC container was created.

# NgcSet: YES = WHfB enrolled, NGC container created
dsregcmd /status | Select-String 'NgcSet'

# Also check for Event 362 in the last 24 hours
Get-WinEvent -LogName 'Microsoft-Windows-User Device Registration/Admin' |
    Where-Object { $_.Id -eq 362 -and $_.TimeCreated -gt (Get-Date).AddDays(-1) } |
    Select-Object TimeCreated, Message | Format-List

References

• Troubleshoot Windows Hello for Business — Microsoft Learn
• Deploy Windows Hello for Business: Cloud Kerberos Trust — Microsoft Learn
• Windows Hello for Business event log reference — Microsoft Learn
• Troubleshoot Hybrid Entra joined devices — Microsoft Learn
• Primary Refresh Token (PRT) and Entra ID — Microsoft Learn