Retrait Politiques de Risque Entra ID Octobre 2026

Retrait Politiques de Risque Entra ID Octobre 2026 Migration Accès Conditionnel : Pas de Chemin Automatique

Le Retrait Politiques de Risque Entra ID Octobre 2026 Migration Accès Conditionnel est une coupure nette pour les contrôles de réponse au risque d'origine dans Entra ID Protection. Selon Microsoft Learn, les anciennes politiques de risque utilisateur et de risque de connexion — celles configurées directement dans le tableau de bord d'Identity Protection, et non via l'Accès conditionnel — « seront retirées le 1er octobre 2026 ». Le suivi des dépréciations Microsoft 365 d'admindroid indique la même date avec la même formulation : « L'interface de politique de risque utilisateur ou de politique de risque de connexion dans Entra ID Protection (anciennement Identity Protection) sera retirée le 1er octobre 2026 ».

Aucune des deux sources ne décrit de conversion automatique. Les directives de migration de Microsoft sont entièrement manuelles : les administrateurs doivent construire eux-mêmes des politiques équivalentes basées sur le risque dans l'Accès conditionnel, les valider, les activer, et seulement ensuite revenir désactiver les anciennes. Rien dans la documentation ne fait passer automatiquement la configuration existante des politiques de risque d'un tenant vers l'Accès conditionnel.

Pourquoi l'absence de migration automatique est le vrai problème

La réponse basée sur le risque est l'un des rares contrôles d'Entra ID Protection qui agit sur les signaux de compromission d'identité sans intervention humaine — c'est ce qui transforme la détection d'un « utilisateur à risque » ou d'une « connexion à risque » en un véritable défi multifacteur, un changement de mot de passe forcé, ou un blocage. Un tenant qui dépend encore de l'ancienne interface de politique et ne fait rien avant le retrait n'est pas migré gratuitement : il perd cette réponse automatisée dès que l'ancienne politique cesse de fonctionner, à moins qu'un équivalent en Accès conditionnel ne soit déjà actif.

C'est un problème plus étroit et plus tranchant que « les détections de risque existent mais personne n'agit dessus » (la lacune plus générale d'Identity Protection qu'EtcSec a déjà couverte séparément). Ici, un tenant peut avoir aujourd'hui une politique de risque fonctionnelle et appliquée, et se retrouver malgré tout avec zéro application basée sur le risque le 2 octobre 2026 — non pas parce que quelqu'un a changé quelque chose, mais parce que personne ne l'a fait.

Détection : dépendez-vous encore de l'ancienne politique ?

Deux éléments sont à vérifier, et le propre guide de migration de Microsoft Learn indique exactement où regarder :

Anciennes politiques de risque. Dans le centre d'administration Microsoft Entra, allez dans ID Protection → Tableau de bord, et ouvrez les tuiles de politique Risque utilisateur et Risque de connexion. Si l'une des deux affiche Appliquer la politique : Activé, ce tenant dépend encore du type de politique en cours de retrait.
Couverture basée sur le risque dans l'Accès conditionnel. Allez dans Entra ID → Accès conditionnel → Politiques et vérifiez si une politique utilise Conditions → Risque utilisateur ou Conditions → Risque de connexion. Si aucune n'existe — ou si les seules présentes sont encore en Rapport seul — il n'y a pas encore de remplacement fonctionnel, quel que soit l'état affiché par l'ancien tableau de bord.

Un tenant peut échouer à l'une ou l'autre vérification indépendamment : certains ont déjà construit des politiques de risque dans l'Accès conditionnel et ont simplement oublié de désactiver les anciennes (redondant, pas urgent) ; d'autres n'ont ni l'un ni l'autre, ce qui est la combinaison qui mène à zéro application basée sur le risque à la date de retrait.

Remédiation : migrer avant le 1er octobre 2026

Microsoft Learn documente un chemin de migration précis, en trois étapes :

Construisez d'abord les équivalents en Accès conditionnel, en mode rapport seul. Créez une politique basée sur le risque utilisateur et une politique basée sur le risque de connexion dans l'Accès conditionnel (manuellement, ou à partir d'un modèle d'Accès conditionnel), en ciblant Tous les utilisateurs avec les comptes d'accès d'urgence (break-glass) exclus. Si vous partez d'un modèle, ajoutez vous-même cette exclusion une fois la politique créée : les modèles de Microsoft n'excluent que le compte qui crée la politique, pas les comptes break-glass du tenant. Laissez d'abord Activer la politique sur Rapport seul.
Validez, puis activez les politiques. Utilisez les informations en mode rapport seul de l'Accès conditionnel pour confirmer que les nouvelles politiques réagissent comme le faisaient les anciennes, avant de faire basculer Activer la politique de Rapport seul à Activé.
Désactivez les anciennes politiques. Retournez dans ID Protection → Tableau de bord, ouvrez chaque ancienne politique de Risque utilisateur et de Risque de connexion, et réglez Appliquer la politique sur Désactivé — les directives de Microsoft s'arrêtent avant la suppression, seule la désactivation est demandée.

Pour les tenants qui ont besoin d'une aide directe, Microsoft Learn documente un chemin de demande de support précis : déposez une Nouvelle demande de support, décrivez le problème comme « Migrate legacy ID Protection policy » [Migrer l'ancienne politique ID Protection], et sélectionnez Connexion Microsoft Entra et authentification multifacteur → Configuration des paramètres de politique nouveaux ou existants.

Deux éléments connexes méritent d'être vérifiés en même temps que cette migration : les politiques de risque — risque de connexion et risque utilisateur, qu'elles proviennent d'ID Protection ou de l'Accès conditionnel — figurent parmi les fonctionnalités que Microsoft réserve à Entra ID P2 ou à la Microsoft Entra Suite et sont indisponibles en Free ou en P1, et toute nouvelle politique devrait suivre la même discipline de validation en mode rapport seul que tout autre déploiement d'Accès conditionnel — une politique laissée indéfiniment en mode rapport seul offre la même absence totale d'application qu'aucune politique du tout. Il vaut aussi la peine de revoir la couverture de base de l'Accès conditionnel pendant que vous y êtes, puisqu'un tenant qui migre ses politiques de risque est un tenant déjà en train d'auditer sa posture d'Accès conditionnel.

Ce retrait s'ajoute à une série d'échéances Entra datées en 2026 — l'application du SSPR limitée aux méthodes enregistrées en novembre en est une autre, avec une coupure nette et aucun repli silencieux — et la leçon opérationnelle est la même à chaque fois : un avis « sera retiré » de Microsoft est une tâche à faire, pas une migration en arrière-plan.

Comment EtcSec détecte cela

L'audit Azure d'EtcSec mesure ce qui subsiste après le retrait : si une politique d'Accès conditionnel activée porte réellement une condition de risque. CA_NO_RISK_BASED_USER et RISK_NO_USER_RISK_POLICY se déclenchent tous deux lorsqu'aucune politique d'Accès conditionnel activée ne définit de niveaux de risque utilisateur ; CA_NO_RISK_BASED_SIGNIN et RISK_NO_SIGNIN_RISK_POLICY se déclenchent tous deux lorsqu'aucune ne définit de niveaux de risque de connexion. Les quatre contrôles lisent l'ensemble des politiques d'Accès conditionnel du tenant — aucun ne lit le volet des anciennes politiques ID Protection.

Deux conséquences méritent d'être énoncées précisément. D'abord, un tenant dont la réponse au risque vit uniquement dans l'ancienne interface ID Protection échoue à ces contrôles dès aujourd'hui, pas le 2 octobre 2026 — le constat est déjà présent dans l'audit, et c'est exactement la tâche de migration que crée cette échéance. Ensuite, les contrôles ne comptent une politique que dans l'état enabled : une politique d'Accès conditionnel basée sur le risque encore garée en rapport seul ne les valide pas, ce qui correspond à la même réalité d'application décrite plus haut.