Politiques de risque Entra ID : elles cessent d'appliquer le 1er octobre 2026, sans prévenir

Une panne silencieuse, pas une fin de support

Le 1er octobre 2026, les politiques de risque configurées dans Microsoft Entra ID Protection cessent de s'appliquer. Pas de bannière rouge, pas d'avertissement au moment de la connexion, pas de blocage inattendu. Elles restent visibles dans le portail et elles arrêtent simplement de faire leur travail. C'est ce qui rend l'échéance plus traître qu'une fin de support classique : rien ne casse, donc rien n'alerte.

Deux protections tombent. La politique de risque utilisateur, qui force la remise à niveau d'un compte dont Microsoft juge les identifiants probablement compromis. Et la politique de risque de connexion, qui exige une authentification multifacteur quand une session sort du comportement normal. La détection de risque, elle, continue de tourner et de remplir le tableau de bord. Vous gardez l'écran, vous perdez le videur à la porte.

La date est confirmée sur la page Microsoft Learn consacrée aux politiques d'accès basées sur le risque, mise à jour le 14 août 2026. Le remplacement passe entièrement par l'accès conditionnel.

Deux politiques d'accès conditionnel, jamais une seule

La procédure documentée par Microsoft, mise à jour le 28 avril 2026, est manuelle. Aucune conversion automatique n'est documentée : ce qui n'est pas reconstruit à la main ne sera pas repris.

Premier réflexe à éviter, regrouper les deux conditions dans une même règle. Microsoft l'interdit explicitement, parce que les contrôles de remédiation attendus ne sont pas les mêmes. Il faut deux politiques distinctes.

• Risque utilisateur : tous les utilisateurs, toutes les ressources, condition « risque utilisateur » au niveau Élevé, octroi « Exiger une remédiation du risque ». Ce contrôle enchaîne automatiquement l'exigence de force d'authentification et une fréquence de connexion à chaque fois.
• Risque de connexion : mêmes cibles, condition « risque de connexion » aux niveaux Moyen et Élevé, octroi « Exiger une force d'authentification » avec authentification multifacteur, fréquence de connexion à chaque fois.
• Dans les deux cas, exclure les comptes d'accès d'urgence dits bris de glace, et sortir les comptes de service vers l'accès conditionnel pour identités de charge de travail.

Politiques de risque Entra ID et accès conditionnel : ce que le change fait gagner

Les deux politiques se créent en mode rapport seul, se valident sur les journaux de connexion, puis s'activent. Les anciennes se désactivent en dernier, depuis le tableau de bord d'ID Protection.

Vue de loin, l'opération ressemble à de la paperasse imposée. Elle règle pourtant de vraies limites de l'ancien modèle, qui était unique et global : un seul niveau de risque, un seul contrôle, pour tout le monde.

En accès conditionnel, on applique un seuil différent aux comptes à privilèges et aux utilisateurs standards, on teste en mode rapport seul avant d'imposer quoi que ce soit, on pilote le tout par l'API Graph, et on lit un diagnostic précis dans les journaux quand un utilisateur appelle le support. C'est aussi la fin d'une incohérence héritée : les conditions de risque vivaient dans un portail, le reste des règles d'accès dans un autre.

Les trois pièges qui font échouer la bascule

• L'inscription MFA. Un utilisateur qui n'a jamais inscrit de méthode d'authentification multifacteur ne peut pas se remédier lui-même : il est bloqué et il faut une intervention d'administrateur. Sur un parc avec des comptes dormants ou des employés de terrain, ça se compte en dizaines d'appels le premier matin.
• L'écriture différée des mots de passe. En identité hybride, la remédiation d'un risque utilisateur suppose que le changement de mot de passe redescende vers l'Active Directory local. Sans password writeback activé, la politique bloque sans offrir de sortie.
• La licence. Les conditions de risque en accès conditionnel exigent Entra ID P2 ou la suite Entra. Une organisation qui utilisait déjà les anciennes politiques est couverte. Celle qui n'a que le niveau P1 ne les a jamais eues, et le découvre parfois à cette occasion.

Ce qu'il reste à faire d'ici le 1er octobre

Fait maintenant, c'est une demi-journée de configuration et deux semaines d'observation passive. Fait après le 1er octobre, ce n'est plus une migration, c'est une période pendant laquelle les connexions à risque passent sans être challengées et personne ne s'en aperçoit. Devant un assureur cyber ou la Commission d'accès à l'information, la nuance entre « la politique existait » et « la politique appliquait » se défend mal. Pour faire l'inventaire et cadrer la bascule avec nous, parlez-en à un expert io4.

• Vérifier si les anciennes politiques sont réellement actives dans ID Protection. Beaucoup d'organisations les ont héritées d'un déploiement initial sans jamais les revisiter.
• Créer les deux politiques en mode rapport seul cette semaine, pour garder deux à trois semaines d'observation avant l'activation.
• Inventorier les utilisateurs sans méthode MFA inscrite, et vider la liste avant d'activer.
• Valider le password writeback si l'annuaire est hybride.
• Désactiver les anciennes politiques seulement après l'activation des nouvelles, pour ne pas ouvrir de fenêtre sans protection.