Microsoft 365 absichern: MFA-Pflicht richtig einordnen

Kaum ein Thema wird in Microsoft-365-Umgebungen so zuverlässig missverstanden wie die MFA-Pflicht. In Gesprächen fällt regelmäßig der Satz „Microsoft zwingt uns ja jetzt sowieso alle zu MFA“ – und daraus wird der Schluss gezogen, das Thema sei erledigt.

Es ist nicht erledigt. Was Microsoft technisch erzwingt, ist deutlich schmaler als der allgemeine Eindruck, und es deckt genau die Konten nicht ab, über die in der Praxis die meisten Vorfälle laufen. Dieser Beitrag trennt beides sauber: erst, was Microsoft von sich aus durchsetzt, dann, was Sie selbst entscheiden und konfigurieren müssen.

Microsofts MFA-Pflicht gilt der Azure- und Entra-Verwaltung, nicht jedem Postfach

Microsoft setzt MFA in zwei Phasen systemseitig durch. Ein Opt-out gibt es nicht – auf die Frage „Will I be able to opt out?“ antwortet die Dokumentation: „There’s no way to opt out.“

Phase 1 läuft seit Oktober 2024. Sie betrifft Konten, die sich am Azure-Portal, am Microsoft Entra Admin Center und am Microsoft Intune Admin Center anmelden, und zwar für jede Lese-, Erstell-, Änderungs- und Löschoperation. Seit Februar 2025 ist das Microsoft 365 Admin Center einbezogen (admin.microsoft.com, admin.cloud.microsoft, portal.office.com/adminportal/home).

Phase 2 läuft seit dem 1. Oktober 2025. Sie betrifft den programmatischen Zugriff auf Azure: Azure CLI, Azure PowerShell, die Azure-Mobile-App, Infrastructure-as-Code-Werkzeuge, das Azure SDK und die REST-API der Control Plane. Erfasst sind Erstellen, Ändern und Löschen – „Read operations won’t require MFA.“ Serverseitig zieht Microsoft die Grenze bei der Zieladresse: Betroffen sind Anfragen an https://management.azure.com/.

Und hier steht der Satz, auf den es ankommt:

„Users aren’t required to use MFA if they access other applications, websites, or services hosted on Azure.“

Die Mitarbeiterin, die morgens Outlook öffnet, in Teams telefoniert und eine Datei in SharePoint ablegt, wird von dieser Durchsetzung nicht erfasst. Ob sie MFA verwendet, entscheidet Ihre eigene Konfiguration – nicht Microsoft.

Was in den Anwendungsbereich fällt und was ausdrücklich draußen bleibt

Vier Punkte werden regelmäßig falsch angenommen:

Notfall- und Break-Glass-Konten sind erfasst. Die Ausnahme, die viele Administratoren gerade für diese Konten eingerichtet haben, greift nicht: „The system enforcement applies to all user accounts, regardless if they are a student account, break-glass account, an administrator account […] or any user exclusions that are enabled for them.“ Microsoft empfiehlt für diese Konten Passkey (FIDO2) oder zertifikatsbasierte Authentifizierung – beides erfüllt die MFA-Anforderung, ohne von einem Mobiltelefon abzuhängen.
Test- und Entwicklungs-Tenants sind erfasst. Wörtlich: „every Azure tenant will require MFA, with no exception for test environments.“
Workload-Identitäten sind nicht erfasst. Managed Identities und Service Principals bleiben außen vor. Benutzerkonten, die als Dienstkonto für Automatisierung missbraucht werden, sind dagegen sehr wohl erfasst – diese gehören migriert, nicht mit einer Ausnahme versehen.
Microsoft Graph ist in der Regel nicht erfasst. „Generally, Microsoft Graph APIs aren’t in scope for Azure MFA enforcement.“ Ebenso wenig betroffen ist das Synchronisierungskonto von Entra Connect beziehungsweise Cloud Sync. Und die Durchsetzung gilt nur für die öffentliche Azure-Cloud, nicht für Azure for US Government oder andere souveräne Clouds.

Ein technischer Nebeneffekt, der Automatisierungen zum Stillstand bringen kann: Der ROPC-Flow (Anmeldung mit Benutzername und Passwort im Code) ist mit MFA unvereinbar und wirft nach Aktivierung Ausnahmen. Wer noch Skripte mit hinterlegten Zugangsdaten betreibt, sollte diese vor der Durchsetzung finden – nicht danach.

Aufschieben ist möglich, aber nur bis zum 1. Juli 2026

Microsoft räumt Umgebungen mit komplexen Abhängigkeiten eine Verschiebung ein. Für Phase 1 war das bis zum 30. September 2025 möglich – dieses Fenster ist geschlossen. Für Phase 2 kann ein globaler Administrator den Beginn der Durchsetzung bis zum 1. Juli 2026 verschieben.

Das ist eine Frist zum Vorbereiten, keine Lösung. Wer sie nutzt, sollte sie mit einem konkreten Plan hinterlegen: betroffene Konten identifizieren, benutzerbasierte Dienstkonten auf Workload-Identitäten migrieren, Break-Glass-Konten auf Passkeys umstellen, Client-Versionen aktualisieren (Azure CLI ab 2.76, Azure PowerShell ab 14.3). Ohne diesen Plan verschiebt der Aufschub nur den Ausfall.

Stand 3. August 2026: Das Aufschubfenster ist geschlossen

Ergänzung nach der Erstveröffentlichung: Die Möglichkeit, den Beginn der Phase-2-Durchsetzung zu verschieben, ist am 1. Juli 2026 ausgelaufen. Nach Beginn der Durchsetzung lässt sich nur noch über eine Anfrage bei Microsoft Help and Support eine befristete Aussetzung erwirken, und auch das nur durch einen globalen Administrator.

Ebenfalls seit dem 1. Juli 2026 blockieren die Sicherheitsstandards in allen neu angelegten Entra-Tenants zusätzlich den Device-Code-Flow. Geräte oder Anwendungen, die auf dieses Anmeldeverfahren angewiesen sind, können sich in solchen Tenants nicht mehr anmelden, solange die Sicherheitsstandards aktiv sind.

Was Microsoft erzwingt, ist ein Minimum – MFA für alle Konten bleibt unsere Empfehlung

Die Durchsetzung schützt die Verwaltungsebene. Sie schützt nicht das Postfach, über das die Rechnung mit geänderter Bankverbindung verschickt wird, und nicht das Konto, aus dem ein Angreifer die interne Adressliste zieht. Microsoft formuliert das in der Dokumentation zu den Sicherheitsstandards selbst: „We tend to think that administrator accounts are the only accounts that need extra layers of authentication. […] But attackers frequently target end users.“

Unsere Empfehlung geht deshalb über die Pflicht hinaus: MFA für alle produktiven Benutzerkonten. Sie ist auch der erste Punkt, den wir in einem IT-Sicherheitscheck prüfen, weil kein anderer Einzelschritt bei vergleichbarem Aufwand so viel Risiko nimmt. Dafür gibt es zwei Wege.

Sicherheitsstandards („Security defaults“) sind kostenlos und in jeder Lizenzstufe verfügbar. Sie verlangen von allen Benutzern die Registrierung für MFA, fordern MFA von Administratoren bei jeder Anmeldung, blockieren veraltete Authentifizierungsprotokolle und schützen den Zugriff auf Azure Resource Manager. In Tenants, die ab dem 22. Oktober 2019 angelegt wurden, sind sie möglicherweise bereits aktiv. Der Preis dieser Einfachheit: Sie lassen sich nicht anpassen – nur ein- oder ausschalten.

Bedingter Zugriff („Conditional Access“) erlaubt differenzierte Regeln, setzt aber mindestens eine Microsoft-Entra-ID-P1-Lizenz voraus. Das ist eine reale Kostenentscheidung, die wir nicht kleinreden: Für viele kleinere Organisationen sind die Sicherheitsstandards die richtige Wahl, und ein Wechsel zu bedingtem Zugriff lohnt erst, wenn tatsächlich Ausnahmen nach Standort, Gerät oder Anwendung nötig werden. Wer die Sicherheitsstandards deaktiviert, ohne sofort entsprechende Richtlinien für bedingten Zugriff zu aktivieren, steht schlechter da als vorher.

Für Unternehmen, die unter NIS-2 fallen, ist die Sache ohnehin entschieden: Multi-Faktor-Authentifizierung ist in § 30 Absatz 2 Nummer 10 BSIG als eigener Maßnahmenbereich benannt. Was das insgesamt bedeutet, haben wir in unserem Beitrag zu NIS-2 in Deutschland ausgeführt.

Getrennte Administratorkonten kosten wenig und verhindern viel

Ein globales Administratorkonto, mit dem täglich E-Mails gelesen und im Web recherchiert wird, verbindet die höchste Berechtigung mit der höchsten Angriffsfläche. Microsoft empfiehlt in derselben Dokumentation ausdrücklich getrennte Konten für Administration und normale Arbeit.

Ein tragfähiges Rollenkonzept beantwortet:

Wer benötigt welche administrative Rolle – und reicht eine spezialisierte Rolle statt der globalen?
Welche Konten sind rein administrativ und ohne Postfach im Alltag?
Wer darf administrative Rollen überhaupt vergeben?
Wie viele globale Administratoren gibt es tatsächlich, und wann wurde das zuletzt geprüft?
Existieren zwei reine Cloud-Notfallkonten, getrennt von allen Personen und Prozessen?

Microsoft empfiehlt für den Notfall zwei dauerhaft mit der Rolle „Globaler Administrator“ ausgestattete Cloud-Konten, die keiner konkreten Person zugeordnet sind. Beide brauchen MFA – siehe oben – und beide gehören dokumentiert, inklusive der Frage, wer im Ernstfall an die Zugangsdaten kommt.

Berechtigungen gehören an Gruppen und benannte Eigentümer

Einzelfreigaben sind schnell vergeben und praktisch nie wieder auffindbar. Wer Zugriffe über nachvollziehbare Gruppen und Rollen vergibt, kann sie auch wieder entziehen.

Für jede Gruppe, jedes Team und jede SharePoint-Site sollte beantwortet sein: Welche Rolle oder Abteilung braucht Zugriff, wer genehmigt die Mitgliedschaft, wer ist Eigentümer, wann werden die Mitglieder überprüft, und wie werden externe Gäste behandelt? Ein Team ohne benannten Eigentümer ist ein Team, dessen Berechtigungen niemand mehr aufräumt.

Dass eine Datei technisch mit „Jeder mit dem Link“ geteilt werden kann, heißt nicht, dass dieser Weg für jede Information angemessen ist.

Der Benutzer-Lebenszyklus entscheidet, wie viele verwaiste Konten Sie haben

Ein Konto entsteht beim Eintritt, verändert sich bei Rollenwechseln und muss beim Austritt kontrolliert behandelt werden. Der Übergang ist der Punkt, an dem in der Praxis am meisten liegen bleibt: Beim Eintritt achtet jeder auf Vollständigkeit, beim Austritt oft nur auf die Lizenz.

Ein sauberer Prozess umfasst Namens- und Kontoregeln, Lizenzzuweisung, Gruppenmitgliedschaften, MFA-Einrichtung, Geräte und aktive Sitzungen, die Übergabe geschäftlicher Daten, die Deaktivierung zum richtigen Zeitpunkt, den Entzug nicht mehr benötigter Rechte – und eine Dokumentation, die das alles nachvollziehbar macht.

Besonders kritisch sind drei Gruppen: Konten ehemaliger Mitarbeiter, externe Gäste aus abgeschlossenen Projekten und Dienstkonten, die niemand mehr aktiv verwaltet.

Externe Freigaben brauchen Regeln, keine pauschale Sperre

Externe Zusammenarbeit ist ein echter Vorteil der Plattform, und eine vollständige Sperre schafft vor allem Umgehungswege über private Konten und fremde Dateidienste. Sinnvoll ist ein bewusst gesetzter Rahmen: Wer darf Gäste einladen, welche Organisationen sind zugelassen, sind anonyme Links erlaubt, wie lange bleiben Freigaben gültig, wer prüft sie nach, und welche Bereiche sind von externer Freigabe grundsätzlich ausgenommen?

Gästekonten aus B2B-Zusammenarbeit unterliegen im Übrigen ebenfalls der MFA-Durchsetzung, wenn sie Verwaltungsoperationen ausführen – entweder aus dem Ressourcen-Tenant heraus oder über korrekt konfigurierte MFA-Claims aus ihrem Heimat-Tenant.

OneDrive, SharePoint und Teams speichern unterschiedlich, und das hat Folgen

Im Alltag verschwimmen die Grenzen, technisch bleiben sie bestehen: OneDrive ist der persönliche Arbeitsbereich eines Benutzers, SharePoint stellt gemeinsame Inhalte und Strukturen bereit, und Teams legt seine Dateien im Hintergrund in SharePoint ab.

Wenn zentrale Abteilungsunterlagen ausschließlich im persönlichen OneDrive einer Person liegen, entsteht bei Krankheit, Urlaub oder Austritt ein vermeidbares Problem – und beim Löschen des Kontos ein größeres. Legen Sie fest, welche Daten persönlich, welche im Team und welche in einer zentralen Ablage gehören, und richten Sie die Struktur danach ein, statt sie wachsen zu lassen.

Aufbewahrung in der Cloud ist keine unabhängige Datensicherung

Versionen, Papierkörbe, Aufbewahrungsrichtlinien und hohe Verfügbarkeit sind wertvoll. Sie beantworten aber nicht jede Anforderung an eine unabhängige Sicherung, insbesondere nicht bei absichtlicher Löschung durch ein kompromittiertes Konto mit weitreichenden Rechten.

Zu klären ist: Welche Daten müssen über welchen Zeitraum wiederherstellbar sein? Was passiert bei versehentlicher oder absichtlicher Löschung nach Ablauf des Papierkorbs? Lassen sich einzelne Postfächer, Dateien oder Sites gezielt zurückholen? Wer bemerkt einen fehlgeschlagenen Sicherungslauf? Und wann wurde eine Wiederherstellung zuletzt tatsächlich durchgeführt?

Ob ein zusätzliches SaaS-Backup nötig ist, hängt von Risiko, Aufbewahrungspflichten und Geschäftsanforderung ab. Es gibt Umgebungen, in denen die eingebauten Funktionen ausreichen – dann brauchen Sie uns dafür nicht. Wichtig ist, dass die Entscheidung bewusst getroffen und dokumentiert wird, statt unausgesprochen zu bleiben. Wie sich das mit dem übrigen Betrieb der IT-Infrastruktur verzahnt, hängt davon ab, was neben Microsoft 365 noch läuft.

Ohne festen Prüfzyklus driftet jede saubere Einrichtung

Benutzer, Gruppen, Teams und Freigaben verändern sich laufend. Eine einmal saubere Konfiguration bleibt es nicht von allein. Ein regelmäßiger Durchgang sollte umfassen:

administrative Rollen und die Zahl der globalen Administratoren
inaktive und nicht mehr benötigte Konten
externe Gäste und offene Freigabelinks
externe Weiterleitungen und ungewöhnliche Postfachregeln – ein klassisches Mittel, um sich nach einer Kompromittierung dauerhaft Einblick zu sichern
registrierte Anwendungen und erteilte Berechtigungen
fehlgeschlagene und auffällige Anmeldungen
Lizenznutzung

Der vierte Punkt verdient besondere Aufmerksamkeit, weil er auch dann Bestand hat, wenn das Passwort längst geändert wurde. Wer diesen Durchgang nicht selbst leisten will oder kann, sollte ihn fest terminieren statt gelegentlich vornehmen – das ist Teil dessen, was in einer laufenden IT-Betreuung verbindlich geregelt gehört.

Eine Reihenfolge, die sich bewährt hat

Zuerst: MFA-Status aller Konten erheben, getrennte Administratorkonten einrichten, zwei Notfallkonten mit Passkey aufsetzen, Konten ehemaliger Mitarbeiter schließen, externe Weiterleitungen prüfen, Backup-Bedarf entscheiden.

Danach: Gruppen- und Rollenmodell festlegen, Eigentümer für Teams und Sites benennen, Gastzugänge regeln, Ablagestruktur definieren, Benutzer-Lebenszyklus als Prozess beschreiben, benutzerbasierte Dienstkonten migrieren.

Fortlaufend: Berechtigungen, inaktive Konten, externe Freigaben, Sicherheitsmeldungen, Aufbewahrung und Lizenzen im festen Turnus prüfen.

Diese Reihenfolge ist nicht beliebig: Die ersten Punkte reduzieren das Risiko sofort und lassen sich in Tagen umsetzen. Die zweite Gruppe braucht Abstimmung im Unternehmen und ist ohne die erste wenig wert.

Die Plattform stellt Werkzeuge bereit, das Betriebskonzept nicht

Microsoft erzwingt MFA dort, wo die Plattform selbst verwaltet wird – am Azure-Portal, am Entra Admin Center, am Microsoft 365 Admin Center und am programmatischen Azure-Zugriff. Alles andere bleibt Ihre Entscheidung: welche Konten MFA nutzen, wer administrative Rechte hat, wer Eigentümer welcher Daten ist, wie lange Freigaben gelten und ob Sie zusätzlich sichern. Wer die erzwungene Pflicht mit einem Sicherheitskonzept verwechselt, hat die Verwaltungsebene geschützt und den Rest offen gelassen.

Handlungsaufruf

Wenn Sie wissen möchten, wie Ihre Microsoft-365-Umgebung tatsächlich konfiguriert ist, nehmen wir sie strukturiert auf: MFA-Status je Konto, administrative Rollen, Gäste und Freigaben, Weiterleitungen, Ablagestruktur und Backup-Situation. Ergebnis ist eine Bestandsaufnahme mit priorisierten Maßnahmen – und eine klare Aussage dazu, was Sie nicht brauchen.

Microsoft-365-Bestandsaufnahme anfragen

Weiterführend: Microsoft 365, Server und Infrastrukturbetrieb · NIS-2: Wer betroffen ist und was zu melden ist · IT-Sicherheit ohne eigene IT-Abteilung: acht Punkte nach Wirkung

Microsoft 365 absichern: Was Microsoft erzwingt und was Sie selbst regeln müssen