In vielen Tenants, die ich betreue, gehört phishingresistente MFA für Admins mittlerweile zum Standard. Der Großteil der Benutzer meldet sich dagegen weiterhin mit der klassischen Authenticator-App an, manchmal sogar per SMS. Zur eigentlichen Bewährungsprobe wird erst der breite Rollout auf alle Benutzergruppen. Unterschiedliche Gerätetypen, geteilte Konten, Frontline-Szenarien, Legacy-Apps und ein uneinheitlicher Hardwarestand lassen sich mit einer einzigen Methode nicht abdecken. Für einen realistischen Fahrplan zu phishingsicherer MFA in Entra ID braucht man deshalb mehrere aufeinander abgestimmte Methoden, klare Onboarding-Prozesse und eine verlässliche Kontrolle des Fortschritts.

Phishingresistente MFA setzt sich in der Praxis aus mehreren Bausteinen zusammen

Am Ende soll jede Cloud-Anmeldung, die privilegierten Zugriff gewährt oder sensible Daten berührt, mit einer Methode abgesichert sein, an der moderne Phishing-Techniken wie MFA-Prompt-Bombing oder AiTM-Angriffe zuverlässig scheitern. Die Anforderungen dafür fasst die Microsoft-Dokumentation zusammen. In meinen Projekten setze ich auf folgende Bausteine, jeweils für die passenden Nutzergruppen:

  • Windows Hello for Business mit Cloud-Kerberos-Trust – für die verwalteten Windows-Clients im Büro (mein Artikel dazu)
  • Passkeys in Microsoft Authenticator – für mobile Szenarien, Plattformwechsel und BYOD, mittlerweile auch für Webanmeldungen abseits des Hauptgeräts (mehr zu Passkeys)
  • FIDO2-Sicherheitsschlüssel – für Sonderfälle wie gemeinsam genutzte Terminals, geteilte Konten oder besonders abgesicherte Umgebungen
  • macOS Platform SSO – für verwaltete Macs, direkt in Entra ID integriert (meine Erfahrungen mit Platform SSO)
  • Temporary Access Pass – für sicheres Onboarding und Recovery, ohne dass man auf schwache Methoden ausweichen muss (so gelingt das Onboarding)

Gesteuert werden alle Methoden über Richtlinien für Authentifizierungsstärken (das Konzept bei Microsoft). Dabei kommt es darauf an, die Methoden so zuzuweisen, dass sie zum tatsächlichen Arbeitsalltag passen. Wer zu schematisch vorgeht, riskiert Schatten-IT oder Frust beim Onboarding.

Authentifizierungsstärken steuern die zulässigen Methoden für jedes Szenario

Mit den Richtlinien für Authentifizierungsstärken (Authentication Strengths) hat Microsoft in Entra ID ein Steuerungsinstrument geschaffen, das sich im Alltag bewährt. Man legt damit fest, welche Methoden an welcher Stelle akzeptiert werden, etwa für sensible Apps, privilegierte Rollen oder bestimmte Gruppen, und kann Benutzer gezielt auf phishingsichere MFA verpflichten. Für Adminrollen und kritische Apps lege ich in der Regel eine eigene Authentifizierungsstärke an, die ausschließlich Windows Hello, Passkeys und FIDO2 zulässt. Standardanwendern in gesicherten Büros kann man Passkeys und Hello erlauben; an Frontline- oder geteilten Geräten sind FIDO2-Sticks oft die realistischste Wahl.

Zugewiesen werden die Richtlinien über Conditional Access, und genau darauf kommt es an. Auf diese Weise lässt sich der Umstieg mit dem Modus „Report-only“ oder mit Ausschlussregeln absichern, bevor man die Zügel anzieht. Viele Details zur praktischen Umsetzung stehen im Beitrag Authentifizierungsstärken für Admins.

flowchart TD
    onboarding["Onboarding mit Temporary Access Pass"] --> winhello["Windows Hello for Business"]
    onboarding --> passkey["Passkey in Authenticator"]
    onboarding --> fido2["FIDO2-Key registrieren"]
    onboarding --> macsso["macOS Platform SSO"]
    winhello --> nutzergruppe1["Büro-Mitarbeiter auf Windows"]
    passkey --> nutzergruppe2["Mobile & BYOD"]
    fido2 --> nutzergruppe3["Frontline & Shared"]
    macsso --> nutzergruppe4["macOS-Anwender"]
    allemethoden["Authentifizierungsstärke-Richtlinie"] --> nutzergruppe1
    allemethoden --> nutzergruppe2
    allemethoden --> nutzergruppe3
    allemethoden --> nutzergruppe4

Abbildung: MFA-Onboarding und Zuweisung nach Nutzergruppen, gesteuert über Authentifizierungsstärken.

Geteilte Konten, Frontline und Recovery brauchen eigene Lösungen

Besonders knifflig wird es in Umgebungen mit gemeinsam genutzten PCs, Terminals oder Frontline-Arbeitsplätzen. Windows Hello scheidet hier aus, weil sich biometrische Methoden nicht teilen lassen. Gut gefahren bin ich damit, in solchen Fällen FIDO2-Sicherheitsschlüssel an kleine Gruppen auszugeben. Oft genügt ein Schlüssel pro Schicht oder Tresen, sofern die Verantwortlichen dokumentiert sind und die Schlüssel physisch gesichert werden. Den Onboarding-Prozess sollte man unbedingt mit Temporary Access Pass (TAP) kombinieren. Damit lassen sich neue oder zurückgesetzte Konten phishingsicher aktivieren, ohne dass jemand das Initialpasswort kennt oder auf unsichere Verfahren wie SMS zurückgreifen muss (Schritt-für-Schritt-Anleitung).

Was in vielen Projekten unterschätzt wird, ist der Umgang mit geteilten Service- oder Funktionskonten. Wo immer es geht, sollte man sie auflösen oder durch persönliche Konten mit delegierten Berechtigungen ersetzen. Dabei helfen die neuen Möglichkeiten von Entra ID Workload Identities, die ich bereits im Beitrag [/blog/entra-id-workload-identities-managed-identities-vs-app-registrierungen] beschrieben habe.

Mein Tipp aus Projekten: FIDO2-Sticks für Frontline-Teams und gemeinsam genutzte Arbeitsplätze vorab als Pool beschaffen, zentral dokumentieren und die Ausgabe wie einen Hardware-Asset-Prozess behandeln. Das steigert die Akzeptanz und senkt den Supportaufwand, wenn ein Schlüssel verloren geht.

Über den Erfolg entscheiden Onboarding, Schulung und Akzeptanz

Die Technik ist das eine, der eigentliche Kraftakt ist das Onboarding. Wer MFA einfach „anschaltet“, geht in Support-Tickets unter. Bewährt haben sich bei mir gestufte Rollouts mit zuerst den Power-Usern, dann den Early Adopters und anschließend nach und nach der breiten Masse. Temporary Access Pass ist dabei das zentrale Werkzeug für die phishingsichere Ersteinrichtung und für Recovery-Szenarien, vor allem wenn Benutzer nicht vor Ort sind. Schulungen und kurze Videoanleitungen nehmen den Benutzern viel Unsicherheit. Admins und Support-Teams müssen auf jeden Fall wissen, wie sie Anmeldeprobleme analysieren und welche Recovery-Wege sicher sind.

Regelmäßige Messungen zeigen den tatsächlichen Stand der Umstellung

Den besten Überblick liefert das Entra-ID-Portal unter Authentifizierungsmethoden → Benutzerregistrierungsdetails. Dort sieht man, wie viele Nutzer bereits eine phishingsichere Methode eingerichtet haben. Man sollte allerdings im Hinterkopf behalten, dass die Zahlen alle eingerichteten Methoden abbilden und nicht nur die tatsächlich genutzten. Wer genau wissen will, welche Methoden für kritische Gruppen erzwungen werden, prüft am besten regelmäßig mit Conditional-Access-Berichten und Richtlinientests (What-If), ob alle Benutzergruppen wirklich wie geplant abgesichert sind. Noch genauer wird es mit einer Auswertung der Anmeldeprotokolle in Log Analytics (zur Anleitung), vorausgesetzt, Lizenzierung und Diagnostic Settings stimmen.

Auf dieser Grundlage kann man auch Quoten pro Zielgruppe festlegen, zum Beispiel „Bis Monatsende 80 % der Office-User mit Passkey oder Hello“. Wer regelmäßig misst, erkennt zudem Ausreißer und Gruppen, die an technischen oder organisatorischen Hürden hängen bleiben, und kann gezielt nachsteuern.

Ein schrittweiser Rollout ist nicht perfekt, aber praktikabel

Die vollständige Umstellung aller Nutzergruppen auf phishingsichere MFA ist selten ein schnelles Infrastrukturprojekt. Sie erfordert Geduld, Flexibilität bei den Methoden und ein gutes Zusammenspiel von Technik, Change Management und Support. Selbst die beste technische Lösung bringt wenig, wenn niemand das Onboarding mitdenkt und die Support-Prozesse nicht auf die neuen Methoden vorbereitet sind. Aus der Praxis rate ich zu einem sauberen Rollout für die wichtigsten Gruppen samt funktionierender Recovery-Prozesse statt zum „Big Bang“ für alle. Dazu gehören regelmäßige Auswertungen der Authentifizierungsdaten und Richtlinien. Wer so vorgeht, wird Schritt für Schritt deutlich widerstandsfähiger gegen moderne Phishing-Angriffe und legt gleichzeitig die Grundlage für eine sichere, passwortlose Zukunft.