Conditional Access ist die Brücke zwischen Identität und Sicherheit
Microsoft Entra Conditional Access ist die Policy-Engine, die entscheidet, unter welchen Bedingungen ein Anmeldeversuch akzeptiert, mit zusätzlichen Anforderungen versehen oder blockiert wird. Die offizielle Microsoft-Dokumentation beschreibt das Prinzip in einem Satz: Wenn ein Nutzer auf eine Ressource zugreifen möchte, dann muss er bestimmte Anforderungen erfüllen. Diese "Wenn-Dann"-Logik ist einfach zu verstehen — und gleichzeitig der Kernmechanismus, mit dem moderne Microsoft-365-Umgebungen geschützt werden.
Im Mittelstand ist Conditional Access (CA) häufig nur halb eingerichtet. Die ersten beiden Policies — MFA-Pflicht für alle Nutzer, Block-Legacy-Authentication — sind oft vorhanden. Darüber hinaus existieren entweder gar keine Regeln, oder ein historisch gewachsenes Geflecht, das niemand mehr durchschaut. Beide Zustände sind problematisch.
Dieser Artikel beschreibt zehn Regeln, die in nahezu jeder mittelständischen M365-Umgebung sinnvoll sind. Konfigurationsdetails (Schritt-für-Schritt im Portal) lassen wir bewusst weg — sie sind in der Microsoft-Deployment-Guide aktuell dokumentiert. Hier geht es um die strategischen Entscheidungen: Welche Regeln, in welcher Reihenfolge, mit welchen Ausnahmen.
Lizenzvoraussetzungen kurz vorab
Conditional Access erfordert Microsoft Entra ID P1 — enthalten in Microsoft 365 Business Premium, E3 und E5. Reine Exchange-Online- oder Microsoft 365 Apps-Lizenzen reichen nicht. Diese Lizenzgrenze ist in der Microsoft-Dokumentation klar benannt und sollte vor jedem CA-Projekt geprüft werden.
Drei Vorarbeiten vor der ersten Policy
Bevor eine einzige Policy aktiviert wird, sollten drei Dinge erledigt sein. Sie wirken trivial, werden aber regelmäßig übersehen — mit ernsten Konsequenzen.
1. Break-Glass-Accounts einrichten
Mindestens zwei Notfall-Administratoren ohne MFA-Bindung an persönliche Geräte, mit langen Passwörtern in einem Tresor (idealerweise außerhalb der Microsoft-Umgebung). Diese Accounts werden in allen Conditional-Access-Policies explizit ausgeschlossen. Sie sind die Versicherung gegen den Fall, dass eine Policy versehentlich alle Admins aussperrt — was in der Praxis bei unsorgfältiger Konfiguration passiert.
2. Naming-Convention festlegen
Wer Policies "Policy-1", "Test-MFA" oder "neu" nennt, verliert nach drei Monaten den Überblick. Eine bewährte Convention enthält: Sequenznummer, Ziel-App, Aktion, Zielgruppe, Bedingung. Ein Beispiel-Name: "CA-001-AllApps-RequireMFA-AllUsers-Always". Die Microsoft Deployment Guide empfiehlt eine solche strukturierte Benennung explizit.
3. Report-Only-Modus nutzen
Jede neue Policy wird zuerst im Report-Only-Modus aktiviert. Über mehrere Tage sammelt man dann im Anmelde-Log Daten dazu, welche Anmeldungen die Policy gegriffen hätte. Erst nach belastbarer Auswertung wird die Policy scharf geschaltet. Dieser Schritt verhindert die häufigste Ursache für CA-Fehlkonfigurationen: unterschätzte Ausnahmen.
Regel 1: MFA für alle Benutzer
Die Basis jeder CA-Strategie ist die flächendeckende MFA-Pflicht. Microsofts eigene Telemetrie zeigt durchgehend, dass MFA die Mehrzahl der identitätsbasierten Angriffe verhindert. Die Policy umfasst alle Cloud-Apps, alle Benutzer, immer — mit folgenden Ausnahmen: Break-Glass-Accounts und ggf. dedizierte Service-Accounts, die separat über stärkere Mechanismen abgesichert sind.
Wichtig: Service-Accounts sollten nach Möglichkeit auf Workload Identities (Managed Identities, Federated Credentials) migriert werden, die ohnehin nicht MFA-pflichtig sind. Echte Ausnahmen sollten dokumentiert und befristet sein.
Regel 2: Legacy-Authentication blockieren
Legacy-Authentication-Protokolle (POP3, IMAP, ältere SMTP-Varianten, basic auth für Exchange ActiveSync) bieten Angreifern eine Tür um MFA herum. Microsoft hat Basic Auth in Exchange Online schon vor Jahren deaktiviert, aber einzelne Legacy-Pfade bestehen weiter. Eine CA-Policy, die Legacy-Auth explizit blockiert, schließt diese Lücke endgültig.
Vor der Aktivierung sollte mit dem Sign-In-Log geprüft werden, ob noch Legacy-Anmeldungen erfolgen — und welche Geräte oder Dienste betroffen sind. Häufig sind es alte Multifunktionsdrucker, ungepflegte Webformulare oder veraltete CRM-Clients. Diese müssen umgestellt oder ersetzt werden, bevor die Policy scharf geht.
Regel 3: Geräte-Compliance für Unternehmens-Endgeräte
Wer Microsoft Intune einsetzt, kann Geräte als "compliant" markieren — auf Basis von Verschlüsselung, Patch-Stand, fehlender Jailbreak/Root-Erkennung und weiteren Kriterien. Eine sinnvolle CA-Policy erlaubt den Zugriff auf sensitive Apps (z. B. Exchange Online, SharePoint Online) nur, wenn das Gerät als compliant markiert oder Hybrid-Azure-AD-joined ist.
Diese Regel ist besonders wirkungsvoll, weil sie das ganze Angriffsmodell verändert: Selbst wenn ein Angreifer Username, Passwort und MFA hat, scheitert er am Gerätestatus. Voraussetzung: Intune muss flächendeckend ausgerollt sein. In Microsoft 365 Business Premium ist Intune Plan 1 enthalten.
Regel 4: App-Protection für mobile Geräte (BYOD)
Mitarbeiter nutzen häufig private Smartphones für E-Mail und Teams. Eine vollständige Gerätekontrolle ist hier weder rechtlich noch praktisch durchsetzbar. Die App-Protection-Policy in Intune schützt stattdessen die App: Sie verhindert Copy-Paste in unmanaged Apps, blockiert Backups, erzwingt eine PIN nur für die geschützte App. Eine CA-Policy kann erzwingen, dass Outlook auf iOS/Android nur mit aktiver App-Protection genutzt werden darf.
Diese Kombination ermöglicht BYOD-Szenarien ohne das volle Compliance-Korsett — ein häufiges Bedürfnis im Mittelstand.
Regel 5: Länder-/Regionssperren mit benannten Standorten
Conditional Access kennt das Konzept "Named Locations" — IP-Bereiche oder Länder, die als bekannte Standorte definiert werden können. Eine sinnvolle Policy blockiert Anmeldungen aus Ländern, in denen das Unternehmen nicht aktiv ist. Statt einer Blockliste empfiehlt sich eine Allowlist (DACH, EU, ggf. ausgewählte Länder) und Block für alle übrigen — das ist robuster, weil neue Angriffsregionen automatisch erfasst werden.
Wichtig dabei: Reisende Mitarbeiter müssen über eine separate Policy oder einen definierten Ausnahmeprozess weiter arbeiten können. Auch hier gilt: Break-Glass-Accounts müssen explizit ausgenommen sein, damit sie auch im Notfall aus einer beliebigen Region funktionieren.
Regel 6: Stärkere Authentifizierung für administrative Rollen
Administrative Konten sind höherwertige Ziele. Sie sollten mit zusätzlichen Anforderungen geschützt werden — entweder mit Phishing-resistenter MFA (FIDO2, Windows Hello for Business, Authenticator mit Number Matching) oder mit der zusätzlichen Bedingung "compliant device". Eine CA-Policy für alle Inhaber privilegierter Rollen (Global Admin, Exchange Admin, SharePoint Admin, Security Admin etc.) schließt diese Lücke.
Die Liste der privilegierten Rollen ist in der Microsoft-Dokumentation klar definiert. Wer die Liste pauschal als "Built-in Admin Roles" einbindet, erfasst alle relevanten Rollen automatisch und muss nicht bei jeder neuen Rolle nachpflegen.
Regel 7: Sitzungs-Steuerung für Web-Sessions
Session Controls erlauben, den Microsoft-365-Web-Zugriff strenger zu reglementieren — etwa: Sessions laufen nach X Stunden ab; Browser-Sessions sind nicht persistent (kein "Angemeldet bleiben"); Downloads sind blockiert bei nicht-verwalteten Geräten. Diese Steuerung wirkt auf SharePoint Online, Exchange Online und OneDrive — wo sie kombiniert mit den Tenant-weiten Einstellungen verhindert, dass Daten auf privaten Geräten landen.
Im BYOD-Kontext ist diese Kombination besonders wertvoll. Sie ermöglicht den Web-Zugriff von beliebigen Geräten, verhindert aber den Datenabfluss auf das lokale Gerät.
Regel 8: Risikobasierte Anmeldung (mit Entra ID Protection)
Wer Entra ID P2 lizenziert hat (E5 oder Add-on), kann Microsofts Risiko-Engine nutzen. Sie bewertet jede Anmeldung in Echtzeit anhand von Indikatoren wie verdächtigem Standort, ungewöhnlicher Tageszeit, bekannten kompromittierten Zugangsdaten, atypischem Login-Verhalten. Eine CA-Policy reagiert auf erhöhtes Risiko mit zusätzlichen Maßnahmen — etwa erneuter MFA-Aufforderung oder Blockierung.
Für Mittelständler, die Entra ID Protection nicht lizenzieren, ist diese Regel zunächst nicht relevant. Bei der nächsten Lizenz-Erweiterung sollte sie aber bewusst geprüft werden — sie ist eines der wirkungsvollsten Werkzeuge gegen kompromittierte Accounts.
Regel 9: Schutz für Gäste-Accounts
Externe Nutzer (B2B-Gäste) werden häufig vergessen. Sie melden sich am eigenen Tenant an, kommen aber von extern. Eine CA-Policy sollte für alle Gast-Konten mindestens MFA erzwingen — viele Tenants haben das standardmäßig nicht aktiviert. Zusätzlich kann der Gast-Zugriff auf bestimmte Apps eingeschränkt werden (etwa: kein Zugriff auf das Admin Center, keine Self-Service-Apps).
Gäste-Accounts sind ein häufiger Einfallspunkt bei Lieferketten-Angriffen — der externe Partner wird kompromittiert und über den geteilten Zugang werden Daten abgegriffen. Eine dedizierte CA-Policy für Gäste reduziert dieses Risiko deutlich.
Regel 10: Notfall-Policies im disabled-Zustand
Microsoft empfiehlt in der Deployment-Guide ausdrücklich, vorbereitete, deaktivierte Policies für Notfälle bereitzuhalten. Beispiele: eine Policy, die alle Anmeldungen aus einem bestimmten Land blockiert, eine Policy, die nur compliant Devices erlaubt, eine Policy, die bestimmte Apps temporär blockiert. Diese Policies tragen ein erkennbares Präfix wie "ENABLE-IN-EMERGENCY" und können in einer akuten Sicherheitslage in Minuten aktiviert werden — ohne dass jemand unter Druck eine neue Policy schreiben muss.
Was Conditional Access nicht leistet
Conditional Access ist mächtig, aber kein Allheilmittel. Drei Grenzen, die in der Praxis wichtig sind:
- CA schützt Authentifizierung, nicht Inhalte. Wer schon angemeldet ist und ein Daten-Leck hat, wird durch keine CA-Policy gestoppt. Hier braucht es Defender for Office 365 / Cloud Apps und Purview.
- CA wirkt am Identity-Layer. Geräte, die nicht über Entra ID authentifizieren (alte VPN-Lösungen, ältere Branchensoftware mit eigener Auth), bleiben außen vor.
- CA-Policies sind komplex zu testen. Die Kombination mehrerer Policies kann unerwartete Effekte haben. Microsoft empfiehlt explizit, vor und nach Änderungen mit dem "What-If"-Tool zu prüfen, wie eine spezifische Anmeldung bewertet würde.
Rollout-Reihenfolge in der Praxis
Wer ein CA-Konzept neu aufbaut, sollte in drei Phasen vorgehen — analog zur Empfehlung in der Microsoft-Dokumentation:
- Phase 1 – Grundlage (Woche 1–2): Break-Glass-Accounts, MFA für alle, Block Legacy-Auth, Naming-Convention, Report-Only-Tests.
- Phase 2 – Erweiterung (Woche 3–6): Geräte-Compliance für Unternehmens-Endgeräte, App-Protection für BYOD, Länder-Allowlist, stärkere MFA für Admins, Gast-Account-Policy.
- Phase 3 – Reife (ab Monat 2): Session-Controls, risikobasierte Anmeldung (sofern lizenziert), Notfall-Policies, Auditierung und Dokumentation.
Wichtig ist, jede Phase zu konsolidieren — also nicht alle Policies parallel auszurollen. Sonst wird die Fehlersuche im Problemfall sehr schwer.
Fazit
Conditional Access ist die zentrale Sicherheits-Steuerung im Microsoft-365-Tenant. Wer die zehn beschriebenen Regeln strukturiert umsetzt — mit sauberer Vorarbeit, Naming-Convention, Report-Only-Tests und Break-Glass-Accounts — hat ein deutlich höheres Schutzniveau als der Durchschnitt mittelständischer M365-Tenants. Die Umsetzung erfordert keine externen Tools, sondern primär Disziplin und Klarheit über die eigene Architektur.