Passkeys erklärt: So funktioniert Login ohne Passwort

Im Januar 2026 tauchte eine frei zugängliche Datenbank mit rund 149 Millionen Zugangsdaten auf. Das eigentlich Beunruhigende daran war nicht die schiere Menge, sondern ein Detail: Zu vielen Einträgen gehörte die passende Login-URL. Angreifer müssen also nicht mehr raten, wo ein gestohlenes Passwort funktioniert, ihre Bots klappern die Adressen automatisch ab. Im Juni legte Have I Been Pwned nach und nahm 124 Millionen neue Passwörter in seine Datenbank auf, eingesammelt von Infostealer-Malware direkt auf infizierten Rechnern. Die unbequeme Frage ist längst nicht mehr, ob eines deiner Passwörter geleakt ist, sondern wie oft.

Gleichzeitig zeigt eine Bitkom-Umfrage zum Digitaltag im Juni 2026: Nur 28 Prozent der Deutschen können erklären, was ein Passkey ist. Dabei sind 96 Prozent aller Geräte längst Passkey-fähig. Die Lösung für das Passwort-Problem liegt also buchstäblich in deiner Hosentasche, aber kaum jemand nutzt sie bewusst.

Ich baue seit über 20 Jahren Websites und habe in dieser Zeit mehr Login-Formulare, Passwort-Reset-Flows und Hashing-Migrationen umgesetzt, als mir lieb ist. Passkeys sind für mich der erste Ansatz, der das Grundproblem wirklich beseitigt, statt nur die Symptome zu verwalten. Wo kein Passwort existiert, kann keines gestohlen, erraten oder auf einer Phishing-Seite eingetippt werden.

Genau da setzen wir an, in zwei Schritten. Zuerst klären wir ohne Marketing-Nebel, wie Passkeys tatsächlich funktionieren, damit du sie erklären kannst, wenn dich jemand fragt. Danach wird es praktisch: Du siehst, wie du Passkeys mit WebAuthn in deine eigene Website einbaust. Und weil ich nichts von Schönfärberei halte, reden wir am Ende auch über die Schwachstellen. Die gibt es nämlich.

Warum Passwörter das eigentliche Problem sind

Ein Passwort ist ein geteiltes Geheimnis. Damit der Login funktioniert, muss es an zwei Orten existieren: bei dir, im Kopf oder im Passwortmanager, und beim Server, hoffentlich als ordentlicher Hash. Und genau das ist die Konstruktionsschwäche. Jede Kopie eines Geheimnisses ist ein eigenes Angriffsziel. Dich erwischt eine Phishing-Seite oder ein Infostealer auf dem Rechner, den Server erwischt ein Datenleck. Es reicht, wenn eine der beiden Seiten verliert.

Dazu kommt das Wiederverwendungs-Problem. Kaum jemand merkt sich 80 verschiedene starke Passwörter, also landet dasselbe Passwort bei mehreren Diensten. Genau darauf setzt Credential Stuffing: Angreifer nehmen geleakte Kombinationen aus Email und Passwort und probieren sie automatisiert bei anderen Diensten durch. Der Leak vom Januar macht vor, wie effizient das inzwischen läuft. Wenn zur Kombination auch noch die Login-URL gehört, muss der Bot nicht einmal mehr suchen, wo er es versuchen soll.

Nun denkst du vielleicht: Dafür gibt es doch Zwei-Faktor-Authentifizierung. Stimmt, und sie hilft auch. SMS-Codes und Authenticator-Apps machen Angriffe deutlich teurer. Aber sie sind kein Allheilmittel. Moderne Phishing-Kits arbeiten als Adversary in the Middle: Die gefälschte Seite reicht deine Eingaben in Echtzeit an die echte Seite weiter, inklusive des sechsstelligen Codes aus deiner App. Du tippst brav alles ein, der Angreifer übernimmt die Session.

Die Messlatte für ein Login-Verfahren heißt heute deshalb Phishing-resistent: Der Mensch darf gar nicht erst in die Verlegenheit kommen, sein Geheimnis auf der falschen Seite einzugeben. Genau hier setzen Passkeys an.

Was ein Passkey ist (und was nicht)

Ein Passkey ist ein kryptografisches Schlüsselpaar, das dein Gerät für genau eine Website erzeugt. Der private Schlüssel bleibt bei dir, sicher verwahrt auf dem Gerät oder im Schlüsselbund deines Passwortmanagers. Die Website bekommt nur den öffentlichen Schlüssel. Wenn du es dir bildlich merken willst: Der Server kennt dein Schloss, aber niemals deinen Schlüssel.

Das dreht die Logik des Logins komplett um. Der Server speichert nichts mehr, was man ihm stehlen könnte. Wird die Datenbank geleakt, erbeuten Angreifer eine Sammlung öffentlicher Schlüssel. Damit lässt sich genau gar nichts anfangen, kein Login, kein Credential Stuffing, kein Knacken mit der Grafikkarte. Das Shared-Secret-Problem aus dem letzten Abschnitt existiert schlicht nicht mehr.

Genauso wichtig ist, was ein Passkey nicht ist. Dein Fingerabdruck oder dein Gesicht verlassen niemals das Gerät. Die Biometrie entsperrt nur lokal den privaten Schlüssel, so wie sie auch dein Handy entsperrt. Der Server sieht davon nichts. Ein Passkey ist auch kein Magic Link. Für den Members-Bereich dieser Seite nutze ich selbst Logins per Email-Link: bequem und passwortfrei, aber am Ende nur so sicher wie dein Email-Postfach. Ein Passkey hängt an deinem Gerät und an harter Kryptografie, nicht an deinem Posteingang. Und er ist kein Trick deines Passwortmanagers, der nur besonders lange Passwörter ausfüllt. Es ist ein eigenes, standardisiertes Verfahren.

FIDO2, WebAuthn, CTAP: Die Begriffe sortiert

Rund um Passkeys schwirren ein paar Abkürzungen, die gern durcheinandergeworfen werden. Dabei ist die Sortierung simpel. FIDO2 ist der Überbegriff für die Standard-Familie, entwickelt von der FIDO Alliance zusammen mit dem W3C. WebAuthn ist die Browser-API daraus, also die Schnittstelle, über die deine Website Schlüsselpaare erzeugen und Logins prüfen lässt. CTAP regelt die Kommunikation zwischen Browser und Authenticator, zum Beispiel wenn dein Laptop den Passkey vom Smartphone nebenan abfragt. Und ein Passkey ist das Ergebnis für den Nutzer: ein FIDO-Credential, das der Browser von sich aus zum Login anbieten kann, sich je nach Anbieter über Geräte hinweg synchronisieren lässt und sich im Alltag anfühlt wie ein gespeichertes Passwort, nur ohne Passwort.

Passkey vs. Passwort im direkten Vergleich

Was bedeutet das? In fast jeder Zeile gewinnt der Passkey, und zwar nicht knapp. Die eine Zeile, in der das Passwort vorne liegt, ist der Gerätewechsel. Das ist keine Kleinigkeit, sondern der echte wunde Punkt des Systems, und wir schauen ihn uns im Abschnitt über die Grenzen ehrlich an. Aber halte kurz fest, was hier passiert: Die drei größten Angriffsklassen auf Logins, also Phishing, Credential Stuffing und geknackte Datenbanken, verschwinden nicht teilweise, sondern komplett.

So funktioniert ein Passkey-Login unter der Haube

Du musst keine Kryptografie studiert haben, um Passkeys zu verstehen. Zwei Abläufe reichen: die Registrierung und der Login.

Die Registrierung: Ein Schlüsselpaar entsteht

Wenn du bei einem Dienst einen Passkey anlegst, passiert Folgendes:

1. Der Server schickt eine Challenge, also einen einmaligen Zufallswert.
2. Dein Gerät erzeugt ein frisches Schlüsselpaar, das nur für diese eine Domain gilt.
3. Du bestätigst lokal mit Fingerabdruck, Gesicht oder Geräte-PIN, dass du das wirklich willst.
4. Der öffentliche Schlüssel wandert zusammen mit einer Credential-ID zum Server, der beides bei deinem Account speichert.

Das war die ganze Registrierung. Der private Schlüssel hat dein Gerät zu keinem Zeitpunkt verlassen, und der Server hat nichts erhalten, was ein Angreifer brauchen könnte.

Der Login: Signieren statt Geheimnis senden

Beim Login schickt der Server wieder eine frische Challenge. Dein Gerät signiert diesen Zufallswert mit dem privaten Schlüssel, nachdem du dich kurz per Fingerabdruck, Gesicht oder PIN verifiziert hast. Der Server prüft die Signatur mit dem öffentlichen Schlüssel, den er bei der Registrierung gespeichert hat. Passt sie, bist du drin.

Der entscheidende Unterschied zum Passwort: Es wird kein Geheimnis übertragen, sondern nur der Beweis, dass du es besitzt. Die Signatur gilt ausschließlich für diese eine Challenge. Wer sie mitschneidet, kann damit nichts anfangen, denn beim nächsten Login wartet ein neuer Zufallswert.

Warum Phishing ins Leere läuft

Jetzt kommt der Teil, der Passkeys wirklich besonders macht. Jeder Passkey ist fest an die Domain gebunden, für die er erstellt wurde. Diese sogenannte Relying Party ID prüft der Browser bei jedem Einsatz. Landet ein Opfer auf paypal-sicherheit.example statt auf paypal.com, bietet der Browser den PayPal-Passkey gar nicht erst an. Es gibt nichts zum Falsch-Eintippen, nichts zum Weiterleiten, nichts zum Abgreifen.

Nicht der Mensch muss die Fälschung erkennen, die Technik erkennt sie. Das ist derselbe Grundgedanke, den du vielleicht aus meinem Artikel über Security Headers kennst: Der Browser ist dein Verbündeter und setzt Regeln zuverlässiger durch als jede Schulung und jeder noch so aufmerksame Blick auf die Adresszeile. Verteidigung funktioniert am besten in Schichten, und diese Schicht sitzt genau an der Stelle, an der Menschen am häufigsten scheitern.

Passkeys 2026: Warum gerade jetzt der Wendepunkt ist

Passkeys gibt es als Standard schon ein paar Jahre. Warum also gerade jetzt darüber schreiben? Weil 2026 das Jahr ist, in dem aus der Option ein Standardverhalten wird. Microsoft aktiviert seit März in Entra ID automatisch Passkey-Profile für Unternehmenskonten und lässt dort erstmals auch synchronisierte Passkeys zu. Apple, Google und Amazon bewerben Passkeys aggressiv in ihren Login-Flows, PayPal und Co. ziehen mit. Wer sich heute irgendwo neu registriert, bekommt immer öfter zuerst einen Passkey angeboten und erst auf Nachfrage ein Passwortfeld.

Auch in Deutschland bewegt sich einiges. Das BSI hat mit der Technischen Richtlinie TR-03188 einen Standard für Passkey-Server veröffentlicht, Behörden testen Passkeys 2026 in Pilotprojekten, der breite Rollout ist für 2027 geplant. Wenn selbst die deutsche Verwaltung umstellt, ist die Technologie endgültig im Mainstream angekommen.

Und trotzdem: 96 Prozent der Geräte können Passkeys, aber nur 28 Prozent der Menschen können erklären, was das ist. Für dich ist das eine gute Ausgangslage: Als Entwickler, der das Verfahren versteht und sauber anbieten kann, bist du der Mehrheit gerade ein gutes Stück voraus.

Passkeys einbauen: WebAuthn in der Praxis

Genug Theorie, schauen wir uns den Code an. Die gute Nachricht: Die Browser-API ist überschaubarer als ihr Ruf. Die ehrliche Nachricht: Der anspruchsvolle Teil liegt auf dem Server, und dazu sage ich gleich noch etwas Deutliches.

Vorab ein praktischer Hinweis: WebAuthn funktioniert nur im Secure Context, also über HTTPS oder lokal auf localhost. Falls deine Seite noch ohne HTTPS läuft, ist das ohnehin überfällig, im Deployment-Guide findest du den Weg dahin.

Feature Detection: Kann der Browser Passkeys?

Bevor du einen Passkey-Button anzeigst, prüfst du, ob der Browser mitspielt:

async function passkeySupport() {
  // Ohne diese API geht gar nichts
  if (!window.PublicKeyCredential) {
    return { login: false, create: false };
  }

  // Unterstützt der Browser Passkeys im Autofill-Dropdown?
  // Ältere Browser kennen die Methode selbst noch nicht,
  // deshalb der Existenz-Check davor
  const login =
    !!PublicKeyCredential.isConditionalMediationAvailable &&
    (await PublicKeyCredential.isConditionalMediationAvailable());

  // Kann dieses Gerät eigene Passkeys anlegen und den Nutzer
  // lokal verifizieren (Fingerabdruck, Gesicht, PIN)?
  const create =
    await PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable();

  return { login, create };
}

Dass hier zwei getrennte Werte zurückkommen, ist Absicht. Für den Login reicht die Unterstützung im Autofill-Dropdown, denn der Passkey kann auch vom Smartphone nebenan kommen, selbst wenn der Rechner keinen Fingerabdruck-Sensor hat. Der zweite Wert entscheidet nur darüber, ob du das Anlegen eines Passkeys auf diesem Gerät anbietest. Und fällt beides negativ aus, zeigst du einfach weiter deinen klassischen Login. Passkeys führst du ohnehin am besten als zusätzliche Option ein, nicht als Zwangsumstellung.

Registrierung mit navigator.credentials.create

Das Herzstück der Registrierung ist ein einziger API-Aufruf. Die Optionen dafür kommen vom Server, denn die Challenge darf niemals im Client erzeugt werden. Eine Kleinigkeit vorweg: WebAuthn erwartet binäre Werte als ArrayBuffer, deshalb brauchst du eine kleine Hilfsfunktion, die Base64-Strings vom Server umwandelt.

// Registrierungs-Optionen inklusive Challenge vom Server holen
const options = await fetch("/api/passkey/register-options").then((res) =>
  res.json(),
);

const credential = await navigator.credentials.create({
  publicKey: {
    // Einmaliger Zufallswert vom Server, verhindert Replay-Angriffe
    challenge: base64ToBuffer(options.challenge),

    // Deine Website als "Relying Party": An diese Domain
    // wird der Passkey fest gebunden
    rp: { id: "deine-domain.de", name: "Deine App" },

    // Interne User-ID plus Anzeigenamen für die Passkey-Verwaltung
    user: {
      id: base64ToBuffer(options.userId),
      name: "mario@example.com",
      displayName: "Mario",
    },

    // Erlaubte Signatur-Algorithmen: ES256 (-7) und RS256 (-257)
    // decken praktisch alle Geräte ab
    pubKeyCredParams: [
      { type: "public-key", alg: -7 },
      { type: "public-key", alg: -257 },
    ],

    authenticatorSelection: {
      // "required" macht das Credential auffindbar, erst damit
      // verhält es sich wie ein echter Passkey
      residentKey: "required",
      // Lokale Verifikation per Biometrie oder PIN, wenn möglich
      userVerification: "preferred",
    },
  },
});

// credential geht zur Prüfung und Speicherung an den Server

Mehr ist es auf der Client-Seite nicht. Der Browser übernimmt den kompletten Dialog mit dem Nutzer, inklusive Biometrie-Abfrage und der Auswahl, ob der Passkey aufs Handy oder in den Passwortmanager soll.

Login mit Conditional UI

Für den Login gibt es einen eleganten Trick namens Conditional UI. Du ergänzt dein normales Login-Formular um ein Attribut:

<input type="text" name="username" autocomplete="username webauthn" />

Dann rufst du die API mit mediation: "conditional" auf:

const options = await fetch("/api/passkey/login-options").then((res) =>
  res.json(),
);

const assertion = await navigator.credentials.get({
  publicKey: {
    challenge: base64ToBuffer(options.challenge),
    rpId: "deine-domain.de",
  },
  // "conditional" zeigt Passkeys direkt im Autofill-Dropdown an,
  // ganz ohne eigenen "Mit Passkey anmelden"-Button
  mediation: "conditional",
});

// assertion enthält die Signatur und geht zur Prüfung an den Server

Das Ergebnis fühlt sich für Nutzer sofort vertraut an: Der Passkey erscheint im selben Dropdown, in dem früher das gespeicherte Passwort stand. Einmal antippen, kurz der Fingerabdruck, fertig. Kein neues UI-Konzept, keine Umgewöhnung, und genau deshalb funktioniert es.

Der Server-Teil: Bitte nicht selbst bauen

Jetzt der versprochene deutliche Satz. Auf dem Server muss einiges geprüft werden: dass die Challenge stimmt und nur einmal verwendet wird, dass Origin und RP-ID-Hash zur eigenen Domain passen, dass die Signatur zum gespeicherten öffentlichen Schlüssel passt und dass der Signature Counter bei gerätegebundenen Authenticatoren keine geklonte Hardware verrät (synchronisierte Passkeys melden hier meist konstant 0). Das ist Krypto-Handwerk mit vielen scharfen Kanten, und es ist exakt die Sorte Code, die man nicht selbst schnitzt.

Nimm eine geprüfte Library. Für Node und TypeScript ist SimpleWebAuthn der Standard, für PHP übernimmt web-auth/webauthn-lib denselben Job. Wer es formal mag: Die BSI-Richtlinie TR-03188 beschreibt haarklein, was ein Passkey-Server können muss.

Ein Handgriff fehlt noch auf dem Weg dorthin: Das rohe Credential aus dem Browser enthält binäre ArrayBuffer, die Library erwartet aber JSON. Bevor du es per fetch verschickst, wandelst du es deshalb mit credential.toJSON() um, in modernen Browsern erledigt JSON.stringify(credential) das automatisch. Noch bequemer nimmt dir startRegistration() aus @simplewebauthn/browser gleich beide Umwandlungsrichtungen ab. Auf dem Server sieht die Verifikation der Registrierung dann so aus:

import { verifyRegistrationResponse } from "@simplewebauthn/server";

const verification = await verifyRegistrationResponse({
  response: credential,
  expectedChallenge: session.challenge,
  expectedOrigin: "https://deine-domain.de",
  expectedRPID: "deine-domain.de",
});

// verification.verified plus verification.registrationInfo
// liefern alles, was du in der Datenbank speichern musst

Damit du keine falschen Erwartungen hast: Ein produktionsreifer Passkey-Login ist mit diesen Snippets nicht fertig. Es fehlen die Session-Anbindung, die Recovery-Wege, das Rate Limiting auf den Auth-Endpoints und die Entscheidung, wie Passkeys und bestehende Passwörter nebeneinander leben. Das sprengt einen Blogartikel, und es ist genau der Punkt, an dem aus einem Code-Beispiel ein durchdachtes Auth-System werden muss.

Die ehrlichen Grenzen von Passkeys

Wenn du meine Artikel kennst, weißt du, dass jetzt der Teil kommt, den Marketing-Seiten gern weglassen. Passkeys lösen das Passwort-Problem, aber sie handeln sich drei neue Baustellen ein.

Account-Recovery: Die Achillesferse

Was passiert, wenn das Gerät mit dem Passkey im See liegt? Ohne Sync ist der Passkey weg, und der Dienst braucht einen Wiederherstellungsweg. In der Praxis ist das fast immer ein Email-Reset, manchmal ein Recovery-Code. Und damit gilt ein Satz, den du dir merken solltest: Dein Account ist nur so sicher wie sein schwächster Wiederherstellungsweg. Ein Account mit perfektem Passkey-Login und ungesichertem Email-Postfach ist am Ende so sicher wie das Postfach. Für dich als Entwickler heißt das: Der Recovery-Flow gehört durchdacht, bevor der erste Passkey live geht, nicht danach.

Das Fallback-Passwort als Hintertür

Die meisten Dienste bieten Passkeys heute zusätzlich zum Passwort an. Verständlich, niemand will Nutzer aussperren. Aber solange das Passwort weiter existiert, bleibt auch der Phishing-Vektor offen. Ein Angreifer phisht dann eben nicht den Passkey, sondern schickt sein Opfer auf die gute alte Passwort-Seite. Ein Passkey als Zusatz ist erst einmal Komfort. Der echte Sicherheitsgewinn beginnt, wenn das Passwort deaktiviert oder der Passwort-Login zusätzlich abgesichert wird, und diese Möglichkeit bieten 2026 noch die wenigsten Dienste an.

Sync, Lock-in und der Gerätewechsel

Passkeys synchronisieren sich bequem, solange du im selben Ökosystem bleibst: iCloud-Schlüsselbund bei Apple, Google Passwortmanager bei Android und Chrome, Microsoft-Konto samt Password Manager bei Windows. Der Wechsel zwischen den Welten ist dagegen noch Handarbeit, oft läuft er auf eine Neuregistrierung pro Dienst hinaus. Wer dem vorbeugen will, legt seine Passkeys in einen plattformübergreifenden Passwortmanager wie 1Password oder Bitwarden. Die FIDO Alliance arbeitet mit dem Credential-Exchange-Format an einem Standard für den Umzug zwischen Anbietern, der Rollout läuft aber noch.

Zum Abschluss die Einordnung, die bei aller Kritik nicht fehlen darf: Der Vergleichsmaßstab für Passkeys ist nicht Perfektion. Der Maßstab ist der Status quo, und der besteht aus wiederverwendeten Passwörtern, Phishing-Mails und 149 Millionen geleakten Zugangsdaten in einer einzigen Datenbank. Gemessen daran sind die drei Baustellen oben ein sehr fairer Preis.

Deine Passkey-Checkliste

Zum Abhaken, zweigeteilt nach Perspektive.

Als Nutzer:

• Ersten Passkey bei einem großen Anbieter anlegen (Google, Apple, Microsoft oder PayPal), das dauert etwa zwei Minuten
• Prüfen, ob sich der Passwort-Login danach deaktivieren oder zumindest zusätzlich absichern lässt
• Sync-Strategie festlegen: eigenes Ökosystem oder plattformübergreifender Passwortmanager
• Recovery-Codes an einem Ort sichern, den ein Geräteverlust nicht mitreißt

Als Entwickler:

• Feature Detection einbauen und Passkeys als zusätzliche Option starten, nicht als Zwangsumstellung
• Registrierung und Login über eine geprüfte Library wie SimpleWebAuthn abwickeln, nie selbst implementieren
• Conditional UI aktivieren, damit Passkeys im Autofill-Dropdown auftauchen
• Recovery-Flow designen, bevor der erste Passkey live geht
• Rate Limiting auf alle Auth-Endpoints legen
• Die Abschaltung des Passwort-Logins als langfristiges Ziel einplanen

Wie es weitergeht

Passkeys sind ein starker Baustein, aber eben ein Baustein. Ein Login-System, das diesen Namen verdient, braucht mehr: sicheres Password-Hashing für die Übergangszeit, in der Passwörter noch existieren, sauberes Session-Management, CSRF-Schutz, Multi-Faktor-Flows mit durchdachten Recovery-Codes und eine Zugriffskontrolle, die auch hält, was sie verspricht. Diese Themen greifen ineinander, und wer sie einzeln zusammengoogelt, übersieht erfahrungsgemäß genau die Lücke, die später wehtut.

Wenn du Authentifizierung und Web-Sicherheit systematisch lernen möchtest, schau dir den Web Security Mastery Kurs an. In 30 Tagen gehst du vom Security-Mindset über die OWASP Top 10 bis zu Authentifizierung, API-Sicherheit und einem abschließenden Praxis-Audit deiner eigenen Anwendung. Die komplette dritte Woche dreht sich nur um Auth: Hashing, Sessions, JWT, CSRF, MFA und Zugriffskontrolle.

Für heute reicht es, wenn du deinen ersten Passkey anlegst. Zwei Minuten, und du hast einen Login ohne Passwort einmal selbst in der Hand gehabt. Das ist ein guter Anfang.