Welche Sicherheitsbaseline braucht ein Microsoft-365-Tenant direkt nach der Migration – MFA, Conditional Access und Break-Glass richtig aufsetzen?

Prioritäten nach dem Go-Live: Sofortmaßnahmen vs. bewusst verzögerte Änderungen zur Stabilisierung des Betriebs

Unmittelbar nach dem Go-Live eines Microsoft-365-Tenants entscheidet nicht die Menge an „aktivierten Security-Features“ über die reale Sicherheitslage, sondern die Reihenfolge. In dieser Phase überlagern sich Restarbeiten aus der Migration, neu auftretende Client-Probleme, unvollständige Identitätsdaten und eine erhöhte Änderungsrate im Tenant. Sicherheitsmaßnahmen müssen daher nach Risiko und Betriebswirkung priorisiert werden: Was schließt akute Angriffswege ohne Nebenwirkungen, und was sollte erst nach belastbaren Telemetriedaten, Support-Readiness und sauberer Ausnahmeverwaltung folgen?

Ein praktikables Prioritätenmodell trennt Maßnahmen, die sofort wirken und primär administrativ abgesichert werden können, von Änderungen, die tief in Authentifizierungsflüsse, Clients oder Automatisierungen eingreifen. Diese Abgrenzung reduziert das Risiko von Self-Lockouts, unplanbaren Ticketwellen und Produktionsstörungen, ohne offensichtliche Sicherheitslücken offen zu lassen.

Sofortmaßnahmen: Angriffsfläche reduzieren, ohne den Betrieb zu destabilisieren

Sofortmaßnahmen zielen auf zwei Ebenen: den Schutz privilegierter Identitäten und die Eliminierung bekannter „High-Impact“-Einfallstore. Priorität haben Konfigurationen, die mit klarer Rückfalloption implementierbar sind, kaum Client-Abhängigkeiten besitzen und sich sauber überwachen lassen. Dazu zählen insbesondere Absicherungen im Identitäts- und Rollenmodell, Baseline-Logging sowie die Abschaltung von Anmeldepfaden, die bereits heute häufig automatisiert angegriffen werden.

• Privilegierte Konten sofort härten: MFA für alle Konten mit Entra-Rollen und kritischen Microsoft-365-Rollen aktivieren, bevorzugt mit separater Admin-Identität; Risiko senken durch Deaktivieren unsicherer Authentifizierungsmethoden und konsequente Rollenminimierung über Microsoft Entra ID-Rollen und Privileged Identity Management (PIM) (sofern vorhanden).
• Legacy-Authentifizierung kurzfristig blockieren: Sperre für Basic Auth in Exchange Online und verwandten Endpunkten prüfen und durchsetzen; besonders relevant sind IMAP4, POP3 und Basic Auth für SMTP AUTH (nur wenn zwingend benötigt), sowie alte Office-Clients, die keine moderne Authentifizierung nutzen.
• Protokollierung und Sichtbarkeit aktivieren: Audit- und Sign-in-Logs in Microsoft Entra ID sowie das Unified Audit Log in Microsoft Purview sicherstellen; Alarme für anomale Anmeldungen und Admin-Aktivitäten konfigurieren, damit spätere Conditional-Access-Änderungen auf Daten statt auf Annahmen basieren.
• Notfallzugang vor jeder Richtlinie: Break-Glass-Konten anlegen, testen und aus allen MFA-/CA-Policies explizit ausschließen, bevor breitere Zugriffsrichtlinien aktiv werden; mindestens zwei Konten, getrennte Anmeldedaten, gesicherte Aufbewahrung, dokumentierter Testablauf.

Diese Maßnahmen lassen sich meist mit begrenzter Benutzerwirkung umsetzen, greifen jedoch unmittelbar dort, wo Angreifer typischerweise ansetzen: bei privilegierten Identitäten und bei Protokollen, die Kennwortspraying und Credential-Stuffing erleichtern. Entscheidend bleibt, dass jede Änderung durch Logs und klar definierte Rollback-Schritte abgesichert ist.

Bewusst verzögerte Änderungen: Warum „zu viel“ Sicherheit am Tag 1 oft riskanter ist

Mehrstufige Conditional-Access-Strategien, strikte Gerätezustandsprüfungen und breit ausgerollte MFA-Pflichten können zwar das Sicherheitsniveau erhöhen, verursachen unmittelbar nach dem Go-Live aber häufig Instabilität: nicht inventarisierte Clients, fehlende Geräteeinträge, unklare Ownership bei Servicekonten oder Applikationen, die noch auf alten Auth-Flows basieren. Wird in dieser Lage „global“ abgesichert, steigt der Anteil an Fehlalarmen, und der Betrieb reagiert mit pauschalen Ausnahmen – ein Muster, das spätere Härtung massiv erschwert.

Typische Kandidaten für eine geplante Verzögerung sind Richtlinien, die Geräte-Compliance (Intune), hybride Join-Zustände, Netzwerkzonen oder App-spezifische Authentifizierungsbesonderheiten voraussetzen. Auch das sofortige Erzwingen sehr kurzer Sitzungsdauern kann Kollateralschäden in mobilen Szenarien, bei Offline-Clients oder bei Drittanbieter-Integrationen auslösen, wenn Telemetrie und Supportprozesse noch nicht stehen.

Entscheidungskriterien: Risiko, Rückfallpfad, Abhängigkeiten

Die Priorisierung gelingt, wenn jede Maßnahme anhand weniger technischer Kriterien bewertet wird. Erstens: Schließt die Änderung einen bekannten, extern ausnutzbaren Angriffsweg (zum Beispiel Basic Auth/Legacy-Login) oder „optimiert“ sie lediglich das Sicherheitsniveau? Zweitens: Existiert ein getesteter Rückfallpfad, der ohne Tenant-weiten Schaden funktioniert? Drittens: Welche technischen Abhängigkeiten bestehen – Clients, Protokolle, Automatisierungen, Drittanbieter-Apps, Identity Federation – und wie vollständig ist die Inventarisierung?

• Risikoreduktion pro Eingriff: Priorität erhalten Maßnahmen, die externe Angriffsvektoren reduzieren, etwa die Sperre von legacy authentication oder die Absicherung von Konten in Rollen wie Global Administrator und Privileged Role Administrator.
• Rollback-Fähigkeit: Jede CA-Änderung benötigt einen definierten Notfallhebel, beispielsweise temporäres Deaktivieren einer Policy oder Zugriff über ein geprüftes Break-Glass-Konto; Konfigurationsstände sollten nachvollziehbar versioniert werden (z. B. über Exporte und Change-Dokumentation).
• Abhängigkeitsgrad: Eingriffe mit hoher Client- und Protokollabhängigkeit (z. B. „Require compliant device“) werden erst nach Validierung der Flotte und nach Pilotierung aktiviert; fehlende Daten führen sonst zu pauschalen Ausnahmen.
• Support- und Kommunikationsreife: Maßnahmen mit Benutzerinteraktion (Authenticator-Registrierung, zusätzliche Prompts) benötigen klaren Prozess, FAQ, Eskalation und Monitoring der Sign-in-Fehlercodes, bevor sie in die Breite gehen.

Damit entsteht eine belastbare Go-Live-Posture: zuerst administrative Überlebensfähigkeit und transparente Sign-in-Telemetrie, danach kontrollierte Härtung in Wellen. Wer diese Reihenfolge einhält, verhindert, dass Sicherheitsdruck zu unkontrollierten Ausnahmen führt – und schafft die Voraussetzung, Conditional Access später präzise statt pauschal zu betreiben.

MFA technisch korrekt einordnen: Token-Ausstellung, Legacy-Authentifizierung, Client-Verhalten und Besonderheiten bei Dienst- und Administratorkonten

Multi-Faktor-Authentifizierung (MFA) wirkt nach außen wie eine einfache Zusatzabfrage. Technisch greift sie jedoch in mehrere Schichten der Microsoft-365-Authentifizierung ein: interaktive Anmeldungen, Token-Ausstellung, Refresh-Verhalten und Protokollpfade, die MFA gar nicht unterstützen. Wer MFA-Richtlinien ohne diese Einordnung aktiviert, erzeugt meist keine „mehr Sicherheit“, sondern unklare Fehlerbilder: wiederholte Sign-in-Prompts, Token-Schleifen, unerwartete App-Abbrüche oder dauerhafte Ausnahmen, die die Baseline aushöhlen.

Token-Ausstellung: Wo MFA tatsächlich durchgesetzt wird

In Entra ID (Azure AD) wird MFA primär als Bedingung bei der Token-Ausstellung (OAuth 2.0/OpenID Connect/SAML) bewertet. Der zentrale Punkt ist nicht die Anwendung, sondern das Ergebnis der Sign-in-Transaktion: Ob ein Zugriffstoken (und ggf. ein Refresh Token) für eine Ressource ausgestellt wird, hängt von der Erfüllung der Richtlinien ab. Conditional Access (CA) entscheidet dabei kontextabhängig, ob zusätzliche Claims wie amr (Authentication Methods References) oder ein Schritt zur Step-up-Authentifizierung erforderlich sind. Ein Token bleibt bis zum Ablauf gültig, auch wenn später strengere Richtlinien eingeführt werden. Eine beschleunigte Durchsetzung entsteht erst durch Token-Ablauf, explizite Sitzungssteuerung (z. B. Sign-in frequency) oder durch den Widerruf von Refresh Tokens („Revoke sessions“).

Für die Praxis bedeutet das: MFA-Einführung ohne Planung der Token-Lebenszyklen führt zu einer Phase, in der Benutzer noch mit „alten“ Tokens arbeiten, während andere bereits Step-up-Prompts sehen. Das ist kein Fehler, sondern eine Folge der Token-Architektur. Kritisch wird es, wenn parallel „Security Defaults“ und CA-Policies aktiv sind oder wenn per-user MFA (legacy) zusätzlich eingeschaltet bleibt; dann entstehen konkurrierende Anforderungen mit uneinheitlichem Prompting.

Legacy-Authentifizierung: Protokolle, die MFA aushebeln oder blockieren

Legacy Authentication meint Anmeldepfade, die keine modernen Tokenflüsse nutzen, etwa Basic Auth über IMAP, POP oder SMTP AUTH oder ältere Office-/Exchange-Clients ohne moderne Authentifizierung. Diese Protokolle können MFA nicht „verstehen“; sie funktionieren entweder gar nicht mehr oder erzwingen unsichere Umgehungen (App-Kennwörter, sofern im Tenant noch zulässig). Ein häufiger Baseline-Fehler ist, MFA breit zu aktivieren, aber Legacy-Anmeldepfade nicht konsequent zu blockieren. Dann bleibt ein Nebenweg offen, der CA-Entscheidungen umgeht oder zumindest die Wirksamkeit reduziert.

Microsoft 365 hat Basic Auth für Exchange Online weitgehend deaktiviert, dennoch existieren in vielen Tenants Restbestände: einzelne Protokolle, Scanner/MFPs, ältere Clients oder SMTP-Relays. Diese müssen vor der MFA-Schärfung technisch inventarisiert werden, weil die Symptome sonst als „MFA-Probleme“ fehlinterpretiert werden, obwohl tatsächlich ein nicht MFA-fähiger Anmeldeweg genutzt wird.

Client-Verhalten: Prompting, WAM, Broker und Token-Caches

Die Benutzererfahrung bei MFA hängt stark vom Client-Stack ab. Auf Windows steuern Web Account Manager (WAM) und der Anmelde-Broker die Tokenablage und das Silent Refresh. Moderne Office-Apps verwenden in der Regel moderne Authentifizierung und können Step-up sauber ausführen. Ältere Office-Versionen, ältere Betriebssysteme oder fehlerhafte Geräte-/Identitätszustände zeigen dagegen häufig wiederkehrende Prompts, weil Tokens nicht persistiert werden, der Primary Refresh Token (PRT) fehlt oder Gerät/Benutzer nicht wie erwartet „compliant“ bzw. „hybrid joined“ sind.

Auch CA-Sitzungssteuerungen beeinflussen das Verhalten direkt: Eine kurze Sign-in frequency kann in Kombination mit großen Client-Footprints (Outlook, Teams, OneDrive, Browser-Sessions) zu einer signifikanten Prompt-Dichte führen. Der Eindruck „MFA nervt“ ist dann kein Akzeptanzthema, sondern eine konkret konfigurationsgetriebene Folge. Stabilität entsteht, wenn CA die interaktive Authentifizierung dort erzwingt, wo sie sinnvoll ist, und gleichzeitig Token-Reuse für unkritische Folgezugriffe zulässt.

• Token-Reset bei Rollout-Problemen: Über Graph-basierte Admin-Funktionen „Revoke sessions“ im Benutzerprofil (Widerruf von Refresh Tokens). Das alte AzureAD-PowerShell-Modul gilt als abgekündigt und sollte nicht mehr als Standardweg eingeplant werden.
• Typische Client-Indikatoren: Sign-in Logs mit Client app „Mobile Apps and Desktop clients“ vs. „Other clients“; letzteres deutet oft auf Legacy-Pfade oder nicht-brokerfähige Flows hin.
• Gezielte CA-Sitzungssteuerung: „Sign-in frequency“ nur für hochriskante Apps/Scopes oder administrative Portale; pauschale Werte verursachen Mehrfachprompts in Teams, Outlook und Browser-Sessions.

Dienstkonten und Automatisierung: MFA ist nicht das richtige Kontrollinstrument

Dienstkonten, geplante Jobs und Integrationen scheitern häufig an einer falsch verstandenen MFA-Pflicht. MFA schützt interaktive Benutzeranmeldungen. Für nicht-interaktive Zugriffe sind andere Kontrollen maßgeblich: Workload-Identitäten (App-Registrierungen), zertifikatsbasierte Authentifizierung, Managed Identities (wo verfügbar) sowie eng begrenzte App- und API-Berechtigungen. Wo trotzdem Benutzerkonten als „Service Accounts“ missbraucht werden, erzwingt MFA entweder einen Betriebsausfall oder eine Ausnahmepolitik, die später unkontrolliert wächst.

Stabil ist ein Design, das Automatisierung konsequent auf App-Identitäten umstellt und interaktive Ausnahmen minimiert. Falls Übergangsphasen unvermeidbar sind, müssen diese Konten mindestens durch starke, zufällige Kennwörter, strikte Anmeldeeinschränkungen, Token- und Sitzungsrestriktionen sowie Monitoring geschützt werden. Eine pauschale MFA-Ausnahme ist dabei der schlechteste Kompromiss, weil sie häufig auch Administratorportale oder Graph-Zugriffe unbeabsichtigt „miterlaubt“.

Administratorkonten: Step-up, privilegierte Rollen und getrennte Identitäten

Für privilegierte Rollen ist MFA nicht nur „auch“, sondern ein zwingender Bestandteil einer kontrollierten Token-Ausstellung. Administrative Tätigkeiten erfolgen typischerweise über Browser und Portale, die Step-up verlässlich unterstützen. Die Risiken liegen weniger im Prompt selbst als im Umfang der Ausnahmen, im Vermischen von Alltags- und Adminidentität sowie in dauerhaft aktiven Rollen. Privileged Identity Management (PIM) reduziert die Zeitfenster mit erhöhten Rechten; Conditional Access kann diese Aktivierungswege zusätzlich absichern, etwa durch verpflichtende phishing-resistente Methoden.

Ein wiederkehrender Fehlzustand entsteht, wenn für Administratoren „zur Sicherheit“ globale Ausschlüsse definiert werden, um Supportfälle zu reduzieren. Damit werden gerade die Konten mit dem höchsten Schadpotenzial aus der stärksten Kontrolle herausgenommen. Korrekt ist die umgekehrte Priorität: Admin-Scopes zuerst stabilisieren (MFA, moderne Auth, klarer Client-Pfad), dann erst die Breite ausrollen. Trennung in dedizierte Admin-Konten unterstützt dabei nicht nur die Policy-Logik, sondern auch die Nachvollziehbarkeit in Logs, Audits und Incident Response.

Praxisbaseline mit Conditional Access: Break-Glass-Konten, Ausnahme- und Notfallregeln, stufenweiser Rollout, Schutz privilegierter Rollen und Vermeidung typischer Fehlkonfigurationen

Break-Glass-Konten: Designziele, Anlage und harte Leitplanken

Break-Glass-Konten dienen ausschließlich dem kontrollierten Wiederzugang, wenn die regulären Administratorpfade durch Fehlkonfigurationen, Ausfall eines Identitätsproviders oder eine kompromittierte MFA-Kette blockiert sind. Ihre Sicherheitslogik unterscheidet sich von Standard-Admin-Konten: minimale Nutzung, maximale Überwachung, keine Abhängigkeit von komplexen Richtlinien. In Microsoft Entra ID (ehemals Azure AD) werden Break-Glass-Identitäten als Cloud-only Benutzer ohne produktive Postfächer angelegt, mit sehr langen, einzigartigen Kennwörtern, getrennt verwahrten Geheimnissen und klar definiertem Besitz- und Freigabeprozess.

Technisch kritisch ist die Interaktion mit Conditional Access (CA): Break-Glass-Konten müssen in CA gezielt ausgenommen werden, da sie sonst bei einer fehlerhaften Richtlinie ebenfalls ausgesperrt werden. Gleichzeitig darf diese Ausnahme nicht als generische „Admins ausnehmen“-Schablone enden, weil damit die gesamte Schutzwirkung von CA unterlaufen wird. Der praktikable Kompromiss ist ein kleines, namentlich bekanntes Kontenset mit eng begrenzten Rollen und maximaler Detektion (Anmeldealarme, PIM-Alerts, SIEM-Korrelation).

• Anlage (Identität und Hygiene): Break-Glass als Cloud-only Benutzer, kein Sync, keine Lizenzzuweisung, eindeutige Benennung (z. B. bg-admin-01), kein Alltagseinsatz, Passwort als Offline-Secret (z. B. HSM/versiegelter Umschlag) mit dokumentiertem Rotationstermin.
• Rollenmodell: Zwei getrennte Konten mit unabhängigen Secrets; mindestens eines mit Global Administrator nur für den Notfall, optional ein zweites mit Privileged Authentication Administrator für MFA-/CA-Reparaturen; Rollen bevorzugt über PIM „eligible“, nur im Ausnahmefall dauerhaft aktiv.
• CA-Ausnahme strikt begrenzen: In CA nicht „Alle Administratoren“ ausnehmen, sondern explizit die Benutzerobjekte bg-admin-01 und bg-admin-02. Keine weiteren Ausnahmen in derselben Regel, um späteres Scope-Creep zu verhindern.
• Alarmierung bei Nutzung: Sign-in Logs auf diese UPNs überwachen; in Microsoft Sentinel oder alternativen SIEMs Regeln auf UserPrincipalName und ConditionalAccessStatus plus Geolocation/Impossible Travel auswerten; Ticketpflicht bei jedem Login.

Ausnahme- und Notfallregeln in Conditional Access: präzise Scopes statt Blanket-Bypasses

Eine stabile Baseline trennt funktionale Ausnahmen (technisch erforderlich) von Notfallmechanismen (operativ erforderlich). Funktionale Ausnahmen betreffen typischerweise nicht-interaktive Zugriffe, Legacy-Clients oder Übergangsphasen in der Authentifizierungskette. Notfallmechanismen betreffen den Rückweg, wenn die Baseline selbst fehlschlägt. Beide Kategorien werden in CA mit klaren Anwendungsbereichen, eigenständigen Policies und konsistenter Namenskonvention umgesetzt, damit Ausnahmen nicht unbemerkt wachsen.

Bei Workload-Identitäten (Service Principals/Managed Identities) gilt: Conditional Access ist primär für Benutzer- und interaktive Anmeldungen konzipiert. Für App-only Zugriffe entstehen Absicherung und Kontrolle über Application permissions, Zertifikate, Rotation, Workload-Identity-Richtlinien (wo verfügbar) sowie restriktive Zugriffsmodelle in den Zielsystemen. Für Benutzerkonten mit Hintergrundprozessen ist eine saubere Migration auf moderne Authentifizierung (z. B. App-Identität mit Zertifikat oder Managed Identity) der richtige Weg; „MFA-Ausnahme für Dienstkonto“ bleibt ein befristeter Übergang und muss als Risiko akzeptiert und kompensiert werden.

Stufenweiser Rollout: von Pilotgruppen zu „All users“ ohne Betriebsbruch

Der Rollout beginnt mit einer Pilotgruppe, die repräsentative Clienttypen abdeckt: Windows (Entra-joined/Hybrid), macOS, Mobilgeräte, Browserzugriffe und ggf. VDI. Für diese Gruppe wird eine CA-Policy erstellt, die MFA erzwingt, und mit „Report-only“ parallel validiert, bevor sie auf „On“ gestellt wird. „Report-only“ liefert belastbare Sign-in-Daten: Welche Apps werden betroffen, welche Flows würden blockiert, und wo greifen unerwartete Ausnahmen.

Nach dem Pilot folgen gestaffelte Wellen. Jede Welle erweitert die Zielgruppe per Entra-Gruppe und reduziert Sonderfälle. Kritisch ist die Konsistenz: Es sollte immer genau eine MFA-basierte Baseline-Policy pro Zielpopulation geben, statt mehrere sich überschneidende Policies. Überschneidungen sind eine häufige Ursache für schwer erklärbare Effekte, weil CA-Entscheidungen aus der Gesamtheit zutreffender Policies abgeleitet werden. Zusätzlich empfiehlt sich eine explizite Block-Policy für Legacy-Authentifizierung, sobald die Sign-in-Logs keine produktiven Abhängigkeiten mehr zeigen.

• Pilot (Report-only, dann On): CA-Policy „MFA-Pilot“ für Gruppe CA-MFA-Pilot, Cloud Apps All cloud apps, Grant Require multifactor authentication, Ausschluss nur bg-admin-01/bg-admin-02.
• Wellenprinzip: Gruppen CA-MFA-Wave-01, CA-MFA-Wave-02 usw.; nach Stabilisierung je Welle Zusammenführung in eine Baseline-Gruppe, um Policy-Sprawl zu vermeiden.
• Legacy-Block getrennt ausrollen: Eigene Policy mit Bedingung Client apps = Other clients (Legacy authentication clients) und Grant Block access; vor Aktivierung Sign-ins nach ClientAppUsed und betroffenen Workloads prüfen.
• Break-Glass regelmäßig testen: Kontrollierte Notfallübung (z. B. quartalsweise) mit dokumentiertem Ablauf; Validierung, dass Ausnahmen greifen und Logging/Alarmierung auslösen.

Schutz privilegierter Rollen: stärkere Anforderungen, weniger Angriffsfläche

Privilegierte Rollen benötigen eine eigene CA-Schicht, weil die Auswirkungen kompromittierter Admin-Sessions größer sind als bei Standardbenutzern. Dafür werden Zielgruppen über Rollen (Directory roles) oder dedizierte Admin-Gruppen gebildet. Eine bewährte Trennung ist: Baseline-MFA für alle Benutzer und eine zusätzliche Admin-Policy für Zugriff auf Admin-Portale und privilegierte Aktionen. Wo möglich, reduziert PIM die permanente Rolleninhaberschaft und erzwingt Just-in-Time-Aktivierungen mit Genehmigung und Begründung.

Bei der MFA-Methode ist die technische Zielrichtung klar: Für privilegierte Konten sollten phishing-resistente Verfahren bevorzugt werden, etwa FIDO2-Sicherheitsschlüssel oder passkey-basierte Anmeldungen (wo im Tenant und Clientbestand unterstützt). SMS gilt aufgrund bekannter Angriffs- und Zuverlässigkeitsprobleme in professionellen Baselines nicht als gleichwertig; falls übergangsweise erforderlich, muss die Nutzung zeitlich begrenzt, dokumentiert und kompensiert werden.

Typische Fehlkonfigurationen und systematische Gegenmaßnahmen

Fehlkonfigurationen entstehen selten durch einzelne „falsche Klicks“, sondern durch Muster: zu breite Ausnahmen, parallele Mechanismen und unklare Verantwortlichkeiten. Besonders riskant sind globale Ausschlüsse („Exclude: All admins“, „Exclude: Trusted locations“) ohne Governance, da sie Angriffswege erzeugen, die in der CA-Auswertung nicht als Fehler erscheinen. Ebenso problematisch sind MFA-Altmechanismen, die neben CA bestehen bleiben und zu uneinheitlichen Prompts führen, weil unterschiedliche Enforcement-Pfade greifen.

Die Gegenmaßnahme ist ein enges Change- und Beobachtungsregime: jede neue CA-Policy mit eindeutiger Zielpopulation, klarer Begründung für Ausnahmen, Test im „Report-only“-Modus und eine feste Prüfroutine über Sign-in-Logs (inklusive Details zu angewandten Policies). Ergänzend sollte eine technische Dokumentation existieren, die Policy-Namen, Scopes, Ausschlüsse, Notfallprozeduren und Verantwortliche abbildet. Ohne diese Metadaten werden selbst korrekte Policies nach Monaten unwartbar und damit faktisch unsicher.

• Übergreifende Ausnahmen: Keine Ausschlüsse wie All privileged roles oder große Gruppen „MFA-Exempt“ ohne Ablaufdatum; Ausnahmen mit Owner, Ticketreferenz und Review-Zyklus führen.
• Policy-Überlappung ohne klare Priorität: Statt vieler teilredundanter Policies eine Baseline-Policy pro Population; Änderungen zuerst in Report-only prüfen und die CA-Auswertung in Sign-in Logs auf „Applied policies“ kontrollieren.
• Parallelbetrieb alter MFA-Enforcement-Pfade: Einheitliche Steuerung über Conditional Access und Authentifizierungsmethoden-Richtlinien; doppelte Prompt-Ursachen (z. B. app-spezifische MFA-Regeln) identifizieren und konsolidieren.
• Blindes Vertrauen in „Trusted locations“: IP-basierte Ausnahmen nur mit nachweisbarer Netzhoheit und klarer Bedrohungsannahme; keine pauschale MFA-Deaktivierung für Büro-IP-Ranges.
• Ungeprüfte Dienst- und Automationskonten: Sign-ins nach nicht-interaktiven Mustern auswerten; Migration auf App-Registrierungen mit Zertifikat/Managed Identity priorisieren; temporäre Ausnahmen mit Sunset-Datum versehen.