Passkeys sind jetzt eine Produktentscheidung
Passkeys sind von einem Security-Thema fuer Early Adopter zu realistischer Login-Infrastruktur fuer Kundenportale, SaaS-Produkte und mobil angebundene Webplattformen geworden. FIDO meldet breite Bekanntheit und wachsenden Einsatz, waehrend Browser- und Betriebssystemanbieter Passkey-Erstellung, Autofill und geraeteuebergreifende Nutzung weiter verbessern.
Fuer Produktteams lautet die wichtige Frage nicht nur, ob Passkeys sicherer sind als Passwoerter. Das sind sie in der Regel, weil sie oeffentliche Schluesselpaare nutzen, die an den jeweiligen Dienst gebunden sind, statt wiederverwendbare Geheimnisse zu speichern. Schwieriger ist die Frage, wie sich der Login fuer echte Nutzer veraendern soll, die bereits Passwoerter, Geraete, Passwortmanager und Support-Erwartungen haben.
Beginne mit der Account-Reise, nicht mit dem Button
Ein Passkey-Rollout sollte entlang der gesamten Account-Reise geplant werden: Registrierung, erster Login, wiederkehrender Login, Geraetewechsel, geteilte Geraete, Wiederherstellung nach Geraeteverlust und Admin-Support. Wenn nur ein weiterer Sign-in-Button ergaenzt wird, bleibt die Nutzung ungleichmaessig und Support-Fragen steigen.
Das staerkste Muster fuer viele Kundenportale ist eine schrittweise Migration. Der bestehende Passwortweg bleibt verfuegbar, Nutzer werden nach einem erfolgreichen Login zum Erstellen eines Passkeys eingeladen, und Conditional UI sorgt dafuer, dass Passkeys in der vertrauten Autofill-Oberflaeche des Browsers erscheinen. So fuehlen sich Passkeys wie ein besserer Login an, nicht wie eine Technikerlaerung.
- Passkeys in Momenten anbieten, in denen der Nutzer der Session bereits vertraut.
- Den Vorteil in Account-Sprache erklaeren: schnellerer Login, Phishing-Schutz und weniger Codes.
- Recovery und Fallback sichtbar halten, ohne sie zum Hauptweg zu machen.
- Passkey-Erstellung, Login-Erfolg, Fallback-Nutzung und Support-Kontakte messen.
- Die Admin-Sicht so gestalten, dass Support-Teams Credential-Status sehen, aber keine Geheimnisse.
Implementierungsdetails praegen die UX
WebAuthn liefert die technische Grundlage, aber die Produktqualitaet haengt an Implementierungsentscheidungen. Relying-Party-IDs, Origin-Handling, discoverable Credentials, Attestation-Policy, Session-Handling und Geraeteunterstuetzung praegen, was Nutzer bei Registrierung und Login erleben.
Conditional Mediation ist besonders hilfreich fuer Portale, die weiterhin Passwoerter unterstuetzen. Die Seite kann im Hintergrund eine Passkey-Anfrage laden und der Browser zeigt vorhandene Passkeys gemeinsam mit gespeicherten Zugangsdaten. Neuere Plattformarbeit rund um automatische Passkey-Upgrades und Credential Exchange zeigt in dieselbe Richtung: weniger Reibung, wenn Nutzer von Passwoertern zu Passkeys oder zwischen Credential Managern wechseln.
Recovery nicht erst im Notfall entwerfen
Passwortlos bedeutet nicht supportlos. Nutzer ersetzen Smartphones, wechseln Arbeitgeber, verlieren Zugriff auf einen Passwortmanager oder versuchen sich von einem Geraet anzumelden, auf dem ihr Credential nicht verfuegbar ist. Wenn Recovery erst spaeter improvisiert wird, wirkt der Passkey-Rollout bruechig, selbst wenn die eigentliche Authentifizierung stark ist.
Ein praktisches Kundenportal braucht vor dem Launch ein Wiederherstellungsmodell. Dazu koennen verifizierter E-Mail-Fallback, Recovery durch Organisations-Admins, supportgestuetzte Identitaetspruefung, mehrere Passkeys pro Account und klare Account-Einstellungen gehoeren, in denen Nutzer Credentials pruefen und entfernen koennen. Das genaue Modell haengt vom Risiko ab, aber die Erfahrung sollte gestaltet sein, bevor der erste echte Nutzer haengen bleibt.
Die erste Version eng bauen
Der beste erste Passkey-Release ist meist begrenzt und messbar. Starte mit einer Produktoberflaeche, einem Account-Typ und einer klaren Erfolgsmetrik, etwa weniger Login-Reibung, weniger Passwort-Resets oder mehr abgeschlossene geschuetzte Workflows.
Fuer EDS Labs Projekte passen Passkeys besonders gut zu Kundenportalen, SaaS-Dashboards und Companion-Plattformen fuer mobile Apps. Das Ziel ist nicht, Authentifizierung futuristisch wirken zu lassen. Das Ziel ist ein sensibler Moment, der ruhig, schnell und vertrauenswuerdig wirkt, waehrend die Architektur fuer staerkere Sicherheit wachsen kann.