Am 1. Oktober 2026 schaltet Microsoft die Legacy-Risk-Policies in Entra ID Protection ab. Es gibt keine automatische Migration und keine Schonfrist. Die Richtlinien verschwinden nicht mit einer Fehlermeldung, sie hören auf zu erzwingen. Ein Konto mit geleakten Zugangsdaten, das gestern noch zur sicheren Passwortänderung gezwungen wurde, meldet sich danach an wie jedes andere.
Im Portal steht weiter eine Richtlinie, im Anmeldeprotokoll steht keine Erzwingung mehr. Genau das macht diesen Termin gefährlicher als eine harte Abschaltung: Der Ausfall meldet sich nicht.
Was am 1. Oktober wegfällt
Betroffen sind die beiden eingebauten Richtlinien im ID-Protection Portal: die Benutzerrisiko-Richtlinie und die Anmelderisiko-Richtlinie. Beide bewerten Signale aus Entra ID Protection und erzwingen daraufhin eine Aktion, etwa eine Passwortänderung oder MFA.
Diese Logik wandert vollständig nach Conditional Access. Dort stehen dieselben Signale als Bedingungen zur Verfügung, Benutzerrisiko und Anmelderisiko, kombinierbar mit allem, was Conditional Access sonst kennt.
Microsoft nennt als Gewinn der Umstellung: eine einzige Stelle für alle Zugriffsrichtlinien, den Nur-Bericht-Modus, Steuerung über Graph-APIs, erzwingbare Anmeldehäufigkeit, Kombination von Risiko mit Bedingungen wie Standort, mehrere Risikorichtlinien für verschiedene Benutzergruppen und eine klarere Diagnose im Anmeldeprotokoll.
Eine Bedingung bleibt unverändert: Risikobasierte Zugriffsrichtlinien brauchen Microsoft Entra ID P2. Wer die Legacy-Policies bisher ohne P2 genutzt hat, hatte sie faktisch nie im vollen Funktionsumfang.
1: Prüfen, ob dich das überhaupt betrifft
Zwei Fragen sind zu trennen. Erstens: Erzwingt in diesem Tenant noch eine Legacy-Policy? Zweitens: Existiert schon eine risikobasierte Conditional-Access-Richtlinie?
Die erste Frage beantwortest du im Portal. Unter ID Protection, Dashboard, wählst du die Benutzerrisiko- oder Anmelderisiko-Richtlinie und liest den Schalter "Richtlinie erzwingen". Für die Legacy-Policies gibt es keinen dokumentierten Cmdlet-Weg, du kommst um den Portalgang nicht herum. Wer mehrere Tenants betreut, plant das als Liste ein, nicht als Skript.
Die zweite Frage beantwortet Graph:
Connect-MgGraph -Scopes Policy.Read.All
Get-MgIdentityConditionalAccessPolicy -All |
Where-Object { $_.Conditions.UserRiskLevels -or $_.Conditions.SignInRiskLevels } |
Select-Object DisplayName, State,
@{Name='Benutzerrisiko'; Expression={ $_.Conditions.UserRiskLevels -join ',' }},
@{Name='Anmelderisiko'; Expression={ $_.Conditions.SignInRiskLevels -join ',' }}Bleibt die Ausgabe leer, hängt dein gesamter Risikoschutz an den Legacy-Policies und endet am 1. Oktober. Kommt etwas zurück, prüfst du den Zustand: Eine Richtlinie im Zustand enabledForReportingButNotEnforced erzwingt nichts, sie protokolliert nur.
2: Lizenzstand klären, bevor du baust
Der Lizenzcheck gehört vor den Richtlinienbau, weil eine risikobasierte Richtlinie ohne P2 für die betroffenen Benutzer keine Wirkung entfaltet und du das Ergebnis im Nur-Bericht-Modus falsch interpretierst:
Connect-MgGraph -Scopes Organization.Read.All
$Skus = Invoke-MgGraphRequest -Method GET -Uri 'https://graph.microsoft.com/v1.0/subscribedSkus'
$Skus.value |
Where-Object { $_.servicePlans.servicePlanName -contains 'AAD_PREMIUM_P2' } |
Select-Object skuPartNumber,
@{Name='Zugewiesen'; Expression={ $_.consumedUnits }},
@{Name='Gekauft'; Expression={ $_.prepaidUnits.enabled }}
Fehlt P2 im Tenant, ist die Migration keine Konfigurationsaufgabe mehr, sondern eine Budgetentscheidung. Dann brauchst du entweder P2 für die Benutzergruppen, die geschützt werden sollen, oder du ersetzt den Risikoschutz durch andere Kontrollen und dokumentierst die Lücke. Stillschweigend in den 1. Oktober laufen ist die schlechteste der drei Varianten.
3: Benutzerrisiko-Richtlinie nachbauen
Der Weg führt über Entra ID, Conditional Access, Neue Richtlinie. Unter Benutzer schließt du deine Notfallkonten aus, unter Zielressourcen wählst du alle Ressourcen. Als Bedingung setzt du Benutzerrisiko auf "Hoch", das ist die Microsoft-Empfehlung und hält die Zahl der Unterbrechungen niedrig.
Bei den Zugriffskontrollen wählst du "Risikobehebung erforderlich". Diese Steuerung ist der eigentliche Fortschritt gegenüber der Legacy-Policy, weil sie sich an die Anmeldemethode anpasst:
- Passwortbasierte Konten werden zur sicheren Passwortänderung geführt, danach werden die alten Sitzungen entzogen.
- Passwortlose Konten bekommen keine Passwortänderung, sondern einen Sitzungsentzug mit erneuter Anmeldung.
- Bei einem durch Angreifer hinzugefügten Gerät deaktiviert Entra ID das Geräteobjekt, entzieht die Sitzungen und verlangt eine neue Anmeldung.
Mit der Auswahl setzt Entra ID zwei Kontrollen automatisch: "Authentifizierungsstärke erforderlich" als Gewährungssteuerung und "Anmeldehäufigkeit: jedes Mal" als Sitzungssteuerung. Beides ist Absicht, denn nach einem Sitzungsentzug muss die Neuanmeldung sofort mit der geforderten Stärke erfolgen.
Zwei Einschränkungen musst du einplanen. Erstens gilt die Risikobehebung für Benutzerrisiko, nicht für Anmelderisiko. Zweitens wird sie für externe Benutzer und Gäste nicht unterstützt, weil Entra ID für diese Konten keinen Sitzungsentzug durchführt. Gäste brauchen also eine eigene Behandlung, etwa eine Blockierrichtlinie bei hohem Benutzerrisiko.
Die Richtlinie legst du mit dem Schalter auf "Nur Bericht" an, nicht auf "Ein".
4: Anmelderisiko-Richtlinie getrennt anlegen
Microsoft warnt ausdrücklich davor, Anmelderisiko und Benutzerrisiko in dieselbe Richtlinie zu packen. Der Grund ist die Auswertungslogik: Beide Bedingungen in einer Richtlinie führen zu Ergebnissen, die im Anmeldeprotokoll kaum noch zuzuordnen sind, und die Behebungsflüsse unterscheiden sich.
Die zweite Richtlinie bekommt als Bedingung Anmelderisiko "Mittel" und "Hoch", als Gewährungssteuerung "Authentifizierungsstärke erforderlich" mit der eingebauten Stärke Multifaktor-Authentifizierung und als Sitzungssteuerung die Anmeldehäufigkeit "jedes Mal". Der Grund für die Anmeldehäufigkeit: Eine riskante Anmeldung lässt sich nur durch eine starke Neuanmeldung entschärfen, ein bereits ausgestelltes Token hilft dabei nicht.
Für Benutzergruppen, die schon passwortlos arbeiten, wählst du statt der Standard-MFA-Stärke die Stärke "Passwortlose MFA" oder "Phishing-resistente MFA", je nachdem, welche Methoden diese Benutzer tatsächlich registriert haben.
5: Nur-Bericht auswerten, dann scharf schalten
Der Nur-Bericht-Modus ist kein Formalismus, sondern die einzige Stelle, an der du siehst, wen die Richtlinie treffen würde, bevor sie es tut. Im Anmeldeprotokoll findest du je Anmeldung den Reiter "Nur Bericht" mit dem Ergebnis pro Richtlinie. Für die Auswertung über alle Anmeldungen nutzt du die Arbeitsmappe unter Conditional Access, Erkenntnisse und Berichte.
Worauf du achtest: Dienstkonten, die plötzlich als riskant auftauchen, Gastkonten, Konten ohne registrierte MFA-Methode und Anmeldungen aus Standorten, die du noch nicht als benannten Standort hinterlegt hast. Sieben bis vierzehn Tage Beobachtung reichen in den meisten Umgebungen, um die Ausreißer zu finden.
Erst danach schiebst du den Schalter von "Nur Bericht" auf "Ein".
6: Ausnahmen sauber setzen
Notfallkonten gehören in jede Ausschlussliste, sonst sperrt dich eine fehlerhafte Risikorichtlinie im Ernstfall selbst aus. Zwei dedizierte Cloud-only-Konten mit Global-Administrator-Rolle, dokumentiert, sicher verwahrt und regelmäßig getestet, sind der Mindeststand.
Eine ältere Faustregel lautet, Notfallkonten von allen Kontrollen auszunehmen, auch von MFA. Das trägt heute nicht mehr. Nimm sie von den Risikorichtlinien aus, aber lass eine phishing-resistente Authentifizierung darauf bestehen. Ein Konto mit Global-Administrator-Rolle und reinem Passwortschutz ist kein Notfallplan, sondern ein offenes Ziel.
Dienstkonten und der Entra-Connect-Synchronisierungsaccount kommen ebenfalls in die Ausschlussliste. Für Dienstprinzipale greifen benutzerbezogene Conditional-Access-Richtlinien ohnehin nicht, dafür brauchst du Conditional Access für Workload-Identitäten. Wo Skripte heute mit Dienstkonten laufen, ist der bessere Weg eine verwaltete Identität.
7: Alte Richtlinien abschalten
Die Reihenfolge entscheidet. Erst wenn die neuen Richtlinien im Zustand "Ein" laufen, deaktivierst du die alten unter ID Protection, Dashboard, Benutzerrisiko- beziehungsweise Anmelderisiko-Richtlinie, Schalter "Richtlinie erzwingen" auf "Deaktiviert". Andersherum entsteht ein Fenster ohne Risikoschutz.
Woran die Migration in der Praxis scheitert
Der häufigste Stolperstein sind Benutzer ohne registrierte MFA-Methode. Wer keine Methode registriert hat, kann sein Risiko nicht selbst beheben und wird blockiert, bis ein Administrator eingreift. Vor dem Scharfschalten gehört deshalb ein Blick auf den Registrierungsstand.
Für hybride Benutzer aus der lokalen AD muss Password Writeback aktiv sein, sonst schlägt die sichere Passwortänderung fehl. Eine Passwortänderung außerhalb des Behebungsflusses zählt übrigens nicht als sichere Passwortänderung, der Benutzer bleibt riskant.
Bei überlappenden Richtlinien gilt eine feste Rangfolge: "Risikobehebung erforderlich" schlägt "Passwortänderung erforderlich", "Zugriff blockieren" schlägt beides. Weise einem Benutzer immer nur eine dieser Richtlinien zu, sonst debuggst du später Ergebnisse, die niemand erwartet hat.
Und wenn dir im Anmeldeprotokoll eine unbekannte Anwendungs-ID auffällt: Für den Behebungsfluss nutzt Entra ID im öffentlichen Cloud-Umfeld die AppId 93625bc8-bfe2-437a-97e0-3d0060024faa gegen die Ressource 00000003-0000-0000-c000-000000000000. Dieser Fluss läuft absichtlich an anderen Conditional-Access-Richtlinien vorbei, damit die Behebung nicht von der Richtlinie blockiert wird, die sie auslösen soll.
Zeitplan bis zum 1. Oktober
Drei Wochen reichen, wenn du jetzt anfängst. Diese Woche: Bestand prüfen, Lizenzlage klären, Ausschlussgruppen für Notfall- und Dienstkonten anlegen. Nächste Woche: beide Richtlinien im Nur-Bericht-Modus anlegen und laufen lassen. Danach: Auswertung, Scharfschalten, alte Richtlinien deaktivieren.
Wer den Termin verpasst, merkt es nicht am Ticketaufkommen. Er merkt es beim nächsten Vorfall, wenn im Anmeldeprotokoll ein hohes Benutzerrisiko steht und daneben kein einziger erzwungener Schritt.
weitere Links
| Quelle | Thema | URL |
| Microsoft Learn | Retirement zum 1. Oktober 2026, Nutzen der Umstellung, P2-Pflicht, Risikobehebung | https://learn.microsoft.com/en-us/entra/id-protection/concept-identity-protection-policies |
| Microsoft Learn | Konfigurationsschritte, Ausschlüsse, Migrationsreihenfolge, Nur-Bericht | https://learn.microsoft.com/en-us/entra/id-protection/howto-identity-protection-configure-risk-policies |
| Microsoft Learn | Notfallzugriffskonten in Microsoft Entra ID | https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access |
Sei der Erste und starte die Diskussion mit einem hilfreichen Beitrag.
Kommentar hinterlassen
Dein Beitrag wird vor der Veröffentlichung kurz geprüft — fachlich, respektvoll und auf den Punkt ist hier genau richtig.