Entra ID Risikorichtlinien-Ablauf Oktober 2026: Conditional-Access-Migration Ohne Automatischen Pfad

Entra ID Risikorichtlinien-Ablauf Oktober 2026 Conditional Access Migration: Was Sich Ändert

Der Entra ID Risikorichtlinien-Ablauf Oktober 2026 Conditional Access Migration ist eine harte Frist für die ursprünglichen Risiko-Reaktionskontrollen in Entra ID Protection. Laut Microsoft Learn werden die veralteten Benutzerrisiko- und Anmelderisiko-Richtlinien — jene, die direkt im Dashboard von Identity Protection konfiguriert werden, nicht über Conditional Access — „am 1. Oktober 2026 eingestellt". Der admindroid Microsoft-365-Deprecation-Tracker nennt dasselbe Datum und dieselbe Einordnung: Die Benutzerrisiko- bzw. Anmelderisiko-Richtlinien-Oberfläche in Entra ID Protection (früher Identity Protection) werde am 1. Oktober 2026 eingestellt.

Keine der beiden Quellen beschreibt eine automatische Umwandlung. Microsofts eigene Migrationsanleitung ist komplett manuell: Administratoren müssen gleichwertige risikobasierte Richtlinien selbst in Conditional Access aufbauen, validieren, aktivieren — und erst danach die alten deaktivieren. Nichts in der Dokumentation überträgt die bestehende Risikorichtlinien-Konfiguration eines Tenants von selbst in Conditional Access.

Warum „Keine Automatische Migration" Der Entscheidende Haken Ist

Die risikobasierte Reaktion ist eine der wenigen Kontrollen in Entra ID Protection, die auf Signale kompromittierter Identitäten reagiert, ohne dass ein Mensch eingreifen muss — sie macht aus einer Erkennung „riskanter Benutzer" oder „riskante Anmeldung" eine tatsächliche Multi-Faktor-Herausforderung, einen erzwungenen Passwortwechsel oder eine Blockierung. Ein Tenant, der noch auf der veralteten Richtlinien-Oberfläche basiert und vor dem Ablauf nichts unternimmt, wird nicht automatisch migriert: Er verliert diese automatisierte Reaktion in dem Moment, in dem die veraltete Richtlinie ihre Funktion einstellt — es sei denn, ein gleichwertiges Conditional-Access-Pendant läuft bereits.

Das ist ein enger gefasstes, härteres Problem als „Risikoerkennungen existieren, aber niemand reagiert darauf" (die allgemeinere Identity-Protection-Lücke, die EtcSec bereits separat behandelt hat). Hier kann ein Tenant heute eine funktionierende, durchgesetzte Risikorichtlinie haben und trotzdem am 2. Oktober 2026 bei null risikobasierter Durchsetzung landen — nicht weil jemand etwas geändert hat, sondern weil niemand etwas geändert hat.

Erkennung: Basieren Sie Noch Auf Dem Veralteten Richtlinienpfad?

Zwei Dinge müssen geprüft werden, und Microsoft Learns eigene Migrationsanleitung zeigt genau, wo:

1. Veraltete Risikorichtlinien. Öffnen Sie im Microsoft Entra Admin Center ID Protection → Dashboard und dort die Kacheln der Richtlinien Benutzerrisiko und Anmelderisiko. Zeigt eine der beiden Richtlinie erzwingen: Ein, hängt dieser Tenant noch vom auslaufenden Richtlinientyp ab.
2. Risikobasierte Abdeckung in Conditional Access. Prüfen Sie unter Entra ID → Conditional Access → Richtlinien, ob irgendeine Richtlinie Bedingungen → Benutzerrisiko oder Bedingungen → Anmelderisiko verwendet. Existiert keine — oder liegen die einzigen vorhandenen noch im Report-Only-Modus — gibt es noch keinen funktionierenden Ersatz, unabhängig davon, was das alte Dashboard anzeigt.

Ein Tenant kann bei jedem der beiden Punkte unabhängig durchfallen: Manche haben bereits Conditional-Access-Risikorichtlinien aufgebaut und einfach vergessen, die alten zu deaktivieren (redundant, nicht dringend); andere haben keines von beidem — genau die Kombination, die am Ablaufdatum auf null risikobasierte Durchsetzung fällt.

Behebung: Migration Vor Dem 1. Oktober 2026

Microsoft Learn dokumentiert einen konkreten, dreistufigen Migrationspfad:

1. Bauen Sie zuerst die Conditional-Access-Äquivalente im Report-Only-Modus auf. Erstellen Sie in Conditional Access eine benutzerrisikobasierte und eine anmelderisikobasierte Richtlinie (manuell oder aus einer Conditional-Access-Vorlage), die auf Alle Benutzer zielt, mit ausgeschlossenen Notfallzugriffs-/Break-Glass-Konten. Starten Sie von einer Vorlage, fügen Sie diesen Ausschluss selbst hinzu, sobald die Richtlinie existiert: Microsofts Vorlagen schließen nur das Konto aus, das die Richtlinie erstellt hat, nicht die Break-Glass-Konten des Tenants. Belassen Sie Richtlinie aktivieren zunächst auf Report-Only.
2. Validieren, dann die Richtlinien aktivieren. Nutzen Sie die Report-Only-Einblicke von Conditional Access, um zu bestätigen, dass die neuen Richtlinien so auslösen wie die alten, bevor Sie Richtlinie aktivieren von Report-Only auf Ein umstellen.
3. Die veralteten Richtlinien deaktivieren. Öffnen Sie zurück in ID Protection → Dashboard jede veraltete Benutzerrisiko- und Anmelderisiko-Richtlinie und setzen Sie Richtlinie erzwingen auf Deaktiviert — Microsofts Anleitung geht nicht so weit, sie zu löschen, nur zu deaktivieren.

Für Tenants, die direkte Hilfe brauchen, dokumentiert Microsoft Learn einen konkreten Support-Anfrageweg: eine neue Supportanfrage stellen, das Problem als „Migrate legacy ID Protection policy" beschreiben und Microsoft Entra Sign-in and Multifactor Authentication → Configuring new or existing policy settings auswählen.

Zwei verwandte Themen lohnen sich, parallel zu dieser Migration zu prüfen: Risikorichtlinien — Anmelde- und Benutzerrisiko, ob aus ID Protection oder aus Conditional Access gesteuert — werden von Microsoft als Entra-ID-P2- oder Microsoft-Entra-Suite-Funktion geführt und sind in Free oder P1 nicht verfügbar, und jede neue Richtlinie sollte dieselbe Report-Only-Validierungsdisziplin durchlaufen, die für jeden anderen Conditional-Access-Rollout gilt — eine Richtlinie, die dauerhaft im Report-Only-Modus verbleibt, liefert dieselbe Nulldurchsetzung wie gar keine Richtlinie. Es lohnt sich auch, währenddessen die allgemeine Conditional-Access-Baseline-Abdeckung zu prüfen, da ein Tenant, der Risikorichtlinien migriert, ohnehin gerade seine Conditional-Access-Haltung auditiert.

Diese Abschaltung reiht sich in eine Serie datierter Entra-Fristen 2026 ein — SSPRs Durchsetzung nur registrierter Methoden im November ist eine weitere mit hartem Stichtag und ohne stillen Fallback — und die betriebliche Lehre ist jedes Mal dieselbe: Ein „wird eingestellt"-Hinweis von Microsoft ist eine Aufgabe, keine automatische Hintergrundmigration.

Wie EtcSec Dies Erkennt

EtcSecs Azure-Audit misst genau das, was nach der Abschaltung noch übrig bleibt: ob eine aktivierte Conditional-Access-Richtlinie tatsächlich eine Risikobedingung trägt. CA_NO_RISK_BASED_USER und RISK_NO_USER_RISK_POLICY schlagen beide an, wenn keine aktivierte Conditional-Access-Richtlinie Benutzerrisiko-Stufen setzt; CA_NO_RISK_BASED_SIGNIN und RISK_NO_SIGNIN_RISK_POLICY schlagen beide an, wenn keine Anmelderisiko-Stufen setzt. Alle vier lesen den Conditional-Access-Richtliniensatz des Tenants — keine liest die veraltete ID-Protection-Richtlinienoberfläche.

Zwei Konsequenzen sind es wert, präzise benannt zu werden. Erstens: Ein Tenant, dessen Risikoreaktion ausschließlich in der veralteten ID-Protection-Oberfläche liegt, fällt bei diesen Prüfungen bereits heute durch, nicht erst am 2. Oktober 2026 — der Befund steht schon jetzt im Audit, und genau das ist die Migrationsaufgabe, die diese Frist erzeugt. Zweitens: Die Prüfungen zählen eine Richtlinie nur im Zustand enabled — eine risikobasierte Conditional-Access-Richtlinie, die noch im Report-Only-Modus geparkt ist, erfüllt sie nicht, was derselben Durchsetzungsrealität entspricht, die oben beschrieben wurde.