Passkeys & FIDO2: Passwortlose Authentifizierung erklärt

Passkeys sind der bislang ernsthafteste Versuch, das Passwort abzulösen, und anders als frühere Anläufe wird er von Apple, Google und Microsoft gleichzeitig getragen. Laut dem Report „The State of Passkeys 2026" der FIDO Alliance (veröffentlicht am 7. Mai 2026) sind weltweit rund 5 Milliarden Passkeys aktiv im Einsatz. Trotzdem herrscht bei vielen Verantwortlichen Verwirrung: Was genau ist ein Passkey, was ist FIDO2, was WebAuthn, und wie hängt das mit den bekannten Hardware-Sicherheitsschlüsseln zusammen?

Dieser Artikel räumt mit der Begriffsverwirrung auf und geht deutlich tiefer als die üblichen Erklärstücke. Sie erhalten eine wasserdichte Begriffshierarchie (FIDO2 = WebAuthn + CTAP2, Passkey als discoverable credential), die kryptografischen Grundlagen der Phishing-Resistenz, echten, lauffähigen Code für die Registrierung und den Login im Browser sowie das native iOS-Pendant in Swift. Dazu kommt ein ehrlicher Abschnitt über die Grenzen von Passkeys, den die meisten Anbieter verschweigen, gestützt auf die differenzierte Einschätzung des britischen National Cyber Security Centre (NCSC).

Am Ende wissen Sie nicht nur, warum Passkeys Phishing praktisch aushebeln, sondern auch, wo ihre realen Schwachstellen liegen (Recovery, Ökosystem-Lock-in, Enterprise-Rollout) und wie Sie Passkeys als Nutzer oder als Organisation sinnvoll einführen.

Was sind Passkeys und FIDO2? Die Begriffe sauber sortiert

Der häufigste Fehler in Erklärartikeln ist, Passkeys und FIDO2 gleichzusetzen oder als konkurrierende Dinge darzustellen. Beides ist falsch. Die klarste Kurzformel stammt vom Identitätsdienstleister Corbado: „FIDO2 ist ein Standard, Passkeys sind seine Implementierung." Sortieren wir das von unten nach oben.

FIDO2 = WebAuthn + CTAP2

FIDO2 ist kein einzelnes Protokoll, sondern der Sammelbegriff der FIDO Alliance für die Kombination aus zwei komplementären Spezifikationen:

WebAuthn (Web Authentication) ist der offizielle Standard des World Wide Web Consortium (W3C). Er definiert die Browser- und Client-API, konkret die Aufrufe navigator.credentials.create() (Registrierung) und navigator.credentials.get() (Anmeldung). WebAuthn beschreibt also die abstrakten Operationen zwischen Webanwendung und Client.
CTAP2 (Client to Authenticator Protocol 2) ist die Spezifikation der FIDO Alliance für die Kommunikation zwischen dem Client-Gerät (etwa dem Laptop) und einem externen Authentikator (etwa einem USB-Sicherheitsschlüssel) über USB, NFC, Bluetooth Low Energy (BLE) oder den neueren Hybrid-Transport.

Wichtig ist das Verhältnis der beiden: Es sind keine konkurrierenden Standards, sondern zwei Schichten desselben Projekts. WebAuthn definiert, was passiert (erstelle ein Credential, signiere eine Challenge), CTAP2 liefert die konkreten Parameter und Kommandos, wie das Gerät das tut. Das Deutsche Bundesamt für Sicherheit in der Informationstechnik (BSI), seit 2015 selbst Mitglied der FIDO Alliance, beschreibt WebAuthn treffend als „Kernkomponente von FIDO2".

Was ist ein Passkey genau?

Ein Passkey ist ein FIDO2-Credential in einer für Endnutzer verständlich benannten Form, kein separater technischer Standard. Der Begriff ist bewusst konsumentenfreundlich und plattformunabhängig gewählt. Laut FIDO Alliance ist „Passkey" ein gewöhnliches Substantiv (im Englischen kleingeschrieben, außer am Satzanfang). Geprägt wurde der Begriff 2022 durch Apple, Google und Microsoft im Rahmen ihrer gemeinsamen Multi-Device-FIDO-Credentials-Initiative.

Technisch ist ein Passkey ein sogenanntes discoverable credential (siehe unten). Der entscheidende Punkt: Passkey ist der Marketing- und UX-Begriff, WebAuthn und CTAP2 sind die technischen Spezifikationen darunter. In den CTAP-Spezifikationen selbst kommt das Wort „Passkey" gar nicht vor.

Damit ergibt sich diese Hierarchie:

FIDO2 ist das Standardpaket der FIDO Alliance.
WebAuthn (W3C) und CTAP2 (FIDO Alliance) sind die zwei Spezifikationen, aus denen FIDO2 besteht.
Passkey ist die nutzerfreundliche Bezeichnung für ein damit erzeugtes Anmelde-Credential.

Wie funktioniert die Authentifizierung mit Passkeys kryptografisch?

Der Kern jedes Passkeys ist asymmetrische Kryptografie, also ein Schlüsselpaar aus einem privaten und einem öffentlichen Schlüssel. Anders als bei klassischen Passwörtern gibt es kein gemeinsames Geheimnis, das gestohlen werden könnte.

An jeder Passkey-Interaktion sind laut BSI drei Rollen beteiligt, die die W3C-WebAuthn-Spezifikation ebenso definiert:

Relying Party (RP): der Onlinedienst oder die Webseite, bei der Sie sich anmelden. Sie wird über ihre RP-ID (im Wesentlichen die Domain) identifiziert.
Client: der Browser oder das Betriebssystem, das die WebAuthn-API bereitstellt.
Authentikator (Authenticator): die kryptografische Entität, die die Schlüssel erzeugt und verwahrt. Sie kann in das Gerät integriert sein (Platform-Authentikator, etwa Windows Hello oder die Secure Enclave im iPhone) oder extern (Roaming-Authentikator, etwa ein YubiKey).

Registrierung: das Schlüsselpaar entsteht

Bei der Registrierung erzeugt der Authentikator laut BSI „ein neues Schlüsselpaar, also einen geheimen privaten Schlüssel und einen zugehörigen öffentlichen Schlüssel". Der private Schlüssel verlässt die sichere Hardware des Geräts nie. Nur der öffentliche Schlüssel wandert zur Relying Party und wird dort im Nutzerkonto gespeichert.

Entscheidend ist die Domänenbindung: Ein Authentikator muss „für jede Webseite und für jeden Benutzer ein eigenes Schlüsselpaar erzeugen" (BSI). Das ist technisch erzwungen, nicht nur empfohlen. Genau daraus resultiert die Phishing-Resistenz: Ein für bank.de erzeugter Passkey funktioniert schlicht nicht auf bank-secure-login.com.

Anmeldung: Challenge und Response

Bei jeder Anmeldung läuft ein Challenge-Response-Verfahren ab. Das BSI beschreibt es präzise: Die Webseite sendet „eine Nachricht an den Client, die eine kryptografische Challenge enthält. Die Challenge ist nicht mehr als eine hinreichend große Zufallszahl." Der Authentikator signiert diese Challenge mit dem privaten Schlüssel, und die Webseite verifiziert die Signatur „anhand des bei der Registrierung hinterlegten öffentlichen Schlüssels".

Microsoft beschreibt denselben Ablauf in seiner Entra-ID-Dokumentation Schritt für Schritt:

Der Nutzer initiiert die Anmeldung bei der Relying Party.
Er wählt einen Passkey (auf demselben Gerät, geräteübergreifend per QR-Code oder als Sicherheitsschlüssel).
Der Dienst sendet eine Challenge (Nonce) an den Authentikator.
Der Authentikator lokalisiert das passende Schlüsselpaar über die gehashte RP-ID und die Credential-ID.
Der Nutzer bestätigt per Biometrie oder PIN, um den privaten Schlüssel zu entsperren.
Der Authentikator signiert die Challenge und gibt die Signatur zurück.
Der Dienst verifiziert die Signatur mit dem öffentlichen Schlüssel und stellt ein Token aus.

Weil das Geheimnis (der private Schlüssel) das Gerät nie verlässt und niemals übertragen wird, sind klassische Angriffe wie Phishing, Credential Stuffing, Replay oder das Abgreifen aus einer geleakten Datenbank praktisch wirkungslos. Selbst bei einem erfolgreichen Serverangriff erbeutet ein Angreifer nur öffentliche Schlüssel, mit denen sich niemand anmelden kann.

Die wichtigsten Fachbegriffe im Detail

Hier trennt sich Präzision von Halbwissen. Diese Begriffe sollten Sie sauber auseinanderhalten können.

Discoverable Credential (Resident Key)

Ein discoverable credential, in der CTAP2-Welt als resident key bezeichnet, ist laut W3C eine „Public Key Credential Source, die auffindbar ist und in Authentifizierungszeremonien nutzbar ist, in denen die Relying Party keine Credential-IDs bereitstellt". Im Klartext: Der Authentikator kann das passende Credential selbst finden, ohne dass Sie vorher einen Nutzernamen eingeben. Genau das ermöglicht den „usernamelosen" Login, bei dem Sie nur noch auf einen Button tippen und sich biometrisch bestätigen. In CTAP2 entspricht das dem Options-Flag rk beim Kommando authenticatorMakeCredential. Jeder Passkey im heutigen Sprachgebrauch ist ein solches discoverable credential.

Attestation

Attestation ist laut W3C eine „Aussage, die Herkunft und ausgegebene Daten des Authentikators während der Registrierung bezeugt". Sie liefert einer Relying Party eine kryptografisch verifizierbare Geräteidentität, abgeglichen über den FIDO Metadata Service (MDS). Damit kann eine Organisation erzwingen, dass nur bestimmte, zertifizierte Authentikator-Modelle akzeptiert werden.

Wichtig und oft übersehen: Synchronisierte Passkeys unterstützen keine Attestation (Microsoft Entra-Dokumentation). Aktiviert eine Relying Party die Attestationspflicht, sind faktisch nur device-bound Passkeys und Hardware-Sicherheitsschlüssel zulässig, synchronisierte Passkeys werden dann ausgeschlossen. In Microsoft Entra ID lässt sich das auf Passkey-Profil-Ebene konfigurieren.

User Presence vs. User Verification

Diese beiden Begriffe werden oft verwechselt, bedeuten aber Unterschiedliches:

User Presence (UP) ist nur eine Interaktionsgeste, etwa ein Tastendruck am Sicherheitsschlüssel. Sie bestätigt, dass ein Mensch anwesend ist, prüft aber nicht dessen Identität.
User Verification (UV) erfordert eine echte Identitätsprüfung durch Biometrie (Fingerabdruck, Gesicht) oder PIN. Erst dadurch wird der Passkey laut BSI faktisch zu einem Zwei-Faktor-Vorgang und damit zu einer Form der Multi-Faktor-Authentifizierung: Besitz des Geräts plus Wissen (PIN) oder Inhärenz (Biometrie).

Das ist auch der Grund, warum das BSI betont, dass Passkeys einen zweiten Faktor benötigen: Ohne biometrische Hürde könnte „jede Person, die ein Smartphone findet, einen Laptop ausleiht oder ein Tablet stiehlt, die Zugänge des Eigentümers kompromittieren".

Synced vs. Device-Bound Passkeys

Dies ist die wichtigste praktische Unterscheidung, und das BSI liefert dazu die klarste kritische Einordnung.

Device-Bound (hardwaregebunden): Der Schlüssel ist „an genau den Authentikator gebunden, auf dem er erzeugt wurde" (BSI). Er ist nicht kopierbar und nicht synchronisierbar. Beispiele: FIDO2-Sicherheitsschlüssel wie ein YubiKey, oder ein an die Microsoft-Authenticator-App gebundener Passkey.
Synced (synchronisiert, cloud-basiert): Die Schlüssel „sind also duplizierbar, lassen sich in einer Cloud hinterlegen oder mit weiteren Geräten synchronisieren" (BSI). Dadurch überleben sie den Verlust eines Geräts. Beispiele: Apple iCloud Keychain, Google Password Manager.

Microsoft ergänzt den technischen Ablauf bei synchronisierten Passkeys: Ein Hardware Security Module (HSM) erzeugt den Schlüssel, verschlüsselt ihn lokal und synchronisiert ihn erst dann in die Cloud des Anbieters. Andere Geräte, die beim selben Anbieter authentifiziert sind, können den Passkey danach nutzen.

Der Komfortgewinn hat einen Preis. Das BSI benennt ihn offen: Mit der „Kopierbarkeit und der Speicherung der Schlüssel in Anbieter-Clouds geht ein gewisser Sicherheitsverlust einher. In der Theorie könnten die Server kompromittiert, die Schlüssel kopiert und missbraucht werden." Diese ausgewogene Position einer Bundesbehörde fehlt in fast allen Marketing-nahen Darstellungen.

Passkey vs. klassischer FIDO2-Sicherheitsschlüssel

Ein häufiges Missverständnis: Passkey und FIDO2-Sicherheitsschlüssel seien Gegensätze. Sind sie nicht. Ein klassischer USB- oder NFC-Sicherheitsschlüssel (etwa ein YubiKey) erzeugt und speichert das Schlüsselpaar ausschließlich hardwaregebunden, kann aber ebenfalls ein discoverable credential, also einen Passkey im technischen Sinn, enthalten.

Der Unterschied liegt also nicht im Protokoll (beide nutzen FIDO2, WebAuthn und CTAP2), sondern im Speicherort und in der Synchronisierbarkeit: dedizierte, nicht kopierbare Hardware auf der einen Seite, cloud-synchronisierte Software-Credentials auf der anderen. Im allgemeinen Sprachgebrauch meint „Passkey" meist die synchronisierbare, konsumentenfreundliche Variante, während „Sicherheitsschlüssel" für die hardwaregebundene steht.

WebAuthn in der Praxis: lauffähiger Code

Genau hier ist die größte Lücke der Konkurrenz. Kaum ein Erklärartikel zeigt echten Code. Die folgenden Beispiele stammen wörtlich aus der W3C-WebAuthn-Spezifikation und der offiziellen Entwickler-Dokumentation von Google (web.dev, zuletzt aktualisiert am 9. April 2026). Wichtiger Hinweis vorab: Bauen Sie den Passkey-Server nicht selbst. Google warnt ausdrücklich, das sei „nicht zeiteffizient und könnte Bugs verursachen, die zu einem kritischen Sicherheitsvorfall führen". Nutzen Sie eine etablierte WebAuthn-Bibliothek für die serverseitige Verifikation.

Registrierungsoptionen (Server → Client)

Die Relying Party stellt zunächst ein PublicKeyCredentialCreationOptions-Objekt bereit. So sieht ein typisches Optionsobjekt aus:

{
  challenge: *****,
  rp: {
    name: "Example",
    id: "example.com",
  },
  user: {
    id: *****,
    name: "john78",
    displayName: "John",
  },
  pubKeyCredParams: [{
    alg: -7, type: "public-key"
  },{
    alg: -257, type: "public-key"
  }],
  excludeCredentials: [{
    id: *****,
    type: 'public-key',
    transports: ['internal'],
  }],
  authenticatorSelection: {
    authenticatorAttachment: "platform",
    requireResidentKey: true,
  }
}

Die wichtigsten Felder laut W3C-Spezifikation:

challenge: server-generierte Zufallsbytes, schützen gegen Replay-Angriffe.
rp: Name und ID (Domain) der Relying Party.
user: Kontodaten mit id, name und displayName.
pubKeyCredParams: akzeptierte Algorithmen. Die Werte sind COSE-Identifier: alg: -7 steht für ES256 (ECDSA mit P-256 und SHA-256), alg: -257 für RS256 (RSASSA-PKCS1-v1_5 mit SHA-256).
excludeCredentials: bereits registrierte Credentials, um Doppelregistrierung zu verhindern.
authenticatorSelection: Kriterien zur Authentikator-Auswahl. requireResidentKey: true erzwingt ein discoverable credential (also einen echten Passkey), authenticatorAttachment: "platform" bevorzugt den geräteintegrierten Authentikator.

Passkey erstellen (Client)

Auf der Client-Seite ruft die Webanwendung navigator.credentials.create() auf. Die moderne Variante nutzt die Hilfsfunktion parseCreationOptionsFromJSON(), um die JSON-Antwort des Servers direkt in das benötigte Format zu überführen:

const _options = await fetch('/webauthn/registerRequest');
const decoded_options = await _options.json();
const options = PublicKeyCredential.parseCreationOptionsFromJSON(decoded_options);

const credential = await navigator.credentials.create({
  publicKey: options
});

Die minimale, aus der W3C-Spezifikation stammende Kernform des Aufrufs sieht so aus:

navigator.credentials.create({ publicKey })
  .then(function (newCredentialInfo) {
    // Neue Credential-Informationen an den Server senden
  }).catch(function (err) {
    // Fehlerbehandlung
  });

Nach der biometrischen Bestätigung erzeugt der Authentikator das Schlüsselpaar und gibt ein Public-Key-Credential zurück. Dieses schicken Sie an das Backend, das den öffentlichen Schlüssel und die Credential-ID dauerhaft speichert:

const _result = credential.toJSON();
const result = JSON.stringify(_result);

const response = await fetch('/webauthn/registerResponse', {
  method: 'post',
  credentials: 'same-origin',
  body: result
});

Anmeldung (Login)

Für die Anmeldung ruft die Relying Party navigator.credentials.get() mit einem PublicKeyCredentialRequestOptions-Objekt auf. Die Kernform aus der W3C-Spezifikation:

navigator.credentials.get({ "publicKey": options })
  .then(function (assertion) {
    // Assertion zur Verifikation an den Server senden
  }).catch(function (err) {
    // Fehlerbehandlung
  });

Die Request-Optionen enthalten laut Spezifikation die Pflicht-challenge, optional timeout, rpId, allowCredentials (kann für discoverable credentials leer bleiben) und extensions. Der Authentikator erzeugt eine signierte Assertion, die das Backend gegen den gespeicherten öffentlichen Schlüssel prüft.

Verwaiste Credentials melden

Ein nützliches Detail aus WebAuthn Level 3: Wenn der Server ein Credential nicht mehr kennt (etwa nach einer Kontolöschung), kann der Client den Passkey-Anbieter darüber informieren, damit dieser den verwaisten Passkey aus seiner Liste entfernt:

if (response.status === 404) {
  if (PublicKeyCredential.signalUnknownCredential) {
    await PublicKeyCredential.signalUnknownCredential({
      rpId: "example.com",
      credentialId: "vI0qOggiE3OT01ZRWBYz5l4MEgU0c7PmAA"
    });
  }
}

Solche Signal-Methoden (signalUnknownCredential, signalAllAcceptedCredentials, signalCurrentUserDetails) sowie getClientCapabilities() sind Neuerungen von WebAuthn Level 3 gegenüber Level 2.

Passkeys nativ auf iOS: Swift-Code

Im Web nutzen Sie die WebAuthn-JavaScript-API. In nativen iOS-Apps übernimmt das AuthenticationServices-Framework von Apple dieselbe Aufgabe über die Klasse ASAuthorizationPlatformPublicKeyCredentialProvider. Voraussetzung: Die relyingPartyIdentifier (die Domain) muss exakt mit der über die „Associated Domains"-Capability konfigurierten Domain übereinstimmen, sonst schlägt die Passkey-Erstellung fehl.

Registrierungsanfrage erstellen

let provider = ASAuthorizationPlatformPublicKeyCredentialProvider(
    relyingPartyIdentifier: "example.com")

let registrationRequest = provider.createCredentialRegistrationRequest(
    challenge: challenge, displayName: email, userID: userID)

let authController = ASAuthorizationController(authorizationRequests: [registrationRequest])
authController.delegate = self
authController.presentationContextProvider = self
authController.performRequests()

Registrierungs-Callback

Im Delegate-Callback casten Sie das Ergebnis auf ASAuthorizationPlatformPublicKeyCredentialRegistration und entnehmen ihm Credential-ID, ClientDataJSON und Attestation-Objekt für die serverseitige Verifikation:

func authorizationController(
    controller: ASAuthorizationController,
    didCompleteWithAuthorization authorization: ASAuthorization
) {
    if let credential = authorization.credential
        as? ASAuthorizationPlatformPublicKeyCredentialRegistration {
        let credentialID = credential.credentialID
        let clientDataJSON = credential.rawClientDataJSON
        let attestationObject = credential.rawAttestationObject
        // Diese Werte zur Verifikation ans Backend senden
    }
}

Anmeldung und Fallunterscheidung

Für den Login erstellen Sie eine Assertion-Anfrage. Derselbe Delegate-Callback unterscheidet dann sauber zwischen Registrierung (Attestation) und Anmeldung (Assertion):

let request = credentialProvider.createCredentialAssertionRequest(challenge: challenge)

func authorizationController(
    controller: ASAuthorizationController,
    didCompleteWithAuthorization authorization: ASAuthorization
) {
    switch authorization.credential {
    case let registration as ASAuthorizationPlatformPublicKeyCredentialRegistration:
        // Attestation-Daten ans Backend senden (Registrierung abschließen)
    case let assertion as ASAuthorizationPlatformPublicKeyCredentialAssertion:
        let signature = assertion.signature
        let clientDataJSON = assertion.rawClientDataJSON
        let authenticatorData = assertion.rawAuthenticatorData
        let credentialID = assertion.credentialID
        // Signatur und zugehörige Daten ans Backend senden (Login abschließen)
    default:
        break
    }
}

Das Muster ist auf allen Plattformen dasselbe: Der Client erzeugt beziehungsweise nutzt das Credential lokal, und Ihr Backend verifiziert kryptografisch. Das Backend ist die Vertrauensinstanz, niemals der Client.

CTAP2 unter der Haube: was das Gerät wirklich tut

WebAuthn beschreibt nur die Browser-Seite. Sobald ein externer Authentikator wie ein YubiKey ins Spiel kommt, regelt CTAP2 die Kommunikation. Die abstrakten WebAuthn-Operationen werden dabei auf konkrete CTAP-Kommandos abgebildet:

navigator.credentials.create() löst auf Geräteebene das CTAP-Kommando authenticatorMakeCredential (0x01) aus.
navigator.credentials.get() entspricht authenticatorGetAssertion (0x02).

Die Parameter werden dabei sauber übersetzt (WebAuthn-zu-CTAP-Mapping): Aus WebAuthn requireResidentKey wird die CTAP-Option options.rk, aus requireUserVerification wird options.uv beziehungsweise ein pinUvAuthParam, aus dem rpEntity das CTAP-rp. Die Daten werden in CBOR (Concise Binary Object Representation) kodiert.

Für die Cross-Device-Authentifizierung (CDA), also die Anmeldung an einem Gerät mit dem Passkey eines anderen Geräts, ist der Hybrid-Transport aus CTAP 2.2 zuständig. Er wird per QR-Code initiiert und nutzt Bluetooth Low Energy nur zur Näherungsprüfung, während die eigentliche kryptografische Sicherheit unabhängig von Bluetooth bleibt. Die aktuelle FIDO2-Zertifizierungsgrundlage ist laut Yubico-Entwicklerdokumentation (Stand 22. Mai 2026) inzwischen CTAP 2.3, vollständig rückwärtskompatibel zu 2.2.

Sie müssen diese Protokolldetails für eine Implementierung nicht selbst beherrschen, Ihre WebAuthn-Bibliothek und das Betriebssystem erledigen das Mapping. Aber es erklärt, warum FIDO2 aus zwei Spezifikationen besteht: WebAuthn allein könnte einen externen Sicherheitsschlüssel gar nicht ansprechen.

Zahlen und Verbreitung: was belegt ist und was nicht

Bei Statistiken zu Passkeys ist Vorsicht geboten, weil verschiedene Aussteller ähnlich klingende, aber nicht identische Zahlen liefern. Wir nennen daher zu jeder Zahl Quelle, Grundgesamtheit und Zeitraum.

Belastbare Primärquellen

Die methodisch sauberste Quelle ist der FIDO-Alliance-Report „The State of Passkeys 2026" (7. Mai 2026), durchgeführt vom Institut Sapio Research:

Rund 5 Milliarden Passkeys sind weltweit aktiv im Einsatz.
90 % der Konsumenten kennen Passkeys, 75 % haben sie auf mindestens einem Konto aktiviert. Grundgesamtheit: 11.000 Erwachsene aus zehn Ländern (darunter Deutschland), regelmäßige Login-Nutzer, Erhebung April 2026, Fehlermarge ±0,9 Prozentpunkte.
68 % der Organisationen setzen Passkeys für die Mitarbeiterauthentifizierung ein, pilotieren oder rollen sie aus. Grundgesamtheit: 1.400 Entscheidungsträger in Organisationen ab 500 Mitarbeitenden, dieselben zehn Länder, April 2026, Fehlermarge ±2,6 Prozentpunkte.

Zur Geschwindigkeit existieren zwei getrennte Belege von Microsoft, die man nicht vermischen darf:

Laut Microsoft-Entra-ID-Dokumentation registrieren 99 % der Nutzer synchronisierte Passkeys erfolgreich. Microsoft weist die Geschwindigkeit dort mit zwei eigenen Telemetrie-Kennzahlen aus, die nicht auf einen einheitlichen Faktor zusammengerechnet werden sollten: eine rund 14-mal schnellere Anmeldung als mit Passwort plus klassischem MFA einerseits und eine durchschnittliche Anmeldedauer von 3 Sekunden gegenüber 69 Sekunden andererseits. Zusätzlich nennt Microsoft eine dreimal erfolgreichere Anmeldung (95 % gegenüber 30 %). Wichtig: Diese Zahlen stammen aus interner Telemetrie von „hunderten Millionen" Microsoft-Endkundenkonten, nicht aus Enterprise-Entra-ID allgemein und nicht branchenübergreifend.
Davon zu unterscheiden ist eine zweite Zahl, die das britische NCSC zitiert: Passkey-Anmeldungen dauerten „durchschnittlich 8 Sekunden gegenüber 69 Sekunden mit Passwort und zweitem Faktor". Quelle laut NCSC ist der Microsoft Security Blog vom Dezember 2024, also eine andere Erhebung als die Entra-Telemetrie.

Case-Study-Werte einzelner Unternehmen

Die FIDO Alliance sammelt auf ihrer Passkey-Seite eine Reihe von Einzelfallwerten. Jede Zahl stammt von einem anderen Unternehmen mit eigener Methodik, es sind also keine repräsentativen Gesamtstatistiken:

6-fach schnellere Anmeldung (Amazon).
4-mal höhere Erfolgsquote gegenüber Passwörtern (Google).
50 % geringere Login-Abbruchrate (Air New Zealand).
98 % weniger Mobile-Account-Übernahmen (CVS Health).
70 % höhere Anmelde-Konversion (Dashlane).

Diese Werte belegen den Trend, taugen aber nur mit Nennung von Firma und Kontext, nicht als allgemeingültige Kennzahlen.

Die Grenzen von Passkeys: der ehrliche Teil

Fast alle Erklärartikel enden beim Loblied. Das ist unredlich. Das britische NCSC hat in seinem Beitrag „Passkeys: they're not perfect but they're getting better" (15. Januar 2025) die realen Schwächen benannt. Wer Passkeys einführt, sollte sie kennen.

Account-Recovery wird zur eigentlichen Schwachstelle

Je stärker die eigentliche Authentifizierung wird, desto mehr verlagern Angreifer ihren Fokus auf die Wiederherstellungsprozesse. Wenn der Login praktisch unangreifbar ist, wird der „Passwort vergessen"- beziehungsweise „Gerät verloren"-Pfad zum lohnendsten Ziel für Phishing und Social Engineering. Diese Backend-Systeme müssen laut NCSC gehärtet werden, sonst ist der gesamte Sicherheitsgewinn dahin. Ein Passkey ist nur so stark wie sein schwächster Recovery-Weg.

Geräteverlust und fehlende Backups

Bei device-bound Passkeys stellt sich die Frage: Was passiert, wenn das einzige Gerät kaputtgeht oder verloren geht? Die Wiederherstellung hängt davon ab, dass Nutzer vorab Backups im Credential-Manager eingerichtet haben, ein vorbereitender Schritt, den laut NCSC viele schlicht nicht erledigen. Ohne zweites Gerät oder synchronisierten Passkey droht die dauerhafte Aussperrung.

Ökosystem-Lock-in und Portabilität

Synchronisierte Passkeys leben bislang im Ökosystem ihres Anbieters. Ein in der iCloud Keychain erzeugter Passkey lässt sich nicht ohne Weiteres zu Bitwarden oder dem Google Password Manager mitnehmen. Das NCSC nennt die Übertragung zwischen Anbietern „derzeit schwierig", was Nutzer faktisch einsperrt. Dieses Problem wird aktiv adressiert (siehe nächster Abschnitt), ist aber noch nicht flächendeckend gelöst.

Uneinheitliche Terminologie und unklarer MFA-Status

Verschiedene Plattformen benennen denselben Vorgang unterschiedlich, was Nutzer verwirrt und abschreckt. Gravierender für Unternehmen: Es besteht kein Konsens darüber, ob jeder Passkey-Typ als vollwertige Multi-Faktor-Authentifizierung zählt. Gerade synchronisierte, potenziell teilbare Passkeys werfen für regulierte Bereiche (Banking, Vollmachten) die Frage auf, ob sie ausreichend sicher sind. Das erzeugt regulatorische Unsicherheit.

Zugänglichkeit und geteilte Geräte

Passkeys setzen exklusiven Gerätezugriff und biometrische Fähigkeiten voraus. Gemeinsam genutzte Haushaltsgeräte, öffentliche Bibliothekscomputer oder Nutzer mit biometrischen Einschränkungen bleiben unterversorgt. Auch Multi-Domain-Setups (etwa example.co.uk und example.com) erfordern jeweils eigene Passkeys, was die Implementierung für Diensteanbieter verkompliziert.

Trotz dieser Punkte ist die NCSC-Empfehlung eindeutig: Konsumenten sollten Passkeys jetzt schon nutzen, weil sie „vor den weitverbreitetsten Angriffen schützen". Die Grenzen sind Gründe zur Sorgfalt beim Rollout, kein Grund zum Abwarten.

Passkey-Portabilität: CXP und CXF

Das Lock-in-Problem hat einen Namen und eine Lösung in Arbeit. Weil Passkeys auf kryptografischen Schlüsselpaaren beruhen, gab es lange kein standardisiertes Export- und Importformat, anders als bei Passwörtern, die sich (unsicher, aber immerhin) als CSV exportieren lassen. Die FIDO Alliance entwickelt dafür zwei ergänzende Spezifikationen:

CXF (Credential Exchange Format): ein JSON-basiertes Datenformat für Credentials mit vier Typen (public-key-credential, password, totp, note), erweiterbar für künftige Typen. Es ermöglicht auch lokale, geräteinterne Übertragungen. CXF wurde am 13. März 2025 als Review Draft veröffentlicht.
CXP (Credential Exchange Protocol): die sichere Transportschicht mittels Hybrid Public Key Encryption (HPKE), Ende-zu-Ende-verschlüsselt für die anbieterübergreifende Übertragung. Ziel ist der Status eines formalen Standards Anfang 2026.

Getragen wird die Initiative von Apple, Google, Microsoft, 1Password, Bitwarden und Dashlane. Apple hat den geräteinternen Credential-Transfer auf CXF-Basis bereits mit iOS und macOS 26 ausgeliefert. Wichtig zur Abgrenzung: CXP/CXF lösen das anbieterübergreifende Wechselproblem (etwa Apple zu Bitwarden), nicht die Synchronisierung innerhalb eines Ökosystems, das ist das ältere Synced-Passkey-Konzept.

Passkeys einführen: Praxis für Nutzer und Unternehmen

Für Privatnutzer

Der Einstieg ist niedrigschwellig, weil die großen Plattformen Passkeys bereits integriert haben:

Prüfen Sie, welche Dienste Passkeys anbieten. Google, Apple, Microsoft, Amazon, PayPal und viele weitere unterstützen sie. In den Sicherheitseinstellungen des jeweiligen Kontos finden Sie meist die Option „Passkey erstellen".
Nutzen Sie Ihren vorhandenen Passwortmanager oder die Plattform-Keychain. Apple iCloud Keychain und Google Password Manager synchronisieren Passkeys automatisch über Ihre Geräte, sodass ein Geräteverlust nicht zur Aussperrung führt.
Richten Sie einen zweiten Weg ein. Registrieren Sie nach Möglichkeit einen Passkey auf mehr als einem Gerät oder ergänzen Sie einen Hardware-Sicherheitsschlüssel als Backup. Das entschärft genau die Recovery-Schwäche, die das NCSC beschreibt.
Behalten Sie das Passwort vorerst als Rückfallebene, bis Sie sicher sind, dass Ihr Passkey-Setup zuverlässig funktioniert.

Für Unternehmen

Der Enterprise-Rollout ist anspruchsvoller und sollte gestaffelt sowie eingebettet in das bestehende Identity- und Access-Management erfolgen. Bewährte Leitplanken:

Passkeys parallel anbieten, nicht sofort erzwingen. Google, Microsoft und die IPG Group empfehlen übereinstimmend, bestehende Methoden (Passwort, klassisches MFA) während der Übergangsphase weiterzuführen, wegen unvollständiger Plattformunterstützung und Nutzer-Bereitschaft.
Authentikator-Typ an das Schutzbedürfnis koppeln. Microsoft empfiehlt für stark regulierte Bereiche oder privilegierte Nutzer device-bound FIDO2-Sicherheitsschlüssel, die (anders als synchronisierte Passkeys) Attestation unterstützen. Für die breite Belegschaft sind synchronisierte Passkeys die kostengünstigere, bequemere Wahl.
Attestation gezielt einsetzen. In Microsoft Entra ID lässt sich Attestation auf Passkey-Profil-Ebene erzwingen. Ist sie aktiv, sind nur zertifizierte, device-bound Passkeys zulässig, sinnvoll für Hochsicherheitskonten, aber eben nicht mit Cloud-Passkeys kombinierbar.
Recovery-Prozesse härten. Da Angreifer bei starker Authentifizierung auf die Wiederherstellung ausweichen (NCSC), gehört das Recovery-Backend ganz oben auf die Prioritätenliste.
In den Compliance-Rahmen einordnen. Passkeys unterstützen phishing-resistente Authentifizierung, wie sie unter anderem im Kontext von NIS2, DORA und TISAX gefordert wird, und lassen sich gut in eine Zero-Trust-Architektur und das bestehende Identity- und Access-Management einbetten.

Passkeys sind eine besonders starke Form der Multi-Faktor-Authentifizierung und der wirksamste bekannte Schutz gegen Phishing-Angriffe, weil sie das gemeinsame Geheimnis, das Phishing überhaupt erst ausnutzbar macht, vollständig eliminieren.

Häufige Fragen

Sind Passkeys wirklich sicherer als Passwörter?

Ja, und der Grund ist strukturell. Bei einem Passkey verlässt der private Schlüssel die sichere Hardware des Geräts nie, und jedes Credential ist fest an eine Domain gebunden. Ein gemeinsames Geheimnis, das abgegriffen werden könnte, existiert nicht. Dadurch laufen Phishing, Credential Stuffing, Replay-Angriffe und geleakte Datenbanken praktisch ins Leere. Selbst bei einem erfolgreichen Serverangriff erbeutet ein Angreifer nur öffentliche Schlüssel, mit denen sich niemand anmelden kann.

Was passiert mit meinen Passkeys, wenn ich mein Handy verliere?

Das hängt vom Passkey-Typ ab. Synchronisierte Passkeys (etwa in der Apple iCloud Keychain oder im Google Password Manager) werden automatisch über Ihre Geräte hinweg gesichert, sodass ein Geräteverlust nicht zur Aussperrung führt. Bei device-bound Passkeys müssen Sie vorab ein Backup eingerichtet haben, indem Sie einen Passkey auf einem zweiten Gerät oder einen Hardware-Sicherheitsschlüssel registrieren. Fehlt dieser vorbereitende Schritt, droht die dauerhafte Aussperrung. Genau deshalb ist die Account-Wiederherstellung die eigentliche Schwachstelle, die Sie absichern sollten.

Sind Passkeys eine Form der Zwei-Faktor-Authentifizierung?

In der Praxis ja: Sobald die User Verification per Biometrie oder PIN aktiv ist, wird der Passkey laut BSI faktisch zu einem Zwei-Faktor-Vorgang, nämlich Besitz des Geräts plus Wissen (PIN) oder Inhärenz (Biometrie). Allerdings gibt es noch keinen branchenweiten Konsens, ob jeder Passkey-Typ als vollwertige Multi-Faktor-Authentifizierung zählt. Besonders bei synchronisierten, potenziell teilbaren Passkeys ist der MFA-Status in regulierten Bereichen noch nicht abschließend geklärt.

Kann ich Passkeys zwischen Apple, Google und Microsoft synchronisieren?

Derzeit nicht ohne Weiteres. Synchronisierte Passkeys leben bislang im Ökosystem ihres Anbieters, ein in der iCloud Keychain erzeugter Passkey lässt sich also nicht einfach zu Google oder Bitwarden mitnehmen. Das NCSC nennt die Übertragung zwischen Anbietern „derzeit schwierig". Die FIDO Alliance arbeitet mit den Standards CXP und CXF an genau diesem anbieterübergreifenden Wechsel, und Apple hat den geräteinternen Transfer auf CXF-Basis bereits mit iOS und macOS 26 ausgeliefert.

Was ist der Unterschied zwischen einem Passkey und FIDO2?

FIDO2 ist der technische Standard, genauer das Standardpaket der FIDO Alliance aus WebAuthn (W3C) und CTAP2. Ein Passkey ist die nutzerfreundliche Bezeichnung für ein damit erzeugtes Anmelde-Credential, technisch ein discoverable credential. Kurz gesagt: FIDO2 ist der Standard, der Passkey ist seine Implementierung. Passkey ist der UX-Begriff, WebAuthn und CTAP2 sind die Spezifikationen darunter.

Fazit

Passkeys sind kein Marketing-Versprechen, sondern eine ausgereifte, standardisierte Technologie, die auf FIDO2 (also WebAuthn und CTAP2) aufsetzt. Ihr entscheidender Vorteil ist strukturell: Weil der private Schlüssel das Gerät nie verlässt und jedes Credential an genau eine Domain gebunden ist, laufen Phishing, Credential Stuffing und Datenbank-Leaks ins Leere. Die belegten Zahlen von FIDO Alliance und Microsoft zeigen zugleich schnellere und erfolgreichere Anmeldungen.

Gleichzeitig sind Passkeys nicht perfekt. Die ehrlichen Schwachstellen liegen nicht in der Kryptografie, sondern drumherum: in der Account-Wiederherstellung, im Ökosystem-Lock-in (an dem CXP und CXF gerade arbeiten) und in der uneinheitlichen Terminologie. Für Privatnutzer lautet die Empfehlung von BSI und NCSC dennoch klar: einsetzen, aber mit Backup-Weg. Für Unternehmen gilt: gestaffelt ausrollen, den Authentikator-Typ am Risiko ausrichten und vor allem die Recovery-Prozesse mit derselben Sorgfalt härten wie den Login selbst. Wer das beherzigt, ersetzt das schwächste Glied der IT-Sicherheit, das Passwort, durch eines der stärksten.