Users never get the PIN setup prompt. Or they do, finish biometrics, and see That option is temporarily unavailable. Or Event Viewer shows Windows Hello for Business provisioning will not be launched (Event ID 360). The usual first moves are to flip the tenant-wide Hello policy, remove the user from every group, or wipe the laptop.
Hold off. Windows Hello for Business provisioning is a short chain: join + Entra user session → policy source (Intune CSP and/or GPO) → NGC prerequisite checks → post-logon provisioning → (hybrid) key sync to AD. Most "Hello not working" tickets die in the first three steps. This post walks them in order. Every step below only reads until the change table at the end.
If dsregcmd /status already shows AzureAdPrt : NO, stop here and use the Primary Refresh Token triage first. Hello for Business will not provision cleanly without a PRT. This article assumes the device can get a PRT and you are debugging the Hello policy and NGC prerequisites.
TL;DR
- The Intune tenant-wide Windows Hello for Business policy under Enrollment applies only at enrollment. Changing it later does not rewrite already-enrolled devices.
- After enrollment, enable or tune Hello with Settings catalog, Account protection, a security baseline, or a custom PassportForWork CSP — not by hoping the Enrollment blade will catch up.
- If GPO and Intune both set Hello, GPO wins for conflicting PassportForWork settings.
MDMWinsOverGPdoes not apply to this CSP. - On the device, read
dsregcmd /status→ Ngc Prerequisite Check and Microsoft-Windows-User Device Registration/Admin (360 / 362 / 363) before you recreate policies. - Hybrid key trust often looks broken until the user's public key lands in AD (
msDS-KeyCredentialLink) after Entra Connect sync — that is the usual cause of temporarily unavailable right after first provision.
Where in the chain did it break?
| Step | What happens | Typical symptom when it breaks |
|---|---|---|
| 1. Join + user session | Device is Entra joined or hybrid joined; user signed in with Entra credentials | Event 360: User has logged on with Azure AD credentials: No; IsUserAzureAD : NO
|
| 2. Policy source | Tenant-wide enrollment policy and/or post-enrollment CSP/GPO enables Hello |
PolicyEnabled : NO; Event 360: policy is enabled: No; PIN complexity never matches Intune |
| 3. NGC prerequisites | Platform evaluates join, policy, TPM/hardware, RDP, post-logon flag |
PreReqResult : WillNotProvision; Event 360 with a specific No |
| 4. Provisioning UI | Post-logon Hello enrollment runs | No PIN prompt; Remote Desktop session; PostLogonEnabled : NO
|
| 5. Hybrid key sync (if used) | Entra Connect writes the NGC public key to AD | PIN works briefly then temporarily unavailable; empty msDS-KeyCredentialLink
|
| 6. Sign-in / unlock | PIN or biometric unlocks the device and reaches resources | PRT / CA / device disabled problems (different articles) |
Sample three or four affected users before you change tenant defaults. If every new Autopilot device is fine and only older hybrids fail, look at GPO and key sync — not the Enrollment blade.
Step 1: Confirm join type and the Entra user session
On the affected device (authorized, read only), as the signed-in user:
dsregcmd /status
Read three sections before anything else:
| Section / field | Healthy for cloud Hello | What a failure usually means |
|---|---|---|
Device State → AzureAdJoined
|
YES (or hybrid with DomainJoined YES) | Fix join first (hybrid Pending triage) |
SSO State → AzureAdPrt
|
YES | Use the PRT triage |
Ngc Prerequisite Check → IsUserAzureAD
|
YES | User is on a local / AD-only session, not Entra credentials |
IsUserAzureAD : NO with a healthy device join is extremely common on hybrid machines where someone signed in with the on-prem UPN form before Entra SSO was ready, or used a cached local admin. Hello will not launch until that user signs in with Entra credentials.
Also reject Remote Desktop: SessionIsNotRemote must be YES. Provisioning is blocked over RDP by design.
Step 2: Read which policy actually governs Hello
Tenant-wide Enrollment policy (applies once)
In Intune admin center > Devices > Enrollment > Windows Hello for Business (Windows tab):
- Enabled / Disabled / Not configured at enrollment time only.
- Microsoft documents that changes here do not apply to devices already enrolled.
- Many tenants leave this Disabled or Not configured on purpose and enable Hello later with a targeted policy so Autopilot / ESP stays predictable.
If you just flipped Enrollment from Disabled to Enabled and expect yesterday's fleet to start prompting: that will not happen from this blade alone.
Post-enrollment Intune controls (what you usually need)
After enrollment, Microsoft supports enabling and tuning Hello with:
- Settings catalog → category Windows Hello for Business (for example Use Windows Hello For Business = true, Require Security Device = true)
- Endpoint security > Account protection
- Security baselines that include Hello settings
- Custom profile → PassportForWork CSP (
./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/...)
Assign to a pilot user or device group, wait for check-in, then re-read NGC on a device in that group.
GPO vs Intune (do not mix)
Microsoft's configure guidance is explicit:
- Do not mix GPO and CSP for Windows Hello for Business.
- Conflicting CSP settings are not applied until the Group Policy settings are cleared.
-
MDMWinsOverGPdoes not apply to PassportForWork (it only covers Policy CSP).
On a hybrid device, run (authorized):
gpresult /h "$env:TEMP\gp-whfb.html" /f
Open the HTML and search for Windows Hello for Business / PassportForWork.
If Computer or User GPO sets Use Windows Hello for Business to Disabled (or conflicting PIN rules), Intune Settings catalog values you see in the portal may never land. User-scoped Hello policies also take precedence over computer-scoped ones when both exist.
Step 3: Read the NGC Prerequisite Check (and Event 360)
Still on dsregcmd /status, focus on Ngc Prerequisite Check:
| Field | Want | If NO / unexpected |
|---|---|---|
IsDeviceJoined |
YES | Not Entra/hybrid joined |
IsUserAzureAD |
YES | Wrong credential type for this session |
PolicyEnabled |
YES | No enabling policy from MDM or GPO reached this user/device |
PostLogonEnabled |
YES | Post-logon provisioning disabled (DisablePostLogonProvisioning) |
DeviceEligible |
YES | Hardware / TPM / security-device requirement not met |
SessionIsNotRemote |
YES | RDP or similar remote session |
CertEnrollment |
none for cloud/key paths; enrollment authority for cert-trust |
Cert-trust / AD FS path — Event 362 territory |
PreReqResult |
WillProvision |
One or more checks failed → WillNotProvision
|
Microsoft notes you may not see the NGC block at all after Hello has already provisioned successfully for that user. Absence after a working PIN is normal; absence with no PIN and Event 360 still firing means keep reading the event.
Open Event Viewer > Applications and Services Logs > Microsoft > Windows > User Device Registration > Admin:
| Event | Meaning |
|---|---|
| 360 | Provisioning will not be launched; body lists each prerequisite Yes/No |
| 362 | Often STS / enterprise auth prerequisite failed (common on cert-trust + AD FS mis-scope) |
| 363 | Microsoft Passport key is missing (provisioning/state problem after policy looks fine) |
Match the first No in Event 360 to Step 1–2. Do not recreate the Settings catalog profile until Event 360 names a policy or eligibility failure.
Read-only event pull:
Get-WinEvent -LogName 'Microsoft-Windows-User Device Registration/Admin' -MaxEvents 30 |
Where-Object { $_.Id -in 360, 361, 362, 363 } |
Select-Object TimeCreated, Id, Message
Step 4: Cloud MFA and "PIN not available" after a failed first try
Cloud-only and many hybrid cloud-trust paths require the user to complete Microsoft Entra multifactor authentication during Hello provisioning. A broken or half-removed authentication method can leave the device with:
- No PIN prompt on next sign-in
-
PreReqResult : WillNotProvisioneven whenPolicyEnabled : YES - Helpdesk folklore that "only a wipe fixes Hello"
Before wipe: in Entra, review the user's Authentication methods, revoke MFA sessions if your process allows, and have them complete a clean MFA challenge on that device. Then sign out/in on the console (not RDP) and re-check Event 360.
This is still a read-first step: confirm methods and sign-in logs before you require re-register for the whole org.
Step 5: Hybrid key trust — "temporarily unavailable"
If provisioning succeeds once, then unlock fails with That option is temporarily unavailable. For now, please use a different method to sign in, you are often past NGC and into key sync:
- Hybrid key trust needs the user's Windows Hello public key written to the AD user attribute
msDS-KeyCredentialLinkvia Microsoft Entra Connect. - Until that delta sync lands, Hello unlock against on-prem resources fails even though the PIN exists locally.
- Certain older Windows Server 2016/2019 DC builds had bugs that deleted the key after sign-in — Microsoft documents specific CU baselines; patch DCs rather than rotating Intune PIN length.
Read-only AD check (from a domain-joined admin workstation with rights to read the attribute):
Get-ADUser -Identity 'jsmith' -Properties 'msDS-KeyCredentialLink' |
Select-Object SamAccountName, @{n='KeyCredCount';e={($_.('msDS-KeyCredentialLink') | Measure-Object).Count}}
Empty count after a successful cloud provision → wait for / fix Entra Connect export, OU filtering, and DC patch level. Do not disable Hello tenant-wide as a workaround.
When a change is justified
| Finding | Prefer | Avoid |
|---|---|---|
| Enrollment blade Disabled; devices already enrolled | Targeted Settings catalog / Account protection enable on a pilot | Expecting Enrollment save to retrofit the fleet |
| GPO Disabled + Intune Enabled | Clear or align the GPO; then let CSP apply | Stacking more Intune profiles on top of GPO |
IsUserAzureAD : NO |
Have the user sign in with Entra credentials on the console | Wipe / Autopilot reset as first response |
DeviceEligible : NO with Require TPM |
Fix TPM visibility / BIOS; or Prefer TPM only if policy allows | Disabling Hello org-wide |
| Event 362 + AD FS cert-trust | Fix AD FS device auth / ugs scope per Microsoft deployment issues |
Recreating PassportForWork PIN length |
Key missing in msDS-KeyCredentialLink
|
Fix Connect sync + DC patches | Deleting the Entra device object to "refresh Hello" |
AzureAdPrt : NO |
Follow PRT triage | Editing Hello PIN complexity |
FAQ
Why did changing Devices > Enrollment > Windows Hello for Business do nothing?
That tenant-wide policy is evaluated at enrollment. Microsoft documents that later edits do not push to already-enrolled devices. Use a post-enrollment Settings catalog or Account protection policy for the existing fleet.
Event 360 says policy is enabled: No, but Intune shows the profile as Succeeded.
Succeeded means Intune delivered a configuration. GPO may still override PassportForWork, the assignment may target the device while a user policy disables Hello, or you are looking at a different user session than the one that checked in. Trust Event 360 + PolicyEnabled over the portal tile alone.
Do we need a TPM?
If policy Require Security Device / TPM required is on, devices without an accessible TPM stay DeviceEligible : NO. Microsoft also allows a Preferred TPM mode in the tenant-wide Enrollment policy; match that intent in your post-enrollment settings and pilot it.
How is this different from AzureAdPrt : NO?
No PRT means SSO/device auth is broken for more than Hello (PRT triage). This article starts after PRT is YES (or you have already fixed it) and focuses on Hello policy sources and NGC prerequisites.
Is wipe the supported fix after a failed first registration?
Only after Steps 1–5 name a device-bound state you cannot clear with policy, MFA recovery, or key sync. Wiping to fix a GPO conflict or a tenant-wide Enrollment misunderstanding just redeploys the same failure.
Related posts
- AzureAdPrt : NO in dsregcmd /status: A Read-First Primary Refresh Token Triage
- Hybrid Azure AD Join Pending: A Read-First Triage Order for Entra Connect Admins
- Company Portal can't connect / device not syncing: a 10-minute triage order
- Entra ID Break-Glass Accounts: Best Practices After Mandatory MFA
Free checklist
Windows Hello for Business often sits next to Conditional Access grant controls (compliant device, MFA, phishing-resistant requirements). Before you enforce those grants on the same users who still cannot provision a PIN, the free Conditional Access pre-enforcement checklist keeps break-glass, pilot groups and report-only review on one page:
If you want the rest of the Intune runway written down for the team (enrollment hygiene, compliance phasing, break/fix cards and read-only PowerShell snapshots), the Intune & M365 Admin Starter Pack pairs with this triage: https://cashflow4375.gumroad.com/l/joonf?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=whfb-provisioning-will-not-be-launched
Admin Pack Studio; not affiliated with Microsoft. Steps 1–5 only read. Pilot any Hello enable/disable on a small group first, and check current Microsoft docs for PassportForWork CSP paths and event IDs.
Top comments (0)