Windows Hello for Business Deployment: How to Fix the 7 Certificate and Trust Failures That Block Phishing-Resistant MFA Rollout

The trust model determines how WHfB-authenticated devices obtain Kerberos tickets for on-premises resources. Choosing the wrong model causes deployment to succeed but on-premises access to fail.

Cloud Kerberos trust (recommended for new deployments): Entra ID issues a partial Kerberos TGT that the on-premises KDC converts to a full TGT. Requires:

• Entra Connect version 2.1.16.0 or later
• Azure AD Kerberos object in each on-premises domain: Set-AzureADKerberosServer
• Windows 10 21H2 / Windows 11 21H2 or later
• No PKI infrastructure required

Hybrid certificate trust (legacy): Each device receives a certificate from the on-premises CA during provisioning. The certificate is used to authenticate to on-premises resources. Requires:

• Enterprise CA with a certificate template for WHfB
• NDES or CES/CEP for certificate enrollment
• CRL distribution points accessible from all devices

Key trust: No certificates or cloud Kerberos. Requires Windows Server 2016+ DCs. On-premises Kerberos authentication uses the WHfB public key directly. Lowest infrastructure requirement but requires 2016+ DCs for all authentication paths.

For most organizations deploying or migrating today: use cloud Kerberos trust. Set it up:

# Install the Azure AD Kerberos object in each domain
Import-Module AzureADHybridAuthenticationManagement
Set-AzureADKerberosServer -Domain 'domain.com' `
    -DomainCredential (Get-Credential) `
    -CloudCredential (Get-Credential)

All provisioning activity is recorded in the Microsoft-Windows-HelloForBusiness/Operational log:

# Read WHfB operational events from the last 24 hours
Get-WinEvent -LogName 'Microsoft-Windows-HelloForBusiness/Operational' `
    -StartTime (Get-Date).AddHours(-24) `
    | Select-Object TimeCreated, Id, Message `
    | Format-List

Key event IDs:

• Event 1: Provisioning started
• Event 300: Provisioning succeeded -- WHfB credential created
• Event 358: Provisioning failed -- error code in the message identifies cause
• Event 360: PIN change failed
• Event 3010: WHfB policy is configured via MDM (Intune)
• Event 1101: Certificate enrollment result during certificate trust provisioning

For Event 358, extract the error code:

Get-WinEvent -LogName 'Microsoft-Windows-HelloForBusiness/Operational' `
    | Where-Object {$_.Id -eq 358} `
    | Select-Object TimeCreated, @{N='ErrorCode';E={$_.Properties[0].Value}}, Message `
    | Format-List

Common error codes in Event 358:

• 0x80090011: TPM error -- key creation failed, TPM may need clearing
• 0x801C0451: Certificate enrollment failed (certificate trust only)
• 0x801C044D: Entra ID join required but device is not joined
• 0x801C03ED: MFA required for provisioning but not satisfied
• 0x801C0003: WHfB disabled by policy

TPM attestation failures prevent WHfB from creating the hardware-backed key:

Failure 1: TPM not ready or not owned

# Check TPM status
Get-Tpm | Select-Object TpmPresent, TpmReady, TpmEnabled, TpmActivated, ManufacturerVersionInfo

If TpmReady = False, the TPM needs initialization. On Windows 10/11: Settings > Windows Security > Device Security > Security processor details > Troubleshoot security processor.

Failure 2: TPM firmware version not supported Some older TPM firmware versions have known vulnerabilities (ROCA, Infineon weak key). Entra ID attestation rejects these. Check:

(Get-Tpm).ManufacturerVersion

Compare against Microsoft's supported TPM firmware list. Update TPM firmware via the device manufacturer's firmware update utility.

Failure 3: Secure Boot disabled WHfB requires Secure Boot on devices enrolling with attestation. Verify in UEFI settings and confirm:

Confirm-SecureBootUEFI
# Returns True if Secure Boot is enabled

Failure 4: Virtual TPM on non-attested VM Hyper-V VMs with virtual TPMs can complete provisioning but cannot attest to physical hardware. For VDI environments, disable the TPM attestation requirement in the WHfB Intune policy (set 'Require attestation' to Not required) if physical TPMs are not available.

Conflicting Intune policies are the most common cause of WHfB provisioning failures on Intune-managed devices:

Conflict source 1: Both Identity Protection policy and Endpoint Security policy configure WHfB Intune has two places to configure WHfB: Devices > Configuration > Identity Protection, and Endpoint Security > Account Protection > Windows Hello for Business. If both are configured with conflicting settings, the device receives conflicting MDM policies and may fail provisioning.

Diagnose conflicts from the device:

# Check all WHfB-related MDM policies applied to the device
$whfbPath = 'HKLM:\SOFTWARE\Microsoft\PolicyManager\current\device\PassportForWork'
Get-ChildItem $whfbPath -Recurse | Get-ItemProperty

Conflict source 2: GPO overriding Intune MDM policy For hybrid-joined devices, a GPO in Computer Configuration > Administrative Templates > Windows Components > Windows Hello for Business may conflict with the Intune policy. MDM policy takes precedence over GPO for cloud-managed devices, but conflicts can cause unpredictable behavior.

Check the effective WHfB GPO on the device:

gpresult /Scope Computer /v | Select-String -Pattern "Hello|Passport" -Context 2

Conflict source 3: 'Use Windows Hello for Business' set to Disabled in any policy Any policy that sets 'Use Windows Hello for Business' to Disabled blocks provisioning for the entire device regardless of other settings. Search all GPOs and Intune policies for this setting.

After provisioning completes, validate the credential is correctly registered:

# Check if WHfB credential exists on the device
$ngcPath = 'C:\Windows\ServiceProfiles\LocalService\AppData\Local\Microsoft\Ngc'
if (Test-Path $ngcPath) {
    Get-ChildItem $ngcPath -Recurse | Select-Object FullName, LastWriteTime
} else {
    Write-Output "NGC folder not found -- WHfB credential not provisioned"
}

# Check Entra ID device registration and key registration
dsregcmd /status | Select-String -Pattern "AzureAdJoined|DomainJoined|WamDefaultSet|NgcSet|NgcKeyId"

Expected output for a successful WHfB provisioning:

AzureAdJoined : YES
NgcSet : YES
NgcKeyId : {key-id-guid}

If NgcSet is NO after the user has attempted to set up a PIN:

1. Check Event 358 in WHfB/Operational log
2. Verify TPM is ready: Get-Tpm
3. Verify Entra ID registration: dsregcmd /debug
4. Force re-registration: dsregcmd /leave then dsregcmd /join

For at-scale validation, query Entra ID for devices with WHfB registered:

# Devices with WHfB key registered (Entra ID)
Get-MgDevice -Filter "accountEnabled eq true" -All `
    | Where-Object {$_.AlternativeSecurityIds -ne $null} `
    | Where-Object {$_.AlternativeSecurityIds.Type -eq 2} `
    | Measure-Object
# Type 2 = WHfB public key registered