Was ist WebAuthn? Definition, Beispiele & Best Practices

WebAuthn ist der W3C-Standard für passwortlose, phishing-resistente Authentifizierung. Erfahren Sie, wie es funktioniert, welche häufigen Bereitstellungsfehler es gibt und welche Best Practices für Unternehmen gelten.

Was ist WebAuthn?

Passwörter versagen. Sie werden durch Phishing abgegriffen, per Stuffing missbraucht, gesprüht und ausgeleitet. Der Verizon Data Breach Investigations Report (DBIR) 2026 stellte fest, dass missbräuchliche Nutzung von Zugangsdaten bei 39 % aller Sicherheitsverletzungen irgendwo eine Rolle spielte – die mit Abstand am weitesten verbreitete Technik im Datensatz. Deshalb priorisieren Verteidiger Kontrollen, die Passwörter aus dem Anmeldepfad entfernen. WebAuthn ist der Standard des World Wide Web Consortium (W3C), der genau dafür entwickelt wurde.

WebAuthn, kurz für Web Authentication, ist ein W3C-Webstandard, der eine Browser-API zum Erstellen und Verwenden starker, auf öffentlichen Schlüsseln basierender Anmeldeinformationen zur Authentifizierung von Benutzern bei Webanwendungen definiert. Anstatt gemeinsame Geheimnisse wie Passwörter auszutauschen, verwendet WebAuthn asymmetrische Kryptografie: Ihr Authenticator erzeugt pro Website ein eindeutiges Schlüsselpaar, hält den privaten Schlüssel in sicherer Hardware eingeschlossen und teilt nur den öffentlichen Schlüssel mit dem Server.

Die W3C-Spezifikation definiert dies formal als „eine API, die die Erstellung und Verwendung starker, attestierter, abgegrenzter, auf öffentlichen Schlüsseln basierender Anmeldeinformationen durch Webanwendungen zum Zweck der starken Authentifizierung von Benutzern ermöglicht“. Praktisch bedeutet das, dass Sie sich bei Webanwendungen per Fingerabdruckscan, Gesichtsentsperrung oder physischem Sicherheitsschlüssel anmelden können, und der Server erhält niemals etwas, das ein Angreifer wiederverwenden könnte.

WebAuthn ist eine Kernkomponente des FIDO2-Projekts, das in Abstimmung mit der Fast Identity Online (FIDO) Alliance entwickelt wurde. FIDO2 kombiniert WebAuthn (die Browser-API-Ebene) mit CTAP (Client to Authenticator Protocol), das die Kommunikation zwischen Ihrem Authenticator-Gerät und dem Browser über USB, Near Field Communication (NFC) oder Bluetooth Low Energy (BLE) verarbeitet. Zusammen bilden sie die Grundlage für passwortlose und phishing-resistente Authentifizierung im Web.

Zwei Vorfälle zeigen, was das Passwortmodell im großen Maßstab kostet. 2021 gelangten Angreifer über ein Legacy-Profil für ein virtuelles privates Netzwerk (VPN), das laut Aussage des CEO des Unternehmens vor dem US-Senat nicht für die Nutzung vorgesehen war, zu Colonial Pipeline. Colonial schaltete die Pipeline ab, um den Angriff einzudämmen, und zahlte 4,4 Millionen US-Dollar Lösegeld an einen DarkSide-Affiliate, die Ransomware-Operation, die in einer CISA-Warnmeldung behandelt wurde. Das Justizministerium beschlagnahmte später 2,3 Millionen US-Dollar davon. 2023 meldete MGM Resorts laut einem 8-K vom Oktober 2023 geschätzte negative finanzielle Auswirkungen in Höhe von 100 Millionen US-Dollar durch einen Cybervorfall, der mit Social Engineering gegen Identitäts-Workflows begann. Beide Vorfälle beruhten auf einem wiederverwendbaren Geheimnis. WebAuthn entfernt dieses aus dem Anmeldepfad.

WebAuthn vs. traditionelle Authentifizierung

Traditionelle Authentifizierung basiert auf gemeinsamen Geheimnissen. Passwörter, Einmalcodes und Push-Bestätigungen übertragen allesamt Daten, die ein Angreifer abfangen, wiedergeben oder in Echtzeit per Phishing erlangen kann. WebAuthn verändert das Modell, indem es gemeinsame Geheimnisse durch Public-Key-Kryptografie ersetzt, bei der der private Schlüssel niemals Ihre Authenticator-Hardware verlässt und nichts Wiederverwendbares das Netzwerk durchquert.

Die Unterschiede sind vor allem an den Punkten wichtig, an denen traditionelle Methoden versagen:

• Phishing-Resistenz. Passwortbasierte und OTP-basierte Authentifizierung kann durch Echtzeit-Phishing-Proxys abgegriffen werden. WebAuthn-Anmeldeinformationen sind kryptografisch an die Ursprungsdomäne gebunden, sodass eine bei login.example.com registrierte Anmeldeinformation nicht gegen login-example.com oder eine andere täuschend ähnliche Domäne authentifiziert. Der Browser erzwingt dies auf Protokollebene, unabhängig vom Urteilsvermögen des Benutzers.
• Serverseitige Exposition. Traditionelle Systeme speichern Passwort-Hashes oder gemeinsame Geheimnisse, die bei Datenbankverletzungen zu hochwertigen Zielen werden. WebAuthn speichert nur öffentliche Schlüssel. Eine vollständige Kompromittierung des Servers gibt einem Angreifer nichts, womit er sich als Benutzer ausgeben könnte.
• Wiederverwendung von Anmeldeinformationen. Benutzer verwenden Passwörter dienstübergreifend wieder, was Credential Stuffing im großen Maßstab effektiv macht. WebAuthn erzeugt pro Relying Party ein eindeutiges Schlüsselpaar, sodass eine kompromittierte Anmeldeinformation bei einem Dienst bei einem anderen keinerlei Wert hat.
• Abwägung zwischen Benutzerfreundlichkeit und Sicherheit. Längere Passwörter und häufige Rotation verbessern die Sicherheit auf dem Papier, verschlechtern aber die Nutzbarkeit. WebAuthn beseitigt diesen Zielkonflikt: Ein Fingerabdruckscan oder eine Gesichtsentsperrung bietet eine stärkere Authentifizierungssicherheit als jede Passwortrichtlinie – bei weniger Reibung für den Benutzer.

Der Nettoeffekt ist, dass WebAuthn die drei Vektoren eliminiert, die für die meisten auf Zugangsdaten basierenden Sicherheitsverletzungen verantwortlich sind: Phishing, serverseitiger Diebstahl und dienstübergreifende Wiederverwendung. Das Verständnis dieser Unterschiede schafft die Grundlage dafür, wie die Komponenten des Protokolls diese Eigenschaften durchsetzen.

Schlüsselkomponenten von WebAuthn

WebAuthn arbeitet mit einer Drei-Parteien-Architektur, die in der W3C-Spezifikation definiert ist.

Authenticator: Dies ist die kryptografische Entität, die Schlüsselpaare erzeugt und Authentifizierungs-Assertions signiert. Authenticators fallen in zwei Kategorien:

• Plattform-Authenticators sind in das Betriebssystem Ihres Geräts integriert: Windows Hello, Touch ID, Face ID. Sie lassen sich nahezu ohne Reibung registrieren, gehen aber verloren, wenn das Gerät verloren geht.
• Roaming-Authenticators (plattformübergreifend) sind portable Hardwaregeräte wie YubiKeys und FIDO-Sicherheitsschlüssel. Sie funktionieren über mehrere Geräte hinweg, erfordern aber physische Verteilung und Bestandsverwaltung.

Unabhängig davon, welchen Typ Sie wählen, bleibt das Sicherheitsmodell gleich: Der Authenticator erstellt pro Relying Party ein eindeutiges Schlüsselpaar, und der private Schlüssel verlässt niemals die sichere Grenze des Authenticators.

Relying Party (RP): Dies ist Ihre Webanwendung: clientseitiges JavaScript, das die WebAuthn-API aufruft, plus eine serverseitige Komponente, die die Speicherung und Verifizierung von Anmeldeinformationen verarbeitet. Die RP speichert nur den öffentlichen Schlüssel. Die RP-ID, typischerweise Ihr Domainname, dient als kryptografischer Anker für die Ursprungsbindung.

User Agent (Browser): Der Browser vermittelt alle Interaktionen zwischen Authenticators und Relying Parties. Er erzwingt Ursprungsrichtlinien, verhindert den Missbrauch von Anmeldeinformationen über Domänen hinweg und wahrt die Privatsphäre der Benutzer: Bei einem Ursprung registrierte Anmeldeinformationen können nicht von einem anderen verwendet werden – genau das stoppt Phishing auf Protokollebene.

WebAuthn definiert außerdem ein Attestierungs-Framework, mit dem Authenticators während der Registrierung ihre Echtheit kryptografisch nachweisen können. Ihr Unternehmen kann dann verifizieren, dass Anmeldeinformationen von vertrauenswürdigen, von der IT genehmigten Authenticator-Modellen stammen und nicht von unbekannten oder Consumer-Geräten. Der FIDO Metadata Service bietet einen Live-Mechanismus für Widerrufe und Hinweise zu Authenticator-Modellen.

Sobald Sie die Akteure und Vertrauensgrenzen kennen, können Sie die beiden Zeremonien abbilden und genau sehen, wo die Verifizierung fehlschlagen kann.

Wie WebAuthn funktioniert

WebAuthn definiert zwei kryptografische Zeremonien: Registrierung (Erstellung von Anmeldeinformationen) und Authentifizierung (Verifizierung von Assertions). Beide folgen einem Challenge-Response-Protokoll.

1. Registrierung (Erstellung von Anmeldeinformationen): Ihr Server erzeugt eine kryptografisch zufällige Challenge und sendet sie zusammen mit Informationen zur Relying Party, Details zum Benutzerkonto und akzeptablen kryptografischen Algorithmen an den Client. Der Client ruft navigator.credentials.create() auf. Der Authenticator fordert die ausdrückliche Zustimmung des Benutzers an, erzeugt ein neues asymmetrisches Schlüsselpaar und gibt ein Attestierungsobjekt zurück, das den öffentlichen Schlüssel, die signierte Challenge, die Credential-ID und (optional) eine Attestierungszertifikatskette enthält. Ihr Server verifiziert die Attestierung, validiert die Signatur, bestätigt, dass der öffentliche Schlüssel den angeforderten Algorithmen entspricht, und speichert den öffentlichen Schlüssel der Anmeldeinformation, die Credential-ID und den Signaturzähler. Kritische Schutzmaßnahme: Selbst bei identischen Parametern erzeugt navigator.credentials.create() bei jedem Aufruf eine neue Anmeldeinformation. Sie müssen den Parameter excludeCredentials verwenden, um doppelte Registrierungen zu verhindern.
2. Authentifizierung (Verifizierung von Assertions): Ihr Server erzeugt eine neue Challenge und sendet sie zusammen mit einer Liste zulässiger Credential-IDs an den Client. Der Client ruft navigator.credentials.get() auf. Der Authenticator verifiziert die Anwesenheit oder Identität des Benutzers (abhängig von Ihrer Richtlinie) und signiert dann die Challenge mit dem gespeicherten privaten Schlüssel. Ihr Server ruft den gespeicherten öffentlichen Schlüssel ab, verifiziert die Assertion-Signatur, validiert die Übereinstimmung der Challenge, prüft Flags für Benutzeranwesenheit/-verifizierung, bestätigt die Übereinstimmung von Ursprung und RP-ID und verifiziert, dass der Signaturzähler erhöht wurde.

Die Verifizierung des Signaturzählers ist Ihre Verteidigung gegen geklonte Authenticators. Wenn der Zähler nicht wie erwartet erhöht wird, haben Sie Hinweise auf eine Duplizierung von Anmeldeinformationen.

Für die AAL2-Konformität müssen Sie User Verification (UV) erzwingen, nicht nur User Presence (UP). Laut Leitfaden für synchronisierbare Authenticators müssen Verifier angeben, dass UV bevorzugt wird, und Antworten prüfen, um zu bestätigen, dass das UV-Flag gesetzt ist.

Wie Unternehmen WebAuthn einsetzen

Zu sehen, wo WebAuthn produktiv läuft, beantwortet die Frage, die die meisten Evaluatoren tatsächlich stellen: Ist das im großen Maßstab bewährt?

• Google Accounts ist der klarste Maßstab. Google begann im Mai 2023 mit der Einführung von Passkeys und machte sie im Oktober 2023 zum Standard für private Konten. Innerhalb eines Jahres nach dem Start wurden Passkeys mehr als eine Milliarde Mal über mehr als 400 Millionen Konten hinweg verwendet, und Google berichtete, dass Passkeys bereits täglich häufiger zur Authentifizierung genutzt wurden als SMS-OTP und Authenticator-Apps zusammen.
• GitHub bezeichnete WebAuthn als die stärkste verfügbare 2FA-Option, als es 2023 2FA für alle Mitwirkenden verpflichtend machte, und nannte physische Sicherheitsschlüssel und Plattform-Authenticators wie Windows Hello und Face ID die am wenigsten phishing-anfälligen Methoden.
• Kommerzielle Plattformen sind gefolgt: Amazon, PayPal, Shopify, DocuSign und Kayak, das die durchschnittliche Registrierungs- und Anmeldezeit um 50 % reduzierte, haben alle eine durch WebAuthn gestützte Anmeldung eingeführt. Diese Bereitstellungen bestätigen, dass WebAuthn im Consumer-Maßstab funktioniert, Recovery-Workflows verarbeitet und sich in Standardarchitekturen von Identity Providern integrieren lässt.

Wenn die Zeremonien und realen Bereitstellungen verstanden sind, ist die nächste Entscheidung, welcher Typ von Authenticator zu Ihrer Umgebung passt.

Typen von WebAuthn-Authenticators

Ihre Wahl des Authenticators bestimmt das Sicherheitsniveau, die Benutzererfahrung und den operativen Aufwand Ihrer WebAuthn-Bereitstellung. Jeder Typ bringt unterschiedliche Abwägungen mit sich, die für die Unternehmensplanung relevant sind.

1. Plattform-Authenticators sind in das Betriebssystem und die Hardware des Geräts eingebettet. Windows Hello verwendet eine durch ein Trusted Platform Module (TPM) gestützte PIN, Gesichtserkennung oder Fingerabdruck. Apple-Geräte verwenden Touch ID oder Face ID, abgesichert durch die Secure Enclave. Android-Geräte verwenden Fingerabdruck oder Gesichtsentsperrung über Google Play Services. Plattform-Authenticators 1tragen die geringste Registrierungsreibung, weil Benutzer die Hardware bereits besitzen, und biometrische Verifizierung erfüllt die Anforderungen an User Verification (UV) für die AAL2-Konformität ohne zusätzliche Schritte. Die Einschränkung ist, dass Anmeldeinformationen an das Gerät gebunden sind. Wenn ein Benutzer seinen Laptop oder sein Telefon verliert, sind diese Anmeldeinformationen verloren, sofern Sie keine synchronisierten Passkeys verwenden.
2. Roaming-Authenticators (plattformübergreifend) sind portable Hardware-Token wie YubiKeys, Feitian BioPass-Schlüssel oder andere FIDO2-Sicherheitsschlüssel, die über USB, NFC oder BLE verbunden werden. Sie funktionieren über mehrere Geräte und Betriebssysteme hinweg und sind daher die Standardwahl für privilegierten Zugriff, gemeinsam genutzte Arbeitsplatzumgebungen und Anwendungsfälle mit hohem Sicherheitsniveau. Der Zielkonflikt liegt in der Verteilungslogistik: Sie müssen physische Geräte beschaffen, versenden, inventarisieren und verwalten, und Benutzer müssen sie mit sich führen.
3. Synchronisierte Passkeys sind eine neuere Kategorie, bei der WebAuthn-Anmeldeinformationen über einen Passwortmanager der Plattform synchronisiert werden (iCloud Keychain, Google Password Manager oder ein Drittanbieter-Manager wie 1Password). Synchronisierte Passkeys verringern das Recovery-Problem bei Geräteverlust, weil die Anmeldeinformation auf jedem Gerät erhalten bleibt, das mit demselben Konto verbunden ist. Für die meisten Unternehmensbenutzer beseitigt dies den größten Reibungspunkt bei der Einführung von WebAuthn. Der Zielkonflikt besteht darin, dass die Sicherheit Ihrer Authentifizierung nun teilweise von der Sicherheit des Plattformkontos abhängt, das die synchronisierte Anmeldeinformation hostet. Für Umgebungen mit hohen Sicherheitsanforderungen bleiben gerätegebundene Anmeldeinformationen mit von der IT verwalteten Backup-Schlüsseln die stärkere Wahl.

Die meisten Unternehmensbereitstellungen verwenden eine Kombination: Plattform-Authenticators für die tägliche Nutzung, einen Roaming-Schlüssel als registriertes Backup und synchronisierte Passkeys dort, wo das Risikoprofil dies zulässt. Die Wahl der richtigen Mischung hängt von Ihren Sicherheitsanforderungen, Ihrer Benutzerpopulation und davon ab, wie viel operativen Aufwand Sie tragen können.

Die Entscheidung für einen Authenticator beeinflusst direkt die Sicherheitseigenschaften, die Sie gewinnen, und genau darum geht es im nächsten Abschnitt.

Sicherheitsvorteile von WebAuthn

WebAuthn bietet konkrete Sicherheitsvorteile in Bezug auf Phishing-Resistenz, serverseitige Exposition, regulatorische Compliance und die Verhinderung dienstübergreifender Angriffe:

• Phishing-Resistenz auf Protokollebene. WebAuthn bindet Anmeldeinformationen kryptografisch an den Ursprung. Der NIST-Kommentar der FIDO Alliance warnte, dass Angreifer zu AAL2-Authenticators aufgeschlossen haben, die nicht phishing-resistent sind. WebAuthn schließt diese Lücke.
• Keine gemeinsamen Geheimnisse auf dem Server.Das Public-Key-Kryptografie-Modell von FIDO2 beseitigt die Notwendigkeit, Geheimnisse zwischen dem Identity Provider und dem Authenticator zu teilen – genau das bezeichnet NIST SP 800-63B-4 als Widerstandsfähigkeit gegen Verifier-Kompromittierung. Eine vollständige Datenbankverletzung liefert nichts, was ein Angreifer wiedergeben könnte.
• Regulatorische Ausrichtung. WebAuthn erfüllt die phishing-resistenten Anforderungen von NIST SP 800-63B-4 AAL2. Das Memorandum M-22-09 des Office of Management and Budget (OMB) der US-Regierung nennt den W3C-Web-Authentication-Standard ausdrücklich als phishing-resistenten Ansatz für Bundesbehörden. Regulierte Organisationen erhalten einen klaren, auditierbaren Compliance-Pfad.
• Beseitigung von Angriffen über den menschlichen Faktor. Der Verizon DBIR 2026   bezifferte den menschlichen Faktor auf 62 % der Sicherheitsverletzungen. WebAuthn beseitigt zwei kritische menschliche Angriffsflächen: die Auswahl schwacher Passwörter und die Anfälligkeit für Phishing. Benutzer können keine schlechten Passwörter wählen, wenn es keine Passwörter gibt.
• Verhinderung von dienstübergreifendem Credential Stuffing. Jede Anmeldeinformation ist kryptografisch auf eine bestimmte Domäne begrenzt, wodurch Credential Stuffing dienstübergreifend deutlich weniger effektiv wird.

Diese Sicherheitseigenschaften sind nicht theoretisch. Die Organisationen, die WebAuthn im großen Maßstab eingeführt haben, haben sie bereits produktiv validiert, und die Anwendungsfälle erstrecken sich über nahezu jede Branche.

Häufige Anwendungsfälle für WebAuthn

Die Einführung von WebAuthn konzentriert sich auf Szenarien, in denen Angriffe auf Basis von Zugangsdaten die größten geschäftlichen Auswirkungen haben. Dies sind die Bereitstellungsmuster, die in Produktionsumgebungen am häufigsten auftreten.

• Privilegierter Zugriff und Admin-Konsolen. VPN-Portale, Cloud-Management-Konsolen und Infrastruktur-Admin-Panels sind die wertvollsten Ziele für Diebstahl von Zugangsdaten. Die Bereitstellung von WebAuthn als verpflichtender zweiter Faktor oder als primäre passwortlose Methode für diese Zugriffspunkte entfernt die Angriffsfläche, die Phishing-Kits und Credential Dumps am aggressivsten ausnutzen. Dies ist typischerweise die erste Phase bei jeder Unternehmens-Einführung.
• Kundenorientierte Anmeldung für Finanzdienstleistungen und Gesundheitswesen. Regulierte Branchen, in denen die Kompromittierung von Zugangsdaten Meldepflichten bei Sicherheitsverletzungen, regulatorische Strafen und direkte finanzielle Verluste auslöst, führen Passkeys für die Kundenauthentifizierung ein. Banking-Anwendungen, Patientenportale und Versicherungsplattformen verwenden WebAuthn, um sowohl Compliance-Anforderungen (PCI DSS, HIPAA-Zugriffskontrollen) als auch das operative Ziel der Reduzierung von Account-Takeover-Betrug zu erfüllen.
• Gemeinsam genutzte Arbeitsstationen und Kiosk-Umgebungen. Krankenhäuser, Fertigungsbereiche und Einzelhandelsbetriebe nutzen gemeinsam genutzte Terminals, bei denen passwortbasierte Anmeldung langsam und anfällig für Shoulder Surfing ist. Roaming-Authenticators (NFC-fähige Sicherheitsschlüssel oder Badge-Tap-Lösungen) authentifizieren Benutzer in Sekunden, ohne dass Anmeldeinformationen in ein gemeinsam genutztes Gerät eingegeben werden.
• Single Sign-On (SSO) für die Belegschaft. Die Bereitstellung von WebAuthn auf Ebene des Identity Providers (IdP) über Plattformen wie Okta, Azure AD oder Ping Identity schützt jede nachgelagerte Anwendung in einer föderierten Umgebung mit einer einzigen Registrierung. Dies ist der effizienteste Weg zu breiter Abdeckung, weil Sie WebAuthn einmal beim IdP bereitstellen und jede Relying Party für Security Assertion Markup Language (SAML) oder OpenID Connect (OIDC) die phishing-resistente Authentifizierung übernimmt.

Jeder dieser Anwendungsfälle bekräftigt dasselbe Prinzip: Je näher Sie daran kommen, wiederverwendbare Geheimnisse aus Ihrem Authentifizierungsfluss zu eliminieren, desto weniger auf Zugangsdaten basierende Angriffswege bleiben offen. Dennoch bringt die Bereitstellung von WebAuthn im großen Maßstab operative Komplexität mit sich, die Teams einplanen müssen.

Herausforderungen und Einschränkungen von WebAuthn

Das Sicherheitsmodell von WebAuthn ist solide, aber Unternehmensbereitstellungen bringen operative Komplexität ans Licht, die Teams konsequent unterschätzen:

• Management des Lebenszyklus von Anmeldeinformationen. Der primäre Ausfallmodus bei WebAuthn-Bereitstellungen in Unternehmen ist operativ, nicht kryptografisch. Sie benötigen dokumentierte Prozesse für die Verteilung von Authenticators, den Widerruf von Anmeldeinformationen bei Geräteverlust, Erneuerungsrichtlinien und Benutzersupport bei Authentifizierungsfehlern. Der FIDO-Leitfaden zum Lebenszyklus behandelt Registrierungs-, Recovery- und Widerrufsphasen im Detail.
• Auswahl des Authenticator-Typs. Sie stehen vor einer strategischen Entscheidung zwischen Plattform-Authenticators (keine Verteilungskosten, gehen mit dem Gerät verloren), Roaming-Authenticators (portabel, aber mit physischer Verteilung) und hybriden Ansätzen. Jeder bringt unterschiedliche Sicherheitsniveaus, Recovery-Anforderungen und operativen Aufwand mit sich.
• Integration von Legacy-Anwendungen. Nicht jede Anwendung in Ihrer Umgebung unterstützt WebAuthn nativ. Sie müssen die Integration mit Föderationsprotokollen wie SAML, OAuth und OpenID Connect adressieren. Dies ist eine erhebliche Herausforderung für Organisationen mit komplexen Topologien der Identitätsföderation.
• Architekturentscheidungen für FIDO-Server. Sie müssen zwischen der Integration eines FIDO-Servers in Ihren bestehenden Identity Provider, der Bereitstellung eines eigenständigen FIDO-Servers oder einem FIDO-Server-as-a-Service-Modell wählen. Jede Option wirkt sich auf die Architektur der Speicherung von Anmeldeinformationen, Disaster-Recovery-Verfahren und den Umfang der Einführung aus. Der Leitfaden zur Bereitstellung von FIDO-Servern behandelt die Zielkonflikte im Detail.
• Der Zielkonflikt bei synchronisierten Anmeldeinformationen. Die Synchronisierung von Passkeys über die Passwortmanager großer Plattformen reduziert die Benutzerreibung drastisch, verlagert aber einen Teil der Authentifizierungssicherheit auf die Sicherheit des Plattformkontos. Wo die Sicherheitsanforderungen am höchsten sind, bleiben gerätegebundene Anmeldeinformationen mit von der IT verwalteten Backup-Schlüsseln die stärkere Wahl.

Über die operative Komplexität hinaus schaffen bestimmte Implementierungsentscheidungen eine nachhaltigere Exposition:

• Alle MFA als phishing-resistent behandeln. Dies ist der Fehler mit der größten Auswirkung. Wenn Sie TOTP, SMS-OTP oder Push-Benachrichtigungs-MFA bereitstellen und phishing-resistente Compliance beanspruchen, bleiben Sie exponiert. Echtzeit-Phishing-Proxys erfassen und wiederholen bei diesen Ansätzen beide Faktoren. Nur WebAuthn mit Verifier Name Binding oder Channel Binding erreicht echte Phishing-Resistenz.
• Unauthentifizierte Registrierung von Anmeldeinformationen zulassen. CVE-2021-3632 demonstrierte dies in Keycloak, wo jeder ein neues Sicherheitsgerät registrieren konnte, wenn für ein Benutzerkonto kein Gerät vorhanden war. Die Registrierung muss innerhalb einer bereits authentifizierten Sitzung oder über verifizierte Out-of-Band-Prozesse erfolgen.
• Schlechtes Design des Registrierungsablaufs. Eine holprige Registrierung erzeugt Benutzerwiderstand und erhöht das Volumen von Support-Tickets. Ihr Registrierungsportal sollte Benutzer innerhalb einer authentifizierten Sitzung durch die Registrierung führen, klare Anweisungen zu akzeptablen Authenticators geben und erklären, warum bestimmte Geräte abgelehnt wurden.
• Fehlende Fallback- und Recovery-Mechanismen. Die Bereitstellung von WebAuthn ohne dokumentierte Fallback-Verfahren für Geräteverlust, Hardwarefehler oder biometrische Probleme führt zu Aussperrungsszenarien. Sie benötigen vorab registrierte Backup-Authenticators, Notfallzugriffscodes für IT-Administratoren und Prozesse zur persönlichen Verifizierung.
• WebAuthn isoliert von Ihrem Security-Stack bereitstellen. WebAuthn ist keine eigenständige Lösung. Laut NIST SP 1800-35 sollte es in die kontinuierliche Bewertung der Authentifizierung, die Verifizierung des Gerätezustands, kontextabhängige Zugriffsrichtlinien und Ihre Endpoint-Sicherheitsinfrastruktur integriert werden. In einer Zero-Trust-Architektur wird WebAuthn zu einem der stärksten Signale, die Sie in Zugriffsentscheidungen einfließen lassen können.

Diese Herausforderungen sind mit der richtigen Planung lösbar. Die folgenden Praktiken behandeln die wichtigsten Entscheidungen, die eine produktionsreife Bereitstellung von einem Proof of Concept unterscheiden.

Best Practices für die Implementierung von WebAuthn

Die folgenden Praktiken behandeln die wichtigsten Entscheidungen, die eine produktionsreife WebAuthn-Bereitstellung von einem Proof of Concept unterscheiden.

User Verification für AAL2 erzwingen. Setzen Sie userVerification: "required" sowohl in den Registrierungs- als auch in den Authentifizierungszeremonien und validieren Sie das UV-Flag serverseitig. Verlassen Sie sich bei Compliance-relevanten Bereitstellungen nicht auf "preferred".

Attestierung verwenden, um Authenticator-Richtlinien durchzusetzen. Prüfen Sie Attestierungen während der Registrierung und lassen Sie nur Authenticators zu, die Ihre Sicherheitsanforderungen erfüllen (zum Beispiel FIDO-L1+-Zertifizierung). Verwenden Sie auf AAGUID (Modellkennung des Authenticators) basierende Allowlists und integrieren Sie den FIDO Metadata Service für Live-Statusprüfungen von Authenticators.

Phasenweise bereitstellen. Die Empfehlung zur phasenweisen FIDO-Einführung ist ein gestufter Ansatz:

1. WebAuthn als zweiter Faktor für Hochrisikoanwendungen (VPN, privilegierter Zugriff, Admin-Konsolen)
2. Plattformweite Einführung als zweiter Faktor bei gleichzeitigem Aufbau operativer Unterstützung
3. Discoverable Credentials und passwortlose Flows für reife Benutzerpopulationen
4. Vollständig passwortlos, wobei Legacy-Authentifizierung für registrierte Benutzer eingestellt wird

Mit diesem Ansatz können Sie Richtlinien, Support- und Recovery-Workflows validieren, bevor Sie WebAuthn zum Standard machen.

Eine Recovery-Strategie mit mehreren Authenticators implementieren. Registrieren Sie mindestens zwei Authenticators pro Benutzer: einen primären (zum Beispiel Plattform-Authenticator für die tägliche Nutzung) und ein Backup (zum Beispiel sicher aufbewahrter Sicherheitsschlüssel). Zeigen Sie registrierte Recovery-Anmeldeinformationen in den Kontoeinstellungen des Benutzers klar an.

Signaturzähler verifizieren. Prüfen Sie, dass der Signaturzähler bei jeder Authentifizierung monoton ansteigt. Ein Zähler, der nicht ansteigt, signalisiert einen potenziell geklonten Authenticator.

Erwartete von unerwarteten Fehlern trennen. Verfolgen Sie WebAuthn-Fehler explizit. Gruppieren Sie NotAllowedError, AbortError und Passkey-Fehler des Credential Managers als separate Signale, damit Sie Benutzerreibung von Sicherheitsanomalien unterscheiden können.

Wenn Sie diese Praktiken befolgen, bringen Sie Ihre WebAuthn-Bereitstellung in einen produktionsreifen Zustand. Aber selbst eine korrekt konfigurierte WebAuthn-Einführung ist keine vollständige Identitätsverteidigung. Die Angriffe, die WebAuthn vollständig umgehen, erfordern Kontrollen, die über die Anmeldezeremonie hinaus wirken: Session Hijacking, laterale Bewegung nach der Authentifizierung und Helpdesk-Social Engineering.

Wie SentinelOne die Identitätssicherheit verbessert

WebAuthn reduziert die Wiederholung von Anmeldeinformationen, stoppt aber nicht jeden identitätsbezogenen Angriffspfad, den Sie in Produktionsumgebungen sehen werden. Sie müssen weiterhin Session-Token-Diebstahl, Gerätek kompromittierung, Helpdesk-Social-Engineering und laterale Bewegung nach der Authentifizierung bewältigen.

Die Singularity™ Platform schließt diese Lücke, indem sie Identitäts- und Endpoint-Kontext korreliert:

• Singularity Identity erkennt verdächtiges Identitätsverhalten und reagiert, wenn Angreifer Verzeichnisdienste und SSO-Workflows ins Visier nehmen. Es deckt die Identitätsinfrastruktur ab, die WebAuthn nie berührt.
• Singularity Endpoint führt verhaltensbasierte und statische KI-Modelle auf dem Gerät aus, um Malware zum Diebstahl von Anmeldeinformationen und Hands-on-Keyboard-Aktivitäten zu stoppen, die Anmeldekontrollen vollständig umgehen. Es kennzeichnet bösartige Muster in Echtzeit ohne menschliches Eingreifen, was wichtig ist, wenn Angreifer auf Sitzungen statt auf Passwörter abzielen.
• Purple AI™ analysiert Ihre Sicherheitsdaten, um Untersuchungen zu steuern und nächste Schritte zu empfehlen. Ein IDC Snapshot 2025 ergab, dass Kunden Bedrohungen 63 % schneller identifizieren, was wichtig ist, wenn Sie feststellen müssen, ob eine fehlgeschlagene WebAuthn-Anmeldung auf Benutzerreibung oder eine aktive Phishing-Kampagne zurückzuführen war.

Zusammen sichern sie den Identitätsangriffspfad auf beiden Seiten der Anmeldung ab.

Wenn Sie WebAuthn als ein starkes Signal innerhalb Ihres umfassenderen Programms zur Phishing-Abwehr und Incident-Response-Workflows behandeln, können Sie sowohl das Risiko einer Kontoübernahme als auch den Zeitaufwand zur Klärung des Vorfalls reduzieren.

Demo anfordern, um zu sehen, wie SentinelOne die Lücke zwischen Authentifizierung und vollständiger Identitätsverteidigung schließt.

Tour starten

Erhalten Sie Echtzeitschutz für Identitäten und vollständige Transparenz in hybriden Umgebungen, um Exponierungen zu erkennen, Missbrauch von Anmeldedaten zu stoppen und Identitätsrisiken zu reduzieren.

Wichtige Erkenntnisse

WebAuthn ist der W3C-Standard für passwortlose, phishing-resistente Webauthentifizierung unter Verwendung von Public-Key-Kryptografie. Es bindet Anmeldeinformationen kryptografisch an bestimmte Domänen, wodurch die Wiederholung von Anmeldeinformationen architektonisch unmöglich wird. 

Eine erfolgreiche Bereitstellung im Unternehmen erfordert eine phasenweise Einführung, auf Attestierung basierende Authenticator-Richtlinien, Recovery-Strategien für mehrere Geräte und die Integration in Ihren umfassenderen Security-Stack.

FAQs

Was ist WebAuthn in der Cybersicherheit?

WebAuthn, kurz für Web Authentication, ist ein W3C-Webstandard, der eine Browser-API zum Erstellen und Verwenden starker, auf öffentlichen Schlüsseln basierender Anmeldeinformationen definiert, um Benutzer bei Webanwendungen zu authentifizieren. 

Anstelle von Passwörtern verwendet es asymmetrische Kryptografie: Ihr Authenticator erzeugt pro Website ein eindeutiges Schlüsselpaar, bewahrt den privaten Schlüssel in sicherer Hardware auf und teilt nur den öffentlichen Schlüssel mit dem Server. Dadurch sind der Diebstahl von Anmeldeinformationen und Phishing-Angriffe deutlich schwerer durchzuführen.

Welche Angriffe verhindert WebAuthn?

Die primäre Sicherheitseigenschaft von WebAuthn ist Phishing-Resistenz durch kryptografische Domain-Bindung. Wenn Sie einen Zugangsnachweis registrieren, wird er an den exakten Ursprung der vertrauenden Partei gebunden. Wenn Sie sich authentifizieren, schließt der Browser diesen Ursprung kryptografisch in die signierte Antwort ein, sodass ein Angreifer auf einer täuschend ähnlichen Domain Ihren Zugangsnachweis nicht erneut verwenden kann. 

Über Phishing hinaus eliminiert WebAuthn den serverseitigen Diebstahl von Zugangsdaten, da nur öffentliche Schlüssel gespeichert werden, und verhindert Credential Stuffing, da jeder Zugangsnachweis auf eine einzelne Domain beschränkt ist.

Ist WebAuthn dasselbe wie FIDO2?

WebAuthn und FIDO2 sind verwandt, aber nicht identisch. FIDO2 ist das umfassendere Projekt, das von der FIDO Alliance in Abstimmung mit dem W3C entwickelt wurde und zwei Spezifikationen kombiniert: WebAuthn (die Browser-API zum Erstellen und Verifizieren von Public-Key-Anmeldeinformationen) und CTAP (Client to Authenticator Protocol, das die Kommunikation zwischen Ihrem Authenticator und dem Browser über USB, NFC oder BLE verarbeitet). 

WebAuthn ist die webbasiert ausgerichtete Hälfte von FIDO2. Sie implementieren WebAuthn in Ihrer Anwendung. CTAP läuft zwischen der Authenticator-Hardware und dem Browser.

Wie unterstützt WebAuthn Zero-Trust-Sicherheit?

WebAuthn bietet eines der stärksten Authentifizierungssignale in einer Zero-Trust-Architektur. Gemäß NIST SP 1800-35 lässt es sich in die kontinuierliche Bewertung der Authentifizierung, die Überprüfung des Gerätezustands und kontextabhängige Zugriffsrichtlinien integrieren. Da WebAuthn-Anmeldeinformationen phishing-resistent und an Domains gebunden sind, dienen sie als Identitätsprüfung mit hohem Vertrauensniveau, die in umfassendere Zugriffsentscheidungen einfließt. 

In der Praxis liefert die Kombination von WebAuthn mit Endpoint-Telemetrie und Verhaltensanalysen Ihrer Richtlinien-Engine ein vertrauenswürdigeres Authentifizierungssignal als jedes Passwort oder jede Legacy-MFA-Methode.

Welche Browser und Plattformen unterstützen WebAuthn?

Laut Can I Use ist WebAuthn in etwa 95 % der globalen Browser verfügbar. Alle Evergreen-Desktop-Browser unterstützen es: Chrome (v67+), Firefox (v60+), Safari (v14+) und Edge (v18+). Auf Mobilgeräten unterstützen Chrome für Android, Safari auf iOS und Samsung Internet WebAuthn. 

Bei Plattform-Authentifikatoren wird Windows Hello unter Windows 10+ mitgeliefert (Gesichtserkennung, Fingerabdruck, PIN über TPM), macOS/iOS 16+ unterstützt Touch ID und Face ID mit iCloud Keychain-Synchronisierung für Passkeys, und Android 9+ bietet Fingerabdruck- und Gesichtsentsperrung über Google Play Services. Lücken bestehen weiterhin bei älteren Betriebssystemversionen und einigen eingeschränkten Browserkonfigurationen in Unternehmen.

Was ist der Unterschied zwischen WebAuthn und Passkeys?

WebAuthn ist die W3C-API-Spezifikation, die Browser für die Erstellung und Authentifizierung von Anmeldeinformationen mit öffentlichen Schlüsseln implementieren. Passkeys sind ein benutzerorientierter Begriff für WebAuthn-Anmeldeinformationen und beziehen sich häufig speziell auf synchronisierte (cloudgestützte) Anmeldeinformationen, die über Plattformanbieter geräteübergreifend synchronisiert werden. 

Alle Passkeys verwenden im Hintergrund WebAuthn, aber nicht alle WebAuthn-Anmeldeinformationen sind synchronisierte Passkeys. Gerätegebundene WebAuthn-Anmeldeinformationen bleiben an bestimmte Hardware gebunden.

Kann WebAuthn alle Formen von MFA ersetzen?

WebAuthn kann je nach Ihrer Konfiguration als Ein-Faktor- (Besitz des Authenticators), Zwei-Faktor- (Besitz plus Biometrie oder PIN) oder Multi-Faktor-Authentifizierung fungieren. 

Für die AAL2-Konformität müssen Sie die Benutzerverifizierung (Biometrie oder PIN) erzwingen und das UV-Flag serverseitig validieren. WebAuthn ersetzt ältere MFA-Methoden wie TOTP und SMS-OTP und bietet dabei eine stärkere Phishing-Resistenz als jede dieser Methoden.

Was passiert, wenn ein Benutzer seinen WebAuthn-Authenticator verliert?

Ohne einen Wiederherstellungsplan werden sie ausgesperrt. Best Practice ist, mindestens zwei Authenticatoren pro Benutzer zu registrieren: ein primäres Gerät für die tägliche Nutzung und ein sicher aufbewahrtes Backup. 

Ihr Kontowiederherstellungsprozess sollte außerdem Notfallzugriffscodes für IT-Administratoren und einen persönlichen Verifizierungspfad für Umgebungen mit hohem Sicherheitsniveau umfassen, in denen keine Backup-Authenticatoren verfügbar sind.

Funktioniert WebAuthn mit föderierten Identitätssystemen?

Ja, aber die Integration erfordert Planung. WebAuthn arbeitet in föderierten Umgebungen mit SAML, OAuth oder OpenID Connect auf der Ebene des Identity Providers (IdP). Ihr IdP verarbeitet den WebAuthn-Ablauf und stellt dann Föderationstoken für nachgelagerte Anwendungen aus. 

Das bedeutet, dass Sie WebAuthn beim IdP statt bei jeder einzelnen Anwendung bereitstellen, was die Einführung über föderierte Dienste hinweg vereinfacht.

Wie schützt WebAuthn vor Man-in-the-Middle-Angriffen?

Der Browser bindet den Ursprung (die Domain) kryptografisch in die Daten ein, die der Authenticator bei jedem Authentifizierungsablauf signiert. Ein Man-in-the-Middle-Angreifer kann eine Authentifizierungsbestätigung nicht an eine andere Domain weiterleiten, da die Signatur für keinen anderen Ursprung als denjenigen gültig ist, bei dem die Anmeldeinformationen registriert wurden. 

Dieser Schutz wirkt auf Protokollebene, unabhängig von TLS oder der Aufmerksamkeit des Benutzers.