[Problem/Bug]: WebAuthn / Passkey (Windows Hello) not working in WebView2 while working in Edge and Chrome

What happened?

Description

We are facing an issue with WebAuthn / Passkey (Windows Hello) authentication inside a WebView2-based application.

The same authentication flow works correctly in Microsoft Edge and Google Chrome, but fails inside WebView2.

---

Expected Behavior

• When invoking WebAuthn APIs (navigator.credentials.create() / get()), the Windows Hello prompt should appear
• PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable() should return true
• Passkey authentication should complete successfully

---

Actual Behavior

• Windows Hello prompt does not appear
• PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable() returns false
• WebAuthn flow fails silently or throws NotAllowedError / SecurityError

---

Environment

• WebView2 Runtime: Latest Evergreen

• Browser comparison:

  • ✅ Works in Microsoft Edge
  • ✅ Works in Google Chrome
  • ❌ Not working in WebView2

---

Additional Context

• The application is running in both:

  • Local machine
  • Virtual environments (VDI / RDP / Citrix / AVD)

• In browsers (Edge/Chrome), passkey authentication works even in VDI (with proper setup), but WebView2 does not behave the same way

• We ensured:

  • HTTPS origin is used
  • Latest WebView2 runtime
  • Persistent userDataFolder is configured
  • No InPrivate / ephemeral sessions

---

Code Snippet (WebView2 Initialization)

Questions

1. Does WebView2 fully support WebAuthn / Passkeys (Windows Hello)?

2. Are there any known limitations for:

   • Embedded WebView scenarios
   • Virtual environments (VDI / RDP)

3. Is additional configuration required beyond enabling browser flags?

4. Does WebView2 use the same OS-level WebAuthn broker as Edge?

5. Is using WebView2 for passkey authentication officially supported/recommended?

---

Impact

This is blocking adoption of Passkey-based authentication in our desktop application, even though the same flow works in standard browsers.

---

Request

Please clarify:

• Whether this is a limitation or a bug
• Recommended approach for supporting passkeys in WebView2-based applications
• Any roadmap or planned improvements (if currently unsupported)

---

Thank you!

Importance

Blocking. My app's basic functions are not working due to this issue.

Runtime Channel

Stable release (WebView2 Runtime)

Runtime Version

148.0.3967.70

SDK Version

1.0.2903.40

Framework

WPF

Operating System

Windows Server

OS Version

No response

Repro steps

Simple Reproduction Steps

1. Open Google Chrome or Microsoft Edge

   • Navigate to a website that supports Passkey / WebAuthn (e.g., https://webauthn.io/ or any internal app)
   • Attempt to register or login using Passkey (Windows Hello)

2. Observe behavior in browser

   • Windows Hello prompt appears
   • Authentication completes successfully
   • Passkey flow works as expected

---

3. Open the WebView2 application

   • Launch the desktop app that uses WebView2
   • Navigate to the same website / same login flow

4. Attempt login using Passkey (Windows Hello)

   • Trigger the same WebAuthn flow (register/login)

---

5. Observe behavior in WebView2

   • Windows Hello prompt does not appear
   • Authentication does not proceed
   • Passkey flow fails

---

Expected Result

WebView2 should behave the same as Chrome/Edge:

• Detect platform authenticator
• Trigger Windows Hello prompt
• Successfully complete authentication

---

Actual Result

• Works in Chrome / Edge
• Fails in WebView2 under the same conditions

Repros in Edge Browser

No, issue does not reproduce in the corresponding Edge version

Regression

Don't know

Last working version (if regression)

No response

Start by reproducing the WebAuthn flow in the WebView2 WPF application and compare it with Edge or Chrome under the reported Windows Server and VDI/RDP conditions. Review the WebAuthn API calls, WebView2 Runtime 148.0.3967.70, SDK 1.0.2903.40, persistent userDataFolder setup, and the listed reproduction steps; done means establishing whether this is supported, a limitation, or a confirmed bug.