Si des ordinateurs Windows 11 ont cessé de se connecter à votre Wi‑Fi d’entreprise après les correctifs de mi-octobre, ou si des utilisateurs ont soudainement commencé à voir des invites d’identification qu’ils n’avaient jamais vues auparavant, vous n’êtes pas seul. Après la mise à jour de sécurité Windows du 13 octobre 2026, de nombreux appareils joints à un domaine qui utilisent PEAP-MSCHAPv2 avec leur authentification Windows ne peuvent plus se connecter automatiquement au Wi‑Fi, au réseau filaire 802.1X ou au VPN.
Il s’agit d’un durcissement planifié de la part de Microsoft. Microsoft a annoncé ce changement en août 2025 dans le cadre de ses efforts pour abandonner NTLM, et la mise à jour d’octobre l’a activé par défaut pour les appareils qui n’avaient été configurés ni dans un sens ni dans l’autre.
Ce guide explique ce qui a changé, quels appareils sont concernés, comment confirmer que la mise à jour est en cause et comment reconnecter les utilisateurs dès aujourd’hui. Il présente également la solution durable : faire passer l’authentification réseau des mots de passe aux certificats avec EAP-TLS.
Ce que la mise à jour Windows d’octobre 2026 a changé
Microsoft a supprimé le protocole NTLMv1 de Windows 11 version 24H2 et Windows Server 2025. Une partie de la cryptographie NTLMv1 reste encore présente dans certains scénarios, notamment : MS-CHAPv2, la méthode interne derrière PEAP-MSCHAPv2 et EAP-MSCHAPv2, lorsqu’elle s’exécute dans un environnement joint à un domaine.
Une valeur de registre appelée BlockNtlmv1SSO contrôle si Windows autorise l’utilisation de ces informations d’identification dérivées de NTLMv1 pour l’authentification unique. Une valeur de 0 (mode Audit) autorise la requête et consigne un avertissement. Une valeur de 1 (mode Enforce) la bloque et consigne une erreur.
À partir de la mise à jour de sécurité du 13 octobre 2026, Windows considère une valeur BlockNtlmv1SSO manquante comme le mode Enforce. La mise à jour ne crée pas et ne modifie pas la valeur de registre. Elle modifie le comportement de Windows lorsque la valeur n'est pas présente, c'est pourquoi tant de parcs ont été pris au dépourvu alors que rien n'a changé dans Group Policy ni dans Intune.
Seul le chemin d’authentification unique est bloqué. Les utilisateurs qui saisissent leur nom d’utilisateur et leur mot de passe à l’invite peuvent toujours se connecter.
Le déploiement s’est fait par étapes. Les événements d’audit ont commencé à apparaître sur Windows 11 24H2 et les versions plus récentes fin août 2025, le déploiement a atteint Windows Server 2025 en novembre 2025, et Enforce est devenu le paramètre par défaut en octobre 2026. Microsoft a ajouté une note sur ce changement dans les notes de version de KB5127648 le 15 octobre, deux jours après la publication de la mise à jour, donc les administrateurs qui ont consulté les notes le jour de la publication ne l’y ont pas trouvée.
Version Windows | Mise à jour du 13 octobre 2026 | Version du build de l’OS |
Windows 11, version 26H2 | KB5127648 | 26300.9711 |
Windows 11, version 25H2 | KB5127648 | 26200.9711 |
Windows 11, version 24H2 | KB5127648 | 26100.9711 |
Windows 11, version 26H1 | KB5127646 | 28000.3231 |
Windows Server 2025 a reçu le même changement dans KB5126646, publiée le même jour.
Qui est concerné (et qui ne l'est pas)
Un appareil est concerné lorsque les quatre conditions suivantes s’appliquent :
Il exécute Windows 11 version 24H2 ou ultérieure, ou Windows Server 2025, avec la mise à jour d'octobre 2026 installée.
Credential Guard n’est pas en cours d’exécution.
La valeur de registre BlockNtlmv1SSO n'a pas été définie.
Son profil Wi‑Fi, filaire ou VPN utilise MS-CHAPv2 avec l’authentification unique à la connexion Windows, comme le font généralement les profils PEAP-MSCHAPv2 et EAP-MSCHAPv2.
Les appareils sur lesquels Credential Guard était en cours d’exécution se trouvaient déjà dans cette situation avant octobre. Credential Guard bloque à lui seul l’authentification unique MS-CHAPv2, et il est activé par défaut depuis Windows 11 version 22H2 pour les appareils éligibles sous licences Enterprise et Education, ainsi que certaines licences Pro. La valeur de registre ne fait rien pour ces appareils. Quoi qu’il en soit, l’authentification unique PEAP sur les appareils Windows gérés touche à sa fin.
Type de connexion | Concerné par la mise à jour d’octobre ? |
PEAP-MSCHAPv2 ou EAP-MSCHAPv2 avec authentification unique de connexion Windows | Oui, bloqué |
PEAP-MSCHAPv2 avec des identifiants saisis à l’invite | Non, la connexion fonctionne toujours |
EAP-TLS (basé sur des certificats) | Non |
WPA2-Personal ou WPA3-Personal (phrase secrète partagée) | Non |
appareils macOS, iOS, Android, Linux et ChromeOS | Non, le changement concerne uniquement Windows |
Le blocage se produit sur l’appareil Windows, avant même qu’une réponse d’authentification n’atteigne le serveur RADIUS. C’est pourquoi les journaux RADIUS n’affichent souvent rien d’utile lors de ces échecs, et pourquoi aucun paramètre côté serveur ne permet de rétablir l’authentification unique.
Comment confirmer que la mise à jour en est la cause
Avant de modifier des paramètres, confirmez que c’est bien la mise à jour d’octobre qui bloque la connexion. Ces vérifications prennent quelques minutes sur un appareil concerné :
Vérifiez si la mise à jour est installée. Accédez à Settings > Windows Update > Update history et recherchez KB5127648, ou exécutez winver et comparez le numéro de build au tableau ci-dessus.
Ouvrez l’Observateur d’événements et accédez à Applications and Services Logs > Microsoft > Windows > NTLM > Operational.
Recherchez l’ID d’événement 4025 (Erreur) au moment de l’échec de la connexion. Son texte indique : "Une tentative d’utilisation d’informations d’identification dérivées de NTLMv1 pour l’authentification unique a été bloquée en raison de la politique."
Vérifiez le profil réseau. S’il utilise PEAP-MSCHAPv2 avec "Utiliser automatiquement mon nom d’ouverture de session et mon mot de passe Windows" sélectionné, vous avez trouvé la cause.
L’ID d’événement 4024 mérite aussi d’être vérifié. C’est l’avertissement du mode Audit dans le même journal, et sur les appareils qui n’ont pas encore installé la mise à jour d’octobre, il signale les machines qui cesseront de fonctionner lorsqu’ils l’installeront. La collecte des événements 4024 et 4025 sur l’ensemble de votre parc vous donne un inventaire de tous les appareils et profils qui dépendent encore de l’authentification unique PEAP, dont vous aurez besoin pour la migration plus loin dans ce guide.
La solution de contournement à court terme, et pourquoi elle n’est que temporaire
Il existe plusieurs façons de reconnecter les utilisateurs pendant que vous préparez une solution durable. Chacune fait gagner du temps et maintient la dépendance sous-jacente en place.
Définissez BlockNtlmv1SSO sur 0
Le fait de définir explicitement BlockNtlmv1SSO sur 0 remet l’appareil en mode Audit, ce qui rétablit l’authentification unique PEAP-MSCHAPv2 tout en conservant la mise à jour de sécurité d’octobre installée. Aucun redémarrage n’est nécessaire.
Paramètre | Valeur |
Chemin du registre | HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0 |
Nom de la valeur | BlockNtlmv1SSO |
Tapez | REG_DWORD |
Données | 0 = Audit (autorisé et journalisé), 1 = Appliquer (bloqué) |
À grande échelle, déployez la valeur via un élément de registre Group Policy Preferences ou un script de remédiation Intune. Prévoyez un moyen d’atteindre les appareils déjà hors du réseau, comme un port filaire, un réseau invité ou une connexion avec saisie d’identifiants, car ils ne peuvent pas recevoir la stratégie tant qu’ils ne se reconnectent pas. Le paramètre n’a aucun effet sur les appareils où Credential Guard est en cours d’exécution.
Microsoft décrit le mode Audit comme quelque chose qui "ne devrait être considéré que comme une exception de sécurité temporaire et limitée," car il réduit la protection offerte par le mode Application. Limitez-le aux appareils qui en ont besoin, fixez une date de fin et suivez-le comme n’importe quel autre risque en cours.
Demandez aux utilisateurs de saisir leurs identifiants
Les utilisateurs peuvent oublier le réseau enregistré et se reconnecter en saisissant leur nom d’utilisateur et leur mot de passe à l’invite. Cela fonctionne sans aucun changement de configuration, mais cela ajoute des frictions pour chaque utilisateur, n’aide pas les appareils qui ont besoin d’un accès réseau à l’écran de connexion et maintient les mots de passe dans le parcours de connexion au réseau.
Pourquoi désinstaller la mise à jour est une mauvaise option
La désinstallation de KB5127648 rétablit l’ancienne valeur par défaut, mais supprime également les correctifs de sécurité du mois. Les mises à jour cumulatives ultérieures incluent le même changement, donc le problème réapparaît à la prochaine mise à jour de l’appareil. Microsoft présente cette valeur de registre comme le chemin d’exception pris en charge.
Pourquoi MS-CHAPv2 est en cours d’abandon, sur Windows et au-delà
La solution de contournement via le registre permet à PEAP-MSCHAPv2 de continuer à fonctionner, mais le protocole qu’elle préserve présente des faiblesses bien documentées, et la pression pour l’abandonner vient de plus d’un côté.
Les faiblesses à l’origine de ce changement
Les propres recommandations de Microsoft indiquent que les points de terminaison Wi-Fi et VPN basés sur MS-CHAPv2 sont vulnérables à des attaques similaires à celles visant NTLMv1. Les principaux problèmes sont bien établis :
Il repose sur un hachage de mot de passe hérité. La réponse MS-CHAPv2 est construite à partir d’un hachage MD4 du mot de passe de l’utilisateur en utilisant la même conception défi-réponse basée sur DES que NTLMv1, c’est pourquoi Windows la traite comme un identifiant dérivé de NTLMv1.
Il a été publiquement compromis en 2012. Lors de la DEF CON 20, les chercheurs Moxie Marlinspike et David Hulton ont montré qu’un échange MS-CHAPv2 capturé peut être réduit au cassage d’une seule clé DES de 56 bits, avec un taux de réussite de 100 % quelle que soit la robustesse du mot de passe.
Sa protection dépend du fait que chaque client soit configuré correctement. PEAP encapsule MS-CHAPv2 dans un tunnel TLS, mais seuls les clients qui valident le certificat du serveur RADIUS bénéficient de cette protection. Un client qui ignore la validation peut être amené à s'authentifier auprès d'un point d'accès jumeau malveillant qui capture l'échange.
Cela reste un mot de passe. Les mots de passe peuvent être hameçonnés, partagés et réutilisés, et chaque réinitialisation ou expiration peut déconnecter un appareil du réseau jusqu’à ce que l’utilisateur se reconnecte.
Le protocole lui-même vient ensuite
Microsoft restreint MS-CHAPv2 côté client. L'organisme de normalisation qui maintient RADIUS travaille du côté du protocole.
Le projet actuel du groupe de travail RADEXT de l’IETF, "Deprecating Insecure Practices in RADIUS," comprend une section qui déprécie officiellement MS-CHAP. Le même projet déprécie également RADIUS sur UDP et TCP en dehors des réseaux sécurisés et préconise des transports sécurisés tels que RadSec (RADIUS over TLS). Il s’agit encore d’un travail en cours, mais cela montre la direction que prennent les normes de sécurité RADIUS. Pour en savoir plus sur la couche transport, consultez notre comparaison de RADIUS et RadSec.
Définir BlockNtlmv1SSO sur 0 ne traite aucune de ces deux tendances. Abandonner MS-CHAPv2 traite les deux.
La solution définitive : faire passer les appareils Windows à EAP-TLS
Microsoft recommande de faire passer les connexions Wi-Fi et VPN de MS-CHAPv2 à une authentification basée sur des certificats, comme EAP-TLS ou PEAP-TLS. Pour la plupart des organisations, EAP-TLS est la voie la plus directe.
Pourquoi EAP-TLS n’est pas concerné
EAP-TLS authentifie l’appareil ou l’utilisateur à l’aide d’un certificat et d’une clé privée. Aucun mot de passe n’est impliqué, et Windows n’a pas besoin d’un identifiant de connexion enregistré, donc la modification de BlockNtlmv1SSO ne s’applique jamais. Credential Guard ne bloque pas non plus l’authentification basée sur un certificat.
Cette évolution résout également des problèmes que PEAP-MSCHAPv2 a toujours eus :
Il n’y a aucun mot de passe à hameçonner, à casser hors ligne ou à capturer via un point d’accès jumeau malveillant.
Un certificat d’appareil permet à un ordinateur portable de se connecter depuis l’écran de connexion, avant que quiconque ne se connecte.
Les réinitialisations et expirations de mots de passe ne déconnectent plus les appareils du Wi‑Fi.
La même approche basée sur les certificats fonctionne pour le Wi‑Fi, le réseau filaire 802.1X et le VPN.
Comment migrer sans interruption de service
PEAP et EAP-TLS peuvent fonctionner côte à côte pendant la transition, afin que les appareils puissent migrer par groupes plutôt que tous en même temps. Ces étapes fonctionnent avec n’importe quel fournisseur d’identité et toute plateforme MDM :
Établissez un inventaire. Utilisez les événements 4024 et 4025 pour lister les appareils concernés et les profils réseau qu’ils utilisent. Séparez les appareils gérés par l’entreprise des appareils personnels et non gérés, car ils recevront les certificats différemment.
Décidez comment les certificats seront délivrés. Une autorité de certification sur site, telle qu’Active Directory Certificate Services, est l’une des options. Une autorité de certification hébergée dans le cloud évite d’avoir à gérer vous-même cette infrastructure.
Distribuez des certificats aux appareils gérés. Utilisez le profil de certificat SCEP de votre MDM, qu'il s'agisse de Microsoft Intune, Jamf, Workspace ONE, Kandji ou Google Admin pour Chromebooks.
Offrez aux appareils non gérés et BYOD une voie en libre-service. Un flux d’inscription qui installe le certificat et le profil réseau permet aux utilisateurs d’intégrer leurs propres appareils sans ticket IT.
Configurez votre serveur RADIUS pour accepter EAP-TLS en plus de PEAP pendant la transition.
Déployez un profil réseau EAP-TLS. Configurez-le pour valider le certificat du serveur RADIUS à l’aide de la racine de confiance et du nom du serveur.
Commencez par un projet pilote avec une équipe ou un site. Confirmez que les appareils se connectent à l’écran de connexion et restent connectés après un changement de mot de passe.
Déployez par étapes par service, emplacement ou groupe d’appareils.
Supprimez PEAP. Supprimez l’ancien profil des appareils, supprimez toutes les exceptions BlockNtlmv1SSO et désactivez MS-CHAPv2 sur le serveur RADIUS.
Les Mac, téléphones et Chromebooks ne sont pas affectés par la mise à jour d’octobre, mais si votre objectif est de retirer totalement PEAP du réseau, ils auront eux aussi besoin de certificats. Notre guide sur le Wi‑Fi basé sur des certificats pour les Chromebooks gérés couvre l’aspect ChromeOS.
Comment Foxpass vous aide à abandonner PEAP-MSCHAPv2
Foxpass, de Splashtop, fournit une authentification RADIUS hébergée dans le cloud pour les réseaux Wi‑Fi, VPN et filaires, ainsi qu’une PKI cloud pour émettre des certificats d’appareils et d’utilisateurs. Ensemble, Foxpass Cloud RADIUS et Foxpass Cloud PKI couvrent chaque étape de la migration ci-dessus, sans serveurs sur site à déployer ni à maintenir.
Émission de certificats sans infrastructure sur site : Foxpass Cloud PKI agit comme votre autorité de certification, et Foxpass Cloud RADIUS valide le certificat à chaque tentative de connexion.
Distribution de certificats via le MDM que vous utilisez déjà : Les appareils gérés reçoivent des certificats via le point de terminaison SCEP Foxpass depuis Microsoft Intune, Jamf, Kandji, Addigy, Workspace ONE, Mosyle, NinjaOne et Google Admin pour les Chromebooks. Les équipes qui gèrent des terminaux Windows avec Splashtop AEM peuvent également distribuer des certificats via Splashtop AEM.
Accès lié au fournisseur d’identité que vous utilisez déjà : Foxpass synchronise les utilisateurs et les groupes depuis Microsoft Entra ID, Google Workspace, Okta et OneLogin, afin que l’accès au réseau suive le même annuaire que tout le reste. Nous détaillons davantage l’aspect Okta et Google Workspace dans l’authentification basée sur des certificats pour Okta et Google Workspace.
Un parcours en libre-service pour BYOD et les appareils non gérés : le programme d’installation de certificats Foxpass BYOD permet aux utilisateurs d’inscrire eux-mêmes leurs appareils Mac, Windows, iOS, Android et Chromebook.
Un accès qui prend fin lorsqu’une personne part : Comme un certificat peut contenir l’adresse e-mail ou l’ID de l’appareil de l’utilisateur, Foxpass peut confirmer au moment de la connexion que l’utilisateur ou l’appareil est toujours actif dans votre annuaire.
Une migration progressive : Foxpass Cloud RADIUS prend en charge EAP-TLS et EAP-TTLS côte à côte, afin que vous puissiez migrer les appareils vers des certificats par vagues.
Trafic RADIUS chiffré : Foxpass prend en charge RadSec, qui protège le trafic d’authentification entre vos points d’accès et le serveur RADIUS avec TLS.
En savoir plus sur l’accès Wi-Fi et VPN sans mot de passe avec Foxpass.
Abandonnez définitivement PEAP au profit du Wi‑Fi basé sur des certificats
Le paramètre BlockNtlmv1SSO peut permettre aux utilisateurs de Windows 11 de se reconnecter dès aujourd’hui, mais il maintient la connexion au réseau liée à un protocole dont Microsoft recommande de s’éloigner, et que l’IETF est en train de déprécier au niveau du protocole. L’authentification basée sur des certificats supprime cette dépendance, afin que les futurs renforcements de sécurité de Windows ne se transforment pas en nouvelle vague de tickets Wi-Fi.
Foxpass Cloud RADIUS et Foxpass Cloud PKI vous permettent d’effectuer cette transition avec le fournisseur d’identité et le MDM que vous utilisez déjà. Démarrez un essai gratuit ou planifiez une démo pour voir comment Foxpass s’intègre à votre environnement.
