Search any forum for "Windows Hello broken" and within three replies someone says: "just delete the Ngc folder and reboot." It is the WHfB equivalent of "have you tried turning it off and on again" - and it is one of the most destructive pieces of advice on the internet. This post opens up the NGC container, explains what actually lives in it, and shows you why the folder-delete trick is dangerous, what it really does, and the supported way to reset a broken Hello credential instead.
The problem: a folder everyone deletes and nobody understands
When Windows Hello for Business (WHfB) provisions, the user's private key does not sit in a normal file you can copy. It lives inside a protected store Microsoft calls the NGC container (NGC stands for Next Generation Credentials, the internal name for Hello). On disk that store is here:
Inside are per-credential subfolders full of opaque binary blobs: references to the protector keys, the PIN reset protector, and metadata that ties the container to the user and (where a Trusted Platform Module is present) to the TPM. You cannot read the actual private key from these files - that is the point. The key material is sealed by the TPM or by DPAPI, and the folder is Access Control List (ACL) protected so ordinary processes cannot even open it.
Two Windows services own this container and must be running for Hello to work at all:
| Service | Display name | Job |
|---|---|---|
NgcSvc | Microsoft Passport | Manages the WHfB credential and key operations |
NgcCtnrSvc | Microsoft Passport Container | Manages the container that stores the keys |
dsregcmd fields (NgcSet, NgcKeyId) still carry the original NGC/Passport branding. When you see any of them, you are looking at the same credential.Why it happens: why "just delete the Ngc folder" is dangerous
The folder-delete advice comes from a real behaviour: if you take ownership of the Ngc folder, wipe its contents, and reboot, Windows rebuilds an empty container and re-provisions Hello. Sometimes that clears a corrupted credential. But look at what you actually did:
- You destroyed the credential for every user profile on that device at once, not just the broken one.
- You left the corresponding public keys orphaned in Microsoft Entra ID and in each user's
msDS-KeyCredentialLinkattribute - keys that now point at a private key that no longer exists. - You changed NTFS ownership on a system-protected folder, which can leave the ACLs wrong so the container cannot re-protect itself correctly.
- On a TPM-backed device you may have desynchronised the on-disk container from the TPM-sealed material, producing a new class of failure that is harder to diagnose than the one you started with.
How to verify what state the container is really in
Before touching anything, read the state. dsregcmd /status tells you whether a Hello credential exists for the signed-in user and its key ID - this is your "is the container populated?" check:
Then confirm the two container services are actually running. If either is stopped or disabled, Hello fails and the fix is to start the service, not to delete anything:
The fix: reset the credential the supported way
If a single user's Hello credential is genuinely broken, you do not delete the folder. You delete that user's Hello container with the built-in tool, run in the user's own context (not elevated):
This removes only the signed-in user's credential, cleanly, through the supported code path - it lets Windows tidy up the container and re-provision on next sign-in. Compare that with the folder-delete sledgehammer, which hits every user and leaves debris:
| certutil -deletehellocontainer | Deleting the Ngc folder | |
|---|---|---|
| Scope | The one signed-in user | Every user profile on the device |
| Supported | Yes | No |
| Cleans up keys | Yes - through the proper path | No - leaves orphaned keys in Entra ID / AD |
| Touches NTFS ACLs | No | Yes - and often wrongly |
| Run as | The user (not elevated) | Requires taking ownership as admin |
certutil -deletehellocontainer from an elevated prompt and it deletes the administrator's container, not the signed-in user's - so nothing appears to happen for the user who has the problem. Always run it in the affected user's own session. To do it at scale, push it as a user-context script, never as SYSTEM.Proof it worked
After a supported reset and re-provision, NgcSet returns to YES with a new NgcKeyId, both container services are Running, and the user signs in with their new PIN. On the directory side, the old public key ages out and the new one is registered - no orphans, because you never bypassed the cleanup path.
Get-Tpm - is it present and ready?) and the two NGC services. A cleared or malfunctioning TPM, or a stopped Passport Container service, breaks Hello for everyone and is fixed without deleting a single file. The folder is almost never the real problem.References
- How Windows Hello for Business works
- WHfB deployment guide (container reset via certutil -deletehellocontainer)
- Troubleshoot devices by using the dsregcmd command (NgcSet / NgcKeyId)
- Windows Hello for Business frequently asked questions
Script for this post is in Daily-Tasks.