Passkeys gehören in vielen Entra-ID-Tenants, die ich betreue, inzwischen zum Alltag. Ihr eigentliches Potenzial entfalten sie aber erst, wenn man über die Standardaktivierung hinausgeht. Die Authentifizierungsmethoden-Richtlinie erlaubt es, FIDO2-Sicherheitsschlüssel und Microsoft-Authenticator-Passkeys genau zu steuern, statt sie bloß freizuschalten. Seit die Passkey-Profile über eine breite Vorschauphase den Weg in die Praxis gefunden haben, begegnen mir in Projekten immer häufiger differenzierte Konfigurationen. Admin-Konten bekommen andere Regeln als Standardbenutzer, bestimmte Schlüsselmodelle werden zugelassen oder ausgeschlossen, und Attestation wird endlich konsequent erzwungen, anstatt als ausgegraute Option ungenutzt zu bleiben.

Mehrere Passkey-Profile ersetzen die bisher einheitlichen Einstellungen

Bisher waren die Einstellungen für FIDO2- und Authenticator-Passkeys in Entra ID recht allgemein gehalten. Mit Passkey-Profilen kann man nun erstmals mehrere Profile mit unterschiedlichen Einstellungen anlegen und gezielt einzelnen Benutzergruppen zuweisen. Einem privilegierten Admin-Kreis erlaubt man so etwa nur bestimmte Hardware-Keys (z. B. YubiKeys mit passender AAGUID) und schreibt Attestation vor, während Standardbenutzer auch Passkeys im Microsoft Authenticator verwenden dürfen. Man muss sich also nicht mehr auf einen Kompromiss für alle einlassen, sondern kann fein abgestuft und nach Risiko steuern.

Die Profile liegen im Entra Admin Center unter Entra ID → Authentifizierungsmethoden → Richtlinien. Dort legt man für FIDO2 und Authenticator jeweils eigene Profile an und weist sie einer Zielgruppe zu (Benutzer, Gruppen, Administrative Units). Danach kann man zum Beispiel AAGUIDs per Allowlist zulassen, die maximale Zahl an Passkeys pro Nutzer festlegen oder Attestation verpflichtend einstellen. Ein typisches Setup sieht so aus:

flowchart TD
    Profil1["Admin-Profile"] --> AAGUIDfilter["AAGUID-Filter: Nur Hardwarekey"]
    Profil1 --> Attestation["Attestation: Erforderlich"]
    Profil1 --> GruppeAdmins["Zuordnung: Admin-Gruppe"]
    Profil2["Standard-User-Profile"] --> AuthPasskey["Authenticator-Passkey erlaubt"]
    Profil2 --> AAGUIDoffen["AAGUID: Keine Einschränkung"]
    Profil2 --> GruppeUser["Zuordnung: Benutzer-Gruppe"]

Abbildung: Unterschiedliche Passkey-Profile für Admins und Standardbenutzer in Entra ID.

Nur getestete Schlüssel gehören auf die AAGUID-Allowlist

Beim Rollout stolpern viele über schlecht durchdachte Allow- oder Denylists für AAGUIDs (Authenticator Attestation GUID). Unternehmen mit strengeren Governance-Vorgaben rate ich, nur Modelle zuzulassen, die ausdrücklich getestet und als sicher eingestuft wurden. Für die Listen meldet man sich am besten testweise mit den gängigen Schlüsseln an und liest die AAGUIDs danach aus den Gerätedetails des Benutzers im Entra Admin Center oder per PowerShell/PIM aus. Vorsicht ist bei Authenticator-Passkeys geboten, denn sie haben je nach Plattform (iOS, Android) eigene AAGUIDs. Die Einzelheiten beschreibt die offizielle Dokumentation (FIDO2-AAGUIDs, Authenticator-Passkeys).

Mit Attestation liefert der Schlüssel bei der Registrierung einen Herkunftsnachweis. Für Admin-Profile ist das Pflicht, weil sich nur so selbstgebaute FIDO2-Implementierungen ausschließen lassen. Allerdings unterstützt nicht jeder Key Attestation. Wer seinen Bestand vor dem Rollout nicht testet, bekommt das später in Form von Supportfällen zu spüren.

Praxistipp: Hakt der Rollout, sollte man zuerst prüfen, ob die betroffenen Benutzer und Geräte wirklich zur Zielgruppe des Profils gehören und ob die AAGUID der verwendeten Keys richtig eingetragen ist. Im Zweifel fängt man lieber zu restriktiv an und lockert bei Bedarf nach, statt den umgekehrten Weg zu gehen.

Für Admins bleiben gerätegebundene Passkeys die erste Wahl

Seit es Passkeys auch im Authenticator gibt, muss man entscheiden, ob man synchronisierbare Passkeys zulässt oder privilegierte Konten weiterhin auf „device-bound“-Passkeys beschränkt, also auf Schlüssel, die nicht synchronisiert werden und fest an ein Gerät gebunden sind. Die meisten Security-Teams, mit denen ich arbeite, gehen bei Admins noch konservativ vor. Synchronisierbare Passkeys wie die aus dem Authenticator sind zwar bequem, könnten bei einem kompromittierten Smartphone aber über mehrere Geräte hinweg missbraucht werden. Bei Standardbenutzern ist dieses Risiko meist vertretbar. Für Admins spricht dagegen vieles dafür, sich auf gerätegebundene Hardware-Keys zu beschränken. Die passende Einstellung findet sich direkt im Passkey-Profil („nur nicht-synchronisierte Passkeys zulassen“).

Im Entra Admin Center lassen sich die Profile per Klick einrichten

Konfiguriert werden die Profile per Klick im Entra Admin Center → Entra ID → Authentifizierungsmethoden → Richtlinien. Die AAGUID-Liste füllt man oft einfach per Copy & Paste aus der Geräteübersicht oder aus der Ausgabe von AzureAD-PowerShell. Ein Beispiel (PowerShell, erfordert Global Administrator und Microsoft Graph PowerShell):

Get-MgUserAuthenticationFido2Method -UserId <UserId>

Die Ausgabe listet die AAGUIDs sämtlicher Keys auf, die der Nutzer registriert hat. Damit lässt sich die Allowlist des gewünschten Profils befüllen. Attestation aktiviert man über einen einfachen Schalter, die Zielgruppe legt man über Benutzer, Gruppen oder Administrative Units fest. Bei größeren Umstellungen lohnt es sich, ein Profil zunächst im Report-only-Modus zu testen und die Auswirkungen zu prüfen, bevor es produktiv geht.

Passkey-Profile werden zum Standard, doch die Governance gibt den Ausschlag

In vielen Tenants beobachte ich, dass Passkey-Profile die MFA-Strategie immer stärker prägen. Die Entwicklung geht eindeutig hin zu differenzierten Konfigurationen. Fehlt es aber an Governance und Tests oder an Disziplin bei den AAGUIDs, bleiben Lücken ein Risiko. Wer sorgfältig arbeitet, kann MFA mit den Passkey-Profilen erstmals tatsächlich risikobasiert und abgestimmt auf einzelne Gruppen umsetzen. Für Admin-Konten empfehle ich nach wie vor gerätegebundene Hardware-Keys mit Attestation und eine Allowlist, die regelmäßig gepflegt wird. Alle aktuellen Optionen beschreibt die offizielle Dokumentation, und das Message Center enthält Hinweise auf geplante Änderungen oder neue Profile.

Weitere Erfahrungen aus der Praxis zur Migration alter Authentifizierungsmethoden und zu Berichten finden sich im Beitrag Authentifizierungsmethoden-Bericht: Den Status sichtbar machen.