Microsoft Entra: Phishing-resistente Anmeldung per Passkey

Architektur und Funktionsprinzip

Passkeys unter Windows nutzen den bestehenden Windows-Hello-Container als isolierte Speicherumgebung für private Schlüssel. Zugriff erhält ausschließlich der lokale Benutzer nach erfolgreicher Verifikation über biometrische Verfahren oder eine PIN. Diese PIN dient nicht als Authentifizierungsmerkmal gegenüber dem Dienst, sondern entsperrt lediglich den lokal gespeicherten Schlüssel. Eine direkte Anmeldung mit der PIN ohne Zugriff auf das Gerät ist technisch ausgeschlossen.

Die Authentifizierung gegenüber Microsoft Entra ID erfolgt über das FIDO2-Protokoll mit Public-Key-Kryptografie. Der Client präsentiert einen signierten Challenge-Response, der an die Zielanwendung gebunden ist. Das vermeidet die Gefahr, Anmeldeinformationen auf gefälschten Webseiten weiterzugeben, da der Passkey nur für registrierte Origins gültig bleibt.

Ein wesentliches Merkmal liegt in der Gerätebindung. Jeder Passkey bleibt lokal im Windows-Container gespeichert und synchronisiert nicht über mehrere Geräte hinweg. Für jedes Entra-Konto ist pro Gerät eine separate Registrierung erforderlich. Mehrere Konten lassen sich parallel auf einem System verwalten, wobei jedes Konto einen eigenen Schlüssel erhält.

Abgrenzung zu Windows Hello for Business

Die technische Nähe zu Windows Hello for Business führt häufig zu Fehlinterpretationen. Beide Technologien nutzen denselben Container, verfolgen jedoch unterschiedliche Konzepte. Windows Hello for Business koppelt Anmeldeinformationen an das Gerätevertrauen und ermöglicht sowohl lokale Anmeldung am Betriebssystem als auch Single Sign-on für angebundene Dienste. Die Provisionierung erfolgt automatisch bei Gerätebindung an Entra. Die zugrunde liegende Authentifizierung nutzt proprietäre Mechanismen auf Basis von FIDO2, jedoch nicht standardisierte Passkeys.

Entra-Passkeys hingegen stellen einen reinen FIDO2-Mechanismus dar. Sie unterstützen keine Geräteanmeldung und keine Single-Sign-On-Funktion auf Betriebssystemebene. Registrierung erfolgt manuell durch den Benutzer, unabhängig vom Gerätezustand. Auch nicht registrierte oder private Systeme lassen sich einbinden. Diese Trennung führt zu einem parallelen Betrieb beider Verfahren mit klarer funktionaler Abgrenzung.

Ein praktisches Problem ergibt sich bei bestehender Hello-for-Business-Konfiguration. Sobald für ein Konto bereits ein entsprechender Schlüssel im Container vorliegt, blockiert das System die Registrierung eines zusätzlichen Passkeys. Diese Einschränkung fällt erst nach Überschreiten einer internen Grenze von insgesamt mehr als 50 gespeicherten Anmeldeinformationen weg.

Einsatzszenarien und funktionale Erweiterung

Der primäre Einsatzzweck liegt außerhalb klassischer, verwalteter Endgeräte. Organisationen können Authentifizierung auf nicht verwalteten Systemen absichern, ohne Gerätebindung oder Registrierung im Verzeichnis. Private Rechner, gemeinsam genutzte Arbeitsplätze oder temporäre Zugriffssysteme lassen sich in das Sicherheitsmodell integrieren.

Der Benutzer authentifiziert sich über biometrische Verfahren oder PIN, die Freigabe des Schlüssels erfolgt lokal. Der Dienst prüft anschließend die kryptografische Signatur. Ein Auslesen von Anmeldeinformationen ist technisch nicht möglich, da kein übertragbares Geheimnis existiert. Ein Angriffsszenario mit abgefangenem MFA-Code verliert damit kaum mehr möglich. Selbst bei einem erfolgreichen Phishing-Angriff liefert das Gerät keinen gültigen Authentifizierungsnachweis für eine manipulierte Zieladresse.

Unterschiede zwischen gerätegebundenen und synchronisierten Passkeys

FIDO2 unterscheidet zwei grundlegende Modelle. Gerätegebundene Passkeys verbleiben lokal und sind nicht übertragbar. Synchronisierte Varianten speichern den privaten Schlüssel verschlüsselt in einem Cloud-Dienst eines Plattformanbieters und stellen ihn auf mehreren Geräten bereit. Plattformen wie Apple iCloud Keychain oder Google Password Manager nutzen diese Synchronisation. Der Zugriff erfolgt über biometrische Verifikation auf jedem Gerät. Dadurch fällt die erneute Registrierung beim Gerätewechsel weg.

Windows-Passkeys in Entra verwenden ausschließlich das gerätegebundene Modell. Eine Synchronisation ist nicht vorgesehen. Diese Einschränkung erhöht die Isolation der Schlüssel, führt jedoch zu höherem Verwaltungsaufwand bei mehreren Geräten. Synchronisierte Passkeys stehen parallel in Microsoft Entra ID zur Verfügung und lassen sich über Passkey-Profile aktivieren. Attestation lässt sich in diesem Szenario nicht erzwingen, da der Ursprung des Schlüssels nicht eindeutig überprüfbar bleibt.

Die gezeigte Konfiguration bildet eine geeignete Ausgangsbasis für den Einsatz von Passkeys in Microsoft Entra. Für die Nutzung von Windows-Passkeys sind nun noch gezielte Ergänzungen erforderlich. Im Passkey-Profil muss ein Hauptschlüsseltyp ausgewählt werden, wobei gerätegebundene Passkeys den relevanten Modus darstellen. Zusätzlich sollten die spezifischen Windows-Hello-AAGUIDs in die Allow-Liste aufgenommen werden, damit Windows-Geräte als Authenticator zugelassen sind. Die deaktivierte Attestation entspricht den Anforderungen der Vorschauphase und kann beibehalten werden. Nach diesen Anpassungen steht die Registrierung von Windows-Passkeys für die zugewiesenen Benutzergruppen zur Verfügung und lässt sich nahtlos in bestehende Richtlinien für den Zugriff integrieren.

Richtliniensteuerung über Passkey-Profile

Die Verwaltung erfolgt über Passkey-Profile innerhalb der Authentifizierungsmethodenrichtlinien. Diese Profile definieren Anforderungen für Registrierung und Nutzung und lassen sich granular auf Benutzergruppen anwenden. Parameter umfassen die Durchsetzung von Attestation, die Auswahl unterstützter Passkey-Typen sowie Einschränkungen auf Basis von AAGUID-Werten. Jede Implementierung eines Authenticators besitzt eine eindeutige AAGUID, die Rückschlüsse auf Hersteller und Modell zulässt.

Die Aktivierung von Attestation verlangt eine vollständige Zertifikatskette, die über den FIDO Metadata Service validierbar ist. Anbieter müssen ihre Metadaten dort hinterlegen. Ohne diesen Eintrag scheitert die Registrierung bei aktivierter Attestation. Wird Attestation deaktiviert, akzeptiert das System auch generische oder nicht verifizierbare Schlüsseltypen. Ein Konflikt ergibt sich aus der Kombination von Attestation und synchronisierten Passkeys. Sobald Attestation aktiv ist, entfällt die Möglichkeit zur Nutzung synchronisierter Varianten, da deren Herkunft nicht verifizierbar bleibt.

Konfigurationsanforderungen für Windows-Passkeys

Die Aktivierung erfolgt nicht automatisch. Administratoren müssen die Methode Passkeys (FIDO2) explizit aktivieren und ein Profil definieren. Für Windows-Passkeys gelten zusätzliche Einschränkungen solange die Lösung noch im Preview-Status ist. Die Registrierung funktioniert nur, wenn spezifische AAGUIDs für Windows Hello explizit freigegeben sind. Dazu gehören Varianten für hardwarebasierte TPM-Speicherung, Virtualization-based Security sowie softwarebasierte Implementierungen. Ohne diese Freigabe blockiert das System jede Registrierung.

Attestation muss deaktiviert sein, da Windows-Passkeys im Preview-Zustand keine entsprechende Nachweisführung liefern. Zusätzlich ist eine Aktivierung von Schlüsselrestriktionen erforderlich, um die erlaubten Authenticatoren einzugrenzen. Conditional-Access-Richtlinien bleiben unverändert aktiv. Passkeys lassen sich in bestehende Authentifizierungsstärken integrieren, ohne Anpassung bestehender Policies.

Ablauf aus Benutzersicht

Die Registrierung erfolgt über das Self-Service-Portal My Sign-Ins. Der Benutzer wählt die Passkey-Option und kann bei Bedarf ein externes Gerät zur Erstellung nutzen. Die initiale Einrichtung kann über QR-Code und Kamera erfolgen, ohne separate App. Nach erfolgreicher Registrierung erfolgt die Anmeldung über biometrische Verifikation oder PIN. Anwendungen akzeptieren den Passkey als vollwertigen Authentifizierungsnachweis. Der Zugriff erfolgt ohne Passwort und ohne zusätzlichen Faktor.

Bei synchronisierten Passkeys steht derselbe Schlüssel auf weiteren Geräten zur Verfügung, sofern der Plattformanbieter eine entsprechende Synchronisation bereitstellt. Bei gerätegebundenen Varianten entfällt diese Möglichkeit vollständig.

Konto-Wiederherstellung und Risikosteuerung

Die Umstellung auf passwortlose Authentifizierung verändert den Wiederherstellungsprozess. Klassische Mechanismen verlieren ihre Bedeutung. Microsoft integriert mit Verified ID ein Verfahren zur Identitätsprüfung über offizielle Dokumente und biometrische Verifikation. Nach erfolgreicher Prüfung stellt das System einen Temporary Access Pass bereit. Dieser dient zur erneuten Registrierung eines Passkeys ohne Passwort.

Der Prozess reduziert Abhängigkeiten von Helpdesk-Strukturen und verhindert klassische Social-Engineering-Angriffe im Recovery-Prozess. Zusätzlich reagiert Microsoft Entra ID auf Risikoereignisse in Echtzeit. Erkennt das System ein kompromittiertes Konto, erfolgt eine sofortige Sitzungsinvalidierung. Der Benutzer muss sich erneut authentifizieren. Erfolgt die Anmeldung erfolgreich über einen Passkey, sinkt das Risiko automatisch.

Kritische Bewertung und Einschränkungen

Die Einführung adressiert bekannte Schwachstellen klassischer MFA-Verfahren. Gleichzeitig ergeben sich neue operative Anforderungen. Die fehlende Synchronisation unter Windows erhöht den Aufwand bei Mehrgeräte-Szenarien. Besonders in heterogenen Umgebungen führt dies zu zusätzlicher Registrierung und Verwaltung. Die Abhängigkeit von AAGUID-Listen und manueller Freigabe erschwert die initiale Konfiguration. Fehlerhafte Richtlinien führen direkt zu blockierten Registrierungen oder nicht nutzbaren Schlüsseln.

Die parallele Existenz von Windows Hello for Business und Entra-Passkeys erzeugt zusätzliche Komplexität. Konflikte im Container verhindern die Nutzung beider Verfahren für dasselbe Konto. Diese Einschränkung beeinflusst insbesondere bestehende Unternehmensumgebungen mit aktivierter Hello-for-Business-Infrastruktur. Attestation stellt einen weiteren kritischen Punkt dar. Ohne Aktivierung fehlt eine verlässliche Prüfung der Authenticator-Herkunft. Mit Aktivierung fallen jedoch Teile der Funktionalität, insbesondere im Kontext synchronisierter Passkeys weg.

Die Vorschauphase zeigt zudem Inkonsistenzen in der Anzeige registrierter Methoden. Entfernte AAGUIDs führen nicht automatisch zur Deaktivierung bestehender Einträge in der Benutzeroberfläche. Die tatsächliche Nutzbarkeit richtet sich weiterhin nach der aktiven Richtlinie.

Einordnung im Sicherheitsmodell

Passkeys verschieben die Authentifizierung in Richtung hardwarebasierter Vertrauensanker. Der Verzicht auf übertragbare Secrets reduziert die Angriffsfläche signifikant. Gleichzeitig erfordert das Modell eine konsequente Umsetzung auf Richtlinienebene. Der Einsatz unter Windows erweitert das Konzept auf nicht verwaltete Systeme, ohne die bestehende Gerätebindung aufzugeben. Diese Kombination führt zu einem hybriden Ansatz zwischen klassischem Endpoint Trust und rein benutzerbasierter Authentifizierung. Die praktische Umsetzung hängt stark von der sauberen Definition der Passkey-Profile und deren Zuordnung zu Benutzergruppen ab. Fehler in diesem Bereich wirken sich unmittelbar auf die Nutzbarkeit und Sicherheit aus.