MFA in Microsoft 365 erzwingen

Wenn du in Microsoft 365 nur eine einzige Sache richtig machst, dann diese: Multi-Faktor-Authentifizierung (MFA) für alle Konten erzwingen. Kein anderer Hebel senkt das Risiko einer Kontoübernahme so stark bei so geringem Aufwand. Dieser Leitfaden zeigt, wie MSPs MFA sauber ausrollen – über Security Defaults oder Conditional Access, mit Break-Glass-Konto und messbarer Abdeckung über viele Kunden-Tenants.

Warum MFA die wichtigste Einzelmaßnahme ist

Der häufigste Weg in einen Microsoft-365-Tenant ist kein ausgeklügelter Exploit, sondern ein gestohlenes Passwort – aus Phishing, Password-Spray oder einem Datenleck. Ein reines Passwort ist ein einzelner Faktor: Wer es kennt, ist drin. MFA verlangt einen zweiten Nachweis (App, FIDO2-Schlüssel, Passkey) und macht ein gestohlenes Passwort allein wertlos. Genau deshalb beginnt fast jede verdächtige Anmeldung, die real zum Schaden führt, bei einem Konto ohne zweiten Faktor.

Zwei Wege, MFA in Microsoft 365 zu erzwingen

Security Defaults – der kostenlose Basisschutz

Security Defaults sind ein pauschaler Schutz, der in jedem Tenant ohne Zusatzlizenz aktiviert werden kann. Sie erzwingen MFA für alle Nutzer, verlangen sie besonders für Administratoren und blockieren die veraltete Legacy-Authentifizierung. Für kleine Kunden ohne Sonderanforderungen sind sie oft schon die richtige Antwort: an, fertig, geschützt.

Ihr Nachteil ist die fehlende Feinsteuerung. Security Defaults kennen keine Ausnahmen, keine Standort- oder Gerätebedingungen und kein sauber ausgenommenes Break-Glass-Konto. Sobald ein Kunde solche Anforderungen hat, stoßen sie an ihre Grenze.

Conditional Access – granulare Steuerung mit Entra ID P1

Für differenzierte Regeln führt der Weg über Conditional Access. Frei konfigurierbare Richtlinien setzen mindestens Entra ID P1 beim Kunden voraus; risikobasierte Richtlinien (Sign-in-Risk über Identity Protection) benötigen Entra ID P2. Mit P1 lässt sich MFA gezielt erzwingen – etwa für alle Nutzer, mit Ausnahme des Break-Glass-Kontos, kombiniert mit einem Block für Legacy-Auth. Wie das zusammenspielt, vertieft der Leitfaden zu Conditional Access in Microsoft 365.

Wichtig: Neue Richtlinien immer zuerst im Report-Only-Modus testen. Er zeigt, wie eine Regel greifen würde, ohne echte Nutzer real auszusperren.

Ausnahmen und das Break-Glass-Konto

Jede MFA-Erzwingung braucht genau eine bewusste Ausnahme: das Break-Glass-Konto (Notfallzugang). Es bleibt von der MFA-Richtlinie ausgenommen, damit ein Ausfall des MFA-Dienstes oder eine fehlerhafte Richtlinie euch nicht komplett aussperrt. Der Preis dafür ist strenge Absicherung an anderer Stelle:

• ein sehr langes, einzigartiges Passwort, offline und sicher hinterlegt;
• keine alltägliche Nutzung – jede Anmeldung ist ein Ereignis;
• enge Überwachung: Alarm bei jeder Anmeldung dieses Kontos.

Andere „Ausnahmen“ – Dienstkonten, Chef-Postfächer, „nur kurz“ – sind fast immer ein Fehler. Jede dauerhafte Ausnahme ist genau das Konto, über das der nächste Angriff läuft.

MFA über viele Kunden-Tenants ausrollen

Bei einem Tenant ist MFA ein Nachmittag. Über zwanzig oder fünfzig Kunden wird daraus ein Projekt – und ein Drift-Problem. So bleibt der Rollout beherrschbar:

• Standardvorgehen definieren: pro Kunde die gleiche Zielkonfiguration (Security Defaults oder eine feste CA-Baseline), damit kein Tenant zum Sonderfall wird.
• Registrierung planen: Nutzer müssen ihre MFA-Methode aktiv einrichten. Ein Registrierungsfenster mit Erinnerung verhindert Support-Wellen am Stichtag.
• Legacy-Auth zuerst schließen: Solange alte Protokolle offen sind, umgeht ein Angreifer MFA komplett – der Block gehört an den Anfang, nicht ans Ende.
• Break-Glass zuerst anlegen: bevor die Richtlinie scharf geht, nicht danach.

Dieselbe Zielkonfiguration über alle Kunden ist nichts anderes als eine Sicherheits-Baseline über mehrere Mandanten – MFA ist ihr wichtigster Einzel-Check.

MFA-Abdeckung messen statt vermuten

Eine aktivierte Richtlinie ist nicht dasselbe wie tatsächlich geschützte Nutzer. Entscheidend ist der Registrierungsstatus je Nutzer: Wer hat eine starke Methode eingerichtet, wer hängt noch bei „nur Passwort“? Ohne diese Sicht bleibt ein einzelnes ungeschütztes Konto unbemerkt – und genau das reicht für eine Übernahme. Über viele Mandanten verteilt fällt so eine Lücke ohne zentrale Auswertung praktisch nie auf.

Wie TenantSecure den MFA-Status zeigt

TenantSecure liest den MFA-Status je Nutzer aus und lässt ihn in den Härtungs-Score jedes Mandanten einfließen. Statt fünfzig Portale einzeln zu prüfen, siehst du über dein ganzes Portfolio, welche Kunden ungeschützte Konten haben und wo die Abdeckung lückenhaft ist. Zusammen mit den Checks für Legacy-Auth und Conditional Access ergibt das ein ehrliches Bild: Fehlt beim Kunden die passende Entra-ID-Lizenz für einen Check, zeigt TenantSecure „Unbekannt“ statt eines geschönten Grüns. Wie der Score entsteht, steht in der Doku zu Härtung und Score.

Mit TenantSecure

TenantSecure macht die MFA-Abdeckung über alle deine Mandanten messbar und zeigt ungeschützte Konten, bevor sie zum Vorfall werden – ohne Tenant-Hopping. Am schnellsten siehst du das an einem echten Beispiel: die Live-Demo ansehen. Ist ein Konto trotz MFA einmal übernommen, hilft der Leitfaden Microsoft 365 kompromittiert – was tun?