In vielen Tenants, die ich betreue, laufen die klassischen Risikorichtlinien aus Microsoft Entra ID Protection noch in der Standardkonfiguration. Irgendwann hat sie jemand aktiviert, seitdem arbeiten sie im Hintergrund, und ehrlich gesagt stellt sie kaum noch jemand infrage. Seit einiger Zeit empfiehlt Microsoft allerdings eindeutig, die Richtlinien für Benutzer- und Anmelderisiko als Conditional-Access-Richtlinien neu aufzusetzen. Für viele Organisationen ist das mehr als eine Formalität. Mit Conditional Access werden Risikorichtlinien endlich flexibel, sie lassen sich sauber mit anderen Bedingungen kombinieren und im Report-only-Modus gefahrlos testen.

Conditional Access macht Risikorichtlinien deutlich flexibler

Die alten ID-Protection-Richtlinien waren ein wichtiger Schritt, im Alltag stoßen sie aber schnell an ihre Grenzen. Kombinieren lässt sich kaum etwas, Ausnahmen gibt es keine, und wie sich eine Änderung tatsächlich auswirkt, bleibt weitgehend im Dunkeln. An genau diesen Stellen hat Conditional Access klare Vorteile:

  • Mehr Bedingungen: Neben dem Risiko dienen auch Geräteplattform, Standort, Benutzergruppen und Apps als Kriterien.
  • Ausschlüsse und gezielte Ausnahmen: Kritische Konten oder Dienstkonten lassen sich besser absichern oder bewusst ausnehmen.
  • Report-only-Modus: Richtlinien kann man ohne Risiko testen, bevor man sie scharf schaltet.
  • Kombinierbarkeit mit modernen Controls: Authentifizierungsstärken oder Sign-in Frequency lassen sich direkt einbinden.
  • Sinnvolle Templates: Für typische Szenarien stehen inzwischen Vorlagen für risikobasierte Richtlinien bereit.

Ich sehe in der Praxis oft, dass Organisationen den Umstieg nutzen, um auch ihre übrigen Conditional-Access-Regeln neu zu ordnen und dabei längst fällige Altlasten loszuwerden. Die Migration ist damit immer auch eine gute Gelegenheit zum Aufräumen.

Die Migration beginnt mit den Vorlagen im Entra Admin Center

Der Wechsel startet im Microsoft Entra Admin Center unter Conditional Access. Dort gibt es seit einiger Zeit eigene Vorlagen für risikobasierte Richtlinien, etwa „MFA bei Anmelderisiko“ oder „Kennwortänderung bei Benutzerrisiko“. Sie orientieren sich an Best Practices, lassen sich direkt übernehmen und bei Bedarf frei anpassen. Auch die Risikobedingungen sind schnell eingerichtet. Statt der alten ID-Protection-Richtlinien legt man in der Conditional-Access-Richtlinie beim Zuweisen der Benutzer oder Gruppen die Bedingung „Benutzerrisiko erkannt“ oder „Anmelderisiko erkannt“ fest.

Wer tiefer einsteigen will, findet Hintergründe und Details in der offiziellen Dokumentation von Microsoft (Konzept der Identity-Protection-Richtlinien, Risikorichtlinien konfigurieren, Risikobasierte Conditional-Access-Richtlinien).

Damit der Ablauf beim Wechsel auf CA-Risikorichtlinien greifbarer wird, habe ich das folgende Diagramm erstellt. Es stellt den klassischen Weg und den über Conditional Access nebeneinander:

graph TD
    LegacyPolicy["Alte ID Protection Richtlinie"]
    CA["Conditional Access Policy"]
    RiskDetection["Risko wird erkannt"]
    LegacyEnforcement["Zwangsmaßnahme (z.B. MFA, Passwortänderung)"]
    CAConditions["Weitere Bedingungen und Ausnahmen"]
    CAEnforcement["Flexible Controls (MFA, Passwortrücksetzung, etc.)"]

    RiskDetection --> LegacyPolicy --> LegacyEnforcement
    RiskDetection --> CA --> CAConditions --> CAEnforcement

Abbildung: So unterscheidet sich der Ablauf bei der klassischen Risikorichtlinie und bei Conditional Access.

Die Reaktion auf ein erkanntes Risiko entscheidet über den Nutzen

Ihre eigentliche Stärke zeigen die Conditional-Access-Risikorichtlinien bei der Reaktion auf ein Risiko. Beim Anmelderisiko verlangen die meisten Organisationen MFA oder blockieren den Zugriff. Beim Benutzerrisiko ist „Kennwortänderung erzwingen“ der Klassiker. Hybride Benutzer brauchen dafür allerdings Entra ID Password Writeback, denn ohne dieses Feature bleibt der Passwort-Reset für lokale Konten wirkungslos.

Wo es irgend geht, rate ich dazu, stattdessen gleich auf passwortlose Methoden umzusteigen. In Conditional Access klappt das sehr gut. Über Authentifizierungsstärken wie „Passwortlos erforderlich“ zwingt man kompromittierte Benutzer, sich mit sicheren Methoden anzumelden, etwa mit dem Microsoft Authenticator oder einem FIDO2-Key. Das erhöht die Sicherheit und erspart allen Beteiligten zugleich viel Ärger mit gesperrten Accounts.

Mein Praxistipp: Schaltet eine neue Risikorichtlinie nie scharf, ohne sie vorher im Report-only-Modus laufen zu lassen. Das gilt besonders für Richtlinien mit „Kennwortänderung“ oder „Zugriff blockieren“. So seht ihr, wen es treffen würde, und könnt Ausnahmen rechtzeitig einplanen.

Risky Users und Risky Sign-ins lassen sich weiterhin in Identity Protection untersuchen

Für das Monitoring bleibt der Bereich Schutz → Identity Protection im Microsoft Entra Admin Center unverzichtbar. Dort sieht man auf einen Blick, welche Benutzer und Anmeldungen derzeit als riskant gelten. Risky Users lassen sich gezielt untersuchen, zum Beispiel daraufhin, ob die Remediation eines kompromittierten Kontos geklappt hat oder ob weitere Schritte nötig sind. Die Details zu einzelnen Risk Events helfen außerdem, typische Angriffswege zu erkennen und Conditional Access weiter zu verfeinern.

Wer mehr will, kann Benutzer- und Anmelderisiken auch automatisiert auswerten, etwa per KQL im Defender- oder Sentinel-Portal, sofern die passenden Signale dort eingespeist werden. Den meisten Admins genügt allerdings das Identity-Protection-Dashboard völlig.

Ohne saubere P2-Lizenzierung entstehen schnell Stolperfallen

Alle Conditional-Access-Risikorichtlinien setzen den Plan Microsoft Entra ID P2 voraus, und zwar für Benutzer- wie für Anmelderisiko. Immer wieder erlebe ich, dass Unternehmen zwar P2-Lizenzen besitzen, diese aber nicht sauber zugewiesen haben. In anderen Fällen gelten die Richtlinien versehentlich auch für Konten ohne P2. Das führt zu Inkonsistenzen und im Zweifel sogar zu Lizenzverstößen.

Ein weiterer Punkt aus der Praxis betrifft den Umstieg selbst. Alte Richtlinien zu CA zu migrieren heißt nicht, einfach einen Schalter umzulegen. Sobald die Conditional-Access-Variante eingeführt ist, sollte man die alten Richtlinien ausdrücklich deaktivieren. Andernfalls drohen unerwartete Doppelungen und entsprechender Ärger im Support.

Der Wechsel zu Conditional Access ist in den meisten Tenants überfällig

Für mich ist die Migration von klassischen Risikorichtlinien zu Conditional Access keine lästige Pflicht, weil sie einen echten Mehrwert bringt. Die Richtlinien werden flexibler, und Ausnahmen lassen sich gezielt steuern. Dazu machen moderne Authentifizierungsmethoden die Remediation deutlich sicherer. In fast allen Tenants, die ich derzeit betreue, ist der Wechsel längst überfällig. Nebenbei entsteht dabei eine wesentlich übersichtlichere und besser dokumentierte Richtlinienlandschaft.

Wer noch mit den alten ID-Protection-Richtlinien arbeitet, sollte spätestens jetzt umstellen. Die Vorteile für Administration und Sicherheit sind zu groß, um sie länger liegen zu lassen.