Check Windows Hello for Business Keys in Entra ID With…

The laptop says Windows Hello for Business is set up. The user still can't sign in with their PIN. Every check you run on the device passes, because every check you run on the device only looks at the device.

A Hello credential has two halves. The private key lives on the laptop. The cloud half is an authentication method registered to the user in Microsoft Entra ID. dsregcmd /status can prove the first half. It can't see the second. This post shows how to read the cloud half with Microsoft Graph, without changing anything.

The short version

Microsoft Graph exposes each user's Hello keys as windowsHelloForBusinessAuthenticationMethod objects at GET /users/{id}/authentication/windowsHelloForBusinessMethods. In PowerShell the cmdlet is Get-MgUserAuthenticationWindowsHelloForBusinessMethod, in the Microsoft.Graph.Identity.SignIns module. To read another user you need UserAuthMethod-WindowsHello.Read.All and a role such as Global Reader. To see which device a key belongs to, get one method at a time with $expand=device. For the whole tenant, the userRegistrationDetails report shows who has no Hello method at all. Correlate by device ID, never by name, and never delete methods from a report.

The problem: the laptop has a key, Entra ID doesn't

On one enterprise laptop, a user reported that Windows Hello sign-in had failed with "credentials could not be verified". The device looked perfect. It was joined. The Trusted Platform Module (TPM) was ready. NgcSet was YES. The key passed its signing test.

The answer was in the Primary Refresh Token (PRT) diagnostics at the bottom of dsregcmd /status. A PRT is the token Windows uses for single sign-on to Microsoft Entra ID. The block looked like this:

dsregcmd /status, run as the user - illustrative

# User State: the device side says Hello is set up NgcSet : YES NgcKeyId : {aaaaaaaa-0b0b-1c1c-2d2d-333333333333} # SSO State: the cloud side refuses the key RefreshPrtDiagnostics : PRESENT Previous Prt Attempt : 2026-10-20 07:28:27.000 UTC Credential Type : NGC HTTP status : 400 Server Error Description : AADSTS130004: The user principal doesn't have the NGC ID key configured.

Illustrative. The field names and layout follow Microsoft's dsregcmd documentation. The values are invented.

Here is what each part tells you:

NgcSet : YES means a Hello key is set on this device for this user. Microsoft's dsregcmd page defines it as "YES if a Windows Hello key is set for the current logged-in user". It says nothing about the cloud.
Credential Type : NGC means Windows tried to renew the PRT with the Hello key. Microsoft's page lists the common credential types as "Password and Next Generation Credential (NGC) (for Windows Hello)".
AADSTS130004 is the cloud's answer. Microsoft's Entra error code list names it NgcKeyNotFound: "The user principal doesn't have the NGC ID key configured."

So the laptop holds a private key that Entra ID no longer recognises. Nothing on the device can show you that. A fleet report built from dsregcmd, TPM state and device registration will mark this laptop healthy. It is healthy. The user's cloud record isn't.

📋 Note: run dsregcmd as the user. Microsoft's page says of the User State and SSO State sections: "The command must run in a user context to retrieve a valid status." A detection script running as SYSTEM sees SYSTEM's state, not the person who raised the ticket. The device triage post covers that trap in detail.

Why it happens: four objects that look like one

When someone says "the user's Hello device", they can mean four different objects. They live in different places, have different IDs, and fail separately.

Object	What it is	Where you read it	What it can't prove
The user's authentication method	The Hello public key registered to the user in Entra ID.	Microsoft Graph: `windowsHelloForBusinessMethods`	That the private key on the laptop still exists or works.
The Entra device	The device's directory identity, created at join or registration.	Entra admin center: Entra ID › Devices › All devices. On the laptop: `DeviceId` in dsregcmd.	That the user has a Hello key on it.
The Intune managed device	The MDM record: enrolment, compliance, check-in.	Microsoft Intune admin center.	Anything about the user's Hello key. It's a separate record, so a healthy check-in says nothing about the key.
Sign-in and PRT evidence	What actually happened when the key was used.	dsregcmd PRT diagnostics on the laptop. Entra sign-in logs in the cloud.	Why the key is missing. That's in the audit log.

Two rules follow from that table:

A Graph method doesn't prove the local container works. The method is only the public half. It tells you nothing about whether the private half on the laptop is still there, or still signs.
NgcSet : YES doesn't prove the method maps to the right device. It proves a key exists on this laptop. It doesn't tell you which Entra device the cloud copy points to, or whether the cloud copy exists.

Microsoft's resource page describes the method as "a Windows Hello for Business authentication method registered to a user". It has four properties and one relationship:

Property	Microsoft's description	What to use it for
`id`	"A unique identifier for this authentication method."	The handle for reading one method with its device.
`displayName`	"The name of the device on which Windows Hello for Business is registered"	A hint only. It's a name, not an ID.
`createdDateTime`	"The date and time that this Windows Hello for Business key was registered."	Match it to when the user last enrolled.
`keyStrength`	"The possible values are: `normal`, `weak`, `unknown`."	Flag anything that isn't `normal` for review.
`device` (relationship)	"The registered device on which this Windows Hello for Business key resides."	The Entra device object, with its `deviceId`. Compare it with dsregcmd.

Why does the device link matter? Because Entra ID checks it. The same error list has AADSTS130008, NgcDeviceIsNotFound: "The device referenced by the NGC key wasn't found." A key can exist for the user and still point at a device object that has gone.

Now the timing. Windows keeps a separate PRT for each credential. Microsoft's PRT documentation says "there's a PRT for each of Windows Hello for Business, password, or smart card", and that the CloudAP plugin "renews the PRT every 4 hours during Windows sign in". A Hello sign-in presents the Hello key to Entra ID. If the cloud copy has gone, that request fails.

Hello method removed in Entra ID→laptop keeps its cached state→next Hello PRT request→AADSTS130004

On the laptop I examined, the failure didn't come when the key was removed. It came days later, when Windows went to renew the session with the Hello key. NgcSet stayed YES throughout, and nothing repaired itself. That delay matters. If keys are removed for many users at once, expect the tickets to arrive one by one over the following days, looking unrelated.

The last trap is names. Microsoft calls the method's id "a unique identifier". It calls displayName only "the name of the device". Nothing makes the name unique. In a large estate I have seen two methods with the same name for one user, after a laptop was rebuilt under its old name. They can point at two different device objects, and one of those may no longer exist. Correlate by ID every time.

How to verify: read the cloud half with Microsoft Graph

Everything in this section only reads. Use a delegated sign-in with read-only scopes, so a typo can't become a write.

Step 1: get the right permission and role

The list endpoint marks UserAuthMethod-WindowsHello.Read as least privileged for delegated access. That one only reads your own methods: the permissions reference describes it as "Read the signed-in user's Windows Hello methods". To read someone else's, you need the .All version, which reads "all users' Windows Hello methods".

What you want	Delegated permission	Entra role for the person signing in
Another user's Hello methods	`UserAuthMethod-WindowsHello.Read.All`	Global Reader, Authentication Administrator or Privileged Authentication Administrator
The registration report (`userRegistrationDetails`)	`AuditLog.Read.All`	Reports Reader, Security Reader, Security Administrator or Global Reader

Microsoft says that when the signed-in user acts on another user, "they must be assigned a supported Microsoft Entra role". Global Reader appears in both lists, so one role covers both reads. The other roles in the first row can also change authentication methods, so you don't need them for this.

Step 2: list one user's Hello methods

This is the request in Graph Explorer. It returns every Hello key registered to the user:

GET https://graph.microsoft.com/v1.0/users/adele.vance@contoso.com/authentication/windowsHelloForBusinessMethods

The same thing in Microsoft Graph PowerShell. Connect-MgGraph signs you in with the read-only scope. The cmdlet after it lists the methods:

PowerShell - list a user's Hello methods, read-only (illustrative output)

Import-Module Microsoft.Graph.Identity.SignIns Connect-MgGraph -Scopes 'UserAuthMethod-WindowsHello.Read.All' $upn = 'adele.vance@contoso.com' Get-MgUserAuthenticationWindowsHelloForBusinessMethod -UserId $upn | Select-Object Id, DisplayName, CreatedDateTime, KeyStrength Id DisplayName CreatedDateTime KeyStrength -- ----------- --------------- ----------- b5e01f81-1f81-b5e0-811f-e0b5811fe0b5 DESKTOP-A1B2C3 2025-03-11 09:14:02 normal e6dab818-e68d-433e-89d5-547357870cb2 DESKTOP-A1B2C3 2026-06-02 08:41:37 normal

Illustrative output. The method IDs are the ones in Microsoft's own example response. The names and dates are invented.

Read it like this:

Good: one method per device the user really signs in on, created around the time they enrolled.
Bad: no rows. Entra ID has no Hello key for this user. If their laptop says NgcSet : YES, you have found the orphaned-key case from the first section.
Suspicious: two rows with the same name. In a large estate I see this after rebuilds. One of them may point at a device that's gone. Step 3 tells you which.

Step 3: find the device behind each method

This is the step most people miss. The list call doesn't return the device. Microsoft's resource page says the device property "is returned only on a single GET and when you specify ?$expand". So you read one method at a time:

GET https://graph.microsoft.com/v1.0/users/adele.vance@contoso.com/authentication/windowsHelloForBusinessMethods/b5e01f81-1f81-b5e0-811f-e0b5811fe0b5?$expand=device

In PowerShell, loop over the list and get each method again with -ExpandProperty device. This prints the method next to the Entra device ID it points at:

PowerShell - each Hello method with its device, read-only (illustrative output)

$upn = 'adele.vance@contoso.com' $methods = Get-MgUserAuthenticationWindowsHelloForBusinessMethod -UserId $upn foreach ($m in $methods) { # The device relationship is only returned on a single GET with $expand $one = Get-MgUserAuthenticationWindowsHelloForBusinessMethod -UserId $upn ` -WindowsHelloForBusinessAuthenticationMethodId $m.Id -ExpandProperty 'device' [pscustomobject]@{ MethodId = $one.Id KeyName = $one.DisplayName Registered = $one.CreatedDateTime DeviceId = $one.Device.DeviceId DeviceName = $one.Device.DisplayName } } MethodId : b5e01f81-1f81-b5e0-811f-e0b5811fe0b5 KeyName : DESKTOP-A1B2C3 Registered : 2025-03-11 09:14:02 DeviceId : DeviceName : MethodId : e6dab818-e68d-433e-89d5-547357870cb2 KeyName : DESKTOP-A1B2C3 Registered : 2026-06-02 08:41:37 DeviceId : 00aa00aa-bb11-cc22-dd33-44ee44ee44ee DeviceName : DESKTOP-A1B2C3

Illustrative output, written for this post. Both methods carry the same name. Only the second resolves to a device.

Good looks like every method resolving to a device. The DeviceId should match the laptop the user actually uses. Bad looks like the first row: a method whose device doesn't come back. Treat that as "needs a person to look", not as proof the method is junk. Look the device up in the portal before you draw any conclusion.

⚠ Gotcha: the list call has no device and no filters. The list endpoint's "Optional query parameters" section reads "Not supported." You can't $expand the device or filter by name on the list. Any script that reads device from the list result gets nothing back, and can wrongly decide that every method is orphaned. Always do the single GET.

Step 4: match the cloud device ID to the laptop

On the user's laptop, read the device ID from dsregcmd. Microsoft defines DeviceId as "The unique ID of the device in the Microsoft Entra tenant." It's in the Device Details section:

PowerShell on the laptop, as the user - read-only (illustrative output)

dsregcmd /status | Select-String 'DeviceId|NgcSet|NgcKeyId' DeviceId : 00aa00aa-bb11-cc22-dd33-44ee44ee44ee NgcSet : YES NgcKeyId : {aaaaaaaa-0b0b-1c1c-2d2d-333333333333}

Then compare the two sides:

Laptop (dsregcmd)	Cloud (Graph)	What it means
`NgcSet : YES`	A method whose device `deviceId` equals the laptop's `DeviceId`	Both halves exist and point at each other. Look elsewhere for the fault.
`NgcSet : YES`	No Hello methods at all	Orphaned local key. The cloud half is gone. Expect `AADSTS130004`.
`NgcSet : YES`	Methods exist, none on this `DeviceId`	The key on this laptop isn't the one Entra ID holds. Treat it as orphaned for this device.
`NgcSet : NO`	A method on this `DeviceId`	The cloud holds a key the laptop no longer has. Fix the device side first. The device triage post covers it.

✅ Tip: the device ID is the join key. An Entra device object has its own object id and a separate deviceId, the "Unique identifier set by Azure Device Registration Service at the time of registration". Compare dsregcmd's DeviceId with deviceId. Microsoft's hybrid join check does the same: take the DeviceId and "compare the status on the service using either the Microsoft Entra admin center or PowerShell". In any report that joins methods to devices, join on deviceId. Keep the name for display only.

Step 5: find users with no Hello method in the whole tenant

Checking users one by one doesn't scale. The authentication methods registration report does. In the portal it's here:

Microsoft Entra admin center › Entra ID › Authentication methods › Activity

Tab: Registration

List: User registration details

Column to read: Methods registered (includes "Windows Hello for Business")

Microsoft's Authentication Methods Activity page sets two conditions. "A Microsoft Entra ID P1 or P2 license is required to access Usage and insights." And the report isn't live: "The report updates for most users in the tenant in 36 hours."

The same data is in Graph at GET /reports/authenticationMethods/userRegistrationDetails. First, confirm the exact method name your tenant uses. This request returns a count per method. In Microsoft's example response, Hello appears as windowsHelloForBusiness:

GET https://graph.microsoft.com/v1.0/reports/authenticationMethods/usersRegisteredByMethod(includedUserTypes='member',includedUserRoles='all')

Then pull the per-user report and keep the members who have no Hello method. The $filter on methodsRegistered only supports any with eq, so "has no Hello" is filtered in PowerShell after the download:

PowerShell - members with no Hello method, read-only (illustrative output)

Import-Module Microsoft.Graph.Reports Connect-MgGraph -Scopes 'AuditLog.Read.All' $hello = 'windowsHelloForBusiness' # confirm with usersRegisteredByMethod first $rows = Get-MgReportAuthenticationMethodUserRegistrationDetail -All $rows | Where-Object { $_.UserType -eq 'member' -and $_.MethodsRegistered -notcontains $hello } | Select-Object UserPrincipalName, IsPasswordlessCapable, LastUpdatedDateTime | Sort-Object UserPrincipalName UserPrincipalName IsPasswordlessCapable LastUpdatedDateTime ----------------- --------------------- ------------------- alex.wilber@contoso.com False 2026-10-30 19:15:41 megan.bowen@contoso.com True 2026-10-30 19:15:41

Illustrative output. The names are Microsoft's standard demo users at contoso.com.

How to read the result:

A user in this list whose laptop says NgcSet : YES is a candidate for the orphaned-key case. Confirm with steps 2 and 4 before you tell anyone.
IsPasswordlessCapable can still be True. Microsoft counts FIDO2 and Microsoft Authenticator passwordless too. It's not a Hello flag.
LastUpdatedDateTime is the report's time, not the user's. Microsoft says it "is not related the user's authentication method registration." A key removed this morning may not show here until tomorrow.
Some users are missing on purpose. The list endpoint "doesn't work for disabled users", and soft-deleted users aren't listed either.

The fix: decide per user, change nothing in bulk

The checks above tell you which users need attention. They don't tell you what to delete, and you shouldn't delete anything from them. Work one user at a time.

The method is missing and the laptop has a key. The local key is no use against Entra ID now. The user has to set up Hello again on that laptop. The companion post on AADSTS130004 covers that re-enrolment.
Find out why the method went before you fix the next one. The laptop can't tell you. Look in the Entra audit log for the user, between their last good sign-in and the first failure. If nothing explains it, keep the evidence and raise a case with Microsoft.
The method points at the wrong or a missing device. Treat it as a finding, not a task. Confirm the user's current laptop by DeviceId, and that it has its own method. Only then decide, with the user, whether the stale method should go.
Many users show up at once. Look for one cause, not many faults. A single admin action or process can remove methods for a whole group. If the one laptop above is typical, the failures then arrive one by one over the following days.

⚠ Warning: never delete Hello methods in bulk from a report. Microsoft Graph has a delete call for this method, and it needs write permissions such as UserAuthenticationMethod.ReadWrite.All. Don't grant them to a reporting app. Deleting a user's Hello method removes the cloud half of a key their laptop still uses. The laptop doesn't know. When Windows next presents that key to renew the PRT, the answer is AADSTS130004, and the user can't sign in with Hello until they enrol again. On the laptop I examined, that moment came days after the key was gone. The registration report lags by up to 36 hours and has no device information at all. A clean-up driven from it will remove working keys. If one stale method must go, do it by hand, for one user, after you have matched every method to a device ID.

Keep the tooling read-only by design, not by good intentions:

Use delegated sign-in with UserAuthMethod-WindowsHello.Read.All and AuditLog.Read.All only. No ReadWrite scope, for anyone running the report.
Sign in as Global Reader. It's listed as supported for both the Hello list and the registration report. It isn't in the list of roles the delete call supports.
For a scheduled fleet job, use application permissions with the same read-only names. The list endpoint's least-privileged application permission is UserAuthMethod-WindowsHello.Read.All. The companion fleet dashboard post builds that on Azure Automation.

Proof it worked: a new method on the right device ID

After the user has set up Hello again, check both halves. On the laptop, NgcSet should be YES with a different NgcKeyId from before. In Graph, run step 3 again:

PowerShell - after re-enrolment (illustrative)

MethodId : 2b1c3d4e-5f60-4718-9a2b-3c4d5e6f7a8b KeyName : DESKTOP-A1B2C3 Registered : 2026-10-31 10:02:19 DeviceId : 00aa00aa-bb11-cc22-dd33-44ee44ee44ee DeviceName : DESKTOP-A1B2C3 # On the laptop, as the user DeviceId : 00aa00aa-bb11-cc22-dd33-44ee44ee44ee NgcSet : YES NgcKeyId : {bbbbbbbb-1c1c-2d2d-3e3e-444444444444}

Three things must be true:

A method exists with a createdDateTime from the re-enrolment. If it doesn't, the user didn't finish setup. Ask them to sign out and back in with the new PIN, then read again.
Its device deviceId equals the laptop's DeviceId. Same name isn't enough. Same ID is.
The PRT diagnostics no longer show AADSTS130004. Microsoft's dsregcmd page says the diagnostics appear "only if the acquisition or refresh failure happened after the last successful PRT update time". After a good renewal, the block goes away.

The registration report will show windowsHelloForBusiness for the user too, but give it up to 36 hours.

References

windowsHelloForBusinessAuthenticationMethod resource type - Microsoft Learn. Properties and the device relationship.
List windowsHelloForBusinessAuthenticationMethods - Microsoft Learn. URL, permissions and roles.
Get windowsHelloForBusinessAuthenticationMethod - Microsoft Learn. The single GET with $expand=device.
Get-MgUserAuthenticationWindowsHelloForBusinessMethod - Microsoft Learn. Module and parameters.
Delete windowsHelloForBusinessAuthenticationMethod - Microsoft Learn. The write permissions to keep out of reporting.
Microsoft Graph permissions reference - Microsoft Learn. What UserAuthMethod-WindowsHello.Read and .Read.All allow.
List userRegistrationDetails - Microsoft Learn. URL, permission, roles and $filter.
userRegistrationDetails resource type - Microsoft Learn. The report's properties.
usersRegisteredByMethod - Microsoft Learn. Counts per method.
Get-MgReportAuthenticationMethodUserRegistrationDetail - Microsoft Learn. The report cmdlet in Microsoft.Graph.Reports.
Authentication Methods Activity - Microsoft Learn. Portal path, licence and latency.
Troubleshoot devices by using the dsregcmd command - Microsoft Learn. DeviceId, NgcSet and PRT diagnostics.
device resource type - Microsoft Learn. The deviceId set at registration.
Verify Microsoft Entra hybrid join state - Microsoft Learn. Matching the dsregcmd DeviceId in the service.
Understanding Primary Refresh Token (PRT) - Microsoft Learn. One PRT per credential and the four-hour renewal.
Microsoft Entra authentication and authorization error codes - Microsoft Learn. AADSTS130004 and AADSTS130008.

Check Windows Hello for Business Keys in Entra ID With Microsoft Graph (Read-Only)