# Eine Regel einführen, die niemanden unangekündigt sperrt
Typ: Checkliste
Herkunft: microsoft-entra-m365 / conditional-access-architecture / microsoft-entra-ca-rollout-sequence
Version: microsoft-entra-ca-rollout-sequence-2026-09-12
Geprüft: 2026-09-12

ACHTUNG: Dieses Dokument ist ein Lernartefakt aus einer Schulungssequenz. Es ist kein produktives Runbook. Vor jeder Anwendung in einer realen Umgebung müssen die Schritte gegen lokale Dokumentation, Runbooks und Freigabestatus geprüft werden.

## Szenario
Für die Verwaltungsoberflächen soll eine phishing-resistente Anmeldung verlangt werden. Betroffen sind rund 30 Personen. Der erste Entwurf lautet: Regel anlegen, alle Benutzer erfassen, einschalten.

## Schritte
1. Den Umfang auf die Gruppe mit Verwaltungsaufgaben eingrenzen statt alle zu erfassen
2. Die Notfallzugangskonten in die Ausschlussliste aufnehmen
3. Die Regel auf `enabledForReportingButNotEnforced` setzen
4. Die Ergebnisse in den Anmeldeprotokollen nach Blockern und erwartbaren Rückfragen trennen
5. Prüfen, welche weiteren Regeln dieselben Personen erfassen
6. Auf `enabled` setzen und den Token-Effekt bei laufenden Sitzungen einplanen

## Begründung
Warum: Bei einer Maßnahme, die aussperren kann, wird der Rückweg vor der Wirkung gesichert — nicht danach. Deshalb steht der Ausschluss vor dem ersten Einschalten und nicht erst dann, wenn sich zeigt, dass er gebraucht wird.
Folgen: **+** Die Regel lässt sich in jeder Phase zurücknehmen, und die Betroffenen sind bekannt, bevor sie es merken. **−** Der Ablauf dauert Tage, in denen die Regel nichts schützt; wer auf eine akute Bedrohung reagiert, muss abkürzen und trägt das Risiko dann bewusst.

## Quellen
1. https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-report-only
2. https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-policies
3. https://learn.microsoft.com/en-us/entra/identity/users/directory-emergency-access