Windows Hello for Business Provisioning Failure: Fix Event ID 360, TPM Issues & Certificate Errors

Published · Windows Hello for Business · Intune · Hybrid Identity

Windows Hello for Business (WHfB) provisioning failures are among the most frustrating issues an endpoint administrator can face. The failure is often silent — users simply receive a password prompt at logon instead of being guided through PIN setup, with no obvious error on screen. The provisioning engine quietly aborts, and without knowing where to look, the root cause can remain hidden for days.

This guide is aimed at experienced IT admins managing WHfB in hybrid or cloud-only Entra environments via Microsoft Intune. We will walk through the key event IDs, prerequisites checklist, TPM pitfalls, certificate sync issues, and Intune policy conflicts that commonly derail provisioning — plus PowerShell commands to verify state and recover.

Where WHfB Provisioning Lives in Event Viewer

Before diving into fixes, you need to know where to look. WHfB provisioning events are written to a dedicated operational log, not the standard Application or System logs where most admins look first.

Open Event Viewer and navigate to:

Applications and Services Logs > Microsoft > Windows > User Device Registration > Admin

This log contains all WHfB provisioning activity. The events you must know are:

Prerequisites Checklist

The WHfB provisioning engine checks a series of conditions at every logon. If any single condition is not met, Event ID 360 is written and provisioning is skipped for that logon. The device retries at the next logon — there is no automatic retry within the same session.

TPM Issues: The Most Common Silent Killer

TPM problems are responsible for a significant proportion of WHfB provisioning failures, particularly on older hardware or in virtual machine environments. The TPM is the hardware root of trust for the WHfB private key — without it, WHfB cannot provision.

TPM 1.2 vs TPM 2.0

TPM 1.2 is supported for WHfB key trust deployments, but it comes with significant limitations. TPM 1.2 does not support attestation, which means cloud trust and certificate trust deployments that require key attestation will fail. If you are deploying WHfB cloud trust (the recommended modern path), TPM 2.0 is effectively mandatory. Check the TPM version with:

# Get TPM status and version
$tpm = Get-Tpm
Write-Host "TPM Present:    $($tpm.TpmPresent)"
Write-Host "TPM Ready:      $($tpm.TpmReady)"
Write-Host "TPM Enabled:    $($tpm.TpmEnabled)"
Write-Host "TPM Activated:  $($tpm.TpmActivated)"
Write-Host "TPM Owned:      $($tpm.TpmOwned)"

# Get TPM specification version from WMI
$tpmWmi = Get-WmiObject -Namespace "root\cimv2\security\microsofttpm" -Class Win32_Tpm
Write-Host "TPM Spec Version: $($tpmWmi.SpecVersion)"

# Check for lockout condition
Write-Host "Locked Out:     $($tpm.TpmOwned -eq $false -and $tpm.TpmEnabled -eq $true)"

Dictionary Attack Lockout (Event ID 1026)

TPM dictionary attack lockout is a frequently overlooked failure mode. After a defined number of failed PIN attempts or TPM operations, the TPM enters a lockout state and refuses further operations for an exponentially increasing cooldown period. When this occurs, WHfB key creation fails silently from the user perspective.

Look for Event ID 1026 in the System log (not the User Device Registration log). The source is TPM-WMI and the message reads: "TPM hardware cannot be provisioned automatically."

# Check current TPM lockout status
$tpm = Get-Tpm
Write-Host "Lockout Count:   $($tpm.LockoutCount)"
Write-Host "Lockout HealTime: $($tpm.LockoutHealTime)"

# If authorized, reset lockout (requires TPM owner auth)
if ($tpm.TpmOwned) {
    Reset-TpmLockout
    Write-Host "TPM lockout counter reset successfully."
} else {
    Write-Host "TPM not owned by OS — lockout reset not available. BIOS intervention required." -ForegroundColor Red
}

# Alternative: clear lockout via tpm.msc (TPM Management Console)
# Or: UEFI/BIOS firmware TPM reset option

Diagnosing the Primary Refresh Token (PRT)

Event ID 362 — "Enterprise STS authentication failed" — almost always means the user does not have a valid Primary Refresh Token (PRT). The PRT is the session credential that WHfB provisioning uses to authenticate to Entra ID to register the new key credential. Without a PRT, the provisioning engine cannot obtain the token it needs to call the key registration endpoint.

# Run dsregcmd /status and parse key fields
$dsreg = dsregcmd /status

# Display join and PRT state
$dsreg | Select-String -Pattern "AzureAdJoined|WorkplaceJoined|AzureAdPrt|PrtUpdateTime|PrtExpiry|OnPremTgt|AzureAdTgt"

# Key fields to check:
# AzureAdJoined : YES           -> device is Entra joined
# AzureAdPrt    : YES           -> user has a valid PRT (provisioning CAN proceed)
# AzureAdPrt    : NO            -> no PRT; provisioning WILL fail with Event ID 362
# PrtUpdateTime : recent        -> PRT was refreshed recently
# OnPremTgt     : YES           -> Kerberos TGT for on-prem (hybrid join only)

Common reasons for a missing PRT include: the user is logged on with a local account cached credential (not an Entra-backed logon), Conditional Access policies blocking token issuance (for example, a compliant device policy that the device fails at that moment), or network issues preventing the device from reaching login.microsoftonline.com.

Certificate and Key Sync Issues (Hybrid Environments)

In hybrid Entra join deployments, WHfB uses the msDS-KeyCredentialLink attribute on the user object in Active Directory to store the public key. After the device registers a WHfB key with Entra ID, Microsoft Entra Connect (formerly Azure AD Connect) must synchronise this attribute back to on-premises AD before hybrid users can authenticate with WHfB for resources requiring Kerberos.

# Run on the Microsoft Entra Connect server

# Force immediate delta sync
Start-ADSyncSyncCycle -PolicyType Delta

# Verify sync status
Get-ADSyncConnectorRunStatus

# Check msDS-KeyCredentialLink on the user object (run on a DC)
Import-Module ActiveDirectory
$user = "jdoe@contoso.com"
Get-ADUser -Filter {UserPrincipalName -eq $user} -Properties msDS-KeyCredentialLink |
    Select-Object -ExpandProperty "msDS-KeyCredentialLink"

# If the attribute is empty after provisioning, the key has not synced yet
# Wait for the next sync cycle or trigger manually as above

Intune Policy Issues: Conflicts, Deprecated Profiles, and Cloud Trust

Intune policy misconfiguration is a leading cause of WHfB provisioning failures in Intune-managed environments, particularly as the console has evolved and older profile types have been deprecated. Peter van der Woude has written extensively on Intune policy layering and conflict resolution — understanding policy precedence is essential before troubleshooting WHfB policy specifically.

Deprecated Identity Protection Profile

The Identity Protection profile type for WHfB configuration in Intune is deprecated. Microsoft has replaced it with the Account Protection profile under Endpoint Security. If you have an existing Identity Protection profile and have also deployed an Account Protection profile to the same users or devices, you will have a policy conflict. The conflict prevents WHfB from being configured correctly and results in Event ID 360 with error code 0x801C03F2 (policy not present) or inconsistent application.

Settings Catalog vs Account Protection

You can also configure WHfB via the Settings Catalog using the PassportForWork CSP settings. However, mixing Settings Catalog policies with Account Protection profiles targeting the same settings on the same scope creates conflicts. Pick one delivery mechanism and be consistent. The PassportForWork CSP reference on Microsoft Learn documents every configurable node.

Cloud Trust Configuration Requirements

WHfB Cloud Trust (Kerberos Cloud Trust) is the recommended deployment model for hybrid environments from Windows 11 22H2 onward. It eliminates the need for an on-premises PKI and the certificate sync dependency described above. However, the Intune policy must be configured correctly:

Connectivity Requirements for Hybrid Deployments

Hybrid WHfB (key trust or cloud trust) requires line-of-sight to a domain controller at two specific points: during provisioning (to obtain a Kerberos TGT) and at every subsequent WHfB logon. If devices are primarily off-network (remote workers), you must ensure one of the following:

• Always On VPN configured to connect before user logon (Device Tunnel) so DC connectivity is available during the authentication phase
• DirectAccess (legacy — not recommended for new deployments)
• Entra Cloud Trust with Azure AD Kerberos — this model eliminates the DC connectivity requirement for initial Kerberos ticket issuance, because the Kerberos service ticket is issued by Entra ID via the Azure AD Kerberos server object, not by an on-premises DC

Full Diagnostic Script

The following script collects all relevant WHfB provisioning diagnostic information from a device and outputs a structured report. Run it as the affected user (not SYSTEM or admin) to capture user-context state correctly, particularly for PRT and WHfB key status.

#Requires -RunAsAdministrator
param(
    [string]$OutputPath = "$env:TEMP\WHfB-Diagnostics-$(Get-Date -Format 'yyyyMMdd-HHmm').txt"
)

$report = [System.Collections.Generic.List[string]]::new()
$report.Add("=== WHfB Diagnostic Report === $(Get-Date)")
$report.Add("")

# Section 1: Device join state
$report.Add("--- DEVICE JOIN STATE ---")
$dsreg = dsregcmd /status
$dsreg | Select-String "AzureAdJoined|WorkplaceJoined|AzureAdPrt|PrtUpdateTime|PrtExpiry|DomainJoined|TenantName|DeviceId" |
    ForEach-Object { $report.Add($_.Line.Trim()) }

# Section 2: TPM state
$report.Add(""); $report.Add("--- TPM STATE ---")
$tpm = Get-Tpm
$report.Add("Present:   $($tpm.TpmPresent)")
$report.Add("Ready:     $($tpm.TpmReady)")
$report.Add("Enabled:   $($tpm.TpmEnabled)")
$report.Add("Owned:     $($tpm.TpmOwned)")
$report.Add("Lockout:   $($tpm.LockoutCount) attempts")
try {
    $tpmWmi = Get-WmiObject -Namespace "root\cimv2\security\microsofttpm" -Class Win32_Tpm -EA Stop
    $report.Add("Version:   $($tpmWmi.SpecVersion)")
} catch { $report.Add("Version:   Could not retrieve (WMI error)") }

# Section 3: Recent WHfB events
$report.Add(""); $report.Add("--- USER DEVICE REGISTRATION EVENTS (last 48h) ---")
Get-WinEvent -LogName "Microsoft-Windows-User Device Registration/Admin" `
    -MaxEvents 50 -EA SilentlyContinue |
    Where-Object { $_.TimeCreated -gt (Get-Date).AddHours(-48) } |
    Select-Object TimeCreated, Id, LevelDisplayName, Message |
    ForEach-Object { $report.Add("[$($_.TimeCreated)] ID $($_.Id) [$($_.LevelDisplayName)] $($_.Message.Split("`n")[0])") }

# Section 4: Intune MDM enrollment
$report.Add(""); $report.Add("--- MDM ENROLLMENT ---")
$mdm = Get-ChildItem "HKLM:\SOFTWARE\Microsoft\Enrollments" -EA SilentlyContinue |
    Get-ItemProperty | Where-Object { $_.EnrollmentType -ne $null }
$mdm | ForEach-Object { $report.Add("Enrollment: $($_.ProviderID) | Type: $($_.EnrollmentType) | UPN: $($_.UPN)") }

# Section 5: PassportForWork registry
$report.Add(""); $report.Add("--- PASSPORTFORWORK POLICY REGISTRY ---")
$pfwPath = "HKLM:\SOFTWARE\Microsoft\PolicyManager\current\device\PassportForWork"
if (Test-Path $pfwPath) {
    Get-ItemProperty $pfwPath | ForEach-Object {
        $_.PSObject.Properties | Where-Object { $_.Name -notlike "PS*" } |
            ForEach-Object { $report.Add("  $($_.Name) = $($_.Value)") }
    }
} else { $report.Add("PassportForWork policy key NOT FOUND — WHfB policy may not be applied") }

# Write report
$report | Out-File -FilePath $OutputPath -Encoding UTF8
Write-Host "Diagnostic report saved to: $OutputPath" -ForegroundColor Green

Step-by-Step Remediation Workflow

Use this sequence when a device is not provisioning WHfB and you need to work through the issue systematically:

1. Open Event Viewer, navigate to Applications and Services Logs > Microsoft > Windows > User Device Registration > Admin. Look for Event IDs 358 or 360 around the last user logon time.
2. If Event ID 360 is present, read the full Description for the error code. Map it using the table at the top of this article.
3. Run dsregcmd /status as the affected user. Confirm AzureAdJoined: YES and AzureAdPrt: YES.
4. Run Get-Tpm and confirm TpmReady: True. Check for lockout count > 0.
5. In the Intune portal, check that the WHfB Account Protection policy is deployed, assigned, and shows success in the device compliance/configuration status. Check for conflicts (yellow triangle icon).
6. If hybrid: verify Entra Connect sync is running and msDS-KeyCredentialLink is populated post-provisioning.
7. Sign out and sign back in after any policy or infrastructure change. WHfB provisioning is triggered at logon — it does not re-evaluate mid-session.
8. After a successful logon attempt, look for Event ID 358 (provisioning launched) followed by a PIN setup prompt. If provisioning completes successfully you will see Event ID 300 or a new WHfB key in the Entra portal under the user's Authentication Methods.

Official References

• Windows Hello for Business Deployment Issues — Microsoft Learn
• Windows Hello for Business Overview and Deployment Guide — Microsoft Learn
• PassportForWork CSP Reference — Microsoft Learn