Intune Says the Hello Policy Applied. Here Is How to Prove It on the Laptop.

You assign a Windows Hello for Business policy in Intune. The console turns green and says Succeeded. Then someone asks you to prove it is actually on the laptop, so you remote in, open the registry where every other Intune CSP policy writes its values, and find nothing at all. No key. Not an empty key. The key does not exist.

At that point most people conclude the policy failed to apply and start troubleshooting delivery. That is the wrong conclusion, and chasing it wastes hours. The policy is almost certainly applied perfectly. It is simply not written where you are looking, because Windows Hello for Business is one of the few CSPs that does not use the standard PolicyManager location. This post shows where it really goes, how to read it three different ways, and how to diff the endpoint against what Intune actually holds so you can answer "is it applied?" with evidence instead of a screenshot of a green tick.

The problem: the key you expect does not exist

Nearly every Intune Settings Catalog policy lands in one of two predictable places on the device. The delivered payload goes under PolicyManager\Providers\{EnrollmentId}, and the value Windows actually enforces appears under PolicyManager\current\device. Learn that pattern once and you can verify almost anything.

So you apply the same pattern to Windows Hello for Business, and this happens.

# The location that works for almost every other CSP policy
Test-Path 'HKLM:\SOFTWARE\Microsoft\PolicyManager\current\device\PassportForWork'

False

# Not a permissions problem - the neighbouring keys are all there
Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\PolicyManager\current\device' |
    Select-Object -ExpandProperty PSChildName

CredentialProviders
DeviceLock
Update
...
# PassportForWork is simply absent from this list

The user is signed in with Hello. Biometrics work. The PIN honours your minimum length. Everything behaves exactly as configured, and yet the key an experienced admin would check first is not there.

Why it happens: the CSP node carries the tenant GUID

The registry layout is not arbitrary. It mirrors the CSP node tree almost exactly, and the PassportForWork CSP is unusual in that its policy nodes are scoped per tenant. Microsoft documents the node as:

That {TenantId} segment is the whole explanation. Because the tenant GUID is part of the node path, it becomes part of the registry path too. The values land here instead:

The same documentation shows that the Biometrics nodes are not tenant-scoped — they sit at PassportForWork/Biometrics/... with no GUID. That asymmetry carries straight through to the registry, which is why a real device shows two sibling trees rather than one.

The setting that has three different names

There is a second trap hiding in the same Intune policy. Most WHfB profiles also set AllowPINLogon, which is not a PassportForWork setting at all — it belongs to the CredentialProviders area of the Policy CSP. It behaves differently in three ways at once.

First, it controls the legacy convenience PIN for domain users, not the Hello PIN. Microsoft's wording is explicit: it "allows you to control whether a domain user can sign in using a convenience PIN". Turning it off does not disable Windows Hello.

Second, it is an ADMX-backed policy. Those do not store a DWORD. They store the literal string <enabled/> or <disabled/>, which is why a value that reads <disabled/> is correct rather than corrupt.

Third, its ADMX mapping renames it. The CSP calls it AllowPINLogon; the registry value it ultimately drives is AllowDomainPINLogon under Software\Policies\Microsoft\Windows\System. One setting, three names, three locations.

How to verify: three ways to read what landed

1. The one-line check

This walks the whole PassportForWork tree, including the sub-keys, and prints every value with its data. It is the fastest way to answer "did anything arrive?" on a single machine.

Get-ChildItem -Recurse 'HKLM:\SOFTWARE\Microsoft\Policies\PassportForWork' |
  ForEach-Object {
      $k = $_
      $k.GetValueNames() | ForEach-Object {
          "{0,-42} = {1}" -f $_, $k.GetValue($_)
      }
  }

DisablePostLogonProvisioning               = 0
UseCloudTrustForOnPremAuth                 = 1
EnablePinRecovery                          = 1
RequireSecurityDevice                      = 1
UsePassportForWork                         = 1
TPM12                                      = 1
MinimumPINLength                           = 8
UseBiometrics                              = 1
FacialFeaturesUseEnhancedAntiSpoofing      = 1

If that returns values, Intune delivered the policy, whatever the console says. If the key does not exist at all, it genuinely did not arrive.

The registry values worth knowing

Every value below lives under this parent key, where the GUID is your own tenant ID:

2. The device report script

Get-WHfBPolicyOnDevice.ps1 runs all of the above plus the enrolment state, the CredentialProviders values, any competing Group Policy keys, the MDM event history and dsregcmd output, then writes a single report file. It is read-only and needs no credentials.

3. Collect it fleet-wide with no script (Intune 2607 and later)

This is the newest option and the one most people have not noticed yet. Intune's properties catalog can now collect selected registry values into Device Inventory, so you can see WHfB policy state across the estate without deploying a script at all.

1. Sign in to the Microsoft Intune admin center.
2. Go to Devices › Windows.
3. Under Manage devices, select Configuration › Create › New Policy.
4. Set Platform to Windows 10 and later and Profile type to Properties catalog, then select Create.
5. Give the profile a name, for example "Inventory — WHfB policy state", and select Next.
6. Select Add properties, choose the Registry category, and add your PassportForWork key path. Add the PINComplexity and ExcludeSecurityDevices sub-keys as separate entries.
7. Select Next, set any scope tags, then assign the profile to your Windows device group.
8. Complete Review + create.
9. To read the results, go to Devices › Windows, pick a device, and under Tools select Device Inventory.

Three limits matter for this use case. Collection is HKLM only, capped at 100 registry keys per device and 6 KB per value, and it is non-recursive — it reads values directly under a key, which is exactly why the two sub-keys need their own entries. Initial collection can take up to 24 hours because the full sync runs once a day.

The MDM events that tell you whether sync is healthy

Policy that never arrives usually leaves a trail. All of the events below are in one channel:

Read that carefully, because it is the single most common misreading of this log. Two errors are present, but neither is a WHfB failure — one is a broken display-scaling CSP and the other is an unrelated ADMX ingestion problem. A device can log dozens of Event 404s and still have perfect Hello policy. Always read the CSP URI in the message before attributing a failure.

The fix: diff the device against Intune

Reading the endpoint only tells you half the story. To prove the endpoint matches intent you need the tenant side too, and that is harder than it sounds because WHfB policy does not live in one place in Intune either.

One policy blade, three Graph collections

Depending on how each policy was created, it sits in a different Graph collection:

In a real tenant this bites. A profile setting DisablePostLogonProvisioning through a custom OMA-URI lives in deviceConfigurations, so a script that reads only configurationPolicies reports the setting as "not configured" while the device happily enforces it.

Settings Catalog values are nested several levels deep

The second obstacle is the shape of the data. Settings Catalog does not return flat name and value pairs. Real values hide inside groupSettingCollectionValue → children, and a naive dump returns parent definition IDs that tell you nothing.

function Expand-SettingInstance {
    param($Instance, [int]$Depth = 0)

    $defId = $Instance.settingDefinitionId

    switch -Wildcard ($Instance.'@odata.type') {
        '*ChoiceSettingInstance' {
            # the chosen option is the definition id plus a suffix
            $val = $Instance.choiceSettingValue.value -replace [regex]::Escape($defId + '_'), ''
            "{0} = {1}" -f $defId, $val
            foreach ($c in $Instance.choiceSettingValue.children) { Expand-SettingInstance $c ($Depth+1) }
        }
        '*GroupSettingCollectionInstance' {
            foreach ($g in $Instance.groupSettingCollectionValue) {
                foreach ($c in $g.children) { Expand-SettingInstance $c ($Depth+1) }
            }
        }
        '*SimpleSettingInstance' {
            "{0} = {1}" -f $defId, $Instance.simpleSettingValue.value
        }
    }
}

Run that against a WHfB policy and the nesting resolves into something you can actually compare against a registry value:

[group] passportforwork_{tenantid}
  passportforwork_{tenantid}_policies_pincomplexity_minimumpinlength = 8
  passportforwork_{tenantid}_policies_enablepinrecovery              = true
  passportforwork_{tenantid}_policies_requiresecuritydevice          = true
  passportforwork_{tenantid}_policies_usepassportforwork             = true
passportforwork_biometrics_facialfeaturesuseenhancedantispoofing     = true

Which source actually won: MDM or Group Policy

Group Policy and Intune can both set the same WHfB values, and by default Group Policy wins. The device records the outcome, which means you never have to guess. Under PolicyManager\current\device\<Area> you get three companion values for an ADMX-backed setting:

To find the competing GPO, check the Group Policy branch directly. It is a different hive path entirely from the MDM one:

If you need to change or remove that GPO, the console path is:

1. Open Group Policy Management (gpmc.msc) on a management workstation.
2. Find the GPO linked to the OU containing the affected devices, right-click it and select Edit.
3. Navigate to Computer Configuration › Policies › Administrative Templates › Windows Components › Windows Hello for Business.
4. Set the conflicting setting to Not Configured so the MDM value applies.
5. Run gpupdate /force on a test device and re-read the registry to confirm the MDM value is now in place.

Deploy the check as an Intune Remediation

To answer the question across the fleet rather than one laptop, deploy the detection script. Microsoft's documentation is explicit that "a script package can contain a detection script only or both a detection script and a remediation script", which matters here because this check should be detection-only.

1. Sign in to the Microsoft Intune admin center.
2. Go to Devices › Manage devices › Scripts and remediations.
3. Select Create script package and name it, for example "WHfB policy delivery — detect".
4. On the Settings page, upload Detect-WHfBPolicyDelivery.ps1 as the Detection script file.
5. Leave the Remediation script file empty.
6. Set Run this script using the logged-on credentials to No, and Run script in 64-bit PowerShell to Yes.
7. Select Next, apply any scope tags, then assign to your Windows device group.
8. Set the schedule to Daily and complete Review + create.

There is deliberately no remediation script. WHfB policy is owned by the MDM channel: anything a script writes gets overwritten at the next sync, and the real fix — assignment, filter, licence or GPO — lives in the service, not on the endpoint. Detection finds the affected devices; you fix the cause centrally.

Two details make the difference between a detection people trust and one they mute. Count only the Event 404s whose CSP URI actually mentions PassportForWork or CredentialProviders, or unrelated ADMX failures will flag healthy machines. And raise an issue only when a GPO value differs from the MDM value, not merely because a GPO exists.

Proof it worked

Here is the comparison script against a real hybrid-joined laptop. Ten settings match across both sides, and the eleventh is a true negative worth understanding.

=== Reading WHfB policy from this device ===
  Found 10 WHfB-related value(s) on this device.

=== Reading WHfB policy from Intune ===
  Found 11 WHfB setting(s) configured in Intune.

=== Comparison ===

SETTING                                  STATUS     INTUNE     DEVICE
AllowPINLogon                            MATCH      0          0
DisablePostLogonProvisioning             MATCH      False      0
EnablePinRecovery                        MATCH      true       1
FacialFeaturesUseEnhancedAntiSpoofing    MATCH      true       1
MinimumPINLength                         MATCH      8          8
RequireSecurityDevice                    MATCH      true       1
TPM12                                    MATCH      true       1
UseBiometrics                            MATCH      true       1
UseCloudTrustForOnPremAuth               MATCH      true       1
UsePassportForWork                       MATCH      true       1
enablewebsignin                          MISSING    1          (absent)

  MATCH 10   MISMATCH 0   MISSING 1   EXTRA 0

Note how the normalisation works. Intune reports booleans as true and false; the registry stores 1 and 0. A naive string comparison would report ten mismatches on a perfectly healthy device, so both sides are normalised before comparing.

The MISSING row is not a fault either. enablewebsignin belongs to a separate Web Sign-in policy that this device is not assigned, so it is correctly absent. That is why the output distinguishes MISSING (Intune has it, the device does not) from MISMATCH (both have it, they disagree) — only the second is unambiguously a problem.

The detection script reduces the same picture to one line per device, small enough for Intune's 2,048-character output limit:

OK Computer=LAPTOP-01;PolicyDelivered=Yes;UsePassportForWork=1;MinimumPINLength=8;
CloudTrust=1;RequireSecurityDevice=1;GPOPresent=Yes;NgcSet=YES;
WHfBCsp404Last3d=0;AllCsp404Last3d=24

That single line is the whole argument of this post. GPOPresent=Yes but no conflict, so no issue is raised. AllCsp404Last3d=24 looks alarming until you see WHfBCsp404Last3d=0 next to it — two dozen CSP failures on this machine, none of them WHfB. And NgcSet=YES confirms the policy did not merely arrive, it produced a working Hello credential.

That last distinction matters more than anything else here. Policy delivery and Hello provisioning are separate outcomes. A device can have every value correct and still show NgcSet : NO because the user has not enrolled yet. Check both, and the green tick in the console stops being the thing you have to trust.

References

• PassportForWork CSP — documents the {TenantId} node path and every policy node used above
• CredentialProviders Policy CSP — AllowPINLogon, its convenience-PIN scope, and the ADMX mapping to AllowDomainPINLogon
• Collect device properties with the Intune properties catalog — registry inventory, and its HKLM-only, 100-key and 6 KB limits
• Use Remediations to detect and fix support issues — detection-only packages, exit code semantics and the 2,048-character output limit
• Understanding ADMX-backed policies — why some values store <enabled/> and <disabled/> instead of a DWORD

Related reading on this site

• The complete Windows Hello for Business Event ID catalog — covers the User Device Registration, HelloForBusiness and AAD logs, which sit alongside the MDM channel used here
• dsregcmd /status decoded — the full field reference behind the NgcSet and PRT checks
• WHfB PIN complexity: every setting, CSP and GPO — goes deeper on the PIN settings referenced in the registry table

Microsoft MVP community deep-dives