La politique de Microsoft met en péril les anciens serveurs Ring 0

Imaginez que vous construisiez une tour de Jenga et que vous deviez soudain retirer tous les blocs les plus bas. Les centres de données du monde entier seront confrontés à ce dilemme en raison d'une nouvelle politique de Microsoft. 

À partir de la mise à jour Windows d'avril 2026, Microsoft supprime la confiance par défaut pour tous les pilotes de noyau signés dans le cadre de son programme racine à signature croisée déprécié. Cette mesure concernera Windows 11 24H2, 25H2, 26H1 et Windows Server 2025. Toutes les versions ultérieures de Windows suivront la même politique. 

Si vous utilisez des serveurs dont les pilotes n'ont pas été soumis au programme de compatibilité matérielle de Microsoft (WHCP), vous avez un problème. Pour compliquer les choses, il s'agit généralement de serveurs plus anciens qui est à la base de toutes les opérations des centres de données. 

Ce que Microsoft a réellement changé, et pourquoi c'est important au niveau du noyau

Ce changement a été amorcé en 2021, lorsque Microsoft a supprimé le programme de signature croisée. Lorsqu'il est actif, il permet aux fournisseurs de matériel tiers d'authentifier leurs pilotes sans passer par le processus de certification de Microsoft.

Voici le mécanisme : les fournisseurs ont signé leurs pilotes à l'aide de certificats délivrés par des autorités de certification tierces, que Microsoft a ensuite contresignés. Ce sont ces contresignatures qui ont permis d'établir la confiance dans le noyau Windows.

Les certificats ont expiré lorsque la fonction a été abandonnée, mais Windows a continué à faire confiance aux pilotes. Cette philosophie de rétrocompatibilité a permis à Microsoft de ne pas couper l'herbe sous le pied de millions de systèmes déployés.

Au moins jusqu'à la fin de la période de grâce. C'est-à-dire en avril 2026. .

Les pilotes du noyau ne sont pas des logiciels d'application ordinaires. Ils s'exécutent au niveau Ring 0 : le niveau d'exécution le plus privilégié du système d'exploitation. 

Un pilote de noyau a un contrôle quasi total sur la mémoire, les E/S et le matériel. Lorsqu'un problème survient au niveau du noyau, il ne se contente pas de générer un journal d'erreurs. Il fait planter la machine, corrompt les données ou compromet silencieusement tous les contrôles de sécurité situés au-dessus de lui dans la pile.

Le vecteur d'attaque est appelé Bring Your Own Vulnerable Driver (BYOVD). Les mécanismes sont simples : les attaquants chargent un pilote légitimement signé mais vulnérable, souvent à partir d'anciens logiciels de surveillance du matériel, d'utilitaires de gestion de disque ou de périphériques de jeu. Ils l'exploitent ensuite pour désactiver les outils de détection des points d'extrémité, élever les privilèges et se déplacer latéralement sans que personne ne s'en aperçoive. Comme le pilote est signé, la plupart des listes d'autorisation et des moteurs antivirus le considèrent comme un code fiable.

Une étude de Nextgen Software estime qu'environ 25% des attaques de ransomware en 2024 ont incorporé des techniques BYOVD visant spécifiquement à désactiver les systèmes EDR avant le cryptage. Le projet LOLDrivers a répertorié plus de 900 pilotes 64 bits signés déjà connus pour être exploitables. Votre ancien pilote de contrôleur de stockage figure peut-être sur cette liste. Le pilote de votre micrologiciel BMC n'a certainement pas fait l'objet d'un audit à cet égard.

La décision de Microsoft n'élimine pas complètement le BYOVD. Mais elle ferme la surface d'attaque la plus évidente : toute la catégorie des pilotes à signature croisée qui n'ont jamais été soumis aux exigences de validation du WHCP. 

Le problème du matériel hérité dont personne ne veut parler

Les serveurs les plus susceptibles d'avoir des pilotes non-WHCP ne sont pas ceux que vous avez rafraîchis en 2024. Ce sont ceux que vous avez oubliés. Il se peut que 

• Intégration du contrôle industriel
• Contrôleurs de stockage sur du matériel vieillissant utilisant des microprogrammes spécialisés 
• Modules de sécurité matériels avec pilotes de noyau propriétaires. 
• Pilotes d'interface réseau pour les cartes 10GbE dont le micrologiciel n'a pas été mis à jour depuis 2019 
• Agents de gestion de l'hyperviseur qui ont été installés une fois et n'ont plus jamais été touchés.

Aucun de ces éléments n'apparaît dans un inventaire standard des actifs en tant que ‘risque de sécurité’. Ils apparaissent en tant qu‘’infrastructure opérationnelle". Du moins jusqu'à la date limite fixée par Microsoft.

Microsoft déploie d'abord cette politique en mode évaluation. Le noyau Windows surveille et vérifie les chargements de pilotes pendant au moins 100 heures, sur un minimum de trois redémarrages du système, avant que l'application ne soit activée. Si tous les pilotes chargés pendant cette période satisfont à la nouvelle politique de confiance, l'application est lancée. 

Si un pilote à signature croisée échoue à la vérification, le système reste en mode évaluation et réinitialise le compteur. Il s'agit d'une soupape de sécurité délibérée, mais cela signifie également que les organisations qui utilisent des pilotes hérités problématiques pourraient rester dans un état perpétuel semi-forcé. Ce n'est pas la même chose que d'être protégé.

Les catégories de matériel les plus exposées sont les suivantes 

• Serveurs utilisant des contrôleurs de stockage spécialisés 
• Systèmes avec BMC propriétaire ou pilotes de gestion hors bande 
• Tout équipement provenant de vendeurs qui ont cessé leurs activités ou abandonné des lignes de produits avant que le WHCP ne devienne la voie obligatoire.

Si le cycle de rafraîchissement de votre infrastructure dépasse cinq ans, ce qui est très probablement le cas, il est presque certain que vous avez un système affecté. Vous devez déterminer le nombre de systèmes concernés. Soit vous le découvrez maintenant, soit vous l'apprendrez à vos dépens à l'occasion d'une panne prolongée.

Ce que le WHCP certifie réellement et ce qu'il ne certifie pas

Pour qu'un pilote soit signé dans le cadre du programme de compatibilité matérielle de Windows, un fournisseur doit le soumettre via le portail Hardware Dev Center de Microsoft. Il doit ensuite passer des tests de compatibilité et de fiabilité et répondre aux exigences actuelles en matière d'intégrité du code. Microsoft contrôle les clés de signature. Le fournisseur ne manipule jamais directement la clé privée.

L'un des problèmes persistants des pilotes à signature croisée était la gestion des clés : les fournisseurs détenaient leurs propres clés privées, et les clés volées permettaient d'utiliser des certificats légitimes pour signer des pilotes malveillants. Le kit d'amorçage BlackLotus de 2023 a utilisé un ancien certificat à signature croisée pour établir une persistance au niveau du noyau sur des systèmes d'entreprise. L'équipe de sécurité de Microsoft a documenté 47 attaques distinctes utilisant des certificats à signature croisée entre 2020 et 2025, chacune nécessitant des correctifs d'urgence et des révocations de certificats après coup.

Le WHCP élimine cette surface d'attaque en centralisant la garde des clés. Il oblige également les pilotes à passer par un pipeline de validation qui teste les exigences actuelles de Windows au lieu de celles qui existaient lorsque le pilote a été écrit pour la première fois.

Voici ce que le WHCP ne certifie pas : le matériel sous-jacent. Un pilote signé WHCP pour un serveur vieux de cinq ans signifie que le pilote a satisfait aux exigences de certification actuelles de Microsoft. Cela ne signifie pas que le serveur est à jour, sécurisé ou adapté à votre infrastructure. 

Le pilote n'est que la couche logicielle. Le matériel sous-jacent a son propre cycle de vie, ses propres vulnérabilités micrologicielles et son propre calendrier de fin d'assistance.

Certaines organisations traitent le WHCP conformité comme une case à cocher qui permet de maintenir indéfiniment en service le matériel existant. En réalité, il ne s'agit que d'une couche de la pile de sécurité. Le matériel fonctionnant sous ce pilote a toujours besoin de correctifs, accumule les CVE connus et exécute des microprogrammes qui n'ont pas été mis à jour depuis le départ de l'équipe d'ingénieurs du fournisseur.

La décision de rafraîchissement : A quoi ressemblent réellement les mathématiques

Le matériel ancien ne comporte pas seulement un risque pour la sécurité. Il entraîne un coût que la plupart des équipes financières ne comptabilisent pas correctement.

Les contrats d'assistance étendus des fournisseurs pour les serveurs ayant dépassé leur cycle de vie standard s'élèvent généralement à 15-20% du coût du matériel d'origine par an. Ce chiffre s'ajoute aux frais d'alimentation et de refroidissement que le matériel plus ancien et moins efficace engendre par rapport à l'équipement de la génération actuelle. Un ordinateur Dell PowerEdge R730 Le fait de tirer 400 W en continu par rapport à un R760 de la génération actuelle exécutant la même charge de travail à 280 W représente un véritable poste sur la facture d'électricité. Ce coût est répercuté sur tous les serveurs de la même cohorte.

Et puis il y a le coût de l'incident. Une seule panne non planifiée causée par une incompatibilité de pilote coûte plus cher en heures d'ingénierie, en interruption d'activité et en achat accéléré de matériel que ce que la plupart des entreprises prévoient dans leur budget pour une mise à jour planifiée. La différence est de savoir qui contrôle le calendrier.

Les serveurs les plus exposés au changement de confiance du noyau de Microsoft en avril 2026 sont également les plus susceptibles d'avoir dépassé leur point de rafraîchissement optimal dans tous les autres domaines. 

Le matériel qui n'a pas été renouvelé depuis cinq ans ou plus a probablement été acheté avant que le WHCP ne devienne la norme imposée, il utilise des pilotes qui n'ont pas été mis à jour depuis que la fenêtre d'assistance du fournisseur s'est refermée, et il présente une dette technique croissante sur de multiples fronts.

Voici la question clé : est-il possible de continuer à faire fonctionner ce matériel, et que pouvez-vous faire maintenant qu'avril 2026 est arrivé ?

Que faire de la mise à jour d'avril de Microsoft ?

Le mode d'évaluation de Microsoft vous offre une fenêtre. Veillez à l'utiliser.

La première étape est l'inventaire des pilotes. Oubliez les logiciels et les réseaux : vous devez évaluer les pilotes de votre noyau en production. Chaque serveur de votre parc doit être contrôlé pour détecter les pilotes qui renvoient à des certificats à signature croisée. 

Les outils intégrés de Microsoft peuvent remonter à la surface : les journaux d'événements du noyau Windows signaleront les pilotes concernés en mode d'évaluation. Vous pouvez également exécuter sigcheck de Sysinternals sur votre répertoire de pilotes pour identifier les informations de la chaîne de certificats avant que la mise à jour ne touche vos systèmes.

Comparez votre liste de pilotes à deux sources : le projet LOLDrivers (loldrivers.io), qui gère une base de données communautaire de pilotes vulnérables connus, et la liste de blocage des pilotes vulnérables de Microsoft, qui est mise à jour par Windows Defender. Si un pilote de votre système figure sur l'une de ces listes, il s'agit d'une surface d'attaque active à l'heure actuelle. Il s'agit d'un problème distinct de la mise à jour d'avril.

Pour les conducteurs qui échouent au contrôle WHCP et qui n'ont pas de remplaçant certifié disponible, trois possibilités s'offrent à vous :

1. Mettre en œuvre des politiques de contrôle des applications pour les entreprises avec l'autorité UEFI Secure Boot afin d'autoriser le pilote spécifique en tant qu'exception explicite. 
2. Isoler le matériel affecté des segments du réseau où des mouvements latéraux pourraient avoir des conséquences.
3. Mise hors service du matériel et récupérer la valeur résiduelle de l'actif avant qu'il ne se déprécie davantage.

La voie d'exception n'est pas une solution permanente. Microsoft a été explicite : chaque future version de Windows appliquera le modèle de confiance WHCP-first. Les exceptions de la liste d'autorisation qui existent aujourd'hui sont un pont de compatibilité, et non une position à long terme. Les entreprises qui continuent à faire fonctionner le matériel existant en utilisant des exceptions manuelles gèrent un compte à rebours et ne résolvent pas le problème.

La voie du déclassement est la seule qui permette de supprimer définitivement l'exposition au risque. En fonction de l'âge et de la configuration du matériel, le déclassement offre une voie directe vers les recettes plutôt que vers les coûts.

Conclusion

La mise à jour April 2026 de Microsoft n'a pas créé un nouveau problème. Elle a fixé une date limite pour un problème qui existait déjà. Si votre infrastructure comporte des serveurs hérités dotés de pilotes non-WHCP, cette date limite est maintenant.

Ces serveurs ont dû être retirés de la production un jour ou l'autre, et cette échéance peut donc servir de leçon. Tout ce qui entre dans votre centre de données a besoin d'un calendrier de sortie. Le matériel de type "set it and forget it" appartient au passé.