Désactiver NTLM : ce que le plan de Microsoft signifie pour vos appareils mobiles

Lukas Schönbächler · Juin 2026 · 8 min de lecture

Voici pourquoi Microsoft procède ainsi, ce que font réellement les deux remplaçants, pourquoi le mobile est laissé de côté, et comment combler l’écart.

Pourquoi Microsoft supprime enfin NTLM

En mars 2025, Microsoft a corrigé CVE-2025-24054, une faille de divulgation de hash NTLM. Pour récupérer des identifiants, il suffisait qu’un utilisateur fasse un clic droit sur un fichier .library-ms malveillant, et Check Point a documenté des attaques actives contre des administrations en Pologne et en Roumanie en quelques jours. En avril 2026, Cymulate publiait un contournement (CVE-2025-50154) ; en juin 2026, un second (CVE-2025-59214). Corrigé deux fois, toujours exploitable, sans aucune interaction de l’utilisateur.

C’est cette série qui explique pourquoi Microsoft a cessé de colmater les failles NTLM une par une. En janvier 2026, l’entreprise a publié son plan visant à désactiver NTLM par défaut sous Windows, le protocole étant à terme entièrement retiré du système d’exploitation.

Comment se déroule la suppression

La transition se déroule en trois phases.

• Phase 1, maintenant : audit NTLM amélioré sous Windows Server 2025 et Windows 11 24H2. De nouveaux ID d’événement (4020 sur les clients, 4022 sur les serveurs, 4032 sur les contrôleurs de domaine) montrent enfin pourquoi NTLM a été choisi et quelle version a été négociée. C’est le préalable à tout le reste : on ne peut pas migrer ce qu’on ne voit pas.
• Phase 2, second semestre 2026 : IAKerb et LocalKDC atteignent la disponibilité générale. Par ailleurs, en octobre 2026, la valeur par défaut de BlockNTLMv1SSO passe d’Audit à Enforce (KB5066470) et bloque l’authentification unique via NTLMv1. NTLMv1, l’ancienne variante basée sur DES, est trivial à casser et disparaît en premier ; NTLMv2 suit la trajectoire plus large de la phase 3. Octobre 2026 est l’échéance ferme la plus proche.
• Phase 3, prochain Windows Server LTSC (prévu pour 2027) : NTLM réseau désactivé par défaut. Il reste réactivable via une stratégie de groupe, mais le repli automatique disparaît.

Figure 1 : calendrier en trois phases de la suppression de NTLM par Microsoft. Octobre 2026 est la première date qui exige d’agir dans la plupart des environnements.

Ce que font réellement IAKerb et LocalKDC

Kerberos a toujours eu une exigence structurelle : le client doit avoir une ligne de vue directe vers un Key Distribution Center (KDC) sur le port 88. Lorsqu’il n’en atteignait aucun, qu’il s’agisse d’une machine distante, d’un réseau segmenté ou d’un poste en groupe de travail, Windows basculait discrètement sur NTLM. IAKerb et LocalKDC suppriment les deux principales raisons d’être de ce repli.

IAKerb permet de relayer l’échange Kerberos lui-même. Lorsqu’un client Windows 11 24H2 ne peut pas joindre directement un contrôleur de domaine, il fait transiter son AS-REQ par un serveur compatible IAKerb qui, lui, le peut, de sorte que le client réalise une authentification Kerberos normale au lieu de retomber sur NTLM. C’est implémenté dans le fournisseur de support de sécurité Negotiate et Kerberos au sein de LSASS ; en on-premises, cela nécessite un Windows Server 2025 exécutant le rôle KDC Proxy sur le chemin (les appareils joints à Entra peuvent utiliser le proxy KDC Azure). Pour l’application, c’est du Kerberos de bout en bout.

LocalKDC place une petite autorité Kerberos sur l’appareil Windows lui-même, de sorte que même les comptes locaux, non rattachés au domaine, s’authentifient via Kerberos contre la base SAM locale. Cela supprime l’hypothèse de longue date selon laquelle l’authentification locale implique forcément NTLM.

Ce sont de réelles améliorations. Ce sont aussi des fonctionnalités exclusivement Windows.

Pourquoi rien de tout cela n’atteint le mobile

IAKerb et LocalKDC sont des fonctionnalités de la pile d’authentification Windows. Elles modifient la façon dont Windows négocie l’authentification au sein de LSASS et du modèle SSP. Android et iOS n’ont ni l’un ni l’autre. Ils n’ont jamais participé à cette négociation.

Sur mobile, un navigateur ou une application s’authentifie au niveau applicatif, directement face au point de terminaison, avec le mécanisme proposé par le serveur. Pour les ressources on-premises adossées à Active Directory, ce mécanisme était très souvent NTLM, justement parce que les plateformes mobiles n’ont pas de machinerie Kerberos intégrée comme en possède un PC Windows joint au domaine. En pratique, NTLM était la voie d’intégration qui permettait au mobile de fonctionner avec l’on-premises.

Donc, lorsque NTLM est bloqué côté serveur, les deux plateformes divergent complètement. Un client Windows 11 bascule de façon transparente vers IAKerb ou LocalKDC. Un appareil Android ou iOS n’a rien vers quoi basculer. Il échoue, tout simplement : les applications web internes renvoient 401, les partages SMB ne se montent plus, le SharePoint on-premises tombe dans une boucle d’authentification qui n’aboutit jamais.

Figure 2 : IAKerb couvre les clients Windows qui ne peuvent pas joindre directement un DC. Les appareils Android et iOS n’ont pas d’équivalent dans le système d’exploitation. Sans client Kerberos dédié sur l’appareil, soit ils échouent lorsque NTLM est bloqué, soit ils nécessitent une solution au niveau applicatif.

Ce qu’il faut retenir du côté Windows : Kerberos est la destination. Pour le mobile, rien dans le plan de Microsoft ne vous y mène. Cette capacité Kerberos, vous devez la fournir vous-même, et vous devriez avoir la stratégie correspondante en place avant que les échéances ne tombent.

Amener Kerberos sur Android et iOS

Sous Windows, LSASS obtient les tickets de façon transparente. Sur mobile, il n’existe pas de client Kerberos au niveau du système d’exploitation ; la capacité doit donc venir d’une application qui implémente le client Kerberos et PKINIT directement sur l’appareil.

PKINIT est la pré-authentification Kerberos basée sur certificat. Un certificat utilisateur, déployé via le profil SCEP ou PKCS de votre MDM, sert à obtenir un TGT Kerberos auprès du contrôleur de domaine ; le client sur l’appareil émet ensuite des tickets de service pour les navigateurs, les WebViews gérées et les applications métier. NTLM n’intervient à aucun moment dans cette chaîne. Sur les appareils Android et iOS gérés, Hypergate Authenticator est l’implémentation exacte de ce flux, et la même approche sous-tend nos guides sur un proxy Kerberos pour Android Enterprise et le SSO sur Android.

La conséquence est l’essentiel : un appareil qui s’authentifie ainsi utilise déjà Kerberos. Bloquer NTLM côté serveur n’a aucun effet sur lui, car il ne reste aucun repli à supprimer.

L’authentification par certificat est aussi le gain de sécurité

Faire passer le mobile à PKINIT ne sert pas seulement à maintenir le fonctionnement. L’authentification basée sur certificat est un progrès en matière de sécurité. Le certificat est lié à l’utilisateur et à l’appareil, et il n’y a ni secret partagé ni hash à relayer ou à rejouer, c’est-à-dire précisément la catégorie d’attaque qu’exploitent les CVE NTLM citées en début d’article.

Ce n’est pas une nouveauté. Les banques et autres environnements à haut niveau d’assurance utilisent l’authentification par certificat depuis des années. Ce qui change, c’est que la suppression de NTLM, combinée à la Strong Certificate Mapping Enforcement de Microsoft, en fait la norme bien au-delà de ces secteurs.

Un prérequis à respecter : le certificat PKINIT doit contenir le SID de l’utilisateur AD dans le Subject Alternative Name (tag:microsoft.com,2022-09-14:sid:<SID>). La Strong Certificate Mapping Enforcement, en mode strict depuis septembre 2025, rejette les certificats qui ne le font pas. Si vous mettez en place le Kerberos mobile maintenant, ce travail de mapping relève de la même configuration MDM. Nous avons détaillé la configuration SAN par MDM dans un article distinct.

Repérez vos dépendances NTLM mobiles avant de bloquer

Vous pouvez observer le trafic NTLM mobile côté serveur. L’événement 8003 (ou 4022 sous Windows Server 2025) sur vos serveurs applicatifs journalise les authentifications NTLM entrantes, y compris le compte et le client source :

Get-WinEvent -LogName "Microsoft-Windows-NTLM/Operational" |
    Where-Object { $_.Id -eq 8003 } |
    Select-Object TimeCreated,
        @{N='User';E={$_.Properties[0].Value}},
        @{N='Client';E={$_.Properties[2].Value}},
        @{N='Process';E={$_.Properties[3].Value}} |
    Sort-Object TimeCreated -Descending

Recoupez le champ Client avec l’inventaire de votre MDM. (Remarque VPN : derrière un VPN, le client peut apparaître comme le concentrateur ; corrélez donc par compte utilisateur.) Une fois un appareil migré, vous verrez l’événement 4768 (TGT Kerberos émis) là où apparaissait auparavant 4776 (validation NTLM). C’est ainsi que vous confirmez qu’il n’utilise plus NTLM.

Où cela vous laisse

Le plan de Microsoft couvre bien Windows. Le volet mobile vous revient, et le travail est simple une fois le trafic visible : auditer avec l’événement 8003, déployer un certificat lié au SID et PKINIT via votre MDM, confirmer avec l’événement 4768, puis restreindre NTLM. Rien de tout cela ne nécessite de nouvelle infrastructure ; la véritable contrainte est de commencer assez tôt pour tout valider avant l’échéance d’octobre 2026.

---