Windows Hello for Business Guide

A password typed at Windows sign-in can be phished, sprayed or replayed, and so can the same password wherever else the user signs in with it. Windows Hello for Business (WHfB) replaces that password with an asymmetric key pair bound to the device, ideally inside its TPM, and unlocked by a PIN or biometric gesture that never leaves the machine. This guide covers how WHfB works, the three deployment models and trust types and which one Microsoft now recommends, hardware and directory prerequisites, the Group Policy and Intune settings that control it, enhanced sign-in security, multi-factor unlock, PIN recovery, troubleshooting logs, and the attacks WHfB does not stop. It is written for identity and endpoint engineers planning or fixing a deployment, and for architects deciding how WHfB fits a passwordless programme. Facts were checked against Microsoft Learn on 16 October 2026.

Key takeaways

• Cloud Kerberos trust is Microsoft's recommended hybrid model. Microsoft calls it "the recommended deployment model when compared to the key trust model", and it is the only hybrid option that needs no certificates on domain controllers or users.
• The PIN is not a password. It unlocks a key protector on one device, is never sent to the identity provider and is useless on any other machine.
• Force hardware keys by policy. By default WHfB prefers the TPM but falls back to software keys; only "Use a hardware security device" guarantees non-exportable, TPM-bound keys.
• WHfB is phishing-resistant sign-in, not post-sign-in protection. Stolen session cookies, tokens and Kerberos tickets, and malware on an unlocked device, bypass it entirely.
• Recovery decides the real strength. Deploy non-destructive PIN reset and make help-desk re-enrolment at least as strong as first enrolment.

How Windows Hello for Business works

Microsoft describes five phases, two of which apply only to some deployments:

1. Device registration: the device registers with the identity provider, Microsoft Entra ID (Device Registration Service) for cloud and hybrid, or AD FS for on-premises.
2. Provisioning: the user signs in with an existing credential and completes a second factor before Windows generates a key pair. The public key is registered with the identity provider and mapped to the user.
3. Key synchronisation (some hybrid models): Microsoft Entra Connect Sync writes the public key from Entra ID to the user's msDS-KeyCredentialLink attribute in Active Directory.
4. Certificate enrolment (certificate trust only): the enterprise PKI issues a user certificate through a certificate registration authority on AD FS.
5. Authentication: the user unlocks the key with a PIN or biometric; the identity provider validates the signature against the registered public key.

Key material lives in a logical Windows Hello container holding an authentication key, user ID keys and an administrative key. Each gesture (PIN, fingerprint, face) has its own protector that wraps the authentication key. Keys are generated in a TPM 1.2 or 2.0 where available and cannot be exported; without a TPM they are encrypted in software. After sign-in, Entra-joined and hybrid-joined devices receive a Primary Refresh Token (PRT) for single sign-on, and Microsoft states the WHfB key "meets Microsoft Entra multifactor authentication (MFA) requirements", which is why users see fewer MFA prompts.

Consumer Windows Hello on a personal device is a convenience unlock for a local or Microsoft account. WHfB is the managed version: configured by Group Policy or MDM, bound to a work identity and usable for Active Directory and Entra authentication.

Deployment models and trust types

There are three deployment models. Cloud-only suits organisations with only Entra identities. Hybrid suits identities synchronised from Active Directory that need single sign-on to on-premises and cloud resources. On-premises is for organisations without cloud identities; Microsoft notes its main use case is enhanced security administrative environments ("red forests"), and moving from on-premises to hybrid requires redeployment. Hybrid and on-premises then need a trust type, which decides how users obtain Kerberos tickets from Active Directory.

Choosing a trust type

• Cloud Kerberos trust: choose it by default for hybrid. Microsoft says it is "also the preferred deployment model if you do not need to support certificate authentication scenarios". There is no key synchronisation delay and no PKI to run.
• Key trust: a fallback where cloud Kerberos trust prerequisites cannot be met. The public key needs at least 30 minutes to sync to Active Directory, and on-premises authentication is delayed until it does.
• Certificate trust: only when users need a certificate in the container, for example for RDP with supplied credentials or applications that require certificate authentication. It brings AD FS, a certificate registration authority and device write-back.
• Small organisations: cloud-only or hybrid cloud Kerberos trust with Intune is the least infrastructure. Large estates with existing key or certificate trust can migrate, but there is no in-place path from certificate trust: the container must be deleted (certutil.exe -deletehellocontainer) and reprovisioned.

Prerequisites and hardware

Cloud Kerberos trust does not support RDP or VDI with supplied credentials (use Remote Credential Guard or a certificate in the container), "Run as", or the first sign-in on a hybrid joined device without line of sight to a domain controller.

Unlock factors: PIN, biometrics, ESS and multi-factor unlock

• PIN: Microsoft states "The PIN or the private portion of the credentials is never sent to the IdP, and the PIN isn't stored on the device." It unlocks the protector key locally, and the TPM's anti-hammering limits guessing. Set complexity through the PIN Complexity settings (minimum and maximum length, character requirements, history, expiration) rather than forcing password-style rules on users.
• Biometrics: face and fingerprint templates stay on the device and never roam. NIST SP 800-63B-4 allows biometrics only as part of multi-factor authentication with a physical authenticator, sets a false match rate of one in 10,000 or better, and requires presentation attack detection for facial recognition. The PIN remains the fallback, so treat it as the primary secret.
• Enhanced sign-in security (ESS): uses virtualisation-based security (VBS) and TPM 2.0 to isolate the face algorithm and templates and to secure the channel to match-on-sensor fingerprint readers that carry a Microsoft-issued certificate. All Copilot+ PCs ship with ESS on.

ESS limits to plan for: external cameras are not supported and non-ESS sensors are blocked while it is on; it is a system-level setting, so on shared devices "the lowest Windows Hello security posture applies"; and from Windows 11 version 22H2 with KB5031455 users can turn it off temporarily to use peripherals. Confirm ESS on a device in the Biometrics Operational log (event ID 1108 shows the sensor isolated in a Virtual Secure Mode process) or by checking that bioiso.exe and ngciso.exe are running.

Multi-factor unlock and dynamic lock

Standard WHfB is already two factors: the device-bound key (possession) plus PIN (knowledge) or biometric (inherence). Multi-factor unlock adds a requirement: a first factor from the PIN, fingerprint or facial recognition credential providers, plus a second factor that is either another of those or a "trusted signal". Trusted signals are a nearby Bluetooth phone (with signal-strength thresholds), an IP configuration (prefix, gateway, DHCP or DNS server, DNS suffix) or a Wi-Fi network (SSID, security type, optionally BSSID and root CA). Credential providers are referenced by GUID, for example PIN {D6886603-9D2F-4EB2-B667-1971041FA96B} and trusted signal {27FBDB57-B613-4AF2-9D7E-4FA7A66C21AD}.

• Use it for: high-risk roles or kiosks where you want "PIN plus on the corporate network" or "face plus fingerprint".
• Watch for: lockouts when a user's trusted phone is lost or replaced, and the known conflict with the DontDisplayLastUserName security policy. Microsoft recommends its default signal values.

Policy settings: Group Policy and Intune

Group Policy settings live under Computer Configuration (and some under User Configuration) > Administrative Templates > Windows Components > Windows Hello for Business. Intune exposes them in the Settings catalog, the tenant-wide Windows Hello for Business enrolment policy, or the PassportForWork CSP. If both Group Policy and Intune configure WHfB, Group Policy wins and Intune is ignored.

Passkeys and phishing resistance

WHfB and passkeys share the same model: a private key on the device, released by a local gesture, with the server holding only the public key. The FIDO Alliance defines passkeys as "FIDO cryptographic credentials that are tied to a user's account on a website or application", split into synced passkeys and device-bound passkeys that "never leave a single device". Windows Hello also acts as a platform authenticator for WebAuthn: passkeys created on Windows are stored with Windows Hello and unlocked with the same PIN or biometric, and Windows 11 22H2 with KB5030310 added native passkey management.

• Entra policy: the built-in Phishing-resistant MFA authentication strength in Conditional Access accepts "Windows Hello for Business or platform credential", FIDO2 security keys and multifactor certificate-based authentication. A user who signed in with a password is not prompted for WHfB; they must sign in again choosing it. See the Conditional Access Guide.
• NIST assurance: SP 800-63B-4 requires AAL2 verifiers to offer a phishing-resistant option and AAL3 to use "a cryptographic authenticator with a non-exportable private key that provides phishing resistance". A TPM-bound WHfB key has the non-exportable property AAL3 asks of the authenticator; a software-protected key does not, which is another reason to require a hardware security device.
• Roaming: WHfB is per device. Users who move between machines, or administrators who need the same credential on jump hosts, are better served by FIDO2 security keys. See the Hardware Security Keys Guide and the Passwordless and Passkeys Guide.

Rollout plan

1. Decide the model and fix prerequisites. For hybrid, deploy Microsoft Entra Kerberos, confirm writable DCs per site and client patch levels, and check that no device has "Use certificate for on-premises authentication" configured.
2. Pilot with provisioning deferred. Target a pilot group with "Use Windows Hello for Business", "Use cloud trust for on-premises authentication" and "Use a hardware security device". Check the prerequisite results in the User Device Registration admin log (event ID 358 means the device is ready to enrol) and with dsregcmd /status.
3. Enable PIN recovery before broad rollout. Consent to the Microsoft Pin Reset Service Production and Client Production enterprise applications, set Enable Pin Recovery, and for federated tenants add the identity provider domains to ConfigureWebSignInAllowedUrls.
4. Expand in rings by department, then all users, tracking provisioning failures per ring.
5. Enforce. Require the Phishing-resistant MFA strength in Conditional Access, starting with administrators, then reduce password use, for example by removing passwords from the Windows sign-in experience once coverage is high.
6. Rollback: unassign the policy or set "Use Windows Hello for Business" to disabled; users fall back to their existing credentials. For a broken container on one device, certutil.exe -deletehellocontainer in the user context followed by sign-out and sign-in reprovisions it.

Recovery and PIN reset

Destructive PIN reset is the default: the container, keys and any certificates are deleted and new keys provisioned. Non-destructive reset keeps the container and changes only the PIN, through the Microsoft PIN reset service. It applies to hybrid and cloud-only deployments on Enterprise, Education and Pro editions with no extra licence. On a device, dsregcmd /status shows CanReset as DestructiveOnly or DestructiveAndNonDestructive. Hybrid key trust devices need non-destructive reset for "I forgot my PIN" to work above the lock screen.

The reset flow itself must be strong: on Entra joined devices it requires an authentication method enabled in the tenant. Lost devices and new laptops send users to the help desk, which is where attackers go too, as the MGM Resorts breach showed. Issue Temporary Access Passes only after verified identity checks. See the Account Recovery and Help Desk Security Guide.

Troubleshooting, monitoring and metrics

• Coverage: percentage of active users with a registered WHfB credential.
• Hardware binding: percentage of WHfB keys that are TPM-protected.
• Password sign-ins: share of Windows and Entra sign-ins still using a password, trending to zero.
• Provisioning failure rate per rollout ring, by prerequisite failure reason.
• Destructive resets per month, which should fall once non-destructive reset is enabled.

What WHfB does not stop

WHfB protects the moment of authentication. Everything issued after it is ordinary token material.

The CitrixBleed 2023 intrusions are the pattern: strong sign-in, then stolen sessions that never needed it.

Framework mapping

Common failure patterns

• Software keys by default. No hardware security device policy, so devices with a faulty TPM quietly provision exportable software keys.
• Certificate trust setting left behind. An old "Use certificate for on-premises authentication" policy overrides cloud Kerberos trust and provisioning fails or picks the wrong trust.
• Passwords left as a parallel path. WHfB is deployed but passwords still work everywhere, so attackers phish the password and ignore WHfB, as MFA fatigue cases such as the Uber breach showed with weaker factors.
• Domain admins on cloud Kerberos trust. Privileged accounts are blocked by the AzureADKerberos Password Replication Policy by design; teams then weaken the policy instead of giving admins separate credentials and privileged access workstations.
• Weak recovery. Destructive reset only, or help-desk resets on a phone call, turning a phishing-resistant credential into a social-engineering target.
• Mixed GPO and Intune. Both configured; Group Policy wins and Intune changes appear to do nothing.

Practitioner checklist

• Use cloud Kerberos trust for hybrid unless certificate scenarios require certificate trust.
• Set "Use a hardware security device" and exclude TPM 1.2 where your fleet allows.
• Configure WHfB through one channel, Group Policy or Intune, not both.
• Enable non-destructive PIN reset and test "I forgot my PIN" on each join type.
• Pilot in rings and track event ID 358 and dsregcmd /status results.
• Require the Phishing-resistant MFA authentication strength, starting with administrators.
• Enable ESS on capable hardware and decide policy for external biometric peripherals.
• Pair WHfB with token protection, Credential Guard and session controls.
• Audit writes to msDS-KeyCredentialLink and restrict who can make them.
• Harden help-desk recovery and Temporary Access Pass issuance.

Standards and references

• Microsoft Learn: Plan a Windows Hello for Business deployment
• Microsoft Learn: How Windows Hello for Business works
• Microsoft Learn: Cloud Kerberos trust deployment guide
• Microsoft Learn: Windows Hello for Business policy settings
• Microsoft Learn: PIN reset
• Microsoft Learn: Windows Hello Enhanced Sign-in Security
• NIST SP 800-63B-4: Authentication and Authenticator Management
• FIDO Alliance: Passkeys

Related NHI Mgmt Group resources: Passwordless and Passkeys Guide · Hardware Security Keys Guide · Conditional Access Guide · Authenticator Apps and OTP Guide · Active Directory and Entra ID Hardening Guide