Passkeys erklärt: der Schritt über Passwörter hinaus

Passwörter versagen seit dreißig Jahren, und keine noch so strenge Komplexitätsregel hat daran etwas geändert. Menschen verwenden sie mehrfach, Phishing-Seiten stehlen sie, und Datenbanken voller Passwörter gelangen jede Woche an die Öffentlichkeit. Passkeys sind die Antwort der Branche, und 2026 haben sie sich von einer vielversprechenden Idee zu einem Standard entwickelt, den Apple, Google und Microsoft inzwischen auf Milliarden von Geräten vorantreiben. Dieser Leitfaden erklärt, was ein Passkey wirklich ist, welche Abwägungen auf Sie zukommen und wie ein praktischer Plan aussieht, um sie in Ihr Produkt zu integrieren.

Was ein Passkey wirklich ist

Ein Passkey ist eine Anmeldeinformation, die auf Public-Key-Kryptografie beruht und nicht auf einem gemeinsam genutzten Geheimnis. Wenn ein Nutzer einen erstellt, generiert sein Gerät ein Schlüsselpaar. Der private Schlüssel bleibt auf dem Gerät gesperrt, geschützt durch dieselbe Biometrie oder PIN, mit der auch das Telefon oder der Laptop entsperrt wird. Der öffentliche Schlüssel geht an Ihren Server. Es gibt kein Passwort einzutippen, kein Geheimnis, das in Ihrer Datenbank liegt, und nichts, was eine gefälschte Anmeldeseite abgreifen könnte.

Die technische Grundlage bildet der WebAuthn-Standard des W3C in Kombination mit den FIDO2-Protokollen. Sie müssen sich die Abkürzungen nicht merken, aber es hilft, die Rollen zu kennen:

• Der Authenticator ist das Element, das den privaten Schlüssel hält. Das kann das Telefon, der Laptop oder ein Hardware-Sicherheitsschlüssel wie ein YubiKey sein.
• Die vertrauende Partei (Relying Party) ist Ihre Anwendung, identifiziert durch ihre Domain. Diese Bindung an Ihre exakte Domain macht Passkeys phishing-resistent.
• Die Zeremonie (Ceremony) ist der Austausch, bei dem Ihr Server eine Challenge sendet, das Gerät sie mit dem privaten Schlüssel signiert und Ihr Server die Signatur mit dem gespeicherten öffentlichen Schlüssel überprüft.

Da die Anmeldeinformation kryptografisch an Ihre Domain gebunden ist, wird ein für yourbank.com erstellter Passkey sich schlicht nicht auf yourbank-login.co anbieten. Die Nachahmerseite des Angreifers sieht nie etwas, das sie wiederverwenden könnte. Diese eine Eigenschaft beseitigt die größte Kategorie von Kontoübernahmen, die wir in der Praxis beobachten.

Synchronisierte Passkeys gegenüber gerätegebundenen Passkeys

Es gibt zwei Varianten, und die Wahl zwischen ihnen ist eine echte Designentscheidung.

Synchronisierte Passkeys werden in einem Cloud-Schlüsselbund gesichert, etwa im iCloud Keychain, im Google Password Manager oder bei einem Drittanbieter-Manager wie 1Password oder Bitwarden. Der Nutzer kann einen Passkey auf seinem Telefon erstellen und ihn Augenblicke später auf seinem Laptop verwenden. Das ist die verbraucherfreundliche Option und diejenige, die die Verbreitung vorantreibt, denn der Verlust eines Geräts sperrt Sie nicht aus.

Gerätegebundene Passkeys verlassen niemals die Hardware, auf der sie erstellt wurden. Ein Hardware-Sicherheitsschlüssel ist das klassische Beispiel. Diese sind für Szenarien mit hohem Sicherheitsbedarf stärker (denken Sie an Admin-Konsolen, Finanzwesen, Gesundheitswesen), weil der private Schlüssel physisch nicht kopiert werden kann. Allerdings erfordern sie einen Wiederherstellungsplan, da ein verlorener Schlüssel eine verlorene Anmeldeinformation bedeutet.

Die meisten Verbraucherprodukte sollten mit synchronisierten Passkeys führen und gerätegebundene Schlüssel als Härtungsoption für sensible Konten anbieten.

Warum Passkeys Passwörter und sogar ältere MFA übertreffen

Es lohnt sich, bei den Vorteilen konkret zu werden, denn „sicherer“ allein rechtfertigt noch keinen Entwicklungsaufwand.

1. Phishing-Resistenz durch Design. Die Anmeldeinformation funktioniert nur auf der echten Domain. Das schließt den Angriff, der SMS-Codes und sogar die meisten Authenticator-Apps aushebelt.
2. Nichts Wiederverwendbares zu stehlen. Ihr Server speichert öffentliche Schlüssel. Eine Datenbankverletzung gibt Daten preis, die für einen Angreifer nutzlos sind, was Ihr Risikoprofil und Ihre Meldepflichten verändert.
3. Kein gemeinsames Geheimnis auf dem Übertragungsweg. Es gibt kein Passwort, das das Netzwerk durchquert und abgefangen werden könnte, und kein Credential Stuffing, weil es keine Passwortliste zum Durchprobieren gibt.
4. Schnellere Anmeldung. Ein Gesichtsscan oder Fingerabdruck schlägt das Eintippen eines Passworts plus das Kopieren eines Codes aus einer zweiten App. Nach unserer Erfahrung verbessert sich die Conversion im Anmeldeschritt in der Regel, sobald die Reibung sinkt.
5. Geringere Support-Last. Passwort-Zurücksetzungen gehören bei jedem Produkt zu den häufigsten Tickets. Passkeys entfernen unauffällig einen großen Teil davon.

Passkeys ersetzen kein vollständiges Sicherheitsprogramm. Sie fügen sich in eines ein. Wenn Sie Identität umfassender betrachten, passen sie natürlich in das Modell, das wir unter Zero-Trust-Architektur erklärt beschreiben, wo eine starke Identität die Grundlage jeder Zugriffsentscheidung ist.

Die Abwägungen, die in der Keynote niemand erwähnt

Passkeys sind hervorragend, aber sie gut auszurollen bedeutet, ehrlich mit den rauen Kanten umzugehen.

• Die Kontowiederherstellung ist nun das schwierige Problem. Sie haben das Risiko von „das Passwort wird abgephisht“ auf „der Nutzer verliert den Zugang zu seinem Authenticator“ verlagert. Ihr Wiederherstellungsablauf wird zum sicherheitskritischsten Teil des Systems, weil er der neue Pfad ist, den ein Angreifer ins Visier nimmt.
• Die ökosystemübergreifende Geschichte ist noch uneinheitlich. Einen synchronisierten Passkey von einem Apple-Konto auf ein Android-Konto zu verschieben, ist noch nicht nahtlos. Nutzer, die in einem einzigen Ökosystem leben, sind gut versorgt. Nutzer, die Geräte mischen, geraten mitunter durcheinander.
• Das Geräteverwaltungswesen im Unternehmen bringt Einschränkungen mit sich. Verwaltete Laptops, gemeinsam genutzte Arbeitsplätze und gesperrte Browser können erschweren, wo Passkeys synchronisiert werden dürfen.
• Sie können Passwörter nicht am ersten Tag abschaffen. Über einen langen Übergang hinweg betreiben Sie beides, was zwei Codepfade und zwei Gruppen von Randfällen zum Testen bedeutet.
• Die UX-Sprache ist ungewohnt. Viele Nutzer haben das Wort Passkey noch nie gehört. Klare Texte und gute Ausweichlösungen sind ebenso wichtig wie die Kryptografie.

Keiner dieser Punkte sollte Sie aufhalten. Sie gehören lediglich in Ihren Plan und nicht in eine Überraschung nach dem Start.

Eine praktische Checkliste für den Rollout

Dies ist die Reihenfolge, der wir folgen, wenn wir Passkeys in ein Kundenprodukt einbauen. Arbeiten Sie sie der Reihe nach ab, statt zum spannenden Teil zu springen.

1. Prüfen Sie Ihre aktuelle Authentifizierung. Dokumentieren Sie jeden Anmeldepfad: Web, Mobil, API, Administration und alle Alt-Abläufe. Sie können eine neue Methode nicht sauber hinzufügen, bevor Sie jede bereits bestehende Tür kennen.
2. Fügen Sie Passkeys neben Passwörtern hinzu, nicht an deren Stelle. Bieten Sie die Passkey-Erstellung zunächst als Upgrade auf der Seite für Kontosicherheit an. Lassen Sie willige Nutzer sich dafür entscheiden, während alle anderen weiterarbeiten.
3. Implementieren Sie WebAuthn mit einer gepflegten Bibliothek. Bauen Sie die Zeremonie nicht selbst zusammen. Verwenden Sie eine gut unterstützte Server-Bibliothek (zum Beispiel SimpleWebAuthn im Node-Ökosystem) und ein seriöses Plattform-SDK auf Mobilgeräten. Dies ist ein Bereich, in dem das Neuerfinden des Rades subtile Sicherheitslücken einlädt.
4. Unterstützen Sie die bedingte Oberfläche (Autofill). Lassen Sie den Browser den Passkey im Benutzernamenfeld anzeigen, damit sich wiederkehrende Nutzer mit einem Tippen anmelden. Dieses eine Detail bewirkt den Großteil des Zuwachses bei der Verbreitung.
5. Gestalten Sie die Wiederherstellung vor dem Start. Legen Sie Ihren Ausweichpfad fest: einen zweiten Passkey, eine verifizierte E-Mail- oder Telefon-Bestätigung, Wiederherstellungscodes oder einen vom Support unterstützten Prozess mit Identitätsprüfungen. Halten Sie für jeden das Bedrohungsmodell schriftlich fest.
6. Begrenzen Sie die Rate und protokollieren Sie die Zeremonien. Behandeln Sie Registrierung und Authentifizierung als sensible Ereignisse. Alarmieren Sie bei Anomalien genauso, wie Sie es bei Passwort-Zurücksetzungen täten.
7. Sprechen Sie bestehende Nutzer im richtigen Moment an. Bieten Sie nach einer erfolgreichen Passwort-Anmeldung an, einen Passkey zu erstellen, „für eine schnellere und sicherere Anmeldung beim nächsten Mal.“ Kontextbezogene Hinweise konvertieren weitaus besser als ein Banner, das niemand liest.
8. Messen Sie, dann ziehen Sie an. Verfolgen Sie die Passkey-Verbreitung, die Erfolgsrate der Anmeldung und die Support-Tickets. Sobald die Verbreitung bei einem Konto gesund ist, können Sie erwägen, Passwörter für diese Nutzer optional zu machen.

Wenn Sie das Backend darum herum bauen, gilt dieselbe Sorgfalt dafür, wie Sie die Endpunkte bereitstellen. Unsere Anmerkungen zum Entwurf von APIs, die Entwickler lieben behandeln die Klarheit und Versionierungsdisziplin, die eine Authentifizierungsschnittstelle wartbar halten, während sie wächst.

Häufige Implementierungsfehler

Einige wenige Muster verursachen den Großteil der Probleme, die wir in Reviews sehen.

• Den Passkey als die gesamte Sicherheitsgeschichte behandeln. Er schützt die Anmeldung. Er behebt kein schwaches Sitzungsmanagement, fehlende Ratenbegrenzungen oder einen unsicheren E-Mail-Ablauf zur Wiederherstellung.
• Die Relying-Party-ID vergessen. Eine falsch konfigurierte Domain-Bindung ist der häufigste Fehler, und sie bricht entweder die Anmeldung oder, schlimmer noch, lockert den Phishing-Schutz, dessentwegen Sie gekommen sind.
• Kein Plan für verlorene Geräte. Ein Start ohne Wiederherstellungsablauf garantiert eine Welle ausgesperrter Nutzer, sobald jemand zum ersten Mal sein Telefon wechselt.
• Den Prüfpfad überspringen. Wenn Sie nicht sehen können, wann und wo Passkeys registriert wurden, können Sie einen verdächtigen später nicht untersuchen.
• Annehmen, dass jeder Nutzer bereit ist. Halten Sie eine klare Ausweichlösung und Hilfe in einfacher Sprache bereit. Verbreitung ist eine Kurve, kein Schalter.

Wie Innovation T helfen kann

Bei Innovation T bauen und sichern wir die Systeme, die hinter dem Anmeldefeld liegen. Wenn ein Kunde eine passwortlose Anmeldung wünscht, verdrahten wir nicht einfach WebAuthn und gehen wieder. Wir kartieren die bestehende Authentifizierungsschnittstelle, entwerfen einen Wiederherstellungsablauf, der einem realen Bedrohungsmodell standhält, implementieren die Zeremonien mit gepflegten Bibliotheken und stellen das Ergebnis auf die Probe. Wenn Sie bereits Passwörter einsetzen, planen wir eine schrittweise Migration, die Passkeys hinzufügt, ohne einen einzigen bestehenden Nutzer zu beeinträchtigen.

Passkeys sind eine Kontrolle innerhalb eines größeren Bildes, deshalb koppeln wir die Arbeit oft mit einer umfassenderen Prüfung. Ein gezieltes Sicherheitsaudit für Ihre Website zeigt Ihnen, wo die Authentifizierung unter Ihren tatsächlichen Risiken steht und wo sich die nächste Stunde Entwicklungsarbeit am meisten auszahlt.

Wenn Sie eine passwortlose Authentifizierung wollen, die Ihre Nutzer wirklich schätzen und Ihre Prüfer wirklich vertrauen, entdecken Sie unsere Software- und Cloud-Engineering-Leistungen oder nehmen Sie Kontakt auf. Wir helfen Ihnen zu entscheiden, was Sie bauen, in welcher Reihenfolge und wie Sie es sicher ausliefern.