Windows Hello for Business (WHfB) is now the front door to most corporate Windows 11 fleets in 2026. Between Microsoft's passwordless push, the RC4 deprecation forcing modern auth, and 24H2 enforcing stricter Hello checks, helpdesks everywhere are seeing a flood of tickets that all look the same on the surface: "Something went wrong and your PIN isn't available." But here's the thing — the error code underneath that friendly message decides whether you spend two minutes on the call or two hours.
This is a field manual for L1/L2 helpdesk engineers who need to triage WHfB issues fast. We'll walk through the deployment models you'll see in the wild (Cloud Kerberos Trust, Key Trust, Certificate Trust), the error codes that actually show up in your queue, the 24H2 regressions that broke previously-working deployments, the Intune PassportForWork CSP conflicts everyone trips over, and the exact PowerShell, dsregcmd, and event log commands that resolve each scenario.
Honestly, if you bookmark one section, make it the error-code table. It's the single biggest time-saver here.
Quick Triage: The First 90 Seconds of a WHfB Ticket
Before you touch anything, gather four facts. They'll tell you which of the five common WHfB failure modes you're staring at:
- Trust type — Cloud Kerberos Trust, Key Trust, or Certificate Trust? Run
dsregcmd /statuson the device. - Join state — Microsoft Entra joined, Entra hybrid joined, or domain joined? Same command.
- Network position — is the device on the corporate LAN with line of sight to a DC, on a VPN, or fully remote on home Wi-Fi?
- Exact error string — the substatus codes after
0xc000006dmatter. Get the full string, not the friendly message.
Run this one-liner first. It gives you about 80% of what you need:
dsregcmd /status | findstr /i "AzureAdJoined DomainJoined TenantName OnPremTgt CloudTgt KerbTopLevelNames NgcSet"The fields you care about most:
- NgcSet : YES — the user has a provisioned Hello container.
- CloudTgt : YES — Entra ID issued a Primary Refresh Token (PRT).
- OnPremTgt : YES — the on-prem DC issued a Kerberos TGT (this is the one that fails most often in Cloud Kerberos Trust).
If OnPremTgt is NO on a hybrid-joined device using Cloud Kerberos Trust, jump straight to the Cloud Kerberos Trust section — don't waste time elsewhere.
WHfB Trust Types in 2026: What's in Your Environment
Microsoft strongly recommends Cloud Kerberos Trust for new deployments because it ditches the on-prem PKI requirement. As of early 2026, most greenfield Intune-managed tenants are already on Cloud Kerberos Trust, while older shops are still running Key Trust or Certificate Trust. The trust type changes how you troubleshoot, so identify it first — full stop.
| Trust Type | How TGT Is Issued | Requires On-Prem PKI? | Common Failure Mode |
|---|---|---|---|
| Cloud Kerberos Trust | Partial TGT from Entra ID, exchanged at on-prem DC | No | AzureADKerberos object missing/broken |
| Key Trust | DC reads msDS-KeyCredentialLink on user object | Yes (NDES + DC certs) | Entra Connect sync delay; "temporarily unavailable" |
| Certificate Trust | User certificate enrolled via NDES/SCEP | Yes (full PKI) | NDES/SCEP enrollment failure |
Cloud Kerberos Trust: The Single Most Common 2026 Issue
In Cloud Kerberos Trust, the on-prem DC can only issue a final Kerberos TGT after receiving a Partial TGT from Entra ID. That partial TGT is signed by an AzureADKerberos computer object in your AD forest. If that object is missing, expired, or has stale keys, every Cloud Kerberos Trust sign-in fails — and your queue lights up with PIN errors all at once.
I've watched this exact scenario hit a 4,000-seat tenant on a Monday morning. We spent about 20 minutes staring at NGC containers before realizing the AzureADKerberos object had silently lost its key rotation. Lesson learned the hard way.
Symptom: Users see "Something went wrong" with status 0xc000006d, substatus 0xc00000d0
This is the canonical Cloud Kerberos Trust failure. The PRT is fine, the device is fine, but the partial TGT exchange is broken. dsregcmd /status shows OnPremTgt : NO.
Step 1 — Verify the AzureADKerberos object exists and is healthy
From a machine with the AzureADHybridAuthenticationManagement module installed (a domain controller or a privileged management box):
Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber
Import-Module AzureADHybridAuthenticationManagement
$cred = Get-Credential # Hybrid Identity Admin in Entra
Get-AzureADKerberosServer -Domain contoso.com -CloudCredential $credYou want to see a KeyVersion that's recent and a DomainDnsName matching your forest. If Get-AzureADKerberosServer returns nothing, or returns an object whose KeyVersion hasn't rotated in over 180 days, recreate it:
Set-AzureADKerberosServer -Domain contoso.com -CloudCredential $cred -DomainCredential (Get-Credential)If it exists but is corrupt, remove and re-add:
Remove-AzureADKerberosServer -Domain contoso.com -CloudCredential $cred -DomainCredential (Get-Credential)
Set-AzureADKerberosServer -Domain contoso.com -CloudCredential $cred -DomainCredential (Get-Credential)After running Set-AzureADKerberosServer, restart the affected client device. OnPremTgt should flip to YES on next sign-in.
Step 2 — Confirm the user is not in a privileged group
This is the trap that catches IT staff testing WHfB on their own admin accounts (yep, guilty). Cloud Kerberos Trust does not work for users who are members of protected/privileged built-in groups — Domain Admins, Enterprise Admins, Schema Admins, Account Operators, Backup Operators, Server Operators, Print Operators, Replicators, and other AdminSDHolder-protected groups. The user's adminCount attribute will be 1.
Get-ADUser jsmith -Properties adminCount,memberOf | Select-Object Name,adminCountIf adminCount is 1, the user must use a separate non-privileged account for daily sign-in, or your environment needs a different trust type for admin accounts.
Step 3 — Check that "Use certificate for on-premises authentication" is NOT enabled
Here's a fun one. If both Cloud Kerberos Trust and the legacy "Use certificate for on-premises authentication" are configured, the certificate trust path takes precedence and Cloud Kerberos Trust gets ignored — silently, of course. In Intune, open your Account Protection profile (or Settings Catalog profile under Windows Hello for Business) and confirm:
- Use cloud trust for on-premises authentication: Enabled
- Use certificate for on-premises authentication: Disabled or Not Configured
Step 4 — Verify line of sight to a DC for first sign-in
On Microsoft Entra hybrid joined devices, the first PIN sign-in after enrollment must reach a domain controller. Subsequent unlocks use cached credentials, but the first one is non-negotiable. Remote employees enrolling at home need either VPN or DirectAccess connectivity to a DC during initial WHfB provisioning. If your enrollment workflow doesn't account for this, you'll see Step 1 sign-ins fail with 0xC000005E — There are currently no logon servers available.
Windows 11 24H2 PIN Regressions: The 2025–2026 Wave
So, 24H2. Microsoft tightened Hello credential validation, which surfaced a class of latent issues that 23H2 was quietly tolerating. The most common manifestation: PIN works after a fresh boot, then breaks after the device resumes from sleep. The PRT silently refreshes in the background, the cached Hello container goes out of sync, and the next unlock fails with 0xc000006d.
It's not technically a Microsoft bug — more like 23H2 was being too forgiving and 24H2 stopped pretending. Either way, your queue doesn't care about semantics.
Helpdesk fix script
This is the script we run on every "PIN broken after sleep on 24H2" ticket. It nukes the corrupt NGC container, forces the user to recreate, and clears stale Web Account Manager state:
# Run as SYSTEM (PsExec -s) or via Intune remediation script
$ngc = "$env:WINDIR\ServiceProfiles\LocalService\AppData\Local\Microsoft\Ngc"
takeown /f $ngc /r /d Y | Out-Null
icacls $ngc /grant administrators:F /t | Out-Null
Remove-Item -Path $ngc -Recurse -Force -ErrorAction SilentlyContinue
New-Item -Path $ngc -ItemType Directory -Force | Out-Null
# Clear Web Account Manager cache
$wam = "$env:LOCALAPPDATA\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy\AC\TokenBroker\Accounts"
Remove-Item -Path "$wam\*" -Recurse -Force -ErrorAction SilentlyContinue
# Force a fresh Hybrid Join sync
dsregcmd /leave
Start-Sleep -Seconds 5
dsregcmd /joinAfter running it, the user signs in once with their password, then re-provisions a new PIN through Settings > Accounts > Sign-in options. On 24H2 specifically, also verify these CSP values aren't set to legacy defaults:
./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/UseCloudTrustForOnPremAuth=True./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/UsePassportForWork=True
Decoding the Error Codes That Show Up in Your Queue
Most WHfB tickets present as one of a small set of error codes. Memorize these — seriously, it cuts diagnosis time in half:
| Error Code | What It Actually Means | First Action |
|---|---|---|
0xc000006d / 0xc00000d0 | Hello credential validation failed; usually NGC container or AzureADKerberos object | Run NGC reset script (see above) |
0xc000005e | No logon servers available — DC unreachable on first sign-in | Connect to VPN; ensure DC line-of-sight |
0x80090036 | TPM operation interrupted during key creation | Run tpm.msc → Clear TPM → reboot → re-provision |
0x80090029 | TPM not prepared | tpm.msc → Action → Prepare the TPM |
0x80090027 | Caller passed wrong parameter (often Intune policy conflict) | Check for duplicate WHfB profiles in Intune |
0x80090031 | NTE_AUTHENTICATION_IGNORED | Reboot; if it persists, Clear-Tpm from elevated PowerShell |
0x80090035 | Policy requires TPM but device has none | Disable "Require TPM" in WHfB policy or replace device |
0x801C03EA | Server token rejected user authorization | Verify license assignment and Conditional Access |
0x801C000E | Maximum number of devices reached for user in Entra ID | Increase per-user device limit or remove stale devices |
Where to find the full error string
Don't trust the friendly UI message. Pull the real event:
Get-WinEvent -LogName "Microsoft-Windows-User Device Registration/Admin" -MaxEvents 50 |
Where-Object { $_.LevelDisplayName -in @('Error','Warning') } |
Format-List TimeCreated, Id, Message
Get-WinEvent -LogName "Microsoft-Windows-HelloForBusiness/Operational" -MaxEvents 50 |
Format-List TimeCreated, Id, Message
Get-WinEvent -LogName "Microsoft-Windows-Kerberos/Operational" -MaxEvents 50 |
Where-Object { $_.Id -in @(107, 313, 314) } |
Format-List TimeCreated, Id, MessageKerberos Event ID 107 with status 0xC000006D nearly always points to a DC certificate that doesn't have the DC's FQDN in the SAN. Update DC certs to include both FQDN and NETBIOS in the Subject Alternative Name and you're done.
Hybrid Key Trust: The "Temporarily Unavailable" Sync Delay
If you're stuck on legacy Key Trust (no Cloud Kerberos Trust yet), the user's public key is written to msDS-KeyCredentialLink on the user object during provisioning. That attribute has to replicate from Entra ID to AD via Microsoft Entra Connect Sync before the user can sign in with their PIN. Until the sync runs, the user sees:
"That option is temporarily unavailable. For now, please use a different method to sign in."
Force a delta sync to skip the wait:
Start-ADSyncSyncCycle -PolicyType DeltaThen verify the attribute populated on the user object:
Get-ADUser jsmith -Properties msDS-KeyCredentialLink |
Select-Object Name, @{N='HasKey';E={[bool]$_.'msDS-KeyCredentialLink'}}If your DCs are still on Server 2019 below build 17763.316 (KB4487044), upgrade them. Older 2016/2019 builds have a known bug where the WHfB key gets deleted after first sign-in and only restored on the next Entra Connect sync — meaning users get one good sign-in, then break. Fun.
Intune PassportForWork CSP: Stop Fighting Yourself
The number-one self-inflicted WHfB outage in 2026 is policy conflict. Hands down. The Identity Protection profile template is deprecated, but existing profiles still apply. If you create a new Account Protection profile or a Settings Catalog profile while an old Identity Protection profile is still targeted at the same users, Windows enforces the most restrictive resulting policy across both — and the user-facing UI may not even mention the conflict exists.
Audit your tenant for duplicate WHfB policies
Use Microsoft Graph to list every profile that touches PassportForWork:
Connect-MgGraph -Scopes "DeviceManagementConfiguration.Read.All"
# Settings Catalog
Get-MgDeviceManagementConfigurationPolicy -All |
Where-Object { $_.TemplateReference.TemplateFamily -match 'Account|Identity' -or $_.Name -match 'Hello|PIN|Passport' } |
Select-Object Id, Name, TemplateReference
# Legacy device configurations (Identity Protection template)
Get-MgDeviceManagementDeviceConfiguration -All |
Where-Object { $_.AdditionalProperties['@odata.type'] -match 'identityProtection' } |
Select-Object Id, DisplayNameConsolidate to one authoritative WHfB policy. Microsoft's recommended path is the Settings Catalog with the Windows Hello for Business category, targeted at users (not devices) — since WHfB credentials are per-user anyway.
The PIN length trap
If your "official" policy says minimum PIN length is 4, but a deprecated profile says 6, users will be forced to set a 6-digit PIN — and the helpdesk will get tickets claiming the policy is wrong. The most restrictive setting wins across all applied profiles. Always. No exceptions.
Web Sign-In and PIN Reset on Entra-Joined Devices
"I forgot my PIN" on the lock screen of a Microsoft Entra joined device kicks off a web sign-in flow. Web sign-in only allows navigation to a Microsoft-defined allowlist of domains. If your Conditional Access or federated IdP forces redirection through a domain that isn't on the allowlist (a custom on-prem ADFS instance, a third-party MFA provider with a non-standard domain), you'll see:
"We can't open that page right now."
The fix is one of two things:
- Add the federation domain to ConfigureWebSignInAllowedUrls via the Policy CSP, or
- Exclude WHfB PIN reset flows from the offending Conditional Access policy.
./Device/Vendor/MSFT/Policy/Config/Authentication/ConfigureWebSignInAllowedUrls
Value (String, semicolon-delimited): fs.contoso.com;mfa.contoso.comFIDO2 Security Keys as a Bypass When PIN Is Broken
When you can't get the user back into Hello fast enough, FIDO2 security keys are a same-day workaround — assuming your tenant has them enabled in Authentication methods. From a working device the user signs in to myaccount.microsoft.com, registers a key under Security info, then signs in to the broken device with the key. This avoids the PIN reset round-trip entirely and is way less disruptive than mailing a temporary access pass overnight.
The Diagnostic Order of Operations
When all else has failed and the ticket is escalating, run this sequence in order:
dsregcmd /status— confirm join state, NgcSet, OnPremTgt, CloudTgt.- Lock screen → Sign-in options → password sign-in to confirm the account itself works.
- Settings > Accounts > Sign-in options > PIN > Remove > recreate.
- If recreate fails, run the NGC reset script above as SYSTEM, reboot, retry.
- If still failing,
Get-WinEventagainst HelloForBusiness/Operational and User Device Registration/Admin to capture the real error. - If the error points to Cloud Kerberos Trust,
Get-AzureADKerberosServeron a DC. - If TPM-related,
tpm.msc→ Clear TPM → reboot → re-enroll device in Intune if necessary. - Last resort: leave Entra/AD with
dsregcmd /leave, reboot, re-join, re-provision Hello.
Frequently Asked Questions
Why does my Windows Hello PIN keep saying "Something went wrong" after the 24H2 update?
Windows 11 24H2 enforces stricter PRT validation. After the device resumes from sleep, the background PRT refresh can fall out of sync with the cached Hello container, breaking the next PIN unlock. The reliable fix is to remove the NGC container (the Hello credential store) and re-provision the PIN. The PowerShell script in this guide does it automatically; for end users, signing in with the password and using Remove → recreate under PIN sign-in options works for most cases.
Can users with Domain Admin rights use Cloud Kerberos Trust?
No. Members of any AdminSDHolder-protected group (Domain Admins, Enterprise Admins, Schema Admins, and friends) cannot authenticate to AD via Cloud Kerberos Trust. They'll sign in to the device with their PIN, but on-prem resource access will fail. Use a separate non-privileged daily-driver account for these users, or deploy a Key Trust or Certificate Trust policy targeted specifically at admin accounts.
Do I still need an on-prem PKI for Windows Hello for Business in 2026?
Not if you're on Cloud Kerberos Trust. That's the main reason Microsoft recommends Cloud Kerberos Trust for greenfield deployments — it eliminates the NDES, SCEP, and on-prem CA infrastructure that Key Trust and Certificate Trust require. You still need writable Server 2016 or later domain controllers, but you don't need an internal PKI.
What's the difference between Windows Hello and Windows Hello for Business?
Windows Hello is the consumer biometric/PIN feature backed by a local TPM key. Windows Hello for Business binds that same biometric/PIN to an asymmetric key pair registered in Microsoft Entra ID and (in hybrid scenarios) Active Directory. Only WHfB satisfies passwordless and phishing-resistant MFA requirements; consumer Hello does not.
Why does my PIN work on the corporate network but fail when I'm at home?
Two likely causes. First, on a hybrid-joined device using Cloud Kerberos Trust, the very first sign-in after enrollment must reach a domain controller — which often means VPN. Second, if your environment uses Key Trust or Certificate Trust, on-prem resource access (file shares, on-prem apps) requires DC connectivity for ticket issuance even if the local sign-in succeeds. Always-On VPN or a SASE solution that proxies authentication is the long-term fix.
How do I force re-enrollment of WHfB for a single user without affecting others?
From the user's device, run certutil.exe -DeleteHelloContainer in an elevated prompt as the affected user, sign out, and sign back in. The next sign-in triggers the WHfB provisioning experience. If the device also has a corrupt cache, follow up with the NGC reset script in this guide before re-enrolling.
Closing the Ticket
Most WHfB tickets resolve in one of three ways: a corrupt NGC container that needs to be wiped (40–50% of tickets in our experience), a Cloud Kerberos Trust configuration drift on the AzureADKerberos object (15–25%), or an Intune policy conflict that nobody realized was active (10–15%). The remainder are TPM, network, or PKI edge cases. Before you escalate, run dsregcmd /status, capture the real event log error, and check for duplicate Intune profiles. That covers the long tail.
The next phase of pain is already visible, by the way: as organizations finish the RC4 deprecation and move to AES-only Kerberos, expect a parallel surge of "I can't sign in to the file server but my PIN works" tickets. Keep klist and setspn handy — you'll need them sooner than you think.
