Passkeys im Brave Browser (2026): Was funktioniert und was nicht

1. Einführung: Passkey-Unterstützung in Brave heute#

Die Passkey-Unterstützung von Brave ist auf Code-Ebene sehr nah an Chromium, aber die Benutzererfahrung weicht an einigen wichtigen Stellen ab. Mit Stand April 2026 wies das breitere brave/brave-browser Repository noch 24 offene Issues auf, die zu passkey oder WebAuthn passten, während brave/brave-core nur eine einzige sichtbare WebAuthn-spezifische Anpassung zeigte. Die Hauptproblempunkte sind das Abfangen durch Erweiterungen, Windows Hello-Aufforderungen und Android-Flows auf de-Googled Geräten.

Brave implementiert Passkeys über denselben WebAuthn-Codepfad wie das zugrunde liegende Chromium und delegiert die Speicherung der Anmeldeinformationen an das Betriebssystem. Diese Architektur lässt Brave auf dem Papier standardmäßig aussehen, aber das tatsächliche Verhalten hängt weiterhin von umgebenden Systemen wie Passwort-Manager-Erweiterungen, Windows Hello und Google Play-Diensten ab. Die folgenden Abschnitte betrachten diese Fehlerquellen separat, damit jedes plattformspezifische Verhalten für sich verstanden werden kann.

2. Wie unterscheidet sich der WebAuthn-Stack in Brave von dem in Chromium?#

Die WebAuthn-Implementierung von Brave entspricht im Wesentlichen der von Chromium mit einer einzigen sichtbaren Änderung an einem UI-Text. Das Repository brave/brave-core enthält eine einzige WebAuthn-bezogene Anpassung – eine überschriebene Zeichenfolge, die im Speicherdialog "Inkognito" in "Privat" umbenennt – und keine C++-Patches, die die WebAuthn-Kernlogik verändern. Das bedeutet, dass Brave den Passkey-Stack von Chromium übernimmt, den Google ab Chromium 115 im Juni 2023 ausgeliefert hat.

Dies ist aus zwei Gründen wichtig. Erstens bedeuten normale Upstream-Merges, dass WebAuthn-Korrekturen und Funktionserweiterungen im Allgemeinen ankommen, ohne dass Brave eine tief verzweigte Passkey-Implementierung pflegen muss. Sie können die einzige Textänderung direkt in brave/brave-core überprüfen. Bei AAGUID-Zuordnungen wird der Chromium-Browser-Authenticator-Pfad typischerweise als b5397666-4885-aa6b-cebf-e52262a439a2 identifiziert, was in unserer Referenzliste als "Chromium Browser" gekennzeichnet ist. Zweitens treten die meisten gemeldeten Fehler – Abfangen durch Erweiterungen, Autofill-Konflikte und die Abhängigkeit von Google Play-Diensten auf Android – in angrenzenden Systemen wie Autofill, Berechtigungen, Shields oder der Wallet-Integration auf. Sie umgeben den WebAuthn-Flow, anstatt ihn zu ersetzen.

3. Kann ein unter macOS erstellter Passkey in Safari auf einem anderen Apple-Gerät verwendet werden?#

Ja, aber nur, wenn der Passkey im iCloud-Schlüsselbund gespeichert ist. Unter macOS nutzt Brave den WebAuthn-Stack von Chromium und kann einen neuen Passkey entweder im Apple-Plattform-Authenticator speichern oder in einem anderen Speicherziel, das im Erstellungsdialog präsentiert wird. Ein im iCloud-Schlüsselbund gespeicherter Passkey synchronisiert sich über die Apple-ID und ist in Safari, Chrome und anderen WebAuthn-fähigen Browsern auf Apple-Geräten verfügbar, die dieselbe Apple-ID verwenden.

Sobald macOS bestätigt, dass Brave auf den iCloud-Schlüsselbund zugreifen darf, kann der Browser dieselben synchronisierten Passkeys verwenden, die auch Safari sieht. Diese Berechtigungsabfrage ist der praktische Moment, in dem die browserübergreifende Portabilität auf Apple-Geräten real und nicht nur theoretisch wird.

Brave auf macOS kann auch an geräteübergreifenden Authentifizierungsflows teilnehmen. Wenn der Benutzer den Bluetooth-Zugriff gestattet, kann Brave während der CDA nahegelegene Geräte erkennen und mit ihnen kommunizieren, was die telefonbasierte Passkey-Freigabe über den Desktop-Browser weitgehend nahtlos macht.

Ein Passkey, der in einem Browser-Profil-Speicher oder einem rein lokalen Speicher gesichert wurde, steht in Safari auf einem anderen Apple-Gerät nicht automatisch zur Verfügung. Dieser Unterschied ist entscheidend, da die Synchronisation von Plattform-Authenticatoren auf Betriebssystemebene und die Synchronisation von Browser-Profilen unterschiedlichen Regeln folgen. Brave bietet nicht die Passkey-Synchronisation von Chrome über den Google Passwortmanager an, sodass nur der Weg über den iCloud-Schlüsselbund die Apple-typische browserübergreifende Portabilität auf Apple-Geräten ermöglicht.

4. Warum funktionieren Passkeys auf Android ohne Google Play-Dienste nicht zuverlässig?#

Der Android Credential Manager ist selbst nicht Teil der Google Play-Dienste. Auf Android 14 und neueren Versionen kann Chromium den System-Pfad des Credential Managers nutzen, während ältere Android-Versionen stärker von der durch Google Play-Dienste unterstützten FIDO2-Schicht abhängen. In der Praxis erbt Brave weiterhin den Fehler, der im Issue #45415 dokumentiert ist: Unter GrapheneOS, CalyxOS, /e/OS und anderen de-Googled Android-Builds ohne den erforderlichen Play-Dienste-Pfad kann die Registrierung und Authentifizierung von Passkeys in ein Timeout laufen. Mit Stand April 2026 blieb dies eine offene Kompatibilitätslücke für datenschutzbewusste Android-Nutzer.

Dieses Verhalten ist im brave/brave-browser Issue #45415 dokumentiert, das im April 2025 eröffnet wurde und ein Jahr später immer noch offen war. Googles Credential Manager-Dokumentation unterscheidet die Credential Manager-API von der optionalen Authentifizierungsabhängigkeit der Play-Dienste, die auf älteren Android-Versionen verwendet wird, und der umfassendere Android-Leitfaden weist darauf hin, dass Android 14+ mit aktivierten Passwort-Managern funktionieren kann. Der Thread merkt auch an, dass derselbe Fehlermodus Chromium-basierte Browser allgemein betrifft, während Firefox-basierte Browser davon nicht auf die gleiche Weise betroffen sind. Der ursprüngliche Melder wies darauf hin, dass GrapheneOS die Abhängigkeit in seinem eigenen Chromium-Fork Vanadium gepatcht hat, sodass ein Downstream-Fix technisch möglich erscheint – er ist nur noch nicht passiert.

Mehrere Nutzer haben das Verhalten in diesem Thread unabhängig voneinander bestätigt. Ein besonders sauberer Test im Dezember 2025 nutzte dasselbe Gerät mit zwei Profilen: Passkeys funktionierten in Brave nur auf dem Profil mit aktivierten Play-Diensten, während Vanadium und Cromite auf beiden funktionierten. Mit Stand April 2026 hatte kein Brave-Maintainer in diesem Thread geantwortet. Für die datenschutzbewusste Android-Zielgruppe von Brave – die einen überproportional hohen Anteil an de-Googled Nutzern umfasst – hinterlässt dies eine sehr sichtbare Lücke. Firefox unter Android nutzt seinen eigenen WebAuthn-Stack und ist nicht auf dieselbe Weise von den Play-Diensten abhängig. Heute besteht der praktische Workaround darin, Firefox für Passkey-Flows auf Android ohne Play-Dienste zu verwenden oder auf einen Hardware-Sicherheitsschlüssel mit einem kompatiblen Client zurückzugreifen. Für einen breiteren Überblick über Fehler unter Android siehe Fehler bei Passkeys in nativen Apps. Spezifische Informationen zu Google Play-Diensten und dem Credential Manager finden Sie unter Passkey-Fehlercodes für Android und Google Play-Dienste.

5. Warum erscheinen Windows Hello-Passkey-Aufforderungen, selbst wenn ich sie deaktiviere?#

Das Deaktivieren der Brave-Einstellung zum Anbieten der Speicherung von Passkeys verhindert nicht, dass Windows Hello bei WebAuthn-Flows angezeigt wird. Sobald eine Website WebAuthn aufruft und Windows Hello eingerichtet ist, bewirbt Windows Hello als Plattform-Authenticator, und Brave bietet keine nutzerseitige Einstellung, die dies blockiert. Bis Januar 2026 blieb die Unterdrückung von Windows Hello ungelöst für Nutzer, die Hello zum Entsperren des Geräts, aber nicht für Passkeys verwenden wollten.

Issue #51858, eröffnet im Januar 2026, und der längere Community-Thread 646042 beschreiben dasselbe Problem. Der ursprüngliche Melder versuchte Änderungen in der Registry, an Gruppenrichtlinien, Flag-Einstellungen und führte Neuinstallationen durch – nichts davon änderte das Verhalten.

Der technische Grund, der im Thread 646042 beschrieben wird, ist simpel: Die Einstellungen des Passwort-Managers des Browsers steuern das browser-eigene Autofill-Verhalten, nicht die WebAuthn-Grenze zwischen der Seite und dem Betriebssystem. Windows bietet Hello unabhängig davon an, und in der Diskussion wurde keine dokumentierte, unterstützte Konfiguration gefunden, die Windows Hello zum Entsperren von Geräten beibehält, es aber als WebAuthn-Plattform-Authenticator vollständig blockiert.

Heute besteht der einzige zuverlässige Weg, diese Aufforderungen zu unterdrücken, darin, die Einrichtung von Windows Hello komplett zu deaktivieren, was natürlich im Widerspruch dazu steht, wie die meisten Menschen ihr Gerät entsperren möchten. Edge verhält sich anders, da es enger in die Verwaltung von Anmeldeinformationen von Windows integriert ist und Einstellungen bietet, über die Chromium-Forks derzeit nicht verfügen. Einen umfassenderen Einblick in das Passkey-Verhalten von Windows finden Sie unter Passkeys in Windows 11.

6. Sollten Sie Passkeys nativ oder in Ihrem Passwort-Manager speichern?#

Die native Speicherung von Passkeys ist die einfachste Option innerhalb eines einzelnen Ökosystems, während Passwort-Manager-Erweiterungen weiterhin die einzige allgemein funktionierende plattformübergreifende Synchronisationsschicht bleiben. Der iCloud-Schlüsselbund funktioniert gut über Apple-Geräte hinweg, Windows Hello funktioniert unter Windows und erweiterungsbasierte Tresore wie 1Password oder Bitwarden sind immer noch die einzige realistische Option für Benutzer, die möchten, dass Passkeys konsistent über Windows, macOS, Linux und Android hinweg nativ verfügbar sind. Die geräteübergreifende Authentifizierung (CDA oder hybrider Transport über QR-Code und Bluetooth) kann Geräte beim Anmelden zwar überbrücken, synchronisiert jedoch nicht die Anmeldeinformationen an sich oder macht sie standardmäßig überall lokal verfügbar. Der Kompromiss liegt in der Zuverlässigkeit: Native Flows sind einfacher, auf Erweiterungen basierende Flows sind portabler, und CDA versteht man am besten als Ausweichlösung und nicht als Speicherstrategie.

Die Entscheidung hängt hauptsächlich von drei Dingen ab: wie viele Plattformen Sie nutzen, wie sehr Sie den Flows von Erweiterungen vertrauen und wo Sie Ihre Anmeldeinformationen bereits aufbewahren. Wenn Sie sich hauptsächlich innerhalb eines Betriebssystem-Ökosystems aufhalten – alles Apple oder alles Windows –, ist der Weg über den nativen Plattform-Authenticator die sauberste Option. In diesem Setup verhält sich Brave sehr ähnlich wie Chrome oder Safari. Wenn Sie Passkeys benötigen, die Sie konsistent über Windows, macOS, Linux und Android hinweg begleiten, ist eine Drittanbieter-Passwort-Manager-Erweiterung wie 1Password, Bitwarden, Dashlane oder Proton Pass immer noch die einzige breit funktionierende Synchronisationsschicht.

Die Komplikation besteht darin, dass seit April 2024 immer wieder Berichte auftauchen, dass die native Passkey-Benutzeroberfläche sporadisch die von der Erweiterung gesteuerten Flows kapert. Nutzer in Issue #37762 berichten von der Anzeige von OS-Authentifizierungsdialogen, obwohl Bitwarden oder 1Password die Anmeldeinformationen besitzen sollten. Bis März 2026 stand der alte Workaround – das Deaktivieren von brave://flags/#web-authentication-new-passkey-ui – nicht mehr zur Verfügung, da das Flag in Version 146 entfernt worden war.

In der Praxis besteht das Muster, bei dem viele datenschutzbewusste Nutzer im Jahr 2026 landen, aus einem hybriden Ansatz: Verwenden Sie den OS-Plattform-Authenticator für alltägliche Anmeldungen innerhalb eines Ökosystems, nutzen Sie eine Passwort-Manager-Erweiterung, wo plattformübergreifende Portabilität wichtig ist, und halten Sie für hochkarätige Konten einen Hardware-Sicherheitsschlüssel bereit.

7. Welche Passkey-Problempunkte melden Benutzer im Jahr 2026?#

Die offenen Passkey-Issues von Brave im Jahr 2026 konzentrieren sich auf drei wiederkehrende Themen: das Abfangen durch Erweiterungen, Fehler unter Android auf de-Googled Geräten und Probleme mit Sicherheitsschlüsseln auf dem Desktop. Mit Stand April 2026 zeigte das gesamte Repository noch 24 offene Issues, die zu webauthn oder passkey passten, was darauf hindeutet, dass die Reibungspunkte konzentriert und nicht zufällig auftreten.

Das aktivste Feld ist das Abfangen durch Erweiterungen, bei dem die native Passkey-Benutzeroberfläche Eingabeaufforderungen von 1Password, Bitwarden oder Dashlane überschreiben kann. Android-Kompatibilität ohne Google Play-Dienste ist das zweite wiederkehrende Problem, und die Erkennung von Sicherheitsschlüsseln auf dem Desktop ist das dritte. Die hier am häufigsten zitierten Issue-Threads sind #37762, #50561, #45415, #15650, #43043, #34441, #33237 und #51858. Die aktiven Threads deuten alle in dieselbe Richtung, ohne dass viele direkte Zitate erforderlich wären.

Einige dieser Issues erhielten in den letzten 90 Tagen neue Kommentare, was sie zu aktiven Regressionen und nicht zu historischen Kuriositäten macht. Für Entwickler, die Passkey-Flows erstellen, ist die Schlussfolgerung eindeutig: Testen Sie von Erweiterungen gesteuerte Flows ausdrücklich in Brave und bieten Sie sinnvolle Fallbacks an, wenn WebAuthn-Aufrufe fehlschlagen. Für Nutzer ist die Lektion ebenso praktisch: Halten Sie einen Hardware-Sicherheitsschlüssel oder einen anderen Wiederherstellungsfaktor für wichtige Konten bereit.

8. Fazit#

Die Geschichte von Passkeys in Brave ist auf Code-Ebene sauber und auf der Ebene der Benutzererfahrung etwas chaotisch. Der WebAuthn-Pfad entspricht im Wesentlichen dem von Chromium, wobei nur eine einzige Textänderung bestätigt, wie nah die Implementierung am Original bleibt. Auf Apple-Plattformen funktioniert die Portabilität von Passkeys genau so, wie Nutzer es erwarten, da der iCloud-Schlüsselbund die Anmeldeinformationen verwaltet. Die eigentliche Reibung tritt anderswo auf: Abfangen durch Erweiterungen (#37762), Unterdrückung von Windows Hello (#51858) und die Abhängigkeit von Google Play-Diensten unter Android (#45415). Bis diese Issues behoben sind, sollten Entwickler Brave separat testen, anstatt von einer Parität mit Chrome auszugehen, und Nutzer sollten für wichtige Konten auf einen starken Fallback setzen – idealerweise einen Hardware-Sicherheitsschlüssel.

9. Über Corbado#

Corbado entwickelt Passkey-Infrastrukturen für Consumer-Logins und bietet eine Passkey-Intelligence-Plattform für Teams, die Passkeys und Authentifizierungssysteme im großen Maßstab betreiben müssen. Wir veröffentlichen technische Analysen zum Verhalten von WebAuthn und Passkeys in Browsern und Betriebssystemen, basierend auf realen Implementierungen, direkter Quellcode-Inspektion und einer genauen Lektüre der zugrunde liegenden Spezifikationen. Fragen oder Korrekturen sind jederzeit willkommen.

10. Häufig gestellte Fragen (FAQ)#

10.1 Kann ein in Brave unter macOS erstellter Passkey in Safari auf einem anderen Apple-Gerät verwendet werden?#

Ja, aber nur, wenn Brave den Passkey im iCloud-Schlüsselbund speichert. Unter macOS verwendet Brave den WebAuthn-Stack von Chromium und kann einen neuen Passkey im iCloud-Schlüsselbund oder an einem anderen Speicherziel ablegen, das in der Erstellungsaufforderung angezeigt wird. Ein im iCloud-Schlüsselbund gespeicherter Passkey synchronisiert sich über die Apple-ID und wird in Safari, Chrome und anderen Browsern auf Apple-Geräten verfügbar, die dieselbe Apple-ID verwenden. Ein Passkey, der in einem Browser-Profil oder nur lokal gespeichert wird, steht in Safari auf einem anderen Apple-Gerät nicht automatisch zur Verfügung.

10.2 Warum schlagen Passkeys in Brave auf Android ohne Google Play-Dienste fehl?#

Brave unter Android kann ohne Google Play-Dienste fehlschlagen, aber der Grund ist spezifischer als "Credential Manager ist Teil der Play-Dienste". Der Credential Manager von Android ist eine System- und Jetpack-API, während ältere Android-Versionen stärker auf der FIDO2-Ebene basieren, die durch die Google Play-Dienste gestützt wird. In der Praxis erbt Brave weiterhin den Fehler, der in brave/brave-browser Issue #45415 dokumentiert ist: Unter GrapheneOS, CalyxOS oder anderen de-Googled Android-Builds ohne den benötigten Play-Dienste-Pfad öffnet sich der Passkey-Dialog nie und die Registrierung oder Authentifizierung läuft ins Timeout.

Weitere Informationen zur allgemeinen Android-Fehlerlandschaft finden Sie unter Fehler bei Passkeys in nativen Apps. Spezifische Details zu den Google Play-Diensten und dem Credential Manager finden Sie unter Passkey-Fehlercodes für Android und Google Play-Dienste.

10.3 Synchronisiert Brave Passkeys geräteübergreifend wie Chrome?#

Nein. Brave bietet kein Äquivalent zur Passkey-Synchronisation über den Google Passwortmanager in Chrome-Browserprofilen. Passkeys, die in Brave erstellt werden, werden im zugrunde liegenden OS-Plattform-Authenticator gespeichert – im iCloud-Schlüsselbund bei Apple, in Windows Hello bei Windows und im Android Credential Manager bei Android – und synchronisieren sich nur über das jeweilige OS-Konto. Wenn Sie eine konsistente geräteübergreifende Synchronisation wünschen, sind Sie auf den OS-Anbieter oder eine Drittanbieter-Passwort-Manager-Erweiterung angewiesen.

10.4 Warum fordert Brave Passkeys mit Windows Hello an, selbst wenn ich Passkey-Optionen in den Einstellungen deaktiviere?#

Der Umschalter brave://password-manager/settings in Brave steuert lediglich, ob Brave selbst die Speicherung von Passkeys anbietet. Er hindert Windows nicht daran, Windows Hello als WebAuthn-Plattform-Authenticator gegenüber der Webseite zu bewerben. Die Seite ruft WebAuthn auf, Windows präsentiert Hello und Brave hat keinen In-Browser-Schalter, um den Dialog des Betriebssystems zu unterdrücken. Das Verhalten wird in brave/brave-browser Issue #51858 nachverfolgt.

10.5 Sollte ich Passkeys im nativen Flow von Brave oder in meinem Passwort-Manager speichern?#

Nutzen Sie den nativen OS-Flow von Brave (iCloud-Schlüsselbund oder Google Passwortmanager über die Plattform), wenn Sie innerhalb eines Ökosystems bleiben und möglichst wenig bewegliche Teile haben möchten. Verwenden Sie eine Drittanbieter-Passwort-Manager-Erweiterung wie 1Password oder Bitwarden, wenn Sie möchten, dass Ihre Passkeys Sie konsistent über Windows, macOS, Linux und Android hinweg begleiten, oder wenn Sie Ihre Geheimnisse bereits dort verwalten. Seit 2024 hat die native Benutzeroberfläche von Brave wiederholt Passkey-Flows von Erweiterungen abgefangen, weshalb Sie überprüfen sollten, ob die Erweiterung immer noch die Aufforderung steuert.

10.6 Wie viele offene Passkey- und WebAuthn-Issues hat das Repository brave/brave-browser derzeit zum Thema Passkey-Verhalten in Brave?#

Mit Stand April 2026 gab es in brave/brave-browser 24 offene Issues, die bei der Suche nach passkey oder WebAuthn gefunden wurden. Die offenen, mit Passkey getaggten Issues stiegen von etwa 2 pro Jahr in 2022–2023 auf 6 neu eröffnete Issues im Jahr 2025. Bei Brave sind die dominanten Themen das Abfangen durch Erweiterungen auf dem Desktop, die Unterdrückung von Windows Hello und die Abhängigkeit von den Google Play-Diensten unter Android.

Über Corbado

Corbado ist die Authentication Intelligence Platform für CIAM-Teams, die Consumer-Authentifizierung im großen Maßstab betreiben. Wir zeigen Ihnen, was IDP-Logs und generische Analytics-Tools nicht sehen können: welche Geräte, OS-Versionen, Browser und Credential-Manager Passkeys unterstützen, warum Enrollments nicht zu Logins werden, wo der WebAuthn-Flow scheitert und wann ein OS- oder Browser-Update den Login still und leise unterbricht – und das alles, ohne Okta, Auth0, Ping, Cognito oder Ihren In-House-IDP zu ersetzen. Zwei Produkte: Corbado Observe ergänzt Observability für Passkeys und jede andere Login-Methode. Corbado Connect bringt Managed Passkeys mit integrierter Analytics (neben Ihrem IDP). VicRoads betreibt Passkeys für über 5 Mio. Nutzer mit Corbado (+80 % Passkey-Aktivierung). Mit einem Passkey-Experten sprechen →