Welche Zugriffsregeln in Microsoft 365 bringen den größten Sicherheitsgewinn?

Die meisten Geschäftsführer hören bei Microsoft 365 das Wort „Zwei-Faktor” und halten das Thema damit für erledigt. Tatsächlich entscheidet nicht eine einzelne Maßnahme über das Risiko, sondern eine Handvoll Regeln, die festlegen, wer sich unter welchen Bedingungen anmelden darf. Diese Regeln heißen in Microsoft 365 „Bedingter Zugriff” (englisch: Conditional Access). Sie sind kein Produkt, das man dazukauft, sondern Konfiguration. Genau deshalb sehen zwei Unternehmen mit identischer Lizenz völlig unterschiedlich abgesichert aus. Deshalb steht die Frage nach den wirksamsten Regeln am Anfang jeder Bestandsaufnahme.

Die kurze Antwort

Den größten Effekt bringen fünf Regeln: Mehr-Faktor-Anmeldung für alle Konten statt nur für Administratoren, das Blockieren alter Anmeldeprotokolle, phishing-resistente Anmeldung für Administratoren, das Sperren des Geräte-Code-Anmeldewegs und die Begrenzung sensibler Zugriffe auf verwaltete Geräte. Umsetzbar sind diese Regeln über den Bedingten Zugriff in Microsoft Entra ID, der eine Entra-ID-P1-Lizenz voraussetzt. Sie ist in Microsoft 365 Business Premium und in Microsoft 365 E3 enthalten. Ohne P1 bleiben nur die kostenlosen „Sicherheitsstandards”: ein grober Teil derselben Schutzwirkung, aber ohne Ausnahmen und ohne Feinsteuerung. Der häufigste Fehler in der Praxis ist nicht die falsche Regel, sondern die fehlende Ausnahme für Notfall- und Dienstkonten.

Was der Bedingte Zugriff ist und was er lizenzseitig kostet

Eine Regel im Bedingten Zugriff ist im Kern ein Wenn-dann-Satz: Wenn ein Benutzer auf eine Anwendung zugreifen will, dann muss eine bestimmte Bedingung erfüllt sein. Microsoft nennt als Voraussetzung ausdrücklich Microsoft Entra ID P1; Kunden mit Microsoft 365 Business Premium haben diese Lizenz bereits, ohne es zwingend zu wissen. Wer nur eine Business-Standard- oder Business-Basic-Lizenz hat, kann die Regeln in dieser Form nicht bauen und ist auf die kostenlosen „Sicherheitsstandards” (Security Defaults) angewiesen. Die decken drei der fünf hier beschriebenen Punkte in einer Pauschalvariante ab: Mehr-Faktor-Anmeldung für alle Konten, das Blockieren alter Anmeldeprotokolle und das Sperren des Geräte-Code-Anmeldewegs. Phishing-resistente Anmeldung für Administratoren und die Begrenzung auf verwaltete Geräte lassen sich damit nicht abbilden. Es gibt zudem weder Ausnahmen noch Zielgruppen noch einen Testmodus. Für ein Unternehmen mit 10 bis 75 Mitarbeitenden ist das ein tragfähiger Einstieg, aber selten ein Dauerzustand.

Regel 1: Mehr-Faktor-Anmeldung für alle Konten, nicht nur für Administratoren

Die verbreitetste Halblösung ist MFA nur für Administratoren. Angreifer zielen aber gerade auf normale Postfächer, weil dort Rechnungen, Verträge und Zahlungswege liegen. Microsoft beziffert die Wirkung von MFA in der eigenen Dokumentation mit „mehr als 99,2 Prozent” blockierter Kontoübernahmen. Das ist eine Herstellerzahl, aber die Richtung ist unstrittig.

Wichtig für die Einordnung: Es gibt keinen Marktstandard „100 Prozent MFA”. Cyberversicherer verlangen MFA für definierte Bereiche, typischerweise Fernzugriffe, privilegierte Konten und Cloud- beziehungsweise E-Mail-Zugänge. Verletzt ein Unternehmen eine solche vertragliche Obliegenheit, ist der Versicherer nach § 28 Abs. 2 VVG nur bei Vorsatz vollständig leistungsfrei; bei grober Fahrlässigkeit wird anteilig gekürzt, bei einfacher Fahrlässigkeit bleibt die volle Leistungspflicht bestehen. Nach § 28 Abs. 3 VVG bleibt die Leistungspflicht zudem erhalten, wenn die Obliegenheitsverletzung für den Schaden nicht ursächlich war.

Was schiefgehen kann: Der Multifunktionsdrucker, der Scans per Mail verschickt, das ERP-System mit eigenem Postfachzugriff und das Synchronisationskonto zu einem lokalen Active Directory kennen keinen zweiten Faktor. Werden sie nicht sauber ausgenommen oder auf moderne Verfahren umgestellt, steht am Montagmorgen der Betrieb.

Regel 2: Alte Anmeldeprotokolle blockieren

Alte Protokolle wie POP3, IMAP oder Exchange ActiveSync mit Kennwortanmeldung kennen keinen zweiten Faktor. Wer sie nutzt, umgeht jede MFA-Regel. Microsoft schreibt in der aktuellen Dokumentation zum Bedingten Zugriff, mehr als 99 Prozent der Passwort-Spray-Angriffe liefen über solche alten Verfahren. Mit abgeschalteter Kennwortanmeldung laufen sie schlicht ins Leere.

In Exchange Online hat Microsoft die Kennwortanmeldung für diese Protokolle bereits abgeschaltet, und zwar unumkehrbar. Eine Ausnahme lebt noch: der Mailversand über SMTP AUTH. Nach dem aktuell veröffentlichten Fahrplan bleibt es bis Dezember 2026 unverändert, wird dann für bestehende Mandanten standardmäßig deaktiviert (mit Möglichkeit zur Reaktivierung), ist für neue Mandanten nicht mehr verfügbar, und ein endgültiges Abschaltdatum soll in der zweiten Jahreshälfte 2027 angekündigt werden.

Was schiefgehen kann: Genau hier hängen Drucker, Scanner, Zeiterfassungen, Warenwirtschaften und Alarmierungssysteme. Vor dem Scharfschalten gehört ein Blick in die Anmeldeprotokolle, gefiltert nach der Spalte „Clientanwendung”. Sonst merkt man erst am Ausfall, wer noch alt anmeldet.

Regel 3: Administratoren brauchen phishing-resistente Anmeldung

Ein Administratorkonto ist der Generalschlüssel. Eine Push-Benachrichtigung im Authenticator lässt sich abfangen oder erschleichen; ein Sicherheitsschlüssel nicht. Microsoft fasst diese Verfahren als „phishing-resistente MFA” zusammen und meint damit FIDO2-Sicherheitsschlüssel beziehungsweise Passkeys, Windows Hello for Business und zertifikatsbasierte Anmeldung.

Parallel dazu erzwingt Microsoft ohnehin MFA für die Verwaltungsportale: seit Oktober 2024 für Azure-Portal, Entra Admin Center und Intune Admin Center, seit Februar 2025 für das Microsoft-365-Admin-Center und seit 1. Oktober 2025 für Azure CLI, Azure PowerShell und REST-Aufrufe. Eine Verschiebung war maximal bis zum 1. Juli 2026 möglich. Dieser Puffer ist heute abgelaufen.

Was schiefgehen kann: Ein einziger Sicherheitsschlüssel ohne Ersatz. Zwei Schlüssel, getrennt verwahrt, sind Pflicht, nicht Komfort.

Regel 4: Den Geräte-Code-Anmeldeweg sperren

Der sogenannte Device Code Flow existiert für Geräte ohne Tastatur, etwa Besprechungsraumsysteme, Fernseher oder Drucker. Man gibt auf einem zweiten Gerät einen Code ein und meldet sich damit für das erste an. Microsoft beschreibt diesen Weg als von Kunden selten genutzt, von Angreifern aber häufig verwendet: Das Opfer tippt den Code in eine echte Microsoft-Anmeldeseite, das Zugriffstoken landet beim Angreifer. Seit dem 1. Juli 2026 blockieren alle neuen Microsoft-Entra-Mandanten diesen Weg im Rahmen der Sicherheitsstandards automatisch. Wer die Sicherheitsstandards aktiviert hat, ist ebenfalls abgedeckt. Für bestehende Mandanten mit Bedingtem Zugriff legt Microsoft eine eigene verwaltete Richtlinie zum Sperren dieses Anmeldewegs an, zunächst im Testmodus. Wer Besprechungsraumsysteme oder Teams-Geräte betreibt, die diesen Weg tatsächlich brauchen, sollte die Ausnahme eng auf diese Geräte begrenzen, statt die Regel abzuschalten.

Regel 5: Sensible Zugriffe auf verwaltete Geräte begrenzen

Die wirksamste, aber aufwendigste Regel: Zugriff nur von Geräten, die das Unternehmen verwaltet und deren Zustand geprüft ist. Also Verschlüsselung aktiv, Virenschutz aktuell, Betriebssystem gepflegt. Wer den vollen Schritt für alle Mitarbeitenden nicht gehen will, kann ihn auf Administratoren begrenzen oder die weichere Variante wählen: verwaltetes Gerät oder MFA.

Voraussetzung und Stolperstein: Diese Regel funktioniert nur mit einer vorhandenen Geräteverwaltung samt hinterlegter Konformitätsrichtlinie. Microsoft warnt ausdrücklich, dass die Regel ohne diese Richtlinie nicht wie beabsichtigt greift. Und auf macOS, iOS und Android verlangt der Nachweis ein Gerätezertifikat, was Nutzer als wiederkehrende Zertifikatsabfrage erleben.

Die Regel vor allen Regeln: Notfallzugänge

Jede der fünf Regeln kann eine Organisation aussperren. Microsoft empfiehlt daher mindestens zwei Notfallkonten („Break-Glass”), die ausschließlich in der Cloud liegen, auf der .onmicrosoft.com-Domäne laufen, mit Passkey oder Zertifikat gesichert sind, von sperrenden Regeln ausgenommen werden und mindestens alle 90 Tage getestet werden. Dazu kommt der Testmodus („Nur Bericht”): Jede neue Regel wird zuerst mitgeschrieben, statt sofort zu greifen. So sieht man, wen sie getroffen hätte, bevor jemand tatsächlich draußen steht.

Microsoft schaltet inzwischen selbst Regeln ein

Ein Punkt, der wenig bekannt ist: Microsoft legt sogenannte „von Microsoft verwaltete Richtlinien” direkt im Mandanten an, zunächst im Testmodus. Bleiben sie dort, aktiviert Microsoft sie frühestens 45 Tage nach Einführung selbst; die Ankündigung erfolgt 28 Tage vorher per E-Mail und im Message Center. Wer diese Nachrichten nicht liest, bekommt Änderungen an den eigenen Zugriffsregeln, ohne sie beschlossen zu haben. Das ist sicherheitlich sinnvoll und betrieblich riskant zugleich.

Checkliste zur Selbsteinordnung

Bleiben mehrere Felder leer, ist das ein häufiges Bild. Zugriffsregeln werden meist einmal eingerichtet und danach selten wieder aufgerufen, während Microsoft im Hintergrund eigene Richtlinien anlegt und aktiviert. Was tatsächlich gilt, steht nicht in der Checkliste, sondern in der Richtlinienübersicht des Mandanten: welche dieser Regeln dort heute aktiv sind, welche Ausnahmen eingetragen sind und ob sich das Ergebnis im Ernstfall belegen lässt.

Quellen

• Bedingter Zugriff (Conditional Access) setzt eine Microsoft-Entra-ID-P1-Lizenz voraus; Kunden mit Microsoft 365 Business Premium können Conditional Access ebenfalls nutzen. Risikobasierte Richtlinien erfordern Entra ID P2 (learn.microsoft.com)
• Entra ID P1 ist in Microsoft 365 Business Premium sowie in Microsoft 365 E3/E5 enthalten; Entra ID P2 in Microsoft 365 E5. Vergleichstabelle: Conditional Access erst ab P1 verfügbar (learn.microsoft.com)
• Die kostenlosen Sicherheitsstandards (Security Defaults) erzwingen MFA-Registrierung für alle Nutzer, MFA für Administratoren, MFA für Benutzer bei Bedarf, Blockieren von Legacy-Authentifizierung, Blockieren des Device Code Flow sowie MFA für Azure-Verwaltungszugriffe. Nicht enthalten sind phishing-resistente Authentifizierungsstärken für Administratoren und die Anforderung eines konformen Geräts. Beides setzt Conditional Access bzw. Geräteverwaltung voraus. Sicherheitsstandards sind ohne Lizenz nutzbar, aber nicht anpassbar (keine Ausnahmen, keine Zielgruppen, kein Berichtsmodus). Seit 1. Juli 2026 blockieren alle neuen Entra-Mandanten den Device Code Flow im Rahmen der Sicherheitsstandards (learn.microsoft.com)
• Microsoft gibt an, MFA blockiere mehr als 99,2 Prozent der Angriffe auf Kontoübernahme (Herstellerangabe, zitiert in der aktuellen Microsoft-Learn-Dokumentation) (learn.microsoft.com)
• Aktuelle Microsoft-Dokumentation zum Blockieren der Legacy-Authentifizierung: Mehr als 99 Prozent der Passwort-Spray-Angriffe nutzen Legacy-Authentifizierungsprotokolle und würden bei deaktivierter Basic Authentication ins Leere laufen. Empfohlenes Vorgehen: Richtlinie zunächst im Modus „Nur Bericht“, Identifikation betroffener Clients über die Spalte „Client App“ in den Anmeldeprotokollen (learn.microsoft.com)
• Basic Authentication ist in Exchange Online für Exchange ActiveSync, POP, IMAP, Remote PowerShell, EWS, OAB, Autodiscover und Outlook abgeschaltet und kann nicht wieder aktiviert werden. SMTP AUTH ist noch verfügbar; Microsoft hat die Abschaltung angekündigt (learn.microsoft.com)
• Aktualisierter Zeitplan für SMTP AUTH: unverändert bis Dezember 2026, Ende Dezember 2026 standardmäßige Deaktivierung für bestehende Mandanten (Reaktivierung durch Administratoren möglich), für neue Mandanten ab dann nicht mehr verfügbar, endgültiges Abschaltdatum wird in der zweiten Jahreshälfte 2027 angekündigt (techcommunity.microsoft.com)
• Die integrierte Authentifizierungsstärke „Phishing-resistant MFA“ umfasst FIDO2-Sicherheitsschlüssel, Windows Hello for Business bzw. Plattform-Anmeldeinformationen und mehrstufige zertifikatsbasierte Authentifizierung. Voraussetzung: Entra ID P1 (learn.microsoft.com)
• Verpflichtende MFA: seit Oktober 2024 für Azure-Portal, Microsoft Entra Admin Center und Intune Admin Center; seit Februar 2025 für das Microsoft-365-Admin-Center; seit 1. Oktober 2025 (Phase 2) für Azure CLI, Azure PowerShell, Azure Mobile App, IaC-Werkzeuge und REST-API. Eine Verschiebung von Phase 2 war bis zum 1. Juli 2026 möglich. Auch Break-Glass-Konten müssen MFA erfüllen; empfohlen werden Passkey (FIDO2) oder zertifikatsbasierte Authentifizierung (learn.microsoft.com)
• Von Microsoft verwaltete Richtlinien werden automatisch im Modus „Nur Bericht“ im Mandanten angelegt und frühestens 45 Tage nach Einführung von Microsoft aktiviert, wenn sie im Berichtsmodus verbleiben; Kunden werden 28 Tage vorher per E-Mail und über das Message Center informiert. Zur Liste gehören unter anderem „Block legacy authentication“, „Block device code flow“, „MFA für Administratoren in Microsoft-Admin-Portalen“ und „MFA für alle Benutzer“. Der Device Code Flow wird von Kunden selten, von Angreifern häufig genutzt; für Geräte, die ihn benötigen, empfiehlt Microsoft eine eng begrenzte Ausnahme statt einer Deaktivierung der Richtlinie (learn.microsoft.com)
• Die Richtlinie „Gerät als konform markiert erforderlich“ funktioniert ohne in Microsoft Intune erstellte Konformitätsrichtlinie nicht wie beabsichtigt. Auf iOS, Android, macOS und einigen Browsern identifiziert Entra ID das Gerät über ein Clientzertifikat, das der Nutzer auswählen muss. Empfohlene Ausnahmen: Notfallkonten sowie Verzeichnissynchronisierungskonten (learn.microsoft.com)
• Microsoft empfiehlt mindestens zwei Notfallzugangskonten, reine Cloud-Konten auf der .onmicrosoft.com-Domäne, gesichert mit phishing-resistenten Verfahren (FIDO2 oder zertifikatsbasiert), ausgenommen von sperrenden Conditional-Access-Richtlinien, mit Überwachung der Anmeldeprotokolle und Funktionsprüfung mindestens alle 90 Tage (learn.microsoft.com)
• Im Modus „Nur Bericht“ werden Richtlinien bei der Anmeldung ausgewertet, aber nicht erzwungen; Ergebnisse erscheinen in den Registerkarten „Bedingter Zugriff“ und „Nur Bericht“ der Anmeldeprotokolle. Richtlinien im Berichtsmodus, die Gerätekonformität prüfen, können auf macOS, iOS und Android dennoch Zertifikatsabfragen auslösen (learn.microsoft.com)
• Die Standardeinstellung für die Anmeldehäufigkeit in Microsoft Entra ID ist ein rollierendes Fenster von 90 Tagen; zu häufige Anmeldeaufforderungen erhöhen laut Microsoft das Risiko, dass Nutzer Anmeldedaten unbedacht an bösartige Aufforderungen weitergeben (MFA-Fatigue) (learn.microsoft.com)
• § 28 VVG: Bei vorsätzlicher Verletzung einer vertraglichen Obliegenheit ist der Versicherer leistungsfrei; bei grob fahrlässiger Verletzung ist er berechtigt, die Leistung entsprechend der Schwere des Verschuldens zu kürzen. Die Leistungspflicht bleibt bestehen, soweit die Verletzung weder für den Eintritt oder die Feststellung des Versicherungsfalls noch für die Feststellung oder den Umfang der Leistungspflicht ursächlich war (gesetze-im-internet.de)