Les certificats Secure Boot expirent en juin 2026 : ce que les équipes IT doivent faire

7 Min. de lecture

À partir de juin 2026, les certificats Microsoft Secure Boot de 2011 perdront leur validité. Les appareils Windows sans certificat 2023 installé ne pourront plus installer de nouvelles mises à jour Secure Boot et perdront la confiance dans les logiciels tiers signés récemment. Les équipes IT ont encore environ deux mois pour faire l’inventaire, tester et déployer. Qui commence en juin sera trop tard.

Ce qui expire concrètement en juin 2026

Secure Boot est un mécanisme UEFI qui vérifie au démarrage d’un ordinateur si le firmware chargé, le chargeur de démarrage et le système d’exploitation proviennent d’une source de confiance. La chaîne de confiance repose sur des signatures cryptographiques émises par des autorités de certification. Microsoft a établi en 2011 trois autorités de certification centrales : la Microsoft Corporation KEK CA 2011 pour la base de données des clés d’échange, la Microsoft Windows Production PCA 2011 pour les composants Windows signés et la Microsoft Corporation UEFI CA 2011 pour les logiciels tiers.

Ces trois certificats perdront leur validité à partir de juin 2026. Le remplacement n’est pas une panne soudaine, mais un processus échelonné qui s’étendra jusqu’en octobre 2026. Microsoft a déjà mis en place les successeurs en 2023 et les distribue progressivement via des mises à jour Windows sur les appareils existants. Les PC livrés depuis début 2024 contiennent les autorités de certification 2023 directement à l’usine – un avantage stratégique pour les entreprises avec un parc de matériel récent, mais un risque pour tous les autres.

Le contexte est motivé par des raisons techniques et réglementaires. Les certificats de 2011 datent d’une époque où SHA-1 était encore répandu et où l’architecture Secure Boot concernait nettement moins de fabricants qu’aujourd’hui. Avec le passage aux autorités de certification 2023, Microsoft adapte les procédures de cryptage aux normes actuelles et réduit simultanément la durée de vie des certificats à une valeur plus gérable pour les systèmes productifs.

Quels appareils sont concernés

La règle simple est la suivante : tout ce qui a été produit avant 2024 nécessite une mise à jour active. Dans la pratique, cela concerne la majorité de tous les appareils d’une entreprise typique, car la durée de vie moyenne d’un ordinateur portable se situe entre quatre et six ans et les ordinateurs de bureau restent souvent en service encore plus longtemps. Les serveurs sont également concernés, bien que les hôtes de virtualisation et les machines virtuelles soient traités différemment.

Les appareils Windows physiques sont fournis avec les certificats de 2023 via les canaux de mise à jour Windows habituels. Cependant, la livraison n’est pas automatique au sens où « chaque ordinateur l’obtient de manière garantie ». Microsoft contrôle la distribution de manière échelonnée. Certaines classes d’appareils attendent encore les approbations des OEM. Dell, HP, Lenovo et Fujitsu ont des calendriers différents pour les mises à jour de firmware qui ancrent les modifications de l’autorité de certification dans le matériel. Les équipes informatiques doivent vérifier l’état par modèle d’appareil et ne pas supposer que la mise à jour Windows résoudra seule le problème.

Les machines virtuelles constituent un cas particulier. Hyper-V, VMware et KVM prennent en charge le démarrage sécurisé, mais les mises à jour de certificats s’effectuent ici via le firmware virtualisé, et non via le système d’exploitation invité. Pour les environnements vSphere, VMware a publié des instructions pour la migration, Microsoft fournit des mises à jour Hyper-V via les correctifs de l’hôte. Pour les environnements KVM sur base Linux, le processus est plus complexe et nécessite souvent une intervention manuelle sur chaque hôte de machine virtuelle.

Les appareils plus anciens qui ont atteint la fin de leur service du point de vue de l’OEM sont particulièrement délicats. Pour ce matériel, il se peut qu’il n’y ait plus de firmware approprié qui ancre les autorités de certification de 2023. Microsoft et les fabricants ne prendront probablement pas en charge tous les anciens appareils. La rédaction de XDA-Developers a souligné dans une analyse fin mars 2026 qu’une partie des PC Windows pré-2020 ne devraient jamais obtenir le correctif. Pour les équipes informatiques, cela signifie que ces appareils doivent être inventoriés, priorisés et soit remplacés rapidement, soit exploités dans des segments de réseau isolés avec des droits réduits.

L’inventaire : PowerShell et Registre

La bonne nouvelle pour les équipes informatiques : l’état d’un appareil peut être vérifié avec un minimum d’effort. Microsoft propose deux méthodes. La première consiste en une entrée de registre dans le chemin HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\UEFICA2023Status. La valeur de cette entrée devrait finalement être « updated ». D’autres valeurs comme « NotStarted » ou « InProgress » indiquent que la distribution n’est pas encore terminée.

La seconde méthode est une requête PowerShell que Microsoft a publiée dans son blog de la communauté technique. Elle liste les entrées de la base de données de démarrage sécurisé actuellement installées et permet une comparaison automatique avec l’état souhaité. Pour un inventaire à l’échelle de la flotte, il est recommandé de combiner cela avec Microsoft Intune, Configuration Manager ou un outil de gestion des points de terminaison comparable qui peut interroger la valeur de registre à l’échelle du système. Une vérification manuelle sur des centaines d’appareils n’est pas réalisable.

Il est important de faire la distinction entre « certificat installé » et « certificat actif ». Un appareil peut avoir le certificat de 2023 dans la base de données UEFI sans qu’il soit utilisé de manière productive. Ce n’est que lorsque l’état est « updated » et que le firmware utilise les autorités de certification de 2023 pour la vérification du chargeur de démarrage que l’appareil est prêt. La transition complète nécessite plusieurs redémarrages et, dans certains cas, des paramètres UEFI manuels. Les équipes informatiques doivent donc tester le processus sur une poignée d’appareils pilotes par modèle avant de lancer le déploiement à l’échelle de la flotte.

Le processus de mise à jour en quatre étapes

Microsoft recommande une approche structurée que les équipes informatiques peuvent mettre en œuvre sur les six à huit prochaines semaines. Le processus se divise en quatre étapes qui s’appuient logiquement les unes sur les autres et ne peuvent pas être parallélisées :

Que se passe-t-il si la mise à jour n’est pas effectuée à temps

Les conséquences d’une mise à jour manquée ne sont pas dramatiques au sens d’une panne complète du système, mais elles sont techniquement désagréables et organisationnellement contraignantes. Les appareils Windows sans CA 2023 restent fonctionnels. Ils continuent à démarrer, sont utilisables et traitent les applications. Cependant, deux choses changent substantiellement.

Premièrement : les nouvelles révisions de Secure Boot publiées par Microsoft après la date limite ne seront plus installées de manière fiable. Cela concerne principalement les mises à jour contre les nouvelles classes de logiciels malveillants au niveau de l’amorçage comme BlackLotus ou les attaques basées sur CoSign. Les appareils sans mise à jour perdent donc progressivement la protection contre les attaques ciblant la chaîne Secure Boot. Ce n’est pas une menace aiguë, mais un risque qui augmente lentement.

Deuxièmement : les logiciels tiers signés avec les nouvelles CA 2023 après la date limite ne seront plus reconnus comme fiables par les anciens appareils. Cela concerne par exemple les chargeurs de démarrage Linux comme Shim et GRUB, qui sont souvent signés à nouveau. S’y ajoutent des outils de sécurité spécialisés avec leurs propres composants de noyau. Les équipes informatiques avec des environnements mixtes ou des applications spécialisées verront très rapidement des problèmes.

Pour les perspectives de conformité, cela est pertinent car NIS2 et ISO 27001 exigent des correctifs de sécurité actuels et une gestion des vulnérabilités. Un auditeur ne manquera pas de poser la question sur l’état du certificat Secure Boot lorsqu’il examine l’architecture de sécurité des points de terminaison. Celui qui ne peut pas présenter un état documenté ici se heurte non seulement à des problèmes techniques, mais aussi à des problèmes réglementaires.

Cas particulier des environnements Linux Dual-Boot et RHEL

Les entreprises avec des environnements Linux ou des appareils Dual-Boot doivent envisager une étape supplémentaire. Red Hat a déjà publié début 2026 une guidance officielle pour les environnements RHEL, qui décrit la transition vers les CA 2023. Le point clé : le chargeur de démarrage Shim de Red Hat est signé par Microsoft avec la CA UEFI 2011. Dès que cette CA expire, les systèmes RHEL et Fedora sur des appareils non mis à jour ne pourront plus démarrer de manière sécurisée. Red Hat fournit de nouvelles versions de Shim signées avec la CA UEFI 2023, mais celles-ci nécessitent la CA correspondante sur l’appareil cible.

Pour les appareils Dual-Boot avec Windows et Linux, il en résulte une séquence claire. Tout d’abord, Windows doit installer les CA 2023 via la procédure de mise à jour, puis le firmware UEFI doit ancrer les nouvelles CA dans la chaîne de confiance, et ce n’est qu’alors que le Shim RHEL ou Fedora avec la signature 2023 pourra démarrer avec succès. L’ordre inverse ne fonctionne pas – une mise à jour échouée peut entraîner une partition Linux non amorçable. Les équipes concernées devraient retenir les mises à jour RHEL jusqu’à la fin de la transition Windows.

Liste de contrôle en six points pour les équipes informatiques

Pour les semaines restantes jusqu’en juin 2026, six étapes concrètes peuvent être priorisées :

1. Lancer l’inventaire. Interroger tous les appareils Windows via une gestion centralisée des points de terminaison sur l’état de l’UEFI CA 2023. Documenter le résultat sous forme de liste Excel ou de tableau de bord, structuré par classe d’appareils et emplacement.
2. Vérifier les mises à jour du firmware. Demander aux fabricants par classe d’appareils si les versions actuelles du BIOS prennent en charge les CA 2023. Dell, HP, Lenovo et Fujitsu ont publié des articles de support avec des versions de firmware compatibles.
3. Mettre en place un pilote. Mettre à jour cinq à dix appareils par modèle dans un groupe pilote, vérifier l’état, documenter les problèmes. Réserver un créneau jusqu’à fin avril.
4. Créer un plan de déploiement. Diviser le déploiement de la flotte en deux à trois vagues, coordonner avec les opérations et les départements métier. Définir des objectifs hebdomadaires au lieu d’objectifs quotidiens, planifier des réserves pour les problèmes inattendus.
5. Coordonner les environnements Linux et de virtualisation. Clarifier avec les administrateurs Linux et les équipes de virtualisation si les systèmes dépendants sont affectés. Définir l’ordre des mises à jour, créer des instantanés rétrocompatibles.
6. Liste des risques pour les anciens appareils. Documenter séparément tous les appareils sans correctif disponible. Les options sont le remplacement, l’isolation du réseau ou la réduction de la surface d’attaque via des listes blanches de logiciels restrictives. Faire valider la décision au niveau CISO.

Conclusion

La transition Secure Boot n’est pas un sujet de réglementation avec une échéance vague, mais une désactivation technique ferme avec une date fixe. Les entreprises qui terminent la mise à jour avant juin 2026 ne devraient pas s’attendre à une rupture brutale. Ceux qui manquent la deadline se retrouveront avec des appareils qui ne feront plus confiance aux nouvelles mises à jour Secure Boot et aux logiciels nouvellement signés – et ce, à une période où les attaques au niveau du démarrage, telles que celles menées par des groupes comme BlackLotus, ont augmenté.

Le travail est réalisable, mais il nécessite une priorité. L’inventaire est la première étape la plus importante, car il fournit la base pour chaque décision ultérieure. Ensuite, suit un déploiement structuré qui sépare proprement les phases de pilote, de tests et de production. Pour les équipes informatiques, cela signifie concrètement : commencer l’inventaire cette semaine, déployer les appareils pilotes la semaine prochaine, mettre à jour tous les appareils standard d’ici fin avril, et traiter les cas problématiques en mai. Ceux qui suivent ce calendrier auront un juin calme.

Foire aux questions

Pouvons-nous déployer la mise à jour de manière centralisée via Intune ou Configuration Manager ?

Oui, les deux outils prennent en charge le déploiement. Microsoft fournit des anneaux de déploiement spécifiques qui sont distribués via Windows Update for Business ou WSUS. Intune propose également des politiques de conformité qui surveillent l’état UEFICA2023 et déclenchent des alarmes en cas d’écart. Pour Configuration Manager, Microsoft recommande une combinaison de séquence de tâches d’inventaire et de déploiements automatisés par groupe d’appareils. Des interventions manuelles ne sont nécessaires que pour les appareils avec des paramètres UEFI personnalisés ou un firmware verrouillé.

Qu’arrive-t-il aux appareils qui ont déjà désactivé Secure Boot ?

Pour les appareils sur lesquels Secure Boot a été désactivé pour des raisons de compatibilité, rien ne change à court terme. Les certificats expirés ne concernent que la fonctionnalité Secure Boot active. Cependant, les équipes informatiques ne devraient pas considérer ces appareils comme traités. La désactivation de Secure Boot est un risque de sécurité qui ne sera plus acceptable en 2026. La transition des certificats est donc une bonne occasion pour auditer les désactivations de Secure Boot et les rétablir si possible.

Comment savoir si mon fabricant de matériel fournit encore la mise à jour ?

La source la plus simple est la page de support du fabricant concerné. Dell, HP, Lenovo et Fujitsu ont publié des listes de leurs appareils pris en charge. Pour les appareils qui n’apparaissent pas sur ces listes, il convient d’adresser une demande directement au support du fabricant. Si cette demande ne reçoit pas de réponse positive, l’appareil est considéré comme en fin de service par le fabricant et ne recevra plus la correction. Microsoft lui-même exploite une page d’atterrissage sous aka.ms/GetSecureBoot avec une collection d’outils et de liens vers les fabricants.

Qu’est-ce que cela signifie pour notre environnement de virtualisation ?

Les machines virtuelles Hyper-V sur Windows Server reçoivent la mise à jour via les correctifs de l’hôte. VMware vSphere nécessite les mises à jour du firmware ESXi fournies par VMware lui-même. Les environnements basés sur KVM sur des hôtes Linux sont plus complexes, car le firmware OVMF doit être mis à jour séparément. Pour les plateformes de virtualisation productives, il est recommandé de procéder à une vague de déploiement avant la date limite, séparément de la mise à jour des clients. Ceux qui utilisent des machines virtuelles de test comme pilotes peuvent identifier les cas limites tôt.

Existe-t-il un moyen de forcer la mise à jour si Windows Update ne la propose pas ?

Microsoft distribue les autorités de certification 2023 de manière échelonnée pour ne pas surcharger les systèmes de production. Un remplacement manuel est possible via l’entrée de registre MicrosoftUpdateManagedOptIn, qui accélère le déploiement pour l’appareil spécifique. La valeur doit être définie sur 0x5944 pour les appareils pilotes individuels. Cette méthode est surtout utile pour les appareils de test dédiés et les audits de conformité, et non pour un déploiement à grande échelle.

Y aura-t-il une prolongation de la deadline ?

Microsoft n’a pas annoncé de prolongation jusqu’à présent et signale au contraire, avec la publication du playbook, que la deadline est prise au sérieux. La planification doit donc être résolument axée sur la date butoir de juin. Même si Microsoft devait introduire une mesure de clémence au dernier moment, l’avantage d’un déploiement effectué à temps est suffisamment important pour ne pas compter sur des délais de grâce. Les équipes informatiques devraient traiter la deadline comme fixe.

Crédit image de titre : Pexels / panumas nikhomkhai

À propos de l'auteur: Tobias Massow

Plus d'articles de Tobias Massow