Passkeys für SaaS-Produkte: WebAuthn sicher einführen

Passkeys für SaaS-Produkte werden zur realistischen Alternative zu Passwörtern und klassischer Zwei-Faktor-Authentifizierung. Für Produkt- und Engineering-Teams ist die Einführung aber kein kleines Login-Feature: Sie verändert Credential-Speicherung, Kontowiederherstellung, Support-Prozesse und die Sicherheitsgrenzen des Backends.

#Was Passkeys für SaaS-Produkte technisch verändern

Passkeys basieren auf FIDO2 und WebAuthn. Bei der Registrierung erzeugt das Gerät oder der Passwortmanager ein Schlüsselpaar. Der private Schlüssel bleibt beim Nutzer, während das Backend den öffentlichen Schlüssel speichert und später eine signierte Challenge prüft.

Damit lösen Passkeys mehrere bekannte Passwortprobleme:

• Phishing-Resistenz: Ein Credential ist an die Relying Party ID und damit an die legitime Domain gebunden.
• Keine Passwortdatenbank: Das Backend speichert keine gemeinsamen Geheimnisse, die Angreifer für Credential Stuffing verwenden können.
• Lokale Nutzerprüfung: Biometrie oder Geräte-PIN entsperren den Passkey lokal und werden nicht an den SaaS-Anbieter übertragen.
• Bessere Nutzung: Synchronisierte Passkeys können über Plattformen wie iCloud Keychain, Google Password Manager oder kompatible Passwortmanager auf mehreren Geräten verfügbar sein.

Die Architektur bleibt trotzdem anspruchsvoll. Das Backend muss einmalige Challenges erzeugen, Origin und Relying Party ID prüfen, mehrere Credentials pro Konto verwalten und Änderungen auditierbar protokollieren. Eine gepflegte WebAuthn-Bibliothek ist dafür belastbarer als eine eigene Kryptografie-Implementierung.

Besonders früh müssen Teams ihre Domain-Strategie festlegen. Mandanten auf Subdomains, eigene Kundendomains und spätere Domainwechsel beeinflussen, wo ein Passkey gültig ist. Eine kurzfristige URL-Entscheidung kann dadurch langfristig Teil des Authentifizierungsmodells werden.

#Wie Teams Passkeys sicher einführen

Der häufigste Fehler ist ein sicherer Passkey-Login mit einer schwachen Kontowiederherstellung. Wenn ein Support-Mitarbeiter nach wenigen persönlichen Angaben wieder ein Passwort setzt, umgehen Angreifer genau den Schutz, den WebAuthn geschaffen hat.

Vor dem Rollout sollten Produkt, Engineering und Security deshalb gemeinsam klären:

• Einführungsweg: Passkeys zunächst zusätzlich anbieten, Nutzung und Abbrüche messen und erst mit belastbaren Recovery-Prozessen zum Standard machen.
• Kontowiederherstellung: Mehrere Passkeys pro Konto ermöglichen und für verlorene Geräte einen geprüften, risikobasierten Prozess definieren.
• Fallbacks: Passwörter, E-Mail-Links oder SMS nicht dauerhaft als unkontrollierte Hintertür bestehen lassen.
• Session-Sicherheit: Passkeys schützen die Anmeldung, aber nicht automatisch vor gestohlenen Sessions, unsicheren Admin-Funktionen oder fehlerhafter Autorisierung.
• B2B-Sonderfälle: Enterprise SSO, SCIM, geteilte Geräte, Service-Accounts und Support-Impersonation getrennt vom Endnutzer-Login behandeln.
• Betrieb: Registrierungen, fehlgeschlagene Challenges, Credential-Löschungen und Recovery-Vorgänge so erfassen, dass Support und Incident Response handlungsfähig bleiben.

Ein sinnvoller Pilot beginnt mit einer klaren Nutzergruppe und einem vorhandenen Login, nicht mit einer sofortigen Abschaltung aller Passwörter. Erfolgsmetriken sind nicht nur Aktivierungsraten, sondern auch Login-Abbrüche, Supportfälle, Recovery-Dauer und verdächtige Kontoübernahmen.

#Warum das wichtig ist

Authentifizierung sitzt direkt zwischen Produktwachstum und Geschäftsrisiko. Schlechte Login-Erlebnisse kosten Aktivierung und Supportzeit, während kompromittierte Konten Vertrauen, Vertragsfähigkeit und operative Kapazität belasten.

Passkeys können beide Seiten verbessern, wenn Architektur und Prozesse zusammenpassen. Wer nur den WebAuthn-Dialog implementiert, verschiebt das Risiko in Recovery, Sessions oder Helpdesk. Wer Domainmodell, Backend-Verifikation und Betriebsprozesse gemeinsam plant, reduziert Passwortabhängigkeit ohne neue blinde Flecken.

Für Entscheider ist die relevante Frage deshalb nicht, ob Browser Passkeys unterstützen. Entscheidend ist, ob das Unternehmen den gesamten Lebenszyklus eines Credentials sicher betreiben kann. Diese Arbeit zahlt sich durch weniger Passwort-Resets, geringeres Phishing-Risiko und eine Authentifizierungsarchitektur aus, die mit dem Produkt skaliert.