Beginnen Sie mit den Administratoren und erzwingen Sie für sie über Conditional Access die integrierte Authentication Strength Phishing-resistant MFA. Sie lässt nur Windows Hello for Business oder ein Plattform-Credential, einen FIDO2-Security-Key oder die zertifikatsbasierte Authentifizierung von Entra (Multifaktor) zu. SMS und Push-Freigaben erfüllen die Richtlinie für diese Konten auf den betroffenen Ressourcen nicht mehr, die Passwortabfrage bleibt allerdings bestehen (siehe „Was schiefgeht“).
Warum Admins zuerst dran sind
In der Authentifizierungsübersicht von Microsoft heißt es, dass MFA auf Basis von SMS, E-Mail-OTP oder Authenticator-Apps anfällig für Remote-Phishing ist. Dabei erbeuten Angreifer Passwörter oder Einmalcodes, ohne das Gerät des Nutzers anzufassen. Microsoft empfiehlt stattdessen Windows Hello for Business, Passkeys (FIDO2), FIDO2-Security-Keys oder zertifikatsbasierte Authentifizierung. Bei einem Admin-Konto richtet ein gestohlener Code den größten Schaden an, und ein kleines Team hat nur eine Handvoll davon umzustellen.
Vorsicht bei der mittleren integrierten Option: Laut der Dokumentation zu Authentication Strengths enthält die Strength Passwordless MFA auch die Telefonanmeldung per Microsoft Authenticator. Die Strength Phishing-resistant enthält sie nicht.
Den Tenant vorbereiten
Passkeys (FIDO2) sind in allen Editionen von Entra ID ohne zusätzliche Lizenz verfügbar. Conditional Access setzt Entra ID P1 voraus.
Die Einstellungen finden Sie unter Entra ID > Security > Authentication methods > Policies > Passkey (FIDO2). Sie benötigen mindestens die Rolle Authentication Policy Administrator. Drei Details sind wichtig:
- Die Umstellung auf Passkey-Profile ist nicht umkehrbar. Sie können sie nachträglich nicht rückgängig machen, und Ihre bisherigen globalen Einstellungen wandern in ein Default-Profil. Unterstützt werden bis zu drei Profile einschließlich Default.
- Allow self-service set up muss auf Yes stehen, sonst können Nutzer über Security info keinen Passkey registrieren. Das ist eine globale Einstellung, keine pro Profil.
- Für die Registrierung ist eine MFA erforderlich, die innerhalb der letzten fünf Minuten abgeschlossen wurde.
Für Admins nennt die Dokumentation selbst als Beispiel ein Profil mit dem Passkey-Typ Device-bound und Enforce attestation auf Yes. Device-bound bedeutet, dass der private Schlüssel das physische Gerät nie verlässt, etwa einen Security Key oder Microsoft Authenticator. Synchronisierte Passkeys unterstützen keine Attestation, und Microsoft rät dazu, sie als phishing-resistent, aber mit dem Sicherheitsniveau anderer nicht attestierter Authenticator zu behandeln. Der NIST-Text verlangt auf AAL3, der höchsten Stufe, einen phishing-resistenten Authenticator mit nicht exportierbarem Schlüssel. Device-bound-Schlüssel kommen dem unter den Optionen in Entra daher am nächsten.
Mit einer Authentication Strength durchsetzen
Erstellen Sie eine Conditional-Access-Richtlinie, wählen Sie als Ziel Ihre Admin-Rollen oder -Gruppe und unter den Grant Controls Require authentication strength. Wählen Sie Phishing-resistant MFA. Eine Kombination mit Require multifactor authentication in derselben Richtlinie ist nicht möglich, weil die integrierte MFA-Strength dieser Kontrolle entspricht.
Integrierte Strengths lassen sich nicht bearbeiten, und Microsoft aktualisiert sie, sobald neue Methoden hinzukommen. Wenn Sie einen festen Satz erlaubter Methoden brauchen, erstellen Sie eine benutzerdefinierte Strength.
SMS müssen Sie nicht für alle abschalten. Die Strength liegt über der Authentication-methods-Richtlinie und schränkt sie für ein Szenario ein. Mitarbeitende können für normale Ressourcen weiterhin Passwort und Push-Freigabe nutzen, während für Admins die strengere Richtlinie gilt.
Was schiefgeht
Ein Admin gibt zuerst weiterhin ein Passwort ein. Conditional Access wird erst nach der initialen Authentifizierung ausgewertet, die Strength verlangt also erst danach eine phishing-resistente Methode.
Meldet sich ein Nutzer mit einem Passwort als primärer Methode an und die Strength verlangt Windows Hello for Business, wird er nicht dazu aufgefordert. Er muss die Sitzung neu starten, Sign-in options wählen und die geforderte Methode auswählen. Nehmen Sie das in Ihre Admin-Anleitung auf.
Zwei Kontrollen greifen zu unterschiedlichen Zeitpunkten. Enforce attestation gilt nur bei der Registrierung, ein ohne Attestation registrierter Passkey wird beim Anmelden also nicht blockiert, sobald Sie die Option aktivieren. Registrieren Sie die Admin-Schlüssel danach neu. Key restrictions per AAGUID gelten sowohl bei der Registrierung als auch bei der Anmeldung. Wer eine zuvor erlaubte AAGUID entfernt, sperrt daher alle aus, die dieses Modell registriert haben.
Überschneidende Profile wirken permissiv, und zwar bei Registrierung und Anmeldung auf Ebene der Passkey-Richtlinie. Fällt ein Nutzer unter mehrere Profile, ist ein Passkey erlaubt, wenn er mindestens eines davon vollständig erfüllt, in beliebiger Reihenfolge. Ein Admin, der zusätzlich in einer Gruppe „alle synchronisierten oder Device-bound-Passkeys“ sitzt, kann daher, soweit es die Passkey-Richtlinie betrifft, einen synchronisierten Passkey registrieren und nutzen. Die Quellen sagen nicht, ob die Strength in Conditional Access ihn akzeptiert. Testen Sie diesen Fall deshalb.
Prüfen Sie nach der Umstellung das Default-Profil unter Enable and target. Ist sein Ziel All users und erlaubt es synchronisierte Passkeys, richten Sie es auf Gruppen aus, die Ihre Admins nicht enthalten. Schließen Sie Admins nicht stattdessen in der Passkey-(FIDO2)-Richtlinie aus: Eine ausgeschlossene Gruppe ist von FIDO2-Registrierung und -Anmeldung komplett gesperrt, und das überstimmt jede Einbeziehung.
Sign-in frequency und Strength können zu unterschiedlichen Zeitpunkten erfüllt werden. Bei einer Passkey-Strength und einer Sign-in frequency von einer Stunde erfüllen eine Passkey-Anmeldung von vor 24 Stunden plus eine heutige Windows-Hello-Geräteentsperrung zusammen beide Vorgaben. Wenn Sie sich bei Admins auf kurze Intervalle verlassen, testen Sie diesen Fall.
Temporary Access Pass taucht in der MFA-Strength auf, nicht aber in der phishing-resistenten. Das ist unsere eigene Schlussfolgerung, die die Quellen nicht ausdrücklich nennen: Ein Recovery- oder Bootstrap-Ablauf auf Basis eines Temporary Access Pass erfüllt die Richtlinie nicht und braucht daher eine Ausnahme oder eine eigene Richtlinie. Entscheiden Sie das vor der Durchsetzung, nicht erst im Incident.
Wo Sie anfangen
- Listen Sie jedes Konto mit einer Admin-Rolle auf und wählen Sie zwei oder drei für die Pilotgruppe aus.
- Wechseln Sie zu Passkey-Profilen, prüfen Sie das Ziel des Default-Profils, erstellen Sie ein Admin-Profil mit Device-bound und Enforce attestation auf Yes und richten Sie es nur auf die Pilotgruppe aus.
- Registrieren Sie pro Pilot-Admin mindestens zwei Authenticator, zum Beispiel einen Security Key und Windows Hello, und bestätigen Sie, dass die Anmeldung mit jedem funktioniert.
- Erstellen Sie die Conditional-Access-Richtlinie mit der Strength Phishing-resistant MFA für die Pilotgruppe. Als allgemeine Praxis (die hier verwendeten Microsoft-Seiten behandeln Break-Glass-Konten nicht) schließen Sie Notfallzugangskonten aus und geben jedem einen eigenen FIDO2-Key.
- Weiten Sie die Richtlinie auf alle Admins aus. Entfernen Sie vor der Attestation-Pflicht registrierte Passkeys erst, nachdem jeder Admin einen attestierten Schlüssel neu registriert hat, damit niemand ausgesperrt wird.
- Lassen Sie das Ergebnis prüfen. Unser Beratungsteam kann die Richtlinie überprüfen, und ein Penetrationstest zeigt, ob ein Admin-Pfad noch eine schwächere Methode akzeptiert.
