Passkeys: Anmeldung ohne Passwort und sichere Kontowiederherstellung

Passkeys ermöglichen die Anmeldung ohne Passwort in einer Webanwendung. Der Nutzer bestätigt die Anmeldung mit Fingerabdruck, Gesicht oder der PIN seines Geräts, und der Server speichert statt eines Passworts einen öffentlichen Schlüssel. Für ein Unternehmen mit Kundenportal oder interner Anwendung ist der wichtigste Vorteil der Schutz vor Phishing, nicht nur der Komfort.

Ein Button „Passkey erstellen“ allein reicht jedoch nicht. Über das Ergebnis entscheiden die richtig gewählte Domain, eine sichere Registrierung, die Geräteverwaltung und vor allem die Kontowiederherstellung, die nicht die schwächste Stelle bleiben darf. Unten finden Sie ein Beispiel zur Veranschaulichung, ein Vorgehen für die Einführung, eine Entscheidungstabelle, häufige Fehler und eine Checkliste.

Was Passkeys lösen und was nicht

Ein Passkey ist ein kryptografisches Schlüsselpaar. Der private Schlüssel bleibt beim Passkey-Anbieter des Nutzers, also auf dem Smartphone, dem Computer, in einem Passwortmanager oder in einem Hardware-Sicherheitsschlüssel. Ihre Anwendung speichert den öffentlichen Schlüssel. Bei der Anmeldung signiert das Gerät die Challenge des Servers erst nach Bestätigung durch den Nutzer, in der Regel durch Entsperren des Geräts. Die technische Grundlage bildet der Standard W3C Web Authentication (WebAuthn) Level 3, der seit dem 25. August 2026 eine W3C-Empfehlung ist.

Der entscheidende Vorteil ist die Phishing-Resistenz. Laut WebAuthn-Standard lässt sich ein Passkey nur bei derselben Partei (RP ID, in der Regel eine Domain) verwenden, für die er registriert wurde. Die Entwicklerdokumentation von Google ergänzt, dass Nutzer nicht dazu verleitet werden können, sich auf einer betrügerischen Website anzumelden, weil Browser oder Betriebssystem die Überprüfung übernehmen.

Die US-Richtlinie NIST SP 800-63B hält ausdrücklich fest, dass Verfahren, bei denen der Nutzer einen Code manuell eintippt, etwa Einmalcodes per SMS oder aus einer App, nicht phishing-resistent sind: Eine betrügerische Website kann den Code an den echten Dienst weiterleiten. WebAuthn nennt sie dagegen als Beispiel für einen phishing-resistenten Standard. Einem Unternehmen im deutschsprachigen Raum schreibt diese Richtlinie nichts vor, sie ist aber eine gut dokumentierte Referenz.

Passkeys lösen weder falsch eingestellte Berechtigungen nach der Anmeldung noch eine gestohlene Sitzung oder eine schwache Kontowiederherstellung. Wenn ein Angreifer den Support überredet, ihm „den Zugang wiederherzustellen“, hilft keine Kryptografie. Deshalb widmen wir der Wiederherstellung einen eigenen Abschnitt.

Synchronisierte und gerätegebundene Passkeys

WebAuthn unterscheidet zwei Arten von Anmeldedaten. Ihre Eigenschaften bestimmen direkt, wie Sie die Kontowiederherstellung gestalten.

Typ	Verhalten	Folge für die Anwendung
Synchronisierter Passkey (multi-device credential)	Der Passkey-Anbieter kann ihn sichern und auf weiteren Geräten des Nutzers bereitstellen.	Der Verlust eines Geräts bedeutet meist nicht den Verlust des Zugangs. Auf der höchsten NIST-Stufe AAL3 dürfen synchronisierte Authentifikatoren jedoch nicht verwendet werden.
Gerätegebundener Passkey (single-device credential)	Er wird nie gesichert, zum Beispiel ein Passkey auf einem Hardware-Sicherheitsschlüssel.	Laut WebAuthn ist er nicht gegen Geräteverlust gewappnet, daher sollte das Konto einen weiteren Authentifikator oder einen Wiederherstellungsprozess haben.

Die Anwendung erkennt den Typ an den Flags BE (backup eligibility) und BS (backup state) in den Daten, die das Gerät zurückgibt. Der WebAuthn-Standard empfiehlt, ihre jeweils letzten Werte beim Konto zu speichern. Wechselt BS von 1 auf 0, ist der Passkey nicht mehr gesichert, und die Anwendung sollte den Nutzer durch die Überprüfung seiner übrigen Anmeldemethoden führen oder ihn eine weitere hinzufügen lassen.

Beispiel: Passkeys im B2B-Portal eines Großhändlers

Beispiel zur Veranschaulichung, kein echter Kunde. Ein Großhändler betreibt unter portal.example.com ein Portal, in dem Abnehmer Bestellungen aufgeben und Rechnungen herunterladen. Die Mitarbeiter arbeiten in der Verwaltung unter admin.example.com. Heute melden sich alle mit Passwort an und bei sensiblen Aktionen zusätzlich mit einem SMS-Code.

Die Einführung könnte in drei Phasen ablaufen:

Angebot nach der Anmeldung. Nach der Anmeldung und einer Bestätigung per E-Mail bietet das Portal an, einen Passkey zu erstellen. Das Passwort bleibt vorerst als Rückfalloption.
Passkey als Standardoption. Das Anmeldeformular bietet den gespeicherten Passkey direkt in den Vorschlägen des Browsers an. Wer keinen Passkey hat, meldet sich wie bisher an.
Pflicht für Administratoren. Mitarbeiter mit Zugriff auf Preislisten und Kundendaten müssen zwei registrierte Authentifikatoren haben, zum Beispiel einen Passkey auf dem Notebook und einen Hardware-Schlüssel im Tresor.

Sollen Passkeys auf beiden Subdomains funktionieren, setzt der Großhändler die RP ID auf example.com. Laut Leitfaden von web.dev kann sich der Nutzer bei der RP ID example.com auf login.example.com und auf weiteren Subdomains von example.com anmelden. Sind Portal und Verwaltung dagegen getrennte Systeme mit unterschiedlichen Konten, können sie eigene RP IDs haben.

Einführung in acht Schritten

Erfassen Sie Zugänge und Nutzergruppen. Listen Sie alle Wege zum Konto auf: Anmeldeformular, mobile App, Passwort vergessen, Änderung der E-Mail-Adresse und Support. Legen Sie für jede Gruppe fest, ob der Passkey optional, empfohlen oder verpflichtend ist.
Wählen Sie die RP ID vor der ersten Registrierung. Laut WebAuthn ist die Standard-RP-ID die Domain der Seite; sie kann auch auf deren registrierbare übergeordnete Domain gesetzt werden. Ein Passkey funktioniert nur mit der RP ID, für die er erstellt wurde, daher müssen Nutzer ihn nach einer späteren Änderung neu erstellen.
Prüfen Sie den Nutzer vor der Passkey-Erstellung stärker als nur mit dem Passwort. web.dev empfiehlt eine Bestätigung zum Beispiel per E-Mail oder Telefon innerhalb eines kurzen Zeitfensters und warnt vor einer Prüfung nur mit dem Passwort: Mit einem geleakten Passwort könnte ein Angreifer einen eigenen Passkey anlegen. Senden Sie die Liste bereits registrierter Passkeys im Parameter excludeCredentials mit, damit keine Duplikate entstehen.
Verwenden Sie auf dem Server eine bewährte Bibliothek. web.dev empfiehlt, die Antwort des Browsers mit einer serverseitigen Bibliothek zu verarbeiten statt mit eigenem Code. Speichern Sie die Credential-ID, den öffentlichen Schlüssel, die Nutzer-ID, die AAGUID (die Kennung des Passkey-Anbieters, nach der Sie den Passkey benennen), die Flags BE und BS sowie das Datum der Erstellung und der letzten Nutzung. Legen Sie in user.id keine personenbezogenen Daten ab, etwa die E-Mail-Adresse.
Zeigen Sie das Angebot nur dort, wo es funktioniert. Mit der Methode PublicKeyCredential.getClientCapabilities() ermitteln Sie, ob das Gerät Passkeys unterstützt und ob sie direkt im Anmeldeformular angeboten werden können. Prüfen Sie bei sensiblen Vorgängen das UV-Flag, denn bei der Einstellung userVerification: "preferred" kann das Gerät die Nutzerverifizierung überspringen.
Versenden Sie Benachrichtigungen. Schicken Sie dem Nutzer nach dem Hinzufügen eines Passkeys eine E-Mail. Laut web.dev bleibt ein Passkey, den ein Angreifer ohne Wissen des Nutzers anlegt, auch nach einer Passwortänderung nutzbar; die Benachrichtigung hilft, einen solchen Zugriff zu erkennen.
Bieten Sie eine Seite zur Verwaltung der Passkeys. Der Nutzer sollte Name, Erstellungsdatum, letzte Nutzung und den Synchronisierungsstatus sehen und den Passkey sofort entfernen können. NIST verlangt, dass ein Authentifikator unverzüglich nach der Meldung von Verlust oder Diebstahl ungültig gemacht werden kann.
Starten Sie ein Pilotprojekt und werten Sie es aus. Beginnen Sie mit einer kleineren Nutzergruppe. Verfolgen Sie die Erfolgsquote der Registrierungen, Anmeldefehler, die Zahl der Kontowiederherstellungen und Supportanfragen. Erst danach machen Sie den Passkey zur Standardoption.

Kontowiederherstellung: die schwächste Stelle, wenn Sie sie nicht planen

Lässt sich ein Passkey über den Link „Passwort vergessen“ oder einen einzigen SMS-Code umgehen, ist das Konto nur so sicher wie dieser Weg. NIST SP 800-63B unterscheidet vier Klassen der Wiederherstellung: gespeicherte Wiederherstellungscodes, zugestellte Wiederherstellungscodes, Wiederherstellungskontakte und eine erneute Identitätsprüfung. Andere Verfahren, etwa über Supportmitarbeiter, lässt die Richtlinie nur auf Grundlage einer Risikoanalyse und mit Dokumentation zu.

Mehrere Anmeldemethoden im Voraus

NIST empfiehlt, Nutzer dazu anzuhalten, mindestens zwei getrennte Authentifizierungsmethoden zu pflegen, und verlangt, dass sich mehrere Authentifikatoren an ein Konto binden lassen. Die beste Wiederherstellung ist die, die man nie braucht: ein zweiter Passkey auf einem anderen Gerät oder ein Hardware-Schlüssel.

Wiederherstellungscodes

Laut NIST muss ein gespeicherter Wiederherstellungscode mindestens 64 Bit aus einem Zufallsgenerator enthalten, wird nur als Hash gespeichert, seine Prüfung unterliegt einer Begrenzung der Versuche, und nach der Verwendung wird der Code ungültig gemacht und ein neuer ausgegeben. Ein per E-Mail zugestellter Code darf höchstens 24 Stunden gültig sein, per SMS oder Sprachanruf höchstens 10 Minuten. Für Konten auf Stufe AAL2 verlangt NIST zwei Codes, die über unterschiedliche Wege bezogen wurden, einen Code zusammen mit der Authentifizierung über einen anderen an das Konto gebundenen Authentifikator oder eine erneute Identitätsprüfung, sofern die Identität ursprünglich geprüft wurde.

Support und Benachrichtigungen

Laut NIST muss jede Kontowiederherstellung eine Benachrichtigung an den Nutzer auslösen. Erstellen Sie für den Support ein schriftliches Verfahren: was geprüft wird, wer Ausnahmen genehmigt und was im Audit-Trail festgehalten wird. Ohne dieses Verfahren ist die manuelle Wiederherstellung die Stelle, an der Social Engineering selbst die beste Technik aushebelt.

Entscheidungstabelle nach Nutzergruppe

Gruppe	Empfohlener Ansatz	Kontowiederherstellung	Worauf achten
Kunden eines Portals oder Onlineshops mit geringem Risiko	Passkey als optionale Methode neben der bisherigen Anmeldung, angeboten nach der Anmeldung	Kurzlebiger, per E-Mail zugestellter Code und ein gespeicherter Wiederherstellungscode	Die Anmeldung für Nutzer ohne Passkey nicht erschweren
B2B-Abnehmer mit Zugriff auf Rechnungen und Bestellungen	Passkey empfohlen, mindestens zwei Anmeldemethoden, erneute Authentifizierung bei sensiblen Aktionen	Zwei unabhängige Wiederherstellungswege und Benachrichtigung bei jeder Wiederherstellung	Gemeinsam genutzte Firmenkonten – jede Person sollte ein eigenes Konto haben
Administratoren und Mitarbeiter mit Datenzugriff	Passkey verpflichtend; wo interne Regeln es verlangen, gerätegebundene Hardware-Schlüssel	Zweiter registrierter Schlüssel und ein dokumentiertes Verfahren über eine benannte Person	Wenn Sie die NIST-Stufe AAL3 verlangen, reichen synchronisierte Passkeys nicht aus

Die Tabelle gibt unsere Empfehlung wieder, keine Norm. Ziehen Sie die Grenzen zwischen den Gruppen danach, welche Daten und Aktionen hinter der Anmeldung liegen.

Vorteile und Zielkonflikte

Geringerer Schaden bei einem Datenbankleck. Bei Konten mit Passkey speichert der Server einen öffentlichen Schlüssel statt eines Passworts. Google zufolge erbeutet ein Angreifer so weit weniger wertvolle Daten, und nach einem Vorfall ist weniger aufzuräumen.
Weniger SMS-Codes. Laut Google können Passkeys Einmalcodes per SMS oder App bei der Anmeldung überflüssig machen, was auch SMS-Kosten spart.
Zielkonflikt: das Ersatzpasswort. Solange das Passwort als Alternative bestehen bleibt, funktioniert Phishing dagegen weiterhin. Zur Einführung gehört ein Plan, wann und für wen Sie das Passwort entfernen.
Zielkonflikt: Abhängigkeit vom Passkey-Anbieter. Synchronisierte Passkeys verwaltet der Dienst des Nutzers, zum Beispiel ein Cloud-Konto oder ein Passwortmanager. Der Schutz dieser Sicherung liegt außerhalb Ihrer Anwendung.
Zielkonflikt: mehr Betriebsaufwand. Hinzu kommen Registrierung, Geräteverwaltung, Benachrichtigungen und ein neues Wiederherstellungsverfahren. Der Support braucht eine Anleitung, bevor die ersten Fragen eintreffen.

Häufige Fehler

Erstellung eines Passkeys nach Eingabe nur des Passworts, ohne weitere Prüfung.
Fehlende Benachrichtigung über einen neuen Passkey oder eine Kontowiederherstellung.
Wiederherstellung mit einem einzigen SMS-Code, die Passkeys und alle übrigen Schutzmaßnahmen umgeht.
Eine überstürzt gewählte RP ID, zum Beispiel nur für www, die später geändert wird.
Personenbezogene Daten in user.id.
Der Nutzer kann seine Passkeys nirgends sehen oder entfernen.
Eigene Signaturprüfung statt einer bewährten Bibliothek.

Checkliste vor dem Start

Die RP ID ist festgelegt und auf allen Domains getestet, auf denen sich Nutzer anmelden.
Vor der Registrierung eines Passkeys findet eine Prüfung statt, die stärker ist als das Passwort.
Der Server speichert Credential-ID, öffentlichen Schlüssel, AAGUID, die Flags BE und BS und die Nutzungsdaten.
Der Nutzer erhält eine Benachrichtigung über einen neuen Passkey und über jede Kontowiederherstellung.
Die Seite zur Verwaltung der Passkeys ermöglicht das sofortige Entfernen.
Jedes Konto mit einem gerätegebundenen Passkey hat einen zweiten Authentifikator oder eine Wiederherstellung.
Wiederherstellungscodes sind einmalig nutzbar, als Hash gespeichert und durch eine Begrenzung der Versuche geschützt.
Der Support hat ein schriftliches Wiederherstellungsverfahren und einen Audit-Trail.

Häufige Fragen

Können wir Passwörter vollständig abschaffen?

Ja, aber schrittweise. WebAuthn hält fest, dass die Anwendung dem Nutzer das Entfernen des Passworts anbieten kann, sobald der Passkey gesichert ist (das BS-Flag wechselt von 0 auf 1). Wir empfehlen das erst, wenn der Nutzer mindestens zwei Anmeldemethoden und eine funktionierende Kontowiederherstellung hat.

Was passiert, wenn ein Nutzer sein Smartphone verliert?

Ein synchronisierter Passkey ist meist auch auf seinen anderen Geräten verfügbar, sodass er sich zum Beispiel vom Notebook aus anmeldet. Bei Verdacht auf Missbrauch entfernt er den Passkey in der Anwendung und erstellt einen neuen. Ein gerätegebundener Passkey geht mit dem Gerät verloren, deshalb empfiehlt WebAuthn, dass das Konto einen weiteren Authentifikator oder einen Wiederherstellungsprozess hat.

Speichert die Anwendung Fingerabdrücke oder Gesichtsbilder?

Nein. Das Entsperren per Fingerabdruck, Gesicht oder PIN findet auf dem Gerät des Nutzers statt, und laut Google speichert der Server einen öffentlichen Schlüssel. Die Liste der Daten, deren Speicherung web.dev empfiehlt, enthält keine biometrischen Daten.

Reicht ein Einmalcode per SMS als Alternative?

Vor Phishing schützt er nicht: NIST betrachtet Einmalcodes, die der Nutzer eintippt, nicht als phishing-resistent, weil eine betrügerische Website sie weiterleiten kann. Wenn Sie SMS für die Kontowiederherstellung nutzen, begrenzt NIST die Gültigkeit des zugestellten Codes auf 10 Minuten. Für sensible Konten empfehlen wir den Passkey als Hauptmethode und SMS höchstens als einen der Wiederherstellungswege.

Wie wir Sie unterstützen

Passkeys lassen sich auch in eine bestehende Anwendung integrieren, ohne das ganze System neu zu schreiben. Im Rahmen unserer individuellen Webanwendungen konzipieren und implementieren wir Registrierung, Anmeldung, Passkey-Verwaltung und Kontowiederherstellung und erstellen ein Verfahren für Ihren Support. Weitere praktische Leitfäden finden Sie in unserem Blog.

Sie erwägen eine Anmeldung ohne Passwort für Ihr Kundenportal oder Ihre interne Anwendung? Schreiben Sie uns, und wir klären gemeinsam, wo Sie anfangen und was Sie vorbereiten sollten.

Quellen

Web Authentication: An API for accessing Public Key Credentials – Level 3 – W3C, Empfehlung vom 25. August 2026.
NIST Special Publication 800-63B – NIST-Richtlinie zur Authentifizierung und Verwaltung von Authentifikatoren, Teil der Revision SP 800-63-4.
Create a passkey for passwordless logins – web.dev, aktualisiert am 9. April 2026.
Passkeys – Google for Developers.