Passkeys einbauen: Login ohne Passwort im Kundenportal
Passkeys lassen sich nicht abfischen, weil sie an die Domain gebunden sind. Was der Einbau in ein Kundenportal verlangt, wo die eigentliche Schwachstelle liegt und wann ein Passwort als Rückfallebene bleiben muss.
Was ein Passkey ist – und was er ersetzt
Ein Passkey ist ein Schlüsselpaar, das die Anmeldung per Passwort ersetzt: Der geheime Schlüssel bleibt auf dem Gerät des Nutzers, der öffentliche Schlüssel liegt beim Kundenportal. Bei der Anmeldung schickt der Server eine Aufgabe, das Gerät unterschreibt sie mit dem geheimen Schlüssel, und der Server prüft die Unterschrift mit dem öffentlichen. Der Nutzer bestätigt das Ganze mit Fingerabdruck, Gesichtserkennung oder der Geräte-PIN.
Technisch steht dahinter der Standard WebAuthn des W3C, Teil des FIDO2-Verbunds der FIDO Alliance. Die aktuelle Fassung, Web Authentication Level 3, ist seit dem 25. August 2026 eine W3C-Empfehlung. Für den Betreiber eines Portals heißt das: Es gibt eine stabile, offene Schnittstelle im Browser, kein Herstellerprodukt, an das man sich bindet.
Der entscheidende Unterschied zum Passwort liegt nicht im Komfort, sondern darin, was auf dem Server liegt. Ein öffentlicher Schlüssel ist für einen Angreifer wertlos. Wird die Datenbank eines Portals gestohlen, gibt es darin kein Geheimnis, das sich anderswo ausprobieren ließe.
Warum Passkeys gegen Phishing immun sind
Passkeys sind gegen Phishing immun, weil der Browser einen Passkey nur der Domain anbietet, für die er angelegt wurde. Die Spezifikation nennt das die Bindung an die Relying-Party-ID: Ein Passkey für portal.beispiel.de wird auf einer täuschend echten Kopie unter portal-beispiel.com schlicht nicht angeboten. Der Nutzer kann ihn dort nicht preisgeben, selbst wenn er die Fälschung nicht erkennt.
Das ist der Punkt, an dem Passkeys jede Schulung schlagen. Eine Anmeldung, deren Sicherheit davon abhängt, dass Menschen eine gefälschte Adresszeile bemerken, scheitert zuverlässig an einem müden Nachmittag. Ein Passkey nimmt diese Entscheidung dem Menschen ab. Das BSI formuliert es auf seiner Verbraucherseite so: Passkeys seien „immun gegen die breite Masse bekannter Phishing-Angriffe".
Das Wort „breite Masse" steht dort nicht zufällig. Wer das Gerät selbst kontrolliert, etwa über Schadsoftware, oder wer über einen schwächeren Wiederherstellungsweg ins Konto kommt, umgeht den Passkey, statt ihn zu knacken. Davon handeln die letzten Abschnitte dieses Beitrags.
Passkey oder Zwei-Faktor-Code: der Unterschied in der Praxis
Ein Passkey ist sicherer als ein Passwort mit SMS- oder App-Code, weil ein Code an der Echtzeit-Weiterleitung scheitert und ein Passkey nicht. Eine nachgebaute Anmeldeseite kann Passwort und sechsstelligen Code entgegennehmen und sofort an das echte Portal weiterreichen. Der Code war korrekt, der Angreifer ist trotzdem angemeldet.
Eine Untersuchung von Google mit zwei Universitäten hat das im Mai 2019 beziffert: Bei gezieltem Phishing blockierte ein SMS-Code 76 Prozent der Kontoübernahmen, eine Bestätigung auf dem Gerät 90 Prozent, ein Sicherheitsschlüssel nach dem FIDO-Verfahren 100 Prozent. Ein Passkey arbeitet nach demselben Prinzip wie dieser Sicherheitsschlüssel.
Dazu kommt der Unterschied im Alltag. Nach dem Passkey Index der FIDO Alliance vom Oktober 2025, erhoben bei neun Mitgliedsunternehmen, gelangen Anmeldungen per Passkey in 93 Prozent der Fälle, mit anderen Verfahren in 63 Prozent. Eine Anmeldung dauerte im Schnitt 8,5 Sekunden statt 31,2 Sekunden. Für ein Kundenportal ist das der Teil der Rechnung, der Supportanfragen spart: Die beteiligten Unternehmen meldeten 81 Prozent weniger Tickets rund ums Passwort.
Was der Einbau in eine eigene Web-Anwendung verlangt
Der Einbau besteht aus zwei Abläufen, Registrierung und Anmeldung, und beide teilen sich die Arbeit zwischen Browser und Server. Bei der Registrierung erzeugt der Server eine zufällige Aufgabe, der Browser ruft navigator.credentials.create() auf, und der Server speichert anschließend die Kennung und den öffentlichen Schlüssel des neuen Passkeys zum Benutzerkonto. Bei der Anmeldung läuft dasselbe mit navigator.credentials.get() und einer Signaturprüfung.
Diese Prüfung schreibt man nicht selbst. Für die verbreiteten Frameworks gibt es gepflegte Bibliotheken, für Laravel etwa spatie/laravel-passkeys oder laragear/webauthn, für Node.js SimpleWebAuthn. Die eigene Arbeit liegt in der Einbindung: Datenmodell für mehrere Passkeys pro Konto, Verwaltungsseite im Profil, sauber gesetzte Relying-Party-ID und ein Anmeldeformular, das Passkeys über die Autovervollständigung des Browsers anbietet, statt einen zusätzlichen Knopf zu verlangen.
Eine Voraussetzung wird gern übersehen: WebAuthn funktioniert nur über HTTPS und nur auf der Domain, die als Relying-Party-ID festgelegt ist. Wer das Portal später auf eine andere Domain umzieht, nimmt die Passkeys seiner Nutzer nicht mit. Die Domainfrage gehört deshalb vor den Einbau, nicht danach.
Synchronisierte und gerätegebundene Passkeys
Passkeys gibt es in zwei Bauarten: synchronisierte, die über das Konto bei Apple, Google, Microsoft oder einem Passwortmanager auf alle Geräte des Nutzers wandern, und gerätegebundene, die ein einzelnes Gerät oder einen Hardware-Schlüssel nie verlassen. Die Spezifikation macht den Unterschied für den Server sichtbar, über die Kennzeichen „backup eligible" und „backup state" in jeder Antwort.
Für ein typisches Kundenportal sind synchronisierte Passkeys die richtige Voreinstellung. Ein Kunde, der sein Telefon wechselt, hat seinen Passkey auf dem neuen Gerät wieder, ohne dass der Support eingreift. Das BSI weist genau darauf hin: Passkeys lassen sich wiederherstellen, wenn lokale Sicherungen bestehen oder die Passkeys in einer Cloud synchronisiert werden.
Gerätegebundene Passkeys sind die Wahl für Zugänge mit hohem Schaden im Missbrauchsfall, etwa Verwaltungsoberflächen mit Zugriff auf alle Kundendaten. Dort ist erwünscht, dass der Schlüssel an einem Hardware-Token hängt, das physisch ausgegeben und wieder eingesammelt wird. Ein Portal kann beide Arten zulassen und für Administratorkonten nur die gerätegebundene akzeptieren.
Die eigentliche Schwachstelle: die Kontowiederherstellung
Ein Konto mit Passkey ist nur so sicher wie der schwächste Weg, der sonst noch hineinführt. Bietet die Anmeldeseite neben dem Passkey weiterhin „anderen Weg versuchen" mit SMS-Code oder einen Passwort-Reset per E-Mail an, greift ein Angreifer genau dort an. Er muss den Passkey nicht knacken, er muss nur den Nutzer auf die schwächere Tür lenken.
Die Gegenmaßnahme ist eine Rangfolge der Wiederherstellungswege. Am sichersten ist ein zweiter Passkey, den das Portal gleich nach dem ersten anbietet. Danach folgen Einmal-Wiederherstellungscodes, die bei der Einrichtung angezeigt und nur gehasht gespeichert werden. SMS- und E-Mail-Codes stehen am unteren Ende, weil sie sich in Echtzeit weiterleiten lassen.
Daraus folgt eine unbequeme Entscheidung: Sobald ein Nutzer zwei Passkeys hinterlegt hat, sollte das Passwort für dieses Konto abschaltbar sein. Solange es aktiv bleibt, ist der Gewinn an Phishing-Schutz nur teilweise eingelöst. Ein Portal, das Passkeys einführt und alle alten Wege unverändert offen lässt, hat Komfort gewonnen, aber kaum Sicherheit.
Wo Passkeys an Grenzen stoßen
Passkeys passen nicht auf jeden Nutzerkreis, und drei Fälle verlangen eine bewusste Rückfallebene. Der erste sind geteilte Geräte: Ein Rechner an der Werkbank oder am Empfang, an dem mehrere Personen arbeiten, verträgt keinen Passkey, der an das Systemkonto einer einzelnen Person gebunden ist. Dort sind Hardware-Schlüssel pro Person die saubere Lösung.
Der zweite Fall sind B2B-Nutzer ohne Diensthandy und auf verwalteten Rechnern, auf denen die Synchronisierung über private Konten untersagt ist. Ein Passkey auf dem Firmenrechner funktioniert dann nur an diesem einen Gerät. Der dritte Fall ist die Verlustlage ohne jede Sicherung: Das BSI hält ausdrücklich fest, dass man sich in seltenen Fällen nach einem Geräteverlust nicht mehr einloggen kann.
Deshalb ist der realistische Fahrplan für ein bestehendes Portal kein harter Umstieg, sondern ein Angebot. Passkeys werden als bevorzugter Weg eingeführt, das Passwort bleibt vorerst als Rückfallebene, und der Anteil der Passkey-Anmeldungen wird gemessen. Erst wenn er trägt, wird das Passwort für Konten mit zwei Passkeys abschaltbar und für neue Konten gar nicht erst vergeben.
Pflicht oder Kür: was rechtlich gilt
Eine allgemeine gesetzliche Pflicht, Passkeys anzubieten, gibt es in Deutschland nicht. Das BSI-Gesetz verlangt in der Fassung des NIS-2-Umsetzungsgesetzes in § 30 Absatz 2 Satz 2 Nummer 10 Lösungen zur Multi-Faktor-Authentifizierung, aber nur von den dort benannten Einrichtungen. Ein Passkey erfüllt diese Anforderung, weil er Besitz des Geräts und die Entsperrung per Biometrie oder PIN verbindet.
Für alle anderen ist die Frage eine wirtschaftliche. Das BSI empfiehlt Verbrauchern seit Januar 2025 ausdrücklich, ganz auf Passkeys umzusteigen, und rät, bei Diensten ohne Zwei-Faktor-Schutz und ohne Passkeys nach Alternativen zu suchen. Ein Kundenportal, das nur ein Passwort kennt, steht damit auf der falschen Seite einer Empfehlung, die Kunden zunehmend kennen.
Die Grenze der Sache gehört hier ausgesprochen: Ein Passkey schützt die Anmeldung, nicht die Anwendung dahinter. Fehlerhafte Berechtigungsprüfungen, eine angreifbare Schnittstelle oder ein übernommenes Administratorkonto bleiben, was sie sind. Wer Passkeys einführt, hat die häufigste Einbruchsart geschlossen, nicht alle.
Rechtsgrundlagen
- Web Authentication Level 3 (W3C-Empfehlung, WebAuthn)(öffnet in neuem Tab)Bindung an die Relying-Party-ID, Kennzeichen „backup eligible" und „backup state"
- BSI-Gesetz (BSIG, Fassung des NIS-2-Umsetzungsgesetzes)(öffnet in neuem Tab)§ 30 Abs. 2 Maßnahmenkatalog, Satz 2 Nr. 10 Multi-Faktor-Authentifizierung, § 61 angeordnete Prüfung