MFA in Microsoft 365 einführen: Checkliste für den Rollout ohne Aussperren

Bei der Multi-Faktor-Authentifizierung (MFA) genügt das Passwort allein nicht. Die Faktoren stammen laut BSI aus verschiedenen Kategorien: Wissen (etwa Passwort oder PIN), Besitz (etwa Chipkarte, USB-Token oder Smartphone) oder Biometrie (etwa Fingerabdruck). Die US-Behörde CISA empfiehlt MFA für alle Benutzer und Dienste und nennt phishingresistente MFA den Goldstandard; jede MFA sei aber besser als keine.

§ 32 NISG 2026 verlangt geeignete und verhältnismäßige Maßnahmen (Abs. 1 bis 3). Die NISV 2026 (BGBl. II Nr. 290/2026) erstreckt in § 2 den Anhang der Durchführungsverordnung (EU) 2024/2690 auf alle wesentlichen und wichtigen Einrichtungen: Nutzer sind, soweit angemessen und je nach Klassifizierung der Werte, mit mehreren Faktoren oder kontinuierlich zu authentifizieren (Anhang Nr. 11.7.1). Ein bestimmtes Verfahren schreiben beide nicht vor. Wer als wesentliche oder wichtige Einrichtung gilt, regeln §§ 24 bis 26. § 32 gilt seit 1. Oktober 2026 (§ 51 Abs. 2; kundgemacht am 23.12.2025).

• Lizenz geklärt: Conditional Access setzt Microsoft Entra ID P1 oder P2 voraus; ohne diese Lizenz aktivieren Sie die Sicherheitsstandards.
• Status der Sicherheitsstandards geprüft (Entra ID > Übersicht > Eigenschaften > Sicherheitsstandards verwalten). Microsoft aktiviert sie auch selbst, wenn ein Mandant weder Richtlinien für bedingten Zugriff noch Premium-Lizenzen noch aktiv genutzte Legacy-Clients hat.
• Vorhandene Richtlinien für bedingten Zugriff erfasst. Wer die Sicherheitsstandards durch eigene Richtlinien ersetzt, muss sie deaktivieren und sofort passende Richtlinien aktivieren.
• Alte MFA pro Benutzer (per-user MFA) erfasst; sie wird nach der Umstellung auf Conditional Access manuell deaktiviert (Schritt 5).
• Sonderkonten erfasst: Administratorkonten samt Rollen, Benutzerkonten, mit denen Skripte laufen, und bei hybrider Identität das Synchronisierungskonto von Entra Connect oder Cloud Sync.

Notfallzugriffskonten (Break-Glass-Konten) verhindern, dass Sie sich durch eine fehlerhafte Richtlinie, einen Ausfall des Identitätsverbunds oder unerreichbare MFA-Geräte aus dem Mandanten aussperren. Die Punkte folgen Microsoft Learn, gelesen am 25. Oktober 2026.

• Mindestens zwei Konten nur in der Cloud, mit der Domäne *.onmicrosoft.com, weder im Verbund noch aus dem lokalen Active Directory synchronisiert.
• Rolle Globaler Administrator dauerhaft aktiv zugewiesen, in Privileged Identity Management nicht nur berechtigt.
• Anmeldung mit Passkey (FIDO2), von Microsoft empfohlen, oder mit zertifikatbasierter Authentifizierung, wenn bereits eine PKI besteht; mit einer anderen Methode als die normalen Administratorkonten. Anmeldedaten und Geräte laufen nicht ab und fallen nicht unter eine automatische Bereinigung.
• Keiner einzelnen Person und keinem Telefon von Mitarbeitenden zugeordnet; Schlüssel und Anmeldedaten an getrennten, sicheren, feuerfesten Orten; Nutzung nur von einer dafür vorgesehenen, sicheren Arbeitsstation.
• Aus allen Richtlinien für bedingten Zugriff ausgeschlossen, die die Anmeldung blockieren oder einschränken, am besten über eine eigene Gruppe. Richtlinien im Modus „Nur Bericht“ blockieren nicht und brauchen keinen Ausschluss.
• Jede Anmeldung löst eine Benachrichtigung aus; jede Nutzung wird anhand der Protokolle nachbesprochen.
• Mindestens alle 90 Tage und nach Personalwechseln in der IT getestet: Anmeldung, Verwaltungsaufgaben, Liste der berechtigten Personen, dokumentierter Ablauf.

Der Ausschluss aus Ihren Richtlinien befreit nicht von der verpflichtenden MFA, die Microsoft für Azure und die Admin-Portale durchsetzt; sie gilt ausdrücklich auch für Notfallzugriffskonten. Passkey (FIDO2) und zertifikatbasierte Authentifizierung erfüllen sie.

• Zielbild: phishingresistent für Administratoren und gefährdete Konten, sonst mindestens Authenticator mit Zahlenabgleich; SMS und Anruf nur befristet; je Person zwei Methoden.

Ohne Microsoft Entra ID Protection werden Personen bei der nächsten Anmeldung, die MFA verlangt, zur Registrierung aufgefordert. Mit einem bereits gestohlenen Passwort könnte dann ein Angreifer seine eigene Methode registrieren. Microsoft empfiehlt deshalb, die Registrierung per Conditional Access an vertrauenswürdige Geräte und Standorte zu binden; zusätzlich lässt sich ein befristeter Zugriffspass (TAP) verlangen, ein zeitlich begrenzter Code von der Administration. Unter Sicherheitsstandards gibt es seit 29. Juli 2024 keine 14-tägige Schonfrist für die Registrierung mehr.

• Termine festgelegt: Pilot, Wellen, Stichtag für die Registrierung; Helpdesk und Vertretung eingeplant.
• Mitarbeitende rechtzeitig informiert, was sich ändert, was sie tun müssen und bis wann; Microsoft stellt Kommunikationsvorlagen bereit (aka.ms/mfatemplates).
• Ablauf bei Verlust oder Wechsel des Smartphones festgelegt: befristeter Zugriffspass oder Pflege der Methoden durch die Administration.
• Nach dem Aktivieren der Sicherheitsstandards bestehende Sitzungen widerrufen, etwa per Revoke-MgUserSignInSession, damit sich alle neu anmelden und registrieren.

Mustertext zum Anpassen. Die Verhaltenshinweise empfiehlt TOMORIS, weil CISA Angriffe mit gehäuften Push-Anfragen (Push Bombing) und Phishing-Seiten für Passwort und Einmalcode beschreibt: „Ab [Datum] bestätigen Sie jede Anmeldung bei Microsoft 365 zusätzlich mit [Microsoft Authenticator oder Passkey]. Bitte richten Sie die Methode bis [Datum] unter https://myprofile.microsoft.com im Bereich Sicherheitsinformationen ein, wenn möglich auch eine zweite. Bestätigen Sie nur Anmeldungen, die Sie gerade selbst durchführen; unerwartete Anfragen lehnen Sie ab und melden sie an [Name, Funktion, Telefon]. Wir fragen Sie nie per Telefon oder E-Mail nach einem Code. Ist Ihr Smartphone verloren, melden Sie sich sofort bei [Kontakt].“

1. 1

   Pilotgruppe bestimmen und registrieren lassen

   Beginnen Sie mit einer kleinen Gruppe, etwa der IT selbst, und aktivieren Sie die gewählten Methoden. Danach erweitern Sie in Wellen, die Ihr Support bewältigen kann.

2. 2

   Richtlinie „MFA für alle“ anlegen

   Einschließen: zuerst die Pilotgruppe, im Endausbau Alle Benutzer. Ausschließen: Notfallzugriffskonten, bei hybrider Identität die Rolle Directory-Synchronisierungskonten. Zielressourcen: Alle Ressourcen. Erteilen: Authentifizierungsstärke Multi-Faktor-Authentifizierung. Richtlinie aktivieren: Nur Bericht (Report-only).

3. 3

   Wirkung prüfen

   Im Modus „Nur Bericht“ blockiert die Richtlinie nichts, zeigt aber, wen sie treffen würde. Prüfen Sie Richtlinienauswirkung und Anmeldeprotokolle.

4. 4

   Einschalten, erweitern, aufräumen

   Stellen Sie die Richtlinie auf „Ein“ und nehmen Sie Welle für Welle weitere Gruppen auf, bis sie für alle gilt. Danach deaktivieren Sie die alte MFA pro Benutzer manuell, wie Microsoft es empfiehlt.

Sicherheitsstandards kennen keinen Testmodus, nur Ein oder Aus für den ganzen Mandanten. Informieren Sie vorher alle und stellen Sie sicher, dass Administratoren keine älteren Authentifizierungsprotokolle verwenden, wie Microsoft es verlangt. Deaktivieren Sie unter Sicherheitsstandards keine Methoden: Microsoft warnt, dass Sie sich damit aussperren können.

Legacy-Authentifizierung nennt Microsoft Anmeldungen von Clients ohne moderne Authentifizierung, etwa Office 2010, und über ältere E-Mail-Protokolle wie IMAP, SMTP oder POP3. Sie unterstützt keine MFA, ein Angreifer kann eine MFA-Richtlinie damit umgehen. Nach Microsofts Analyse nutzen mehr als 97 Prozent der Credential-Stuffing- und mehr als 99 Prozent der Password-Spray-Angriffe Legacy-Authentifizierung.

1. 1

   Nutzung ermitteln

   Entra ID > Monitoring & health > Anmeldeprotokolle: Spalte Client-App einblenden und nach allen älteren Authentifizierungsprotokollen filtern, auch auf der Registerkarte für nicht interaktive Anmeldungen. Betroffene Clients umstellen oder ersetzen.

2. 2

   Blockieren, erst im Modus „Nur Bericht“

   Alle Benutzer, Alle Ressourcen, Bedingungen > Client-Apps: nur Exchange ActiveSync-Clients und Andere Clients; Erteilen: Zugriff blockieren. Ausschließen nur Konten, die Legacy-Authentifizierung noch brauchen; Microsoft empfiehlt, mindestens ein Konto auszuschließen, um sich bei einem Fehler nicht auszusperren. Nach Prüfung auf „Ein“ stellen, Ausnahmen abbauen.

Sicherheitsstandards blockieren Legacy-Authentifizierung, die Standardauthentifizierung für Exchange ActiveSync und den Gerätecodefluss; für neue Mandanten gilt die Sperre des Gerätecodeflusses seit 1. Juli 2026.

Wer ein Administratorkonto übernimmt, erreicht oft jedes System und alle Daten. CISA fordert Administratoren und andere besonders wertvolle Ziele deshalb auf, phishingresistente MFA einzuführen oder die Umstellung zu planen, beginnend mit Helpdesk und IT-Administration. Conditional Access bietet dafür die integrierte Authentifizierungsstärke „Phishingresistente MFA“. Als Rollen eignen sich jene, für die schon die Sicherheitsstandards MFA bei jeder Anmeldung verlangen, etwa Global Administrator, Privileged Role Administrator, Security Administrator, Exchange Administrator und User Administrator.

• Getrennte Konten für Verwaltung und tägliche Arbeit; das senkt auch die Zahl der MFA-Abfragen (Microsoft).
• Alle mit Admin-Rolle haben eine phishingresistente Methode registriert, etwa einen Passkey mit Hilfe eines befristeten Zugriffspasses, und die Notfallzugriffskonten sind getestet, bevor die Richtlinie greift; sonst sperren Sie Administratoren aus.
• Richtlinie (Empfehlung von TOMORIS): Verzeichnisrollen einschließen, Notfallzugriffskonten ausschließen, Alle Ressourcen, Authentifizierungsstärke „Phishingresistente MFA“, zuerst „Nur Bericht“.
• Danach weitere gefährdete Gruppen, etwa Personal- oder Rechtsabteilung mit weitreichenden Leserechten; Systeme ohne MFA-Unterstützung der Geschäftsleitung als Risiko melden und ablösen (CISA).

Unabhängig von Ihren Richtlinien verlangt Microsoft MFA für die Verwaltung über Azure und die Admin-Portale. Die Phasen und Termine stammen von Microsoft Learn, gelesen am 25. Oktober 2026.

• Gilt für alle Benutzerkonten, auch für Notfallzugriffskonten, Administratoren mit berechtigten Rollen und Testmandanten. Ausschlüsse in Ihren Richtlinien wirken nicht, ein Opt-out gibt es nicht; auch „Angemeldet bleiben“ befreit nicht.
• Nicht betroffen sind Workload-Identitäten wie verwaltete Identitäten und Dienstprinzipale sowie das Synchronisierungskonto von Entra Connect oder Cloud Sync. Benutzerkonten, mit denen Skripte laufen, müssen MFA erfüllen; Microsoft empfiehlt den Umstieg auf Workload-Identitäten.
• Anmeldungen per ROPC (Benutzername und Kennwort über OAuth) sind mit MFA nicht vereinbar; Azure CLI ab 2.76 und Azure PowerShell ab 14.3 verwenden.
• Status prüfen als Global Administrator unter aka.ms/managemfaforazure (Phase 1) und aka.ms/postponePhase2MFA (Phase 2).

Die verpflichtende MFA ersetzt keine eigene Richtlinie: Sie gilt nur für die genannten Anwendungen. E-Mail, Teams und alle anderen Anwendungen sichern Sie mit Sicherheitsstandards oder Conditional Access ab.

• Registrierung und Nutzung der Methoden regelmäßig im Dashboard „Authentifizierungsmethodenaktivität“ geprüft; Personen mit SMS oder Anruf schrittweise auf Microsoft Authenticator oder sicherere Methoden umgestellt.
• Anmeldeprotokolle ausgewertet: Sie zeigen, wann MFA verlangt wurde und welche Richtlinien für bedingten Zugriff griffen; bei der verpflichtenden MFA nennen sie die Anwendung, die MFA erzwungen hat.
• Legacy-Anmeldungen (Spalte Client-App) gegengeprüft; Ausschlüsse aus Richtlinien dokumentiert, begründet und abgebaut.
• Notfallzugriffskonten mindestens alle 90 Tage getestet; neue Mitarbeitende registrieren ihre Methoden beim Eintritt, etwa mit befristetem Zugriffspass.

Häufige Fehler: kein oder nur ein Notfallzugriffskonto; Richtlinien sofort auf „Ein“ statt „Nur Bericht“; phishingresistente MFA vor der Registrierung erzwungen; unter Sicherheitsstandards Methoden deaktiviert; Legacy-Authentifizierung blockiert, ohne Scanner und Altanwendungen zu erfassen; Skripte unter Benutzerkonten; nur eine Methode je Person.