Moving Windows Hello for Business policy off Group Policy looks like a one-line job: switch off the Hello GPO and let Intune take over. On one enterprise laptop I worked on, that plan would have changed nothing. The setting that mattered came from a GPO with nothing about Hello in its name.
Windows Hello for Business (Hello) lets users sign in with a PIN or biometric that unlocks a key on the device. Its policy can come from Group Policy or Intune, and Group Policy wins. So the order of the move decides whether users notice it.
Find every GPO that carries a Hello setting, not just the ones named after Hello. Map each setting to its PassportForWork CSP node. Build the Intune policy first, with the same values, for every device the GPOs reach. Then set each Hello setting in each GPO to Not Configured while the GPO keeps applying. Don't deny it, unlink it or set the setting to Disabled. After gpupdate /force, the Group Policy key should be empty and the Intune key should hold the same values. Record every setting where the old GPOs and Intune disagree before anyone deletes a GPO.
The problem: the Hello setting is not always in the Hello GPO
The laptop's PIN length did not match the Intune policy. The domain had two GPOs named after Windows Hello for Business. One was denied to the device. The other did not apply to it at all. Neither set a PIN length.
The value came from a third GPO: a general computer policy that carried telemetry and other unrelated settings, plus one Hello setting. Nobody had looked at it, because its name said nothing about Hello. The migration work had been aimed at the wrong objects.
Step 1: inventory every GPO that carries a Hello setting
Hello settings sit in two folders of the Group Policy editor. Microsoft's Windows Hello for Business policy settings page puts the feature settings under Computer Configuration › Administrative Templates › Windows Components › Windows Hello for Business, and several also under User Configuration. The PIN rules are elsewhere: Computer Configuration › Administrative Templates › System › PIN Complexity. A review of the Hello folder alone misses every PIN setting.
On the device, Group Policy writes them under one key per scope. Microsoft documents these as the location of the GPO's Enabled value:
HKEY_USERS\<UserSID>\SOFTWARE\Policies\Microsoft\PassportForWork (user GPO; HKCU for the signed-in user)
Any value under these keys came from a GPO. To find which one, use the Group Policy operational log, not GPO names. I cover that in finding which GPO sets a registry value with events 5312 and 5313. For each GPO, record:
| Column | Why you need it |
|---|---|
| The GPO and where it is linked | Which devices and users it reaches. |
| Every Hello setting it carries, with its value | What Intune must copy in step 3. |
| Whether it carries anything else | A GPO with unrelated settings must keep applying. That decides step 4. |
| Whether it applies today | A denied GPO changes nothing now, but contests Intune if anyone brings it back. |
Why it happens: Group Policy outranks Intune for Hello
Microsoft's Configure Windows Hello for Business page gives the order in which Hello policy is enforced:
- User - GPO
- Computer - GPO
- User - PassportForWork CSP
- Device - PassportForWork CSP
- Exchange ActiveSync - DeviceLock CSP
The PassportForWork configuration service provider (CSP) is how Intune sends Hello policy to the device. Both Group Policy sources rank above it. The same page says: "If you mix GPO and CSP policy settings, the conflicting CSP settings aren't applied until the group policy settings are cleared." The cloud Kerberos trust guide is blunter: "If you deploy Windows Hello for Business configuration using both Group Policy and Intune, Group Policy settings take precedence, and Intune settings are ignored."
That is the reason for the order in this post. While a GPO still sends a value, the Intune value for that setting waits. When the GPO value goes, the Intune value takes over. If the two match, the user sees nothing.
On the laptop I examined, this worked setting by setting. The GPO's PIN length was enforced over Intune's, while Hello settings only Intune sent did apply. More in Group Policy beats Intune, one setting at a time.
The same setting has two names. Microsoft's registry table shows the Group Policy value for turning Hello on as Enabled, and the CSP value as UsePassportForWork. A comparison that matches value names misses this pair.
Disabled is not Not Configured. Disabled is a value, and Group Policy keeps sending it. For Use Windows Hello for Business, Microsoft says: "If you disable this policy setting, the device doesn't provision Windows Hello for Business for any user". Disabled keeps Group Policy in charge, with a different answer.
How to verify: map every setting and read both registry keys
Step 2: map each Group Policy setting to its CSP node
Every node below sits under ./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/, where {TenantId} is your Microsoft Entra tenant ID as a GUID "without curly braces". The table lists only what Microsoft documents on the policy settings page, the CSP page and the cloud Kerberos trust guide.
| Group Policy setting (path) | CSP node | Intune settings catalog |
|---|---|---|
| Use Windows Hello for Business (Computer or User › Administrative Templates › Windows Components › Windows Hello for Business) | UsePassportForWork | Windows Hello for Business › Use Windows Hello For Business |
| Its option Don't start Windows Hello provisioning after sign-in | DisablePostLogonProvisioning (device only) | Search the catalog, or custom OMA-URI |
| Use a hardware security device (Computer, same folder) | RequireSecurityDevice | Windows Hello for Business › Require Security Device |
| Its option to exclude TPM revision 1.2 | ExcludeSecurityDevices/TPM12 (device only) | Search the catalog, or custom OMA-URI |
| Use certificate for on-premises authentication (Computer or User, same folder) | UseCertificateForOnPremAuth (device only) | Search the catalog, or custom OMA-URI |
| Use cloud Kerberos trust for on-premises authentication (Computer only) | UseCloudTrustForOnPremAuth | Windows Hello for Business › Use Cloud Trust For On Prem Auth |
| Minimum PIN length, Maximum PIN length, Require digits, lowercase, uppercase or special characters, Expiration, History (Computer › Administrative Templates › System › PIN Complexity) | PINComplexity/MinimumPINLength, MaximumPINLength, Digits, LowercaseLetters, UppercaseLetters, SpecialCharacters, Expiration, History (device and user) | Search the catalog, or custom OMA-URI |
| Turn off smart card emulation; Allow enumeration of emulated smart card for all users | Not available | None. Group Policy only. |
Three traps in that table:
- One GPO setting can be two CSP nodes. The TPM 1.2 exclusion is an option inside Use a hardware security device. The post-sign-in switch is an option inside Use Windows Hello for Business. Set the parent to Not Configured and its option goes too, so Intune needs both nodes.
- The value types differ. A GPO is Enabled, Disabled or Not Configured. Most CSP nodes are true or false, but the PIN character rules are numbers. For
Digits, 1 means Hello "requires users to include at least one digit in their PIN" and 2 means it "prevents users from using digits in their PIN". Copy the meaning, not the raw number. - Two settings have no Intune equivalent. Decide before step 4 whether you still need them.
What the settings that usually trip a migration do, in Microsoft's words:
| CSP node | What Microsoft says it does |
|---|---|
DisablePostLogonProvisioning | "Don't start Windows Hello provisioning after sign-in." true means "Provisioning Disabled." |
ExcludeSecurityDevices/TPM12 | "If you enable this policy setting, TPM revision 1.2 modules will be disallowed from being used with Windows Hello for Business." |
UseCertificateForOnPremAuth | "If you enable this policy setting, Windows Hello for Business will wait until the device has received a certificate payload from the mobile device management server before provisioning a PIN." |
UseCloudTrustForOnPremAuth | "Boolean value that enables Windows Hello for Business to use Microsoft Entra Kerberos to authenticate to on-premises resources." |
PINComplexity/MinimumPINLength | The minimum number of characters in the PIN, from 4 to 127. |
One more check. If a GPO enables Use certificate for on-premises authentication and Intune uses cloud Kerberos trust, you are changing the trust model, not moving a setting. Microsoft says "Cloud Kerberos trust is incompatible with certificate trust", and "There is no direct migration path from a certificate trust deployment to a cloud Kerberos trust deployment." Keep that out of this project.
Read both registry keys on a device
Intune writes Hello policy to a tenant-scoped key. Microsoft's table gives it as:
The paths look alike. Group Policy has Policies\Microsoft; Intune has Microsoft\Policies. The Intune side is covered in depth in proving the Hello policy on the laptop.
This script reads both sources and lines them up setting by setting. It renames the Group Policy Enabled value to UsePassportForWork so the pair matches. Run it as the signed-in user, not in an elevated window under another admin account, so HKCU is the user's own hive.
Read-only: only Test-Path, Get-Item and Get-ChildItem. Microsoft documents the key paths and the Enabled / UsePassportForWork pair; subkey and value names below them are as seen on enterprise laptops.
In a large estate, Intune often already has a Hello policy for cloud-joined devices. A device in scope of both can look like this:
- Same: GP still wins. Safe to move. Nothing changes when the GPO value goes.
- GP only: no Intune value. Not safe yet. Remove the GPO value now and the device falls back to the default. Add it to Intune first.
- DIFFERENT: GP wins today. Not safe. Users get the Intune value after the move. Here, Intune would start Hello setup after sign-in where the GPO stops it, and block TPM 1.2 devices the GPO allows. Decide which value is right first.
The fix: Intune first, then Not Configured in the GPO
Step 3: configure Intune first, with the same values
Build one Intune policy holding every Hello setting from your inventory, with the GPO's values. While the GPO still applies, users see nothing, because Group Policy wins and the Intune values wait. You are putting the new floor in before you take the old one out.
Microsoft lists several Intune policy types for Hello, including the settings catalog, a custom policy through the PassportForWork CSP and the account protection policy. The cloud Kerberos trust guide uses the settings catalog, so the path below does too. Keep every Hello setting in one policy. Microsoft's walkthrough warns: "If two configuration profiles are in conflict, then the setting isn't applied."
- In the Microsoft Intune admin center, select Devices › Manage devices › Configuration › Create › New policy.
- For Platform, select Windows 10 and later. For Profile type, select Settings catalog. Select Create.
- In Basics, name the policy after what it replaces. Select Next.
- In Configuration settings, select Add settings. Search the picker for each setting in your step 2 table. Microsoft lists Use Windows Hello For Business, Use Cloud Trust For On Prem Auth and Require Security Device in the Windows Hello for Business category. A setting with (User) in its name applies to users; the rest apply to devices.
- Set each value to match the GPO, including ones that look like defaults. Where you chose a different value in step 2, use that.
- Select Next until you reach Assignments, then Add groups. Cover every device the GPOs reach.
- Select Next. In Review + create, select Create.
If a node is not in the catalog, use a custom profile with its OMA-URI, for example ./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/UseCloudTrustForOnPremAuth, type bool. Once devices check in, run the script on a few. Every row should read Same: GP still wins, apart from values you chose to change.
Step 4: set each Hello setting to Not Configured, and leave the GPO applying
In each GPO from your inventory, set every Hello setting to Not Configured, in both Computer and User Configuration and in System › PIN Complexity. Leave the GPO linked, enabled and in scope.
Why not deny or unlink it? A GPO like the one in this post carries other settings that must keep applying. Denying it to fix one Hello value would take the telemetry settings and everything else with it. Not Configured changes only the Hello settings. And not Disabled, because Group Policy keeps sending a Disabled value and keeps winning.
Go one GPO at a time, starting with the one that reaches the fewest devices. Check a few of its devices before the next GPO.
Fix it at the source, never with a registry script
If you have heard that Administrative Template settings "tattoo" the registry, read the GPO tattooing myth. On the laptop I examined, the value that looked stranded was being rewritten by live policy.
Proof it worked: the Group Policy key is empty and Intune holds the same values
Step 5: verify per device and per setting
Group Policy refreshes in the background. To check a device now, refresh it yourself. Microsoft's gpupdate reference says /force "Reapplies all policy settings. By default, only policy settings that have changed are applied." Then check the Group Policy keys and rerun the script.
Here the team chose in step 2 to keep the GPO's behaviour, so Intune now holds the GPO's old values for the two earlier differences.
Good looks like this:
- The Group Policy keys are gone, or hold no Hello values.
- Every row reads Intune only, with the values from your step 1 inventory.
- Users sign in and unlock with the same PIN as before, with no new setup prompt.
Bad looks like this:
- A GP column still has a value after
gpupdate /force. Another GPO still sends it. Back to step 1, with events 5312 and 5313. - A setting has vanished from both sides. Intune does not cover it: the device is outside the assignment, or the setting is missing from the policy. Fix the Intune policy.
- Intune tenant keys found: 0. The device gets no Intune Hello policy. Check its enrollment.
Check a handful of devices per GPO. Devices in different OUs and groups get different policy, so one healthy laptop does not prove the scope.
Step 6: record where the old GPOs and Intune differ, before anyone deletes them
Once the Hello settings are Not Configured, someone will want to delete the old Hello GPOs. First, write down every setting where any old GPO, including denied and out-of-scope ones, holds a different value from Intune. If a GPO is ever relinked, restored or copied, those are the settings where it takes control back.
| Setting (CSP node) | Old GPO value | Intune at the start | Decision |
|---|---|---|---|
DisablePostLogonProvisioning | Setup not started after sign-in | Setup starts after sign-in | Intune changed to match before step 4. Review later as its own change. |
ExcludeSecurityDevices/TPM12 | TPM 1.2 allowed | TPM 1.2 excluded | Intune allows TPM 1.2 for now. Microsoft recommends excluding it: planned follow-up. |
UseCertificateForOnPremAuth | Disabled | Not set | No change. Disabled and not configured behave the same. |
Illustrative table. The pattern is real: on one enterprise laptop, two old Hello GPOs that no longer applied would have contested Intune on DisablePostLogonProvisioning and ExcludeSecurityDevices/TPM12 if either came back into scope.
On TPM 1.2, Microsoft says: "It's recommended to exclude TPM 1.2 devices from Windows Hello for Business provisioning." For the certificate setting, it gives Disabled and not configured the same result: a key or a Kerberos ticket is used instead.
Only when that record exists should anyone delete an old Hello GPO. A GPO with unrelated settings stays, its Hello settings at Not Configured.
References
- Configure Windows Hello for Business - Microsoft Learn. Precedence order, policy conflicts, MDMWinsOverGP, Intune policy types and both registry paths.
- Windows Hello for Business policy settings - Microsoft Learn. Each setting with its CSP and GPO path, and the settings with no CSP.
- PassportForWork CSP - Microsoft Learn. Node names, value types, allowed values and scope.
- Windows Hello for Business cloud Kerberos trust deployment guide - Microsoft Learn. Group Policy precedence over Intune, settings catalog names and the certificate trust warning.
- Walkthrough: create a settings catalog policy - Microsoft Learn. The Intune click path and the profile conflict rule.
- gpupdate - Microsoft Learn. What
/forcedoes.
Related reading on EndpointWeekly
- Find which GPO sets a registry value - the step 1 inventory.
- Group Policy beats Intune for Hello, per setting - the precedence behind this order.
- The GPO tattooing myth - why Not Configured is enough.
- Prove the Hello policy on the laptop - reading the Intune key.
- Windows Hello for Business PIN complexity - every PIN setting.
- Moving off Group Policy - the wider migration.
- Disable Windows Hello for Business cleanly - if the goal is to switch Hello off.
Device findings come from enterprise laptops examined read-only. Script output blocks are illustrative. Microsoft facts were checked against the pages above on 31 October 2026.