Politiques de risque Entra ID retirées : que faire ?

Depuis le 1er octobre 2026, les anciennes politiques de risque utilisateur et de risque de connexion de Microsoft Entra ID Protection ne sont plus gérables depuis leur interface d'origine. Microsoft demande de les migrer vers l'accès conditionnel. Si personne ne l'a fait, aucune alerte ne vous le dira : la protection peut avoir disparu sans bruit.

Cet article détaille ce qui a changé, la licence requise, la configuration recommandée par Microsoft et les pièges qui bloquent les utilisateurs.

Ce qui a changé le 1er octobre 2026

Microsoft a retiré l'interface des anciennes politiques de risque d'ID Protection (risque utilisateur et risque de connexion) au plus tard le 1er octobre 2026. La documentation Microsoft Learn demande de les recréer sous forme de politiques d'accès conditionnel. Le mouvement a été annoncé en octobre 2023, puis déployé en deux temps.

Une nuance importante. On entend souvent que les anciennes politiques sont « probablement toujours là » et continuent de s'appliquer. La documentation ne le confirme pas : elle parle de retrait de l'interface et de fin de support, pas de maintien de l'application. Vérifiez l'état réel dans chaque tenant plutôt que de le supposer.

Pourquoi l'absence de protection passe inaperçue

La détection de risque continue de noter les connexions : lieu inhabituel, réseau inconnu, identifiants divulgués. Sans politique d'accès conditionnel qui lit ce niveau de risque, rien ne réagit à ce score. L'alerte est enregistrée, mais aucune action n'est déclenchée.

C'est une alarme qui repère le cambrioleur mais dont la sirène reste muette. Aucune erreur n'apparaît. Aucun utilisateur n'ouvre de ticket pour se plaindre qu'on ne lui a pas demandé de prouver son identité.

Quelle licence pour les politiques basées sur le risque ?

Les politiques d'accès conditionnel basées sur le risque exigent Microsoft Entra ID P2 ou Microsoft Entra Suite. L'accès conditionnel seul demande Microsoft Entra ID P1, inclus par exemple dans Microsoft 365 Business Premium. La documentation Microsoft Learn précise que les conditions de risque de connexion et de risque utilisateur ne sont pas disponibles avec P1.

Un tenant en P1 ne peut donc pas reconstruire ces politiques. Il doit traiter les utilisateurs à risque lui-même. La page Microsoft Learn sur la remédiation et le déblocage des utilisateurs décrit les voies manuelles.

Deux politiques, deux conditions : la configuration recommandée

Microsoft recommande deux politiques distinctes. Ne combinez jamais risque utilisateur et risque de connexion dans la même politique.

Avec « Exiger la remédiation des risques », la force d'authentification et la fréquence « À chaque fois » sont imposées automatiquement et sont obligatoires. Pour un utilisateur par mot de passe, cela force un changement de mot de passe sécurisé après le MFA. Pour un utilisateur sans mot de passe, les sessions sont révoquées et il doit se reconnecter.

Créer la politique de risque de connexion

Créer la politique de risque utilisateur

Les bases sont identiques : tous les utilisateurs, exclusion du groupe d'accès d'urgence, toutes les ressources. Choisissez la condition de risque utilisateur avec le niveau élevé. Accordez l'accès avec Exiger la remédiation des risques. Démarrez là aussi en mode rapport seul.

Prérequis et pièges qui bloquent les utilisateurs

Le piège le plus fréquent est l'enregistrement MFA. Les utilisateurs doivent avoir enregistré leurs méthodes MFA avant d'être confrontés à une remédiation. Sinon ils sont bloqués et un administrateur doit intervenir.

Plusieurs limites sont documentées par Microsoft Learn :

• Le contrôle de remédiation ne traite que le risque utilisateur, pas le risque de connexion.
• Il n'est pas pris en charge pour les invités et les utilisateurs externes.
• Le changement de mot de passe sécurisé ne passe pas par la réinitialisation en libre-service (SSPR).
• En cas de politiques multiples, la remédiation l'emporte sur le changement de mot de passe, et le blocage l'emporte sur tout.

Mesurer l'impact avant d'activer

Le mode rapport seul montre ce que la politique aurait fait, sans rien appliquer. Microsoft propose en complément le classeur « Impact analysis of risk-based access policies ». Il fonctionne sans aucune politique en mode rapport seul et prend aussi en compte les politiques héritées restantes, ce qui aide à repérer ce qui subsiste.

Une entreprise de quelques centaines de postes pourrait ainsi créer ses deux politiques en mode rapport seul un jour, analyser les utilisateurs touchés, corriger les enregistrements MFA manquants, puis activer. Cette séquence est une illustration, pas une durée imposée.

En cas de difficulté de migration, un support « Migrate legacy ID Protection policy » peut être ouvert depuis le centre d'administration Microsoft Entra. Pour le reste de votre socle, consultez aussi notre guide sur l'imposition du MFA par l'accès conditionnel et notre framework de test des politiques d'accès conditionnel.

Questions fréquentes

Mes anciennes politiques de risque protègent-elles encore mon tenant ?

Impossible de l'affirmer. La documentation Microsoft parle de retrait de l'interface et de fin de support, sans indiquer que les politiques continuent de s'appliquer. Vérifiez l'état réel de chaque tenant et recréez les politiques dans l'accès conditionnel.

Business Premium suffit-il pour les politiques de risque ?

Non. Business Premium inclut Microsoft Entra ID P1, qui donne l'accès conditionnel mais pas les conditions de risque utilisateur et de risque de connexion. Il faut Microsoft Entra ID P2 ou Microsoft Entra Suite.

Puis-je mettre les deux conditions de risque dans une seule politique ?

Non, Microsoft recommande une politique pour le risque utilisateur élevé et une autre pour le risque de connexion moyen ou élevé. Évitez aussi d'affecter un même utilisateur à plusieurs de ces politiques.

Que se passe-t-il pour les invités et les utilisateurs B2B ?

Le contrôle « Exiger la remédiation des risques » ne les prend pas en charge. La FAQ Microsoft recommande de les exclure via un groupe d'invités.

Par où commencer

Commencez par un inventaire, pas par une création de politique. Vérifiez ce qui existe, puis reconstruisez en mode rapport seul.

Si votre tenant est en P1, alors prévoyez une remédiation manuelle ou par script des utilisateurs à risque, et étudiez le passage à P2. Si votre organisation redoute la fatigue MFA, alors évaluez le blocage du risque élevé plutôt que la demande répétée. Pour aller plus loin sur la base de référence, notre article sur les scopes Baseline et l'accès conditionnel complète ces deux politiques.

Pour aller plus loin

• Configurer et activer les politiques de risque (Microsoft Learn) : la procédure officielle de migration, avec réglages recommandés et demande de support.
• Politiques d'accès basées sur le risque d'ID Protection : remédiation adaptative, priorité entre contrôles et limites.
• Classeur d'analyse d'impact des politiques basées sur le risque : simulez l'effet des politiques et repérez les politiques héritées.
• FAQ Microsoft Entra ID Protection : cas hybrides, fédérés, B2B et fatigue MFA.
• Remédier aux risques et débloquer les utilisateurs : remédiation manuelle et automatique, utile sans P2.