Windows Hello for Business via Intune: the two paths, and picking the right one

Windows Hello for Business (WHfB) replaces the password at the Windows sign-in with a device-bound gesture — a biometric or a TPM-backed PIN. The security win is that the credential never leaves the device and can't be phished or replayed. But how you deploy it from Intune matters more than most people realise, because there are two distinct paths with different scoping behaviour — and that's where this post starts.

01The two paths — this is the crux

A tenant-wide default vs a group-scoped profile. They are not the same.

	Enrollment path	Device-configuration profile
Where	Devices → Enroll devices → Windows Hello for Business	Devices → Configuration → a WHfB profile
Scope	Tenant-wide — applies at enrollment, all devices	Group-scoped — include/exclude specific groups
Targeting	All-or-nothing; no group targeting	Pilot groups, exclusions, phased rollout
Priority	Lowest — the baseline default	Layered on top of the enrollment default
Best for	Setting (or explicitly disabling) the org-wide baseline	Controlled rollout, testing, per-group policy

Why the distinction bites

The enrollment-path setting is applied once, at enrollment, to everything — great for setting a baseline, useless for a careful pilot. If you want to roll WHfB out to a test group first, watch for problems, then widen — you need the device-configuration profile, scoped to an include group with an exclude group for the accounts that shouldn't get it. A common clean pattern is to set the enrollment default to "not configured / disabled" and drive the actual rollout entirely through targeted config profiles, so you're never fighting a tenant-wide default you can't aim.

02Prerequisites

Hardware and join state decide whether it can work at all.

# WHfB needs these in place
- Windows 10/11, Entra joined or hybrid joined + Intune enrolled
- A TPM (required if you enforce "Require Security Device" — recommended)
- For hybrid / on-prem resource access: a trust model —
  Cloud Kerberos trust is the modern, simplest choice
- Security groups for the rollout: an INCLUDE (pilot) group
  and an EXCLUDE group (accounts that must not get WHfB)

Cloud Kerberos trust and the security-device requirement

For on-prem resource access, Cloud Kerberos trust is the modern trust model and far simpler than the older certificate/key trust setups — enable it unless you have a specific reason not to. And Require Security Device = true means WHfB won't provision on machines without a usable TPM; that's the right posture for security, but it's also a source of "error" check-ins on older hardware (see the failures section).

03The configuration (profile path)

A group-scoped profile with sensible PIN and device settings.

Create the WHfB device-configuration profile, assign the include (pilot) group, and add the exclude group. The settings that matter:

Setting	Value	Why
Use Windows Hello for Business	Enabled (true)	Turns WHfB on for the scoped users
Require Security Device	true	Only provision where a TPM backs the key
Use Cloud Trust for On-Prem Auth	Enabled	Cloud Kerberos trust for on-prem resources
Minimum PIN Length	6	A sensible floor above the 4-digit default
Maximum PIN Length	127	Allow long PINs for those who want them
PIN History	10	Prevent immediate PIN reuse
Expiration	0 (never)	A device-bound PIN doesn't need forced expiry
Enable PIN Recovery	true	Let users recover a forgotten PIN without a wipe

Note the Expiration = 0 choice: unlike a password, a WHfB PIN is device-bound and TPM-protected, so forcing it to expire adds churn without adding security — most deployments leave it non-expiring. And PIN Recovery = true is what saves you help-desk tickets when someone forgets their PIN.

04Reading the results

Succeeded vs error, and confirming it on a device.

The policy overview shows the check-in status — Succeeded against Error / Conflict counts across the assigned groups. Because WHfB depends on hardware (the TPM / security-device requirement), it's normal to see a non-trivial Error count relative to LAPS — those are frequently devices that can't meet Require Security Device. Confirm success on a real device: after the policy applies and the user signs out/in, they're prompted to set up a PIN, and Sign-in options at the lock screen show the PIN (keypad) and biometric methods.

05Failures & remediation

Most WHfB errors are hardware or trust, not policy.

What the errors usually mean

Error with "Require Security Device" on → the device has no usable/enabled TPM; enable/clear the TPM in firmware, or exclude genuinely incapable hardware. PIN setup never prompts → the enrollment-path default may be disabling WHfB and overriding your profile, or the user/device isn't in the include group — check both. Conflict → the enrollment-path setting and the config profile (or two profiles) disagree; resolve by making the enrollment default "not configured" and driving policy from the profile. On-prem resources still prompt for a password → the trust model (Cloud Kerberos trust) isn't fully configured; verify it end to end.

The single most common WHfB confusion is the two paths fighting each other — a config profile that "won't apply" is very often the tenant enrollment default winning. When results look wrong, check the enrollment-path setting first, then the group membership, then the hardware. Scattered TPM errors on old machines are expected and handled with an exclusion, not a fix.

The takeaway

Windows Hello for Business has two Intune deployment paths: the enrollment path is a tenant-wide, all-or-nothing baseline; the device-configuration profile is group-scoped and is how you actually pilot and roll out. Set the enrollment default out of the way, drive the rollout from a scoped profile (include pilot + exclude group), require a security device, use Cloud Kerberos trust for on-prem, and expect hardware-driven errors on TPM-less machines — which you exclude rather than fight. When a profile "won't apply," the tenant default is the usual culprit.