Passkey-Fehlerbehebung: Lösungen für Passkey-Probleme & Fehler

1. Einführung#

Passkeys werden mittlerweile von 20 % der 100 weltweit führenden Websites unterstützt und 53 % der Verbraucher weltweit haben Passkeys bei mindestens einem Konto aktiviert, so das FIDO Alliance Authentication Barometer 2024. Amazon, WhatsApp, Coinbase, TikTok, Facebook, LinkedIn und X/Twitter haben alle seit 2023 Unterstützung dafür eingeführt.

Die W3C WebAuthn Level 3 Spezifikation definiert eine Reihe von DOM-Ausnahmen, aber Browser fassen die meisten Fehlschläge (Benutzerabbruch, Timeouts, ungeeignete Authenticatoren) absichtlich in dem generischen NotAllowedError zusammen, um Datenschutzlecks zu vermeiden, gemäß den W3C Privacy Considerations. Viele Relying Parties definieren zudem ihre eigenen Fehlermeldungen, da es abgesehen von den UX-Richtlinien der FIDO Alliance nicht viele bewährte Best Practices gibt. Dieser Leitfaden ordnet die häufigsten verbrauchergerichteten Formulierungen einer klaren Ursache und einer praktischen Lösung zu, versehen mit Screenshots sowohl vom ursprünglichen Release als auch von den neuesten iOS- und Android-Builds.

Wenn ein „google passkey funktioniert nicht“ auf Ihrem Gerät auftritt, ist die erste Prüfung, ob Browser, OS und Google Play-Dienste alle auf einem aktuellen Build sind, da die meisten Regressionen innerhalb von ein oder zwei Releases behoben werden.

2. Wie funktionieren Passkeys?#

Passkeys sind passwortlose Credentials, die auf der WebAuthn API und der zugrundeliegenden CTAP 2.2 Spezifikation der FIDO Alliance basieren. Das W3C standardisierte WebAuthn Level 1 im März 2019, Level 2 im April 2021 und Level 3 im Jahr 2024. Die Akzeptanz erreichte bis Q4 2024 rund 1 Milliarde registrierte Credentials über die großen Ökosysteme hinweg, gemäß FIDO Alliance Authenticate 2024.

Das Gerät generiert bei der Registrierung ein einzigartiges Schlüsselpaar. Nur der öffentliche Schlüssel wird an die Relying Party gesendet, während der private Schlüssel im Secure Enclave, TPM oder TEE verbleibt. Bei der Anmeldung sendet der Server eine Challenge, das Gerät entsperrt den privaten Schlüssel mit Face ID, Touch ID oder Windows Hello, signiert die Challenge und gibt die Signatur zurück. Die Relying Party verifiziert diese mit dem öffentlichen Schlüssel.

Da der private Schlüssel das Gerät nie verlässt, funktionieren Phishing und Passwort-Wiederverwendung nicht mehr als Angriffsvektoren. Aus Benutzersicht ist der gesamte Ablauf eine einzige biometrische Aufforderung.

3. Passkey-Anforderungen#

3.1 iOS oder macOS#

iCloud-Schlüsselbund aktiviert:

Der iCloud-Schlüsselbund ist der Speicherort für Credentials auf Apple-Geräten und ist auf iOS 16, iPadOS 16 und macOS Ventura 13 oder neuer verfügbar. Apple meldete Anfang 2024 rund 2,2 Milliarden aktive Geräte, von denen über 90 % unter iOS 16 oder neuer laufen, gemäß Apples Entwickler-Dashboard. Um den iCloud-Schlüsselbund zu aktivieren, navigieren Sie zu den Einstellungen Ihres Geräts, wählen Sie Ihre Apple-ID, gehen Sie zu iCloud und aktivieren Sie dann den iCloud-Schlüsselbund (mehr dazu lesen Sie hier). Laut Apples Entwickler-Dokumentation wird für iCloud-Konten mit aktiviertem Schlüsselbund die Verwendung von MFA erzwungen.

iOS 16 oder macOS Ventura erforderlich:

iOS 16 wurde am 12. September 2022 veröffentlicht und macOS Ventura 13 am 24. Oktober 2022. Unter iOS 18 wurde der Speicher in eine dedizierte Passwörter-App verlagert, weshalb einige Aufforderungen jetzt „Passwörter“ anstelle von „iCloud-Schlüsselbund“ lauten. Laut Apple Support können Benutzer mit älteren OS-Builds Passkeys überhaupt nicht erstellen oder verwenden.

3.2 Windows#

Windows Hello-Einrichtung:

Windows Hello ist erforderlich, um Passkeys auf Windows 10- und Windows 11-Geräten zu erstellen oder zu verwenden. Laut Microsofts Windows-Passkey-Dokumentation lieferte Windows 11 Build 22631 (November 2024) die native Passkey-UI aus, und Windows 11 25H2 (November 2025) fügte Unterstützung für Passkey-Manager von Drittanbietern wie 1Password und Bitwarden hinzu. Windows Hello akzeptiert einen Fingerabdruck, einen Gesichtsscan oder eine 6-stellige PIN. Konfigurieren Sie dies unter Einstellungen > Konten > Anmeldeoptionen (mehr dazu lesen Sie hier).

3.3 Android#

Android Version 9 oder neuer:

Android 9 (Pie) wurde am 6. August 2018 veröffentlicht und ist die Mindestvoraussetzung für die Credential Manager API. Laut dem Android Distribution Dashboard laufen Android 9 und neuer im Jahr 2026 auf rund 95 % der aktiven Android-Geräte. Ältere Builds können Passkeys überhaupt nicht verwenden, da ihnen der StrongBox Keymaster und der Credential Manager fehlen.

Google Play-Dienste aktualisiert:

Google Play-Dienste Version 23.40 oder neuer ist für den Credential Manager erforderlich. Google Play-Dienste werden ungefähr alle 4 bis 6 Wochen aktualisiert, und die meisten Probleme mit „google passkey funktioniert nicht“ lassen sich auf eine veraltete Version zurückführen. Aktualisieren Sie die Google Play-Dienste sowie die System-WebView unter Einstellungen > Apps und versuchen Sie es erneut.

Halten Sie auf allen Plattformen den Browser auf einem aktuellen Build. Safari, Chrome und Edge veröffentlichen etwa wöchentlich stabile Updates, und die meisten Regressionen werden innerhalb von ein oder zwei Releases behoben.

4. Häufige Passkey-Fehler, ihre Ursachen und Fehlerbehebung#

Wir verfolgen rund 15 wiederkehrende Fehlermuster auf iOS-, Android- und Windows-Clients, die zusammen den Großteil der Verbrauchersupport-Tickets ausmachen, die bei großen Relying Parties beobachtet werden. Die nächsten 6 Abschnitte gruppieren diese Fehler nach ihrer Grundursache: iCloud-Schlüsselbund und die Apple Passwörter-App, kein verfügbares Credential, QR-Code und geräteübergreifende Abläufe, Windows-spezifische Probleme, Android-spezifische Probleme und die generische WebAuthn- oder Browser-Kategorie.

Jeder Eintrag enthält Screenshots vom ursprünglichen Release sowie von den neuesten iOS-Builds und Android Credential Manager-Builds, die wahrscheinlichste Ursache und eine Lösung, die bei anderen funktioniert hat. Wo es nützlich ist, verweist der Eintrag auf die W3C WebAuthn Level 3 Spezifikation, die FIDO Alliance Spezifikationen oder die relevante Plattformdokumentation von Apple, Microsoft und dem Android Credential Manager.

5. Fehler des iCloud-Schlüsselbunds und der Apple Passwörter-App#

Diese Gruppe deckt die beiden Fehler ab, die Apple-Geräte anzeigen, wenn der iCloud-Schlüsselbund nicht korrekt eingerichtet ist. Beide werden vom System angezeigt, nicht von der Relying Party. Der iCloud-Schlüsselbund ist eine zwingende Voraussetzung für Passkeys auf iOS 16, iPadOS 16 oder macOS Ventura 13 und neuer, laut Apples Entwickler-Dokumentation. Unter iOS 18 wurde der Speicher in die neue Passwörter-App verlagert, weshalb sich der Wortlaut geändert hat.

Fehlermeldung: Um einen Passkey zu speichern, musst du den iCloud-Schlüsselbund aktivieren. Du kannst den Schlüsselbund in den Apple ID-Systemeinstellungen aktivieren#

Auf dem neuesten iOS lautet der Wortlaut „Um Passkeys zu verwenden, musst du den iCloud-Schlüsselbund aktivieren“ und der Pfad wurde umbenannt in Einstellungen > Apple Account > iCloud > Passwörter und Schlüsselbund:

• Ursache: Der iCloud-Schlüsselbund, der Speicherort für Credentials auf Apple-Geräten, ist nicht aktiviert.
• Lösung: Aktivieren Sie den iCloud-Schlüsselbund in den Apple ID-Systemeinstellungen (oder Einstellungen > Apple Account > iCloud > Passwörter und Schlüsselbund unter iOS 18). Stellen Sie sicher, dass er geräteübergreifend synchronisiert wird, da das Credential andernfalls nur lokal existiert.

Fehlermeldung: Es sind keine passenden Passkeys vorhanden / Es sind keine passenden Passkeys in deinem iCloud-Schlüsselbund gesichert#

Auf dem neuesten iOS ist die Aufforderung nun mit der neuen Passwörter-App versehen und lautet „Es sind keine passenden Passkeys in Passwörter gesichert für ...“:

• Ursache: Der Benutzer versucht sich mit einem Credential anzumelden, das nicht im iCloud-Schlüsselbund auf dem aktuellen Gerät gespeichert ist, oder die Synchronisierung zwischen Geräten ist defekt.
• Lösung: Bestätigen Sie, dass der iCloud-Schlüsselbund auf jedem Apple-Gerät aktiviert ist, das dieselbe Apple-ID verwendet. Wenn das Credential auf einem anderen iPhone oder Mac existiert, aber nicht auf dem aktuellen, erzwingen Sie eine Schlüsselbund-Synchronisierung, indem Sie den iCloud-Schlüsselbund aus- und wieder einschalten, und versuchen Sie die Anmeldung erneut. Wenn überhaupt kein Credential existiert, registrieren Sie ein neues in den Kontoeinstellungen der Relying Party.

6. Fehler „Kein Passkey verfügbar“ und „Existiert bereits“#

Diese Fehler treten auf, wenn das vom Benutzer erwartete Credential entweder nicht auf dem aktuellen Gerät vorhanden ist, bereits registriert wurde oder auf einer Seite gelöscht wurde und auf der anderen nicht. Die WebAuthn-Eigenschaften AllowCredentials und excludeCredentials steuern den Großteil dieses Verhaltens auf der Serverseite.

Fehlermeldung: Keine Passkeys verfügbar. Auf diesem Gerät gibt es keine Passkeys für Relying Party#

Unter Android wird derselbe Fehler durch die Google Play-Dienste mit „Keine Passkeys verfügbar. Auf diesem Gerät gibt es keine Passkeys für <Relying Party>“ und einem Fallback „Ein anderes Gerät verwenden“ ausgegeben:

• Ursache: Es befindet sich kein passendes Credential auf dem aktuellen Gerät und der WebAuthn-Server lässt keinen plattformübergreifenden Authenticator zu. Dieselbe Fehlermeldung erscheint auch, wenn der Benutzer das lokale Credential gelöscht hat, der Server es aber weiterhin erwartet.
• Lösung: Überprüfen Sie, ob auf dem Gerät ein Credential existiert. Wenn es im iCloud-Schlüsselbund oder in den Einstellungen des Google Passwortmanagers gelöscht wurde, entfernen Sie es auch serverseitig in den Kontoeinstellungen der Relying Party. Andernfalls fragt der Server weiterhin nach dem fehlenden Credential und der Fehler tritt immer wieder auf.

Fehlermeldung: Passkey existiert bereits (oder ähnliche Fehlermeldung, wie von der Relying Party definiert)#

• Ursache: Eine neue Registrierung wird auf einem Gerät versucht, das bereits ein Credential für dasselbe Konto hat. Viele Relying Parties erlauben nur ein Credential pro Gerät oder pro Ökosystem (z. B. synchronisierter iCloud-Schlüsselbund oder 1Password), indem sie excludeCredentials auf dem WebAuthn-Server setzen.
• Lösung: Verwenden Sie das vorhandene Credential oder registrieren Sie ein neues von einem anderen Gerät aus. Alternativ können Sie das alte Credential in den Kontoeinstellungen der Relying Party löschen und dann ein neues registrieren.

Fehlermeldung: Wir konnten keinen passenden Passkey finden (oder ähnliche Meldung von der Relying Party)#

• Ursache: Ein Credential wurde manuell gelöscht, entweder auf Client- oder Serverseite. Selbst wenn der lokale private Schlüssel noch existiert, löst das Fehlen des passenden öffentlichen Schlüssels auf dem Server diesen Fehler aus.
• Lösung: Melden Sie sich von einem anderen Gerät aus an oder verwenden Sie eine Fallback-Authentifizierungsmethode. Erstellen Sie dann ein neues Credential in den Kontoeinstellungen, wodurch das Client-Server-Paar wiederhergestellt wird.

7. Fehler bei QR-Code und geräteübergreifender Anmeldung#

Der QR-Code-Ablauf nutzt den FIDO Hybrid-Transport (auch CTAP 2.2 Hybrid genannt). Laut den FIDO CTAP-Spezifikationen tauschen die beiden Geräte über den QR-Code ein One-Time-Secret aus und kommunizieren dann über Bluetooth Low Energy bei einer maximalen Reichweite von ca. 3 Metern. Sowohl Bluetooth als auch räumliche Nähe sind erforderlich, andernfalls schlägt der Ablauf stillschweigend fehl.

Fehlermeldung: Ich sehe einen QR-Code#

Auf dem neuesten iOS lautet das Sheet für den geräteübergreifenden QR-Code nun „QR-Code scannen. Scanne diesen QR-Code mit einem kompatiblen Gerät, um dich bei ... anzumelden“:

Unter Android gibt der Credential Manager denselben Ablauf als „Keine verfügbare Anmeldung“ mit der Option QR-Code anzeigen und einem Fallback zum Öffnen des Google Passwortmanagers aus:

• Ursache: Das Credential ist an ein bestimmtes Konto und eine bestimmte Plattform (das Gerät oder ein Cloud-synchronisiertes Plattformkonto wie den iCloud-Schlüsselbund) gebunden. Das Sehen eines QR-Codes bedeutet, dass auf dem aktuellen Gerät kein Credential existiert, selbst wenn der Benutzer zuvor eines unter iOS oder Android registriert hat. Die andere häufige Ursache ist, dass der Server die akzeptierten Credentials über die WebAuthn-Eigenschaft AllowCredentials einschränkt und die verfügbaren lokalen Credentials nicht übereinstimmen.
• Lösung: Wenn das ursprüngliche Gerät über eine Kamera verfügt, scannen Sie den QR-Code, um sich über den Hybrid-Transport anzumelden. Andernfalls verwenden Sie eine Fallback-Methode, melden sich an und registrieren dann ein neues Credential für das aktuelle Gerät in den Kontoeinstellungen der Relying Party.

Fehlermeldung: Bluetooth erforderlich für die geräteübergreifende Passkey-Anmeldung#

• Ursache: Der Hybrid-Transport erfordert Bluetooth Low Energy zwischen den beiden Geräten. Wenn Bluetooth auf dem PC oder auf dem Telefon ausgeschaltet ist, schlägt der Ablauf ohne Vorwarnung mit generischen Meldungen wie „Etwas ist schiefgelaufen“ oder „Wir konnten Sie nicht anmelden“ fehl.
• Lösung: Aktivieren Sie Bluetooth auf beiden Geräten und halten Sie diese innerhalb von etwa 3 Metern voneinander entfernt. Versuchen Sie dann den QR-Ablauf erneut. Wenn sich Bluetooth nicht einschalten lässt (z. B. Unternehmensrichtlinie oder ältere Hardware), verwenden Sie eine Fallback-Anmeldung und registrieren Sie dann ein gerätelokales Credential, sodass zukünftige Anmeldungen nicht mehr vom Hybrid-Transport abhängen.

8. Windows-spezifische Fehler#

Windows-Builds haben in den letzten 18 Monaten einige Passkey-bezogene Regressionen ausgeliefert. Laut der Microsoft Windows-Passkey-Dokumentation fügte Build 22631 (November 2024) die native Passkey-UI hinzu und Windows 11 25H2 (November 2025) fügte die Unterstützung für Passkey-Manager von Drittanbietern hinzu. Beide Umstellungen setzten einige Windows Hello-Zustände zurück.

Fehlermeldung: Stecken Sie Ihren Sicherheitsschlüssel in den USB-Anschluss#

• Ursache: Ein Hardware-Sicherheitsschlüssel (z. B. YubiKey) ist erforderlich, da das Gerät kein TPM hat oder Windows Hello deaktiviert ist. Dieselbe Aufforderung erscheint auch auf Maschinen ohne Bluetooth, die den Hybrid-Transport nicht nutzen können und kein lokales Credential haben.
• Lösung: Stecken Sie den Sicherheitsschlüssel (z. B. YubiKey) in den USB-Anschluss. Um den Hardware-Schlüssel zu umgehen, aktivieren Sie zunächst Windows Hello und erstellen Sie dann vor der nächsten Anmeldung ein Windows Hello-Credential.

Fehlermeldung: Passkey für das Microsoft-Konto schlägt nach dem letzten Windows-Update immer wieder fehl#

• Ursache: Mehrere Windows 11 Insider- und Release-Builds haben fehlerhafte Anmeldeabläufe für das Microsoft-Konto verursacht, die als „Etwas ist schiefgelaufen“, „Wir konnten Sie nicht anmelden“ oder als stiller Fehler bei der Erstellung auftreten. Die Grundursache ist meist ein beschädigter Windows Hello-Status oder ein Microsoft-Konto, das ursprünglich mit einem älteren Setup konfiguriert wurde.
• Lösung: Melden Sie sich mit Passwort plus MFA an, entfernen Sie das defekte Credential in den Sicherheitseinstellungen des Microsoft-Kontos und erstellen Sie ein neues. Bei einem lokalen Konto sichern und löschen Sie den Windows Hello NGC-Ordner (C:\Windows\ServiceProfiles\LocalService\AppData\Local\Microsoft\Ngc) und registrieren Sie dann Windows Hello neu. Betrachten Sie die Anmeldung mit dem Microsoft-Konto unter Windows als Best-Effort und halten Sie immer mindestens eine Nicht-Passkey-MFA-Option aktiv.

9. Android-spezifische Fehler#

Die Android Credential Manager API erfordert Google Play-Dienste 23.40 oder neuer und verlässt sich auf den sicheren Sperrbildschirm zur Benutzerverifizierung, laut der Android Credential Manager-Dokumentation. Geräte ohne Bildschirmsperre können Credentials überhaupt nicht registrieren oder verwenden.

Fehlermeldung: Passkeys nicht angeboten#

• Ursache: Auf dem Android-Gerät ist keine Bildschirmsperre aktiviert. Android erfordert eine PIN, ein Muster, ein Passwort oder eine biometrische Sperre, um den Zugriff auf das Credential zu regeln. Ohne eine Sperre wird die Option ausgeblendet.
• Lösung: Aktivieren Sie die Bildschirmsperre unter Einstellungen > Sicherheit auf dem Gerät und versuchen Sie es dann erneut. Bestätigen Sie auf älteren Android-Builds außerdem, dass die Google Play-Dienste auf dem neuesten Stand sind.

10. Generische WebAuthn- und Browser-Fehler#

Diese Fehler kommen direkt vom Browser oder der WebAuthn-Schicht. Sie sind absichtlich generisch gehalten, um die Privatsphäre der Benutzer zu schützen. Browser exponieren laut W3C-Spezifikation zwischen 10 und 14 verschiedene DOM-Ausnahmen während eines Vorgangs, und die häufigste (NotAllowedError) fasst Abbruch, Timeout und stille Plattformverweigerung in einer einzigen Kategorie zusammen.

Fehlermeldung: Passkey konnte nicht erstellt werden / Fehler beim Erstellen des Passkeys / Fehler beim Generieren des Passkeys#

• Ursache: Ein Fehler in der App der Relying Party, ein temporäres Serverproblem oder inkompatible Geräteeinstellungen (z. B. ein altes Betriebssystem ohne WebAuthn-Unterstützung).
• Lösung: Starten Sie die App oder das Gerät neu und versuchen Sie es erneut. Wenn das Problem weiterhin besteht, aktualisieren Sie das Betriebssystem und den Browser. Wenn nur eine Relying Party betroffen ist, liegt das Problem auf der Serverseite und ein erneuter Versuch nach einigen Minuten löst es normalerweise.

Fehlermeldung: Passkeys sind auf diesem Gerät oder in diesem Browser nicht verfügbar#

• Ursache: Der Browser oder das Betriebssystem unterstützt WebAuthn nicht, oder die Relying Party (z. B. PayPal) blockiert die aktuelle Kombination. Häufige Beispiele sind alte Browser-Builds, Nischenbrowser ohne WebAuthn-Unterstützung oder von Unternehmen verwaltete Geräte mit restriktiven Richtlinien.
• Lösung: Aktualisieren Sie den Browser und das Betriebssystem. Wenn das Gerät grundsätzlich inkompatibel ist, wechseln Sie zu einem unterstützten Gerät (Safari auf iOS 16+, Chrome auf Android 9+, Edge oder Chrome auf Windows 10+).

Fehlermeldung: Etwas ist schiefgelaufen. Es gab ein Problem bei der Anmeldung mit deinem Passkey.#

• Ursache: Falsches Credential ausgewählt, ein vorübergehender Netzwerkfehler zwischen dem Gerät und dem Server oder eine Fehlfunktion in der WebAuthn-Schicht des Browsers.
• Lösung: Bestätigen Sie, dass das richtige Credential aus der Eingabeaufforderung ausgewählt wurde. Versuchen Sie es nach einer kurzen Wartezeit erneut. Wenn das Problem weiterhin besteht, überprüfen Sie das Netzwerk und setzen Sie das Credential zurück, indem Sie es aus den Kontoeinstellungen neu registrieren.

Fehlermeldung: Etwas ist schiefgelaufen. Zeitüberschreitung bei der Anforderung.#

• Ursache: Der Server hat zu lange gebraucht, um zu antworten, meist aufgrund von Netzwerkinstabilität oder hoher Auslastung. Das Standard-WebAuthn-Timeout in Chrome beträgt 60 Sekunden, wobei ein Maximum von 600 Sekunden durch die W3C-Spezifikation definiert ist.
• Lösung: Versuchen Sie es über eine stabile Verbindung erneut. Wenn die Verbindung in Ordnung ist, liegt das Problem auf der Serverseite, und ein erneuter Versuch nach einigen Minuten behebt es normalerweise. Relying Parties können das Timeout auf das W3C-Limit erhöhen, wenn ihr Backend den Standardwert regelmäßig überschreitet.

Fehlermeldung: NotAllowedError. Die Operation hat entweder das Zeitlimit überschritten oder war nicht erlaubt#

• Ursache: Der generische WebAuthn-Fehler, der von Browsern zurückgegeben wird, wenn ein Vorgang nicht abgeschlossen wird. Er kann einen Benutzerabbruch, ein Timeout, einen blockierten Ursprung, eine fehlende Benutzeraktion oder einen Plattform-Authenticator bedeuten, der die Anfrage abgelehnt hat. Der Browser verbirgt die genaue Ursache aus Datenschutzgründen.
• Lösung: Erhöhen Sie das WebAuthn-Timeout auf der Seite der Relying Party und stellen Sie sicher, dass der Aufruf durch eine direkte Benutzeraktion wie einen Klick auf einen Button ausgelöst wird. Überprüfen Sie, ob die Relying Party ID mit dem Ursprung (Origin) übereinstimmt, ob der Benutzer über einen nutzbaren Authenticator verfügt und ob keine Browser-Erweiterung den Aufruf abfängt. Endnutzer können das Problem meist beheben, indem sie das Gerät entsperren, die biometrische Abfrage oder PIN bestätigen und es erneut versuchen.

11. Fazit#

Passkeys beseitigen die Kategorie der Passwort-Schwachstellen, indem sie geteilte Geheimnisse durch Public-Key-Kryptographie ersetzen. Bereitstellungen in der Praxis berichten von einer 4- bis 6-mal schnelleren Anmeldung im Vergleich zu Passwort plus OTP, wobei Verizons Data Breach Investigations Report 2024 68 % der Datenpannen auf ein nicht böswilliges menschliches Element zurückführt, einschließlich Credential-Missbrauch. Die Verringerung dieser Angriffsfläche ist der eigentliche Sinn und Zweck.

In der Praxis machen die 15 oben genannten Fehler den Großteil der Verbrauchersupport-Tickets aus, die wir in der Passkeys-Community sehen, und die richtige Fehlerbehebung ist für eine breitere Passkey-Adoption unerlässlich. Das Befolgen von Best Practices für die Erstellung und Best Practices für die Anmeldung reduziert Fehlerraten erheblich. Um über Fehlerbehandlung und Rollout-Details auf dem Laufenden zu bleiben, abonnieren Sie den Passkeys Substack oder treten Sie der Community auf Slack bei.

Über Corbado

Corbado ist die Passkey 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 →

Häufig gestellte Fragen#

Warum werde ich aufgefordert, einen Sicherheitsschlüssel einzustecken, anstatt meinen Passkey zu verwenden?#

Diese Aufforderung wird angezeigt, wenn Windows Hello deaktiviert ist oder kein TPM verfügbar ist, wodurch das System auf die Authentifizierung mit einem Hardware-Sicherheitsschlüssel zurückgreift. Dies lässt sich beheben, indem Windows Hello in den Anmeldeoptionen Ihres Geräts aktiviert wird, Sie müssen jedoch zunächst einen Windows Hello-Passkey erstellen, bevor Sie diesen für die Anmeldung nutzen können.

Wie behebe ich den Fehler „Passkey konnte nicht erstellt werden“?#

Dieser Fehler resultiert typischerweise aus einem Anwendungsfehler, einem temporären Serverproblem oder inkompatiblen Geräteeinstellungen. Ein Neustart der Anwendung oder des Geräts sowie das Überprüfen auf OS- und App-Updates beheben das Problem meist. Wenn das Problem serverseitig auftritt, wird empfohlen, zu warten und es später erneut zu versuchen.

Warum kommt es bei der Passkey-Authentifizierung immer wieder zu Timeouts?#

Timeout-Fehler treten auf, wenn der Server zu lange für eine Antwort benötigt, meist aufgrund von Netzwerkinstabilität oder hoher Serverauslastung. Die Überprüfung Ihrer Internetverbindung ist der erste Schritt. Wenn die Verbindung stabil ist, liegt das Problem wahrscheinlich auf der Serverseite, und ein erneuter Versuch nach einer kurzen Wartezeit sollte es beheben.

Was passiert, wenn ich meinen Passkey auf meinem Gerät lösche, aber nicht in den Kontoeinstellungen?#

Das clientseitige Löschen eines Passkeys, beispielsweise aus dem iCloud-Schlüsselbund oder dem Google Passwortmanager, ohne ihn auch in den Kontoeinstellungen der Relying Party zu entfernen, führt zu Fehlern der Art „kein passender Passkey“. Der Server hält weiterhin den öffentlichen Schlüssel und erwartet das Credential, daher ist sowohl ein clientseitiges als auch ein serverseitiges Löschen erforderlich, bevor ein neuer Passkey registriert wird.

Was bedeutet NotAllowedError bei der Verwendung eines Passkeys?#

NotAllowedError ist der allgemeine WebAuthn-Fehler, den Browser zurückgeben, wenn ein Passkey-Vorgang nicht abgeschlossen wurde. Er kann einen Abbruch durch den Benutzer, ein Timeout, eine fehlende Benutzeraktion, einen blockierten Ursprung oder einen Plattform-Authenticator bedeuten, der die Anfrage abgelehnt hat. Browser verbergen die genaue Ursache aus Datenschutzgründen. Den Vorgang nach einer direkten Benutzeraktion erneut zu versuchen und Biometrie oder PIN zu bestätigen, löst das Problem in der Regel.

Warum zeigt iOS „Es sind keine passenden Passkeys in Passwörter gesichert“ an?#

Unter iOS 18 und neuer ist der Speicherort in die neue Passwörter-App umgezogen, wodurch sich der Wortlaut von „iCloud-Schlüsselbund“ zu „Passwörter“ geändert hat. Der Fehler bedeutet, dass das Credential auf diesem Gerät fehlt oder die iCloud-Synchronisierung nicht aktiv ist. Stellen Sie sicher, dass der iCloud-Schlüsselbund auf jedem Apple-Gerät aktiviert ist, das dieselbe Apple-ID verwendet, erzwingen Sie eine Synchronisierung, indem Sie den iCloud-Schlüsselbund aus- und wieder einschalten, und versuchen Sie die Anmeldung erneut. Wenn überhaupt kein Credential existiert, registrieren Sie ein neues in den Kontoeinstellungen der Relying Party.

Warum zeigt Android „Keine verfügbare Anmeldung für die Relying Party“ an?#

Der Android Credential Manager zeigt diese Aufforderung an, wenn für die angefragte Relying Party auf dem aktuellen Gerät kein passendes Credential gespeichert ist. Es wird typischerweise die Option „QR-Code anzeigen“ angeboten, um einen Passkey von einem anderen Gerät über den FIDO Hybrid-Transport zu nutzen, sowie ein Fallback, um den Google Passwortmanager zu öffnen. Scannen Sie entweder den QR-Code mit einem Smartphone, auf dem sich das Credential bereits befindet, melden Sie sich mit einer Fallback-Methode an oder registrieren Sie in den Kontoeinstellungen der Relying Party ein neues Credential auf dem aktuellen Gerät.

Wie funktioniert der geräteübergreifende Passkey-QR-Code-Ablauf?#

Der geräteübergreifende Ablauf ist der in CTAP 2.2 definierte FIDO Hybrid-Transport. Der Desktop-Browser zeigt einen QR-Code, der ein One-Time-Secret enthält. Ein Smartphone scannt ihn mit der Kamera und stellt dann eine Rückverbindung über Bluetooth Low Energy bei einer maximalen Reichweite von ca. 3 Metern her. Nachdem sich der Benutzer auf dem Smartphone verifiziert hat, wird der WebAuthn-Vorgang auf dem Desktop abgeschlossen. Sowohl Bluetooth als auch räumliche Nähe sind erforderlich, andernfalls schlägt der Ablauf ohne Vorwarnung mit generischen Meldungen wie „Etwas ist schiefgelaufen“ oder „Wir konnten Sie nicht anmelden“ fehl.