This blog is about a frustrating issue in which Windows Hello for Business (WHfB) shows the “Set up a PIN” screen but fails to display the PIN input field.
1. Set up A Pin Issue on Reddit
It started with a Reddit post. Someone tagged me asking for help with a strange issue: the Windows Hello for Business (WHfB) “Set up a PIN” screen appeared, but no PIN input field was shown.
It first looked like it was trying to do something, but the textbox simply wasn’t there and wasn’t showing up. Also, trying to manually add a PIN through Settings > Accounts > Sign-in options led to the same broken Set Up A Pin state.
As shown above, there was absolutely no option to enter or set up a PIN. At first, it looked like a familiar misconfiguration or a CIS baseline breaking Windows Hello For Business (which wouldn’t surprise me)
2. Reproducing the Set up A Pin Issue
The original poster offered a test account and the option to upload the device hash, so I could try reproducing it myself. I uploaded the hash into my lab environment and ran through an Autopilot deployment on a VM.
Sure enough, I hit the exact same issue: the WHfB screen appeared, but there was no place to enter a PIN. Going through Settings also gave me a broken UI. Something was clearly interfering, but everything looked correct on the surface. At this point, I had to move from surface-level configuration to what the system was actually doing.
3. Stripping Down Intune Policies… But Carefully
Whenever you suspect configuration issues, isolating the environment is key. I created a dedicated Entra group, added only my test VM, and excluded it from any potentially interfering policies.
In this case, a CIS Level 1 security baseline was assigned to the targeted Autopilot devices. While these baselines are valuable from a security perspective, they often tighten control over user experience features and could potentially also break stuff like setting up a PIN with WHfB.
I excluded the device from the CIS baseline entirely. No other configuration profiles seemed responsible. Still, no change. The PIN input remained missing.
4. Dsregcmd Was All Good
I ran dsregcmd /status and confirmed that everything looked healthy:
- IsDeviceJoined = YES
- NgcPrerequisiteCheck = willProvision
- PolicyEnabled = YES
- TPM present and functional
This meant that WHfB prerequisites were fulfilled, and according to the system, the provisioning workflow should be able to proceed. Yet the option to set up a PIN with WHfB didn’t show up.
5. Time to Launch Procmon
With the usual suspects (CIS) cleared, it was time to dive in a bit more. I opened Process Monitor (Procmon) and triggered the WHfB setup again, this time via the Settings > Set up a PIN option.
While watching Procmon in real-time, I filtered on CredentialUIBroker.exe, the process responsible for handling sign-in UI interactions.
I noticed that CredentialUIBroker.exe was querying the following registry path: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers.
It was iterating through the registered credential providers. One of them stood out: {D6886603-9D2F-4EB2-B667-1971041FA96B}. Under that key, there was a value called Disabled, which was set to 1. That caught my attention.
6. What That GUID Actually Is
That GUID corresponds to the Windows Hello PIN credential provider, the part of the system that renders and handles the PIN setup UI.
By setting Disabled = 1, Windows hides the provider from the system. It won’t show up as an available authentication method. There’s no visible error, just the absence of the option to set up a PIN. WHfB provisioning appears to run, but the user interaction needed to set up the PIN never starts.
This was the missing link. The environment wanted to provision WHfB, but the necessary UI component was blocked at a lower level.
7. So Where Did That Setting Come From?
I hadn’t applied this manually, and there was no longer a CIS baseline targeted, so I moved on to checking what was being executed by the Intune Management Extension.
I opened AgentExecutor.log from the IME logs and found that a PowerShell script had been executed on the device.
There it was…a PowerShell script that configured the {D6886603-9D2F-4EB2-B667-1971041FA96B} to be disabled.
After finding the PowerShell script ID, I opened the Intune portal and looked up the PowerShell script. The script was named HideOtherUser.ps1, which seemed completely unrelated.
But after using Microsoft Graph and decoding the base64 content, this is what it contained:
$registryPath = “HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers\{D6886603-9D2F-4EB2-B667-1971041FA96B}”
New-ItemProperty -Path $registryPath -Name “Disabled” -Value 1 -PropertyType DWord -Force
So, despite the name, the script wasn’t hiding the “Other user” login option; it was, in fact, disabling the PIN credential provider.
8. Silent Sabotage
This script had been silently deployed via Intune. It didn’t throw errors, alert the user, or get flagged by the WHfB setup process.
A simple registry value added by a misnamed script derailed the whole Windows Hello For Business (WHfB) experience. These kinds of configuration conflicts are the most difficult to detect because everything appears normal until you rule out everything else and end up with a PowerShell script.
9. The Set up A Pin not Showing Fix
I first tested a simple change by setting the Disabled value to 0: After closing the Set up A Pin screen and reopening it, the PIN setup screen worked perfectly. WHfB completed without issue.
Once verified, I updated the Intune script assignment to exclude this device and prevent reapplication. That ensured the fix would stick.
10. Final Thoughts
When troubleshooting issues like a missing PIN screen in Windows Hello for Business, start by ruling out what you can. Exclude the device from baselines. Strip away configuration profiles (don’t remove them… exclude your test device!). Confirm the obvious before diving deeper.
In this case, it wasn’t a settings catalog policy or a CIS baseline. It was a PowerShell script that silently disabled the PIN credential provider. Easy to miss unless you know where to look.
Always check what scripts are running on the device, review the logs, and use Procmon to see what the system is doing. Sometimes, it’s not a misconfiguration, it’s a PowerShell script breaking something you didn’t expect.