Conditional Access: sicher planen, testen und einschalten
Eine neue Anmelderichtlinie kontrolliert ausrollen.
Der Prüfauftrag
Für Administratoren eines Entra-Tenants mit den erforderlichen Berechtigungen und Lizenzen. Jede Änderung benötigt ein klares Schutzziel, definierte Testkonten und einen Wiederherstellungsweg. Quellenstand: 09.11.2026.
Am Ende hast du:Eine dokumentierte Erstprüfung mit nachvollziehbaren Nachweisen und einer Liste offener Maßnahmen.
Beweisen statt vermuten.
Vor Erzwingung den dokumentierten Notfallweg testen und erlaubte sowie zu blockierende Anmeldungen mit repräsentativen Testkonten nachstellen.
Status, Prüfbereich und Notizen bleiben in diesem Browser. Keine Übertragung an MauriSec. Ohne Speicherung geht der Stand beim Verlassen verloren; gespeicherte Daten bleiben bis zu deiner Löschung. Keine Geheimnisse, Zugangsdaten oder fremden personenbezogenen Daten eintragen.
Schutzziel, betroffene Benutzer, Ressourcen, Clienttypen und Gerätebedingungen je Richtlinie schriftlich festlegen.
So belegst du es: Richtliniensteckbrief mit Eigentümer, Freigabe und gewünschter Zugriffsentscheidung.
Nachweis und nächsten Schritt notieren
Bestehende Richtlinien und Abhängigkeiten erfassen; alle auf eine Anmeldung zutreffenden Richtlinien gemeinsam berücksichtigen.
So belegst du es: Konfigurationsexport und Testmatrix mit überlappenden Richtlinien.
Nachweis und nächsten Schritt notieren
Notfallzugriff testen und notwendige Ausnahmen eng, begründet und überprüfbar halten.
So belegst du es: Notfall-Testprotokoll und Ausnahmeliste mit Zuständigkeit und Prüftermin.
Nachweis und nächsten Schritt notieren
Benutzeranmeldungen und Workload-Identitäten getrennt planen; Benutzer-Richtlinien nicht als Schutz aller Dienstprinzipale ansehen.
So belegst du es: Getrennte Bestandsliste und dokumentierte Abdeckung je Identitätstyp.
Nachweis und nächsten Schritt notieren
Die Richtlinie zunächst für einen passenden Pilot und, soweit unterstützt, in Report-only prüfen.
So belegst du es: Richtlinienzustand und protokollierte Report-only-Ergebnisse der vorgesehenen Anmeldungen.
Nachweis und nächsten Schritt notieren
Erlaubte und verbotene Szenarien mit What If vorprüfen und anschließend mit realen Testanmeldungen validieren.
So belegst du es: Simulationsbericht plus korrespondierende Anmeldeereignisse mit Korrelations-ID.
Nachweis und nächsten Schritt notieren
Auswirkungen auf Geräteaufnahme, Administrationszugang und wichtige Ressourcen gezielt testen.
So belegst du es: Erfolgreiche Aufnahme und Administration sowie erwartete Ablehnungen im Pilot.
Nachweis und nächsten Schritt notieren
Erst nach dokumentierter Auswertung auf On wechseln; Support, Rücknahme und Nachkontrolle bereitstellen.
So belegst du es: Freigabe, Änderungsticket, Rücknahmeweg und überprüfte Anmeldeergebnisse nach Aktivierung.
Nachweis und nächsten Schritt notieren
Deine nächste Arbeit.
Beginne mit den vorrangigen Punkten. Markierte Lücken erscheinen hier mit deinen nächsten Schritten.
Grenzen und Primärquellen
Report-only erzwingt die Richtlinie nicht und unterstützt nicht jeden User-Action-Fall. Geräte-Compliance-Prüfungen können dort trotzdem Zertifikatsdialoge auf macOS, iOS und Android auslösen. What If ist eine Simulation und ersetzt keinen echten Anmeldungstest. Pauschales Blockieren aller Benutzer und Ressourcen oder voreilig erzwungene Geräte-Compliance kann Administration und Geräteaufnahme aussperren.
Microsoft Learn: Plan a Conditional Access deployment ↗Microsoft Learn: Analyze impact with report-only ↗Microsoft Learn: Troubleshoot Conditional Access ↗Microsoft Learn: Conditional Access What If ↗Prüfbericht / Selbsteinschätzung
Conditional Access: sicher planen, testen und einschalten · v2026.11 · 10.11.2026 ·
0/8 bearbeitet · 0 Lücken. Keine unabhängige Prüfung oder Zertifizierung.
1. Schutzziel, betroffene Benutzer, Ressourcen, Clienttypen und Gerätebedingungen je Richtlinie schriftlich festlegen.
Status: Offen
Erwarteter Nachweis: Richtliniensteckbrief mit Eigentümer, Freigabe und gewünschter Zugriffsentscheidung.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
2. Bestehende Richtlinien und Abhängigkeiten erfassen; alle auf eine Anmeldung zutreffenden Richtlinien gemeinsam berücksichtigen.
Status: Offen
Erwarteter Nachweis: Konfigurationsexport und Testmatrix mit überlappenden Richtlinien.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
3. Notfallzugriff testen und notwendige Ausnahmen eng, begründet und überprüfbar halten.
Status: Offen
Erwarteter Nachweis: Notfall-Testprotokoll und Ausnahmeliste mit Zuständigkeit und Prüftermin.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
4. Benutzeranmeldungen und Workload-Identitäten getrennt planen; Benutzer-Richtlinien nicht als Schutz aller Dienstprinzipale ansehen.
Status: Offen
Erwarteter Nachweis: Getrennte Bestandsliste und dokumentierte Abdeckung je Identitätstyp.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
5. Die Richtlinie zunächst für einen passenden Pilot und, soweit unterstützt, in Report-only prüfen.
Status: Offen
Erwarteter Nachweis: Richtlinienzustand und protokollierte Report-only-Ergebnisse der vorgesehenen Anmeldungen.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
6. Erlaubte und verbotene Szenarien mit What If vorprüfen und anschließend mit realen Testanmeldungen validieren.
Status: Offen
Erwarteter Nachweis: Simulationsbericht plus korrespondierende Anmeldeereignisse mit Korrelations-ID.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
7. Auswirkungen auf Geräteaufnahme, Administrationszugang und wichtige Ressourcen gezielt testen.
Status: Offen
Erwarteter Nachweis: Erfolgreiche Aufnahme und Administration sowie erwartete Ablehnungen im Pilot.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
8. Erst nach dokumentierter Auswertung auf On wechseln; Support, Rücknahme und Nachkontrolle bereitstellen.
Status: Offen
Erwarteter Nachweis: Freigabe, Änderungsticket, Rücknahmeweg und überprüfte Anmeldeergebnisse nach Aktivierung.
Eigene Referenz: Nicht hinterlegt
Nächster Schritt: Nicht hinterlegt
Report-only erzwingt die Richtlinie nicht und unterstützt nicht jeden User-Action-Fall. Geräte-Compliance-Prüfungen können dort trotzdem Zertifikatsdialoge auf macOS, iOS und Android auslösen. What If ist eine Simulation und ersetzt keinen echten Anmeldungstest. Pauschales Blockieren aller Benutzer und Ressourcen oder voreilig erzwungene Geräte-Compliance kann Administration und Geräteaufnahme aussperren.