Passkeys in Brave Browser (2026): What Works and Breaks

1. Introduction: Passkey Support in Brave Today#

Brave's passkey support is close to Chromium at the code level, but the user experience diverges in a few important places. As of April 2026, the broader brave/brave-browser repository still had 24 open issues matching passkey or WebAuthn, while brave/brave-core showed one visible WebAuthn-specific customization. The main breakpoints are extension interception, Windows Hello prompts and Android flows on de-Googled devices.

Brave ships passkeys through the same WebAuthn code path as upstream Chromium and delegates credential storage to the operating system. That architecture makes Brave look standard on paper, but real-world behavior still depends on surrounding systems such as password-manager extensions, Windows Hello and Google Play Services. The sections below keep those failure modes separate so each platform-specific behavior can be understood on its own.

2. How does the WebAuthn stack in Brave differ from Chromium's?#

Brave's WebAuthn implementation is effectively Chromium's implementation with one visible UI text change. The brave/brave-core repository contains a single WebAuthn-related customization - a string override that renames "Incognito" to "Private" in the save dialog - and no C++ patches touching WebAuthn core logic. That means Brave inherits the Chromium passkey stack Google shipped from Chromium 115 in June 2023 onward.

This matters for two reasons. First, normal upstream merges mean WebAuthn fixes and feature additions generally arrive without Brave maintaining a deeply forked passkey implementation. You can inspect the lone string override directly in brave/brave-core. In AAGUID mappings, the Chromium browser authenticator path is commonly identified as b5397666-4885-aa6b-cebf-e52262a439a2, labeled "Chromium Browser" in our reference list. Second, most reported failures - extension interception, autofill conflicts and Android's Google Play Services dependency - appear in adjacent systems such as autofill, permissions, Shields or Wallet integration. They surround the WebAuthn flow rather than replacing it.

3. Can a passkey created on macOS be used in Safari on another Apple device?#

Yes, but only if the passkey is saved to iCloud Keychain. On macOS, Brave uses Chromium's WebAuthn stack and can store a new passkey either in the Apple platform authenticator or in another storage target presented in the creation prompt. A passkey saved to iCloud Keychain syncs through the Apple ID and becomes available in Safari, Chrome and other WebAuthn-capable browsers on Apple devices that share that Apple ID.

Once macOS confirms that Brave is allowed to access iCloud Keychain, the browser can use the same synced passkeys that Safari sees. That permission prompt is the practical moment where cross-browser portability on Apple devices becomes real rather than theoretical.

Brave on macOS can also participate in cross-device authentication flows. If the user allows Bluetooth access, Brave can discover and communicate with nearby devices during CDA, which makes phone-based passkey approval feel largely seamless from the desktop browser.

A passkey saved to a browser-profile store or local-only store does not automatically become available in Safari on another Apple device. That difference matters because OS-level platform-authenticator sync and browser-profile sync follow different rules. Brave does not ship Chrome's Google Password Manager passkey sync, so only the iCloud Keychain path provides Apple-style cross-browser portability on Apple devices.

4. Why don't passkeys reliably work on Android without Google Play Services?#

Android's Credential Manager is not itself part of Google Play Services. On Android 14 and later, Chromium can use the system Credential Manager path, while older Android versions rely more heavily on the Google Play Services-backed FIDO2 layer. In practice, Brave still inherits the failure documented in issue #45415: on GrapheneOS, CalyxOS, /e/OS and other de-Googled Android builds without the needed Play Services path, passkey registration and authentication can time out. As of April 2026, this remained an open compatibility gap for privacy-focused Android users.

This behavior is documented in brave/brave-browser issue #45415, opened in April 2025 and still open a year later. Google's Credential Manager documentation distinguishes the Credential Manager API from the optional Play Services auth dependency used on older Android versions, and the broader Android guide notes that Android 14+ can work with enabled password managers. The thread also notes that the same failure mode affects Chromium-based browsers more broadly, while Firefox-based browsers are not affected in the same way. The original reporter pointed out that GrapheneOS patched the dependency in its own Chromium fork, Vanadium, so a downstream fix looks technically possible - it just has not happened.

Multiple users independently confirmed the behavior in that thread. One especially clean test in December 2025 used the same device with two profiles: passkeys worked in Brave only on the profile with Play Services enabled, while Vanadium and Cromite worked on both. As of April 2026, no Brave maintainer had responded in the thread. For Brave's privacy-focused Android audience - which includes a disproportionate number of de-Googled users - that leaves a very visible gap. Firefox on Android uses its own WebAuthn stack and does not depend on Play Services in the same way. Today, the practical workaround is to use Firefox for passkey flows on non-Play-Services Android, or fall back to a hardware security key with a compatible client. For the broader Android failure landscape, see Native App Passkey Errors. For the Google Play Services and Credential Manager specifics, see Android & Google Play Services Passkey Error Codes.

5. Why do Windows Hello passkey prompts appear even when I disable them?#

Disabling Brave's "offer to save passkeys" setting does not stop Windows Hello from appearing during WebAuthn flows. Once a site calls WebAuthn and Windows Hello is enrolled, Windows advertises Hello as a platform authenticator and Brave does not expose a user-facing control that blocks it. As of January 2026, Windows Hello suppression remained unsolved for users who wanted Hello for device unlock but not for passkeys.

Issue #51858, opened in January 2026, and the longer community thread 646042 describe the same thing. The original reporter tried registry edits, group policies, flag toggles and clean installations - none of it changed the behavior.

The technical reason described in thread 646042 is simple: browser password-manager settings control the browser's own autofill behavior, not the WebAuthn boundary between the page and the OS. Windows exposes Hello independently, and the discussion does not identify a documented, supported configuration that preserves Windows Hello for device unlock while fully blocking it as a WebAuthn platform authenticator.

Today, the only reliable way to suppress those prompts is to disable Windows Hello enrollment entirely, which obviously clashes with how most people want to unlock their device. Edge behaves differently because it is more tightly integrated with Windows' credential-management layer and exposes controls Chromium forks currently do not. For a broader look at Windows passkey behavior, see Passkeys on Windows 11.

6. Should you store passkeys natively or in your password manager?#

Native passkey storage is the simplest option inside a single ecosystem, while password-manager extensions remain the only broadly workable cross-platform sync layer. iCloud Keychain works well across Apple devices, Windows Hello works on Windows and extension-based vaults such as 1Password or Bitwarden are still the only realistic option for users who want passkeys to be natively available across Windows, macOS, Linux and Android. Cross-device authentication (CDA, or hybrid transport via QR code and Bluetooth) can still bridge devices at sign-in time, but it does not sync the credential itself or make it locally available everywhere by default. The tradeoff is reliability: native flows are simpler, extension flows are more portable and CDA is best understood as a fallback path rather than a storage strategy.

The decision mostly comes down to three things: how many platforms you use, how much you trust extension flows and where you already keep your credentials. If you mostly stay inside one OS ecosystem - all Apple, or all Windows - the native platform authenticator route is the cleanest option. In that setup, Brave behaves much like Chrome or Safari. If you need passkeys to follow you across Windows, macOS, Linux and Android, a third-party password manager extension such as 1Password, Bitwarden, Dashlane or Proton Pass is still the only broadly workable sync layer.

The complication is that, since April 2024, reports have kept coming in that the native passkey UI intermittently hijacks extension-driven flows. Users in issue #37762 describe OS authentication dialogs appearing even though Bitwarden or 1Password should own the credential. By March 2026, the old workaround - disabling brave://flags/#web-authentication-new-passkey-ui - was no longer available because the flag had been removed in version 146.

In practice, the pattern many privacy-focused users end up with in 2026 is a hybrid one: use the OS platform authenticator for everyday sign-ins inside one ecosystem, use a password manager extension where cross-platform portability matters and keep a hardware security key around for high-value accounts.

7. What passkey pain points are users reporting in 2026?#

Brave's open passkey issues in 2026 cluster around three recurring themes: extension interception, Android failures on de-Googled devices and desktop security-key problems. As of April 2026, the broader repository still showed 24 open issues matching webauthn or passkey, which suggests the friction is concentrated, not random.

The busiest cluster is extension interception, where the native passkey UI can override 1Password, Bitwarden or Dashlane prompts. Android compatibility without Google Play Services is the second recurring problem, and desktop security-key detection is the third. The issue threads most often referenced here are #37762, #50561, #45415, #15650, #43043, #34441, #33237 and #51858. The active threads point in the same direction without needing many direct quotes.

Several of these issues received new comments within the last 90 days, which makes them active regressions rather than historical curiosities. For developers building passkey flows, the takeaway is clear: test extension-driven flows in Brave explicitly and offer sensible fallbacks when WebAuthn calls fail. For users, the lesson is equally practical: keep a hardware security key or another recovery factor configured on high-value accounts.

8. Conclusion#

The passkey story in Brave is clean at the code level and messy at the user-experience level. The WebAuthn path is effectively Chromium's, with just a single string override confirming how close the implementation stays to upstream. On Apple platforms, passkey portability works exactly as users expect because iCloud Keychain owns the credential. The real friction sits elsewhere: extension interception (#37762), Windows Hello suppression (#51858) and Android's Google Play Services dependency (#45415). Until those issues are resolved, developers should test Brave separately instead of assuming Chrome parity and users should keep a strong fallback - ideally a hardware security key - for important accounts.

9. About Corbado#

Corbado builds passkey infrastructure for consumer login and provides a passkey observability and adoption platform for teams that need to operate passkeys and authentication systems at scale. We publish technical analyses of WebAuthn and passkey behavior across browsers and operating systems based on real deployments, direct source inspection and close reading of the underlying specifications. Questions or corrections are always welcome.

10. Frequently asked questions#

10.1 Can a passkey created in Brave on macOS be used in Safari on another Apple device?#

Yes, but only if Brave saves the passkey to iCloud Keychain. On macOS, Brave uses Chromium's WebAuthn stack and can store a new passkey in iCloud Keychain or in another storage target shown in the creation prompt. A passkey saved to iCloud Keychain syncs through the Apple ID and becomes available in Safari, Chrome and other browsers on Apple devices that share that Apple ID. A passkey saved to a browser-profile store or local-only store does not automatically become available in Safari on another Apple device.

10.2 Why do passkeys fail in Brave on Android without Google Play Services?#

Brave on Android can fail without Google Play Services, but the reason is more specific than "Credential Manager is part of Play Services." Android's Credential Manager is a system and Jetpack API, while older Android versions rely more heavily on the Google Play Services-backed FIDO2 layer. In practice, Brave still inherits the failure documented in brave/brave-browser issue #45415: on GrapheneOS, CalyxOS or other de-Googled Android builds without the needed Play Services path, the passkey dialog never opens and registration or authentication times out.

For the broader Android failure landscape, see Native App Passkey Errors. For the Google Play Services and Credential Manager specifics, see Android & Google Play Services Passkey Error Codes.

10.3 Does Brave sync passkeys across devices like Chrome does?#

No. Brave does not provide an equivalent of Chrome's browser-profile passkey sync through Google Password Manager. Passkeys created in Brave are stored in the underlying OS platform authenticator - iCloud Keychain on Apple, Windows Hello on Windows and Android Credential Manager on Android - and sync only through that OS account. If you want consistent cross-device sync, you rely on the OS vendor or on a third-party password manager extension.

10.4 Why does Brave prompt for Windows Hello passkeys even when I disable passkey options in settings?#

Brave's brave://password-manager/settings toggle only controls whether Brave offers to save passkeys itself. It does not stop Windows from advertising Windows Hello as a WebAuthn platform authenticator to the page. The site invokes WebAuthn, Windows presents Hello and Brave has no in-browser switch to suppress the OS dialog. The behavior is tracked in brave/brave-browser issue #51858.

10.5 Should I store passkeys in Brave's native flow or in my password manager?#

Use Brave's native OS flow (iCloud Keychain or Google Password Manager through the platform) if you stay inside one ecosystem and want the fewest moving parts. Use a third-party password manager extension such as 1Password or Bitwarden if you need passkeys to follow you across Windows, macOS, Linux and Android consistently, or if you already keep your secrets there. Since 2024, Brave's native UI has repeatedly intercepted extension passkey flows, so it is worth verifying that the extension still owns the prompt.

10.6 How many open passkey and WebAuthn issues does the brave/brave-browser repository currently have for Brave passkey behavior?#

As of April 2026, brave/brave-browser had 24 open issues matching passkey or WebAuthn searches. Passkey-tagged open issues grew from roughly 2 per year in 2022-2023 to 6 opened in 2025. For Brave, the dominant themes are extension interception on desktop, Windows Hello suppression and Android Google Play Services dependency.