IT-Sicherheit · Passkeys
Passkeys: Anmelden, ohne ein Geheimnis preiszugeben.
Ein Passkey ist kein besseres Passwort, sondern ein Schlüsselpaar: Der private Teil bleibt im Gerät, der Dienst kennt nur den öffentlichen. Was genau dabei passiert, warum gefälschte Seiten ins Leere laufen und was synchronisierte Passkeys für Unternehmen bedeuten – Schritt für Schritt.
Die Kernidee
Bei einem Passwort beweisen Sie, dass Sie ein Geheimnis kennen – indem Sie es verraten. Bei einem Passkey beweist Ihr Gerät, dass es einen Schlüssel besitzt, ohne ihn je herauszugeben.
Daraus folgt fast alles Weitere: Ein Datenleck beim Dienst erbeutet nur öffentliche Schlüssel. Eine gefälschte Seite bekommt nichts, was sie weiterverwenden könnte. Und Ihr Fingerabdruck bleibt, wo er hingehört – auf Ihrem Gerät.
Passkey Experience
Was bei einem Passkey wirklich passiert
Scrollen Sie durch Registrierung und Anmeldung. Die Bühne zeigt, wer welche Daten hält und was über die Leitung geht – Schritt für Schritt, berechnet aus einem vereinfachten Modell des Standards WebAuthn. Achten Sie auf zwei Dinge: Der private Schlüssel und Ihr Fingerabdruck tauchen nie in einer Nachricht auf. Und die Adresse der Seite steht in allem, was unterschrieben wird.
- Registrierung
- Anmeldung
- Konto-Kennung
- Biometrie / PINbleibt im Authenticator
- Privater Schlüsselbleibt im Authenticator
- Öffentlicher Schlüssel
- Credential-ID
- Authenticator-Daten
- Signatur
- Konto-Kennung
- Client-Daten (Origin + Challenge)
- Öffentlicher Schlüssel
- Credential-ID
- Authenticator-Daten
- Signatur
Angemeldet – Challenge verbraucht
Prüfungen
- Signatur passt zum gespeicherten öffentlichen Schlüssel
- Challenge ist die eben ausgegebene
- Origin ist https://beispiel-shop.de
- Hash der RP ID und Flags (anwesend, verifiziert) stimmen
Registrierung · Einladung
Der Dienst bittet um einen Passkey
Sie sind bei beispiel-shop.de angemeldet und wählen „Passkey erstellen“. Der Dienst schickt dem Browser Optionen: seine Domain als RP ID, eine Kennung Ihres Kontos und eine Challenge – einen Zufallswert, der nur für diesen einen Vorgang gilt.
Registrierung · Herkunft
Der Browser prüft, wer fragt
Bevor irgendetwas erzeugt wird, prüft der Browser, ob die RP ID zur tatsächlich aufgerufenen Seite passt. Dann hält er in den Client-Daten fest, welche Adresse (Origin) im Adressfeld steht und welche Challenge kam – das kann die Webseite selbst nicht verfälschen. An den Authenticator geht davon nur ein Hashwert.
Registrierung · Lokale Freigabe
Sie bestätigen – am Gerät, nicht im Netz
Das Gerät fragt nach Fingerabdruck, Gesicht oder Geräte-PIN. Geprüft wird ausschließlich lokal: Das biometrische Merkmal und die PIN verlassen das Gerät nicht, der Dienst erfährt nur, dass Sie anwesend waren und sich verifiziert haben.
Registrierung · Schlüsselpaar
Ein neues Schlüsselpaar – nur für diesen Dienst
Der Authenticator erzeugt ein Schlüsselpaar, das ausschließlich zu beispiel-shop.de gehört. Der private Schlüssel bleibt beim Authenticator. Dazu kommen eine Credential-ID und die Authenticator-Daten mit dem Hash der RP ID und Flags, etwa „Benutzer verifiziert“ und „kann gesichert werden“.
Registrierung · Übergabe
Nur der öffentliche Teil geht an den Dienst
Über den Browser erhält der Dienst den öffentlichen Schlüssel, die Credential-ID, die Authenticator-Daten und die Client-Daten. Nichts davon ist geheim: Mit einem öffentlichen Schlüssel kann man Signaturen prüfen, aber keine erzeugen.
Registrierung · Prüfen und speichern
Der Dienst prüft und merkt sich den öffentlichen Schlüssel
Der Dienst vergleicht die Challenge mit der ausgegebenen, prüft Adresse und RP-ID-Hash und speichert öffentlichen Schlüssel und Credential-ID bei Ihrem Konto. Die Challenge ist damit verbraucht. Ein Passwort gibt es in diesem Ablauf nicht.
Anmeldung · Neue Anmeldung
Tage später: eine frische Challenge
Sie möchten sich anmelden. Der Dienst erzeugt eine neue Challenge und schickt sie mit seiner RP ID an den Browser. Jede Anmeldung bekommt einen eigenen Zufallswert – eine mitgeschnittene Antwort von gestern ist heute wertlos.
Anmeldung · Herkunft
Der Browser schreibt die echte Adresse hinein
Wieder erstellt der Browser Client-Daten mit der tatsächlich aufgerufenen Adresse und der Challenge. Auf einer nachgemachten Seite stünde hier deren Adresse – und der Browser würde die RP ID beispiel-shop.de gar nicht erst zulassen.
Anmeldung · Freigabe und Signatur
Ein Fingerabdruck – und das Gerät unterschreibt
Der Authenticator findet den Passkey für beispiel-shop.de und bittet um Ihre Freigabe. Danach signiert er mit dem privaten Schlüssel die Authenticator-Daten zusammen mit dem Hash der Client-Daten. Die Signatur gilt damit genau für diese Challenge und diese Adresse.
Anmeldung · Antwort
Zurück geht nur die Unterschrift
Signatur, Credential-ID und Authenticator-Daten gehen über den Browser an den Dienst, zusammen mit den Client-Daten. Der private Schlüssel bleibt, wo er ist.
Anmeldung · Verifikation
Der Dienst prüft – mit dem öffentlichen Schlüssel
Der Dienst prüft die Signatur mit dem gespeicherten öffentlichen Schlüssel, vergleicht Challenge und Adresse und wertet die Flags aus. Passt alles, sind Sie angemeldet. Hätte jemand die Antwort auf einer fremden Seite eingesammelt, stünde dort die falsche Adresse – die Prüfung schlägt fehl.
Domain-Probe
Auf welcher Seite wird der Passkey angeboten?
Wählen Sie eine Adresse. Das Ergebnis folgt allein aus der Regel des Standards: Die RP ID muss der Domain der Seite entsprechen oder eine übergeordnete Domain davon sein. Wie echt die Seite aussieht, spielt keine Rolle.
Registriert für beispiel-shop.de · Aufgerufene Seite beispiel-shop.de
Passkey wird angeboten
Die Seite gehört genau zur registrierten Domain beispiel-shop.de.
Der Normalfall: Passkey auswählen, Fingerabdruck – angemeldet.
Ablauf und Domain-Probe als Text
Registrierung
- Der Dienst bittet um einen Passkey. Sie sind bei beispiel-shop.de angemeldet und wählen „Passkey erstellen“. Der Dienst schickt dem Browser Optionen: seine Domain als RP ID, eine Kennung Ihres Kontos und eine Challenge – einen Zufallswert, der nur für diesen einen Vorgang gilt. – Nachricht von Dienst an Browser: Konto-Kennung (User Handle), Challenge (frischer Zufallswert).
- Der Browser prüft, wer fragt. Bevor irgendetwas erzeugt wird, prüft der Browser, ob die RP ID zur tatsächlich aufgerufenen Seite passt. Dann hält er in den Client-Daten fest, welche Adresse (Origin) im Adressfeld steht und welche Challenge kam – das kann die Webseite selbst nicht verfälschen. An den Authenticator geht davon nur ein Hashwert. – Nachricht von Browser an Authenticator: Konto-Kennung (User Handle), Client-Daten: Adresse der Seite und Challenge.
- Sie bestätigen – am Gerät, nicht im Netz. Das Gerät fragt nach Fingerabdruck, Gesicht oder Geräte-PIN. Geprüft wird ausschließlich lokal: Das biometrische Merkmal und die PIN verlassen das Gerät nicht, der Dienst erfährt nur, dass Sie anwesend waren und sich verifiziert haben. – Lokal bei Authenticator: Fingerabdruck oder PIN lokal geprüft.
- Ein neues Schlüsselpaar – nur für diesen Dienst. Der Authenticator erzeugt ein Schlüsselpaar, das ausschließlich zu beispiel-shop.de gehört. Der private Schlüssel bleibt beim Authenticator. Dazu kommen eine Credential-ID und die Authenticator-Daten mit dem Hash der RP ID und Flags, etwa „Benutzer verifiziert“ und „kann gesichert werden“. – Lokal bei Authenticator: Schlüsselpaar für beispiel-shop.de erzeugt.
- Nur der öffentliche Teil geht an den Dienst. Über den Browser erhält der Dienst den öffentlichen Schlüssel, die Credential-ID, die Authenticator-Daten und die Client-Daten. Nichts davon ist geheim: Mit einem öffentlichen Schlüssel kann man Signaturen prüfen, aber keine erzeugen. – Nachricht von Authenticator über Browser an Dienst: Öffentlicher Schlüssel, Credential-ID, Authenticator-Daten (Hash der RP ID, Flags, Zähler), Client-Daten: Adresse der Seite und Challenge.
- Der Dienst prüft und merkt sich den öffentlichen Schlüssel. Der Dienst vergleicht die Challenge mit der ausgegebenen, prüft Adresse und RP-ID-Hash und speichert öffentlichen Schlüssel und Credential-ID bei Ihrem Konto. Die Challenge ist damit verbraucht. Ein Passwort gibt es in diesem Ablauf nicht. – Lokal bei Dienst: Öffentlicher Schlüssel beim Konto gespeichert.
Anmeldung
- Tage später: eine frische Challenge. Sie möchten sich anmelden. Der Dienst erzeugt eine neue Challenge und schickt sie mit seiner RP ID an den Browser. Jede Anmeldung bekommt einen eigenen Zufallswert – eine mitgeschnittene Antwort von gestern ist heute wertlos. – Nachricht von Dienst an Browser: Challenge (frischer Zufallswert).
- Der Browser schreibt die echte Adresse hinein. Wieder erstellt der Browser Client-Daten mit der tatsächlich aufgerufenen Adresse und der Challenge. Auf einer nachgemachten Seite stünde hier deren Adresse – und der Browser würde die RP ID beispiel-shop.de gar nicht erst zulassen. – Nachricht von Browser an Authenticator: Client-Daten: Adresse der Seite und Challenge.
- Ein Fingerabdruck – und das Gerät unterschreibt. Der Authenticator findet den Passkey für beispiel-shop.de und bittet um Ihre Freigabe. Danach signiert er mit dem privaten Schlüssel die Authenticator-Daten zusammen mit dem Hash der Client-Daten. Die Signatur gilt damit genau für diese Challenge und diese Adresse. – Lokal bei Authenticator: Freigabe lokal, Signatur mit privatem Schlüssel.
- Zurück geht nur die Unterschrift. Signatur, Credential-ID und Authenticator-Daten gehen über den Browser an den Dienst, zusammen mit den Client-Daten. Der private Schlüssel bleibt, wo er ist. – Nachricht von Authenticator über Browser an Dienst: Signatur, Credential-ID, Authenticator-Daten (Hash der RP ID, Flags, Zähler), Client-Daten: Adresse der Seite und Challenge.
- Der Dienst prüft – mit dem öffentlichen Schlüssel. Der Dienst prüft die Signatur mit dem gespeicherten öffentlichen Schlüssel, vergleicht Challenge und Adresse und wertet die Flags aus. Passt alles, sind Sie angemeldet. Hätte jemand die Antwort auf einer fremden Seite eingesammelt, stünde dort die falsche Adresse – die Prüfung schlägt fehl. – Lokal bei Dienst: Angemeldet – Challenge verbraucht.
Diese Daten verlassen ihr Gerät nie: Fingerabdruck, Gesicht oder Geräte-PIN (bleibt bei Authenticator); Privater Schlüssel (bleibt bei Authenticator).
- Die echte Seite (https://beispiel-shop.de): Passkey wird angeboten.
- Kundenkonto des Shops (https://konto.beispiel-shop.de): Passkey wird angeboten.
- Täuschend ähnliche Domain (https://beispiel-shop-login.de): Kein Passkey angeboten.
- Domain als Tarnung im Namen (https://beispiel-shop.de.kundenservice-hilfe.com): Kein Passkey angeboten.
- Tippfehler-Domain (https://beispeil-shop.de): Kein Passkey angeboten.
Vereinfachtes Lernmodell nach W3C Web Authentication (Level 3) und FIDO-Passkeys: Attestierung, Erweiterungen, Zähler und die Prüfung über die Public-Suffix-Liste sind nicht dargestellt; beispiel-shop.de ist ein fiktiver Dienst. „Bleibt im Authenticator“ heißt: Der private Schlüssel geht nie an Browser oder Dienst. Bei synchronisierten Passkeys überträgt der Passkey-Anbieter ihn verschlüsselt auf Ihre weiteren Geräte – dazu weiter unten mehr.
Zwei Arten, ein Standard
Synchronisiert oder gerätegebunden?
Beide Varianten nutzen dasselbe Verfahren und sind gleich phishingresistent. Sie unterscheiden sich darin, wo der private Schlüssel liegen darf – und damit bei Verlust, Wiederherstellung und Kontrolle.
Synchronisierter Passkey
Der Passkey-Anbieter (z. B. iCloud-Schlüsselbund, Google Passwortmanager oder ein Passwortmanager) überträgt den privaten Schlüssel verschlüsselt auf weitere Geräte desselben Kontos. Ein neues Smartphone hat die Passkeys sofort wieder.
- Stärke: bequem, kaum Verlustrisiko, gut für die breite Einführung
- Abwägung: Die Sicherheit hängt am Anbieterkonto und dessen Wiederherstellung; Kopien können in einem privaten Konto liegen
- NIST SP 800-63B-4: synchronisierbare Authenticatoren sind bis Vertrauensstufe AAL2 vorgesehen
Gerätegebundener Passkey
Der private Schlüssel verlässt das Gerät nie, auch nicht verschlüsselt – etwa auf einem FIDO2-Sicherheitsschlüssel, in Windows Hello for Business oder in Microsoft Authenticator.
- Stärke: klare Kontrolle, eindeutig einem Gerät zugeordnet
- Abwägung: Gerät verloren heißt Passkey verloren – ein zweiter Schlüssel oder ein geregelter Wiederherstellungsweg gehört dazu
- NIST SP 800-63B-4: für AAL3 sind nicht exportierbare Schlüssel erforderlich
Woran ein Dienst den Unterschied erkennt
Der Authenticator meldet in jeder Antwort zwei Flags: ob der Passkey gesichert werden kann (Backup Eligibility) und ob er gerade gesichert ist (Backup State). Ein Dienst kann darauf reagieren – etwa, indem er für synchronisierte Passkeys einen zusätzlichen Wiederherstellungsweg anbietet.
Credential Sync Explorer
Wohin ein Passkey synchronisiert wird – und wohin nicht
Ein Passkey wohnt bei einem Passkey-Anbieter: im Betriebssystem, im Browserkonto oder in einem Passwortmanager. Wählen Sie ein Gerät oder einen Anbieter, um zu sehen, woher die Passkeys kommen. Die Abläufe zeigen dokumentierte Wege: Synchronisierung im selben Anbieterkonto, Anmeldung an einem anderen Gerät per QR-Code und den Sicherheitsschlüssel, der nichts synchronisiert. Auch Passwortmanager können Passkey-Anbieter sein; sie synchronisieren dann innerhalb ihres eigenen Kontos – welche Plattformen sie unterstützen, steht in ihrer Dokumentation.
Passkey-Anbieter (Konto in der Cloud) · Apple-Account
iCloud-Schlüsselbund
Speichert Passkeys Ende-zu-Ende-verschlüsselt und synchronisiert sie auf die Geräte, die mit demselben Apple-Account angemeldet sind und den Schlüsselbund aktiviert haben.
- Wird gebraucht von
Illustrative Übersicht, vereinfacht: Sie zeigt dokumentierte Wege, keine vollständige Liste von Geräten, Anbietern und Versionen. Ob ein Anbieter Passkeys mit anderen Anbietern austauschen kann und welche Betriebssystemversion was unterstützt, ändert sich laufend – maßgeblich ist die jeweilige Herstellerdokumentation. Apple, iCloud, iPhone und Mac sind Marken der Apple Inc.; Google und Android sind Marken der Google LLC; Windows und Windows Hello sind Marken der Microsoft Corporation.
Beispielarchitektur als Text
- iCloud-Schlüsselbund (Passkey-Anbieter (Konto in der Cloud)) – Speichert Passkeys Ende-zu-Ende-verschlüsselt und synchronisiert sie auf die Geräte, die mit demselben Apple-Account angemeldet sind und den Schlüsselbund aktiviert haben. Wird gebraucht von: iPhone, Mac.
- Google Passwortmanager (Passkey-Anbieter (Konto in der Cloud)) – Verschlüsselt Passkeys Ende-zu-Ende und stellt sie auf den Geräten bereit, die mit demselben Google-Konto angemeldet sind. Wird gebraucht von: Android-Smartphone.
- iPhone (Apple-Geräte) – Erstellt und nutzt Passkeys mit Face ID oder Touch ID; gespeichert im iCloud-Schlüsselbund. Braucht: iCloud-Schlüsselbund.
- Mac (Apple-Geräte) – Ein auf dem iPhone erstellter Passkey steht hier ohne erneute Registrierung zur Verfügung – über den iCloud-Schlüsselbund. Braucht: iCloud-Schlüsselbund.
- Android-Smartphone (Android) – Nutzt Passkeys aus dem Google Passwortmanager, der sie Ende-zu-Ende-verschlüsselt im Google-Konto speichert. Kann einen Computer in der Nähe per QR-Code anmelden. Braucht: Google Passwortmanager.
- Windows-PC (Windows-PC) – Speichert Passkeys lokal mit Windows Hello (Gesicht, Fingerabdruck oder PIN). Für Passkeys auf einem Smartphone zeigt Windows einen QR-Code; Bluetooth und Internet müssen auf beiden Geräten aktiv sein.
- Sicherheitsschlüssel (Dienst und Hardware) – Der Passkey entsteht im Schlüssel und lässt sich nicht exportieren oder synchronisieren. Er funktioniert per USB, NFC oder Bluetooth an jedem passenden Gerät.
- Online-Dienst (Dienst und Hardware) – Der Dienst speichert je Passkey nur den öffentlichen Schlüssel. An welchem Gerät oder über welchen Anbieter angemeldet wird, ist für ihn zweitrangig – er prüft die Signatur. Über das Flag „gesichert“ (Backup State) erfährt er, ob ein Passkey synchronisiert wird.
Typische Abläufe
- Passkey erscheint auf dem Mac: iPhone → iCloud-Schlüsselbund → Mac – Auf dem iPhone erstellt, über den iCloud-Schlüsselbund verschlüsselt synchronisiert, auf dem Mac sofort nutzbar. Der Dienst merkt davon nichts – es ist derselbe Passkey.
- Fremder PC: Anmeldung per QR-Code: Android-Smartphone → Windows-PC → Online-Dienst – Windows zeigt einen QR-Code, das Android-Smartphone scannt ihn, Bluetooth bestätigt, dass beide Geräte nah beieinander sind; beide brauchen eine Internetverbindung. Das Smartphone signiert, der Passkey bleibt auf dem Smartphone. Das Verfahren heißt bei der FIDO Alliance „Hybrid“-Transport.
- Sicherheitsschlüssel: Sicherheitsschlüssel → Online-Dienst – Der Schlüssel signiert direkt; es gibt keine Kopie in einer Cloud. Verloren heißt: weg. Deshalb registriert man einen zweiten Schlüssel oder hält einen anderen Wiederherstellungsweg bereit.
Praxisfälle im Unternehmen
Was passiert, wenn …
Vier Situationen, die in jeder Einführung vorkommen. Wählen Sie einen Fall: Die Schritte zeigen, wer handelt und wo der Passkey dabei liegt.
Das alte Smartphone wird ersetzt, die Passkeys waren synchronisiert.
- AnlassNeues Gerät einrichten, mit demselben Anbieterkonto anmelden.
- AnbieterkontoDer Anbieter stellt die Passkeys verschlüsselt auf dem neuen Gerät bereit.
- Neuen Passkey registrieren
- Zweiter Weg zur Anmeldung
- IT stellt Zugang her
- Passkey beim Dienst entfernen
- Ergebnis prüfenAnmeldung bei einem Dienst testen; das alte Gerät zurücksetzen.
Kein neuer Passkey nötig – sofern der Zugang zum Anbieterkonto gesichert ist.
Alle Szenarien als Text
Neues Smartphone – Das alte Smartphone wird ersetzt, die Passkeys waren synchronisiert.
- Anlass: Neues Gerät einrichten, mit demselben Anbieterkonto anmelden.
- Anbieterkonto: Der Anbieter stellt die Passkeys verschlüsselt auf dem neuen Gerät bereit.
- Ergebnis prüfen: Anmeldung bei einem Dienst testen; das alte Gerät zurücksetzen.
Kein neuer Passkey nötig – sofern der Zugang zum Anbieterkonto gesichert ist.
Sicherheitsschlüssel verloren – Eine Mitarbeiterin hat ihren einzigen FIDO2-Schlüssel verloren.
- Anlass: Verlust sofort melden.
- Passkey beim Dienst entfernen: Den verlorenen Schlüssel beim Konto entfernen – ein Finder bräuchte ohnehin die PIN.
- IT stellt Zugang her: Identität prüfen, zeitlich begrenzten Zugang ausstellen (in Entra ID z. B. einen befristeten Zugriffspass).
- Neuen Passkey registrieren: Neuen Schlüssel registrieren – besser gleich zwei.
- Ergebnis prüfen: Anmeldung testen, Vorgang dokumentieren.
Wieder arbeitsfähig, ohne auf ein schwaches Verfahren zurückzufallen.
Anmeldung an einem fremden Rechner – Im Besprechungsraum steht ein Gerät, auf dem kein Passkey liegt.
- Anlass: Am Rechner „Passkey von einem anderen Gerät“ wählen; es erscheint ein QR-Code.
- Zweiter Weg zur Anmeldung: Smartphone scannt, Bluetooth bestätigt die Nähe, Freigabe am Smartphone.
- Ergebnis prüfen: Nach der Sitzung abmelden; auf dem fremden Rechner bleibt kein Passkey zurück.
Angemeldet, ohne Passkey oder Passwort auf dem fremden Gerät zu hinterlassen.
Austritt eines Mitarbeiters – Ein Mitarbeiter verlässt das Unternehmen; seine Passkeys liegen teils in einem privaten Anbieterkonto.
- Anlass: Austritt aus dem Personalprozess.
- Passkey beim Dienst entfernen: Konto sperren und alle registrierten Passkeys beim Dienst bzw. im Verzeichnis entfernen.
- Ergebnis prüfen: Prüfen, dass keine weitere Methode übrig ist; Sitzungen beenden.
Kopien im privaten Konto sind wertlos, weil der Dienst den öffentlichen Schlüssel nicht mehr kennt.
Typische Missverständnisse
Wird mein Fingerabdruck an den Dienst geschickt?
Nein. Fingerabdruck, Gesicht oder PIN entsperren nur den Passkey auf Ihrem Gerät. Der Dienst erfährt lediglich über ein Flag, dass eine Verifikation stattgefunden hat – nicht womit und schon gar nicht das Merkmal selbst.
Ein Passkey ist doch nur ein langes, gespeichertes Passwort?
Nein. Ein Passwort wird bei jeder Anmeldung übertragen und beim Dienst geprüft. Beim Passkey wird nichts Geheimes übertragen: Das Gerät signiert eine einmalige Challenge, der Dienst prüft die Signatur mit dem öffentlichen Schlüssel.
Mit Passkeys bin ich vor Phishing vollständig geschützt.
Die Anmeldung selbst ist phishingresistent. Aber: Bietet der Dienst zusätzlich Passwort, SMS-Code oder eine bequeme Kontowiederherstellung an, greifen Angreifer genau dort an. Und eine bereits angemeldete Sitzung schützt kein Anmeldeverfahren – gegen gestohlene Sitzungscookies helfen Gerätesicherheit und Richtlinien des Dienstes.
Ist das Smartphone weg, sind alle Passkeys weg.
Bei synchronisierten Passkeys nicht: Sie kommen über das Anbieterkonto auf ein neues Gerät. Bei gerätegebundenen Passkeys ja – deshalb gehört zu jeder Einführung ein zweiter Schlüssel oder ein geregelter Wiederherstellungsweg.
Synchronisierte Passkeys sind unsicher, weil sie in der Cloud liegen.
Apple und Google dokumentieren eine Ende-zu-Ende-Verschlüsselung; NIST lässt synchronisierbare Passkeys bis AAL2 zu, wenn der Zugang zum Anbieterkonto selbst mehrstufig geschützt ist. Die eigentliche Frage ist eine der Kontrolle: Wer kann das Anbieterkonto wiederherstellen, und darf ein Passkey für ein Firmenkonto in einem privaten Konto liegen? Das entscheidet man je Personengruppe.
Passkeys funktionieren nur im Apple- bzw. Google-Universum.
Der Standard ist herstellerübergreifend. Innerhalb eines Anbieterkontos wird synchronisiert; über Plattformgrenzen hinweg hilft die Anmeldung per QR-Code mit dem Smartphone oder ein Passwortmanager, der auf mehreren Betriebssystemen als Passkey-Anbieter läuft. Wie sich Browser- und zentrale Passwortmanager unterscheiden, zeigen die Seiten Browser-Passwortmanager und Passwortmanagement im Unternehmen.
Im Unternehmen
Worauf es bei der Einführung ankommt
Passkeys sind schnell erklärt und schnell registriert. Die eigentliche Arbeit steckt in den Entscheidungen drumherum.
Welche Dienste unterstützen Passkeys?
Microsoft Entra ID unterstützt laut Microsoft Learn synchronisierte Passkeys sowie gerätegebundene Passkeys auf FIDO2-Sicherheitsschlüsseln und in Microsoft Authenticator – in allen Editionen. Für weitere Anwendungen lohnt eine Bestandsaufnahme: Was meldet sich über Entra ID an, was hat eigene Konten?
Welche Passkeys sind erlaubt?
In Entra ID legen Passkey-Profile fest, welche Passkey-Arten und Modelle (AAGUID) zulässig sind und ob ein Nachweis (Attestierung) verlangt wird – synchronisierte Passkeys liefern keinen. Microsoft empfiehlt FIDO2-Sicherheitsschlüssel für stark regulierte Branchen und Personen mit erhöhten Rechten, Passkeys in Microsoft Authenticator als weitere Option für diese Gruppen und synchronisierte Passkeys für die meisten übrigen Nutzer. Für Administratorrollen empfiehlt Microsoft zusätzlich, phishingresistente MFA über den bedingten Zugriff zu verlangen.
Wie kommt der erste Passkey sicher zustande?
Die Registrierung ist der empfindlichste Moment: Wer sie mit einem Passwort absichert, erbt dessen Schwächen. Ein befristeter Zugriffspass (Temporary Access Pass) in Entra ID – zeitlich begrenzt, wahlweise nur einmal nutzbar – oder eine persönliche Übergabe schließt diese Lücke.
Was passiert bei Verlust?
Den Wiederherstellungsweg vorher festlegen, nicht im Notfall erfinden. Er darf nicht schwächer sein als der Passkey selbst – sonst wird er zum bevorzugten Angriffsweg. Das BSI bewertet eine einstufige Wiederherstellung als grundsätzlich kritisch.
Was müssen Mitarbeitende wissen?
Kurz und konkret: wo der Passkey liegt, was die Anmeldung per QR-Code ist, was bei Verlust zu tun ist – und dass die IT niemals nach einer PIN oder einem Code fragt.
Mögliches Vorgehen
Von der Bestandsaufnahme zum Regelbetrieb
Bestandsaufnahme
Konten, Anwendungen, Geräte, heutige Anmeldeverfahren.
Regeln festlegen
Erlaubte Passkey-Arten je Personengruppe, Wiederherstellung, Ausnahmen.
Pilot
Kleine Gruppe, echte Arbeitsabläufe, Rückmeldungen einsammeln.
Ausrollen
Registrierung begleitet, verständliche Anleitung, erreichbarer Support.
Nachsteuern
Schwächere Verfahren schrittweise abbauen, Ausnahmen regelmäßig prüfen.
Passkeys in Ihrem Unternehmen? Sprechen wir darüber.
Ob und wie eine Einführung zu Ihrer Umgebung passt, klären wir gern in einem ersten Gespräch – individuell und ohne Paketversprechen.