Here is a fact that surprises a lot of admins: Windows Hello for Business (WHfB) is enabled by default on every Microsoft Entra joined device. You did not turn it on. Autopilot did, silently, the moment the device enrolled. So when leadership says "we're not ready for passwordless, turn it off," you discover that "off" is not one switch - and that flipping the obvious one leaves orphaned keys scattered across your directory. This post covers how to disable WHfB cleanly, at the right layer, and how to clean up the credentials it already provisioned.
The problem: it was on before you decided anything
WHfB provisioning starts automatically after a user signs in to an Entra joined device, because the default state is "enabled." There is also a tenant-wide enrolment policy that most people never look at. The catch with that tenant policy: it only applies at enrolment time, and it applies to every device that enrols. So changing it does nothing for the thousands of devices already out there - and if you leave it enabled, every new Autopilot device keeps provisioning Hello regardless of what you do later.
That combination - default-on, tenant policy that only bites at enrolment, and per-device policy that applies afterwards - is why "just disable Windows Hello" turns into a three-part job.
Why it happens: three policy layers, one default
WHfB is configured through the PassportForWork Configuration Service Provider (CSP) or Group Policy - never a mix of both. There are three places "enabled" can be decided, and they resolve in a strict order:
- Tenant-wide enrolment policy (Intune › Devices › Windows › Windows Enrollment › Windows Hello for Business) - evaluated only when a device enrols.
- Device configuration policy (Settings Catalog, Account protection, or a custom PassportForWork policy) - applied after enrolment, refreshed on the normal cycle.
- Group Policy - for Active Directory joined or Entra hybrid joined devices not managed by Intune.
MDMWinsOverGP setting does not apply to Windows Hello for Business. WHfB lives in the PassportForWork CSP, and MDMWinsOverGP only governs the Policy CSP. If you set WHfB by both GPO and CSP, the conflicting CSP settings are ignored until the Group Policy settings are cleared. Pick one channel per device and never mix them.How to verify the current state
Before you change anything, read where WHfB stands on a sample device. Two signals: the policy value in the registry, and whether a credential is actually provisioned. The enablement value lives here (device scope shown; a user-scope key can override it):
Group Policy writes a different value name (Enabled) under HKLM\SOFTWARE\Policies\Microsoft\PassportForWork. Then confirm whether a credential exists for the signed-in user:
The fix: disable at the right layer, then clean up
Step 1 - Stop new devices provisioning it
Set the tenant-wide policy to Not configured or disabled so new Autopilot enrolments do not turn Hello on:
Step 2 - Turn it off on devices already enrolled
The tenant policy will not touch existing devices, so push a device policy that sets Use Windows Hello for Business to Disabled. In a Settings Catalog or Account protection policy that is one toggle; as raw CSP or registry it is UsePassportForWork = 0:
| Channel | Key path | Value name | Disable value |
|---|---|---|---|
| CSP (device) | HKLM\SOFTWARE\Microsoft\Policies\PassportForWork\<TenantId>\Device\Policies | UsePassportForWork | 0 |
| GPO (device) | HKLM\SOFTWARE\Policies\Microsoft\PassportForWork | Enabled | 0 |
The Group Policy equivalent is Computer Configuration › Administrative Templates › Windows Components › Windows Hello for Business › Use Windows Hello for Business = Disabled. If you also want to stop auto-provisioning while a third-party tool handles it, that same policy exposes Don't start Windows Hello provisioning after sign-in (DisablePostLogonProvisioning).
msDS-KeyCredentialLink. "Disabled" is not "removed." Skipping the cleanup leaves orphaned keys behind.Step 3 - Clean up the credentials it already made
On each affected device, in the user's context, delete the Hello container so no stale credential lingers:
That removes the on-device credential cleanly. The registered public key then ages out; for a faster tidy-up, audit and remove stale entries from msDS-KeyCredentialLink (hybrid) or the user's registered keys in Entra ID, using the audit approach from the msDS-KeyCredentialLink deep dive.
Proof it worked
On a cleaned device, dsregcmd /status shows NgcSet : NO, the user is back to password/other sign-in, and no new Hello prompt appears at logon. New Autopilot devices enrol without provisioning Hello, and your directory key audit shows no growth in orphaned keys.
References
- Configure Windows Hello for Business (disable enrolment)
- Windows Hello for Business policy settings (Use Windows Hello for Business)
- PassportForWork CSP (UsePassportForWork / DisablePostLogonProvisioning)
- Set up the Enrollment Status Page
Script for this post is in Daily-Tasks.