Passwortlose Authentifizierung - Sicher & einfach anmelden?

Passwortlose Authentifizierung verlagert den Fokus weg von einem geteilten Geheimnis hin zu einem Gerät, einem privaten Schlüssel oder einer lokalen Freigabe wie Fingerabdruck oder PIN. Für Nutzer sinkt die Reibung, für Unternehmen fallen typische Angriffsflächen wie Phishing, Credential Stuffing und Passwort-Resets deutlich kleiner aus. Entscheidend ist aber die Einordnung: Nicht jedes Verfahren ohne Passwort ist automatisch gleich stark. Ich zeige hier, welche Methoden heute wirklich tragen, wie sie technisch funktionieren und worauf es bei Identität und Zugriff in der Praxis ankommt.

Was ohne Passwort eigentlich gemeint ist

Im Kern geht es nicht um „kein Login mehr“, sondern um einen anderen Nachweis. Statt ein Passwort einzugeben, beweist der Nutzer Besitz eines Geräts, entsperrt lokal einen Schlüssel oder bestätigt die Anmeldung mit einem biometrischen Merkmal. Ich trenne dabei bewusst zwischen Authentifizierung und Autorisierung: Erst wird die Identität geprüft, dann erst der Zugriff vergeben.

• Besitz eines registrierten Geräts oder Schlüssels
• Lokale Freigabe per PIN, Fingerabdruck oder Gesichtserkennung
• Kryptografischer Nachweis gegenüber dem Dienst statt Eingabe eines Geheimworts

Genau deshalb ist die Frage nicht, ob ein Verfahren „modern“ wirkt, sondern ob es einen echten Identitätsbeweis liefert und sich im Betrieb sauber absichern lässt. Von hier aus lohnt sich der Blick auf die Varianten, die heute wirklich eingesetzt werden.

Welche Verfahren heute wirklich überzeugen

Ich unterscheide hier bewusst zwischen echten Ersatzverfahren und Übergangslösungen. Das ist wichtig, weil manche Ansätze das Passwort nur verstecken, andere es tatsächlich aus dem Anmeldeprozess entfernen.

WebAuthn ist die Browser- und App-Schnittstelle, FIDO2 der Standardschirm dahinter. CTAP verbindet den Authenticator mit Browser oder Gerät. Wer beides zusammendenkt, hat die technische Basis für die meisten modernen Login-Szenarien bereits verstanden.

Mein klares Fazit aus dieser Einordnung: Passkeys und Hardware-Schlüssel tragen den Zielzustand, alles andere ist je nach Risiko eher Ergänzung oder Brücke. Besonders SMS und klassische OTP-Strecken wirken vertraut, lösen aber das eigentliche Problem nur halb.

Technisch ist der Ablauf dahinter klarer, als viele denken. Genau das macht den Sicherheitsgewinn so belastbar.

So läuft die Anmeldung unter der Haube ab

Der klassische Passwort-Check wird durch einen Challenge-Response-Ablauf ersetzt. Der Server speichert nur den öffentlichen Schlüssel, das private Gegenstück bleibt auf dem Gerät oder in einem geschützten Authenticator. Bei der Anmeldung sendet der Server eine Einmal-Challenge, das Gerät entsperrt sie lokal per PIN oder Biometrie und liefert eine Signatur zurück.

1. Bei der Registrierung erzeugt das Gerät ein Schlüsselpaar.
2. Der Dienst speichert nur den öffentlichen Schlüssel.
3. Beim Login startet der Server eine neue Challenge.
4. Das Gerät bestätigt lokal Besitz und Nutzungsabsicht.
5. Nur die Signatur wird geprüft, nicht ein wiederverwendbares Passwort.

Das erklärt auch, warum Passkeys so viel besser gegen Phishing funktionieren: Ein Angreifer kann die Signatur nicht einfach auf einer falschen Seite abgreifen und später wiederverwenden. In der Praxis ist das der entscheidende Unterschied zu Passwort, SMS-Code oder klassischer OTP-Eingabe.

Bei synchronisierten Passkeys wandert der private Schlüssel verschlüsselt über die eigenen Geräte hinweg. Das ist gut für Komfort und Recovery. Für besonders hohe Sicherheitsstufen würde ich trotzdem device-bound Schlüssel oder Hardware-Token bevorzugen, weil NIST für AAL3 einen nicht exportierbaren Schlüssel verlangt und synchronisierbare Authenticatoren dort ausschließt.

Biometrie ist dabei meist nicht der eigentliche Identitätsbeweis, sondern die lokale Freigabe für den Schlüssel. Genau diese Unterscheidung schützt vor einem typischen Missverständnis und hält den Datenschutz sauberer, als wenn biometrische Daten selbst zum zentralen Login-Asset würden.

Wenn man das technisch verstanden hat, wird auch klarer, wann die Methode stark ist und wo sie zusätzliche Leitplanken braucht.

Wo die Methode stark ist und wo sie an Grenzen stößt

Die größte Stärke ist aus meiner Sicht die Phishing-Resistenz. Die FIDO Alliance beschreibt Passkeys genau deshalb als besonders robust gegen Phishing, Credential Stuffing und andere Remote-Angriffe. Gleichzeitig sinkt der Support-Aufwand, weil vergessene Passwörter, Reset-Schleifen und Lockouts deutlich seltener werden.

NIST SP 800-63-4 ordnet das über AALs ein; AAL steht für Authentication Assurance Level, also das geforderte Sicherheitsniveau der Anmeldung. Auf AAL2 muss eine phishing-resistente Option vorhanden sein, und auf AAL3 sind nicht exportierbare Schlüssel Pflicht. Das passt gut zu dem, was ich in Projekten beobachte: Für hohe Sicherheit reicht „ohne Passwort“ allein nicht, es braucht auch starke Recovery- und Rollenlogik.

Push-Bestätigungen und OTPs bleiben nutzbar, aber sie sind nicht mein Favorit für hohe Risiken. Sobald ein Benutzer nur noch reflexartig auf „Ja“ tippt oder einen Code abliest, kehrt ein großer Teil des alten Problems durch die Hintertür zurück.

Damit ist der Zielkonflikt klar. Im nächsten Schritt geht es darum, wie man die Umstellung so plant, dass sie nicht im Betrieb hängen bleibt.

Wie ich die Einführung in Unternehmen aufziehe

Ich würde niemals mit dem kompletten Unternehmen gleichzeitig starten. Ein guter Rollout beginnt klein, mit Rollen, die stark profitieren und gleichzeitig sauber steuerbar sind.

1. Ich starte mit IT, Admins und anderen Hochrisiko-Konten.
2. Ich definiere eine Primärmethode und mindestens einen klaren Backup-Pfad.
3. Ich prüfe, wie Geräte registriert, ersetzt und gesperrt werden.
4. Ich rolle zuerst in einer Pilotgruppe aus und messe Anmeldequote, Resets und Supportlast.
5. Ich dokumentiere Recovery, Offboarding und Rechtevergabe, bevor der breite Rollout beginnt.

Für deutsche Unternehmen ist genau dieser Teil oft wichtiger als die eigentliche Technik. Wer Identität und Zugriff ernst nimmt, braucht belastbare Prozesse für Gerätewechsel, Verlust, Fernzugriff und den Austritt von Mitarbeitenden. Sonst wird aus der modernen Anmeldung nur ein neuer Operativ-Schmerz.

Der nächste Engpass sind dann weniger die Systeme als die typischen Denkfehler bei der Umsetzung.

Die typischen Fehler, die Projekte ausbremsen

In Projekten sehe ich immer wieder dieselben Fehler. Sie sind selten spektakulär, aber sie entscheiden darüber, ob ein Vorhaben fliegt oder nach drei Monaten im Support versandet.

• SMS als Zielzustand verkaufen: Das wirkt modern, ist aber sicherheitlich oft nur eine leichte Verbesserung.
• Biometrie mit Identität verwechseln: Der Fingerabdruck entsperrt meist nur den Schlüssel, er ersetzt nicht die gesamte Vertrauenskette.
• Kein Recovery-Konzept haben: Wer Geräteverlust nicht mitdenkt, produziert sofortige Sperren und Frust.
• Ein einziges Verfahren für alle Rollen erzwingen: Admins, Partner und normale Nutzer haben nicht dasselbe Risikoprofil.
• Passwort als heimlichen Fallback behalten: Dann bleibt das alte Angriffsziel weiter erhalten.

Mein pragmatischer Rat: Erst das Risiko, dann die Methode. Wer mit Rollen, Geräten und Recovery arbeitet, macht aus einer Sicherheitsidee ein tragfähiges Betriebsmodell. Genau daraus ergibt sich auch, welcher Standard 2026 am meisten Sinn ergibt.

Warum Passkeys für die meisten Umgebungen 2026 der beste Startpunkt sind

Für die Mehrheit der Web- und Unternehmensanmeldungen würde ich heute mit Passkeys beginnen. Sie verbinden gute Nutzerführung mit einem Sicherheitsniveau, das klassische Passwörter, SMS-Codes und einfache OTP-Strecken in den meisten Szenarien klar übertrifft. Für privilegierte Konten, besonders sensible Workflows oder Umgebungen mit strengerem Assurance-Bedarf ergänze ich sie mit Hardware-Sicherheitsschlüsseln oder device-bound Verfahren.

Wenn ich ein System neu aufsetze, denke ich in dieser Reihenfolge: erst Identität sauber prüfen, dann Recovery und Gerätelebenszyklus definieren, danach den Rollout skalieren. So wird aus passwortlosen Verfahren nicht nur ein Sicherheits-Upgrade, sondern eine spürbare Entlastung für Nutzer, Support und Administration. Genau das ist in der Praxis der Unterschied zwischen einem schönen Konzept und einem funktionierenden Zugriffssystem.