Windows Hello for Business Setup & Troubleshooting
Windows Hello for Business (WHfB) is the primary path for phishing-resistant authentication at the Windows logon screen. When a user signs in with WHfB (PIN or biometric backed by TPM), Windows performs a cryptographic Entra ID authentication that mints a Primary Refresh Token (PRT) carrying a phishing-resistant MFA claim. That PRT is then used silently by every app the user opens, including the background Intune enrollment task on Hybrid Joined machines.
WHfB is the default recommendation for standard environments. For environments where cameras, fingerprint readers, or USB ports are not viable (oil mist, dust, industrial settings), PIV cards via Entra Certificate-Based Authentication and FIDO2 NFC security keys are supported alternatives. See Phishing-Resistant Authentication for a complete decision guide.
The setup procedure in this guide requires a direct Windows sign-in session. WHfB provisioning runs at the Windows lock screen before any remote session is established and requires direct access to the device's TPM. This means:
- Physical endpoints and dedicated personal-pool VMs (console access): WHfB provisions normally: this guide applies.
- AVD session hosts accessed remotely: A user signing in to AVD via a browser or RD client is already inside a remote session by the time the Windows desktop loads. WHfB cannot be provisioned from within that session. The
dsregcmd /statusfieldSessionIsNotRemote: NOwill block provisioning.
Note that WHfB can be used to authenticate to AVD: if the user has WHfB provisioned on their local corporate device, that credential satisfies the A002 phishing-resistant auth strength policy for the AVD connection itself.
For pure AVD environments where users have no corporate local device and access all resources through AVD, use FIDO2 security keys instead. See Phishing-Resistant Authentication → Path 3 for the key registration workflow.
Why Windows Logon Authentication Matters for Intune Enrollment
A Conditional Access policy requiring MFA for all cloud apps will intercept Intune enrollment: enrollment is itself a cloud app authentication event. There are two ways to handle this:
| Approach | Trade-off |
|---|---|
| Add a CA exception for the Intune Enrollment app | Workable short-term; creates a permanent gap in the "no exceptions" posture required for a compliant zero-trust deployment |
| Configure phishing-resistant Windows logon auth first | Eliminates the exception entirely; the enrollment authenticates using the MFA-bearing PRT from Windows logon |
For Entra Join, enrollment is interactive: the user can satisfy an MFA prompt in the moment, so the exception is only needed until WHfB is provisioned. For Hybrid Join, enrollment is a background, non-interactive task: the PRT from the current Windows logon session is the only authentication the task can use. WHfB must be in place before Intune enrollment is triggered, not after.
Setup
- Entra Join (Intune Policy)
- Hybrid Join (GPO)
For Entra Joined devices, WHfB enrollment is driven by an Intune policy. No GPO or on-prem infrastructure is required.
Option A: Tenant-Wide Setting (Simplest)
Navigate to Intune > Devices > Windows > Windows enrollment > Windows Hello for Business.
| Setting | Value |
|---|---|
| Configure Windows Hello for Business | Enabled |
| Use a Trusted Platform Module (TPM) | Required |
| Minimum PIN length | 6 |
| Maximum PIN length | 127 |
| PIN expiration | Never (biometric makes rotation low-value) |
| Remember PIN history | 0 |
| Allow biometric authentication | Allowed |
| Use enhanced anti-spoofing | Allowed |
| Use certificate for on-premises authentication | Disabled (use Cloud Kerberos Trust instead) |
This blade applies to every Windows device that enrolls in Intune. For phased rollouts, use Option B to target specific groups instead.
Option B: Settings Catalog Profile (Targeted)
Create a Settings Catalog configuration profile and assign it to your target group.
Search for and configure settings under the Windows Hello for Business category:
| Setting | Value |
|---|---|
| Use Windows Hello for Business | Enabled |
| Use a hardware security device | Enabled (requires TPM; blocks software-only enrollment) |
| Use cloud Kerberos trust for on-premises authentication | Enabled (if users access on-prem resources) |
| Enable PIN Recovery | Enabled |
When deploying WHfB via the OIB, you will see two policies that appear to contradict each other:
- Win - OIB - ES - Windows Hello for Business - D - WHfB Configuration - v3.2 sets
Use Certificate For On-Prem Auth→ Disabled - Win - OIB - SC - Windows Hello for Business - D - Cloud Kerberos Trust - v3.5 sets
Use Cloud Trust For On-Prem Auth→ Enabled
These are two distinct Windows settings controlling two entirely different on-premises authentication models. The OIB is deliberately disabling the old model and enabling the new one:
| Certificate Trust (disabled by OIB) | Cloud Kerberos Trust (enabled by OIB) | |
|---|---|---|
| Mechanism | Device presents a client certificate to the DC to obtain a Kerberos ticket | Device presents a cloud-issued partial TGT; the DC validates it using the AzureADKerberos object in AD |
| On-prem requirement | Active Directory Certificate Services (ADCS) + certificate enrollment infrastructure | A single read-only AzureADKerberos computer object (one PowerShell command; see Hybrid Join tab) |
| Certificate lifecycle | Yes: client certificates must be enrolled, renewed, and revoked | None: no certificates issued to devices or users |
| Internet access at logon | Not required (but PKI must be reachable) | Not required: DC validates offline using the synced Kerberos object |
| Recommended for | Environments with existing PKI that cannot yet migrate | All new deployments and any environment using Entra Join |
The OIB ships with both policies because Certificate Trust is the Windows default and must be explicitly disabled, while Cloud Kerberos Trust is opt-in and must be explicitly enabled. Neither policy alone is sufficient: both must be deployed together.
For Hybrid Joined devices, WHfB is deployed via Group Policy. The Cloud Kerberos Trust prerequisite must be configured first so that WHfB-provisioned devices can still obtain Kerberos tickets for on-prem resources.
Step 1: Configure Cloud Kerberos Trust
Run the following on the Entra Connect server (or any server with the AzureADHybridAuthenticationManagement module):
# Install module if not present
Install-Module -Name AzureADHybridAuthenticationManagement
# Create the AzureADKerberos computer object in AD
# This read-only object lets DCs validate cloud-issued Kerberos tickets
Set-AzureADKerberosServer -Domain contoso.com `
-DomainCredential (Get-Credential) `
-CloudCredential (Get-Credential)
This creates a read-only AzureADKerberos computer object in your AD. Entra Connect syncs it once. Your Domain Controllers use it to validate cloud-issued partial Kerberos tickets without needing internet access themselves.
Step 2: Configure WHfB via GPO
In Group Policy Management, configure:
Computer Configuration\Administrative Templates\Windows Components\Windows Hello for Business
| Policy Setting | Value |
|---|---|
| Use Windows Hello for Business | Enabled |
| Use cloud Kerberos trust for on-premises authentication | Enabled |
| Use a hardware security device | Enabled |
If Use cloud Kerberos trust for on-premises authentication doesn't appear in GPMC, your Group Policy central store predates the setting: copy Passport.admx/Passport.adml from a current Windows client into the central store. And confirm Use certificate for on-premises authentication is Not configured on these machines: an enabled certificate-trust policy takes precedence over Cloud Kerberos Trust (cloud Kerberos trust deployment guide).
Apply the GPO to the OU containing your Hybrid Joined workstations. Run gpupdate /force on a test machine to pull the policy immediately.
Diagnosing WHfB Provisioning
Partial Provisioning
Like the Entra Hybrid Join process, WHfB provisioning involves communication between the device and cloud services. After WHfB setup completes, the public key needs to be written back to the user's Entra ID (or on-prem AD) attribute before the PIN or biometrics can actually authenticate. The event log under Applications and Services Logs > Microsoft > Windows > HelloForBusiness captures each step of the provisioning chain. If something in that chain didn't fully complete before the first post-setup login attempt, the credential providers appear but can't back themselves with a valid key. WHfB options may be visible on the login screen but not be functional, forcing a password login.
dsregcmd /status
Run the following from a standard (non-elevated) command prompt while logged in as the affected user. Running as Administrator returns the system context instead of the user context, which will give misleading results.
dsregcmd /status
Ngc Prerequisite Check
If WHfB is not provisioning, find the NgcPrerequisiteCheck section in the output. Every field that says NO is a reason WHfB will not launch the setup prompt.
| Field | What It Checks | Common Fix |
|---|---|---|
IsDeviceJoined | Device is Entra Joined or Hybrid Joined | Complete the join process (Entra Join or Hybrid Deployment) |
IsUserAzureAD | Logged-in user has an Entra identity with a valid PRT | Ensure Entra Connect is syncing this user; check AzureAdPrt |
PolicyEnabled | WHfB policy is explicitly set to ON | Check for conflicting MDM policy or HKCU registry override (see below) |
PostLogonEnabled | System is allowed to prompt immediately after login | Leave enabled; if disabled, users must enroll manually via Settings |
DeviceEligible | Hardware meets TPM requirements | Verify TPM 2.0 is enabled in BIOS/UEFI; VMs need a virtual TPM |
SessionIsNotRemote | User is at the console, not in RDP | WHfB cannot be provisioned over a standard RDP session |
CertEnrollment | Certificate chain is available (Cert Trust model only) | Only relevant for Cert Trust; for Cloud Kerberos Trust, this should be NotRequired |
PreReqResult | Final verdict | WillProvision = ready. WillNotProvision = at least one above is NO |
User State, also check:
NgcSet : NO→ the user has no WHfB container/PIN yet (normal before first provisioning)AzureAdPrt : NO→ no valid PRT; provisioning will silently abort even if all Ngc fields say YES
Event Viewer: Provisioning Decision Logs
Windows logs exactly why WHfB provisioning was skipped or launched during the user's login sequence.
Navigate to: Applications and Services Logs > Microsoft > Windows > User Device Registration > Admin
| Event ID | Meaning |
|---|---|
| 358 | Provisioning will be launched this login |
| 360 | Provisioning will not be launched: open the event details for a yes/no prerequisite checklist |
| 362 | Provisioning will not be launched (variant) |
Open the event details. The description shows each prerequisite as yes/no. Scan for any No entries, such as:
"User has logged on with AAD credentials: No"→ AzureAdPrt issue"Windows Hello for Business policy is enabled: No"→ policy conflict
Event Viewer: HelloForBusiness Logs
If provisioning starts but fails silently (TPM error, broken container), errors appear here.
Navigate to: Applications and Services Logs > Microsoft > Windows > HelloForBusiness > Operational
Look for errors or warnings related to container creation, TPM communication, or Event ID 7055.
Common Silent Blockers
Even with a clean dsregcmd output and correct GPO/Intune policy, these environment factors will suppress the setup prompt:
Missing MFA Registration
WHfB setup itself requires an MFA claim to bootstrap. If the user has never registered a security method in Entra ID (no Authenticator app, no phone), the WHfB prompt will silently skip. Ensure users complete security info registration at mysignins.azure.usmysignins.microsoft.com before their first WHfB-eligible login.
Registry Conflict (GPO vs. MDM) Verify the policy wrote the correct keys:
HKLM\SOFTWARE\Policies\Microsoft\PassportForWork→UsePassportForWorkshould be1- Check
HKCU\SOFTWARE\Policies\Microsoft\PassportForWork: a value of0here (from an old user-scoped policy or MDM config) overrides the computer-scoped key
Mixed Policy Sources (GPO + Intune CSP)
Microsoft's guidance is to configure WHfB via GPO or CSP, but not both: mixed sources produce unexpected results, and where the same setting conflicts, the GPO value wins and the CSP value is simply not applied until the GPO setting is cleared (policy conflicts from multiple policy sources). MDMWinsOverGP cannot flip this: it covers only the Policy CSP, and WHfB settings live in the PassportForWork CSP. The practical symptom is an Intune WHfB profile that reports as delivered while the device keeps obeying the GPO. Audit both sources with the registry checks in the policy-source section below.
Licensing WHfB requires Entra ID P1 or P2 (included in M365 G3/G5). Verify the user has an active eligible license.
Ongoing WHfB Management: GPO to Bootstrap, Intune to Govern
The Deployment Bootstrap Problem
For Hybrid Joined devices, WHfB must be provisioned before Intune enrollment can complete without a Conditional Access exception.
As established above, the background Intune enrollment task on a Hybrid Joined device runs silently and can only authenticate with the PRT from the current Windows logon session. Under a CA policy requiring phishing-resistant MFA for all cloud apps, that PRT must already carry an MFA claim.
A Windows login with a password produces a PRT without an MFA claim. A Windows login with WHfB produces a PRT with a phishing-resistant MFA claim.
The sequence that avoids a permanent CA exception:
- GPO deploys the WHfB Cloud Kerberos Trust policy to the Hybrid Joined OU.
- User logs in with a password: the WHfB setup prompt appears on first login after the policy applies.
- User completes WHfB enrollment (PIN and optionally biometric).
- User logs back in with WHfB: Entra mints a PRT with a phishing-resistant MFA claim.
- Intune enrollment scheduled task runs silently, presents the MFA-bearing PRT, and enrollment completes.
Without this sequence, the only alternative is a permanent CA exception for the Intune Enrollment cloud app, particularly problematic in CMMC-scoped environments where every CA exception requires a documented justification.
Without this sequence, the only alternative is a permanent CA exception for the Intune Enrollment cloud app, which requires a documented justification.
Hybrid Joined devices are domain members that are not yet Intune-managed. They can receive GPO immediately. Intune MDM policies cannot reach a device until enrollment is complete, which is the step we are trying to enable. GPO is the only management channel available at this stage of the device lifecycle.
Recommended Split: GPO for Provisioning, Intune OIB for Settings
Once the device enrolls, Intune takes over ongoing management of the WHfB policy settings below. The GPO stays in place for the two bootstrap-critical settings. This split only works because the two sources never configure the same setting: for WHfB, a GPO value wins any conflict and the Intune (CSP) value is ignored until the GPO setting is cleared, and MDMWinsOverGP cannot change that because it applies only to the Policy CSP, not the PassportForWork CSP where WHfB settings live (policy conflicts from multiple policy sources).
The table below distinguishes two categories of settings:
- Bootstrap-critical (GPO required): These settings must exist before WHfB can provision. Without these two settings in place via GPO, the bootstrap sequence described above cannot start.
- Policy settings (Intune OIB only): These settings are not required for provisioning to succeed: WHfB will enroll using safe Windows defaults if they are absent. There is no technical barrier to also setting them in GPO, but doing so hands the setting to the GPO permanently: the Intune value is ignored while the GPO value exists, and the Intune console gives no hint of it. Keeping policy settings exclusively in Intune eliminates that risk.
| Setting | Managed via | Notes |
|---|---|---|
| Enable WHfB / Use Hardware Security Device | GPO (bootstrap-critical) → Intune OIB | Must be set via GPO. Without this, WHfB never provisions and the enrollment bootstrap cannot complete. OIB profile keeps it enforced post-enrollment. |
| Use Cloud Kerberos Trust | GPO (bootstrap-critical) → Intune OIB | Must be set via GPO. Without this, Hybrid Join provisioning fails or on-prem resource access breaks from day one. OIB Cloud Kerberos Trust profile maintains it post-enrollment. |
| PIN Complexity | Intune OIB only | Not required for provisioning. Windows defaults allow enrollment; OIB enforces your complexity policy after enrollment. (Win - OIB - ES - Windows Hello for Business - D - WHfB Configuration - v3.2) |
| Enable PIN Recovery | Intune OIB only | Not required for provisioning. Enables users to self-reset their PIN at the lock screen post-enrollment without contacting IT. |
| Allow Biometric Authentication | Intune OIB only | Not required for provisioning. Controls whether face/fingerprint is offered alongside PIN post-enrollment. |
| Enhanced Anti-Spoofing | Intune OIB only | Not required for provisioning. Required for AAL2 compliance on devices with Windows Hello Enhanced Sign-In Security; enforced via OIB post-enrollment. |
See the Entra Join tab above for a breakdown of why the OIB deploys Use Certificate For On-Prem Auth = Disabled alongside Use Cloud Trust For On-Prem Auth = Enabled. Both must be deployed together; one without the other leaves the device in a mixed state.
Which Source Wins: GPO Beats CSP for WHfB
The general co-management intuition ("switch the Device Configuration workload to Intune and MDM wins") does not apply to WHfB. Windows Hello for Business settings live in the PassportForWork CSP, and Microsoft documents the precedence explicitly: if a setting is configured by both GPO and CSP, the GPO value takes precedence and the conflicting CSP value is not applied until the GPO setting is cleared. MDMWinsOverGP does not change this: that policy covers only the Policy CSP (policy conflicts from multiple policy sources).
The migration consequence: moving a WHfB setting to Intune does nothing while the GPO still sets it. Retire the GPO setting first, then confirm the Intune value lands on the next sync. During the overlap, the Intune console reports the profile as delivered even though the device is obeying the GPO.
Check the active policy source on any device:
# GPO-sourced WHfB settings
Get-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\PassportForWork"
# MDM-sourced WHfB settings
Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\PolicyManager\current\device\PassportForWork"
Compliance and Enrollment Reporting
After Intune enrollment, WHfB status is visible in:
- Entra Admin Center → Protection → Authentication methods → User registration details: tenant-wide view of which users have registered phishing-resistant methods; export to CSV for CMMC IA.L2-3.5.3 audit evidence.
- Entra Admin Center → Protection → Authentication methods → User registration details: tenant-wide view of which users have registered phishing-resistant methods; export to CSV for audit evidence.
- Entra Admin Center → Users → [user] → Authentication methods: per-user method list; confirms WHfB, passkey, or FIDO2 key registration.
- Intune → Reports → Device configuration: policy deployment status for WHfB OIB profiles; surfaces devices where settings have not yet applied.
📩 Don't Miss the Next Solution
Join the list to see the real-time solutions I'm delivering to my GCC High clients.