A user types their Windows Hello for Business PIN and Windows answers: "Your credentials could not be verified". I have seen that one message come from two faults that have nothing to do with each other. One fixes itself in 15 seconds. The other never fixes itself.
Both look identical to the user and to the service desk. Pick the wrong cause and you either rebuild a Hello container that was fine, or keep retrying a refresh that can never work. This post shows how to tell them apart with read-only checks, before you fix anything.
Run dsregcmd /status as the affected user, not elevated and not as SYSTEM, and read the Primary Refresh Token (PRT) diagnostics block. No server answer (HTTP status 0, a transport error such as 0x80072ee7) means the network was not ready. Retry, and it works. HTTP status : 400 with AADSTS130004 means Microsoft Entra ID received the request and says the user has no Hello key registered. That never heals on its own, and an automatic dsregcmd /refreshprt cannot fix it.
The problem: one message, two unrelated faults
Microsoft documents the message. Its support article (original KB number 4519735) says that a sign-in "by using a WHFB certificate or key trust" can fail with "Your credentials could not be verified".
I met this message on two enterprise laptops in a large estate. The user reports were word for word the same. The causes were not:
| Cause A: network not ready at sign-in | Cause B: Hello key missing in Entra | |
|---|---|---|
| What the user sees | "Your credentials could not be verified" | "Your credentials could not be verified" |
| Retry 10 to 15 seconds later | Works | Fails again, every time |
| Signature | A Winlogon result of 1326 close to NetworkProfile events 10000 / 10001 | HTTP status : 400 and AADSTS130004 in the PRT diagnostics |
| Who owns the fix | Nobody, or whoever owns network start-up on the device | Identity: the user's Hello key must be registered again |
Why it happens: a network race, or a key Entra no longer has
A Hello sign-in is not a local password check. Microsoft's page on Hello authentication describes the Entra joined flow. Windows asks Entra for a nonce, signs it with the user's private key, and sends it back. Then "Microsoft Entra ID validates the signed nonce using the user's securely registered public key against the nonce signature", and returns a PRT.
Two things must be true for that to work. The device must reach Entra at that moment. And Entra must still hold the public half of the user's Hello key. Cause A breaks the first. Cause B breaks the second.
One caveat on join type. Microsoft says hybrid joined devices "authenticate to Active Directory during sign-in, and authenticate to Microsoft Entra ID in the background". With hybrid key or certificate trust, I would expect cause B to show as broken single sign-on rather than a failed sign-in screen. Both laptops here failed at the sign-in screen.
Cause A: the request never reached Entra
On the laptop I examined, the Winlogon log recorded the failed attempt with a result of 1326. In the same few seconds, the NetworkProfile log recorded events 10000 and 10001: the connection was still changing state. The user tried again 10 to 15 seconds later and was signed in.
Do not trust the code alone. Microsoft's system error code list names 1326 ERROR_LOGON_FAILURE: "The user name or password is incorrect." The PIN was correct. The code says the sign-in failed, not why.
This cause heals because Windows tries again. Microsoft's PRT page says CloudAP renews the PRT every 4 hours, and: "If the user doesn't have internet connection during that time, CloudAP plugin will renew the PRT after the device is connected to the internet and a new Windows sign in is done."
Cause B: Entra received the request and said no
On the second laptop, every device check passed. The answer was one line in dsregcmd /status: AADSTS130004. Microsoft's Entra error code reference defines it as "NgcKeyNotFound - The user principal doesn't have the NGC ID key configured." Microsoft's dsregcmd page expands NGC as "Next Generation Credential (NGC) (for Windows Hello)". So this is the Hello key.
In plain words: the private key is on the laptop, but the matching public key is no longer registered against the user in Entra. Entra has nothing to check the signature against, so it refuses.
The failure is delayed. Nothing happens on the device when the key is removed in the cloud. On that laptop, the first failure came days later, at a PRT renewal. That is why these tickets arrive spread out and look unrelated.
It also never clears by itself. Microsoft says NgcSet is YES "if a Windows Hello key is set for the current logged-in user". That is a local fact. The device has the key, so Windows sees no reason to set one up again. On that laptop nothing changed until someone stepped in.
dsregcmd /refreshprt automatically when sign-in fails. Microsoft says the command schedules a refresh and prints PRT refresh scheduled. Check AAD event logs for details. It prints that whether the refresh later works or not. On cause A the refresh was not needed. On cause B it goes back to Entra and gets AADSTS130004 again. The remediation "succeeds", the device is flagged again, and the loop repeats.How to verify: three read-only checks, in order
None of these checks changes anything on the device or in the tenant. Do them before any fix, because the fix for one cause is wrong for the other.
Check 1: read the PRT diagnostics as the user
This is the check that separates the two causes. Microsoft's dsregcmd page says of the SSO state section: "The command must run in a user context to retrieve that user's valid status." An elevated window or a SYSTEM capture shows the wrong view.
Have the user open a normal PowerShell window, not "Run as administrator". The first command confirms who is running it. The second prints only the lines you need:
Microsoft documents each field:
| Field | Microsoft's description | What to look for |
|---|---|---|
Previous Prt Attempt | "The local time, in UTC, at which the failed PRT attempt occurred." | Close to when the user saw the message. |
Attempt Status | "The client error code that's returned (HRESULT)." | Note it, but don't stop here. |
Credential Type | Password, or NGC "(for Windows Hello)". | NGC means the Hello key was used. |
HTTP Error | "WinHttp transport error code." | Not 0x0 means the transport failed. |
HTTP status | "The HTTP status returned by the endpoint." | 400 means Entra answered. |
Server Error Description | "The error message from the server." | An AADSTS code means Entra answered. |
This is the shape of cause A: a transport error and no server fields at all.
Each code decodes on a Microsoft page:
0x80072ee7is a Win32 error inside an HRESULT. Facility 7,FACILITY_WIN32, "is reserved to map undecorated error codes into HRESULTs". The low part,0x2EE7, is 12007:ERROR_WINHTTP_NAME_NOT_RESOLVED, "The server name cannot be resolved."0xc000023cis the NTSTATUSSTATUS_NETWORK_UNREACHABLE: "The remote network is not reachable by the transport."HTTP status : 0is my observation, not a Microsoft definition. No server replied, so there was no status to record.
This is the shape of cause B. The identifiers are illustrative; the description line is the text the laptop showed.
The rule that comes out of these two blocks:
| You see | It means | Cause |
|---|---|---|
HTTP status : 0, HTTP Error not 0x0 (for example 0x80072ee7), or 0xc000023c, and no server message | The request did not reach Entra, or no reply came back | A: network or proxy |
HTTP status : 400, an AADSTS code, a correlation ID | Entra received the request and answered | A server decision. AADSTS130004 is cause B. |
No diagnostics block, AzureAdPrt : YES | No PRT failure since the last success | Neither, right now. Cause A may have healed. |
The second row settles arguments with a network or proxy team. Microsoft's error reference describes trace_id and correlation_id as unique identifiers "for the request that can help in diagnostics". Entra issues those and the AADSTS number. A proxy that blocked the request cannot. A numbered AADSTS error proves the request got through.
Attempt Status was 0xc00000d0. MS-ERREF names it STATUS_REQUEST_NOT_ACCEPTED and describes a computer that has reached its maximum number of connections. That has nothing to do with a missing Hello key. When a Server Error Description is present, it is the answer.dsregcmd. Cause B keeps the block, because no success follows. Microsoft also warns: "On a shared device, this diagnostics information could be from a different user's login attempt." Check User Identity.Check 2: line up the events around the failure
Use this when Check 1 shows no diagnostics block, or a transport error. It reads every event from three logs in a four-minute window around the failure.
On the cause A laptop, the result had this shape (illustrative times, message text trimmed):
The NetworkProfile events bracket the failed attempt. The retry, once the network had settled, worked. I could not find a Microsoft page that documents these Winlogon and NetworkProfile event IDs, so read each event's full message on your own device. Treat the IDs as what one laptop showed, not as a rule.
For cause B this timeline adds little: the failure repeats whatever the network does. The WHfB event ID catalog covers the Hello and AAD events in these logs.
Check 3 (cause B only): find the same request in Entra
The correlation ID from Check 1 finds the rejected request on the Entra side. Microsoft's filter table calls it a "Unique identifier for all sign-in requests that are part of a single sign-in attempt". You need at least Reports Reader. In the tenant I worked in, the rejections were in the non-interactive tab. Microsoft describes those as sign-ins that "don't require any interaction or authentication factor from the user". If that tab is empty, check the interactive tab too.
Correlation ID from dsregcmd /statusPrevious Prt Attempt timeA matching failure row proves cause B from the cloud side. Finding out why the key disappeared is a separate job, in the audit logs. The companion post covers it.
The fix: different for each cause, and fix the automation too
Cause A: nothing on the device needs repairing
The Hello key and the device registration are fine. The PRT renews once the network is back and the user signs in again. So:
- Ask the user to try again once the network icon shows a connection.
- If you want a fresh PRT at once, have the user run
dsregcmd /refreshprtin their own session after the network is up. Microsoft's procedure says to "Wait one to two minutes for the token refresh to occur." - If it happens every morning on the same device, the question is why the network is late at sign-in. Bring the Check 2 timeline to whoever owns the network client.
Do not delete the Hello container for cause A. It destroys a working credential and changes nothing about network timing.
Cause B: register the key again
Retrying and refreshing will not help, because the device is doing nothing wrong. Entra needs a registered Hello key for this user again. In practice the user's Hello credential is removed from the device and the user enrols again, which registers a new key. The ordered procedure, and how to find what removed the key, is in the companion post: AADSTS130004: the Hello key is missing in Entra.
certutil.exe -deleteHelloContainer, and warns that "On the latest versions of Windows 11, running the certutil -deletehellocontainer command clears not only Windows Hello for Business, but also any passkeys stored on that Windows device." First check Start > Settings > Accounts > Passkeys with the user, make sure they can sign in with a password, and confirm cause B with Check 1. Never push this from an Intune remediation.Both causes: put the check before the action
The real fix for the refresh loop is in your automation. Anything that runs dsregcmd /refreshprt must first read the diagnostics block and decide which cause it is looking at. This snippet does only that classification and changes nothing. It must run in the user's session, for the reason in Check 1.
Only NETWORK should ever lead to an automatic refresh. KEY-MISSING-IN-ENTRA and SERVER-REJECTED are decisions Entra made, so a refresh just asks the same question again. WRONG-CONTEXT and REVIEW go to a person.
The parser matches the field labels in Microsoft's sample SSO State output and reads the first diagnostics block it finds. If an AcquirePrtDiagnostics and a RefreshPrtDiagnostics block are both present, read the output by hand.
Proof it worked: a fresh PRT and no diagnostics block
The proof is the same for both causes. After the fix and a new sign-in, run Check 1 again as the user. Good looks like this (illustrative):
Check three things:
AzureAdPrtUpdateTimeis after your fix. Microsoft defines it as the time "when the PRT was last updated". A time from before the first failure means nothing has renewed.- The diagnostics block has gone. No block means no failure since the last success.
- For cause B,
NgcKeyIdhas changed. Microsoft describes it as "The ID of the Windows Hello key". A new value proves a new key. The same value means the old key is still in use, and Entra will keep refusing it.
For cause B, repeat Check 3 for the period after the fix. The failure rows should stop.
Bad looks like the same AADSTS130004 line coming back with a newer Previous Prt Attempt time. The re-enrolment did not complete, or the old container is still in use. Go back to the companion post before trying anything else.
References
- Your credentials could not be verified error when logging on to Windows with WHFB - Microsoft Learn. The message text and the NTAuth cause.
- Troubleshoot devices by using the dsregcmd command - Microsoft Learn. The PRT diagnostics fields and the user-context rule.
- Microsoft Entra authentication and authorization error codes - Microsoft Learn. AADSTS130004 and the trace and correlation IDs.
- Understanding Primary Refresh Token (PRT) in Microsoft Entra ID - Microsoft Learn. How and when the PRT renews.
- How Windows Hello for Business authentication works - Microsoft Learn. The signed nonce and the registered public key.
- Windows Hello for Business FAQ - Microsoft Learn. Deleting a Hello container, and the passkey warning.
- No local administrator group privileges on Microsoft Entra joined device - Microsoft Learn. The
dsregcmd /refreshprtprocedure. - System Error Codes (1300-1699) - Microsoft Learn. 1326.
- WinHTTP Error Messages - Microsoft Learn. 12007.
- [MS-ERREF] HRESULT - Microsoft Learn. FACILITY_WIN32.
- [MS-ERREF] NTSTATUS Values - Microsoft Learn. 0xC000023C and 0xC00000D0.
- Customize and filter activity logs in Microsoft Entra ID - Microsoft Learn. Sign-in log path, Correlation ID filter, Reports Reader.
- Non-interactive sign-in logs - Microsoft Learn. What a non-interactive sign-in is.
Related reading on EndpointWeekly
- AADSTS130004: the Hello key is missing in Entra - the full fix for cause B.
- dsregcmd /status Decoded: The Complete Field Reference - every field beyond the PRT lines.
- The Primary Refresh Token (PRT): How Entra ID SSO Actually Works - issue, renewal and protection.
- The Complete Windows Hello for Business Event ID Catalog - the events behind Check 2.
- NgcSet Says YES and Windows Hello Still Does Not Work - triaging one device when the local state looks healthy.
- WHfB on a Hybrid-Joined Device: Diagnostic Walkthrough - the hybrid join path.
Both causes were observed on enterprise laptops in 2026. All dsregcmd and event output here is illustrative: identifiers, times and user names are fictional, in Microsoft's documentation style. The Winlogon and NetworkProfile event IDs are observations from one device. Microsoft facts were checked against the pages above on 31 October 2026.