Passkeys tauchen inzwischen an immer mehr Stellen in Microsoft Entra ID auf. Gleichzeitig liest man Begriffe wie FIDO2, WebAuthn, AAGUID, Attestation, gerätegebundene Passkeys und synchronisierte Passkeys.
Wer nicht jeden Tag mit Identity Security arbeitet, kann dabei schnell den Eindruck bekommen, dass Passkeys komplizierter sind als Passwörter.
Eigentlich ist das Grundprinzip ziemlich einfach.
Ein Passwort ist ein Geheimnis, das Benutzer und Dienst kennen.
Ein Passkey funktioniert anders. Statt eines gemeinsamen Geheimnisses gibt es ein kryptografisches Schlüsselpaar, einen privaten Schlüssel und einen öffentlichen Schlüssel.
Der öffentliche Schlüssel liegt beim Dienst, beispielsweise bei Microsoft Entra ID.
Der private Schlüssel wird vom Authenticator beziehungsweise Passkey Anbieter geschützt.
Bei der Anmeldung wird der private Schlüssel nicht an Microsoft übertragen. Stattdessen beweist der Authenticator durch eine digitale Signatur, dass er über den passenden privaten Schlüssel verfügt.
Genau deshalb lohnt es sich, Passkeys einmal von Grund auf zu betrachten.
Was ist ein Passkey eigentlich?
Ein Passkey ist eine FIDO2 basierte Anmeldeinformation auf Basis asymmetrischer Kryptografie.
Bei der Registrierung entsteht ein Schlüsselpaar.
Der öffentliche Schlüssel wird beim Dienst hinterlegt.
Der private Schlüssel bleibt unter Kontrolle des Authenticators oder Passkey Anbieters.
Microsoft Entra unterstützt inzwischen sowohl gerätegebundene als auch synchronisierte Passkeys. Beide Varianten ermöglichen eine passwortlose und phishingresistente Anmeldung, unterscheiden sich aber deutlich darin, wie das Schlüsselmaterial gespeichert und verwaltet wird.
Das ist bereits der erste Punkt, bei dem eine häufig verwendete Vereinfachung ungenau wird.
Man liest oft, dass der private Schlüssel eines Passkeys das Gerät niemals verlässt.
Bei einem gerätegebundenen Passkey stimmt das.
Bei einem synchronisierten Passkey ist die Situation anders. Microsoft beschreibt hier, dass der private Schlüssel durch Hardware geschützt erzeugt und lokal verschlüsselt wird. Das verschlüsselte Schlüsselmaterial wird anschließend über den jeweiligen Cloud Passkey Anbieter synchronisiert und kann auf weiteren autorisierten Geräten verwendet werden. Beispiele sind Apples iCloud Schlüsselbund und der Google Password Manager.
Die bessere Formulierung lautet deshalb:
Bei einer Passkey Anmeldung wird kein gemeinsames Geheimnis an den Dienst übertragen. Wie und wo der private Schlüssel gespeichert wird, hängt vom verwendeten Passkey Typ und Anbieter ab.
Wie läuft eine Anmeldung mit einem Passkey ab?
Der Ablauf lässt sich auf wenige Schritte reduzieren.
1. Die Anmeldung beginnt
Der Benutzer möchte sich beispielsweise bei Microsoft Entra ID anmelden.
2. Microsoft erzeugt eine Challenge
Der Dienst erzeugt eine kryptografische Challenge.
Man kann sich das wie eine einmalige Aufgabe vorstellen, die nur für diesen konkreten Anmeldevorgang gedacht ist.
3. Der Browser spricht mit dem Authenticator
Der Browser beziehungsweise die Plattform sucht einen passenden Passkey.
Dieser kann beispielsweise auf einem FIDO2 Sicherheitsschlüssel, im Microsoft Authenticator, in einem lokalen Windows Hello Container oder bei einem unterstützten synchronisierten Passkey Anbieter liegen.
4. Der Benutzer bestätigt die Verwendung
Je nach Gerät erfolgt eine lokale Benutzerüberprüfung, beispielsweise mit Fingerabdruck, Gesichtserkennung oder PIN.
5. Der Authenticator signiert
Der Authenticator erstellt mit dem privaten Schlüssel eine kryptografische Signatur über die relevanten Authentifizierungsdaten.
6. Microsoft prüft die Antwort
Microsoft besitzt den zugehörigen öffentlichen Schlüssel und kann damit kontrollieren, ob die Signatur gültig ist.
Das Passwort kommt in diesem Ablauf nicht vor.
Auch der private Schlüssel muss nicht an Microsoft übertragen werden.
WebAuthn definiert dabei unter anderem die Prüfung der Challenge, des erwarteten Origins, der Relying Party ID und gegebenenfalls der Benutzerverifikation.
Warum gelten Passkeys als phishingresistent?
Hier liegt der entscheidende Unterschied zu Passwörtern.
Ein Passwort weiß nicht, auf welcher Webseite es gerade eingegeben wird.
Wenn ein Benutzer sein Passwort auf einer überzeugend nachgebauten Anmeldeseite eingibt, kann ein Angreifer dieses Passwort grundsätzlich erhalten.
Bei WebAuthn wird die Authentifizierung dagegen an den jeweiligen Dienst gebunden.
Dabei spielen insbesondere der Origin und die Relying Party ID eine Rolle.
Vereinfacht gesagt funktioniert ein für einen bestimmten Dienst registrierter Passkey nicht einfach auf irgendeiner ähnlich aussehenden Domain.
Eine gefälschte Microsoft Anmeldeseite kann zwar optisch nahezu identisch aussehen, sie besitzt aber nicht automatisch die Berechtigung, einen für den echten Microsoft Dienst registrierten Passkey zu verwenden.
Die WebAuthn Spezifikation verlangt außerdem, dass die Gegenstelle den erwarteten Origin und die Relying Party ID bei der Verifikation kontrolliert.
Genau das macht klassische Phishing Szenarien mit Passkeys wesentlich schwieriger.
Wichtig ist allerdings das Wort „phishingresistent“.
Es bedeutet nicht, dass ein Passkey jeden denkbaren Angriff auf eine Identität verhindert.
Diesen Unterschied habe ich bereits im Beitrag zu Pass the Passkey ausführlicher betrachtet. Dort geht es darum, was passiert, wenn nicht die Kryptografie selbst, sondern die Implementierung, das Endgerät oder die Verarbeitung der WebAuthn Daten angegriffen wird. Pass the Passkey, wie sicher sind Passkeys wirklich?
Kann ein Passkey gleichzeitig MFA sein?
Ja, im Microsoft Entra Kontext können FIDO2 Passkeys eine mehrstufige Authentifizierung erfüllen.
Das wirkt zunächst ungewöhnlich, weil der Benutzer nur eine Aktion wahrnimmt.
Hinter dieser Aktion stecken aber unterschiedliche Faktoren.
Der Authenticator beziehungsweise das Gerät stellt den Besitzfaktor dar.
Die lokale Benutzerüberprüfung erfolgt beispielsweise über eine PIN oder Biometrie.
Microsoft beschreibt Passkeys deshalb als Möglichkeit für passwortlose Mehrfaktorauthentifizierung.
Für den Benutzer fühlt sich die Anmeldung trotzdem wie ein einzelner Vorgang an.
Das ist einer der Gründe, warum Passkeys aus meiner Sicht nicht nur aus Security Sicht interessant sind. Sie können stärkere Authentifizierung mit weniger sichtbaren Schritten verbinden.
Und was ist jetzt der Unterschied zu Windows Hello for Business?
Diese Frage ist berechtigt, denn technisch gibt es Gemeinsamkeiten.
Windows Hello for Business arbeitet ebenfalls mit asymmetrischer Kryptografie und gerätegebundenen Schlüsseln.
Trotzdem sollte man Windows Hello for Business und einen Microsoft Entra Passkey nicht gleichsetzen.
Windows Hello for Business ist eng mit dem Windows Gerät, dessen Identität und dem Single Sign on Prozess verbunden.
Es dient insbesondere der Anmeldung an einem verwalteten Windows Gerät und anschließend dem Zugriff auf Entra integrierte Ressourcen.
Ein Passkey ist dagegen eine standardbasierte Anmeldeinformation für einen Dienst.
Und seit 2026 gibt es noch eine zusätzliche Nuance.
Microsoft bietet derzeit den Microsoft Entra Passkey unter Windows als Preview an. Dabei kann ein FIDO2 Passkey direkt im lokalen Windows Hello Container gespeichert werden.
Dieser Passkey ist gerätegebunden, trotzdem ist er laut Microsoft ausdrücklich nicht dasselbe wie die Windows Hello for Business Anmeldeinformation.
Der Microsoft Entra Passkey unter Windows benötigt beispielsweise keinen Entra Join oder eine Entra Registrierung des Geräts und unterstützt nicht die Windows Geräteanmeldung. Windows Hello for Business bleibt für verwaltete Unternehmensgeräte die von Microsoft empfohlene Lösung für Geräteanmeldung und Single Sign on.
Das klingt zunächst nach einer kleinen Unterscheidung, ist für Richtlinien und Sicherheitsbewertungen aber wichtig.
Gerätegebunden oder synchronisiert?
Bei Passkeys gibt es zwei grundsätzliche Modelle.
Gerätegebundene Passkeys
Der private Schlüssel wird an ein bestimmtes physisches Gerät gebunden.
Dazu gehören beispielsweise FIDO2 Sicherheitsschlüssel und Passkeys im Microsoft Authenticator.
Der Vorteil liegt in der klaren Gerätebindung.
Ein Angreifer kann den Passkey nicht einfach über einen Cloud Account auf ein zweites Gerät synchronisieren.
Der Nachteil ist die Wiederherstellung.
Geht das Gerät oder der Sicherheitsschlüssel verloren, benötigt der Benutzer einen definierten Recovery Prozess oder einen weiteren registrierten Authenticator.
Synchronisierte Passkeys
Bei synchronisierten Passkeys wird verschlüsseltes Schlüsselmaterial über einen Passkey Anbieter synchronisiert.
Dadurch kann ein Benutzer denselben Passkey auf mehreren autorisierten Geräten verwenden.
Microsoft unterstützt hierfür unter anderem Apples iCloud Schlüsselbund und den Google Password Manager sowie weitere unterstützte Anbieter.
Aus Benutzersicht ist das komfortabler.
Ein neues Smartphone bedeutet nicht automatisch, dass jeder Passkey neu registriert werden muss.
Microsoft sieht synchronisierte Passkeys deshalb inzwischen als sinnvolle Option für einen großen Teil normaler Benutzer. Für privilegierte Benutzer oder Umgebungen mit strengen regulatorischen Anforderungen empfiehlt Microsoft weiterhin die Prüfung gerätegebundener Passkeys.
Es gibt also nicht den einen richtigen Passkey Typ für alle Benutzer.
Die Entscheidung hängt vom Schutzbedarf ab.
Was ist eine AAGUID?
Jetzt kommen wir zu einem dieser Begriffe, die komplizierter klingen als sie sind.
AAGUID steht für Authenticator Attestation GUID.
Es handelt sich um eine 128 Bit Kennung, die einen Authenticator Typ beziehungsweise einen Passkey Anbieter beschreibt.
Vereinfacht gesagt kann Microsoft Entra anhand der AAGUID unterscheiden, mit welcher Art von Authenticator es zu tun hat.
Wichtig ist dabei:
Eine AAGUID ist kein eindeutiger Fingerabdruck eines einzelnen physischen Sicherheitsschlüssels.
Authentifikatoren desselben Typs beziehungsweise Anbieters können dieselbe AAGUID verwenden.
Microsoft Entra kann Passkey Profile so konfigurieren, dass beispielsweise nur bestimmte AAGUIDs zugelassen werden. Dadurch lässt sich einschränken, welche Passkey Anbieter oder Sicherheitsschlüsseltypen Benutzer registrieren dürfen.
Aber daraus ergibt sich direkt die nächste Frage.
Wenn ein System lediglich eine Kennung übermittelt, woher weiß Microsoft, dass diese Kennung tatsächlich zu dem behaupteten Authenticator gehört?
Damit kommen wir zur Attestation.
Was bedeutet Attestation?
Die AAGUID beschreibt, um welchen Authenticator Typ es sich handeln soll.
Attestation kann einen kryptografisch überprüfbaren Nachweis über den Authenticator beziehungsweise dessen Herkunft liefern.
Microsoft kann diese Informationen zusammen mit dem FIDO Metadata Service verwenden, um zu prüfen, ob ein Authenticator den erwarteten Eigenschaften und Vertrauensankern entspricht.
Das ist besonders relevant, wenn eine Organisation nicht irgendeinen FIDO2 Authenticator akzeptieren möchte, sondern nur festgelegte und überprüfbare Geräte.
Man könnte beispielsweise festlegen, dass privilegierte Administratoren ausschließlich einen bestimmten zugelassenen Typ von FIDO2 Sicherheitsschlüssel verwenden dürfen.
Nur eine AAGUID zu erlauben ist dabei nicht dasselbe wie Attestation zu erzwingen.
Die AAGUID beschreibt den Typ.
Die Attestation liefert den kryptografisch prüfbaren Herkunftsnachweis.
Microsoft Entra kann beides über Passkey Profile steuern.
Warum ist Attestation bei synchronisierten Passkeys ein wichtiger Unterschied?
Microsoft dokumentiert für Microsoft Entra ausdrücklich, dass synchronisierte Passkeys keine Attestation unterstützen.
Wird in einem Passkey Profil Attestation erzwungen, werden synchronisierte Passkeys deshalb ausgeschlossen.
Das ist kein Beweis dafür, dass synchronisierte Passkeys unsicher sind.
Es bedeutet lediglich, dass eine Organisation eine andere Aussage über die Herkunft und Gerätebindung des Credentials treffen kann.
Für einen normalen Office Benutzer kann ein synchronisierter Passkey eine sehr sinnvolle Verbesserung gegenüber Passwort, SMS oder anderen phishbaren Methoden darstellen.
Für einen Global Administrator oder einen anderen hochprivilegierten Benutzer kann die Anforderung anders aussehen.
Dort möchte ich möglicherweise nicht nur wissen, dass ein gültiger Passkey verwendet wurde.
Ich möchte möglicherweise zusätzlich kontrollieren, auf welcher Klasse von Authenticator dieser Passkey liegt.
Diese Trennung sollte bei einer Passkey Einführung bewusst getroffen werden.
Was Passkeys nicht automatisch verhindern, Device Code Phishing
Origin Binding schützt sehr gut gegen ein klassisches Szenario, bei dem ein Opfer auf einer falschen Webseite zur Anmeldung gebracht wird.
Es gibt aber Authentifizierungsflüsse, bei denen das Opfer tatsächlich eine legitime Microsoft Seite benutzt.
Ein wichtiges Beispiel ist der Device Code Flow.
Ein Angreifer kann einen solchen Ablauf initiieren und anschließend versuchen, einen Benutzer dazu zu bringen, den erzeugten Code auf der echten Microsoft Anmeldeseite einzugeben und dort die Anmeldung abzuschließen.
Der Origin ist in diesem Fall legitim.
Deshalb löst die Origin Bindung eines Passkeys dieses Problem nicht automatisch.
Das bedeutet nicht, dass der Passkey gebrochen wurde.
Der Benutzer wird vielmehr dazu gebracht, einen echten Authentifizierungsvorgang für einen vom Angreifer gestarteten Flow zu bestätigen.
Microsoft selbst bezeichnet den Device Code Flow als Authentifizierungsfluss mit erhöhtem Risiko und empfiehlt Organisationen, ihn möglichst weitgehend zu blockieren und nur für dokumentierte Anwendungsfälle gezielt zuzulassen.
Das passt zu einem Muster, das wir bei modernen Identity Angriffen immer häufiger sehen.
Die Kryptografie wird nicht unbedingt angegriffen.
Stattdessen versuchen Angreifer, einen legitimen Prozess im falschen Kontext ausführen zu lassen.
Im Beitrag zu Storm 2949 habe ich genau diesen größeren Zusammenhang zwischen Identität, Cloud Zugriff, Conditional Access und modernen Angriffsketten beschrieben. Storm 2949, warum Microsoft Cloud Umgebungen heute aktiv betrieben und geschützt werden müssen
Was passiert, wenn der Angreifer bereits auf dem Endgerät ist?
Auch hier muss man sauber trennen.
Wenn Malware bereits im Benutzerkontext auf einem Gerät ausgeführt wird, befinden wir uns nicht mehr im klassischen Phishing Szenario.
Aktuelle Forschung von Dirk Jan Mollema zu Windows Hello for Business zeigt beispielsweise, dass ein Angreifer unter bestimmten Voraussetzungen die legitimen kryptografischen Schnittstellen eines bereits angemeldeten Windows Benutzers verwenden kann.
Dabei wird der private Windows Hello Schlüssel nicht aus dem TPM exportiert.
Der Angreifer bringt vielmehr das vorhandene System dazu, mit diesem Schlüssel zu signieren.
Das ist ein wesentlicher Unterschied.
Die Kryptografie wurde nicht gebrochen, der private Schlüssel wurde nicht gestohlen.
Das bereits kompromittierte Endgerät wird zum Werkzeug.
Diesen Angriff und seine Bedeutung für Windows Hello und Passkeys habe ich im Beitrag „Wenn passwortlose Authentifizierung zur Angriffsfläche wird“ genauer eingeordnet. Wenn passwortlose Authentifizierung zur Angriffsfläche wird
Auch die Forschung zu Pass the Passkey zeigt denselben Grundgedanken aus einer etwas anderen Richtung.
Phishingresistente Authentifizierung ist ein sehr starker Baustein.
Sie ersetzt aber keine Endpoint Security und keine korrekte Implementierung der Authentifizierungsprotokolle. Pass the Passkey, wie sicher sind Passkeys wirklich?
Der Registrierungsprozess gehört zum Sicherheitsmodell
Noch ein Punkt wird bei Passkeys häufig unterschätzt.
Wir diskutieren sehr ausführlich darüber, wie sicher eine Anmeldung mit einem vorhandenen Passkey ist.
Mindestens genauso wichtig ist aber die Frage, wie ein neuer Passkey registriert werden darf.
Wenn ein Angreifer bereits Zugriff auf ein Konto oder einen geeigneten Authentifizierungskontext besitzt und anschließend eine eigene starke Authentifizierungsmethode registrieren darf, kann aus der sicheren Authentifizierungsmethode ein Persistenzmechanismus werden.
Genau dieses Muster sehen wir inzwischen auch in realen Social Engineering Kampagnen.
Angreifer geben sich beispielsweise als Support aus und versuchen Benutzer dazu zu bringen, an einem manipulierten Registrierungsablauf mitzuwirken.
Der Passkey selbst ist dabei nicht die Schwachstelle.
Angegriffen wird der Prozess, mit dem Vertrauen aufgebaut wird.
Die aktuelle Vishing Kampagne gegen Microsoft 365 habe ich hier ausführlich beschrieben. Neue Passkey Betrugsmasche gegen Microsoft 365
Das ist für geplante Passkey Rollouts besonders relevant.
Benutzer müssen wissen, wann eine legitime Registrierung stattfindet, über welchen Kanal sie angekündigt wird und welche Abläufe der interne Support niemals telefonisch anstößt.
Was bedeutet das für Unternehmen?
Für mich ergeben sich daraus einige recht klare Konsequenzen.
Standardbenutzer
Für viele normale Benutzer sind Passkeys ein deutlicher Fortschritt gegenüber Passwörtern und klassischen phishbaren MFA Methoden.
Synchronisierte Passkeys können hier einen guten Kompromiss aus Sicherheit, Wiederherstellbarkeit und Benutzerfreundlichkeit darstellen.
Privilegierte Benutzer
Bei Administratoren und anderen besonders schützenswerten Identitäten würde ich stärker auf Gerätebindung, kontrollierte Authenticator Typen und, sofern für den gewählten Authenticator unterstützt, Attestation achten.
Die Entscheidung sollte nicht nur danach getroffen werden, ob eine Methode in Conditional Access als phishingresistent gilt.
Device Code Flow
Wenn der Device Code Flow im Unternehmen nicht benötigt wird, sollte er nicht einfach aus Kompatibilitätsgründen offen bleiben.
Microsoft empfiehlt selbst, diesen Flow so weit wie möglich zu blockieren und Ausnahmen gezielt einzugrenzen.
Registrierung neuer Authentifizierungsmethoden
Die Registrierung eines neuen Passkeys ist ein sicherheitskritischer Vorgang.
Conditional Access, klare Registrierungsprozesse, passende Authentication Strengths und eine Überwachung neuer Authentifizierungsmethoden gehören deshalb zum Rollout.
Endgeräte
Passkeys lösen das Passwortproblem.
Sie lösen nicht automatisch ein kompromittiertes Endgerät.
Endpoint Security, Gerätecompliance und Identitätsschutz bleiben deshalb relevant.
Externe Benutzer
Auch B2B Szenarien sollte man getrennt betrachten.
Microsoft erweitert die Passkey Unterstützung für Gäste und externe Benutzer weiter. Welche Einschränkungen aktuell gelten und was sich im weiteren Verlauf von 2026 ändert, habe ich im Beitrag zu Passkeys für B2B Gäste zusammengefasst. Passkeys für B2B Gäste in Entra ID
Fazit
Passkeys sind im Kern nicht besonders kompliziert.
Statt eines gemeinsamen Passworts gibt es ein kryptografisches Schlüsselpaar.
Der Dienst kennt den öffentlichen Schlüssel.
Der Authenticator kontrolliert den privaten Schlüssel.
Bei der Anmeldung wird eine Challenge signiert und der Dienst prüft, ob die Signatur zum registrierten öffentlichen Schlüssel und zum erwarteten Kontext passt.
Die eigentliche Komplexität beginnt erst danach.
Ist der Passkey gerätegebunden oder synchronisiert?
Welche Passkey Anbieter sind erlaubt?
Benötigt eine Benutzergruppe Attestation?
Wie wird ein neuer Passkey registriert?
Welche Recovery Prozesse existieren?
Was passiert bei einem kompromittierten Endgerät?
Und welche Authentifizierungsflows dürfen im Tenant überhaupt verwendet werden?
Genau deshalb sollte eine Passkey Einführung nicht einfach als Ersatz des Passwortfeldes betrachtet werden.
Passkeys verändern das Authentifizierungsmodell.
Wer dieses Modell versteht und Registrierung, Geräte, Policies und Recovery mit einbezieht, bekommt eine deutlich stärkere Grundlage für moderne Identity Security.
