Windows Hello for Business provisioning errors in Intune: 0x801C03ED, Event 360 and more

Windows Hello for Business provisioning fails in one of two ways: the Create a PIN step stops with a hex code, or the PIN prompt never appears at all. In this post I'll match the documented 0x801C and 0x8009 codes to their causes, decode the Event ID 360 prerequisite lines, untangle conflicting policy sources, and prove the fix with dsregcmd /status.

Symptoms#

• The PIN setup wizard fails and shows one of these codes (the descriptions are Microsoft's):

0x801C03ED Multi-factor authentication is required for a 'ProvisionKey' operation, but wasn't performed.
0x801C000E Registration quota reached.
0x801C03F2 Windows Hello key registration failed.
0x801C044D Authorization token doesn't contain device ID.
0x80090035 Policy requires TPM and the device doesn't have TPM.
0x80090029 TPM isn't set up.

• A user who already has a PIN can't sign in with it: 0xC00000BB Your PIN or this option is temporarily unavailable.
• No PIN prompt appears after sign-in, and Applications and Services Logs › Microsoft › Windows › User Device Registration › Admin holds a warning like this one, posted by an admin on Microsoft Q&A from a PC where the user hadn't signed in with Microsoft Entra credentials:

Event ID 360
Windows Hello for Business provisioning will not be launched.
Device is AAD joined ( AADJ or DJ++ ): Not Tested
User has logged on with AAD credentials: No
Windows Hello for Business policy is enabled: Not Tested
Windows Hello for Business post-logon provisioning is enabled: Not Tested
Local computer meets Windows hello for business hardware requirements: Not Tested
User is not connected to the machine via Remote Desktop: Yes
User certificate for on premise auth policy is enabled: Not Tested
Machine is governed by none policy.
Cloud trust for on premise auth policy is enabled: Not Tested
User account has Cloud TGT: Not Tested

Why it happens#

At every sign-in Windows runs a prerequisite check. If it passes, provisioning starts: the user completes MFA and creates a PIN, and a key pair is generated (in the TPM when available) and registered with Microsoft Entra ID. A failed prerequisite gives you Event 360 and no prompt; a later failure gives you a wizard code. In Event 360, the line that reads No is the one to fix; Not Tested means that check wasn't evaluated. Each line maps to a field in the Ngc Prerequisite Check section of dsregcmd /status:

The wizard codes point to different layers:

How to fix it#

1. Capture the evidence: the wizard code, and the newest Event 360 in the User Device Registration Admin log.
2. Run dsregcmd /status as the user (not elevated). Check AzureAdJoined, AzureAdPrt, NgcSet and the Ngc Prerequisite Check. Fix join problems first; see hybrid join troubleshooting and PRT troubleshooting.
3. Check the TPM if DeviceEligible is NO or you see a 0x8009 code: Get-Tpm should show TpmPresent and TpmReady as True. Clearing a TPM wipes its keys; make sure the BitLocker recovery key is escrowed first.
4. Use one policy source. Windows Hello for Business can come from the tenant-wide policy (Devices › Enrollment, Windows tab, Windows Hello for Business), from settings catalog or Endpoint security › Account protection profiles, and from Group Policy. Make the tenant-wide policy and your profiles agree, and remember the tenant-wide policy applies only at enrollment, so changing it doesn't touch enrolled devices. If a device also gets Windows Hello settings from Group Policy, the conflicting MDM settings aren't applied until the Group Policy settings are cleared; MDMWinsOverGP covers the Policy CSP, not the PassportForWork CSP, so it won't help. Find stray settings with:
   PowerShell

   # Group Policy source (should be empty when Intune manages Windows Hello)
   reg query "HKLM\SOFTWARE\Policies\Microsoft\PassportForWork" /s
   reg query "HKCU\SOFTWARE\Policies\Microsoft\PassportForWork" /s
   # MDM source (one subkey per tenant ID)
   reg query "HKLM\SOFTWARE\Microsoft\Policies\PassportForWork" /s
   # Which GPO sets it?
   gpresult /h "$env:USERPROFILE\Desktop\gp.html"

   For conflicts between Intune profiles, use the MDM diagnostic report as described in finding Intune policy conflicts.
5. Fix the code-specific cause from the table above.
6. Reset and retry. Provisioning is evaluated at the next sign-in, so sign out and back in. For a damaged container (0x8009000F "The container or key already exists", 0x80090011 "The container or key wasn't found"), run certutil.exe -deletehellocontainer as the user and sign out; it deletes the user's Windows Hello container on that device, so they set Windows Hello up again (Microsoft's documented fix for both codes is unjoin and rejoin). For 0x801C0451, delete the token broker files under %LOCALAPPDATA%\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy\AC\TokenBroker\Accounts and reboot. Unjoin and rejoin is Microsoft's catch-all mitigation, but on an Intune device it usually means re-enrolling: keep it for last.

Verify the fix#

• Before the PIN prompt, the User Device Registration log shows Event 358 (Windows Hello for Business provisioning will be launched) and dsregcmd shows PreReqResult : WillProvision.
• After setup, dsregcmd /status shows NgcSet : YES with an NgcKeyId under User State, and AzureAdPrt : YES under SSO State. With cloud Kerberos trust, expect OnPremTgt : YES too.
• On hybrid devices, klist after a PIN sign-in lists a krbtgt ticket for your AD realm.

Key takeaways#

• No prompt means a prerequisite failed (read Event 360); a wizard code means provisioning started (use the code table).
• Configure Windows Hello for Business from one source and set the tenant-wide enrollment setting deliberately.
• Pre-register MFA, clean up stale devices, and check Get-Tpm before you require a security device.

References#

• Windows Hello errors during PIN creation
• Troubleshoot devices by using the dsregcmd command
• Configure Windows Hello for Business
• Configure a tenant-wide Windows Hello for Business policy with Microsoft Intune