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, why Microsoft's own current documentation says the "container" is not even a real folder at the architecture level, and shows you the registry keys, Event IDs, and supported reset path to use instead - plus a Proactive Remediation pair so you never have to touch a device by hand.
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. Do not just check the one setting or the one event you already suspect - the table below is every PassportForWork policy value that actually governs whether provisioning happens and whether PIN recovery is even possible, and the Event ID catalog after it is every provisioning event you will see in the User Device Registration log, not just the error.
Registry key reference - the policy values that actually control provisioning
These are not the NGC container's internal storage (per Microsoft's note above, that is not a real registry location) - they are the PassportForWork MDM policy values, delivered by Intune via the PassportForWork CSP, that determine whether Hello provisions at all and whether a broken PIN can be recovered without a destructive reset. All four live under the same parent key, so it is stated once here rather than in every row:
| Value name (REG_DWORD) | Healthy value | If wrong |
|---|---|---|
UsePassportForWork | 1 or absent | 0 = WHfB never provisions on this device |
EnablePinRecovery | 1 | 0/absent (default) = a broken PIN can only be deleted and recreated |
RequireSecurityDevice | 1 if hardware required | 0 = software-key fallback allowed |
DisablePostLogonProvisioning | 0 (default) | 1 = looks identical to "Hello never set up" |
EnablePinRecovery defaults to disabled. Most tenants never turn it on, which means the very first time a user's PIN genuinely breaks, the only supported path is delete-and-recreate (via certutil, never the folder) - there is no "recover the old PIN" option waiting in reserve. If you want a non-destructive recovery option available before you need it, this is the setting to enable now, not after the first support ticket.Event ID catalog - the provisioning story in User Device Registration
All of these live in the same channel, so it is stated once here rather than in every row - this is the log that explains why provisioning did or did not happen, including the specific "NGC key is missing" event that maps directly to a broken credential:
| Event ID | Level | Meaning |
|---|---|---|
| 358 | Information | Provisioning will be launched - prerequisites passed |
| 360 | Warning | Provisioning blocked - a prerequisite failed (easy to miss, not an Error) |
| 362 | Error | Device authentication to the enterprise STS did not succeed |
| 363 | Error | The Microsoft Passport (NGC) key is missing |
Read that sequence the way the site's Event ID catalog post teaches: the 363 at 08:41:07 is the actual finding - the key genuinely does not exist - and the 360 Warning right after it is the consequence, not a separate problem. The second 358 at 08:44:12 is what you want to see after running the supported reset below: a clean retry.
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:
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.Deploy this as an Intune Proactive Remediation
Rather than wait for a helpdesk ticket and then run certutil by hand, deploy the detect/remediate pair below fleet-wide. It performs exactly the two checks and the one supported fix already covered above - nothing else - and it runs in the signed-in user's context, so certutil -deletehellocontainer targets the right container automatically.
- Sign in to the Intune admin center.
- Go to Devices › Scripts and remediations › Proactive remediations.
- Select Create and name it "WHfB NGC Container - Detect and Remediate".
- On the Settings page, paste
Detect-NgcContainerHealth.ps1into Detection script file. - Paste
Remediate-NgcContainerHealth.ps1into Remediation script file. - Set Run this script using the logged-on credentials to Yes - this is required, not optional, for
certutil -deletehellocontainerto target the right user. - Select Next, then assign to a pilot device group first under Assignments.
- Set the schedule to Daily and select Next › Create.
certutil -deletehellocontainer call needs to run as the affected user - as SYSTEM it deletes a different (system) container and the user's broken credential is untouched, so the ticket reopens with no visible cause.Proof it worked
Here is a real run of Get-NgcContainerInfo.ps1 from this series, against a healthy device (device key IDs shown are replaced below to avoid publishing a real Entra device identifier):
Both services Running, a populated container, and a matching NgcKeyId are exactly the "nothing to fix here" result - the moment to reach for certutil -deletehellocontainer is when one of those lines reads differently (a stopped service, or NgcSet : NO when the user insists they set up a PIN).
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.
The Proactive Remediation's detection script gives the same answer in the format Intune actually consumes. This is a real run on a healthy device:
On a device where Event 363 has actually fired and the credential is genuinely missing, the same script instead prints NOT HEALTHY: dsregcmd reports NgcSet: NO (no Hello credential provisioned) and exits 1 - which is Intune's signal to run Remediate-NgcContainerHealth.ps1 automatically, in the user's own session, with no ticket and no admin touching the device.
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
- PassportForWork CSP reference (UsePassportForWork, EnablePinRecovery, RequireSecurityDevice, DisablePostLogonProvisioning)
Script for this post is in Daily-Tasks.