AADSTS130004: the Hello key works on the laptop but is missing in Entra ID

The laptop has a Windows Hello for Business key, and the key works. Microsoft Entra ID no longer has that key registered for the user. Hello sign-in fails, and the usual device health checks all pass.

I call this the orphaned Hello key. The private key is still on the laptop. The public half that Entra ID checks it against is gone. Windows doesn't treat that as a fault, and neither does any health report that only collects device state.

The problem: a healthy laptop that Entra ID refuses

On one enterprise laptop, the user reported that Hello sign-in failed with a "credentials could not be verified" message. That message has more than one cause, and this companion post shows how to tell them apart. This post covers the cause that never goes away on its own.

Every device check passed. The answer was one block of dsregcmd /status, run in the user's own session. This is the shape of it, with placeholder values:

Illustrative. Field names follow Microsoft's dsregcmd article. Values are invented. The server message is the text the laptop I examined returned. Microsoft's error reference words it slightly differently.

• NgcSet : YES. Microsoft defines it as a Windows Hello key being set "for the current logged-in user". That is a fact about this laptop, not about Entra.
• Credential Type : NGC. Microsoft lists the common values as "Password and Next Generation Credential (NGC) (for Windows Hello)". The failed attempt used Hello.
• AADSTS130004. Microsoft's reference: "NgcKeyNotFound - The user principal doesn't have the NGC ID key configured."
• Attempt Status : 0xc00000d0. This is "The client error code that's returned (HRESULT)." Microsoft's NTSTATUS reference names it STATUS_REQUEST_NOT_ACCEPTED, with a generic description about connection limits that doesn't fit here. Don't chase it. The server error is the useful part.

A second read confirms the key really is on the laptop. certutil -key lists keys, -user switches to the user's keys, and Microsoft maps the provider name NGC to the "Microsoft Passport Key Storage Provider".

Good means at least one key is listed. No key at all is a different fault, covered in the NGC container explained. Here the key is present, and Entra still refuses it.

Why your dashboards say this device is fine

A report built from device checks will say "Hello is set up, nothing to do" for a user who cannot sign in with Hello. To ask Entra directly, see check Hello keys in Entra with Microsoft Graph.

Why it happens: Entra checks a key it no longer has

A Hello sign-in doesn't send a secret. It proves the laptop holds the private key. In Microsoft's description of the Entra join flow, the Cloud Authentication provider (CloudAP) gets a nonce from Entra and "signs the nonce using the user's private key". Then "Microsoft Entra ID validates the signed nonce using the user's securely registered public key against the nonce signature."

That step needs the public key registered at enrolment. If the registration is deleted in Entra, the laptop still signs correctly. Entra has nothing to check the signature against, so it returns AADSTS130004.

Why the failure arrives days later

Removing the key in Entra doesn't break the laptop straight away. Microsoft's PRT article explains why a delay is possible. CloudAP "caches the PRT to enable cached sign in". A PRT "is valid for 90 days and is continuously renewed as long as the user actively uses the device." And "Windows initiates cached sign in and validates credentials to log the user in. Every 4 hours, the CloudAP plugin initiates PRT renewal asynchronously."

So the unlock is local, and renewal runs in the background. A renewal can fail without the user seeing anything.

On the laptop I examined, PRT updates kept succeeding for several days after the key had gone. The first failure lined up with an AAD Operational event (ID 1280 on that device) saying the PRT session key needed to be rolled because of its age. Every Hello PRT attempt after that failed with AADSTS130004. Microsoft doesn't document that event, so treat it as one device's evidence, not a rule. Microsoft does mention the roll in passing: MFA "might be required after session key associated with PRT is rolled".

Password sign-in usually still works, which confuses people further. Microsoft says "Windows 10 or newer maintain a partitioned list of PRTs for each credential. So, there's a PRT for each of Windows Hello for Business, password, or smart card." The password PRT doesn't depend on the Hello key.

Why it never heals itself

NgcSet stays YES, because the key is still on the device. Windows has no reason to enrol again.

On the laptop I examined, the User Device Registration admin log showed event 358, saying Hello provisioning will be launched, many times a day. No enrolment ever completed. Microsoft's deployment issues article says "The provisioning experience for Windows Hello for Business launches if the prerequisite checks are successful", and shows the blocked counterpart, event 362, as "Windows Hello for Business provisioning will not be launched." So the repeated 358 only showed that the prerequisite checks kept passing. No new key was registered.

Retrying the PRT doesn't help. It sends the same key to the same Entra that just refused it.

How to verify: one block on the laptop, the cause in Entra

The laptop tells you what is wrong in a minute. Only Entra can tell you why, and it only keeps that evidence for a limited time.

Check 1: dsregcmd as the user

Open a normal Command Prompt in the user's session. Don't use "Run as administrator". Microsoft says "The command must run in a user context to retrieve a valid status." It also warns that WamDefaultSet "could display an error if" the command "is run from an elevated command prompt."

Look under SSO State for AcquirePrtDiagnostics or RefreshPrtDiagnostics. Microsoft says this information is "displayed only if the acquisition or refresh failure happened after the last successful PRT update time". If the block is there, the latest attempt failed.

Two traps. The Acquire and Refresh blocks use the same field names, so note which block a line sits in. And Microsoft warns that on a shared device the diagnostics "could be from a different user's login attempt". Check User Identity first.

Check 2: find every affected user in the sign-in log

Now leave the laptop. Background PRT renewals land in the non-interactive log. Microsoft describes those sign-ins as "performed by a client app or OS components on behalf of a user" that "don't require the user to provide an authentication factor".

1. Sign in as at least Reports Reader. Microsoft says that role "is the least privileged role required to access the activity logs".
2. Open the Non-interactive user sign-ins tab and widen the time range past the first ticket.
3. Add filters. Microsoft's steps: "Select the Add filters button, choose a filter option, and select Apply." Set Status to Failure.
4. Narrow to 130004. Microsoft's filter page says "Not all filter options are described", and the error code filter is one it leaves out. On the tenant where I worked this case, the filter list offered the sign-in error code, and 130004 gave every affected user in a couple of minutes. If yours doesn't, open the failed rows: Microsoft's troubleshooting guide lists "Sign-in error code" among the details each one shows.

Good is no rows. Bad is a list of users who started failing within days of each other. That cluster points to one cause. To match a single laptop instead, filter on the Correlation ID from dsregcmd. Microsoft defines it as a "Unique identifier for all sign-in requests that are part of a single sign-in attempt".

Check 3: find the cause in the audit log

Take one affected user. Note the last successful PRT update and the first 130004. The removal happened before the first failure, maybe days before.

Open Entra ID › Monitoring & health › Audit logs. Set Target to the user (Microsoft notes "The target name and UPN are case-sensitive."). For Date range, Microsoft says "You can search the last 7 days, 24 hours, or a custom range." Use a custom range that starts well before the first failure. Look for these activities from Microsoft's audit activity reference:

Then read Initiated by. Microsoft describes that filter as a way to "search by who initiated the activity". Finding that person or process is the real fix. Repair only laptops, and the same process orphans the next batch of keys.

"Require re-register MFA" often gets the blame, so check what it does. It sits under Entra ID › Users › (user) › Authentication methods. Microsoft says it "deactivates the user's hardware OATH tokens and deletes the following authentication methods from this user: phone numbers, Microsoft Authenticator apps and software OATH tokens." Windows Hello for Business isn't in that list. If you find the re-register action but no Hello credential deletion, don't assume it was the cause. Raise it with Microsoft. It still matters for the fix: a user whose phone methods were removed may not be able to pass MFA to re-enrol.

Don't wait. Microsoft's retention table:

With a delayed failure, the cause can be a week or two old before the first ticket. To keep logs longer, Microsoft says to route them "to an Azure storage account using Azure Monitor".

The fix: delete the container and re-enrol

The laptop holds a key that Entra no longer recognises. The fix that works is a new key: remove the old container and enrol again.

Before you start

• The code is 130004. Not 130005 to 130008, and not a network fault. Anything else, stop.
• The user can pass MFA. Microsoft says Hello "itself requires MFA to provision". If their phone methods are gone, issue a Temporary Access Pass first. See TAP for Hello recovery.
• The user knows their password. They need it after the delete.
• The Hello policy still applies. In Group Policy: Computer Configuration\Administrative Templates\Windows Components\Windows Hello for Business › Use Windows Hello for Business (a User Configuration version also exists). The CSP node is ./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/UsePassportForWork, set in an Intune settings catalog profile as Use Windows Hello For Business. If dsregcmd shows the Ngc Prerequisite Check section, PolicyEnabled : YES confirms it.

Steps

1. Remove face and fingerprint. In Settings › Accounts › Sign-in options, remove Facial recognition, then Fingerprint. On the laptop I examined, Windows wouldn't remove the PIN while a biometric was enrolled, so clear them first.
2. Delete the container as the user. In the user's own session, open a normal Command Prompt. Don't elevate it. Run the command below. Microsoft says "Users need to sign out after using this option for it to complete."
3. Sign out, then restart for a clean session.
4. Sign in with the password. Its PRT is separate from the Hello one.
5. Confirm the old key is gone. Run dsregcmd /status as the user. You want NgcSet : NO before you re-enrol.
6. Re-enrol. Microsoft says provisioning "begins immediately after the user profile is loaded and before the user receives their desktop", and "all prerequisite checks must pass." The user completes MFA and sets a PIN. Then "Windows communicates with the IdP to register the public key." That registration is what Entra was missing.

The NgcSet : NO line is illustrative of a good result. If it still says YES, the delete didn't complete. Check the user signed out, and don't re-enrol yet.

A PIN reset is not the same thing. Destructive and non-destructive PIN reset explains what each kind keeps. Here, anything that keeps the old key keeps the fault.

Proof it worked: a new key ID and a clean PRT

Have the user lock and unlock with the new PIN, then sign out and back in with it. Run the checks again, as the user.

1. NgcKeyId has changed. Microsoft defines it as "The ID of the Windows Hello key if one is set for the current logged-in user." The same ID as before means the old key is still in use.
2. AzureAdPrtUpdateTime is after the fix, with no PRT diagnostics block.
3. The audit log shows Add Windows Hello for Business credential for the user at re-enrolment time.
4. The non-interactive sign-in log stops showing 130004 for this user. Check again the next day.

Then work through the users from check 2, and take the audit entry from check 3 to whoever owns the process that removed the keys.

References

• Microsoft Entra authentication and authorization error codes - AADSTS130004 and its 1300xx neighbours.
• Troubleshoot devices by using the dsregcmd command - NgcSet, NgcKeyId, PRT diagnostics, user context.
• Understanding Primary Refresh Token (PRT) - lifetime, renewal, cached sign-in, per-credential PRTs.
• How Windows Hello for Business authentication works - the signed nonce and the registered public key.
• certutil - -key, -csp and -DeleteHelloContainer.
• Customize and filter activity logs - sign-in log tabs and filters, audit log target and date range.
• How to troubleshoot sign-in errors - the Failure status filter and the sign-in error code in each row.
• Non-interactive sign-in logs - what counts as non-interactive.
• Microsoft Entra audit log activity reference - the Hello credential and security info activities.
• Manage authentication methods for Microsoft Entra MFA - what "Require re-register MFA" deletes.
• Microsoft Entra data retention - log retention by licence.
• Configure and enroll in Windows Hello for Business in a hybrid key trust model - policy paths, provisioning, the 30-minute sync.
• Windows Hello for Business known deployment issues - prerequisite checks and event 362.
• MS-ERREF: NTSTATUS values - the name of 0xC00000D0.
• Configure Windows Hello - Microsoft Support. Where Sign-in options lives in Settings.

Related reading on EndpointWeekly

• "Credentials could not be verified": two causes
• Check Hello keys in Entra with Microsoft Graph
• dsregcmd /status reference
• Primary Refresh Token deep dive
• The NGC container explained
• Destructive and non-destructive PIN reset
• Temporary Access Pass for Hello recovery

The pattern was diagnosed on one enterprise laptop in October 2026. All output blocks are illustrative, with invented values. Microsoft facts were checked against the pages above on 31 October 2026.