Du crépuscule de NTLM à l’assurance ancrée dans le matériel: la trajectoire de la sécurité Windows au-delà de janvier 2026
Alors que janvier 2026 a apporté un renforcement de Windows 11 en dehors du rythme normal des Patch Tuesday, la direction suivie est devenue indubitable: l’identité est en train de se débarrasser des protocoles hérités, le noyau ferme ses portes au code non fiable, et la confiance dans le démarrage passe de promesses logicielles à une preuve ancrée dans le matériel. L’impact immédiat se manifeste par des paramètres par défaut plus stricts pour l’authentification, l’intégrité des pilotes et la sécurité réseau; sur le long terme, cela aboutit à une conformité fondée sur l’attestation et une cryptographie moderne comme bases indiscutables. Cet article retrace cette trajectoire depuis l’application à court terme des restrictions NTLM et l’isolement des identifiants jusqu’à un avenir où Secure Boot et l’attestation TPM influencent les décisions d’accès en temps réel à travers des environnements hybrides. Les lecteurs repartiront avec une compréhension claire des étapes à venir, des choix opérationnels et des questions de recherche qui nécessitent encore des réponses alors que la sécurité Windows évolue au-delà de janvier 2026.
Avancées en recherche
La prochaine phase de l’identité: dépréciation de NTLM, renforcement de Kerberos, émergence de l’authentification moderne
Windows réduit progressivement les occasions pour NTLM d’apparaître dans le chemin d’authentification et se concentre sur une dépréciation éventuelle. Concrètement, cela signifie que les environnements verront une expansion continue des contrôles d’audit-à-application qui bloquent le recours à NTLM à travers des protocoles tels que SMB, HTTP et RPC où Kerberos ou l’authentification moderne peuvent être négociés. Le point positif est un coup direct sur les attaques par relais et rétrogradation qui exploitent des poignées de main plus faibles; l’inconvénient est une friction prévisible avec des appareils, appareils et outils legacy qui n’ont jamais dépassé NTLM. Une validation plus stricte de Kerberos — incluant une gestion plus rigoureuse des PAC et un lien de canal — réduit encore la surface de falsification et expose les mauvaises configurations dans les noms des principaux de service et la délégation restreinte. Ensemble, ces changements transforment l’identité d’une posture “meilleur effort” en une position explicite “pas de legacy par défaut” dans les domaines hybrides.
LSASS reste central dans l’histoire de l’identité. Une protection élargie pour la Local Security Authority — communément décrite comme appliquant la protection LSA (RunAsPPL) — limite l’injection de code non fiable et le raclage de la mémoire, augmentant le coût du vol de données d’identification et de la reproduction de jetons. Là où les modes d’audit prévalaient auparavant, les entreprises devraient s’attendre à ce que davantage d’appareils passent à des protections appliquées à mesure que les blocages de compatibilité sont résolus. Cela améliorera la résistance aux techniques courantes de mouvement latéral post-compromission, même si certains outils de diagnostic et fournisseurs d’identifiants personnalisés nécessitent des mises à jour pour coexister avec un LSASS protégé.
Isolement des identifiants par défaut: empreinte croissante de Credential Guard
Credential Guard s’est progressivement répandu des SKUs premium et des déploiements ciblés vers des bases plus larges. En isolant les secrets au sein de la sécurité basée sur la virtualisation (VBS), il réduit le rayon de propagation d’une brèche utilisateur et limite la viabilité du pass-the-hash. À mesure que les paramètres par défaut se resserrent, les intervenants en cas d’incident et les fournisseurs d’outils devront ajuster les méthodes de collecte et les hypothèses d’analyse mémoire, car le vidage direct de LSASS et d’autres techniques héritées deviennent moins fiables sur les hôtes protégés. Les organisations devraient s’attendre à ce que les configurations d’audit passent en modes appliqués à mesure que les prérequis pour pilotes et virtualisation mûrissent. Le prérequis opérationnel le plus immédiat reste de s’assurer que des pilotes compatibles VBS sont présents, notamment pour les agents de sécurité des terminaux, les clients VPN et les charges de travail de virtualisation qui dépendent de crochets du noyau.
Au-delà de BYOVD: listes de blocage de pilotes, signatures plus solides et chemin vers WDAC/HVCI
La stratégie Bring-Your-Own-Vulnerable-Driver continue d’être un pivot au niveau du noyau. La pile de contre-mesures de Microsoft — HVCI (intégrité de la mémoire), listes de blocage de pilotes vulnérables actualisées, et signature de code en mode noyau plus stricte — réduit cette avenue en empêchant le chargement de pilotes non signés ou connus pour être problématiques. La trajectoire au-delà de janvier 2026 annonce des rafraîchissements de liste de blocage plus fréquents et une poussée constante pour des pilotes compatibles WHQL et favorables à HVCI à travers l’écosystème. Windows Defender Application Control (WDAC) s’élève au-dessus de cela comme moteur de politique pour définir ce qui est autorisé à s’exécuter, permettant aux organisations de restreindre l’exécution de code non fiable sans avoir besoin de pourchasser chaque famille de menaces.
Pour les entreprises, le modèle d’adoption est familier: démarrer en mode audit, récolter les événements, et converger vers l’application à mesure que les listes d’autorisation se stabilisent. La friction principale demeure dans les catégories à haute sensibilité — EDR/AV, filtres VPN/réseau, anti-triche pour jeux — où les pilotes legacy ou intensifs en noyau sont à la traîne par rapport aux exigences HVCI et WDAC. Le dividende protecteur est significatif: moins de voies EoP viables dans le noyau et un chemin de persistance plus difficile.
Modernisation de la confiance au démarrage: cycles de vie de la politique Secure Boot et rafraîchissements DBX
Secure Boot a toujours promis l’assurance de la chaîne de démarrage, mais le rythme post-2026 met l’accent sur l’hygiène continue des politiques plutôt qu’une activation ponctuelle. Attendez-vous à des mises à jour continues des bases de données d’autorisation/interdiction (DB/DBX) pour invalider les chargeurs de démarrage vulnérables et atténuer la persistance des boot-kits. Cela renforce la nécessité d’un firmware UEFI à jour et d’une gestion prudente des gestionnaires de démarrage tiers ou des composants de chiffrement complet du disque qui reposent sur des ancres de confiance spécifiques. Le résultat est une chaîne de démarrage plus résiliente avec moins de place pour la manipulation avant le système d’exploitation, bien qu’une attention opérationnelle soit requise pour les scénarios de double démarrage ou de chargeurs de démarrage spécialisés.
Horizon de durcissement du réseau et de la cryptographie: la sécurité TLS et SMB devient incontournable
Windows 11 a déjà tracé une voie pour désactiver TLS 1.0 et 1.1 par défaut et tailler les suites de chiffrement faibles. À mesure que cela devient la réalité par défaut dans davantage de classes de périphériques, les points de terminaison et middlewares legacy TLS nécessiteront une remédiation pour maintenir la connectivité. Du côté des services de fichiers, Windows continue de rehausser la barre avec la signature SMB et des contrôles additionnels qui bloquent l’utilisation de NTLM pour les sessions SMB par politique. L’effet combiné réduit le risque de rétrogradation et de relais, comble les lacunes dans les vérifications d’intégrité et aligne la posture cryptographique sur les attentes contemporaines. Les impacts sur le débit dus à la signature SMB persistent sur les systèmes sans support de déchargement, donc la validation sur les liens sensibles à la performance reste prudente.
Feuille de route et directions futures
L’attestation comme plan de contrôle
Le changement le plus conséquent à long terme pourrait être l’élévation de l’attestation de santé des appareils d’un signal d’arrière-plan à un contrôle de première ligne. Avec les mesures du Trusted Platform Module (TPM) et l’attestation de démarrage établissant ce qui a été lancé et comment, les systèmes d’accès conditionnel peuvent prendre des décisions de politique qui vont bien au-delà de “le système d’exploitation est-il à jour?”. Dans ce modèle, un appareil démontre sa conformité avec une posture au démarrage et au runtime — Secure Boot activé, DBX à jour, intégrité mémoire appliquée — avant de recevoir un accès sensible. À mesure que davantage d’organisations intègrent ces signaux dans les passerelles Zero Trust, des états de démarrage faibles ou non vérifiables se traduisent directement en refus d’accès plutôt qu’en bruit d’audit. La directive à court terme est simple: vérifier les profils PCR et les rapports d’attestation après chaque changement de politique, et traiter la dérive d’attestation comme un signal d’incident de première classe.
Réalignement des ISV et OEM: incitations à la compatibilité et maturité ARM64
Les changements de posture de sécurité ne sont efficaces que lorsque l’écosystème suit. Des exigences plus strictes en matière d’intégrité et de signature de code créent de fortes incitations pour les ISV à fournir des pilotes conformes WHQL et compatibles HVCI, et à documenter les paramètres par défaut de Windows 11 comme la signature SMB ou le blocage de NTLM. Les OEM jouent un rôle parallèle: un firmware UEFI à jour, des variables Secure Boot correctes, et des implémentations TPM robustes sont désormais des prérequis pour de nombreux scénarios d’accès d’entreprise. Du côté de l’architecture, ARM64 n’est plus un cas particulier; les attentes de support mainstream incluent des packages de mise à jour natifs ARM64 et des pilotes fournisseurs pour les terminaux de classe Snapdragon. Les entreprises devraient valider systématiquement les fonctionnalités EDR, VPN et d’accélération matérielle sur les cohortes ARM aux côtés du x64, plutôt que de traiter ARM comme une simple expérience pilote.
Opérations: mises à jour accélérées, anneaux, et télémetrie alimentant la confiance
Les mises à jour de sécurité d’urgence renforcent une bonne pratique qui est là pour rester: déployer par anneaux, accélérer seulement lorsque le risque d’exploitation le justifie, et s’appuyer sur la télémetrie pour décider d’un go/no‑go. Les politiques de Windows Update for Business, les capacités d’accélération dans la gestion des terminaux et les tableaux de bord de reporting offrent aux organisations une manière contrôlée de déployer rapidement les correctifs critiques tout en surveillant les régressions telles que les échecs d’authentification, les BSOD, ou les baisses de débit sur les liens SMB. Le Known Issue Rollback (KIR) continuera à être la méthode de mitigation privilégiée pour les régressions non sécuritaires, évitant les désinstallations complètes. Cette structure opérationnelle — anneaux, garde-fous et régressions — soutiendra les deux prochaines années d’évolution à mesure que les configurations par défaut se durcissent.
Impact et Applications
Ce que cela signifie pour les défenseurs
- Le mouvement latéral devient plus difficile lorsque la protection LSASS et Credential Guard sont largement appliqués. Les techniques de vol de jetons et de pass-the-hash ont moins de cibles viables, et les scénarios post-compromission doivent se tourner vers des itinéraires plus bruyants ou plus complexes. Des métriques spécifiques sur les réductions réalisées ne sont pas disponibles, mais la direction qualitative est claire: coût plus élevé pour les attaquants et options de persistance réduites.
- La persistance au niveau du noyau diminue à mesure que HVCI et les listes de blocage mûrissent. Les tactiques BYOVD rencontrent plus d’impasses, et les attaques qui dépendent du chargement de pilotes non signés ou signés de manière héritée échouent plus souvent.
- Les attaques d’identifiants transmises par le réseau perdent de l’oxygène à mesure que les chemins NTLM se ferment et que la signature SMB devient la norme. Les fenêtres de relais se rétrécissent, et les rétrogradations cryptographiques sont plus difficiles à induire.
Ce que cela signifie pour les responsables informatiques et applicatifs
- Attendez-vous à des ruptures d’authentification où les systèmes hérités insistent sur NTLM. Le chemin à suivre consiste à remédier ou isoler: mettre à niveau, remplacer ou ségréger ces systèmes, et utiliser une liste blanche explicite uniquement comme exception à durée limitée.
- Planifiez des cycles de rafraîchissement des pilotes. Coordonnez-vous avec les fournisseurs EDR/AV, VPN et autres sensibles au noyau pour assurer la compatibilité HVCI et WDAC avant d’activer l’application à l’échelle de la flotte.
- Préparez-vous pour que les vérifications de confiance au démarrage influencent l’accès. Conservez un firmware UEFI à jour, validez les composants de démarrage tiers et confirmez les rapports d’attestation après les mises à jour des politiques OS.
- Testez la compatibilité TLS 1.2/1.3 à travers les applications métier et les middlewares. Là où des suites de chiffrement faibles sont implicitement supposées, construisez des calendriers de remédiation dès maintenant.
Posture avant/après: vers quoi les organisations se dirigent
| Domain | Hier (risque) | Demain (posture) | Pourquoi c’est important | Compromis opérationnels |
|---|---|---|---|---|
| Identité (NTLM/Kerberos, LSASS) | Persistante régression NTLM et validation plus faible; LSASS souvent non protégé | Blocage NTLM croissant; contrôles Kerberos plus stricts; protection LSASS appliquée | Réduit les chemins de rétrogradation/relais et de vol d’identifiants | Cassure d’authentification héritée; mises à jour des fournisseurs et politiques |
| Isolement des identifiants | Secrets accessibles au raclage par l’utilisateur et aux injecteurs | Credential Guard isole les secrets via VBS | Réduit la viabilité du pass-the-hash | Prérequis pour pilotes et virtualisation |
| Intégrité du noyau | Les pilotes vulnérables/non signés peuvent se charger | HVCI actif; listes de blocage rafraîchies; signature plus stricte | Réduit la persistance et les EoP du noyau | Mises à jour des pilotes fournisseurs, ajustement des listes blanches |
| Confiance au démarrage | DBX obsolète et chaînes de démarrage permissives | Cadence de rafraîchissement Secure Boot DBX | Neutralise les bootkits | Coordination firmware/chargeur de démarrage |
| Réseau/cryptographie | Sessions TLS héritées et SMB non signées | TLS 1.0/1.1 désactivé par défaut; Signature SMB et blocages NTLM | Empêche rétrogradations et relais | Impact potentiel sur le débit; rémédiaction des points de terminaison hérités |
Recherche et Questions Ouvertes
- Mesurer la viabilité résiduelle du mouvement latéral. Avec la protection LSASS et Credential Guard en progression, quelle fraction du mouvement latéral réel s’appuie encore sur des identifiants volés par rapport à des techniques alternatives? Des métriques spécifiques sont indisponibles, et leur collecte nécessite des études contrôlées contre des configurations diversifiées.
- Minimisation de la surface d’attaque du noyau. À mesure que HVCI et WDAC s’étendent, qu’est-ce qui reste comme EoP au niveau du noyau pour les attaquants comptant sur BYOVD? Suivi de la couverture des listes de blocage et de la conformité des pilotes fournisseurs au fil du temps est un effort ouvert.
- Des paramètres par défaut sécurisés à grande échelle. À quelle vitesse de grands environnements peuvent-ils passer de l’audit à l’application sans un niveau inacceptable de rupture? La télémetrie — succès d’installation, taux de crash, erreurs d’authentification — existe, mais des seuils standardisés pour la promotion restent à établir.
- Fidélité de l’attestation au démarrage. Quand l’accès conditionnel utilise les signaux ancrés dans le TPM, comment des variations bénignes dans les profils PCR causent-elles des refus erronés, et quels sont les meilleurs schémas pour la rémédiation sans affaiblir la politique? Les taux d’erreur quantifiés sont indisponibles et méritent une étude future.
Conclusion
La sécurité Windows après janvier 2026 est définie par la soustraction: moins de protocoles hérités, moins de drivers de provenance douteuse chargés, moins de composants de démarrage de confiance, et moins de chemins réseau non authentifiés ou non signés. Ce qui reste est plus fort par défaut et plus étroitement lié à une preuve ancrée dans le matériel de l’état. Les gagnants seront les organisations qui associent l’adoption rapide de ces paramètres par défaut à des opérations disciplinées — anneaux pilotes, portes basées sur la télémetrie et exceptions limitées dans le temps — et qui considèrent l’attestation des appareils comme un contrôle de première classe aux côtés des correctifs. L’objectif final est clair: identité sécurisée par une authentification moderne, intégrité de la plateforme garantie par l’intégrité du code et le Secure Boot, confiance réseau portée par une cryptographie contemporaine, et décisions d’accès éclairées par une santé des appareils vérifiable. 🔐
Points clés à retenir:
- Le rôle de NTLM continue de diminuer; le renforcement de Kerberos et l’authentification moderne deviennent la norme dans les domaines hybrides.
- Credential Guard, protection de LSASS, HVCI et WDAC transforment la permission par défaut en autorisation explicite uniquement à travers la mémoire et l’exécution du code.
- Les rafraîchissements Secure Boot DBX et l’attestation de santé TPM solidifient la confiance au démarrage comme un signal de conformité, pas seulement un réglage.
- La fin de vie de TLS 1.0/1.1 et la signature SMB rendent l’intégrité cryptographique incontournable.
- Le succès dépend du déploiement en anneaux, de l’alignement des fournisseurs sur la signature des pilotes et d’une télémetrie continue.
Prochaines étapes:
- Inventoriez les dépendances NTLM, les points de terminaison TLS hérités et les pilotes sensibles au noyau; construisez des calendriers de remédiation.
- Pilotez Credential Guard et HVCI/WDAC en audit, puis passez à l’application à mesure que les listes d’autorisation mûrissent.
- Mettez à jour le firmware UEFI et validez les rapports de Secure Boot et d’attestation à travers les cohortes d’appareils.
- Intégrez les états d’attestation et de fonctionnalité de sécurité dans les politiques d’accès conditionnel.
- Maintenez des anneaux de déploiement, accélérez seulement si nécessaire, et utilisez Known Issue Rollback pour gérer les régressions.
Windows ne se contente pas de resserrer les vis; il recentre la confiance sur des preuves ancrées dans le matériel et des politiques explicites. Ce changement définira la prochaine phase de la sécurité d’entreprise — et la mémoire musculaire opérationnelle pour la faire perdurer.