Windows Hello for Business — setup, adoption gaps, and common misconfigurations

← All articles

Windows Hello for Business (WHfB) replaces passwords with a PIN or biometric (fingerprint, face) that is tied to a specific device. It's one of the most effective security improvements available to Microsoft 365 organisations — but it's also one of the most commonly half-deployed. This guide covers what it does, how to deploy it correctly, what goes wrong, and how to measure adoption.

What Windows Hello for Business actually is

Standard Windows Hello is the consumer version — a PIN or fingerprint that unlocks your device. Windows Hello for Business is the enterprise version, and the difference is significant:

Device-bound credentials — the private key never leaves the device's TPM chip. Even if someone steals your password, they cannot sign in from another device without also physically having your hardware.
No password transmitted over the network — WHfB uses asymmetric cryptography. There is no password to intercept, replay, or phish.
Satisfies MFA — WHfB counts as a strong authentication method, satisfying Conditional Access policies that require MFA without requiring a second factor prompt.
TPM-backed — the private key is stored in the Trusted Platform Module, which means it cannot be extracted from the device even with administrative access.

Why it matters: phishing attacks that steal passwords are useless against WHfB. The credential is device-bound — there is no password to steal. It also eliminates the attack surface of "Remember MFA on trusted device" because the device itself is the authenticator.

Deployment models — which one you need

There are three deployment models. Getting this wrong is the most common misconfiguration:

Cloud-only (Azure AD joined) — for organisations with no on-premises Active Directory. Simplest to deploy. Works with Intune.
Hybrid Azure AD joined — for organisations with on-premises AD synced to Azure AD via Entra Connect. Requires a Key Distribution Service (KDS) on a Domain Controller running Windows Server 2016 or later. This is where most hybrid deployments fail.
On-premises only — rare, not relevant for Microsoft 365 tenants.

Common hybrid misconfiguration: the Intune policy to enable WHfB is deployed correctly, but the on-premises Key Distribution Service is not configured on Domain Controllers. Devices appear to set up Hello but then fail authentication with error 0x801c0016. Users get confused, disable it, and revert to passwords.

How to deploy WHfB via Intune

In the Intune admin centre, go to Devices → Windows → Windows Hello for Business
Set Configure Windows Hello for Business to Enabled
Set minimum PIN length (6+ recommended), enable letters and special characters for stronger PINs
Enable biometric authentication if your devices have compatible hardware
Set Use a Trusted Platform Module (TPM) to Required — this ensures the key is hardware-backed, not software-backed
If hybrid joined, configure the Key Distribution Service on Domain Controllers first

Alternatively, you can configure WHfB through an Identity Protection profile in Intune under Endpoint Security → Account Protection.

Measuring adoption gaps

Enabling the policy is only half the job. The critical question is: what percentage of your users have actually completed WHfB registration?

You can check this via the Microsoft Entra admin centre under Identity → Monitoring → Authentication methods → User registration details. Filter by Windows Hello for Business to see which users have registered.

Common reasons for low adoption after policy deployment:

Device doesn't have a TPM — older hardware may lack TPM 2.0. The policy can be set to "preferred" rather than "required" to fall back gracefully, but those devices won't get the security benefit.
Hybrid KDS not configured — as above. Users see the setup prompt but registration fails silently.
User skipped setup — if the policy isn't enforced (set to "required" rather than "enabled"), users can dismiss the Hello setup prompt and continue using their password.
Device not Azure AD joined or hybrid joined — WHfB requires the device to be joined to Azure AD. Workgroup devices or devices only domain-joined on-premises cannot use it.

WHfB vs FIDO2 security keys

Both are strong passwordless methods. The key difference is portability. WHfB is device-bound — the credential lives on one specific device. FIDO2 security keys (e.g. YubiKey) carry the credential on a physical key that can be used on any device. For most Microsoft 365 users, WHfB is the right choice. FIDO2 keys are better suited to shared workstations, kiosk devices, or users who regularly work from multiple machines.

What M365Clarity checks

M365Clarity's passwordless authentication check shows the percentage of users in your tenant who have registered for any passwordless method — including Windows Hello for Business, FIDO2, and the Microsoft Authenticator app passwordless sign-in. If the percentage is low despite having Intune policies in place, that's an adoption gap worth investigating.

The Intune Health Report also checks whether an authentication methods policy is configured that enables WHfB, and surfaces it in the context of your overall device management posture.

Check your passwordless adoption in 2 minutes

M365Clarity shows the percentage of users registered for WHfB and other passwordless methods — alongside your full device health picture. Free plan available.

Scan your tenant free →