| name | windows-hello |
| description | Guidance for Windows Hello for Business (WHfB) — passwordless, phishing-resistant authentication using a PIN or biometric backed by an asymmetric key or certificate. Covers trust model selection (cloud Kerberos trust default for hybrid; key trust legacy; certificate trust niche), prerequisites (Entra join, MFA registration, Entra Kerberos for cloud Kerberos trust), Intune-based provisioning, multi-factor unlock, and Conditional Access authentication strengths. WHEN: Windows Hello for Business, WHfB, passwordless Windows, biometric sign-in, PIN sign-in, cloud Kerberos trust, key trust, certificate trust, hybrid sign-in, Entra Kerberos, multi-factor unlock, FIDO2 vs Hello, Hello provisioning. DO NOT USE for FIDO2 security keys (use entra-id), CA policy authoring (use conditional-access-mfa), or Intune compliance baseline (use intune-device-mgmt). |
| license | MIT |
| metadata | {"author":"Microsoft","version":"0.1.0"} |
Windows Hello for Business
Windows Hello for Business (WHfB) replaces passwords on Windows with a phishing-resistant
2-factor credential: a PIN or biometric (something you know/are) that unlocks a per-device
asymmetric key (something you have, bound to TPM). The credential never leaves the device and
is not replayable.
When to use
Eliminating password sign-in on Windows endpoints and meeting phishing-resistant MFA
requirements for users on Windows. Use this skill to choose the trust model, satisfy
prerequisites, and roll out provisioning.
Do not use this skill for FIDO2 keys on shared devices (entra-id), CA policy
(conditional-access-mfa), or device compliance (intune-device-mgmt).
Pick the trust model
WHfB has three trust models. The choice depends on whether on-prem AD SSO is needed and the
state of the AD environment.
| Scenario | Trust model | Why |
|---|
| Cloud-only (Entra-joined, no on-prem AD) | Cloud-only (default) | No on-prem trust needed |
| Hybrid (Entra-joined / hybrid-joined, AD SSO needed) | Cloud Kerberos trust (recommended) | Simplest hybrid model; requires Entra Kerberos server objects |
| Hybrid, can't deploy Entra Kerberos | Key trust | Legacy; needs Windows Server 2016+ DCs + cert on each DC |
| Hybrid with strict cert-based environment | Certificate trust | Requires AD CS + NDES + Intune cert connector; most complex |
Rule of thumb: cloud Kerberos trust is the default for hybrid in 2026 unless there
is a specific blocker (no Entra Connect Sync, regulated environment forbidding new auth
models). Don't deploy key trust or certificate trust on new tenants - both are legacy.
Approach
-
Verify prerequisites — Devices: Windows 10 1903+ / Windows 11; TPM 2.0 (TPM 1.2 in
limited cases). Users: Entra-joined or hybrid-joined; MFA registered; supported license.
For cloud Kerberos trust: deploy Entra Kerberos server objects in AD (Set-AzureADKerberosServer).
Verify: dsregcmd /status shows AzureAdJoined = YES; Get-AzureADKerberosServer returns
one object per AD forest.
-
Provision via Intune — Use Intune Account Protection policy (preferred) or the
legacy WHfB Identity Protection profile. Set tenant-wide WHfB off, then target-on via
Intune profile for the pilot ring; don't enable tenant-wide WHfB on day one.
Verify: pilot device shows the WHfB provisioning experience at first sign-in; PIN
complexity matches policy.
-
PIN complexity and biometric policy — Minimum 6 digits (6-8 typical); allow biometric
(Windows Hello face / fingerprint) on supported hardware. Don't require special characters
in PIN - it's not a password, it's a local unlock.
-
Disable convenience PIN — Some legacy estates have "convenience PIN" enabled (a PIN
for password fill, not WHfB). Disable it explicitly; otherwise users may end up with the
wrong credential type and think they're using WHfB.
-
Conditional Access - authentication strength — Create a CA policy that requires
phishing-resistant MFA authentication strength for sensitive apps. WHfB satisfies it;
password+SMS does not. Combine with PIM and PAW for Tier 0.
Verify: CA What If on a sensitive app with a password-only sign-in = blocked.
-
Multi-factor unlock for shared / kiosk — On devices accessed by multiple users (lab,
shared kiosk), configure multi-factor unlock (PIN + biometric, or PIN + trusted signal).
-
Plan credential recovery (PIN reset) and shared-device scenarios — Configure
Microsoft PIN reset service so users self-recover without help desk; alternative is
destructive reset (re-provision WHfB credential from scratch). Plan and communicate
before rollout.
Verify: PIN reset tested end-to-end by pilot user.
Guardrails
- PIN is not a password. It's local-only, device-bound, backed by TPM. Don't enforce
password-style complexity (rotation, special chars) - it discourages adoption without
improving security.
- TPM-bound is the security property. A device without TPM (or with TPM disabled in BIOS)
gets software fallback - much weaker. Verify TPM presence before counting WHfB as phishing-
resistant.
- WHfB credentials are per device, per user. A user with 3 devices has 3 WHfB credentials.
Lost device = revoke that credential, others unaffected.
- Don't deploy certificate trust on new tenants. Operational complexity vastly exceeds
cloud Kerberos trust. Pick certificate trust only with explicit justification.
- CA authentication strength is the lever. Without "require phishing-resistant MFA" CA
policy, users can still use password+SMS for sensitive apps; WHfB rollout alone doesn't
block weak auth.
- Plan PIN reset before rollout. Forgotten PINs on day 2 of rollout, no recovery, = ticket
storm and rollback.
Common anti-patterns
- "Enable WHfB tenant-wide and roll forward" - Forced enablement breaks shared devices,
non-TPM devices, and edge cases. Intune-target rings.
- "Require 14-character complex PIN" - Users hate it, write it down, adopt slower. 6
digits is the recommendation.
- "Deploy key trust for the new tenant" - Legacy. Cloud Kerberos trust unless blocked.
- "WHfB rollout - we're done with MFA" - WHfB is great for Windows sign-in; CA policy
still required to extend the phishing-resistant property to apps.
- "Disable TPM to make troubleshooting easier" - Strips the security property; WHfB
becomes software-only. Re-enable.
- "Convenience PIN is the same as WHfB" - Different credential type, weaker. Disable
convenience PIN explicitly.
Example prompts
Choose between cloud Kerberos trust and key trust for our hybrid deployment.Roll out Windows Hello for Business via Intune to a 50-device pilot ring.Configure phishing-resistant MFA authentication strength in Conditional Access for SharePoint admin.Set up the PIN reset service so users can self-recover.Why do my hybrid users still get prompted for password after WHfB enrollment?Plan multi-factor unlock on shared lab devices.
Microsoft Learn
