Microsoft 365 Conditional Access: Praxisleitfaden für KMU

Microsoft 365 ist in vielen KMU längst zur zentralen Arbeitsplattform geworden. E-Mail, Dokumente, Kommunikation und Identitäten liegen bei Microsoft – erreichbar von jedem Gerät, aus jedem Netzwerk, zu jeder Zeit. Genau darin liegt der Nutzen. Und genau darin liegt das Risiko.

Ein einzelnes kompromittiertes Passwort reicht aus, um Angreifern Zugriff auf Postfächer, SharePoint-Daten und Teams-Chats zu geben. Multi-Faktor-Authentifizierung (MFA) senkt dieses Risiko deutlich, ist aber nur ein Baustein. Der eigentliche Steuerungsmechanismus in Microsoft 365 heißt Conditional Access (seit der Umbenennung 2023 offiziell: Microsoft Entra Conditional Access). Hier legen Sie fest, unter welchen Bedingungen ein Zugriff erlaubt, blockiert oder mit zusätzlichen Anforderungen versehen wird.

Dieser Leitfaden richtet sich an IT-Administratoren und M365-Verantwortliche in kleinen und mittleren Unternehmen. Er zeigt, wie Sie Conditional Access von der Grundlage bis zum laufenden Betrieb einführen – mit dem Blick, den wir aus unseren Kundenrollouts mitbringen: pragmatisch, sicher, ohne dass sich am Ende jemand aussperrt.

Autor: aconitas Security-Team · Letzte Aktualisierung: 5. August 2026

Was ist Microsoft 365 Conditional Access – und wozu brauche ich es?

Microsoft 365 Conditional Access ist die zentrale Richtlinien-Engine in Microsoft Entra ID (ehemals Azure Active Directory). Sie werten Signale aus – Benutzer, Gerät, Standort, Anwendung, Risikobewertung – und entscheidet, ob der Zugriff gewährt, mit MFA versehen, blockiert oder auf konforme Geräte beschränkt wird. Vereinfacht: Wenn ein Benutzer auf eine Ressource zugreifen will, dann muss er eine bestimmte Bedingung erfüllen.

Ohne Conditional Access gilt in Microsoft 365 die Grundregel: Wer Benutzername und Passwort kennt, kommt rein. Die kostenlosen Security Defaults ergänzen das um eine grundlegende MFA-Pflicht, sind aber nicht granular steuerbar. Für den professionellen Einsatz in einem KMU sind sie ein Übergangszustand, kein Zielbild.

Was Conditional Access typischerweise regelt:

• MFA-Pflicht für bestimmte Benutzergruppen (z. B. alle Admins)
• Blockade veralteter Authentifizierungsprotokolle (IMAP, POP3, SMTP-Basic)
• Zugriffsbeschränkung auf verwaltete, compliant markierte Geräte
• Geografische Einschränkungen (bestimmte Länder komplett blockieren)
• Höhere Anforderungen bei Anmeldungen mit hohem Risiko

Lizenzvoraussetzungen (Stand 2026):

Für ein KMU mit typischerweise 25 bis 250 Arbeitsplätzen ist Microsoft 365 Business Premium in der Regel die richtige Basis. Wer erweiterten Identitätsschutz braucht (z. B. NIS2-relevante Sektoren), sollte zumindest für privilegierte Konten auf E5 oder Entra ID P2 als Add-on gehen.

Welche Voraussetzungen muss ich vor der Einführung prüfen?

Bevor Sie die erste Policy schreiben, klären Sie fünf Punkte. Das erspart Ihnen später Rollbacks im laufenden Betrieb.

1. Lizenzen prüfen. Öffnen Sie im Microsoft 365 Admin Center die Lizenzübersicht. Jeder Benutzer, der von einer Conditional-Access-Policy erfasst wird, benötigt eine Entra-ID-P1- oder P2-Lizenz. Gäste sind in der Regel kostenlos, solange sie unter der monatlichen Grenze liegen (aktuell 50.000 MAU pro Tenant im External Identities Free Tier).

2. Break-Glass-Konten anlegen. Bevor irgendeine Policy scharf geschaltet wird, benötigen Sie zwei Notfall-Konten (Emergency Access Accounts). Diese Konten:

• sind reine Cloud-Konten (kein Sync aus dem lokalen AD)
• haben die Rolle Global Administrator
• sind von allen Conditional-Access-Policies ausgenommen
• haben ein sehr langes, zufällig generiertes Passwort
• werden nicht mit MFA über die Standard-Authenticator-App gesichert (sonst gibt es das gleiche Lockout-Risiko), sondern mit FIDO2-Sicherheitsschlüsseln – zwei Schlüssel pro Konto, physisch getrennt gelagert
• werden regelmäßig getestet, dokumentiert und im Zugriff protokolliert

Ohne funktionierende Break-Glass-Konten führen Sie keine Conditional-Access-Policy scharf. Das ist der häufigste vermeidbare Fehler bei M365-Rollouts.

3. MFA-Registrierung sicherstellen. Prüfen Sie, ob alle Benutzer bereits eine MFA-Methode registriert haben (Report unter Entra ID → Benutzer → Authentifizierungsmethoden). Wenn nicht, definieren Sie eine Registrierungskampagne, bevor MFA verpflichtend wird.

4. Report-Only-Modus einplanen. Jede neue Policy startet im Report-Only-Modus. Sie sehen dann in den Sign-in Logs, was die Policy hätte getan, ohne dass Benutzer betroffen sind. Rechnen Sie mit zwei bis vier Wochen Beobachtungszeit pro Policy-Set.

5. Kommunikation vorbereiten. Legen Sie fest, wer die Endanwender informiert, wann die Umstellung erfolgt und wie der Support reagiert, wenn Anmeldungen fehlschlagen. Rechnen Sie mit einer erhöhten Ticket-Last in den ersten drei bis fünf Werktagen nach Aktivierung.

Wie baue ich sinnvolle Baseline-Policies für ein KMU auf?

Für ein typisches KMU haben sich fünf bis sieben Baseline-Policies bewährt. Wichtig ist die Reihenfolge: Erst die harten Sperren, dann die Anforderungen an Endbenutzer, zuletzt die Feinsteuerung.

Empfohlene Baseline (in dieser Reihenfolge einführen):

Policy 1: MFA für alle Administratoren (immer, überall)

• Assignments: Zielrollen – Global Administrator, Security Administrator, Exchange Administrator, SharePoint Administrator, Application Administrator, Privileged Role Administrator (Microsoft nennt aktuell 14 privilegierte Rollen, die Sie mindestens abdecken sollten)
• Conditions: alle Cloud-Apps, alle Netzwerke
• Grant: MFA erforderlich
• Ausnahme: Break-Glass-Konten

Policy 2: Legacy-Authentifizierung blockieren

• Assignments: alle Benutzer (außer Break-Glass)
• Conditions: Client-Apps – Other clients (Exchange ActiveSync, andere Legacy-Clients)
• Grant: Zugriff blockieren

Legacy-Protokolle wie IMAP, POP3 und SMTP-Basic-Auth umgehen MFA komplett. Diese Policy schließt das häufigste Einfallstor für Passwort-Spray-Angriffe.

Policy 3: MFA für alle Benutzer

• Assignments: alle Benutzer (außer Break-Glass und ggf. Dienstkonten)
• Conditions: alle Cloud-Apps
• Grant: MFA erforderlich
• Session: Sign-in Frequency auf 14 oder 30 Tage setzen (je nach Risikoappetit)

Policy 4: Länder-Sperre (Named Locations)

• Assignments: alle Benutzer
• Conditions: Locations – alle Länder außerhalb definierter erlaubter Regionen (z. B. DACH + EU)
• Grant: Zugriff blockieren

Definieren Sie unter Named Locations zunächst die Länder, aus denen Ihre Mitarbeitenden regulär arbeiten. Alles andere wird blockiert. Für Dienstreisen werden gezielte Ausnahmen ergänzt.

Policy 5: Geräte-Compliance erforderlich

• Assignments: alle Benutzer (Rollout in Wellen)
• Conditions: alle Cloud-Apps, ggf. beschränkt auf Desktop-Plattformen
• Grant: Compliant device oder Hybrid Azure AD Joined device erforderlich

Diese Policy setzt einen funktionierenden Intune-Rollout voraus (siehe nächste Sektion).

Policy 6 (optional, P2-Lizenz): Risikobasierte MFA

• Assignments: alle Benutzer
• Conditions: Sign-in Risk = Medium oder High
• Grant: MFA + Passwortänderung erforderlich

Policy 7: Guest Access einschränken

• Assignments: Guest oder External Users
• Conditions: alle Cloud-Apps
• Grant: MFA erforderlich, ggf. Terms of Use akzeptieren

Für weitere Kontext-Empfehlungen zu M365-Härtung siehe unseren Leitfaden zu Microsoft 365 Security Best Practices. Wenn Sie unter die NIS2-Anforderungen fallen, sind MFA-Pflicht und dokumentierte Zugriffskontrollen ohnehin Pflicht – Conditional Access ist dann der technische Nachweis dafür.

Wie kombiniere ich Conditional Access mit Device Compliance und Intune?

Conditional Access entfaltet seinen vollen Wert erst in Kombination mit Microsoft Intune. Solange die Policy nur MFA verlangt, bleibt die Frage offen, ob das anmeldende Gerät überhaupt vertrauenswürdig ist. Erst Compliant device required stellt sicher, dass nur Geräte zugelassen werden, die einer definierten Sicherheitsrichtlinie entsprechen.

Voraussetzungen für Device Compliance:

• Intune-Lizenz (in Microsoft 365 Business Premium enthalten)
• Geräte sind in Intune registriert oder Hybrid Azure AD Joined
• Es existieren Compliance Policies für die relevanten Plattformen (Windows, macOS, iOS, Android)

Typische Compliance-Kriterien in einer KMU-Baseline:

Rollout-Reihenfolge in der Praxis:

1. Intune-Enrollment für neue Windows-Geräte über Autopilot einrichten
2. Bestandsgeräte in Wellen einbinden (Abteilung für Abteilung)
3. Compliance Policies zunächst nur überwachen (nicht durchsetzen)
4. Sobald mindestens 90 % der Geräte als compliant markiert sind: Conditional-Access-Policy 5 im Report-Only-Modus aktivieren
5. Nach zwei Wochen Auswertung: scharf schalten

Häufiger Stolperstein bei macOS und mobilen Geräten: Auf privaten Geräten (BYOD) ist volle MDM-Kontrolle oft nicht durchsetzbar. Alternative sind App Protection Policies: Der Zugriff auf Outlook, Teams oder OneDrive wird dann auf die Microsoft-Apps beschränkt, die eine eigene Container-Verschlüsselung mitbringen. Der Grant-Type in Conditional Access heißt hier Require approved client app oder Require app protection policy.

Für Kunden mit strengeren Anforderungen kombinieren wir Conditional Access typischerweise mit Managed Security – die kontinuierliche Auswertung von Sign-in Logs und Compliance-Reports gehört dann nicht zu den Aufgaben der internen IT.

Welche Fallstricke muss ich beim Rollout vermeiden?

Aus unserer Erfahrung bei M365-Rollouts wiederholen sich einige wenige Fehler in fast jedem Projekt. Wer sie kennt, spart sich Rollbacks.

Fallstrick 1: Kein Break-Glass-Konto. Wenn eine Policy versehentlich alle Admins aussperrt und kein Notfall-Konto existiert, bleibt nur der Microsoft-Support als Ausweg – im schlechtesten Fall mit mehreren Tagen Downtime. Konsequenz: Zwei Break-Glass-Konten anlegen, dokumentieren, aus allen Policies ausschließen und mindestens halbjährlich testen.

Fallstrick 2: Direkte Aktivierung ohne Report-Only. Jede Policy, die ohne Beobachtungszeitraum scharf geschaltet wird, produziert Support-Tickets. Konsequenz: Report-Only-Modus mindestens 14 Tage laufen lassen, Sign-in Logs auswerten, dann aktivieren.

Fallstrick 3: Dienstkonten vergessen. Anwendungen, Skripte und Verzeichnisdienste laufen oft unter dedizierten Konten, die MFA technisch nicht bedienen können. Werden sie von einer generischen "MFA für alle"-Policy erfasst, brechen Prozesse ab. Konsequenz: Dienstkonten identifizieren, in eine eigene Gruppe legen, gezielt ausschließen – und stattdessen mit langen Passwörtern, Rotationsverfahren und Zugriffsbeschränkung auf bestimmte IP-Bereiche absichern. Perspektivisch auf Managed Identities oder Workload Identities umstellen.

Fallstrick 4: Zu viele Ausnahmen. Jede Ausnahme schwächt die Policy. Wenn nach sechs Monaten die Ausschlussliste länger ist als die Zielgruppe, war der Zuschnitt falsch. Konsequenz: Ausnahmen dokumentieren, mit Ablaufdatum versehen und im Rezertifizierungsprozess prüfen.

Fallstrick 5: Change-Kommunikation fehlt. Wenn Benutzer am Morgen der Umstellung ohne Vorwarnung mit MFA-Prompts konfrontiert werden, sinkt die Akzeptanz. Konsequenz: Vorab per E-Mail informieren, kurze Anleitung mit Screenshots bereitstellen, Ansprechpartner benennen. Rollout möglichst nicht an einem Montagmorgen oder direkt vor Urlaubszeiten.

Fallstrick 6: Legacy-Anwendungen übersehen. Ältere Line-of-Business-Anwendungen, Multifunktionsgeräte mit Scan-to-Mail oder Alarmierungssysteme nutzen häufig noch Basic Authentication. Werden diese ohne Vorbereitung geblockt, fallen sie aus. Konsequenz: Vor Aktivierung der Legacy-Auth-Blockade das Sign-in Log nach Client App = Other Clients filtern und die betroffenen Konten migrieren – typischerweise auf App-Passwörter, OAuth 2.0 oder Modern Authentication.

Wie überwache und optimiere ich Conditional Access im laufenden Betrieb?

Conditional Access ist kein "einmal einrichten und vergessen"-Thema. Cloud-Dienste, Rollen und Bedrohungslage ändern sich – die Policies müssen mitgehen. In der Praxis genügt ein monatlicher Betriebsrhythmus mit drei Kernaufgaben.

1. Sign-in Logs auswerten. Unter Entra ID → Monitoring → Sign-in Logs sehen Sie jeden Anmeldeversuch inklusive der ausgeführten Conditional-Access-Policies. Filtern Sie mindestens wöchentlich nach:

• Status = Failure mit CA-Bezug (welche Policy hat blockiert, war die Blockade beabsichtigt?)
• Anmeldungen aus nicht erlaubten Ländern (Angriffsversuche oder legitime Reisen?)
• Anmeldungen mit Sign-in Risk = High (nur mit Entra ID P2 sichtbar)

Für längere Aufbewahrung (Standard: 30 Tage) exportieren Sie die Logs in einen Log Analytics Workspace oder ein externes SIEM. Für NIS2-relevante Unternehmen sind mindestens 12 Monate Aufbewahrung sinnvoll.

2. What-If-Tool nutzen. Bevor Sie eine Policy ändern, simulieren Sie den Effekt mit dem What-If-Tool. Sie geben Benutzer, Anwendung, Gerätezustand und Standort an und sehen, welche Policies greifen würden. Das erspart Testanmeldungen mit echten Konten.

3. Policy-Rezertifizierung. Führen Sie mindestens halbjährlich eine strukturierte Prüfung durch:

• Sind alle Policies noch fachlich begründet?
• Sind Ausnahmen noch gültig oder abgelaufen?
• Wurden neue Rollen, Anwendungen oder Standorte eingeführt, die berücksichtigt werden müssen?
• Funktionieren die Break-Glass-Konten? (Test-Anmeldung mit dokumentiertem Protokoll)
• Sind die MFA-Methoden noch dem Stand der Technik? SMS-basierte MFA sollte spätestens 2026 durch Authenticator-App oder FIDO2 abgelöst sein.

Break-Glass-Test: Setzen Sie einen wiederkehrenden Kalendereintrag alle sechs Monate. Beim Test wird das Passwort neu gesetzt, mit einem Break-Glass-Konto eine echte Anmeldung durchgeführt und das Protokoll archiviert. Ein untestbares Notfall-Konto ist kein Notfall-Konto.

Zusatz für höhere Reifegrade: Wenn Sie in Conditional Access → Templates nachsehen, finden Sie 14 offizielle Microsoft-Vorlagen (Stand 2026). Sie sind ein guter Ausgangspunkt, sollten aber immer an das eigene Zielbild angepasst werden – nicht ungeprüft aktivieren.

Was ist der nächste Schritt?

Ein tragfähiger Conditional-Access-Rollout in einem KMU dauert typischerweise vier bis acht Wochen von der Bestandsaufnahme bis zur produktiven Aktivierung aller Baseline-Policies. Der größte Aufwand liegt nicht im Konfigurieren, sondern in der Vorbereitung: Break-Glass-Konten, MFA-Registrierung, Intune-Enrollment, Kommunikation.

Ein sinnvoller erster Schritt ist eine Bestandsaufnahme:

1. Welche Lizenzen sind vorhanden – reicht Business Premium, oder ist E5 sinnvoll?
2. Wie viele privilegierte Rollen sind aktuell vergeben – lassen sich diese reduzieren?
3. Gibt es Legacy-Anwendungen, die Basic Authentication verwenden?
4. Wie ist der Reifegrad des Intune-Rollouts?
5. Existieren funktionierende Break-Glass-Konten?

Auf dieser Grundlage lässt sich ein Rollout-Plan erstellen, der zur Größe und zum Risikoprofil des Unternehmens passt. Wenn Sie diesen Prozess nicht komplett intern abbilden wollen, unterstützen wir Sie gerne – von der Erstkonfiguration bis zum laufenden Betrieb.