Microsoft va désactiver NTLM par défaut dans les prochaines versions de Windows
La désactivation de NTLM par défaut annoncée par Microsoft marque un vrai changement de rythme dans la sécurisation des environnements Windows. Ce protocole, vieux de plus de trente ans, a longtemps survécu comme solution de repli : quand Kerberos échoue, quand une appli est trop ancienne, quand un équipement “hérité” traîne dans un coin du SI. Justement, c’est ce rôle de secours qui a entretenu sa présence. Sa disparition progressive va donc produire des effets très concrets, à la fois techniques et organisationnels, que les entreprises ont intérêt à anticiper dès maintenant.
NTLM : un héritage des années 1990, avec les faiblesses qui vont avec
NTLM a été conçu à une époque où les exigences de sécurité et les modèles de menace n’étaient pas ceux d’aujourd’hui. Il n’embarque pas les mécanismes modernes attendus pour une authentification robuste, comme une négociation mutuelle forte et des approches cryptographiques plus résilientes. Résultat : il est associé à des attaques bien documentées.
Le pass the hash illustre le problème : un attaquant qui récupère un hachage peut l’utiliser comme un “jeton” réutilisable. Le NTLM relay est un autre classique : l’authentification est captée puis redirigée vers une autre cible, ce qui ouvre la porte à des accès non autorisés sans forcément connaître le mot de passe. Dans un environnement Windows, ce type de faiblesse facilite aussi les mouvements latéraux, donc la propagation après une compromission initiale.
Et pourtant, NTLM est toujours là. Non pas parce qu’il est bon, mais parce qu’il est compatible. On le retrouve dans des environnements mixtes, des applications historiques, des imprimantes, certains équipements réseau ou des intégrations tierces. Dans beaucoup de SI, il reste le plan B automatique quand Kerberos n’est pas disponible.
Une transition en plusieurs temps, avec une logique d’audit puis de durcissement
Microsoft prévoit une trajectoire progressive en trois étapes. D’abord, mesurer : auditer l’usage réel de NTLM via les journaux d’événements et la télémétrie, afin d’identifier précisément où le protocole est encore utilisé. Ensuite, outiller : fournir des paramètres et des outils pour aider à migrer vers des mécanismes plus solides, en pratique Kerberos et Negotiate. Enfin, durcir : bloquer NTLM par défaut dans de futures versions majeures de Windows, tout en laissant une possibilité de réactivation temporaire via des stratégies de groupe pour gérer des cas résiduels.
Ce que ça change pour les DSI : inventaire, migration, tests
Le principal enjeu, c’est l’inventaire. Repérer toutes les dépendances à NTLM n’est pas toujours évident, surtout dans des SI hétérogènes avec des briques anciennes, des scripts d’administration et des intégrations oubliées. Une fois les dépendances identifiées, la migration vers Kerberos suppose une infrastructure Active Directory solide, avec une synchronisation des horloges fiable et des relations de confiance correctement établies.
Le risque opérationnel est clair : une désactivation trop rapide, sans campagne de tests, peut provoquer des ruptures de service. La bonne approche ressemble donc à un chantier piloté : cartographier, qualifier les impacts, corriger, tester, puis durcir progressivement.
Vers une authentification plus robuste et plus cohérente
La fin programmée de NTLM s’inscrit dans une stratégie plus large : éliminer les protocoles faibles et pousser des standards d’authentification modernes. À terme, l’écosystème Windows se dirige vers des mécanismes plus résilients, avec Kerberos et Negotiate en socle, et des options plus récentes comme Windows Hello for Business ou les tokens FIDO2, cohérentes avec une approche Zero Trust.
Au final, ce n’est pas une simple bascule technique. C’est une incitation forte à moderniser l’authentification, à réduire les exceptions, et à fermer un angle mort encore très exploité dans les environnements Windows.
Source : Microsoft
