WebAuthn Level 3 ist Recommendation: Ist Ihr Passkey-Login wirklich produktionsreif?

Am 25. August 2026 wurde Web Authentication Level 3 zur W3C Recommendation. Für Produktteams ist das weniger ein Signal, jetzt schnell noch einen Passkey-Button einzubauen, als eine gute Gelegenheit für eine grundsätzlichere Frage: Ist unsere Authentifizierungsgrenze sauber modelliert – oder funktioniert der Passkey nur im Happy Path?

Passkeys sind attraktiv, weil sie keine wiederverwendbaren Passwörter an den Server schicken und die Bindung an den richtigen Dienst durch Browser, Betriebssystem und Authenticator mit durchgesetzt wird. Aber genau diese Stärke macht Implementierungsdetails wie RP ID, Origin-Prüfung und Credential-Zuordnung sicherheitskritisch.

Ein Login kann in Chrome auf dem Entwickler-Laptop funktionieren und trotzdem in Produktion fragil sein: Die App läuft auf mehreren Subdomains, Staging nutzt dieselbe Auth-Konfiguration, der Server akzeptiert zu viele Origins, Conditional UI wird als einzige Anmeldung behandelt oder der Recovery-Pfad fällt bei Geräteverlust auf einen deutlich schwächeren Prozess zurück.

WebAuthn Level 3 ist deshalb ein guter Anlass, Passkeys nicht als UI-Feature, sondern als Authentifizierungsarchitektur zu prüfen.

1. RP ID ist eine Vertrauensgrenze, kein beliebiger Konfigurationsstring

WebAuthn bindet Credentials an eine Relying Party. Zentral dafür ist die RP ID. Laut W3C ist sie typischerweise die effektive Domain des aufrufenden Origins oder eine zulässige registrierbare übergeordnete Domain. Sie enthält weder Schema noch Port.

Das klingt abstrakt, hat aber sehr konkrete Auswirkungen.

Läuft Ihr Login unter https://login.example.de, kann die RP ID beispielsweise login.example.de oder – wenn die Architektur das bewusst vorsieht – example.de sein. Eine RP ID wie example.de schafft eine breitere organisatorische Grenze als login.example.de.

Die Audit-Frage lautet daher nicht nur: Was funktioniert? Sondern: Welche Hosts sollen langfristig zur selben Authentifizierungsdomäne gehören?

Prüfen Sie insbesondere:

• Hauptanwendung, Adminbereich und Kundenportal,
• www versus App-Subdomain,
• alte Login-Hosts,
• Preview- und Staging-Umgebungen,
• White-Label- oder Kundendomains,
• geplante Domainmigrationen.

Eine zu breite RP ID ist kein Komfortgewinn, den man später beliebig zurückdreht. Sie ist Teil der Credential-Bindung. Umgekehrt kann eine zu enge RP ID spätere Host-Wechsel unnötig schwierig machen.

Die richtige RP ID ist deshalb eine Architekturentscheidung, kein Copy-Paste-Wert aus einem Tutorial.

2. RP ID ersetzt niemals die Origin-Prüfung auf dem Server

Ein häufiger Denkfehler lautet: Wenn der Browser das Credential ohnehin an die RP bindet, muss der Server den Origin nicht mehr so genau prüfen.

Doch.

Die WebAuthn-Spezifikation verlangt bei der Authentifizierung mehrere serverseitige Prüfungen. Dazu gehören unter anderem der erwartete Challenge-Wert, der Typ der Operation, der erwartete Origin, der Hash der RP ID und die Authenticator-Flags. Ein unerwarteter Origin darf nicht einfach akzeptiert werden.

Das ist besonders wichtig, wenn mehrere Frontends denselben Auth-Backend-Service verwenden.

Für eine Anwendung mit genau einem Login-Origin ist ein exakter Vergleich gegen diesen Origin leicht nachvollziehbar. Bei mehreren erlaubten Origins sollte eine explizite Liste oder eine ebenso streng definierte Regel existieren.

Red Flags sind:

• origin.endsWith("example.de"),
• Substring-Prüfungen,
• pauschales Vertrauen in alle Preview-Subdomains,
• dieselbe Origin-Liste für Produktion und Entwicklung,
• fehlende Berücksichtigung von Schema oder Port,
• ein Reverse Proxy, der interne und externe Hosts vermischt.

RP ID und Origin beantworten unterschiedliche Fragen. Die RP ID bestimmt, für welchen Relying-Party-Namespace ein Credential gilt. Der Origin sagt, von welchem konkreten Webkontext die Operation gestartet wurde. Beides gehört in die Prüfung.

3. Der Challenge muss frisch, transaktionsgebunden und serverseitig geprüft sein

Die Kryptografie eines Passkeys hilft nur, wenn der Server genau die Operation verifiziert, die er selbst gestartet hat.

Dafür dient der Challenge. Er sollte zufällig, ausreichend stark, kurzlebig und an den konkreten Anmelde- oder Registrierungsversuch gebunden sein. Beim Rücklauf muss der Server prüfen, ob genau dieser Challenge erwartet wurde.

Ein robuster Flow beantwortet:

• Wer hat diesen Challenge erzeugt?
• Für welchen Zweck: Registrierung oder Login?
• Für welches Konto oder welche noch offene Sitzung?
• Wie lange ist er gültig?
• Kann derselbe Challenge erneut benutzt werden?
• Was passiert bei zwei parallelen Login-Tabs?

Ein Passkey-Assertion ist keine frei stehende Unterschrift nach dem Motto „dieser Nutzer hat irgendwann etwas signiert“. Der Server muss beweisen können, dass die Antwort zu dieser aktuellen Authentifizierung gehört.

4. Discoverable Credentials verändern die Account-Zuordnung

Passkeys sind discoverable credentials. Damit kann eine Anmeldung ohne vorherige Eingabe eines Benutzernamens funktionieren. Der Authenticator kann passende Credentials für die RP anbieten; nach erfolgreicher Auswahl erhält die Anwendung unter anderem einen Credential-Identifier und – je nach Flow – einen User Handle.

Das ist hervorragend für passwortlose UX. Es ändert aber die Backend-Annahmen.

Wenn allowCredentials leer beziehungsweise nicht vorgegeben ist, muss der Server die eingehende Credential-ID einem gespeicherten Credential und damit dem richtigen lokalen Nutzerkonto zuordnen können. Die Spezifikation sieht den User Handle dafür als stabilen, von der RP vergebenen Nutzerbezug vor.

Red Flags:

• Ein Konto kann technisch nur genau einen Passkey besitzen.
• Credential-IDs werden nicht eindeutig gespeichert.
• Die Zuordnung basiert auf E-Mail oder sichtbarem Anzeigenamen statt auf internen stabilen IDs.
• Beim Löschen eines Credentials wird versehentlich das gesamte Konto gesperrt.
• Es gibt keinen nachvollziehbaren Weg, mehrere Geräte oder Security Keys demselben Konto zuzuordnen.

Ein gutes Datenmodell behandelt einen Passkey als einen von mehreren möglichen Authenticatoren eines Kontos, nicht als das Konto selbst.

5. userVerification muss zur Sicherheitsanforderung passen

WebAuthn unterscheidet bei der User Verification unter anderem required, preferred und discouraged. Diese Einstellung ist keine reine UX-Vorliebe.

Wenn ein Produkt für eine bestimmte Aktion wirklich verlangt, dass der lokale Authenticator den Nutzer verifiziert – etwa per Geräte-PIN oder Biometrie –, muss die Anforderung im Request passend gesetzt und das Ergebnis serverseitig ausgewertet werden. Die Spezifikation verlangt bei required, dass die Operation fehlschlägt, wenn User Verification nicht durchgeführt werden kann.

Das bedeutet nicht, dass jede Website pauschal überall required verwenden muss. Es bedeutet: Die Policy sollte explizit sein.

Praktische Fragen:

• Reicht für normalen Login die gewählte Verifikationsstufe?
• Brauchen besonders sensible Aktionen eine erneute starke Bestätigung?
• Vertraut der Server dem UV-Flag tatsächlich oder ignoriert er es?
• Werden Unterschiede zwischen Plattform-Authenticator, Security Key und Cross-Device-Nutzung verstanden?

„Der Browser hat irgendetwas mit Face ID angezeigt“ ist keine serverseitige Sicherheitsdefinition.

6. Conditional UI ist Progressive Enhancement, kein Grund den Fallback zu verstecken

Mit Conditional Mediation kann WebAuthn Passkeys direkt in eine bestehende Anmeldeoberfläche integrieren. Der Browser beziehungsweise Credential Manager kann verfügbare Passkeys im Autofill-Kontext anbieten, ohne dass die Seite sofort ein modales Authenticator-Fenster erzwingt.

Das ist eine sehr gute UX, wenn es sauber eingesetzt wird.

passkeys.dev beschreibt genau dieses Bootstrapping-Muster: Conditional UI kann im Hintergrund auf ein passendes Credential warten. Wenn ein Passkey verfügbar ist und gewählt wird, entsteht eine WebAuthn-Anmeldung. Wenn nicht, kann der Nutzer einen bestehenden Legacy-Login weiterverwenden.

WebAuthn Level 3 erweitert zudem die Möglichkeit, Client-Fähigkeiten über getClientCapabilities() zu erkennen. Dazu gehören beispielsweise conditionalGet, conditionalCreate, hybridTransport und Hinweise auf Passkey-fähige Plattform-Authenticators.

Daraus folgt eine wichtige Produktregel: Capability Detection hilft beim Optimieren der UX, darf aber keine Sicherheitsentscheidung ersetzen.

Und vor allem: Verstecken Sie Passwort, Magic Link oder einen anderen vorgesehenen Fallback nicht allein deshalb, weil der Browser Conditional UI grundsätzlich unterstützt. Unterstützung bedeutet nicht, dass genau dieser Nutzer auf diesem Gerät einen nutzbaren Passkey besitzt.

7. Cross-Device ist ein normaler Teil des Passkey-Modells

Ein Nutzer sitzt am Desktop, sein Passkey liegt auf dem Smartphone. Oder ein Account nutzt einen gerätegebundenen Security Key. Oder mehrere Passkeys werden über einen Credential Provider synchronisiert.

FIDO beschreibt Cross-Device Authentication ausdrücklich als vorgesehenen Weg: Ein Passkey auf einem anderen Gerät kann über einen vom Browser und Authenticator unterstützten Ablauf für den Login verwendet werden. WebAuthn Level 3 kennt außerdem hybridTransport als erkennbare Client-Fähigkeit.

Deshalb sollten Tests nicht nur „Passkey auf demselben Laptop“ umfassen.

Prüfen Sie mindestens:

• Plattform-Passkey auf demselben Gerät,
• synchronisierter Passkey auf einem zweiten Gerät,
• Cross-Device-Anmeldung vom Desktop über ein Smartphone,
• gerätegebundener Security Key, wenn Ihre Zielgruppe ihn verwendet,
• Browser ohne die gewünschte komfortable UI,
• Nutzer mit mehreren gespeicherten Credentials.

Wer Passkeys nur auf dem Entwickler-Mac testet, testet einen Anbieterpfad – nicht das Produkt.

8. Credential-Management gehört in die Kontoeinstellungen

Ein produktionsreifer Passkey-Rollout braucht nicht nur „Passkey hinzufügen“. Nutzer sollten nachvollziehen können, welche Credentials zum Konto gehören, weitere hinzufügen und nicht mehr benötigte entfernen können.

Dabei sollte die Oberfläche keine Sicherheit vorspielen, die technisch nicht vorhanden ist. Ein Server kennt nicht zwingend das exakte physische Gerät, auf dem ein synchronisierter Passkey liegt. Sinnvoll sind deshalb Metadaten, die die Anwendung wirklich kennt, etwa:

• Erstellungsdatum,
• zuletzt verwendet,
• vom Nutzer vergebener Name,
• grober Credential- oder Authenticator-Typ, soweit zuverlässig verfügbar,
• Status aktiv oder widerrufen.

Ein wichtiges Detail: Das Entfernen eines einzelnen Passkeys sollte nicht automatisch alle anderen Authentifizierungswege zerstören. Umgekehrt darf ein widerrufenes Credential serverseitig nicht weiter akzeptiert werden, nur weil der private Schlüssel auf irgendeinem Gerät noch existiert.

9. Recovery ist Teil des Passkey-Designs – sonst gewinnt der schwächste Pfad

Passkeys reduzieren viele klassische Passwortprobleme. Sie eliminieren aber nicht die Notwendigkeit für Recovery. Geräte gehen verloren, Credential Provider können gewechselt werden, Mitarbeitende verlieren Security Keys und Nutzer können versehentlich ihren letzten Passkey entfernen.

Ein System mit starkem Passkey-Login und schwachem Support-Reset hat deshalb weiterhin eine schwache Account-Grenze.

Planen Sie bewusst:

• Darf ein Konto mehrere Passkeys registrieren?
• Wird aktiv dazu ermutigt, einen zweiten Weg einzurichten?
• Welche Recovery-Methode existiert, wenn kein Passkey mehr verfügbar ist?
• Wie wird verhindert, dass Support allein aufgrund leicht beschaffbarer Daten Authentifizierung umgeht?
• Was passiert mit alten Sessions nach einem Recovery-Vorgang?
• Werden verlorene Credentials gezielt widerrufen?
• Ist der Recovery-Pfad genauso beobachtbar und auditierbar wie der normale Login?

Die richtige Frage lautet nicht: „Sind Passkeys phishing-resistent?“ Die Antwort darauf ist technisch sehr gut begründet. Die Produktfrage lautet: Kann ein Angreifer den Passkey einfach umgehen, indem er den schwächeren Wiederherstellungspfad nimmt?

10. Domain- und Login-Migrationen brauchen eine Credential-Strategie

Weil WebAuthn-Credentials an die RP ID gebunden sind, sind Domainwechsel keine reine DNS- oder Redirect-Aufgabe.

Wenn ein Produkt beispielsweise von einer alten, unabhängigen Domain auf eine neue umzieht, sollte das Auth-Team früh klären, wie bestehende Credentials behandelt werden. Dass ein HTTP-Redirect funktioniert, bedeutet nicht, dass ein Credential plötzlich zu einer anderen RP ID gehört.

Schon vor einem Relaunch sollte dokumentiert sein:

• welche RP ID aktuell verwendet wird,
• welche Origins serverseitig akzeptiert werden,
• welche neuen Hosts geplant sind,
• ob bestehende Credentials dort weiterhin gültig sein können,
• wie Nutzer bei Bedarf kontrolliert neue Credentials registrieren.

Das ist genau die Art von Abhängigkeit, die bei einem rein visuellen Relaunch gerne unsichtbar bleibt.

Ein pragmatischer Passkey-Audit

Ein guter Test deckt nicht nur die erfolgreiche Registrierung ab. Testen Sie mindestens diese Zustände:

1. Neues Konto registriert den ersten Passkey.
2. Bestehendes Konto fügt einen zweiten Passkey hinzu.
3. Login ohne vorherige Username-Eingabe über ein discoverable credential.
4. Conditional UI mit vorhandenem Passkey.
5. Conditional UI ohne verfügbaren Passkey und sauberer Fallback.
6. Login aus einem nicht erlaubten Origin.
7. Manipulierter oder wiederverwendeter Challenge.
8. Cross-Device-Anmeldung.
9. Widerruf eines einzelnen Credentials.
10. Login nach Widerruf mit einem anderen Credential.
11. Verlust des letzten verfügbaren Passkeys und Recovery.
12. Alte Sitzung nach Recovery oder sicherheitsrelevanter Credential-Änderung.
13. Staging- und Preview-Hosts gegen die Produktionskonfiguration.
14. Geplanter Domain- oder Login-Host-Wechsel.

Damit wird aus „der Passkey-Button funktioniert“ ein überprüfbares Authentifizierungsmodell.

Was Website-Pflichtencheck dabei prüfen würde

Von außen lässt sich nicht jede WebAuthn-Serverprüfung beweisen. Challenge-Speicherung, Credential-Datenmodell und interne Recovery-Regeln brauchen Testzugang, Staging oder Code-/Konfigurationssicht. Genau diese Grenze sollte ein Audit transparent machen.

Je nach Zugriff kann Website-Pflichtencheck unter anderem prüfen:

• HTTPS und reale Login-Origins,
• konfigurierte RP ID und geplante Host-Grenzen,
• erlaubte Origin-Liste,
• Challenge-Erzeugung, Lebensdauer und Einmalnutzung,
• Prüfung von clientDataJSON, Origin, RP-ID-Hash und Flags,
• Umgang mit User Verification,
• discoverable credentials und Credential-Zuordnung,
• mehrere Passkeys pro Konto,
• Conditional UI und Capability Detection,
• Cross-Device- und Fallback-Verhalten,
• Credential-Management und Widerruf,
• Recovery und Session-Invalidierung,
• Staging-, Preview- und Domain-Migrationsrisiken,
• Regressionstests über mehrere Browser und Geräte.

Der Nutzen eines Passkey-Audits ist nicht, ein modernes Häkchen in der Feature-Liste zu bekommen. Es ist eine präzise Antwort auf die Frage: Welche Kombination aus Domain, Browserkontext, Credential und serverseitigem Zustand darf dieses Konto wirklich öffnen?

WebAuthn Level 3 ist jetzt ein stabiler W3C-Referenzpunkt. Das ist ein guter Moment, um Passkeys nicht mehr als Experiment zu behandeln – und genauso wenig als magischen Login, bei dem der Browser schon alles richtig machen wird.

Die Kryptografie ist nur dann die starke Grenze, wenn Ihre RP-, Origin-, Recovery- und Account-Logik sie nicht wieder aufweicht.