Phishing-resistente MFA in Microsoft 365: FIDO2 und Passkeys für privilegierte Rollen
App-Push als zweiter Faktor war jahrelang der goldene Standard. Mit NIS2 §30 Bereich 10, BAIT, VAIT und der schärferen Aufsichts-Praxis ist das vorbei. Phishing-resistente MFA ist Pflicht für privilegierte Rollen. Dieser Artikel zeigt die drei Stufen und den Migrationspfad.
Was App-Push nicht mehr abfängt
Microsoft hat seit 2023 schrittweise umgestellt. Number Matching im Authenticator ist Default. Push-Notifications ohne Bestätigungszahl wurden im Februar 2024 deaktiviert. Diese Maßnahmen verhindern die einfachste Form von MFA-Fatigue-Angriffen, in denen Angreifer den User mit Push-Anfragen bombardieren, bis dieser eine versehentlich bestätigt.
Was sie nicht verhindern, sind Adversary-in-the-Middle-Phishing-Angriffe. Hier läuft die Phishing-Seite als Echtzeit-Proxy: User authentifiziert sich gegen die Phishing-Seite, die Anmeldung wird live an Microsoft weitergeleitet, der Number-Match-Code wird durchgereicht, der Angreifer erhält das Session-Token. Klassisches App-Push und auch Number Matching schützen davor nicht.
Phishing-resistente Authentifizierung schützt davor, weil sie kryptografisch an die Domain der echten Anmeldeseite gebunden ist. FIDO2 und Passkeys sind die zwei dominanten Implementierungen.
App-Push mit Number Matching für allgemeine User
Für die breite Masse der User in einem regulierten Unternehmen ist App-Push mit Number Matching ein vertretbares Niveau. Microsoft Authenticator zeigt eine zweistellige Zahl, die im Anmeldebildschirm bestätigt werden muss. MFA-Fatigue ist damit weitgehend eliminiert.
Was diese Stufe nicht abfängt: AiTM-Phishing. Wenn der User auf einen Phishing-Link klickt und seine Credentials plus Number Match auf der Phishing-Seite eingibt, kommt der Angreifer durch. Für Standard-User ohne Zugriff auf besonders sensible Daten ist das Restrisiko vertretbar, in einer Risikoanalyse aber zu dokumentieren.
Aktion: Number Matching im Authenticator-Tenant erzwingen, App-Push als Default-Authentifizierungsmethode für allgemeine User belassen, Phishing-Awareness-Training quartalsweise.
Authentication Strength mit Geo- und Device-Context
Conditional Access Authentication Strength erlaubt feinere Differenzierung. Die Strength "MFA + Compliant Device + Geo-Match" verhindert Login-Anomalien selbst dann, wenn die MFA-Antwort gegeben wird. Wenn der Login geographisch oder vom Device-Status nicht passt, wird er blockiert, unabhängig davon ob die MFA durchgeht.
Diese Stufe ist der typische Ansatz für sensible User-Gruppen wie HR, Finance und Geschäftsführungs-Assistenten. Sie kombiniert die Praxis-Tauglichkeit von App-Push mit der Risiko-Reduktion durch Kontext-Bedingungen.
Aktion: Authentication Strength Policy "MFA + Compliant Device + Geo-Match" definieren, sensible User-Gruppen identifizieren, Policy mit Conditional Access erzwingen.
FIDO2 oder Passkey für privilegierte Rollen
Hardware-gebundene, kryptografische Authentifizierung ist die einzige tatsächlich phishing-resistente Methode. FIDO2-Schlüssel (z.B. Yubikey, Feitian) und Passkeys (im Sinne von Platform Authenticators auf Apple-, Microsoft- oder Google-Geräten) erfüllen die Anforderung.
Die Bindung an die Origin-Domain (also https://login.microsoftonline.com) bedeutet: Eine Phishing-Seite kann den Schlüssel nicht abrufen, weil die kryptografische Antwort nur auf der echten Anmelde-Domain funktioniert. Für Global Admins, Privileged Role Admins, Security Admins, Tier-0-Accounts und Geschäftsführung ist das die einzige aufsichtskonforme Methode.
Aktion: FIDO2-Token für alle Tier-0-Accounts beschaffen, Authentication Strength "Phishing-resistent" in Conditional Access aktivieren, App-Push für diese Rollen sperren.
Rollout-Plan in 4 Phasen
Phase 1 (Woche 1 bis 2): Identifikation der Tier-0-Rollen. Global Admins, Privileged Role Admins, Security Admins, alle Accounts mit Berechtigungen über PIM-Eskalation. Liste pro Account dokumentieren.
Phase 2 (Woche 3): Token-Beschaffung. 50 bis 80 Euro pro FIDO2-Token, plus zwei Token pro Person (Primary und Backup). Bei Geschäftsführung und Vorstand zusätzlich Passkey-Optionen für Reise-Szenarien.
Phase 3 (Woche 4): Onboarding der Pilot-Gruppe. 30 Minuten User-Training pro Account. Token-Registrierung, Test der Anmeldung, Backup-Token registrieren, Recovery-Prozess durchspielen.
Phase 4 (Woche 5 bis 6): Conditional Access Policy erzwingen, App-Push für diese Rollen sperren, Reporting nach 30 Tagen.
Aktion: Rollout-Plan mit Phasen 1 bis 4 in Projekt-Tracker anlegen, Token-Bedarf pro Rolle berechnen, Recovery-Prozess in Tenant-Doku festschreiben.
Was die Audit-Praxis tatsächlich prüft
NIS2-Reviews fragen seit Anfang 2026 explizit nach Phishing-Resistenz für privilegierte Rollen. Die typische Frage: "Zeigen Sie uns die Authentication Strength Policy, die für Global Admins gilt." Wer keine hat oder eine, die App-Push erlaubt, schreibt eine Auflage.
BAIT- und VAIT-Audits prüfen die Phishing-Resistenz seit 2025 in vergleichbarer Tiefe. Bei DORA wird die Anforderung über Artikel 4 der RTS zu ICT-Risikomanagement transportiert. In allen drei Aufsichtsregimen ist die Erwartung gleich: Tier-0 mit FIDO2 oder Passkey, Restrisiko dokumentiert.
Aktion: Authentication Strength Policy mit Begründung im Compliance-Register dokumentieren, Liste der Tier-0-Accounts mit Token-Status pflegen, jährliches Review.
Faustregel: Phishing-resistente MFA ist keine Option für 2027. Sie ist die Aufsichts-Erwartung für 2026. Wer Tier-0-Accounts noch mit App-Push schützt, schreibt im nächsten Audit eine Auflage.
Die Migration auf FIDO2 ist eines der Projekte mit dem höchsten Risiko-Reduktions-Effekt pro investiertem Euro. 50 bis 80 Euro pro Token plus 30 Minuten User-Onboarding für jeden privilegierten Account. Im Vergleich zu einem erfolgreichen AiTM-Angriff auf einen Global Admin ist das eine triviale Investition.
Microsoft 365 Compliance Check
In 5 Tagen prüfen wir Ihre Identity-Posture: Conditional Access, MFA-Methoden, PIM, Tier-0-Accounts. Plus: priorisierter Plan zur Migration auf phishing-resistente Authentifizierung.
Zum Compliance Check