Windows Hello for Business Deployment with Intune: Cloud Trust vs Key Trust · CloudEngineerHub
Windows11 min read4 views
Windows Hello for Business Deployment with Intune: Cloud Trust vs Key Trust
Deploy Windows Hello for Business with Intune: cloud trust vs key trust architecture, cloud Kerberos setup, PIN and biometric policy, validation, and troubleshooting.
C
CloudEngineerHub Team
Published: September 11, 2026· Last Updated: September 24, 2026·11 min read
Windows Hello for Business Deployment with Intune: Cloud Trust vs Key Trust
Passwords remain the most abused credential in the enterprise, and password-based sign-in keeps dying by a thousand phishing emails. Windows Hello for Business (WHfB) replaces passwords on Windows devices with strong, device-bound credentials — a PIN protected by a TPM plus optional biometrics such as face or fingerprint — while still granting access to on-premises resources through Kerberos. Deploying WHfB with Microsoft Intune gives you policy-driven enrollment, centralized reporting, and a rollout you can pace ring by ring.
Visual Walkthrough
Key vs certificate trust converges here: passwordless, phishing-resistant.
C
CloudEngineerHub Team
Author
The CloudEngineerHub editorial team — Microsoft endpoint management and cloud engineers writing hands-on guides on Intune, Azure, Entra ID, Autopilot, Defender and PowerShell. Every article is reviewed against current Microsoft documentation.
Self-service reset via portal/Company Portal where allowed.
Windows Hello for Business — Trust to Sign-In. 1. Policy assigned: Intune WHfB profile selects trust type + PIN complexity. — 2. Gesture provisioned: User enrolls face/finger/PIN — bound to device TPM. — 3. Key/cert created in TPM: Private key non-exportable; attestation where required. — 4. Trust registered: Cloud Trust: Entra Kerberos; Key Trust: key published to Entra. — 5. Sign-in mints PRT: WHfB unlocks SSO incl. on-prem Kerberos (cloud trust). — 6. PIN reset supported: Self-service reset via portal/Company Portal where allowed.
The single most important design decision is the trust model: cloud trust or key trust. Choose wrong and you inherit an on-premises certificate infrastructure you did not plan for; choose right and WHfB becomes the quiet, reliable foundation of your phishing-resistant sign-in story. This guide compares both models, walks through an Intune deployment step by step, and closes with validation, troubleshooting, and hardening guidance for production.
Prerequisites
Microsoft Intune licenses for every targeted user (Intune Plan 1, included in Microsoft 365 E3/E5).
Microsoft Entra ID — WHfB works with every Entra ID edition; no premium tier is required for the core capability.
Windows 10 21H2 or later / Windows 11 devices that are Microsoft Entra joined or Entra hybrid joined.
TPM 2.0 strongly recommended (1.2 is the technical minimum; 2.0 is mandatory on Windows 11 anyway and provides stronger anti-tamper).
Cloud trust: connectivity between the Entra tenant and Active Directory, and rights to run the Kerberos trust bootstrap (Global Administrator plus Domain Admin).
Key trust: Windows Server 2016+ domain controllers, an AD CS issuing infrastructure with the Windows Hello for Business certificate templates, and the AD DS Connector provisioning service published through Microsoft Entra Connect.
Working Intune enrollment — WHfB policy rides on the MDM channel, so devices that cannot enroll cannot receive it.
How It Works
WHfB generates a public/private key pair on the device inside the TPM during enrollment. The private key never leaves the hardware; the PIN and biometrics simply unlock its use. What differs between the two models is how the enterprise decides to trust that key when the user needs on-premises resources.
Cloud trust uses Microsoft's cloud-based Kerberos infrastructure. Intune provisions the WHfB policy with the cloud trust option enabled, and the device obtains a certificate from the Microsoft cloud Kerberos trust issuer, which is trusted by an Azure AD Kerberos Server object you create in Active Directory. When the user signs in, Entra ID issues them a partial ticket-granting ticket (TGT) that the on-premises domain controllers accept and exchange for a full TGT. The result: Kerberos sign-in to file shares, printers, and on-prem apps with zero on-premises PKI.
Key trust is the original model. The public key is published into Active Directory, and domain controllers validate WHfB sign-ins themselves. It requires AD CS to issue domain controller and user authentication certificates, Windows Server 2016 or later on the DCs, and the Entra Connect AD DS Connector publishing service. It is fully supported but operationally heavier — Microsoft recommends cloud trust for all new deployments unless a specific blocker applies.
Step-by-Step Implementation
Step 1: Choose the Trust Model
For Entra joined, cloud-first estates, cloud trust is the default answer. For hybrid estates without PKI, cloud trust removes the PKI build entirely. Only choose key trust when you must keep certificate issuance on premises, for example in regulated environments with mandated AD CS usage.
Step 2: Create the Cloud Kerberos Trust (Cloud Trust Only)
Run the bootstrap from the AzureADHybridAuthenticationManagement PowerShell module on a domain-joined admin workstation. This creates the Azure AD Kerberos Server object in AD and publishes it to Entra ID so domain controllers will honor the partial TGTs Entra issues.
Step 3: Review Tenant-Wide WHfB Settings in Intune
In intune.microsoft.com go to Devices > Enrollment > Windows > Windows Hello for Business. Leave it Not configured if you intend to drive WHfB purely with Account Protection policies (recommended), or set tenant defaults for a minimal pilot.
Step 4: Create the Account Protection Policy
Go to Endpoint security > Account protection > Create policy, pick Windows 10 and later with the Account protection profile type, choose the Windows Hello for Business experience, and set Configure Windows Hello for Business to Enabled. Enable Use a cloud trust for on-premises authentication for the cloud trust model.
Step 5: Configure PIN and Biometrics
In the same policy, set the PIN minimum length (8 or more), require digits, decide on lowercase, uppercase and special characters, block reuse of expired PINs, and enable Use hardware security device to force TPM-backed keys. Enable biometrics where your hardware supports it.
Step 6: Assign, Pilot, Validate
Assign the policy to a pilot group of 10-20 users with representative hardware and network paths — office LAN, VPN, and home Wi-Fi. Confirm provisioning on the lock screen, then verify sign-in to both cloud and on-premises resources before scaling in waves.
Configuration Deep Dive
The Intune Account Protection profile maps to the PassportForWork CSP. The tenant GUID inside the policy corresponds to your Entra tenant, and every setting lands in the NGC (Next Generation Credentials) container on the device. Settings worth tuning deliberately:
Minimum PIN length: 8 is a sensible enterprise floor. Longer PINs materially increase brute-force resistance because the key material is TPM-protected, rate-limited, and wiped after repeated failures.
TPM enforcement: Use hardware security device = Required ensures keys are non-exportable. Without it, software-based keys can be provisioned on virtualized or legacy hardware.
Enhanced anti-spoofing: enables the deeper camera and liveness pipeline for Windows Hello face recognition — keep it on for all capable devices.
Cloud trust toggle: when enabled, the device requests a cloud trust certificate during WHfB provisioning; on-premises DCs accept the resulting partial TGT because of the Kerberos Server object created in Step 2.
Remote sign-in: current Windows builds support remote sign-in (RDP) to AD-joined servers with cloud trust, closing a historic gap that key trust handled naturally — verify your fleet's patch level before promising it to users.
Real-World Enterprise Scenario
A 12,000-seat manufacturer with 40 plants wanted to kill password expiry without weakening access to on-premises manufacturing execution systems. The team deployed WHfB cloud trust through Intune: an Account Protection policy required PIN length 8 with TPM enforcement, and biometrics were enabled where cameras existed. The Kerberos trust bootstrap took under an hour, and partial-TGT sign-in gave users seamless access to plant file shares and MES web endpoints. Within two quarters, 92 percent of daily sign-ins were WHfB, helpdesk password resets dropped by roughly half, and the team retired the password-expiry GPO for WHfB-enabled users. The only meaningful friction was branch-to-datacenter latency for the TGT exchange at remote plants, solved with domain controllers in the largest sites.
PowerShell for Windows Hello for Business
Bootstrap and verify the cloud Kerberos trust object, then audit Intune WHfB policy delivery:
PowerShell
1
2
3
4
5
6
7
8
9
10
# Cloud trust bootstrap (run once per forest, on a domain-joined admin workstation)
Install-Module AzureADHybridAuthenticationManagement -Force
Import-Module AzureADHybridAuthenticationManagement
# Create the Azure AD Kerberos Server object in AD and publish it to Entra ID
New-AzureADKerberosServer -Domain"corp.contoso.com" -UserPrincipalName"admin@contoso.onmicrosoft.com"# Confirm the object exists and check the Kerberos key state
Get-AzureADKerberosServer -DomainId"corp.contoso.com" -UserPrincipalName"admin@contoso.onmicrosoft.com"# Expected output: Id, Domain, CloudKeyExpiration showing the object and key refresh state
PowerShell
1
2
3
4
5
6
7
8
9
10
Connect-MgGraph -Scopes'DeviceManagementConfiguration.Read.All'# List Windows Hello for Business (identity protection) policies in Intune$whfb = Invoke-MgGraphRequest -Method GET -Uri"https://graph.microsoft.com/beta/deviceManagement/deviceConfigurations?`$filter=isof('microsoft.graph.windowsIdentityProtectionConfiguration')"$whfb.value | Select-Object displayName, id, lastModifiedDateTime | Format-Table
# Expected output: displayName such as 'WHfB - Cloud Trust - Pilot' with the policy id# Spot-check a device: confirm Entra join state and NGC provisioning
dsregcmd /status | Select-String -Pattern'AzureAdJoined|NgcSet|DeviceId'# Expected output: AzureAdJoined : YES and NgcSet : YES on a provisioned device
Troubleshooting
Symptom
Likely Cause
Fix
WHfB provisioning prompt never appears
Account Protection policy not reaching the device (enrollment, assignment, or licensing gap)
Confirm the policy in Devices > Configuration, run dsregcmd /status, and verify the device checks in to Intune
"That option is temporarily unavailable" on the lock screen
NGC container corruption or TPM fault
Reset the PIN from Settings; if persistent, remove and re-add Windows Hello, or clear the NGC container
Cloud sign-in works but on-prem file shares fail
Missing or stale Azure AD Kerberos Server object, or no line of sight to a domain controller
Re-run Get-AzureADKerberosServer, verify DC connectivity or configure KDC proxy for remote sites
Partial TGT exchange fails intermittently on VPN
Split tunneling excludes the DC subnet, or clock skew is too high
Include DC reachability in the VPN profile and keep time skew under five minutes
Users stuck in a "set up your PIN" loop
Tenant WHfB setting conflicts with the Account Protection policy
Align the tenant-level Windows Hello for Business enrollment setting with the policy, then re-sync the device
RDP to domain-joined servers fails with WHfB
Client build predates cloud trust remote sign-in support
Patch the fleet; until then use the documented fallback credential flow
Visual Walkthrough
The gate every sign-in passes: collect signals, AND the policies, decide.
Decision TreeConditional Access — Signals In, Decision Out5/5
Decision gate
Evaluate all matching policies (AND)
One failing control blocks; grants must be earned in full.
0x80090016 — Keyset does not exist during provisioning: the NGC container is corrupt. Reset the PIN; on stubborn devices, clear the TPM-based NGC container and let policy re-provision.
0x801c0021 — device record not found: the Entra device object was deleted while the device still holds keys. Re-register the device (dsregcmd /leave as administrator, then rejoin) to restore a clean identity.
0x80090029 — TPM device not ready: firmware or TPM driver problems. Update device firmware from the OEM before blaming policy.
0x800b0109 — untrusted certification path (key trust only): the DC or WHfB user certificate chain is not trusted. Publish the root CA and DC certificates via trusted certificate profiles in Intune.
Best Practices
Standardize on cloud trust for new deployments; it removes the AD CS and provisioning service dependencies entirely.
Force TPM-backed keys and enhanced anti-spoofing before fleet-wide assignment.
Pilot with both an office and a remote user cohort — the partial TGT path behaves differently across VPN topologies.
Keep PIN policy in one policy object; duplicate WHfB policies with conflicting PIN rules cause provisioning flapping.
Rotate the cloud Kerberos key on Microsoft's recommended cadence with Set-AzureADKerberosServer -RotateServerKey and monitor key expiration.
Communicate the biometric opt-out path to users; face and fingerprint can be skipped, but the PIN is not optional once WHfB is enforced.
Security Considerations
WHfB is phishing-resistant for device sign-in, but pair it with Conditional Access so stolen session tokens cannot simply bypass the stronger credential.
TPM enforcement prevents key exfiltration; without it, a compromised device can theoretically export software-based keys.
Enable Enhanced anti-spoofing on all face-recognition-capable hardware.
Audit WHfB enrollment events in the Entra sign-in logs and alert on repeated PIN resets — a classic indicator of shared or abused devices.
Consider requiring WHfB or another phishing-resistant factor through authentication strengths for privileged roles.
FAQ
Q: Does Windows Hello for Business require Entra ID P1?
A: No. WHfB works with every Microsoft Entra ID edition; premium tiers matter only for adjacent features such as Conditional Access.
Q: Can cloud trust work for Entra hybrid joined devices?
A: Yes. Cloud trust supports both Entra joined and Entra hybrid joined devices; the partial TGT flow is what reaches on-premises resources in both cases.
Q: What happens if a user forgets their PIN?
A: They use the I forgot my PIN flow, which re-authenticates with Entra ID (plus MFA if configured) and re-provisions the NGC key. Administrators can also trigger a PIN reset remotely for managed devices.
Q: Do users still need passwords anywhere?
A: Rarely. WHfB users still type a password in a few flows such as initial setup or some legacy web portals; Windows hides password sign-in where WHfB is enforced.
Q: Is biometric sign-in mandatory?
A: No. It is offered when capable hardware is present, and the PIN remains the fallback — you can even disable biometrics in policy if your risk posture requires it.
Conclusion
Windows Hello for Business is the highest-value password-elimination step most Windows estates can take, and Intune turns the rollout into a policy exercise rather than a PKI project. Cloud trust collapses the on-premises footprint of WHfB to a single Kerberos trust object, so unless you have a hard requirement for key trust, start there. Pilot on real networks, force TPM-backed keys, validate the partial TGT path against your oldest on-premises applications, and scale ring by ring — then watch password-reset tickets fall off the helpdesk queue.
Comments
0No comments yet — be the first to share your thoughts.