À retenir — Authentification NTLM 2026

  • NTLM (NT LAN Manager) est un protocole d'authentification Microsoft datant de 1993, originellement conçu pour Windows NT — toujours actif en 2026 sur 95 % des AD français malgré annonces dépréciation.
  • Trois versions : LM (1993, déprécié, ~6 ms à cracker), NTLMv1 (1996, vulnérable challenge fixe), NTLMv2 (2000, plus robuste mais relay possible).
  • Vulnérabilités majeures 2026 : NTLM relay (Responder + NTLMrelayx), Pass-the-Hash, kerberoasting comparatif, CVE-2026-32202 APT28 zéro-clic.
  • Microsoft a annoncé en juillet 2024 la dépréciation officielle de NTLM dans Windows 11/Server 2025+ — désactivation complète prévue 2027-2028 selon évolution adoption Kerberos.
  • Plan de migration : audit usage NTLM (Event ID 8004, 4624 LogonType 3), priorisation NTLMv1 puis NTLMv2, désactivation progressive GPO, contournements pour applications legacy.

L'authentification NTLM (NT LAN Manager) est l'un des piliers historiques de l'écosystème Microsoft Windows — et l'un des plus problématiques en 2026. Conçu en 1993 pour Windows NT 3.1, évolué en NTLMv1 (1996) puis NTLMv2 (Windows 2000), NTLM reste actif sur 95 % des Active Directory français en 2026 malgré 25 ans d'efforts pour le remplacer par Kerberos et plus récemment par les protocoles passwordless (FIDO2, Windows Hello for Business). Cet article retrace l'histoire de NTLM, détaille les vulnérabilités exploitées en 2026 (NTLM relay moderne, Pass-the-Hash, CVE-2026-32202 zero-click exploitée par APT28), compare avec Kerberos, et propose un plan de migration concret aligné sur la dépréciation officielle annoncée par Microsoft en juillet 2024. Issu de 50+ audits AD français et 12+ projets de durcissement NTLM menés 2024-2026.

1. Histoire de NTLM — de Windows NT à 2026

NTLM succède au protocole LM (LAN Manager) issu d'OS/2 1.x et de Microsoft LAN Manager 1987 — un protocole d'authentification challenge-response basé sur DES sur des hashes 14 caractères découpés en deux blocs 7 caractères. LM est dès 1993 considéré comme vulnérable mais Microsoft maintient compatibilité dans Windows NT 3.1. NTLMv1 (1996, Windows NT 3.51) introduit MD4 sur la passphrase Unicode + DES sur le challenge — amélioration sur LM mais toujours vulnérable au crack rainbow tables. NTLMv2 (Windows 2000) ajoute timestamp, double challenge client/serveur, HMAC-MD5 — résistant aux rainbow tables classiques. Microsoft pousse Kerberos v5 comme protocole par défaut sur AD Windows 2000+ pour authentification interactive domaine, mais maintient NTLM pour compatibilité applications, accès non-AD, et fallback. En 2026, NTLM persiste malgré 25 ans de Kerberos disponible. Cause : ~60 % des applications LOB anciennes appellent NTLM en dur, et la majorité des SI n'ont jamais audité leur usage. Voir NTLM Relay 2026 : Attaque Moderne et Défense.

2. Fonctionnement protocolaire NTLM

Le flux NTLMv2 est un challenge-response en 3 messages : (1) Type 1 — Negotiate : client envoie au serveur ses capabilities (NTLMv1, NTLMv2, signing, sealing, encryption) ; (2) Type 2 — Challenge : serveur retourne un challenge 8 octets random + target info (TargetName, TargetInfo, Timestamp) ; (3) Type 3 — Authenticate : client envoie réponse calculée à partir du hash NT du mot de passe utilisateur, du challenge serveur, d'un challenge client (Client Challenge), et du timestamp. Le serveur vérifie soit localement (compte local) soit en transmettant au DC qui re-calcule via NetLogon. Particularité notable : le hash NT (MD4 du mot de passe Unicode) est suffisant pour s'authentifier — pas besoin du mot de passe en clair — d'où l'attaque Pass-the-Hash. Voir Pass-the-Hash : Attaque NTLM Active Directory.

3. NTLM relay — l'attaque dominante 2024-2026

L'attaque NTLM relay (publiée 2001 par SMB Squatting, industrialisée depuis 2008 par Squirtle puis ntlmrelayx) reste l'attaque AD la plus rentable en 2026. Mécanique : (1) attaquant force une victime (machine ou utilisateur) à s'authentifier vers son service contrôlé via coercion (PetitPotam, PrintNightmare, DFSCoerce, WebDav over Webclient, LDAP referrer abuse) ou empoisonnement (Responder LLMNR/NBT-NS/mDNS) ; (2) attaquant relay l'authentification vers un service cible (SMB, LDAP/LDAPS, HTTP/IIS, AD CS, MSSQL) ; (3) si signature désactivée côté cible et MFA non requise, attaquant obtient session authentifiée. Les cibles privilégiées en 2026 : AD CS (Active Directory Certificate Services, abuse ESC8 via HTTP enrollment endpoint) permettant demande certificat user/machine → Pass-The-Cert ; LDAPS sur DC pour modifier ACL ou ajouter user à Domain Admins ; SMB pour exécution distante. Outils : Responder (LLMNR/NBT-NS poisoning), Coercer (15+ coercion techniques), ntlmrelayx Impacket (relay engine). Voir NTLM Relay 2026 : Techniques et Défenses Actuelles.

4. CVE-2026-32202 — zero-click NTLM exploité par APT28

CVE-2026-32202 publiée en mai 2026 affecte Windows 10/11 et Windows Server 2016/2019/2022/2025. Description : "Windows Shell allows unauthenticated remote attackers to coerce NTLM authentication of victim systems via specially crafted file that user merely needs to extract or display in Explorer preview pane". CVSS 7.5. Mécanique : fichier .library-ms ou .theme contenant un chemin SMB pointant vers un serveur attaquant — quand Windows Explorer indexe l'icône via preview pane (sans clic utilisateur), le système initie une authentification NTLM vers le serveur attaquant. Exploitation : zéro-clic, fichier livré par email (zip extrait), partage SMB, OneDrive sync. Groupe APT28 (Sofacy/Fancy Bear, attribué GRU Russie) observé en exploitation massive avril-mai 2026 contre OTAN et entités gouvernementales européennes. Microsoft a publié le patch en mai 2026 (KB5039212 et équivalents), mais un re-patch a été nécessaire en juillet 2026 (KB5040872) car le premier patch était contournable. Voir CVE-2026-32202 zero-click NTLM Windows exploité par APT28.

5. Pass-the-Hash — exploit historique

Pass-the-Hash (PtH) publiée par Paul Ashton en 1997 reste en 2026 une attaque majeure. Principe : NTLM utilise le hash NT directement pour calcul de la réponse au challenge — un attaquant possédant le hash NT (extrait via Mimikatz, dump LSASS, SAM file dump, ntds.dit dump) peut s'authentifier comme l'utilisateur sans connaître le mot de passe. Outils : mimikatz.exe sekurlsa::pth /user:Administrator /domain:corp.local /ntlm:HASH /run:cmd.exe lance un nouveau processus dans un contexte authentifié avec le hash. Combinable avec : Pass-the-Ticket (Kerberos), Over-Pass-the-Hash (utilise hash NTLM pour pré-authentifier Kerberos), Pass-the-PRT (Entra ID Primary Refresh Token, équivalent moderne). Défenses : (1) Credential Guard (Windows 10/11/Server 2019+ activé par défaut Windows 11 22H2+) isole hashes via VBS ; (2) LSA Protection RunAsPPL ; (3) Tier 0 separation pour limiter l'extraction sur postes utilisateurs ; (4) désactivation NTLM à terme ; (5) LAPS pour empêcher mot de passe local admin unique réutilisable. Voir Mimikatz : Extraction Credentials Active Directory.

6. NTLM vs Kerberos — comparatif

Comparatif NTLM vs Kerberos 2026
CritèreNTLMv2Kerberos v5
Année introduction2000 (NT4 SP4)1989 (MIT), Windows 2000
ModèleChallenge-ResponseTicket-based (KDC)
Mutual authenticationNonOui (optionnelle)
Single Sign-OnLimitéNatif
Vulnérabilité relayÉlevéeFaible (interdit par design)
Vulnérabilité Pass-the-HashOui (hash NT directement utilisable)Pass-the-Ticket différent, exigences supplémentaires
KerberoastingN/AOui sur SPN accounts
Crypto par défautRC4-HMAC + MD5AES-256 (Windows 7+)
Dépendance infraAucune (peut être local)KDC (DC AD) obligatoire
Support cross-realmLimitéTrust forêt natif
Avenir MicrosoftDépréciation 2024-2028Conservé long-terme

Kerberos est fondamentalement plus sûr que NTLM par design : mutual auth, pas de hash réutilisable à grande échelle, exigence KDC. Mais Kerberos a ses propres attaques : kerberoasting, AS-REP roasting, Golden Ticket, Silver Ticket, Pass-the-Ticket, Constrained / Unconstrained Delegation abuse, RBCD (Resource-Based Constrained Delegation). Voir Kerberoasting 2026 : Attaque, Détection et Défense AD et Golden Ticket : Attaque Kerberos.

7. Dépréciation officielle Microsoft 2024-2028

Microsoft a publié en juillet 2024 son annonce officielle de dépréciation de NTLM (blog Microsoft Tech Community, David Weston, VP Enterprise Security). Calendrier annoncé : (1) 2024 — Windows Server 2025 et Windows 11 24H2 introduisent NTLM auditing avancé et signaling de dépréciation ; (2) 2025 — désactivation NTLMv1 par défaut sur nouveaux déploiements Windows 11/Server 2025 ; (3) 2026-2027 — annonce dépréciation totale visant Windows 12 / Server vNext, avec opt-in NTLMv2 pour cas legacy uniquement ; (4) 2028 — désactivation complète NTLM par défaut, opt-in restant possible pour 3-5 ans supplémentaires en compatibilité. Le successeur officiel : Kerberos + IAKerb (Initial and Pass Through Kerberos, RFC 6113) qui permet à Kerberos de fonctionner dans les scénarios actuellement réservés à NTLM (workgroups, applications legacy, scénarios non-domaine), et Local KDC pour authentification machine locale sans DC. Sur Windows 11 22H2+ et Server 2025, IAKerb est déjà déployé en preview. Voir Chaîne d'exploitation Kerberos.

8. Plan de migration NTLM → Kerberos — 6 étapes

Plan opérationnel de migration en 6 étapes sur 6-18 mois selon ampleur. Étape 1 — Audit usage NTLM (1-2 mois) : activer NTLM Auditing via GPO (Event ID 8001/8002/8003/8004 sur DC, Event ID 4624 LogonType 3 + NetworkAuthenticationProtocol = NTLM côté serveurs), collecter 30-60 jours, identifier sources NTLM par application et compte. Étape 2 — Priorisation : NTLMv1 d'abord (peu d'usage en 2026, désactivation rapide), puis NTLMv2 par criticité. Étape 3 — Tests Kerberos : forcer Kerberos sur applications testables, mesurer impact, corriger SPN manquants. Étape 4 — Désactivation NTLMv1 : GPO Network security: LAN Manager authentication level = Send NTLMv2 response only. Refuse LM & NTLM, déploiement par vagues. Étape 5 — Restriction NTLMv2 par compte et serveur : GPO Network Security: Restrict NTLM (Audit puis Deny), exceptions pour applications legacy identifiées. Étape 6 — Désactivation complète NTLM : GPO finale, gestion exceptions résiduelles. Voir Migration MFA Entra : Révoquer les Sessions Legacy.

9. Détection des attaques NTLM dans SIEM

Détecter les attaques NTLM dans un SIEM exige les bons logs. Sources prioritaires : (1) DC Security Event Log — Event ID 4624 (logon success) avec LogonType 3 (network), Event ID 4625 (logon failure), Event ID 4768/4769 (Kerberos for context), Event ID 4670 (object permission change) ; (2) NTLM Auditing Events — Event ID 8001 à 8004 sur DC (NTLM logon, application identification), Event ID 4776 NTLM auth ; (3) Sysmon — Event ID 1 (process create) pour Mimikatz, NTLMrelayx, Responder ; (4) Network captures — détection SMB sans signing, LDAP simple bind non-LDAPS. KQL Sentinel : SecurityEvent | where EventID == 4624 | where LogonType == 3 | where AuthenticationPackageName == "NTLM" pour mesurer volume NTLM. Pour relay : SecurityEvent | where EventID == 4624 | where LogonType == 3 | where TargetUserName != computer name | join with Source IP anomaly. Voir Audit AD Automatisé PowerShell : Scripts 2026.

10. Contre-mesures immédiates — avant migration complète

En attendant la migration complète, 10 contre-mesures immédiates contre les attaques NTLM. (1) Désactiver NTLMv1 via GPO LAN Manager authentication level = Send NTLMv2 response only/refuse LM & NTLM ; (2) Activer SMB signing en obligatoire sur DC et fileservers (Microsoft network server: Digitally sign communications (always) = Enabled) ; (3) Activer LDAP signing + LDAPS channel binding sur DC ; (4) Désactiver LLMNR et NBT-NS via GPO ; (5) Désactiver WPAD ; (6) EPA (Extended Protection for Authentication) sur IIS, ADFS, Exchange ; (7) Credential Guard activé sur tous postes Windows 10/11 Enterprise ; (8) LSA Protection RunAsPPL ; (9) LAPS sur tous postes pour mots de passe locaux unique ; (10) Surveillance EDR sur Mimikatz, Responder, NTLMrelayx, Coercer. Voir Guide de Sécurisation Active Directory Windows Server.

11. Pièges legacy — applications LOB qui exigent NTLM

La principale difficulté de migration NTLM concerne les applications LOB legacy (Line of Business) qui appellent NTLM en dur dans leur code. Types récurrents observés : (1) applications .NET Framework < 4.6.2 utilisant System.Net.NetworkCredential sans configuration explicite Kerberos ; (2) applications Java avec JCIFS legacy ; (3) applications mainframe avec connecteurs SMB ; (4) scanners réseau / imprimantes envoyant scans en SMB share avec NTLM uniquement ; (5) backup software ancien (Backup Exec, NetBackup, Veeam versions < 11) ; (6) monitoring tools (PRTG, SolarWinds anciennes versions) ; (7) solutions de virtualisation (Citrix XenApp anciennes versions, Hyper-V management) ; (8) logiciels métiers sectoriels avec composants COM/DCOM. Stratégie : audit applicatif systématique, mise à jour applications quand possible, remplacement quand impossible, isolation réseau pour les irréductibles avec MFA en surcouche. Voir API Microsoft Graph M365 : Guide Audit Sécurité 2026.

12. Futur NTLM — IAKerb et Local KDC

Microsoft a annoncé deux technologies remplaçant NTLM dans les scénarios actuellement réservés : (1) IAKerb (Initial and Pass Through Kerberos, RFC 6113) — permet Kerberos dans des scénarios sans connectivité directe au KDC (workgroups, accès distant, applications legacy). Le client passe par un proxy intermédiaire qui relais les messages Kerberos au KDC. Déjà en preview Windows 11 22H2+, Windows Server 2025 ; (2) Local KDC — un KDC embarqué dans chaque machine Windows pour authentification machine locale (workgroup, accès local sans domaine), remplaçant l'authentification NTLM locale qui restait nécessaire pour comptes non-AD. En preview Windows 11 24H2. Ces deux technologies, déployées d'ici 2027, permettront de désactiver NTLM dans 99 % des scénarios. Les 1 % résiduels (applications legacy non-migrables) resteront sur opt-in NTLM jusqu'en 2030+. Plan de migration RSSI 2026-2028 : auditer + tester + désactiver NTLMv1 immédiatement, planifier basculement Kerberos d'ici 2027, IAKerb + Local KDC opt-in en 2027-2028.

Sources : Microsoft Tech Community blog "The evolution of Windows authentication" juillet 2024 ; Microsoft NTLM Auditing documentation ; MITRE ATT&CK technique T1550.002 (Pass the Hash), T1187 (Forced Authentication), T1557.001 (LLMNR/NBT-NS Poisoning), T1558.003 (Kerberoasting) ; CVE-2026-32202 advisory Microsoft MSRC mai 2026 ; ANSSI guide Active Directory 2024.

13. Articulation avec NIS2, DORA et ISO 27001 — comprendre les obligations 2026

Le sujet du authentification ntlm s'inscrit en 2026 dans un cadre réglementaire européen et français dense qui structure les obligations des organisations. Trois textes majeurs encadrent désormais la posture cyber. (1) Directive NIS2 (UE 2022/2555) transposée en droit français par la loi de novembre 2024 — élargit considérablement le périmètre par rapport à NIS1 : passage de ~300 à ~10 000 entités françaises classées soit Entités Essentielles (EE), soit Entités Importantes (EI). Les obligations centrales (article 21.2) incluent l'analyse de risques annuelle, la gestion des incidents avec notification ANSSI < 24h, la continuité d'activité, la sécurité de la chaîne d'approvisionnement, la sécurité de l'acquisition/développement/maintenance, l'évaluation de l'efficacité, la formation cyber, les politiques cryptographie et contrôle d'accès, l'authentification multifacteur. Les pratiques liées à authentification NTLM et la migration vers Kerberos touchent directement plusieurs de ces obligations. (2) Règlement DORA (UE 2022/2554) applicable depuis janvier 2025 — concerne les entités financières (banques, assurances, sociétés de gestion, fintechs). Cinq piliers : gestion des risques ICT, gestion des incidents, tests de résilience opérationnelle (TLPT triennal pour entités critiques), gestion des risques tiers ICT, échange d'informations. (3) ISO 27001:2022 — norme internationale du SMSI avec 10 clauses de management et 93 contrôles Annexe A organisés en 4 thèmes : organisationnel, personnel, physique, technologique. La certification ISO 27001 fournit un cadre robuste qui couvre l'essentiel des exigences NIS2 et DORA, avec mapping documenté. Voir ISO 27001:2022 Guide Complet Certification Expert et NIS2, DORA et RGPD : Cartographie des Exigences Croisées.

14. KPI et indicateurs de pilotage — mesurer l'efficacité

Au-delà de la mise en œuvre initiale, le pilotage des sujets relatifs au authentification ntlm exige des indicateurs mesurables et révisés mensuellement ou trimestriellement. Cinq familles d'indicateurs structurent un tableau de bord cyber moderne 2026. (1) Couverture : pourcentage d'actifs couverts par la mesure (endpoints sous EDR, comptes en MFA, applications avec WAF, etc.) avec cible >= 95 % pour les mesures critiques. (2) Performance opérationnelle : MTTD (Mean Time To Detect) cible < 4h pour incident critique, MTTR (Mean Time To Respond) cible < 24h, taux de remédiation des vulnérabilités critiques dans le SLA (cible > 90 % patchés J+15 du Patch Tuesday). (3) Conformité : score d'audit interne ou externe (cible > 75/100), nombre de non-conformités majeures (cible 0 par trimestre), avancement plan d'action (cible > 80 % à 6 mois). (4) Maturité : score CMMI par domaine (Initial / Managed / Defined / Quantitatively Managed / Optimizing), évolution annuelle attendue +1 niveau par domaine prioritaire. (5) Risque résiduel : nombre de risques résiduels élevés non traités, valeur en € des risques résiduels selon analyse EBIOS RM, vraisemblance / gravité moyennes. Ces KPIs alimentent les revues de direction trimestrielles (ISO 27001 clause 9.3) et les rapports COMEX trimestriels. Voir Tableau de Bord KPI ISMS ISO 27004 : Excel.

15. Retour d'expérience terrain — 3 missions anonymisées

Trois cas concrets observés sur missions 2024-2026 illustrent les enjeux pratiques autour du authentification ntlm. Cas A — ETI industrielle 1 800 postes multi-sites (anonymisée) : initiative de modernisation de la posture cyber lancée en 2024 à la demande du COMEX après tentative de ransomware (chiffrement partiel évité grâce à EDR). Périmètre : 5 sites France + 2 Allemagne, AD complexe avec 3 forêts, mix Windows/Linux/OT. Démarche : audit complet (12 jours), pentest externe + interne (15 jours), pentest applicatif sur 2 apps métier critiques (10 jours), plan d'action 18 mois. Investissement total accompagnement : 380 000 € HT sur 18 mois (audits + remédiation + formation). Résultats à 18 mois : score posture cyber passé de 48/100 à 84/100, certification ISO 27001 obtenue, posture NIS2 conforme, 0 incident critique post-remédiation. Cas B — PME services 220 salariés (anonymisée) : remplacement d'un ancien prestataire d'audit jugé trop superficiel, demande pour audit complet en première intention. Périmètre : 1 site principal + 3 antennes commerciales, M365 + AD basique, 1 application web SaaS interne. Démarche : audit cybersécurité PME 15 contrôles (8 jours), pentest externe léger (4 jours), accompagnement remédiation 60 jours. Investissement : 22 000 € HT total. Résultats : MFA déployée 100 %, EDR en place sur 100 %, sauvegardes 3-2-1 testées trimestriellement, conformité cyber-assurance obtenue avec réduction de prime 18 %. Cas C — Collectivité 8 000 agents (anonymisée) : préparation à homologation RGS renforcée d'une plateforme de téléservices avec 1,2 M usagers. Périmètre : portail web, back-office, base de données, intégrations multiples (FranceConnect, INSEE, ANTAI). Démarche : analyse EBIOS RM (3 mois), audit PASSI architecture + configuration + tests d'intrusion (6 semaines), constitution dossier d'homologation, commission, signature. Investissement : 145 000 € HT. Résultats : homologation niveau renforcé délivrée fin 2025, validité 3 ans avec revue annuelle, intégration smooth avec FranceConnect+, fréquentation usagers en croissance +27 %.

16. Erreurs fréquentes et bonnes pratiques 2026

Six erreurs récurrentes observées sur les sujets liés au authentification ntlm en 2024-2026, et leurs contournements. Erreur 1 — démarrage sans cadrage : se lancer dans la mise en œuvre sans phase préalable d'analyse de contexte, d'inventaire et de cartographie. Conséquence : périmètre mal défini, budget dérapant, livrable inadapté. Bonne pratique : 5-10 % du temps total en cadrage, ateliers contradictoires avec parties prenantes, RACI clair. Erreur 2 — copier-coller des bonnes pratiques sans adaptation : appliquer une checklist générique sans contextualiser à la taille, secteur, contraintes de l'organisation. Conséquence : surinvestissement ou sous-investissement, démotivation équipe. Bonne pratique : référentiel proportionné au profil (CIS Implementation Group 1 pour PME, IG2 pour ETI, IG3 pour grands comptes). Erreur 3 — focus sur l'outil au détriment du processus : acheter une solution technique (EDR, SIEM, IAM) sans définir au préalable les processus opérationnels et les rôles. Conséquence : outil sous-exploité, alertes ignorées, ROI faible. Bonne pratique : processus avant outil, formation équipes, runbooks documentés. Erreur 4 — absence de plan post-projet : finaliser la mise en œuvre sans plan de continuité opérationnelle, de revue périodique, de mise à jour. Conséquence : dérive lente de la posture, retour à l'état initial en 12-24 mois. Bonne pratique : plan annuel de mise à jour, revue trimestrielle KPI, audit annuel externe. Erreur 5 — sous-estimation de la conduite du changement : déployer techniquement sans accompagner les utilisateurs et opérationnels. Conséquence : résistance, contournements (post-it mots de passe, désactivation MFA, etc.). Bonne pratique : 15-25 % du budget projet en communication, formation, support. Erreur 6 — pas d'évaluation indépendante : s'auto-évaluer sans regard externe critique. Conséquence : angle mort persistants, biais de confirmation. Bonne pratique : audit externe annuel par prestataire différent de l'intégrateur, alternance des auditeurs tous les 2-3 ans.

17. Écosystème des acteurs cyber français 2026

L'écosystème cyber français en 2026 comporte plusieurs catégories d'acteurs complémentaires à mobiliser selon les besoins liés au authentification ntlm. (1) Cabinets de conseil cyber généralistes : Big 4 (Deloitte, EY, KPMG, PwC), Capgemini, Sopra Steria, Atos Eviden, Wavestone, Mazars, Beijaflore. Forces : couverture globale, références grands comptes, méthodologies normalisées. Limites : prix élevés, parfois trop pyramidal. (2) Cabinets cyber spécialisés : Synacktiv, Wallix, Stormshield Audit, Almond, Devoteam Cyber Trust, Wavestone Cybersecurity, Algosecure, Itrust, HarfangLab Services, et acteurs régionaux. Forces : expertise technique pointue, agilité, prix compétitifs. Limites : ressources limitées sur très gros projets. (3) Cabinets d'expertise pure-players souvent < 30 consultants, spécialisés (AD, cloud, OT, IA security) — typiquement ce que nous représentons. Forces : profondeur d'expertise, contact direct expert, flexibilité. Limites : capacité limitée projet très grande taille. (4) MSSP et MDR managés : Orange Cyberdefense, Thales Cyber Solutions, Atos Big Fish, Sopra Steria CyberSecurity Services. Forces : opérations 24/7, SLA, mutualisation. (5) Solutions software éditeurs : Wallix (PAM), Stormshield (UTM), Tehtris (XDR), HarfangLab (EDR), Datadog (observability), Snyk (DevSecOps). (6) Acteurs publics : ANSSI (autorité nationale), CERT-FR, Cybermalveillance.gouv.fr, France 2030 / Plan France Relance cyber, BPI France Diag Cyber, régions (BoosterCyber Île-de-France). (7) Communautés et écosystème : Clusif, Hexatrust, FIC (Forum International de la Cybersécurité, devenu InCyber Forum), Le Hack, BSides Paris, OSSIR, Cesin. Construire un écosystème de prestataires complémentaires plutôt que dépendre d'un acteur unique réduit le risque et améliore la couverture expertise.

FAQ

NTLM est-il vraiment toujours actif en 2026 ?

Oui — sur ~95 % des Active Directory français selon nos audits 2024-2026. La majorité des SI n'a jamais réalisé l'audit NTLM nécessaire (Event ID 8001-8004), n'a pas planifié la migration, et trouve NTLM 'pratique' pour applications legacy. Microsoft a annoncé dépréciation officielle juillet 2024 mais le calendrier de désactivation s'étale jusqu'en 2028-2030. La pression réglementaire NIS2 article 21.2.h (MFA et chiffrement) accélère les projets de migration.

Faut-il désactiver NTLMv2 en 2026 ?

Non encore — NTLMv2 reste actif et utilisé en attendant migration complète Kerberos. NTLMv2 est résistant aux rainbow tables classiques (vs NTLMv1) et reste acceptable pour applications legacy si SMB signing activé et EPA configuré. Plan recommandé 2026-2028 : (1) désactiver immédiatement NTLMv1 ; (2) activer audit NTLMv2 ; (3) migrer applications vers Kerberos progressivement ; (4) déployer IAKerb/Local KDC quand GA ; (5) désactiver NTLMv2 par étapes 2027-2028.

CVE-2026-32202 affecte-t-elle toutes les versions Windows ?

Oui — affecte Windows 10, Windows 11 toutes versions, Windows Server 2016/2019/2022/2025. Microsoft a publié patches initial mai 2026 (KB5039212) mais re-patch nécessaire juillet 2026 (KB5040872) car contournement découvert. Recommandation urgente : appliquer KB de juillet 2026 minimum, configurer SMB outbound vers Internet bloqué (réduit surface), activer Defender Attack Surface Reduction rules pour bloquer macros et téléchargements suspects.

IAKerb est-il production-ready en 2026 ?

Partiellement — preview Windows 11 22H2+ et Server 2025, GA prévue Windows 12 / Server vNext 2026-2027. Pour environnements stables production grande échelle, attendre GA. Pour environnements early adopter ou tests, IAKerb fonctionne déjà dans 80 % des cas. Le 20 % résiduel concerne applications legacy non documentées qui nécessitent encore NTLM jusqu'à migration complète. Tester en environnement dev avant production.

Combien coûte un projet de migration NTLM → Kerberos ?

Pour ETI 1 000-5 000 postes : 15 000-45 000 € HT sur 9-15 mois (audit usage NTLM, plan de migration, accompagnement applications, déploiement progressif, validation). Pour grands comptes 10 000+ postes : 50 000-200 000 € HT sur 12-24 mois. ROI : (a) réduction surface attaque AD massive ; (b) conformité NIS2/DORA accélérée ; (c) éligibilité passwordless FIDO2 facilitée ; (d) baisse coût incident futur potentiel.

Pour aller plus loin

Besoin d'un accompagnement sur votre migration NTLM → Kerberos ?

Audit usage NTLM, plan de migration phasé, accompagnement applications legacy, mise en oeuvre Kerberos. Diagnostic offert.

Notre méthodologie →