Conditional Access greift nicht: Warum MFA ausbleibt oder Anmeldungen plötzlich blockiert werden

Wie Conditional Access wirklich ausgewertet wird: parallele Policies, kombinierte Wirkung und „Block hat Vorrang“

Conditional Access (CA) wirkt in der Praxis oft „unerklärlich“, weil die Auswertung nicht als lineare Wenn-dann-Kette erfolgt. Stattdessen bewertet Microsoft Entra ID alle relevanten Richtlinien parallel gegen den konkreten Anmeldekontext (Benutzer, App, Clienttyp, Standort, Gerät, Risiko, Authentifizierungsstärke etc.). Aus dieser parallelen Bewertung entsteht eine kombinierte Entscheidung – und genau hier liegt der Kern vieler Missverständnisse: Mehrere Policies können gleichzeitig zutreffen. Dabei werden Anforderungen aus Grant Controls grundsätzlich zusammengeführt, während Block access als harte Entscheidung jede erfolgreiche Anmeldung verhindert.

Parallele Auswertung: Richtlinien laufen nicht „der Reihe nach“

CA-Richtlinien werden nicht in einer Reihenfolge „abgearbeitet“, sondern jeweils einzeln gegen denselben Sign-in geprüft. Eine Policy ist dabei entweder „trifft zu“ oder „trifft nicht zu“ – basierend auf Zuweisungen (Users/Groups, Cloud-Apps/Actions) und Bedingungen (Conditions). Nur Policies im Zustand On fließen in die effektive Entscheidung ein; Policies im Zustand Report-only liefern nur Simulationsresultate, ändern aber die tatsächliche Durchsetzung nicht.

Wichtig ist außerdem der Unterschied zwischen nicht zutreffend und zutreffend ohne zusätzliche Kontrollen: Eine Richtlinie, die aufgrund eines Scopes oder einer Bedingung nicht greift, ist für diese Anmeldung faktisch unsichtbar. Eine Richtlinie, die greift, aber keine Grant Controls „erzwingt“ (zum Beispiel weil sie nur Session Controls konfiguriert), kann trotzdem Auswirkungen haben – jedoch nicht im Sinne einer MFA-Abfrage.

Kombinierte Wirkung: Aus mehreren Treffern wird eine effektive Entscheidung

Treffen mehrere CA-Richtlinien gleichzeitig zu, kombiniert Entra ID deren Anforderungen. Dabei gilt vereinfacht: Was zusätzlich gefordert wird, muss insgesamt erfüllt werden; was irgendwo verboten wird, ist insgesamt verboten. Daraus ergeben sich typische Situationen, in denen MFA „fehlt“ oder Logins „plötzlich“ blockiert werden – ohne dass eine einzelne Policy für sich genommen so aussieht, als wäre sie dafür verantwortlich.

Besonders relevant ist das Zusammenspiel aus Grant Controls (z. B. MFA bzw. Authentifizierungsstärke, compliant device, Microsoft Entra joined device, Terms of Use) und Block-Entscheidungen. Block ist dabei kein „Kontrollpunkt“, sondern eine harte Kante: Sobald eine zutreffende Policy Block access fordert, gibt es für diesen Sign-in kein „Ausweichen“ über eine weniger strenge Policy.

„Block hat Vorrang“: Priorität von Block und kumulativen Anforderungen

Für den Betriebsalltag lässt sich die kombinierte Auswertung auf zwei Regeln herunterbrechen: (1) Block access setzt sich immer durch. (2) Anforderungen aus Grant Controls addieren sich, sobald mehrere Richtlinien greifen. Dadurch entsteht häufig der Eindruck, dass Conditional Access „überreagiert“ – tatsächlich werden aber nur mehrere, gleichzeitig gültige Entscheidungen konsistent zusammengeführt.

Eine verbreitete Fehlinterpretation betrifft die Erwartung, dass eine „MFA-Policy“ eine andere Policy „ersetzt“. Das passiert nicht. Wenn beispielsweise eine Richtlinie „Zugriff nur von compliant devices“ verlangt und eine zweite Richtlinie „MFA/Authentifizierungsstärke für alle externen Standorte“, dann gilt für externe Sign-ins von nicht-complianten Geräten: Entweder wird blockiert (wenn die geforderte Kombination nicht erfüllt werden kann) oder es sind sowohl die geforderte Authentifizierungsstärke als auch Compliance nachzuweisen – je nach konkret gesetzten Grant Controls.

• Block hat Vorrang: Sobald eine zutreffende Richtlinie Block access fordert, ist das Ergebnis Block – auch wenn eine andere zutreffende Richtlinie „nur“ Require multifactor authentication verlangt.
• Grant Controls sind kumulativ: Treffen Richtlinien zu, die verschiedene Kontrollen verlangen, müssen diese insgesamt erfüllt werden, z. B. Require authentication strength: Phishing-resistant MFA plus Require device to be marked as compliant.
• „Require one of the selected controls“ ist kein Freifahrtschein: Diese Option wirkt nur innerhalb einer einzelnen Policy. Mehrere Policies können dennoch insgesamt mehrere Anforderungen erzeugen, weil jede Policy ihre eigene „one of“-Logik auswertet.
• Ausnahmen wirken nur pro Policy: Ein Exclude (z. B. Benutzergruppe oder Standort) „hebt“ ausschließlich diese einzelne Richtlinie auf. Andere zutreffende Policies bleiben unverändert wirksam.

Warum „keine MFA-Abfrage“ nicht zwingend bedeutet, dass keine Policy gegriffen hat

Selbst wenn eine MFA-Anforderung objektiv besteht, kann die Nutzerwahrnehmung „keine MFA“ sein. Grund ist, dass CA keine „Abfrage“ erzwingt, sondern einen Authentifizierungszustand verlangt. Wenn dieser bereits erfüllt ist, erscheint keine zusätzliche Interaktion.

• Vorhandene starke Anmeldung: Eine aktuelle MFA-Authentifizierung kann über Token-/Session-Mechanismen bereits vorliegen; dann wird die Anforderung erfüllt, ohne dass erneut ein Prompt sichtbar wird.
• Passkeys oder CBA ohne „MFA-Popup“: Bei passwortloser Anmeldung oder zertifikatbasierter Authentifizierung kann die Benutzerinteraktion anders aussehen; entscheidend ist, ob die geforderte Authentifizierungsstärke erreicht wird, nicht ob ein klassischer MFA-Dialog erscheint.
• Clienttyp beeinflusst den Ablauf: Browser, Modern Auth Clients und bestimmte Protokolle verhalten sich unterschiedlich; CA-Entscheidungen gelten grundsätzlich, aber die sichtbare Challenge hängt davon ab, wie der Client den nächsten Auth-Schritt umsetzt.

Für die Ursachenanalyse ist daher entscheidend, nicht nur auf „hat nach MFA gefragt“ zu schauen, sondern auf die tatsächliche CA-Entscheidung im Sign-in-Kontext: Welche Policies waren zutreffend, welche Grant Controls wurden verlangt, und welche davon galten als bereits erfüllt.

Typische Fehlkonfigurationen, die MFA verhindern oder Zugriffe blockieren: Ausnahmen, Legacy-MFA, Scope, Standorte, Gerätebedingungen, App-Zuweisungen

Ausnahmen (Exclude) zu breit oder falsch platziert

Die häufigste Ursache für „keine MFA-Abfrage“ ist keine kaputte Richtlinie, sondern eine zu großzügige Ausnahme. Conditional Access wertet „Exclude“-Scopes pro Richtlinie strikt aus: Sobald ein Benutzer, eine Gruppe, ein Standort oder eine Workload-Identität im Exclude landet, ist die betreffende Policy für diesen Sign-In vollständig raus – auch wenn alle anderen Bedingungen eigentlich passen würden. In Umgebungen mit mehreren Policies führt das dazu, dass die „MFA-Policy“ zwar existiert, aber für genau die relevanten Personen oder Szenarien nicht greift.

Besonders tückisch sind dynamische Gruppen oder verschachtelte Gruppen, die im Alltag ihre Mitgliedschaften verändern. Ebenso riskant sind „Notfall“-Ausnahmen, die versehentlich auf reguläre Admins ausgeweitet wurden, oder Excludes für „Trusted locations“, die zu groß definiert sind und damit MFA faktisch überall aushebeln.

• Typischer Fehler: Eine MFA-Richtlinie enthält Users: Include = All users, aber gleichzeitig Exclude = All privileged roles oder eine große Admin-Gruppe; damit sind genau die Konten ausgenommen, für die MFA erwartet wird.
• Übersehene Dynamik: Eine dynamische Gruppe im Exclude basiert auf Attributen wie Abteilung/Standort; Änderungen in HR/Entra-ID-Attributen verschieben Benutzer unbemerkt in die Ausnahme.
• Fehlannahme bei Break-Glass: Statt wenige, klar dokumentierte Notfallkonten auszunehmen, werden produktive Admin-Konten „temporär“ exkludiert und später nicht zurückgenommen.

Legacy-MFA (Per-User MFA) und Security Defaults: widersprüchliche Erwartungen

Conditional Access ist nicht der einzige Mechanismus, der MFA auslösen oder Anmeldungen einschränken kann. Wenn in einem Tenant parallel noch Per-User MFA (klassische Benutzer-MFA) für einzelne Konten aktiv ist, oder wenn Security Defaults aktiv sind, entstehen leicht Fehldeutungen: MFA erscheint „an der falschen Stelle“, oder Administratoren erwarten eine CA-basierte Abfrage, die tatsächlich durch ein anderes System ausgelöst wird.

Umgekehrt kann CA korrekt konfiguriert sein, aber die Wahrnehmung ist „MFA fehlt“, weil der Zugriff über bereits erfüllte Token-/Sitzungszustände (z. B. bestehende MFA-Claims, „remembered“ MFA) oder durch Anmeldekontexte (z. B. Token-Refresh) ohne interaktive Challenge erfolgt. Entscheidend ist, im Sign-In-Log die tatsächlich angewendeten Details unter „Authentication Details“ und die CA-Ergebnisse zu prüfen, statt nur auf das UI-Verhalten zu schauen.

Scope-Probleme: falsche Benutzer-, Rollen- oder Gruppen-Zuordnung

Viele CA-Fehler sind reine Scoping-Fehler: Die Richtlinie ist technisch korrekt, gilt aber nicht für den tatsächlich anmeldenden Principal. Klassiker sind falsch gewählte Zielgruppen (z. B. „All users“ plus Excludes, die mehr entfernen als gedacht), oder Gruppen, deren Mitgliedschaft nicht dem betrieblichen Ziel entspricht. Auch Rollen-Scopes werden häufig missverstanden: Eine Policy, die administrative Rollen absichern soll, muss explizit auf Rollen zielen; eine reine Benutzergruppen-Policy deckt „Privilege“ nicht automatisch ab, wenn privilegierte Benutzer außerhalb dieser Gruppen existieren.

• „Include: ausgewählte Benutzer“ statt vollständiger Abdeckung: Einzelne Service- oder Admin-Konten werden vergessen, weil sie keiner zentralen Gruppe zugeordnet sind.
• Gruppenmitgliedschaft nicht wirksam: Bei dynamischen Gruppen oder Änderungen an Mitgliedschaften kann es Verzögerungen geben; für akute Tests ist ein Sign-In-Log/What-If relevanter als die Erwartung „muss sofort greifen“.
• Workload Identities übersehen: Anmeldungen über Service Principals/Workload Identities folgen anderen CA-Pfaden als Benutzer-Logins; eine User-Policy erklärt keine Token-Probleme bei Automatisierungen.

Standorte (Named locations): falsches Vertrauen durch IP-Design und IPv6

Standortbedingungen wirken nur so gut wie die IP- und Netzwerkrealität. Häufig wird ein „Trusted location“ auf Basis von Office-IP-Ranges definiert, während Benutzer tatsächlich über VPN-Egress, Secure Web Gateway, Proxy oder Cloud-Zugänge mit anderen Quell-IP-Adressen erscheinen. Dann greift eine „MFA nur außerhalb vertrauenswürdiger Standorte“-Logik nicht wie geplant: Entweder wird MFA zu selten abgefragt (weil ein zu großer IP-Range als vertrauenswürdig markiert ist) oder Zugriffe werden blockiert (weil die erwartete Office-IP gar nicht verwendet wird).

Zusätzlich ist IPv6 in der Praxis eine wiederkehrende Fehlerquelle. Wenn Named Locations nur IPv4-Ranges enthalten, die Clients aber IPv6 nutzen oder Gateways IPv6-Adressen anzeigen, wird der Login als „untrusted“ bewertet. Ebenso kritisch: „Countries/Regions“ als Standortlogik ist bei mobilen Nutzern, Roaming und Cloud-Backhauling oft nicht stabil genug für harte Allow/Block-Entscheidungen.

Gerätebedingungen: Join-Status, Compliance und Filterlogik

Unerwartete Blockaden entstehen oft durch Geräteanforderungen wie „Require device to be marked as compliant“ oder „Require Microsoft Entra joined device“. Diese Controls sind präzise, aber unforgiving: Ein Gerät, das „eigentlich verwaltet“ wirkt, kann in Entra als nicht compliant erscheinen (z. B. weil die MDM-Registrierung fehlt, der Compliance-Status nicht reportet, das falsche Gerät verwendet wird oder der Zugriff ohne Device-Claims erfolgt). Dann blockt CA konsequent – unabhängig davon, dass MFA korrekt erfüllt wäre.

Gerätefilter („Filter for devices“) werden ebenfalls häufig falsch interpretiert. Ein Filter kann Anmeldungen unbeabsichtigt aus dem Scope nehmen (MFA bleibt aus) oder zusätzliche Anmeldungen in den Scope ziehen (Blockade/MFA unerwartet). Entscheidend ist, ob der Sign-In überhaupt Geräteinformationen trägt und ob der Filter auf die tatsächlich verwendeten Device-Attribute passt.

• Klassischer Blocker: Policy kombiniert Grant: Require device to be marked as compliant und Benutzer arbeitet auf einem BYOD ohne MDM-Enrollment; Ergebnis ist Block statt „nur MFA“.
• Join-Falle: Require Microsoft Entra joined device sperrt konsequent Geräte, die nicht Entra-joined sind (z. B. viele BYOD-/mobile Szenarien), selbst wenn sie compliant sind.
• Filter zu eng: Device-Filter schließt die eigentlich gemeinte Geräteklasse aus (z. B. wegen falschem deviceOwnership oder Modell/OS-Attributen) und CA wird „not applied“.

App-Zuweisungen und Zielressourcen: falsche Cloud-App, falscher Kontext

Wenn MFA „für App X“ erzwungen werden soll, muss die Zielressource exakt stimmen. Häufig wird die falsche Cloud-App ausgewählt, oder ein Dienst nutzt im Hintergrund eine andere Ressource als erwartet (z. B. Exchange Online vs. Microsoft Graph, oder ein Portal, das Token für eine nachgelagerte API zieht). Dann greift die Policy nicht – oder greift an einer anderen Stelle und wirkt wie „zufällig“.

Auch „User actions“ werden oft missverstanden: Einige sensible Aktionen (z. B. Sicherheitsinformationen registrieren) können über spezifische CA-Zieltypen abgedeckt werden; wer stattdessen nur Cloud-Apps auswählt, erreicht die eigentliche Schutzwirkung nicht. Umgekehrt kann eine zu breit definierte App-Zielgruppe (z. B. All cloud apps) plötzlich produktive Protokolle und Legacy-Zugriffe treffen, die nicht MFA-fähig sind, und damit echte Ausfälle verursachen.

Systematische Fehlersuche in der Praxis: What-If, Sign-In-Logs und Auditdaten für eine eindeutige Policy-Zuordnung; Break-Glass und Rollout-Disziplin

Vorgehensmodell: vom beobachteten Symptom zur eindeutigen Ursache

In der Praxis sind zwei Symptome besonders häufig: Entweder bleibt eine erwartete MFA-Abfrage aus, oder ein produktiver Zugriff wird unerwartet blockiert. In beiden Fällen ist das Ziel der Analyse identisch: Für genau diesen einzelnen Anmeldeversuch muss zweifelsfrei nachvollziehbar sein, welche Conditional-Access-Richtlinien ausgewertet wurden, welche davon tatsächlich angewendet wurden und welche Bedingung (oder Kontrolle) den Ausschlag gab.

Eine belastbare Fehlersuche arbeitet deshalb immer „vom Ereignis nach oben“: erst den konkreten Sign-In in den Logs identifizieren, dann die CA-Entscheidung (Applied/Not applied) auswerten, anschließend die Richtliniendetails (Conditions, Exclusions, Grant/Session Controls) gegen die realen Kontextdaten (User, App, Device, Location, Client, Risk) halten. Erst danach lohnt sich das Gegenprüfen mit dem What-If-Tool, um Hypothesen zu testen und geplante Änderungen risikofrei zu validieren.

What-If-Tool: schnelle Policy-Simulation, aber nur mit korrekten Eingaben

Das What-If-Tool in Microsoft Entra ID ist die schnellste Methode, um eine erwartete Policy-Wirkung zu simulieren. Es ersetzt jedoch keine Loganalyse, weil die Simulation nur so gut ist wie die eingegebenen Parameter und nicht automatisch alle Echtzeit-Signale eines konkreten Sign-Ins „errät“ (z. B. tatsächlicher Client-App-Typ, exakte Ressourcen-App-ID, reale IP/Location-Auflösung oder Gerätezustand in diesem Moment).

Für eine valide Simulation sollten die Werte aus einem echten Sign-In übernommen werden. Entscheidend ist dabei, die gleiche Zielanwendung (Ressource), denselben Benutzer, den passenden Geräte- und Clientkontext sowie die verwendete IP-Adresse abzubilden. Anschließend zeigt What-If, welche Policies „apply“ würden und welche Bedingung den Ausschluss oder die Nichtanwendbarkeit verursacht.

• Minimaler Datensatz für reproduzierbare What-If-Ergebnisse: Benutzer, Zielanwendung (Cloud App), Client-App-Typ, Geräteplattform und Gerätestatus (sofern relevant), Standort/IP sowie ggf. Sign-in risk und user risk, wenn risikobasierte Policies im Einsatz sind.
• Typische Eingabefehler: Falsche App gewählt (z. B. „Office 365“ statt der konkreten Ressource), „Browser“ simuliert obwohl der echte Zugriff als „Mobile Apps and desktop clients“ lief, oder eine interne IP genutzt, obwohl der tatsächliche Egress über eine andere öffentliche IP erfolgt.
• Interpretation der Ergebnisse: „Not applied“ ist kein Fehlerzustand, sondern meist ein Scope-/Bedingungsthema (User/Group nicht enthalten, App nicht enthalten, Condition trifft nicht, oder explizit ausgeschlossen). „Applied“ ist erst dann zielführend, wenn die ausgewiesenen Kontrollen exakt den erwarteten Effekt erklären.

Sign-In-Logs: die maßgebliche Quelle für die tatsächliche CA-Entscheidung

Die Sign-In-Logs in Entra ID sind für Conditional Access der primäre Beweis. Für den betroffenen Anmeldeversuch sollten gezielt die Details geöffnet werden, insbesondere der Bereich „Conditional Access“ (Policies evaluated/applied), „Authentication Details“ (MFA-Methode, Schrittfolge, Fehlercodes) sowie die Kontextfelder wie „Client app“, „Resource“, „Device info“ und „Location“.

Wichtig ist die Trennung zwischen „Policy wurde ausgewertet“ und „Policy wurde angewendet“. Eine Policy kann sichtbar sein, aber nicht angewendet werden, weil eine Bedingung nicht zutrifft oder eine Ausnahme greift. Umgekehrt kann eine einzige angewendete Block-Policy den gesamten Sign-In stoppen, selbst wenn andere Policies MFA verlangen würden. Die Logs zeigen zudem, ob ein Token-Refresh oder ein nicht-interaktiver Token-Abruf vorlag; dadurch lassen sich Fälle erklären, in denen Nutzer „keine MFA sehen“, obwohl MFA bei einer früheren Interaktion bereits erfüllt wurde.

• Gezielte Filterung: Nach Benutzer und Zeitraum filtern, anschließend über „Status“ und „Application“ eingrenzen; bei Blockierungen zusätzlich die Felder „Failure reason“ und „Conditional Access“ prüfen.
• Policy-Detailprüfung: Für jede „applied“-Policy prüfen, ob die Entscheidung aus Grant controls (z. B. Require authentication strength, Require device to be marked as compliant, Block access) oder aus Session controls (z. B. Sign-in frequency) resultiert.
• Location-Fallstricke: Im Sign-In die erkannte öffentliche IP und den daraus abgeleiteten Standort prüfen; bei „Named locations“ verifizieren, ob IPv4/IPv6 korrekt gepflegt ist und ob Proxy-/NAT-Szenarien die erwartete Zuordnung aushebeln.
• Client-App-Klassifikation: „Other clients“ ist ein Warnsignal, weil hier häufig nicht intendierte Legacy-Flows oder Sonderfälle (z. B. bestimmte SMTP/IMAP/POP- oder ältere Bibliotheken) landen; CA-Wirkung kann dadurch anders ausfallen als bei Browser/Modern Auth.

Auditdaten: wer hat die Policy oder die Ausnahmen geändert – und wann?

Wenn eine Policy „plötzlich“ nicht mehr greift, ist die technische Ursache oft eine Änderung am Objekt selbst (Policy, Named Location, Gruppe, App-Zuweisung) oder am Scope (User/Group-Mitgliedschaften). Dafür sind die Entra-Auditlogs die richtige Quelle. Sie beantworten nicht, warum ein einzelner Sign-In blockiert wurde, aber sie erklären, warum sich das Verhalten im Zeitverlauf verändert hat.

Für saubere Ursachenanalyse sollten Auditereignisse zeitlich um den ersten Auftretenszeitpunkt korreliert werden: Änderungen an Conditional-Access-Policies (Enable/Disable, Conditions, Exclusions), Änderungen an Named Locations, Anpassungen an Gruppenmitgliedschaften sowie Änderungen an Gerätestatussignalen (z. B. Compliance-Policy-Auswertung in Intune als vorgelagertes Thema) sind dabei typische Kandidaten.

• Audit-Suchstrategie: In Entra-Auditlogs nach Aktivitäten rund um Update conditional access policy, Add named location/Update named location und Gruppenänderungen filtern und mit dem Zeitpunkt der ersten fehlerhaften Sign-Ins abgleichen.
• Scope-Veränderungen nachvollziehen: Bei dynamischen Gruppen Regeln und Auswertung berücksichtigen; ein Nutzer kann „über Nacht“ aus dem Scope fallen, ohne dass eine CA-Policy direkt geändert wurde.
• Change-Qualität prüfen: Auditdaten zeigen den Initiator (Konto/Workload), die geänderten Felder und oft Vorher/Nachher-Werte; damit lassen sich unbeabsichtigte Ausnahmen (z. B. zu breit) nachweisen.

Break-Glass korrekt einsetzen: Absicherung der Administration ohne CA-Blackout

Break-Glass-Konten sind kein Komfortmerkmal, sondern eine Betriebssicherheitsmaßnahme: Wenn Conditional Access oder Identity-Signale fehlerhaft sind, muss ein definierter, kontrollierter Zugriff zur Wiederherstellung möglich bleiben. Gleichzeitig dürfen Break-Glass-Konten nicht als dauerhafte Ausnahme „missbraucht“ werden.

In der Praxis bewährt sich ein sehr kleiner Satz dedizierter Konten, die streng überwacht, mit starken, offline verwahrten Anmeldedaten versehen und nur im Notfall verwendet werden. Conditional Access sollte diese Konten gezielt ausnehmen, aber andere Schutzmaßnahmen (z. B. restriktive Rollenvergabe, getrennte Nutzung, Monitoring und Alarme) bleiben zwingend. Ob und wie MFA für Break-Glass umgesetzt wird, hängt vom eigenen Notfallkonzept ab; entscheidend ist die getestete Wiederherstellbarkeit auch bei Ausfall einzelner Faktoren.

Rollout-Disziplin: Testnutzer, gestaffelte Aktivierung und dokumentierte Policy-Zuordnung

Die häufigste Ursache für „unerwartete“ Blockierungen ist ein Rollout ohne klare Stufen: Eine Policy wird zu früh breit aktiviert, während Randfälle (Legacy-Clients, Dienstkonten, Spezialanwendungen, Standortdefinitionen, Geräteausnahmen) noch nicht abgedeckt sind. Eine belastbare Vorgehensweise kombiniert Pilotgruppen, klare Ownership und eine nachvollziehbare Dokumentation der beabsichtigten Policy-Wirkung pro App und Benutzersegment.

• Testnutzer-Set definieren: Mindestens je ein Nutzer für Standard-Workplace, mobile Nutzung, externe Netzwerke/VPN, privilegierte Rolle sowie ein Konto mit bewusst abweichendem Gerätezustand (compliant/nicht compliant), um Bedingungen reproduzierbar zu testen.
• Änderungen nur mit Beleg: Vor Aktivierung einer CA-Änderung What-If mit realistischen Parametern durchführen; nach Aktivierung den ersten Sign-In im Log als Referenz sichern (Zeitpunkt, App, Device, Applied Policies).
• Dokumentation der Policy-Intention: Pro Policy festhalten, welche Zielanwendungen und welche Benutzersegmente abgedeckt sind, welche Ausnahmen es gibt und welche Logfelder den Erfolg belegen (z. B. „Applied: Policy X“, „Grant: Require authentication strength“).