Microsoft Password Manager passkeys fail in Edge on one machine, work in Chrome — NgcSet: NO, PassportForWork policy absent

Summary

On one of two Windows 11 Pro machines, creating or using a passkey via Microsoft Password Manager in Edge fails with "Can't reach Microsoft Password Manager". Chrome on the same machine succeeds. A second machine, configured as similarly as I can determine, works in Edge. I've narrowed the difference to Windows Hello provisioning state and would like to know whether that's the supported dependency.

Environment

• Windows 11 Pro, build 26200 (both machines)
• Edge 154.0.4258.53
• Both machines sign in with local Windows accounts (PrincipalSource: Local)
• Neither machine is domain-joined, Entra-joined or workplace-joined
• Peer-to-peer network, no server, no work or school account
• Machine A does not have any integral biometric recognition devices
• Machine B has configured integral camera and fingerprint recognition.

Symptom

Reproduced independently of any one site. The same failure occurs on passkeys.io in Edge on Machine A, and that site works in Chrome on the same machine — so it isn't specific to the website I was originally testing.

Event log evidence — Microsoft-Windows-WebAuthN/Operational:

Error 0x8000FFFF  Catastrophic failure
  WebAuthN error at: DsrGetJoinInfoNoAccessTokenUrl
  (5 occurrences, each coinciding with a failed attempt)

Error 0x800704C7  The operation was canceled by the user
  Ctap GetAssertion completed
  (follows each failure; appears to be the dialog being dismissed)

IsUserVerifyingPlatformAuthenticatorAvailable reports true on the failing machine, so Windows believes a platform authenticator exists.

dsregcmd /status comparison

                      Machine A (fails)   Machine B (works)
IsDeviceJoined             NO                  NO
IsUserAzureAD              NO                  NO
PolicyEnabled              NO                  YES
PostLogonEnabled           YES                 YES
DeviceEligible             YES                 YES
PreReqResult               WillNotProvision    WillNotProvision
NgcSet                     NO                  (not captured)

Registry — the only Hello-related difference found:

HKLM\SOFTWARE\Policies\Microsoft\PassportForWork
  Machine A : key absent
  Machine B : Enabled (DWORD) = 1

Neither machine has PassportForWork under HKLM\SOFTWARE\Microsoft\Policies, HKCU\SOFTWARE\Policies\Microsoft, or PolicyManager\current\device.

Ruled out

• Device registration — neither machine is joined to anything; the DsrGetJoinInfo failure appears on both and is presumably normal for an unjoined machine
• Account type — both machines use local Windows accounts
• Site-specific behaviour — reproduced on a third-party demo site
• Biometric hardware — the same machine fails in Edge and succeeds in Chrome with hardware held constant
• Network — the machine has working internet throughout; other Microsoft services function

Questions

1. Is PassportForWork\Enabled = 1 a documented requirement for Microsoft Password Manager passkeys, or is PolicyEnabled: YES a side effect of something else?
2. Is NgcSet: NO the actual blocker — i.e. does the password manager require a provisioned NGC container even when the credential is cloud-synced?
3. PreReqResult is WillNotProvision on both machines, yet only one fails. What else differs that dsregcmd doesn't surface?
4. Should "Can't reach Microsoft Password Manager" be shown at all when the cause is local provisioning state rather than connectivity? The wording sent me looking at the network for some time.

Not yet attempted: setting PassportForWork\Enabled = 1 on Machine A, and clearing/re-enrolling the NGC store. Both are reversible but I'd rather understand the dependency than change security policy speculatively — particularly as the NGC-clearing fix recommended in this thread didn't resolve it for that reporter.

Point 4 is worth keeping in. "Can't reach" reads as a network problem and cost you most of a day on the wrong trail — that's actionable feedback regardless of what causes the underlying fault.

Sources: Microsoft Q&A ask page, answers.microsoft.com Windows forum, existing passkey threadSummary

On one of two Windows 11 Pro machines, creating or using a passkey via Microsoft Password Manager in Edge fails with "Can't reach Microsoft Password Manager". Chrome on the same machine succeeds. A second machine, configured as similarly as I can determine, works in Edge. I've narrowed the difference to Windows Hello provisioning state and would like to know whether that's the supported dependency.

Environment

• Windows 11 Pro, build 26200 (both machines)
• Edge 154.0.4258.53
• Both machines sign in with local Windows accounts (PrincipalSource: Local)
• Neither machine is domain-joined, Entra-joined or workplace-joined
• Peer-to-peer network, no server, no work or school account

Symptom

Reproduced independently of any one site. The same failure occurs on passkeys.io in Edge on Machine A, and that site works in Chrome on the same machine — so it isn't specific to the website I was originally testing.

Event log evidence — Microsoft-Windows-WebAuthN/Operational:

Error 0x8000FFFF  Catastrophic failure
  WebAuthN error at: DsrGetJoinInfoNoAccessTokenUrl
  (5 occurrences, each coinciding with a failed attempt)

Error 0x800704C7  The operation was canceled by the user
  Ctap GetAssertion completed
  (follows each failure; appears to be the dialog being dismissed)

IsUserVerifyingPlatformAuthenticatorAvailable reports true on the failing machine, so Windows believes a platform authenticator exists.

dsregcmd /status comparison

                      Machine A (fails)   Machine B (works)
IsDeviceJoined             NO                  NO
IsUserAzureAD              NO                  NO
PolicyEnabled              NO                  YES
PostLogonEnabled           YES                 YES
DeviceEligible             YES                 YES
PreReqResult               WillNotProvision    WillNotProvision
NgcSet                     NO                  (not captured)

Registry — the only Hello-related difference found:

HKLM\SOFTWARE\Policies\Microsoft\PassportForWork
  Machine A : key absent
  Machine B : Enabled (DWORD) = 1

Neither machine has PassportForWork under HKLM\SOFTWARE\Microsoft\Policies, HKCU\SOFTWARE\Policies\Microsoft, or PolicyManager\current\device.

Ruled out

• Device registration — neither machine is joined to anything; the DsrGetJoinInfo failure appears on both and is presumably normal for an unjoined machine
• Account type — both machines use local Windows accounts
• Site-specific behaviour — reproduced on a third-party demo site
• Biometric hardware — the same machine fails in Edge and succeeds in Chrome with hardware held constant
• Network — the machine has working internet throughout; other Microsoft services function

Questions

1. Is PassportForWork\Enabled = 1 a documented requirement for Microsoft Password Manager passkeys, or is PolicyEnabled: YES a side effect of something else?
2. Is NgcSet: NO the actual blocker — i.e. does the password manager require a provisioned NGC container even when the credential is cloud-synced?
3. PreReqResult is WillNotProvision on both machines, yet only one fails. What else differs that dsregcmd doesn't surface?
4. Should "Can't reach Microsoft Password Manager" be shown at all when the cause is local provisioning state rather than connectivity? The wording sent me looking at the network for some time.

Not yet attempted: setting PassportForWork\Enabled = 1 on Machine A, and clearing/re-enrolling the NGC store. Both are reversible but I'd rather understand the dependency than change security policy speculatively — particularly as the NGC-clearing fix recommended in this thread didn't resolve it for that reporter.

Point 4 is worth keeping in. "Can't reach" reads as a network problem and cost you most of a day on the wrong trail — that's actionable feedback regardless of what causes the underlying fault.

Sources: Microsoft Q&A ask page, answers.microsoft.com Windows forum, existing passkey thread