Brave Passkeys: Clean WebAuthn, Messy UX

Brave's passkey story in 2026 is a good example of why standards compliance does not automatically produce a clean user experience.

At the implementation level, Brave is almost entirely upstream Chromium for WebAuthn. The code path is essentially untouched, with only one visible customization: a string change from Chrome's "Incognito" to Brave's "Private" in the passkey save dialog. No C++ patches alter the WebAuthn flow itself.

That matters because it explains why Brave usually behaves like Chromium, but also why many reported problems sit outside the core WebAuthn implementation.

The practical takeaway for developers: do not assume Chrome parity just because Brave shares Chromium. The biggest failures are not about attestation formats or RP configuration. They show up in surrounding layers:

• OS integration
• Extension prompts
• Platform services

Where Brave actually breaks

As of April 2026, there are 24 open Brave issues matching passkey or WebAuthn searches. The problems are not random. They cluster around three themes.

1. Android on de-Googled devices

The sharpest issue is dependency on Google Play Services. Issue #45415 documents that on GrapheneOS, CalyxOS, /e/OS, and similar setups, passkey registration and authentication can:

• Time out completely
• Fail to open the dialog at all

Chromium can use Android's Credential Manager on newer versions, but that does not eliminate the failure mode across all devices and configurations.

Key lesson: "Android support" is too broad a test label. If your users include privacy-focused Android distributions, Brave needs separate validation.

2. Windows Hello prompts

Issue #51858 shows a different boundary problem. Disabling Brave's own passkey-saving settings does not stop Windows Hello from being offered as a WebAuthn platform authenticator. That is because:

• The site talks to WebAuthn
• The OS advertises Hello directly
• Brave's settings do not control that OS-level offer

Key lesson: If your product team expects a browser toggle to suppress Windows Hello, that expectation is wrong in Brave today.

3. Extension interception

Issue #37762 tracks the native passkey UI overriding Bitwarden and 1Password prompts. This has been active since April 2024, and a previous workaround using the web-authentication-new-passkey-ui flag disappeared in Chromium 146.

Storage choice is the real product decision

Passkey reliability in Brave depends less on browser branding and more on where the credential lives. Brave does not provide Chrome-style browser-profile passkey sync through Google Password Manager. Instead, it delegates to the platform authenticator or to third-party extension flows.

That creates a clear storage tradeoff:

macOS nuance: A passkey created in Brave can be used in Safari on another Apple device only if it was saved into iCloud Keychain. A browser-local credential does not magically become cross-browser portable.

The extension problem is the most important regression

If you support users across Windows, macOS, Linux, and Android, extension-based vaults are still the most practical answer. But this is also where Brave is most unstable.

If your login relies on extension-owned passkeys, don't just test whether WebAuthn succeeds. Test:

• Prompt ownership — does the right dialog appear?
• Fallback behavior — what happens when it doesn't?
• Recovery UX — what does the user see when the browser routes them into the OS dialog instead of the extension they expected?

For high-value accounts: keep a hardware security key as fallback. In Brave today, that is not just a security recommendation. It is an operational safety net.

Read the full breakdown here: https://www.corbado.com/blog/passkeys-brave-browser