A brand-new Autopilot device finishes the Enrollment Status Page, the user lands on the desktop, and up pops "Set up a PIN" - or worse, on a hybrid device, WHfB provisioning fails and the user is stuck. Nobody on your team configured that. This post explains why Windows Hello for Business (WHfB) provisions during Autopilot whether you asked for it or not, how the Enrollment Status Page (ESP) fits in, and how to take control of exactly when - or whether - it happens.
The problem: provisioning you did not schedule
Two things collide during an Autopilot deployment. First, WHfB is enabled by default on Microsoft Entra joined devices - and Autopilot produces Entra joined devices. Second, the tenant-wide WHfB enrolment policy is evaluated at the moment a device enrols. So unless you have explicitly turned it off, every Autopilot device is told "provision Hello" as it comes up, and the user gets the PIN setup experience right after sign-in.
On Entra joined devices that usually just works. On Entra hybrid joined Autopilot devices it is a classic support call: WHfB tries to provision, but the freshly deployed machine may not yet have line of sight to a domain controller (DC), or the on-premises prerequisites have not synced, and provisioning errors out at the worst possible moment - first boot for a new user.
Why it happens: the tenant policy fires at enrolment
The tenant-wide policy (Intune › Devices › Windows › Windows Enrollment › Windows Hello for Business) has one behaviour people forget: it only applies at enrolment time, and it applies to all devices that enrol. That is exactly the window Autopilot runs in. If that policy is left at its default, Autopilot devices provision Hello before your carefully targeted device-configuration policy has necessarily landed.
That is why Microsoft's own guidance is to disable the tenant-wide policy and instead enable WHfB through a policy targeted at a security group - so provisioning happens on your terms, for the devices and users you choose, with the trust model you intend. The tenant policy lives here:
How the Enrollment Status Page changes the timing
The ESP can hold a user at the out-of-box experience (OOBE) until the device has received its required policies. That is the lever that lets you control WHfB during Autopilot. If your "disable WHfB" or "use cloud Kerberos trust" device policy is in the ESP's blocking set, it applies before the user reaches the desktop - so Hello never provisions with the wrong (default) configuration, and hybrid devices are not asked to provision before they can reach a DC.
Understanding which policy wins matters here. WHfB settings resolve in this fixed order:
| Priority | Source |
|---|---|
| 1 (highest) | User - Group Policy |
| 2 | Computer - Group Policy |
| 3 | User - PassportForWork CSP |
| 4 | Device - PassportForWork CSP |
| 5 (lowest) | Exchange ActiveSync - DeviceLock CSP |
How to verify what a device did during OOBE
After an Autopilot run, check whether Hello provisioned and why. dsregcmd /status shows the credential state and the join type - on a hybrid device confirm both join states are YES before expecting Hello to work on-premises:
Provisioning activity is logged in the User Device Registration admin log (Event Viewer › Applications and Services Logs › Microsoft › Windows › User Device Registration). That is where a provisioning attempt shows up - Event ID 358 is the "we're starting" marker, and a failed attempt on a hybrid device shows its real reason nearby, usually "no DC line of sight" or a missing prerequisite:
The fix: decide when Hello provisions
Option A - Provision on your terms (recommended)
- Disable the tenant-wide enrolment policy so Autopilot devices do not auto-provision with the default configuration.
- Create a targeted device policy (Settings Catalog / Account protection) that enables WHfB with your chosen trust model - cloud Kerberos trust for most - and assign it to a pilot security group.
- Add that policy to the ESP blocking set so it lands during OOBE, before the desktop.
Option B - Defer provisioning until after enrolment
If you want the device fully enrolled and managed before Hello sets up (for example, so a hybrid device has DC connectivity first), use Don't start Windows Hello provisioning after sign-in - the DisablePostLogonProvisioning setting on the Use Windows Hello for Business policy. Hello then provisions when your process triggers it, not automatically at first sign-in.
MDMWinsOverGP does not arbitrate WHfB (it only covers the Policy CSP, and WHfB lives in the PassportForWork CSP). On an Entra hybrid joined Autopilot device that also receives Group Policy, a stray GPO can silently override your Intune WHfB settings. Confirm the device gets its WHfB policy from exactly one channel.Proof it worked
A controlled Autopilot run looks like this: the device enrols with the tenant policy off, your targeted trust-model policy applies during ESP, and Hello provisions with your configuration - or defers cleanly if you chose Option B. dsregcmd /status shows the intended state (for cloud trust, OnPremTgt : YES after first DC sign-in), and the User Device Registration log shows a clean provisioning sequence with no OOBE-time failures.
References
- Configure Windows Hello for Business (tenant policy, precedence)
- Set up the Enrollment Status Page
- Windows Hello for Business policy settings (DisablePostLogonProvisioning)
- Windows Autopilot Enrollment Status Page
Script for this post is in Daily-Tasks.