Passkeys haben den Wendepunkt überschritten — Passwörter verlieren

Jahrelang war die passwortlose Zukunft eine PowerPoint-Folie – vielversprechend, ständig "in Kürze verfügbar" und nie ganz angekommen. Das hat sich geändert. Bis Mitte 2026 sind Passkeys von einer experimentellen Funktion zur Standard-Authentifizierung für Hunderte Millionen Konten geworden. Google, Apple, Microsoft, Amazon, GitHub, Shopify, PayPal und WhatsApp haben Passkeys entweder zum Standard gemacht oder als primäre empfohlene Anmeldeinformation eingeführt. Der Übergang ist nicht mehr theoretisch. Er findet statt, und die ihn untermauernden Sicherheitsdaten sind beeindruckend.

Was Passkeys eigentlich sind

Passkeys sind eine Implementierung des FIDO2/WebAuthn-Standards, einer Spezifikation, die gemeinsam von der FIDO Alliance und dem W3C entwickelt wurde. Im Kern verwenden Passkeys asymmetrische Public-Key-Kryptographie: Wenn Sie einen Passkey bei einem Dienst registrieren, erzeugt Ihr Gerät ein Schlüsselpaar. Der private Schlüssel verlässt niemals Ihr Gerät (oder Ihre synchronisierte Schlüsselverwaltung). Der Dienst speichert nur den öffentlichen Schlüssel. Wenn Sie sich authentifizieren, sendet der Dienst eine kryptografische Herausforderung (Challenge); Ihr Gerät signiert diese mit dem privaten Schlüssel; der Server überprüft die Signatur mit dem gespeicherten öffentlichen Schlüssel.

Es wird kein Passwort übertragen. Es existiert kein gemeinsames Geheimnis auf dem Server, das gestohlen werden könnte. Ein Datenbank-Leck, das jede gespeicherte Anmeldeinformation preisgibt, leckt nur öffentliche Schlüssel – wertlos für einen Angreifer ohne die entsprechenden privaten Schlüssel, die auf den Geräten der Benutzer verbleiben.

Gerätegebundene vs. synchronisierte Passkeys

Es gibt zwei grundlegend unterschiedliche Bereitstellungsmodelle, und der Unterschied ist sowohl für die Sicherheit als auch für die Benutzerfreundlichkeit von Bedeutung:

• Gerätegebundene Passkeys (auch hardwaregebundene oder nicht auffindbare Anmeldeinformationen genannt) werden in einem Hardware-Sicherheitsmodul gespeichert – einem TPM-Chip unter Windows, der Secure Enclave auf Apple Silicon oder einem FIDO2-Hardwareschlüssel wie einem YubiKey. Der private Schlüssel ist physisch nicht exportierbar. Wenn das Gerät verloren geht, ist der Passkey weg. Dies ist das Modell mit der höchsten Sicherheit und eignet sich für Unternehmen, hochwertige Konten und sicherheitsbewusste Personen, die bereit sind, Ersatzschlüssel zu verwalten.
• Synchronisierte Passkeys werden in einer cloudbasierten Schlüsselverwaltung gespeichert – Apples iCloud Keychain, Google Password Manager oder einem Drittanbieter-Manager wie 1Password oder Bitwarden. Das Material des privaten Schlüssels wird verschlüsselt, auf Ihren Geräten synchronisiert und kann einen Geräteverlust überstehen. Dies opfert eine enge Hardware-Attestierungsgarantie zugunsten einer deutlich besseren Benutzerfreundlichkeit und Wiederherstellbarkeit. Für die überwältigende Mehrheit der Verbraucher-Anwendungsfälle stellen synchronisierte Passkeys eine enorme Sicherheitsverbesserung gegenüber Passwörtern dar, ohne nennenswerte praktische Nachteile.

Die Spezifikationsaktualisierung der FIDO Alliance von 2023 standardisierte synchronisierte Passkeys formell, nachdem man erkannt hatte, dass reine Hardware-Passkeys eine Hürde für die Einführung darstellten, die Benutzer bei Passwörtern hielt – das schlechteste Ergebnis für die Gesamtsicherheit.

Der Authentifizierungsablauf, Schritt für Schritt

Das Verständnis dessen, was während einer WebAuthn-Authentifizierung im Hintergrund passiert, hilft zu erklären, warum Phishing-Angriffe bei Passkeys scheitern:

• Registrierung: Der Browser ruft navigator.credentials.create() mit einer Herausforderung (Challenge) vom Server auf. Der Authentifikator (Gerät, Plattform oder Hardwareschlüssel) erzeugt ein Schlüsselpaar, das auf die genaue relying party ID (die Domain) beschränkt ist. Der öffentliche Schlüssel und eine Anmeldeinformations-ID werden an den Server gesendet und gespeichert.
• Authentifizierung: Der Server gibt eine neue zufällige Herausforderung aus. Der Browser ruft navigator.credentials.get() auf. Der Authentifikator prüft, ob Ursprung (origin) und relying party ID exakt übereinstimmen – ein für google.com registrierter Passkey weigert sich, eine Herausforderung von g00gle.com zu signieren. Nach biometrischer Überprüfung oder PIN-Eingabe signiert der private Schlüssel die Herausforderung. Der Server überprüft die Signatur.
• Die Phishing-Barriere: Da der Passkey zum Zeitpunkt der Registrierung an den genauen Ursprung gebunden ist, kann eine Phishing-Website Anmeldeinformationen nicht abfangen oder wiederverwenden. Selbst wenn ein Benutzer getäuscht wird, eine ähnlich aussehende Website zu besuchen, weigert sich der Authentifikator, eine gültige Signatur für einen anderen Ursprung zu erzeugen. Dies ist der Mechanismus, der für die nahezu Null-Phishing-Rate bei Passkey-Konten verantwortlich ist.

Einführungszahlen: Was die Daten zeigen

Google berichtete auf der Google I/O 2024, dass über 800 Millionen Google-Konten Passkeys aktiviert hatten, gegenüber 400 Millionen Ende 2023. Anfang 2025 begann Google, Benutzer während des Anmeldevorgangs zur Erstellung von Passkeys aufzufordern und standardmäßig die Passkey-Ersteinrichtung für neue Kontoanmeldungen einzuführen. Interne Google-Daten, die in ihrem Sicherheitsblog zitiert wurden, zeigten, dass Passkey-Anmeldungen 4x schneller abgeschlossen wurden als Passwort + SMS-2FA-Abläufe.

Noch wichtiger: Die internen Phishing-Kennzahlen von Google für Konten, die auf reine Passkey-Authentifizierung umgestellt hatten, zeigten Kompromittierungsraten durch Phishing nahe Null – verglichen mit einer Basislinie von Passwortkonten, bei denen selbst mit 2FA SIM-Swap- und AiTM (Adversary-in-the-Middle)-Phishing-Angriffe weiterhin erfolgreich waren.

Apple führte die Passkey-Unterstützung in iOS 16 und macOS Ventura (2022) ein und hatte bis 2025 Passkeys zur standardmäßig vorgeschlagenen Methode im Passwort-Manager von Safari gemacht. Microsoft aktivierte Passkeys für Verbraucher-Microsoft-Konten im Jahr 2023 und weitete dies 2024 auf Entra ID (Azure AD) für Unternehmen aus. GitHub machte Passkeys 2023 allgemein verfügbar und verzeichnete eine besonders starke Akzeptanz bei Entwicklerkonten – einem hochwertigen Zielsegment, in dem Phishing-Resistenz entscheidend ist.

Plattform- und Ökosystem-Unterstützung

Apple: iCloud Keychain Passkeys

Die Implementierung von Apple synchronisiert Passkeys Ende-zu-Ende-verschlüsselt über iCloud Keychain. Passkeys funktionieren auf iPhone, iPad, Mac und – seit iOS 17 – können mit Familienmitgliedern geteilt oder über QR-Code-Näherungsauthentifizierung auf Nicht-Apple-Geräten verwendet werden. Die Secure Enclave erzwingt eine biometrische Überprüfung (Face ID oder Touch ID) vor jeder Signieroperation. Apple unterstützt über ihre Plattform-Authentifikator-API auch Hardwaresicherheitsschlüssel als Passkey-Authentifikatoren.

Google: Passwort-Manager-Passkeys

Google Password Manager synchronisiert jetzt Passkeys auf Android und Chrome auf jeder Plattform, einschließlich Windows und macOS. Die Synchronisierung ist mit der PIN des Google-Kontos des Benutzers Ende-zu-Ende-verschlüsselt. Eine bedeutende Ergänzung von 2024: Google begann, den Passkey-Export in einigen Abläufen zu unterstützen, und fügte die Passkey-Unterstützung für ihr Advanced Protection Program hinzu – zuvor die exklusive Domäne physischer Sicherheitsschlüssel.

Windows Hello

Windows Hello bietet gerätegebundene Passkeys, die an den TPM-Chip gebunden und über Gesichtserkennung, Fingerabdruck oder PIN entsperrt werden. Die Implementierung von Microsoft ist eng in den Windows-Anmeldeinformationsspeicher integriert. In Unternehmensumgebungen erweitert Windows Hello for Business dies um zertifikatsbasierte Authentifizierung mit Entra ID, was passwortlose Abläufe in verwalteten Unternehmensumgebungen ermöglicht.

Passwort-Manager von Drittanbietern

Sowohl 1Password als auch Bitwarden haben 2023-2024 die Passkey-Speicherung hinzugefügt und behandeln Passkeys als neuen Anmeldeinformationstyp neben Passwörtern. Dies ist bedeutsam: Es entkoppelt die Passkey-Speicherung von Plattformanbietern, ermöglicht plattformübergreifende Passkey-Nutzung ohne Bindung an Google oder Apple und bietet Unternehmen einen Weg, Passkeys in der bestehenden Tresorinfrastruktur zu verwalten. Die Open-Source-Implementierung von Bitwarden wurde unabhängig auditiert.

Die verbleibenden harten Probleme

Geräteverlust und Kontowiederherstellung

Geräteverlust ist das emotional auffälligste Hindernis für die Passkey-Einführung. Die richtige Antwort – und eine, die explizite Benutzerschulung erfordert – ist die Registrierung mehrerer Passkeys auf verschiedenen Geräten oder Authentifikatoren, bevor Sie sie benötigen. Registrieren Sie einen Passkey auf Ihrem Telefon, Ihrem Laptop und einem an einem sicheren Ort aufbewahrten Hardwareschlüssel. Die meisten Dienste, die Passkeys gut implementieren, fordern dazu auf. Aber die Realität ist, dass die meisten Benutzer einen einzelnen Passkey registrieren und das Wiederherstellungsproblem erst entdecken, wenn ihr Gerät weg ist.

Für synchronisierte Passkeys haben iCloud Keychain und Google Password Manager beide Kontowiederherstellungsmechanismen. Wenn Sie Ihr iPhone verlieren, aber Ihr iCloud-Konto wiederherstellen können (über einen Wiederherstellungsschlüssel oder ein vertrauenswürdiges Gerät), stellen Sie auch Ihre Passkeys wieder her. Dies verschiebt die Sicherheitsgrenze vom Gerätebesitz zur Kontosicherheit – was eine Regression darstellen kann, wenn Ihr iCloud- oder Google-Konto schwache Sicherheit hat. Die Lösung besteht darin, Ihr primäres Cloud-Konto als hochsichere Wurzel zu behandeln: starker Wiederherstellungsschlüssel, Hardware-2FA, nichts Schwächeres.

Unternehmenseinführung: Active Directory und LDAP

Unternehmensumgebungen stellen echte Komplexität dar. Legacy-Anwendungen, die sich gegen Active Directory oder LDAP authentifizieren, unterstützen WebAuthn nicht. Die Überbrückung von Passkeys zu diesen Umgebungen erfordert entweder eine Föderation über einen Identitätsanbieter (Entra ID, Okta, Ping Identity), der WebAuthn-Authentifizierung in SAML- oder OIDC-Tokens übersetzen kann, oder das Warten auf die Modernisierung der Anwendungen. Die meisten großen Unternehmen befinden sich in einem Hybridzustand: Passkeys für Cloud-native Apps und SSO-Portale, Passwörter oder Smartcards für Legacy-Line-of-Business-Apps. Die vollständige unternehmensweite Passkey-Einführung ist ein mehrjähriges Programm, kein Konfigurationsschalter.

Android/iOS-Interoperabilität

Die plattformübergreifende Passkey-Nutzung – also die Anmeldung auf einem iOS-Gerät mit einem auf einem Android-Telefon gespeicherten Passkey oder umgekehrt – funktioniert über den CTAP2-Hybridtransport (Bluetooth-Näherungs-QR-Code-Ablauf). In der Praxis funktioniert dies zuverlässig, wenn beide Geräte modern sind, Bluetooth eingeschaltet ist und der Benutzer versteht, was er tut. Für weniger technische Benutzer ist es nicht nahtlos und fügt in Szenarien wie dem Ausleihen eines Geräts Reibung hinzu. Dies ist ein Bereich, in dem die Benutzererfahrung noch hinter der zugrunde liegenden kryptografischen Fähigkeit zurückbleibt.

Legacy-Geräte ohne biometrische Sensoren

Passkeys erfordern eine Form der Benutzerüberprüfung – biometrische Daten (Fingerabdruck, Gesicht) oder eine Geräte-PIN. Geräte ohne biometrische Sensoren können eine PIN verwenden, aber eine kurze PIN auf einem alten Android-Gerät ist eine schwächere Benutzerüberprüfung als Face ID. Hardwaresicherheitsschlüssel (FIDO2-Schlüssel mit PIN + Berührung) lösen dies für Benutzer, die bereit sind, einen mit sich zu führen, aber die Akzeptanz bei nicht-technischen Benutzern ist minimal.

Die Entwicklerperspektive: Implementierung von WebAuthn

Wenn Sie Authentifizierung entwickeln, ist die WebAuthn-Implementierung jetzt gut unterstützt. Die ausgereiften, aktiv gewarteten Bibliotheken im Jahr 2026 umfassen:

• SimpleWebAuthn (TypeScript/Node.js) – die am weitesten verbreitete JS-Bibliothek, behandelt sowohl Registrierung als auch Authentifizierung, hervorragende Dokumentation, handhabt die Zeremonie korrekt, einschließlich Challenge-Überprüfung und Speichermustern für Anmeldeinformationen.
• py_webauthn (Python) – die Referenz-Python-Implementierung, verwendet im Stack von Duo Security, unterstützt sowohl FIDO2 als auch das ältere U2F für Abwärtskompatibilität.
• webauthn4j (Java) – die ausgereifte Java-Bibliothek, die von der WebAuthn-Unterstützung von Spring Security verwendet wird; behandelt Attestierungsvalidierung, Metadatendienstintegration und funktioniert gut in Spring Boot-Anwendungen.
• go-webauthn/webauthn (Go) – die Standard-Go-Implementierung, saubere API, aktiv gewartet.

Die Browser-Kompatibilität ist für die Kern-WebAuthn-API jetzt kein Problem mehr: Chrome 67+, Firefox 60+, Safari 14+ und Edge 18+ unterstützen sie alle. Die verbleibende Kompatibilitätslücke liegt in der bedingten Benutzeroberfläche (conditional UI) (autofill-gesteuerte Passkey-Eingabeaufforderungen), die etwas neuere Browserversionen erfordert, aber jetzt weit verbreitet ist.

Wichtige Implementierungsfehler, die es zu vermeiden gilt: Die Challenge nicht serverseitig an die Sitzung zu binden (Replay-Angriffsvektor), die rpId und den Ursprung (origin) in der serverseitigen Validierung nicht zu überprüfen, die Attestierungsvalidierung in sicherheitskritischen Kontexten zu überspringen und nicht von Anfang an Multi-Geräte-Registrierungsabläufe zu implementieren.

Praktische Empfehlungen

Aktivieren Sie Passkeys zuerst für Ihre wichtigsten Konten, in dieser Prioritätsreihenfolge:

• E-Mail-Anbieter – Ihre E-Mail ist der Wiederherstellungsmechanismus für alles andere. Ein kompromittiert