Passkeys vs. Passwörter 2026: NIST 800-63-4 und der reale Rollout

2026 ist das Jahr, in dem Passkeys den Sprung von »cool, aber wer nutzt das schon?« zu »warum hast du noch Passwörter?« geschafft haben. Die FIDO Alliance meldet im Juni 2026 über 1 Milliarde aktivierte Passkeys, 48 % der Top-100-Webseiten unterstützen die Technologie, und Google sagt: 99,9 % weniger Compromise-Rate als bei Passwörtern. Gleichzeitig hat NIST mit SP 800-63-4 verbindlich phishing-resistente Authentifizierung für AAL2 verlangt. Ich habe in den letzten zwei Monaten zwei Passkey-Migrationen bei Kunden begleitet — was Passkeys können, wo sie noch hapern, und warum Passwort-Tools weiterhin relevant bleiben.

Was Passkeys technisch sind

Ein Passkey ist im Kern ein asymmetrisches Kryptografie-Schlüsselpaar, das in einem sicheren Hardware-Modul deines Geräts (Secure Enclave bei Apple, TPM unter Windows, StrongBox bei Android) erzeugt und gespeichert wird. Der private Schlüssel verlässt das Gerät nie. Bei jeder Anmeldung schickt der Server eine Challenge, dein Gerät signiert sie mit dem privaten Schlüssel, der Server verifiziert die Signatur mit dem zugehörigen öffentlichen Schlüssel, den er beim Erst-Onboarding empfangen hat.

Der entscheidende Unterschied zu Passwörtern: das Geheimnis (der private Schlüssel) wird nie übertragen. Selbst wenn der Server gehackt wird und seine gesamte Datenbank leakt, sind die Public Keys nutzlos für einen Angreifer — er kann damit keine Signaturen erzeugen. Das ist ein paradigmaler Sicherheitsgewinn. Passwörter mussten immer beim Server zwischengespeichert werden (auch wenn als Hash); Passkeys nicht.

Phishing-Resistenz kommt durch eine zweite Eigenschaft: der Passkey ist an die Domain (Relying Party ID) gebunden, für die er erstellt wurde. Wenn ein Angreifer eine Fake-Site unter calcsi-login.com aufsetzt, signiert dein Gerät nichts, weil die Domain nicht zur registrierten passt. Es gibt keine »Falle, in die du tappen kannst« — die Kryptographie verhindert, dass die Authentifizierung gegen die falsche Domain überhaupt erfolgreich sein kann.

NIST SP 800-63-4: was die neue US-Norm festschreibt

Das NIST-Dokument »SP 800-63-4: Digital Identity Guidelines« ist seit der finalen Veröffentlichung 2025 die maßgebliche US-Norm für Identitäts-Authentifizierung. Wer für US-Bundesbehörden arbeitet, muss sich daran halten — und im Schlepptau folgen Großkonzerne, weil 800-63-4 auch in privaten Vertragsklauseln zur Referenz wird. Für Authenticator Assurance Level 2 (AAL2) verlangt 800-63-4 phishing-resistente Authentifizierung. Für AAL3 ist sie zwingend.

Drei weitere wichtige Änderungen gegenüber der Vorgängerversion 800-63-3: (1) keine erzwungene periodische Passwort-Rotation mehr — nur bei vermutetem Compromise. Das hat Jahre gedauert; die alte Vorschrift »Passwort alle 90 Tage ändern« hat objektiv Sicherheit verschlechtert, weil Nutzer sich Variations-Schemata gemerkt haben. (2) Mindest-Länge wichtiger als Komplexität — 8 Zeichen Pflicht, 15+ empfohlen, Composition Rules (»1 Großbuchstabe, 1 Sonderzeichen«) sind explizit unerwünscht. (3) Screening gegen kompromittierte Passwort-Listen verpflichtend — wer ein Account erstellt, wird gegen HaveIBeenPwned o. ä. geprüft.

Die EU-Welt hat keine direkte 1:1-Entsprechung, aber die NIS-2-Richtlinie und der EU-Cyber-Resilience-Act gehen in dieselbe Richtung: phishing-resistente MFA für kritische Infrastrukturen ab 2026 verpflichtend. Wer in Deutschland ein BSI-konformes System betreibt, kann die NIST-Richtlinien als Best Practice zitieren — sie werden in Audits zunehmend als Vergleichsmaßstab benutzt.

Was 2026 wirklich passiert — Adoption-Realität

Die nüchterne Realität: 48 % der Top-100-Sites supporten Passkeys. Aber: Support heißt nicht »default«. Bei den meisten Sites musst du immer noch aktiv in den Account-Einstellungen einen Passkey hinzufügen — der Login-Flow für Neukunden geht weiter über Passwort + E-Mail. Google, Microsoft, Apple und PayPal sind die Vorreiter und versuchen, Passwörter aktiv loszuwerden. Bei kleineren SaaS-Anbietern bleibt das Passwort die primäre Methode, der Passkey ist ein optionales Plus.

Konkret beobachte ich bei den Migrations, die ich 2026 begleitet habe: ungefähr 15-25 % der Nutzer aktivieren in den ersten 3 Monaten einen Passkey, wenn man sie aktiv anstößt. Ohne Anstoß sind es <5 %. Das heißt: das Passwort wird auf absehbare Zeit (5+ Jahre) im Stack bleiben, neben dem Passkey. Wer als Entwickler 2026 ein neues System baut, plant für beide Wege.

Wo Passkeys noch hapern: das »Setup an Gerät A, später Login an Gerät B«-Problem. Apple und Google haben das durch iCloud-Keychain und Google Password Manager weitgehend gelöst — die Schlüssel synchronisieren zwischen Geräten desselben Cloud-Accounts. Aber: cross-platform (Apple-Schlüssel auf einem Windows-PC nutzen) ist immer noch unrund. WebAuthn-Hybrid via QR-Code funktioniert, ist aber für viele Nutzer zu fummelig. Sicherheitsschlüssel (YubiKey 5) bleibt die robusteste Cross-Platform-Lösung.

Wo Passwörter weiterhin relevant bleiben

Erstens: viele Dienste werden in den nächsten 5 Jahren keine Passkey-Unterstützung bekommen. Behörden-Portale, kleine SaaS, internationale Anbieter aus Regionen mit anderer Sicherheits-Reife. Ein 25-stelliges, einzigartiges Passwort pro Dienst im Passwort-Manager ist 2026 immer noch der pragmatische Default.

Zweitens: Recovery-Szenarien. Wenn dein Telefon ins Wasser fällt und der iCloud-Login nicht klappt, brauchst du einen Backup-Path — und das ist meistens ein Passwort. Das ist auch das größte Argument gegen einen reinen Passkey-Only-Service: viele Nutzer haben Angst, ausgesperrt zu werden. Praktisch sehe ich, dass die Recovery-Mechanik über E-Mail-Codes plus Backup-Codes (10 Einmal-Codes ausdrucken) ein guter Kompromiss ist.

Drittens: WordPress, Wikis, Self-Hosted-Tools. Die WordPress-Community hat seit 2024 ein Passkey-Plugin, aber die Verbreitung ist klein. Wer eine eigene WordPress-Installation hat, wird auf absehbare Zeit über das Standard-WordPress-Login-Formular hereinkommen — mit einem starken Passwort und Two-Factor-Authentifizierung. Unser WordPress-Passwort-Hash-Generator bleibt in Recovery-Szenarien wichtig: damit kannst du einen neuen Admin-Hash direkt in die Datenbank schreiben, ohne über E-Mail-Reset zu gehen.

Praktische Migration: was ich Kunden 2026 empfehle

Schritt 1 ist immer: Inventar. Welche Dienste hat dein Team genutzt? Welche unterstützen Passkeys, welche nicht? Ein einfacher CSV-Export aus dem Passwort-Manager (1Password, Bitwarden, Dashlane) ist der Startpunkt. Dann pro Service prüfen: passkey-fähig? Bei den ja-Antworten: aktivieren, alten Passwort behalten als Backup. Bei den nein-Antworten: starkes, einzigartiges Passwort + MFA (idealerweise mit YubiKey, sonst TOTP).

Schritt 2 ist die Eskalation für privilegierte Accounts. Admins, Finance, HR — alle Konten mit Zugriff auf Bezahlsysteme, Personaldaten oder Kunden-Datenbanken. Hier ist ein YubiKey 5 (50-70 EUR) plus mindestens ein Backup-YubiKey Pflicht. Wer in einer Organisation arbeitet, die NIS-2 oder ähnliche Compliance-Frameworks hat, muss das ohnehin tun.

Schritt 3 ist der schwierigste: User-Schulung. »Passkey« ist für die meisten Mitarbeitenden ein Buzzword. Eine 20-Minuten-Demo am Beispiel des Microsoft-Logins reicht in der Regel aus, um den Mehrwert zu zeigen. Wichtig ist: keine Pflicht, sondern Anreiz. Wer einen Passkey nutzt, hat 5 Sekunden Login-Zeit. Wer 25-Zeichen-Passwort plus TOTP nutzt, hat 30 Sekunden. Der Bequemlichkeitsvorteil macht die Migration besser als jeder Vortrag über »Sicherheit«.

Konkreter Plan für deinen 2026er Sicherheits-Audit

Eine kurze Checkliste, die ich für jedes Projekt durchgehe:

• Passwort-Stärke prüfen. Mit dem Passwort-Generator mindestens 20 Zeichen pro Account erzeugen. Keine Composition Rules erzwingen — Länge schlägt Komplexität.
• Hash-Algorithmus für gespeicherte Passwörter prüfen. Argon2id (besser) oder bcrypt mit cost ≥12 sind State-of-the-Art. MD5 und SHA-1 sind dort verboten. PBKDF2 ist akzeptabel, aber nicht mehr empfohlen.
• Passkey-Support im Frontend prüfen. WebAuthn-API einbauen, conditional UI für Browser-eigene Passkey-Vorschläge nutzen. Apple und Google haben Standard-Snippets in der Dokumentation.
• Recovery-Mechanismus testen. Backup-Codes generieren und an einem realen Test-Account validieren. Lass einen Kollegen versuchen, sich auszusperren und wieder reinzukommen.
• Audit Logs aktivieren. Jeder Login-Versuch sollte in einem Audit-Log mit IP, User-Agent und Zeit mitlaufen. Bei Anomalien Alerts an Admins.

Das klingt nach viel, ist aber für einen kleinen bis mittelgroßen Stack in 2 Tagen machbar. Der größte Gewinn liegt nicht in der Pure-Technologie, sondern in der Disziplin: einmal anständig aufgesetzt, müssen die Mechanismen nicht jeden Tag neu erfunden werden.

Mein Fazit für 2026

Passkeys sind kein Ersatz für Passwörter — sie sind ein Add-on, das aktiv die Phishing-Angriffsfläche eliminiert. Wer beides parallel anbietet und User-freundlich zum Passkey schubst, gewinnt Sicherheit ohne Friktion. Wer immer noch im 90-Tage-Passwortwechsel-Modus läuft, sollte das umgehend abschaffen — NIST sagt es seit 2017, jetzt steht es im Update von 2025 explizit drin.

Persönlich: ich habe seit Mai 2024 für meine wichtigsten Accounts Passkeys im Einsatz, der erste war ein Google-Account. Login-Zeit von 12 Sekunden auf 2 Sekunden, kein einziger Phishing-Versuch mehr seit über zwei Jahren. Mein Passwort-Manager ist noch da, sein Inhalt schrumpft langsam. In drei Jahren — denke ich — ist er für mich primär ein Backup-Archiv, kein Primärwerkzeug mehr.

Häufige Fragen

Sind Passkeys auch dann sicher, wenn jemand mein Handy klaut?

Ja, vorausgesetzt dein Handy hat Geräte-PIN oder Biometrie. Der Passkey selbst ist im Secure Element gespeichert und kann ohne erfolgreiche User-Verifikation (Face ID, Touch ID, PIN) nicht genutzt werden. Ein Dieb kann das Handy einschalten, sieht aber den Lock Screen — und ohne diesen Schritt funktioniert auch der Passkey nicht. Wichtig: Cloud-Backup deiner Passkeys (iCloud Keychain) sollte mit einer separaten Passphrase geschützt sein.

Was passiert, wenn ich von iOS auf Android wechsle?

Passkeys, die in iCloud Keychain liegen, kann man derzeit nicht direkt zu Google Password Manager exportieren. Man muss bei jedem Service den Passkey neu registrieren. 1Password, Bitwarden und Dashlane können cross-platform syncen — wer also einen Passwort-Manager unabhängig vom OS nutzt, hat den Wechsel deutlich einfacher. Die FIDO Alliance arbeitet an einem Passkey-Export-Standard, aber das wird mindestens 2027 dauern.

Brauche ich noch einen YubiKey, wenn ich Passkeys auf meinem Handy habe?

Für hochprivilegierte Accounts (Banking, Krypto-Custody, Admin-Konsolen): ja. Ein YubiKey ist phishing-resistent UND cloud-unabhängig. Bei iCloud-synchronisierten Passkeys liegt das Vertrauen letztlich bei Apple — Apple wurde noch nie kompromittiert, aber das ist ein einzelner Vertrauensanker. Für normales Online-Banking, Email-Konto, Social Media reichen Phone-Passkeys vollkommen.

Kann mein Arbeitgeber sehen, welche Passkeys ich nutze?

Auf einem privaten Gerät: nein. Auf einem firmen-managed Gerät (MDM): er sieht, dass Passkeys existieren, aber nicht für welche Services. Bei Apple ist die Passkey-Speicherung im Privatbereich der iCloud-Keychain isoliert; Apple Business Manager hat keinen Zugriff darauf. Auf Windows mit Entra ID kann das anders sein — die Konfiguration legt fest, ob private Passkeys im selben Profil liegen oder getrennt.

Sind Passkeys sicher gegen Quantencomputer?

Die aktuellen Passkeys nutzen elliptische Kurven (ES256, ES384) oder RSA-2048 — beide würden von einem ausreichend großen Quantencomputer gebrochen. Eine post-quantum-sichere Variante ist im FIDO-Spec-Pipeline, aber noch nicht produktiv. Praktisch: Quantencomputer, die das Problem lösen, sind noch 5-15 Jahre entfernt; bis dahin ist die Migration auf Post-Quantum-Krypto eine plattformweite Aufgabe, die Microsoft, Apple und Google parallel vorantreiben.

Wie kann ich als Webentwickler 2026 mit Passkey-Login starten?

Drei Schritte: (1) WebAuthn-API im Frontend einbinden (vanilla JS oder Bibliothek wie SimpleWebAuthn). (2) Server-seitig die Challenge generieren, das öffentliche Schlüsselmaterial speichern, Signaturen verifizieren. (3) Conditional UI verwenden, damit der Browser automatisch verfügbare Passkeys vorschlägt. Auth0, Clerk, Stytch und Supabase bieten alle Passkey-as-a-service — wer keinen Eigen-Stack will, kann das in 2 Stunden integrieren. Reine OSS-Lösungen: SimpleWebAuthn (JS/TS) oder webauthn-py (Python).