Le 19 octobre 2026, la page de connexion de Microsoft Entra ID (anciennement Azure AD) n'acceptera plus que des scripts hébergés par Microsoft. Si vos utilisateurs s'appuient sur une extension de navigateur, un gestionnaire de mots de passe ou un outil maison qui injecte du code dans cette page, ils risquent de le découvrir un matin, devant un écran de connexion qui ne se comporte plus comme avant. Ce guide vous donne une méthode d'audit en six étapes pour repérer ces dépendances, décider quoi faire de chacune et vérifier le résultat.
Ce qui change le 19 octobre 2026 sur la page de connexion
Microsoft annonce, dans le message MC1481309 du centre de messages, de nouvelles protections de type Content Security Policy (CSP) sur l'expérience d'authentification Microsoft Entra ID. Ces contrôles restreignent les pages de connexion aux scripts hébergés par Microsoft et visent à empêcher l'injection de scripts non autorisés, notamment les attaques par cross-site scripting (XSS).
L'action demandée aux administrateurs tient en une phrase : vérifier si des extensions de navigateur, des outils ou des solutions personnalisées injectent des scripts dans les pages de connexion Entra, car ces solutions devront peut-être être mises à jour. Nous sommes le 13 octobre 2026 : il reste six jours.
Le message MC1481309 ne nomme ni extension, ni éditeur, ni gestionnaire de mots de passe. Les familles citées dans ce guide (gestionnaires de mots de passe, branding, outils internes) sont des candidats logiques d'après leur mode de fonctionnement, pas une liste confirmée par Microsoft. L'audit sert précisément à transformer ces hypothèses en constats.
Pourquoi cela compte pour la sécurité : une page de connexion qui n'exécute que du code de confiance ferme une porte au vol d'identifiants par injection. Le revers est pratique : tout ce qui s'y greffait de manière légitime est traité comme du code étranger.
Prérequis
Avant de toucher quoi que ce soit, rassemblez les accès et les informations suivantes. L'audit lui-même est en lecture seule et ne demande aucune licence particulière en dehors de ce que vous possédez déjà .
- Un accès en lecture au Centre d'administration Microsoft 365 pour consulter le centre de messages (rôle de lecture, par exemple Lecteur global)
- Un accès en lecture au centre d'administration Microsoft Entra pour examiner la personnalisation de la page de connexion
- La liste des extensions de navigateur déployées ou autorisées dans l'organisation (stratégie de navigateur, outil de gestion des postes ou, à défaut, un questionnaire aux équipes)
- Un ou deux utilisateurs pilotes volontaires, avec les extensions les plus répandues installées, sur un poste non critique
- Le contact de l'éditeur de chaque gestionnaire de mots de passe utilisé en entreprise
- Un canal pour prévenir le support et les utilisateurs avant la date
Auditer les dépendances en six étapes
Le tableau ci-dessous résume les quatre familles à examiner. Les étapes qui suivent vous font parcourir chacune d'elles.
Ouvrez le Centre d'administration Microsoft 365 > Centre de messages, puis recherchez MC1481309. Relevez la date du 19 octobre 2026 et le texte de l'action requise, que vous collerez dans votre fiche de suivi.
Vous devez voir un message intitulé autour du blocage d'injection de scripts externes lors de la connexion à Microsoft Entra ID.
Ouvrez le centre d'administration Microsoft Entra et accédez à la rubrique de personnalisation de marque (Company branding) ; l'intitulé exact peut varier selon l'évolution du portail. Notez ce qui est configuré, puis demandez aux équipes web et identité si un script, une extension maison ou un outil de test a été ajouté en plus des réglages natifs.
Vous devez obtenir un document listant, pour chaque personnalisation, qui l'a mise en place et sur quel mécanisme elle repose. Une ligne « inconnu » est un résultat valide : elle devient une action de recherche.
Exportez la liste des extensions imposées ou autorisées par vos stratégies de navigateur. Si vous n'avez pas de stratégie, envoyez un court questionnaire aux utilisateurs avec trois questions : quel navigateur, quelles extensions de mots de passe, quelles extensions qui modifient l'apparence ou automatisent des pages.
Vous devez obtenir une liste dédupliquée, classée par nombre d'utilisateurs, avec les gestionnaires de mots de passe en tête.
Sur le poste pilote, ouvrez une fenêtre de navigation avec les extensions actives et lancez une connexion Microsoft Entra ID. Notez pour chaque extension si elle intervient sur la page : remplissage automatique, changement d'affichage, boutons ajoutés. Ouvrez aussi les outils de développement du navigateur pour consulter la liste des scripts chargés par les extensions, qui varie selon le navigateur.
Vous devez pouvoir associer chaque comportement observé à une extension précise. Celles qui n'interviennent pas sur la page sont, en principe, hors sujet.
Pour chaque dépendance identifiée, demandez à l'éditeur si son produit est compatible avec les protections annoncées et à partir de quelle version. En parallèle, prévoyez une solution de repli : saisie manuelle des identifiants, ou méthode de connexion qui ne dépend pas du remplissage automatique. Depuis début octobre 2026, Microsoft Entra reconnaît Windows Hello for Business et macOS Platform SSO comme facteurs MFA autonomes dans les scénarios pris en charge (MC1450134), ce qui peut réduire la dépendance aux mots de passe saisis dans le navigateur.
Vous devez obtenir, pour chaque ligne de votre inventaire, une décision : mettre à jour, remplacer, retirer ou accepter l'impact.
Rédigez un message court : date du 19 octobre, symptôme possible (remplissage automatique qui ne se déclenche plus, apparence de la page modifiée), geste de contournement et point de contact. Transmettez-le au support avec l'inventaire pour qu'il reconnaisse les signalements.
Vous devez avoir, avant le 19 octobre, une communication validée et un référent identifié par équipe.
Vérifier le résultat après le 19 octobre
La source ne mentionne aucun mode d'essai de ces protections : on ne peut donc valider qu'après l'entrée en vigueur. Prévoyez une vérification dès le 19 octobre, sur les mêmes postes pilotes qu'à l'étape 4.
- La page de connexion Microsoft Entra ID s'affiche normalement sur chaque navigateur et chaque profil pilote
- La connexion aboutit, y compris avec l'authentification multifacteur
- Les extensions de mots de passe se comportent comme prévu, ou l'écart est documenté avec son contournement
- Les outils internes inventoriés à l'étape 2 fonctionnent encore
- Le support n'a pas reçu de signalement inexpliqué sur la connexion dans la journée
Si un élément ne fonctionne plus, les outils de développement du navigateur affichent en règle générale, dans la console, un message mentionnant la Content Security Policy lorsqu'un script est refusé. Ce message vous donne un indice précis à transmettre à l'éditeur concerné.
Mise en œuvre : auditer les politiques d'accès conditionnel liées aux changements Entra de 2026
L'audit des extensions se fait sur les postes, pas par script. En revanche, deux autres changements Entra de la même période se vérifient automatiquement et se répètent sur plusieurs tenants. La documentation Microsoft Learn indique que les contrôles personnalisés de l'accès conditionnel sont retirés le 30 septembre 2026 avec fin de vie en mai 2027 (migration vers External MFA), et que les politiques de risque héritées d'ID Protection sont retirées le 1er octobre 2026 au profit de politiques d'accès conditionnel. Le script ci-dessous liste les politiques qui utilisent des contrôles personnalisés et celles qui ciblent un niveau de risque, et signale celles qui combinent risque utilisateur et risque de connexion, ce que Microsoft déconseille dans une même politique.
- Module requis :
Install-Module Microsoft.Graph.Identity.SignIns -Scope CurrentUser - Permission minimale : le scope délégué
Policy.Read.All, avec un rôle de lecture sur le tenant (par exemple Lecteur de sécurité) - Sortie : un fichier CSV et un tableau de synthèse des politiques à traiter. Le script est en lecture seule : il ne modifie rien.
1param(2 # Un ou plusieurs tenants à auditer ; vide = tenant de la connexion interactive3 [string[]]$TenantIds = @(),4 [string]$OutputPath = ('.\audit-entra-' + (Get-Date -Format 'yyyyMMdd') + '.csv')5)6 7Import-Module Microsoft.Graph.Identity.SignIns8 9if ($TenantIds.Count -eq 0) { $TenantIds = @('') }10 11$rapport = foreach ($tenant in $TenantIds) {12 # Connexion en lecture seule à Microsoft Graph13 if ($tenant) { Connect-MgGraph -TenantId $tenant -Scopes 'Policy.Read.All' -NoWelcome }14 else { Connect-MgGraph -Scopes 'Policy.Read.All' -NoWelcome }15 $ctx = Get-MgContext16 17 foreach ($p in (Get-MgIdentityConditionalAccessPolicy -All)) {18 # Contrôles personnalisés (custom controls) et niveaux de risque ciblés19 $custom = @($p.GrantControls.CustomAuthenticationFactors | Where-Object { $_ })20 $signIn = @($p.Conditions.SignInRiskLevels | Where-Object { $_ })21 $user = @($p.Conditions.UserRiskLevels | Where-Object { $_ })22 23 [pscustomobject]@{24 TenantId = $ctx.TenantId25 Politique = $p.DisplayName26 Etat = $p.State27 ControlesPersonnalises = ($custom -join ', ')28 RisqueConnexion = ($signIn -join ', ')29 RisqueUtilisateur = ($user -join ', ')30 # Vrai si les deux types de risque sont dans la même politique31 RisquesCombines = ($signIn.Count -gt 0 -and $user.Count -gt 0)32 Id = $p.Id33 }34 }35 Disconnect-MgGraph | Out-Null36}37 38# Export complet pour archivage39$rapport | Export-Csv -Path $OutputPath -NoTypeInformation -Encoding UTF840 41# Synthèse : politiques à migrer ou à scinder42$rapport |43 Where-Object { $_.ControlesPersonnalises -or $_.RisquesCombines } |44 Format-Table TenantId, Politique, Etat, ControlesPersonnalises, RisquesCombines -AutoSizeUne politique qui cible un niveau de risque n'est pas un problème en soi : c'est la forme attendue après migration. L'information utile est son absence. Si votre tenant n'en contient aucune alors que vous aviez des politiques de risque ID Protection, la migration n'a pas été faite. Les politiques héritées elles-mêmes n'apparaissent pas dans cette liste, puisqu'elles relèvent d'ID Protection et non de l'accès conditionnel.
Les autres échéances Entra à planifier
L'injection de scripts n'est pas votre seule échéance d'identité. Voici, d'après le centre de messages et la documentation Microsoft Learn, les dates qui entourent le 19 octobre.
Les contrôles personnalisés de l'accès conditionnel sont retirés, avec fin de vie en mai 2027. La cible est External MFA ; notre article sur la fin des Custom Controls pour la MFA détaille la transition : Microsoft Entra ID : fin des Custom Controls pour l'authentification MFA.
Les politiques de risque utilisateur et de risque de connexion d'ID Protection sont retirées. Elles étaient en lecture seule depuis le 31 juillet 2025. Il faut les recréer en accès conditionnel (licence Entra ID P2 ou Entra Suite).
La page de connexion n'accepte que les scripts hébergés par Microsoft (MC1481309).
L'opérateur de règle MemberOf disparaît pour les groupes dynamiques et les unités administratives dynamiques : réécrivez les règles qui l'emploient.
La réinitialisation de mot de passe en libre-service n'acceptera plus les coordonnées de l'annuaire qui ne sont pas enregistrées comme méthode d'authentification.
Microsoft retire son service intégré de SMS et d'appel vocal ; il faudra configurer un fournisseur de télécommunications pris en charge pour continuer.
Pour la suite du calendrier de l'année, notre revue des nouveautés de septembre 2026 pour les admins complète ce tableau.
En cas de problème
Le gestionnaire de mots de passe ne remplit plus la page
Vérifiez d'abord la version de l'extension : l'éditeur a peut-être publié un correctif. En attendant, demandez aux utilisateurs de saisir leur identifiant manuellement ou d'utiliser une méthode de connexion qui n'exige pas le remplissage automatique. Consignez le produit et la version dans votre inventaire pour relancer l'éditeur.
Un outil maison cesse de fonctionner Ă la connexion
Identifiez le script injecté grâce au message de la console du navigateur évoqué plus haut, puis demandez à l'équipe propriétaire de supprimer l'injection ou de passer par un mécanisme pris en charge par Microsoft Entra ID. Ne tentez pas de contourner la protection : le but du changement est précisément d'empêcher ce type d'ajout.
Une politique de risque migrée ne réagit pas comme avant
Controlez que la politique d'accès conditionnel équivalente est bien activée et non laissée en mode rapport seul. Vérifiez aussi qu'elle ne combine pas risque utilisateur et risque de connexion, ce que la documentation Microsoft Learn déconseille. Le script de la section précédente repère ces deux cas.
Si vous ne disposez que d'une heure cette semaine, consacrez-la à l'étape 3 et à l'étape 4 : un inventaire des extensions et un test sur un poste pilote vous apprennent plus que n'importe quelle lecture du message. Si votre organisation n'a aucune extension de mots de passe déployée et aucune personnalisation par script, votre exposition est probablement faible ; une vérification le 19 octobre suffit alors.
Pour aller plus loin
- Microsoft Entra ID security updates: What organizations need to do now : les autres changements Entra de 2026, dont les Custom Controls et l'accès conditionnel à l'enrôlement des identifiants
- Risk policies - Microsoft Entra ID Protection : la procédure officielle de migration des politiques de risque vers l'accès conditionnel
- Deprecation of Exchange Web Services in Exchange Online (Microsoft Learn) : la chronologie de la désactivation d'EWS, autre échéance d'octobre 2026
- Microsoft Entra ID : fin des Custom Controls pour l'authentification MFA : notre guide sur la transition vers External MFA
