Passkeys & Passwordless 2025: Das Ende der Passwörter?

1) Warum Passwörter sterben – das Sicherheits- und Usability-Dilemma

Passwörter sind gleichzeitig zu schwach und zu kompliziert. Nutzer sollen lange, einzigartige Zeichenfolgen erstellen, regelmäßig wechseln und niemals recyceln. Die Realität sieht anders aus: Wiederverwendung über Dutzende Dienste, leicht zu erratende Muster, unsichere Speicherorte. Auf Betreiberseite ist es nicht besser: selbst mit Hashing, Salting und Leck-Überwachung bleibt die Angriffsfläche riesig – Phishing, Credential Stuffing, Datenbankleaks, Brute-Force via Bots. Zwei-Faktor-Verfahren (2FA) haben das verbessert, aber SMS-Codes sind abfangbar, TOTP-Codes werden phishbar abgefragt, und Push-MFA leidet unter „MFA Fatigue“. Kurz: Wir kleben Pflaster auf ein Grundproblem. Passkeys gehen das Fundament an: Das Passwort selbst verschwindet.

2) Was sind Passkeys? FIDO2 & WebAuthn in Klartext

Ein Passkey ist ein digitales Schlüsselpaar: ein privater Schlüssel bleibt sicher auf deinem Gerät (oder in dessen Secure Enclave/TPM), der öffentliche Schlüssel wird beim Dienst gespeichert. Statt ein geheimes Passwort an den Server zu senden, beweist du bei jeder Anmeldung kryptografisch, dass du den privaten Schlüssel besitzt. Das Protokoll dahinter stammt aus dem Standard-Set FIDO2 (bestehend aus CTAP2 für die Kommunikation mit Authenticatoren und WebAuthn als Web-API).

Wichtig: Passkeys sind phishing-resistent. Sie binden sich an die Domain, für die sie erstellt wurden. Ein gefälschtes Login-Formular auf news24-7.co statt news24-7.de kann deinen Passkey nicht missbrauchen, weil der Browser die Herkunft prüft. Außerdem verlassen private Schlüssel niemals dein Gerät. Der Dienst speichert nur den öffentlichen Schlüssel – ein Datenbank-Leak ist daher deutlich weniger brisant.

3) So funktioniert ein Passkey-Login technisch – vom Schlüsselpaar bis zur Biometrie

Registrierung: Du willst bei einem Dienst einen Passkey anlegen. Der Server erzeugt eine Challenge (zufällige Zeichenfolge) und schickt sie an den Browser. Dein Gerät (Authenticator) erzeugt ein neues Schlüsselpaar. Der private Schlüssel wird sicher gespeichert, der öffentliche Schlüssel – inklusive Metadaten (Schlüssel-ID, erlaubte Algorithmen, Origin-Bindung) – geht an den Server. Optional wird die Registrierung an eine Benutzerprüfung gekoppelt (z. B. Fingerabdruck, Face-ID, Geräte-PIN). Ergebnis: Konto <–> öffentlicher Schlüssel verknüpft.

Anmeldung: Beim Login sendet der Server wieder eine Challenge. Dein Gerät signiert diese Challenge mit dem privaten Schlüssel, nachdem du dich lokal authentifiziert hast (Biometrie/PIN). Der Browser übermittelt die Signatur, der Server verifiziert sie mit dem gespeicherten öffentlichen Schlüssel. Passt alles, bist du drin. Passwort? Gab es nie.

Synchronisierte vs. gerätegebundene Passkeys: Moderne Ökosysteme (z. B. iOS/iPadOS/macOS Keychain, Google Password Manager) können Passkeys Ende-zu-Ende-verschlüsselt zwischen deinen Geräten synchronisieren. Alternativ gibt es Hardware-gebundene Passkeys auf FIDO-Sicherheitsschlüsseln (z. B. YubiKey), die nicht synchronisiert werden – beliebt in Hochsicherheitsumgebungen.

4) Vorteile in der Praxis: Sicherheit, Conversion, Support

Phishing-Resistenz: Weil Authentifizierung an die echte Domain gebunden ist, verlieren klassische Phishing-Kampagnen ihren Biss. Kein Abfischen von Passwörtern, keine Weitergabe von TOTP-Codes via „gefakter Support“.

Weniger Reibung: Nutzer tippen nichts Kryptisches ein, sondern entsperren lokal per Fingerabdruck oder Gesicht. Für Shops und SaaS erhöht das die Conversion im Login/Checkout – weniger Abbrüche, weniger „Passwort vergessen“.

Support spart Kosten: Passwort-Resets und Konto-Entsperrungen belasten Helpdesks. Passkeys reduzieren diese Tickets merklich, besonders bei großen Nutzerbasen oder verteilten Teams.

Datenschutz & Leaks: Selbst wenn eine Benutzer-Datenbank kompromittiert wird: Öffentliche Schlüssel sind kein Geheimnis, ein „Credential-Stuffing“ ist wirkungslos. Betreiber haben weniger hochkritische Secrets im Bestand.

5) Einbindung für Websites & Apps: Architekturen, UX-Muster, Fallbacks

Architekturgrundlagen: Auf Web-Seite sprichst du via navigator.credentials.create() (Registrierung) und navigator.credentials.get() (Login) die WebAuthn-APIs an. Der Server verwaltet pro Nutzer einen oder mehrere öffentlichen Schlüssel und eine Liste unterstützter Algorithmen (typisch: ECDSA mit P-256). Wichtig sind saubere Relying Party IDs (rpId, meist die Domain) und korrekte Challenge-Handhabung (einmalig, zufällig, kurzlebig).

UX-Muster: Erfolgreiche Implementierungen sind Passkey-First: Schon auf der Login-Seite signalisierst du „Mit Passkey anmelden“, daneben ein unaufdringlicher Link „Stattdessen Passwort verwenden“. Nach der ersten Passwort-Anmeldung bietest du proaktiv an: „Diesen Account mit einem Passkey sichern“ – ideal mit microcopy („Schneller, sicherer, kein Passwort mehr nötig“). Visuelle Hinweise (Browser-Dialog, Plattform-Branding) erhöhen Vertrauen.

Geräteübergreifendes Onboarding: Nutzer sind mobil und stationär unterwegs. Gute Setups bieten QR-Handshakes an: Desktop zeigt QR, das Smartphone als „Roaming Authenticator“ bestätigt per Biometrie – fertig. Danach wird optional ein synchronisierter Passkey angelegt.

Fallbacks & Recovery: Passwordless heißt nicht zwangsläufig „ohne Netz und doppelten Boden“. Für den Start ist ein paralleles Passwort-Login okay, aber begrenze das auf Recovery-Fälle. Bessere Wege: zusätzliche Passkeys (Zweitgerät), Security Keys als Backup, klarer Geräte-Recovery-Prozess (z. B. „Bestätige auf einem bereits verbundenen Gerät“). E-Mail-Magic-Links sind als letzte Option denkbar, aber nur mit Rate-Limiting und Abuse-Schutz.

6) Passwordless im Unternehmen: SSO, Geräteflotten & Compliance

SSO-Integration: In Unternehmensumgebungen dockt Passwordless sinnvoll an bestehende Identitäts-Provider (IdP) an – Azure AD/Entra, Okta, Ping, Keycloak, Authentik u. a. Viele bieten heute WebAuthn/FIDO2 nativ. Vorteil: Ein zentrales Richtlinien-Set („Passkey oder Hardware-Key erforderlich“) für alle SaaS-Ziele (M365, Salesforce, Atlassian …).

Geräteverwaltung: Für verwaltete Flotten (Windows mit TPM, macOS mit Secure Enclave, iOS/Android) definierst du, welche Authenticatoren erlaubt sind, ob Synchronisierung zulässig ist und ob Biometrie verpflichtend ist. In regulierten Umgebungen empfiehlt sich die Kombination aus hardwaregebundenen Sicherheitsschlüsseln plus passkeyfähigen Plattform-Authentikatoren als Komfortschicht.

Compliance & Audit: Passkeys vereinfachen Audits: Keine Passwort-Komplexitätsrichtlinien, keine Rotationszwänge, weniger PII-kritische Daten. Wichtig bleiben Logs: Registrierungen, De-Registrierungen, gescheiterte Versuche, Attribut-Änderungen – zentral gesammelt und SIEM-fähig.

7) Hürden & Missverständnisse: Synchronisierung, Geräteverlust, Phishing

„Was, wenn ich mein Handy verliere?“ – Dann greift dein Recovery-Konzept: zweites Gerät mit Passkey, Hardware-Security-Key als Backup, oder bestätigte Wiederherstellung über ein bereits vertrauenswürdiges Gerät. Der Punkt ist: vor dem Vorfall klare Wege definieren – und prominent kommunizieren.

„Sind synchronisierte Passkeys unsicher?“ – Sie sind Ende-zu-Ende-verschlüsselt im jeweiligen Ökosystem. Der private Schlüssel verlässt die sichere Umgebung nicht im Klartext. Für Höchstsicherheit bleiben non-sync Hardware-Keys die Königsklasse; für die Breite der Nutzer sind Sync-Passkeys ein guter Sweet Spot zwischen Sicherheit und Komfort.

„Kann man Passkeys phishen?“ – Klassisches Phishing wird stark erschwert, weil Signaturen an die echte Domain gebunden sind. Angreifer können weiterhin Social-Engineering betreiben (z. B. Fake-Support), aber das Abgreifen von Geheimnissen entfällt. Gute UX-Hinweise (z. B. vertrauenswürdiger Browser-Dialog) helfen, Rest-Risiken zu senken.

„Brauche ich dann gar keine Passwörter mehr?“ – Ziel ist Passkey-First. Für Übergangszeiten oder Sonderfälle kann ein Passwort-Fallback bestehen. Langfristig lässt sich der Passwort-Pfad einschränken oder per Policy deaktivieren.

8) Fahrplan zur Umstellung: Von Password-Only zu Passkey-First

Schritt 1 – Ist-Analyse: Welche Logins hast du (Web, Mobile, B2B-APIs)? Welche IdPs/SDKs nutzt du, wie sehen deine MFA-Quoten aus, wo entstehen Support-Kosten (Passwort-Resets, Fraud)?

Schritt 2 – Architektur & Pilot: Wähle den ersten Anwendungsfall mit hohem Impact und überschaubarer Komplexität (z. B. Kunden-Login im Shop oder Mitarbeiter-SSO fürs Intranet). Implementiere WebAuthn-Flows, Logging, Recovery. Teste auf iOS/Android/Windows/macOS mit gängigen Browsern.

Schritt 3 – UX & Kommunikation: Erkläre in einem Satz, warum Passkeys besser sind („Schneller & sicherer – mit Fingerabdruck statt Passwort“). Biete post-login aktiv die Passkey-Registrierung an. Onboarding-E-Mails, kurze Hilfeseiten, Tooltips – und fertig.

Schritt 4 – Metriken & Rollout: Miss Conversion im Login, Anteil Passkey-Logins, Abbruchraten, Supporttickets. Schalte dann schrittweise weitere Touchpoints um (App, Partner-Portale, Admin-Logins). Definiere, ab wann Passkeys Pflicht werden (z. B. für Admins).

Schritt 5 – Passwort-Deprecation: Nach ausreichender Adoption kannst du Passwörter nur noch als Recovery zulassen, später ganz abschalten. Kommuniziere Deadlines frühzeitig, biete glatte Migrationswege (Zweitgerät, Security-Key).

9) FAQ: Häufige Fragen aus Nutzer- und Betreiber-Sicht

Kann ich mehrere Passkeys pro Account haben? Ja, und das ist empfohlen: z. B. Smartphone, Laptop und ein Hardware-Key als Backup.

Funktioniert das auf allen Geräten? Moderne Browser und Betriebssysteme unterstützen WebAuthn/Passkeys breit. Alte Plattformen brauchen ggf. Fallbacks (Magic Link, einmalige Codes).

Müssen Nutzer Biometrie verwenden? Nein, sie ist komfortabel, aber nicht zwingend. Alternativ kann die Geräte-PIN die lokale Entsperrung übernehmen – der private Schlüssel bleibt geschützt.

Wie geht Onboarding bei neuen Geräten? Entweder über die Synchronisation des Ökosystems (z. B. Keychain) oder über die Autorisierung per bestehendem Gerät/Hardware-Key. Gute Oberflächen führen in 2–3 Schritten durch.

Ist Passwordless teurer als klassische Logins? Initial ja (Implementierung, Kommunikation, Tests). Laufend sinken jedoch Supportkosten, Betrugsfälle und Abbrüche – in Summe rechnet sich der Umstieg meist schnell.

10) Fazit: Passwordless ist kein Trend – es ist die neue Basis

Passkeys lösen ein altes Grundproblem des Internets: das Teilen von Geheimnissen zwischen Nutzer und Dienst. Mit Public-Key-Kryptografie, Biometrie und Domain-Bindung wird Login sicherer und bequemer zugleich. Für Nutzer bedeutet das: weniger Tippen, weniger Stress, mehr Schutz. Für Unternehmen: bessere Conversion, geringere Risiken, niedrigere Supportkosten. 2025 ist der ideale Zeitpunkt, den Wechsel einzuleiten – pragmatisch, iterativ und mit Blick auf echte Nutzerbedürfnisse. Passwörter waren ein Anfang. Passkeys sind die Basis für das nächste Jahrzehnt.