NgcSet Says YES and Windows Hello Still Does Not Work: Triaging One Device Properly

A user tells you Windows Hello stopped working. You remote onto the device, run dsregcmd /status, and read the line everyone reads: NgcSet : YES. Hello is provisioned. The device is joined. You close the ticket.

Three days later the same user raises the same ticket, because they are still typing a password every morning. NgcSet : YES was true the whole time. It was also irrelevant. That one line tells you a key was created at some point in the past. It does not tell you the key still exists on disk, that the service which signs with it is running, that the token it feeds is valid, or that the person has used it once this month. Those are five different components, and each one reports its health somewhere else.

The problem: the 60-second check that lies to you

Here is the output almost everyone stops at. On the face of it, this device is perfectly healthy. It is joined, Hello is provisioned, and the security chip is protecting the key.

+----------------------------------------------------------------------+
| Device State                                                         |
+----------------------------------------------------------------------+

             AzureAdJoined : YES
          EnterpriseJoined : NO
              DomainJoined : YES

+----------------------------------------------------------------------+
| User State                                                           |
+----------------------------------------------------------------------+

                    NgcSet : YES
                  NgcKeyId : {aaaaaaaa-0b0b-1c1c-2d2d-333333333333}
              WorkplaceJoined : NO
             WamDefaultSet : YES

Now here is the same device, read properly. Four of these values are the reason the user is still typing a password, and not one of them appears in the block above.

NgcSet                  : YES          <- the line that closed the ticket
NGC containers on disk  : 0            <- there is no key to sign with
KeySignTest             : FAILED       <- Windows own test of that key
AzureAdPrt              : NO           <- no single sign-on token
NgcSvc                  : Stopped      <- the service that runs Hello
Sign-ins, last 30 days  : Password 41, PIN 0, Fingerprint 0
Device certificate      : Expired 2026-09-30

This is not a contrived example. These states are routine, and they are independent of each other. A device can hold a perfectly valid Hello key and still have no token. It can have a healthy token and a cleared TPM. It can pass every structural check and have a user who has not touched the fingerprint reader since the day it was enrolled.

The three combinations that cause most repeat tickets:

• NgcSet : YES with zero NGC containers. The registry says Hello is set up for this user. The folder that holds the protected key is empty. Windows will offer the PIN prompt and then fail to sign with it. This is the state that most often follows a TPM clear or a firmware update.
• NgcSet : YES and a healthy key, but AzureAdPrt : NO. Hello itself is fine. The single sign-on token is gone, so every Microsoft app prompts for credentials all day. Users describe this as “Hello is broken” because the symptom they feel is constant prompting.
• Everything structurally green, and the sign-in history is 100% password. Nothing is broken. The user was never shown how to use the fingerprint reader, or it failed once and they gave up. No diagnostic script will ever flag this as a fault, and it is the single biggest gap between the adoption number on your dashboard and reality.

Why it happens: Hello is a chain, not a switch

Windows Hello for Business is often described as if it were a feature you turn on. It is closer to a chain of seven dependencies, and the user experience is determined by the weakest link. Break any one and the symptom is identical: a password prompt.

1. A cloud identity. The device must be registered with Entra ID. No registration, no Hello.
2. Policy. Something has to tell the device to offer Hello, via Intune or Group Policy.
3. A security chip. The TPM holds the private key. If it is not ready, Windows either refuses to create a key or creates a weaker software one.
4. The key itself. Created once per user per device, stored in the NGC container.
5. Services. NgcSvc runs Hello and KeyIso isolates the keys. Both must be running at the moment of sign-in.
6. A token. The Primary Refresh Token is what turns a successful Hello gesture into silent access to Microsoft 365.
7. A human. Someone has to choose the fingerprint reader over the password box.

Each of those links reports its health through a different component, which is why no single command covers them. Worse, two of them report differently depending on who is asking.

Registry values worth knowing

Three of the seven links are registry-backed. These are the keys the collector reads, and what each value means when it is wrong. The shared parent key is stated once here rather than repeated in every row:

The event IDs that actually tell you something

Three logs carry Hello signals. The collector counts errors in all three, but these are the individual IDs worth opening by hand. The log channel is stated once above the table:

If you want the full decode of Event 360 and every prerequisite it reports, that is covered separately in Event ID 360: every prerequisite that blocks WHfB provisioning.

How to verify: three lines, and the context trap

Before installing anything, you can settle most tickets with one command, provided you run it in the right context. Run this as the signed-in user, not as an administrator and not as SYSTEM. An elevated PowerShell runs under a different token, and the User State block will not be the user's.

# Hello key, single sign-on token, and Windows own test that the key can sign
dsregcmd /status | Select-String 'NgcSet|AzureAdPrt\s|KeySignTest'

# Does a key actually exist on disk? Needs an elevated shell to read the folder.
$ngc = Join-Path $env:SystemRoot 'ServiceProfiles\LocalService\AppData\Local\Microsoft\Ngc'
(Get-ChildItem $ngc -ErrorAction SilentlyContinue | Measure-Object).Count

# Are the two services Hello cannot work without actually running?
Get-Service NgcSvc, KeyIso | Format-Table Name, Status, StartType -AutoSize

Read the result like this. NgcSet : YES with a container count of 0 is the broken state described above. KeySignTest : FAILED means stop looking anywhere else, because the key is unusable. AzureAdPrt : NO points at the token, not at Hello.

The fix: a read-only collector and an offline viewer

Three commands is fine for one device. It stops being fine when you are on a call, the user is waiting, and you need the TPM state, the certificate expiry, the policy values, the service states, the error counts and the sign-in history as well. So the three commands became a script.

Get-WHFBDeviceReport.ps1 reads all eight surfaces in one pass, scores a verdict, prints a console summary, and writes a JSON file. It is strictly read-only: it reads the registry, certificates, services, event logs, dsregcmd, Get-Tpm and auditpol, and the only thing it writes is the report itself. It changes nothing on the device, nothing in Intune and nothing in Entra ID, and it uploads nothing anywhere.

Running it

Open an elevated PowerShell on the device you are troubleshooting and run the script. Without elevation it still runs, but the Security log, the TPM and the audit policy cannot be read; rather than guessing, the report lists them under “Could not be read” so you know exactly which parts are missing.

# Default run: 30 days of sign-in history, report written beside the script
.\Get-WHFBDeviceReport.ps1

# Shorter window, and a specific output path
.\Get-WHFBDeviceReport.ps1 -Days 7 -JsonPath C:\Temp\device.json

# Masks user names, device ID, Hello key ID and certificate thumbprints.
# Use this before attaching a report to a support case or a forum post.
.\Get-WHFBDeviceReport.ps1 -Anonymise

Reading the result

The JSON is readable on its own, but nobody wants to read JSON on a call. whfb-report-viewer.html ships beside the script: a single file with no libraries, no tracking and no network calls. Download it, open it from your own disk, and load the report. Every technical name is explained underneath it in plain English, and each value carries OK, Check or Problem as a word as well as a colour, so it reads correctly for colour-blind users and in print.

Because the parsing happens entirely in your browser, the file you open never leaves the machine. That is also why it works on an isolated device with no internet connection, which is frequently exactly where you need it.

Deploy this as an Intune Proactive Remediation

One device at a time is the right tool for a ticket. For the fleet, the same checks ship as a detection and remediation pair. The detection script runs the identical blocking checks in the identical order, so a device flagged by the fleet shows the same reason in its full report.

1. Sign in to the Intune admin center.
2. Go to Devices › Scripts and remediations › Remediations.
3. Select Create and name it, for example “Windows Hello for Business — detect and repair”.
4. On the Settings page, upload Detect-WHFBDeviceHealth.ps1 as the detection script.
5. Upload Remediate-WHFBDeviceHealth.ps1 as the remediation script.
6. Set Run this script using the logged-on credentials to No, and Run script in 64-bit PowerShell to Yes.
7. Select Next, assign to a pilot group first, and set the schedule to Daily.
8. Select Next › Create, then read the output column before you widen the assignment.

Read the remediation script before you deploy it, because the half that refuses to act is the important half. It will start a stopped NgcSvc or KeyIso, and it will trigger the device registration task and an MDM sync when the token or the certificate needs renewing. Those are safe, reversible and need nobody present.

It deliberately refuses four things:

• Re-enrolling Hello when NgcSet is NO or the container is missing. The repair deletes the user's PIN and biometrics and needs them sitting at the device. Done silently at fleet scale by a scheduled task, it is indistinguishable from an attack.
• Clearing a TPM that is not ready. That destroys every key on the device, BitLocker protectors included.
• Re-joining a device that is not registered. That is an enrolment decision, not a repair.
• Writing Enabled = 1 when policy set it to 0. The next sync reverts it and the real policy problem is now hidden behind a script that appears to have fixed something.

In each case it logs the reason and exits non-zero, so the device stays visible in the Intune output column instead of quietly disappearing from your problem list.

Setting the policy properly, in both worlds

If the collector reports that policy is absent or disabling Hello, fix it at the source. Both deployment paths are below, because plenty of estates still run a mix.

The last two matter more than they look. If sign-in auditing is off, the Security log has no anchors, the sign-in history in every report is empty, and the adoption figure on your dashboard is measuring nothing. The collector reports this explicitly rather than showing you a confident zero.

Proof it worked: what a clean device looks like

Here is the console summary from a healthy device. The verdict line is the headline, and the four lines underneath are the ones you quote back to the user.

WHfB device report - LAP-DEMO-01
----------------------------------------------------------
HEALTHY - Windows Hello for Business looks correctly set up

  Join        : Hybrid joined / Cloud Kerberos trust
  NgcSet      : YES      NGC containers: 1
  AzureAdPrt  : YES      TPM ready     : True
  Sign-ins    : 112 anchor events for 1 user(s)

Report written: .\WHFB-Device-LAP-DEMO-01-20261012-0930.json
Open whfb-report-viewer.html and load that file to read it.

And here is the same script on the device from the top of this post. Note that it separates blockers from notes: the password habit is reported, but it does not turn the verdict red, because nothing on the device is broken.

WHfB device report - LAP-DEMO-02
----------------------------------------------------------
NEEDS ATTENTION - 4 blocking issue(s) found
  [blocker] Device registration certificate has expired
  [blocker] NgcSet says YES but there is no NGC container on disk
  [blocker] No single sign-on token (AzureAdPrt is not YES)
  [blocker] A service Windows Hello depends on is stopped
  [note]    Windows Hello is set up but a password was still the most used sign-in method
  [note]    Sign-in auditing is incomplete, so the usage figures above under-report

  Join        : Hybrid joined / Key or certificate trust
  NgcSet      : YES      NGC containers: 0
  AzureAdPrt  : NO       TPM ready     : True
  Sign-ins    : 41 anchor events for 1 user(s)

Four blockers, in priority order, from a check that took under a minute. The expired certificate is the root cause: once registration lapsed, the token could not renew, and the Hello container was never rebuilt. Renew the registration and three of the four resolve together.

In the viewer, the same report renders as a verdict panel followed by one card per surface, each value carrying its own plain-English explanation. A simulated extract:

The pattern worth taking away is not the script. It is the habit: when a user says Hello is broken, establish which of the seven links failed before you touch anything. Most of the time the answer is not the one the first command gives you.

References

• Windows Hello for Business documentation — Microsoft Learn
• Windows Hello for Business cloud Kerberos trust deployment guide — Microsoft Learn
• Troubleshoot devices by using the dsregcmd command — Microsoft Learn, the authoritative field reference for every value in this post
• What is a Primary Refresh Token? — Microsoft Learn
• Remediations in Microsoft Intune — Microsoft Learn
• PassportForWork CSP reference — Microsoft Learn