Introduction
Début 2026, des organisations diplomatiques déployées en Asie centrale ont vu leurs postes Windows compromis par un bootkit UEFI sophistiqué. Particularité troublante : toutes les machines concernées avaient reçu leurs mises à jour Windows. Les bulletins de sécurité avaient été appliqués, les tableaux de bord affichaient une conformité irréprochable.
L'incident a mis en lumière une confusion ancrée dans beaucoup d'équipes IT : corriger une vulnérabilité logicielle et activer la protection firmware qui s'y rattache sont deux actions distinctes, et les outils standard ne rendent visible que la première.
Le correctif appliqué, la protection absente
L'histoire commence en 2022, quand Microsoft publie un correctif pour CVE-2022-21894, une faille baptisée « Baton Drop » permettant de court-circuiter le mécanisme de démarrage sécurisé (Secure Boot). La mise à jour a été déployée via Windows Update sur des millions de machines.
Mais Secure Boot repose sur un mécanisme complémentaire : la base DBX (Forbidden Signature Database), stockée dans le firmware UEFI de chaque équipement. Cette liste noire contient les empreintes cryptographiques des composants de démarrage identifiés comme vulnérables. Pour neutraliser réellement la faille, le composant compromis doit être inscrit dans cette DBX, ce qui constitue une opération firmware distincte, non automatique sur un parc d'entreprise géré.
Microsoft proposait bien cette mise à jour DBX, mais sans jamais l'imposer. Elle nécessite un déploiement explicite via les outils de gestion de flotte : Intune, MECM, scripts GPO. Faute d'une communication claire de l'éditeur sur cette distinction, beaucoup d'équipes ont conclu que la CVE était close une fois le correctif Windows appliqué. Elle ne l'était pas, au niveau du firmware.
Ce que les outils IT standard ne voient pas
Cet angle mort tient à une limitation structurelle : les solutions de gestion de parc offrent une excellente visibilité sur l'état des mises à jour Windows, mais elles ne couvrent pas, par défaut, l'état du firmware de chaque machine, ni l'intégrité des bases DBX.
Deux couches de protection coexistent sur chaque poste :
- La couche OS : mises à jour Windows Update, auditables dans WSUS, Intune ou MECM ;
- La couche firmware/UEFI : certificats de démarrage, révocations DBX, clés OEM, rarement incluses dans les inventaires de conformité.
La question n'est pas théorique. En juin 2026, les certificats KEK utilisés par Microsoft depuis 2011 sont arrivés à expiration. En octobre de la même année, c'est le certificat signataire des composants de démarrage Windows qui a atteint sa date limite. Or, l'expiration d'un certificat n'équivaut pas à une révocation : les composants vulnérables qu'il signait restent exploitables tant qu'ils ne figurent pas explicitement dans la DBX. Les équipements qui n'ont pas migré vers les certificats 2023 ne pourront plus recevoir de nouvelles entrées DBX via Windows Update, gelant définitivement leur niveau de protection firmware.
Ce que les responsables IT doivent intégrer
Face à ce décalage, quelques ajustements de gouvernance s'imposent.
Étendre la définition de « parc à jour » : un inventaire de conformité complet doit inclure l'état firmware, version UEFI, statut des certificats KEK/DB/DBX, date de dernière mise à jour de la liste de révocation. Des outils spécialisés ou les diagnostics UEFI natifs permettent cet audit sur la plupart des équipements récents.
Distinguer correctif et révocation : corriger une CVE au niveau OS ne protège pas automatiquement le démarrage. Chaque bulletin Microsoft lié à Secure Boot doit être analysé pour déterminer si une action firmware complémentaire est requise, et documentée dans les processus de validation.
Intégrer les mises à jour firmware dans le patch management : les déploiements OEM doivent être traités avec le même niveau de priorité que les correctifs Windows, avec un séquençage précis, firmware d'abord, puis certificats, pour éviter tout risque de non-démarrage.
Le cas BlackX illustre une réalité que les équipes IT commencent à peine à mesurer : la surface de gouvernance d'un parc Windows s'étend désormais bien en dessous du système d'exploitation. Se fier à ses seuls indicateurs de patch management pour attester qu'un équipement est protégé, c'est gérer la moitié d'un parc.