Every few weeks I get a question from an MSP engineer that starts with some version of “we’re about to roll out Windows Hello for Business — key trust or cloud trust?” My answer has been the same for a couple of years now, but the question keeps coming because the documentation is sprawling and the old hybrid PKI diagrams still haunt everyone who deployed WHfB before 2022. If you have a hybrid Active Directory and a Business Premium tenant, you should be on cloud Kerberos trust. Full stop. Everything else is legacy baggage.
The prerequisites people still miss
Microsoft’s own planning guide is the source of truth, but two prereqs catch MSPs out every time.
First, domain controllers. Cloud Kerberos trust needs Windows Server 2016 or later DCs, fully patched, and you need enough read-write DCs in every AD site where users will authenticate. If your branch office has one creaky 2012 R2 box left, the sign-in will fail in ways that look like network issues and waste a day of your life.
Second, Microsoft Entra Kerberos has to be explicitly enabled against the on-prem domain. It’s not on by default. Skip it and users will provision a PIN happily, then fail to reach on-prem file shares the first time they try. The cloud Kerberos trust deployment guide walks through enabling it.
Where to configure it
For greenfield Autopilot tenants, the fastest path is the Intune tenant-wide enrolment policy at Intune admin center → Devices → Enrolment → Windows → Windows Hello for Business. Set it to Enabled and configure the defaults there. That covers OOBE.
For everything else, build an explicit Account Protection policy at Intune admin center → Endpoint security → Account protection → Create Policy → Windows → Account protection → Windows Hello for Business. This is the one you target at device groups for staged rollout. Microsoft’s tenant-wide policy guide explains the precedence rules; read it before you layer policies.
A rollout pattern that survives contact with users
I run three rings and I don’t apologise for how boring it looks.
Ring 1: five to ten IT-adjacent devices for two weeks. You’re looking for PIN provisioning completion and on-prem resource access — not for smiles.
Ring 2: one full business unit, minimum fifty devices, two to three weeks. This is where you catch VPN quirks, smartcard reader conflicts, and the one shared PC nobody told you about.
Ring 3: the rest of the fleet, staged over a fortnight by device group, not by user.
Stage by device, not by user, because Windows Hello is a per-device-per-user credential. Chasing user groups creates a weird matrix where someone’s laptop prompts for a PIN but their desktop doesn’t, and the helpdesk gets blamed for inconsistency.
The pitfalls that burn you
Rolling back is worse than rolling forward. Disabling the policy doesn’t remove provisioned PINs; it just stops new ones. Plan the forward path before you enable it.
Don’t mix trust types. If you have leftover key trust policy from an old deployment, retire it before enabling cloud Kerberos trust on the same fleet. The hybrid key trust guide is still published, and Microsoft explicitly recommends against key trust for new deployments — pay attention to that.
Shared and kiosk devices need explicit exclusions. WHfB binds a credential to a user-device pair, which is exactly wrong for a front-desk PC logged in as five different people a day. Use Intune filters to carve those devices out of the policy.
Get the prerequisites right, pick cloud Kerberos trust, ring it, and Windows Hello becomes the quietest part of your security stack. Which is what you want.
CIAOPS 