Entra ID Security Defaults: Wann sie reichen und wann Conditional Access besser ist
Entra ID Security Defaults liefern einen schnellen, Microsoft-empfohlenen Mindestschutz: MFA wird durchgesetzt und Legacy authentication wird weitgehend unattraktiv. Das ist ideal, wenn du zügig Risiken reduzieren willst, ohne gleich ein Regelwerk zu bauen. Sobald Ausnahmen, Rollenlogik oder Audit-Anforderungen dazukommen, ist Conditional Access meist die passendere Lösung.
- Security Defaults: schnell, standardisiert, wenig Steuerung.
- Conditional Access: granular, testbar (Report-only), braucht Entra ID P1/P2.
- Für sauberen Rollout: Break-Glass-Konten, Sign-In Logs und Wellen-Umstellung einplanen.
Entscheidend ist nicht nur das Aktivieren, sondern das Betreiben: Alerts, Logs und regelmäßige Reviews machen den Schutz messbar und alltagstauglich.
Du sorgst dafür, dass M365 läuft. Wir sorgen dafür, dass niemand unbemerkt eindringt, heimlich mitliest und Schaden anrichtet.
Definition
Security Defaults sind vordefinierte Sicherheitsvorgaben in Microsoft Entra ID, die einen Basis-Schutz für Identität und Zugriff im Tenant aktivieren, insbesondere durch Multi-factor authentication (MFA) und Einschränkungen für unsichere Anmeldeverfahren. Sie sind kein frei modellierbares Regelwerk und ersetzen keine Conditional Access policies für differenzierte access policies.
Einleitung
Wenn ein Microsoft-365-Tenant „läuft“, ist er dadurch nicht automatisch sicher: Admin-Konten sind oft nur passwortgeschützt, und legacy authentication ist noch aktiv. Entra ID Security Defaults sind dafür gedacht, schnell einen Mindeststandard zu setzen: MFA erzwingen und alte Authentication protocols zurückdrängen. Der Nutzen ist pragmatisch: weniger Angriffsfläche, weniger Account-Übernahmen, weniger Feuerwehr-Einsätze im IT-Alltag.
Wie Security Defaults funktionieren
Security Defaults werden tenantweit im Microsoft Entra admin center aktiviert und setzen Microsoft-managed access policies durch. Typische Effekte: Benutzer und privileged administrators werden zur MFA-Registrierung geführt, und riskante Anmeldewege über legacy authentication werden blockiert oder stark eingeschränkt.
- MFA wird breit eingeführt und requiring MFA wird zur Standarderwartung.
- Blocking legacy senkt das Risiko von Password-Spraying und ähnlichen identity related attacks.
- Der Default ist bewusst pauschal: wenig Ausnahmen, wenig Feinsteuerung.
Wichtig: Security Defaults sind „aktiv“ im Sinne von Standardregeln, aber sie sind nicht „komplex“ konfigurierbar. Genau diese Einfachheit spart Zeit, kann aber bei Sonderfällen bremsen.
Abgrenzung zu Conditional Access
Conditional Access ist die Methode, um eigene access policies als Conditional Access policies zu definieren: nach Benutzergruppe, Rolle, App, Standort, Gerätezustand oder Risiko. Der entscheidende Unterschied: Security Defaults sind default-Logik, Conditional Access ist Design-Logik.
Conditional Access ist meist besser geeignet, wenn mindestens eines davon zutrifft:
- Es gibt unterschiedlich kritische Accounts (z. B. Global Administrator, Privileged Role Administrator) mit eigenen Anforderungen.
- Es braucht kontrollierte Ausnahmen für Anwendungen, Admins, Service-Prozesse oder device flows.
- Änderungen sollen messbar getestet werden, z. B. per Report-only mode, bevor sie „enabled“ sind.
Lizenzierung: Conditional Access erfordert in der Praxis Entra ID P1 / P2 (für viele Szenarien mindestens P1). Security Defaults sind dagegen für viele Tenants ohne zusätzlichen Lizenzkauf nutzbar. Das ist oft der Budget-Hebel: schnell Schutz erhöhen, ohne ein Lizenzprojekt zu starten.
Typische Einsatzszenarien und Anwendungsfälle
Security Defaults passen gut, wenn ein Tenant neu created wurde oder wenn in einem bestehenden Tenant schnell ein Grundschutz fehlt. Typisch ist der „wir wollen MFA jetzt, aber ohne Regelwerk“-Moment.
- Schneller MFA-Start für Standard-Accounts, ohne Rollen- und Gruppenmodell.
- Erste Gegenmaßnahme gegen legacy authentication, bevor Alt-Clients modernisiert sind.
- Übergangslösung, bis Conditional Access sauber designed und getestet ist.
Weniger passend wird es, wenn viele Ausnahmen nötig sind (z. B. ältere Mail-Clients, technische Konten, Spezial-Apps) oder wenn du unterschiedliche Schutzstufen pro organization/Abteilung brauchst.
Fokus: MFA und Schutz vor Legacy-Authentifizierung
Der größte Sicherheitsgewinn entsteht aus zwei Punkten: MFA reduziert die Wirkung gestohlener Zugangsdaten, und das Zurückdrängen von legacy authentication schließt Angriffswege, die keine modernen Kontrollen nutzen (z. B. fehlende moderne Token-Mechanismen). Praktisch relevant wird das bei Protokollen wie SMTP / IMAP / POP3 und Exchange ActiveSync, aber auch bei älteren Clients, die keine Modern authentication (OAuth2) können.
Aus Anwendersicht ist der Nutzen oft überraschend konkret: weniger „komische Anmeldeversuche“ und weniger Konto-Sperrungen nach Attacken, weil Angriffe früher scheitern.
Aktivierung, Deaktivierung und typische Auswirkungen
Die Aktivierung erfolgt im Entra admin center. Vorher sollte geprüft werden, welche accounts, administrators und Anwendungen betroffen sind, weil sich Anmeldeabläufe ändern: Nutzer werden zu Registrierungsprozessen geführt und können bei alten Clients „prompted“ werden oder scheitern.
Deaktivierung (disable defaults) ist möglich, aber riskant, wenn keine Alternative aktiv ist. Wer Security Defaults disabled, muss die Schutzwirkung durch Conditional Access oder andere Entra-ID-Mechanismen ersetzen, sonst wird der defaults tenant wieder „offen“.
Unbedingt einplanen: Emergency access accounts (break glass), die unabhängig abgesichert und dokumentiert sind, damit Administratoren sich nicht aussperren.
Überwachung, Logging und Audit-Spuren
Damit der Nutzen messbar wird, braucht es Routine in der Überwachung. In Entra ID sind dafür vor allem Sign-In Logs und Reports relevant: Welche sign-ins scheitern? Welche authentication protocols werden noch genutzt? Welche Benutzer haben MFA nicht abgeschlossen?
- Sign-In Logs: zeigen block events, Legacy-Use und betroffene Apps/Clients.
- Berichte: MFA-Registrierungsstatus, riskante Anmeldeversuche, Auffälligkeiten.
- Audit-Spuren: Änderungen an Einstellungen und Richtlinien für Nachweise.
So sinkt das Risiko nicht nur technisch, sondern auch operativ: weniger Störungen, weniger ungeplante Zeit für „Account wiederherstellen“ und nachvollziehbare Nachweise für interne Audits.
Best Practices: Rollout-Strategie und Migrationspfad
Ein sauberer Rollout reduziert Risiko und Zeitaufwand. Bewährt hat sich ein Wellen-Ansatz: erst Klarheit über Legacy-Nutzung, dann Registrierung, dann Durchsetzung.
- Vorbereitung: Break-Glass, betroffene Anwendungen (z. B. alte Mail-Clients) identifizieren, Kommunikationsplan.
- Rollout in Wellen: erst IT/Admins, dann Pilotgruppe, dann restliche Benutzer; Support-Fenster einplanen.
- Migrationspfad zu Conditional Access: Regeln im Report-only mode bewerten, dann enable, erst danach disable defaults.
Wenn du später Conditional Access einführst, zahlt sich diese Reihenfolge aus: Du bekommst schnelle Risikoreduktion, ohne dir die Option auf ein sauberes, gemanagtes Policy-Set zu verbauen.
Wann externe Unterstützung sinnvoll wird
Externe Unterstützung lohnt sich, wenn Zeitdruck und Risiko gleichzeitig hoch sind: viele Benutzer, mehrere Tenants, legacy-Protokolle, Admin-Sonderrollen und Nachweispflichten. Dann ist das Thema weniger „Schalter umlegen“ und mehr „Betriebsfähigkeit sicherstellen“: Wer wird wann betroffen, wie werden Störungen abgefangen, wie werden Logs ausgewertet, wie werden policies dauerhaft gepflegt.
Wenn du Security Defaults als Start nutzt oder auf Conditional Access migrierst, ist der größte Hebel ein klarer Betriebsprozess: Monitoring, Reaktion, Dokumentation und regelmäßige Reviews statt einmaliger Umsetzung.
Fazit
Entra ID Security Defaults sind der schnellste Weg zu einem soliden Mindestschutz: MFA wird durchgesetzt und legacy authentication wird zurückgedrängt. Conditional Access ist die bessere Wahl, sobald du Ausnahmen, Rollenlogik und kontrollierte Tests brauchst. Entscheidend ist, dass Überwachung und Betrieb mitgedacht werden, damit der Schutz im Alltag messbar bleibt.
Wenn du Security Defaults sauber aktivieren oder gezielt zu Conditional Access migrieren willst, lohnt sich ein strukturierter Rollout mit klaren Verantwortlichkeiten und aussagekräftigen Sign-In-Auswertungen.
Häufige Fragen
Brauchen Security Defaults Entra ID P1 oder P2?
In vielen Tenants lassen sich Security Defaults ohne zusätzliche Entra ID P1/P2-Lizenz nutzen. Conditional Access-Funktionen für eigene Policies erfordern in der Praxis typischerweise Entra ID P1 (oder P2 für erweiterte Szenarien).
Blockieren Security Defaults immer Legacy authentication?
Security Defaults zielen darauf ab, legacy authentication stark einzuschränken, damit unsichere Anmeldewege unattraktiv werden. Ob einzelne ältere Anwendungen betroffen sind, zeigt sich über Sign-In Logs und sollte vor dem breiten Rollout geprüft werden.
Was ist der häufigste Rollout-Fehler bei Security Defaults?
Security Defaults aktivieren, ohne Break-Glass-Konten und ohne Analyse der betroffenen Clients/Protokolle. Das führt oft zu vermeidbaren Störungen bei Benutzern oder zu Admin-Zugriffsproblemen.
Wie migriert man sauber von Security Defaults zu Conditional Access?
Zuerst Conditional Access policies modellieren und im Report-only mode bewerten, dann schrittweise aktivieren (enabled) und erst danach Security Defaults deaktivieren. Die Migration sollte durch Log-Auswertung und klare Ausnahme-Regeln gestützt werden.
