Secure Boot 2026 : expiration des certificats, comprendre et agir maintenant!

Vous avez probablement déjà vu passer les communications Microsoft sur la mise à jour des certificats Secure Boot avant juin 2026. Et comme souvent avec ce type de sujet, la première réaction peut vite être l’une de celles-ci : “j’ai encore un peu de temps” ou au contraire “par où commencer ?”.

Secure Boot reste l’une des premières lignes de défense d’un poste Windows. Au niveau du firmware UEFI, il vérifie que le bootloader, les drivers et les composants critiques du démarrage portent bien une signature numérique approuvée, afin de bloquer très tôt tout composant non fiable ou malveillant.

Le changement à venir concerne les certificats Microsoft historiques utilisés dans cette chaîne de confiance. Les premières échéances arrivent en 2026, avec une transition vers la génération Windows UEFI CA 2023 et la mise à jour des bases DB, KEK et DBX, distribuées via Windows pour les postes pris en charge.

Le sujet mérite surtout d’être cadré proprement : comprendre ce qui change, identifier les impacts côté parc, et préparer un déploiement cohérent dans un environnement géré avec Intune.

Ce qui change en 2026

Deux échéances structurent le sujet :

• Juin 2026 : expiration des certificats :
  • Microsoft Corporation KEK CA 2011
  • Microsoft Corporation UEFI CA 2011
• Octobre 2026 : expiration de Microsoft Windows Production PCA 2011

La « cible à atteindre » est la chaîne 2023 :

• Microsoft Corporation KEK CA 2023
• Microsoft UEFI CA 2023
• Windows UEFI CA 2023

A noter que la rotation des certificats s’inscrit aussi dans le durcissement de la chaîne de boot face à BlackLotus / CVE-2023-24932. En pratique, faire passer un poste sur la chaîne 2023 permet à la fois de préparer l’après-2011 et de sortir de l’ancien chemin de confiance utilisé par le boot manager vulnérable.

Rappel : le Secure Boot sert à quoi ?

Secure Boot contrôle ce qui se charge avant Windows. On parle ici du bootloader, des drivers UEFI, des option ROMs et d’autres composants critiques du démarrage. Si la signature n’est pas reconnue par la chaîne de confiance, le composant ne doit pas être exécuté.

Cette chaîne repose sur plusieurs bases stockées dans le firmware :

• PK : la clé racine de la plateforme
• KEK : autorise les mises à jour de DB et DBX
• DB : liste des signatures autorisées
• DBX : liste des signatures révoquées

Dans la pratique, les plus parlantes côté exploitation restent souvent DB et DBX. C’est là que se joue ce qui peut encore démarrer et ce qui doit être bloqué.

Pourquoi BlackLotus revient (encore) dans le sujet

BlackLotus est un bootkit UEFI qui exploite la CVE-2023-24932. Le problème est simple : le code s’exécute avant Windows, donc sous les contrôles habituels de l’OS. Antivirus, EDR, voire réinstallation de l’OS, ne suffisent pas forcément si la chaîne de confiance du boot n’a pas été corrigée.

Il faut donc bien séparer deux choses :

• BlackLotus est un problème de sécurité
• L’expiration 2026 est un problème de gestion du cycle de vie des certificats

Mais la réponse technique à ces deux éléments converge : mise à jour du bootloader, révocation de l’ancien chemin vulnérable et passage vers la chaîne 2023.

Ce qui se passe si rien n’est fait

Autant le dire tout de suite et clairement : un poste non traité ne va généralement pas s’arrêter de démarrer en juin 2026. Dans la majorité des cas, les machines continuent à booter et à fonctionner normalement du point de vue utilisateur.

En revanche, le poste passe progressivement dans un état de sécurité dégradé :

• les futures mises à jour Secure Boot risquent de ne plus s’appliquer correctement
• certains composants UEFI tiers signés avec la chaîne 2023 peuvent ne plus être approuvés
• le poste reste sur une ancienne base de confiance et conserve une exposition inutile côté boot path

Le principal risque réside dans une diminution graduelle du niveau de sécurité du parc, plutôt que dans l’apparition soudaine d’une panne un bon matin de juin 2026.

Comment la mise à jour fonctionne

Le mécanisme est déjà intégré à Windows. Il repose sur une clé de registre sous :

HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot

et sur la tâche planifiée :

\Microsoft\Windows\PI\Secure-Boot-Update

La logique de mise à jour est fournie par Windows, puis déclenchée après positionnement des bons indicateurs. Dans la vraie vie, cela veut souvent dire un ou plusieurs redémarrages avant d’arriver à un état final propre.

La valeur utilisée pour déclencher la séquence complète est :

AvailableUpdates = 0x5944

Cette valeur couvre :

• l’ajout du KEK 2023
• la mise à jour des entrées DB
• la mise à jour du boot manager
• la mise à jour de DBX

Pour le suivi local, les valeurs les plus utiles se trouvent ensuite sous :

HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing

Les trois premières à regarder sont :

• UEFICA2023Status
• WindowsUEFICA2023Capable
• UEFICA2023Error

C’est généralement ce trio qui permet de comprendre si la machine est déjà à jour, en attente, non capable ou bloquée par une erreur interne.

Les prérequis à valider (avant le déploiement…)

Le firmware, cet élément (trop) souvent oubliée

C’est souvent là que le sujet devient moins évident. Sur une partie du parc, surtout sur des machines qui ont déjà quelques années, la partie gérée par Microsoft ne suffit pas. Une mise à jour BIOS / UEFI constructeur peut être nécessaire avant que la chaîne 2023 soit acceptée correctement.

C’est souvent ce point qui explique les situations où :

• le paramétrage paraît bon mais le poste remonte des états partiellement cohérents
• Le certificat n’est toujours pas correctement appliqué

Une règle simple peut vous aider à une prise de décision sur le sujet : sur des machines de plus de deux ans, il faut envisager qu’un update firmware soit nécessaire. Sur les modèles plus récents, c’est plus variable, donc à vérifier au cas par cas pour chaque modèles.

Il faut aussi garder en tête deux choses très importantes :

• certains devices demandent plus d’un redémarrage
• un script ou un statut de conformité peut paraître correct alors qu’un problème firmware subsiste encore sur la machine

La gestion du firmware ne doit donc pas être traité comme un détail mais comme une étape à part entière dans votre démarche.

Comment traiter la mise à jour de firmware

Il n’y a pas une seule bonne méthode. Le bon choix dépend surtout du socle de gestion déjà en place dans votre organisation.

Lorsque vos appareils Windows utilise déjà Windows Update for Business ou Autopatch, il est généralement plus judicieux d’opter pour Driver Updates. Cette solution s’avère souvent la plus simple et efficace, puisque le système Windows Update fonctionne déjà.

Dans un environnement ConfigMgr / SCCM, une autre approche consiste à utiliser SCCM avec des catalogues tiers constructeurs pour distribuer BIOS et firmware.

Il reste enfin les outils OEM, qui sont parfois la méthode la plus simple sur certains lots ou en phase pilote :

• Dell Command | Update
• Lenovo Vantage / Lenovo System Update
• HP Image Assistant (HPIA)

La bonne méthode reste souvent la même :

1. Regrouper vos postes par constructeur et modèle
2. Identifier les versions BIOS / UEFI minimales
3. Valider le comportement sur un pilot
4. Contrôler le résultat après le redémarrage
   • puis élargir progressivement le déploiement

Les constructeurs publient des matrices par modèle avec la version minimale de BIOS ou d’UEFI requise pour supporter la chaîne de certificats 2023. L’inventaire matériel du parc doit être rapproché de ces matrices avant tout déploiement.

Les constructeurs publient des matrices par modèle avec la version minimale de BIOS ou d’UEFI requise pour supporter la chaîne de certificats 2023. L’inventaire matériel du parc doit être rapproché de ces matrices avant tout déploiement.

Lenovo

HP

Dell

Dans la pratique, ces tableaux servent à identifier les modèles qui nécessitent une mise à jour firmware avant le déploiement Secure Boot, puis à organiser les vagues de traitement par constructeur et par modèle.

Pour une liste plus complète, je vous ajoute les liens pour chaque OEM :

• Lenovo : https://support.lenovo.com/fr/fr/solutions/ht518129
• HP : https://support.hp.com/fr-fr/document/ish_13070359-13192079-16
• Dell : https://www.dell.com/support/kbdoc/fr-fr/000347876/expiration-du-certificat-de-secure-boot-microsoft-2011

Avant de choisir une méthode : comment le poste est géré?

Avant de déployer une policy Secure Boot, il faut d’abord savoir comment le poste est géré :

• Intune
• SCCM / ConfigMgr
• Co-managed

Le choix de la méthode dépend directement de cette réponse :

Si les postes sont co-gérés et que le workload Device Configuration est encore côté ConfigMgr, les policies Intune Settings Catalog n’atteindront pas le device. Dans ce cas, elles restent simplement en Pending. On peut attendre longtemps, le poste ne bougera pas.

Si l’objectif est de pousser la configuration depuis Intune, le workload doit être déplacé vers Pilot Intune ou vers l’état approprié selon le modèle retenu, et le device doit bien faire partie de la pilot collection.

C’est un contrôle très simple, mais il évite beaucoup de temps perdu quand tout semble correct côté Intune alors que le poste n’est tout simplement pas censé recevoir la policy.

Déploiement avec Intune

Settings Catalog

Microsoft a ajouté des réglages dédiés dans le Settings Catalog. Les trois paramètres à connaître sont :

• Enable SecureBoot Certificate Updates
• Configure Microsoft Update Managed Opt In
• Configure High Confidence Opt Out

Attention à l’erreur 65000. Elle apparaît encore dans certains cas chez mes clients, notamment sur des machines Windows Pro ou sur des postes passés en Enterprise via subscription activation.

Le Settings Catalog reste donc une bonne option sur un parc homogène et propre, mais ce n’est pas forcément le chemin le plus confortable pour un rollout large ou pour un environnement hétérogène.

Il faut aussi garder le point précédent en tête : sur un parc co-managé, si Device Configuration est toujours géré par ConfigMgr, la policy Intune peut rester en Pending sans jamais atteindre le poste, voir mon rappel plus haut dans l’article.

Une fois la configuration appliquée, les clés de registres sont mises à jour :

Après application de la policy Secure Boot via le Settings Catalog Intune, il est normal de voir plusieurs valeurs apparaître sous :

HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot

Par exemple :

• AvailableUpdatesPolicy = 0x5944
• AvailableUpdates = 0x4000

Le point important, c’est que ces deux valeurs n’ont pas le même rôle.

AvailableUpdatesPolicy correspond à la consigne envoyée par la policy.
AvailableUpdates, lui, correspond à la valeur de travail utilisée par Windows pendant le traitement.

Donc si les deux ne sont pas identiques, ce n’est pas forcément un problème, c’est souvent le signe que Windows a déjà commencé à traiter la demande.

HighConfidenceOptOut = 1 signifie que le poste ne passe pas par le mode de déploiement automatique “high confidence”

• MicrosoftUpdateManagedOptIn = 1 signifie qu’il est bien inscrit dans le mode de gestion Microsoft pour ce rollout

En revanche, ça ne veut pas encore dire que la mise à jour Secure Boot est terminée.

Pour savoir où en est réellement la machine, il faut ensuite regarder sous :

HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing

Les deux valeurs les plus utiles sont :

• UEFICA2023Status
• UEFICA2023Error

C’est là qu’on voit si le poste est encore en cours, terminé, ou bloqué.

Et après quelques heures et un redémarrage plus tard :

La policy Intune a bien atteint le poste, Windows a bien traduit cette policy dans son workflow Secure Boot le poste est bien engagé dans le processus de mise à jour.

Platform Script

Le Platform Script est souvent plus simple pour un pilote, il suffit de lire l’état actuel, vérifier que Secure Boot est activé, contrôler les clés de servicing, écrire AvailableUpdates = 0x5944 si nécessaire dans le registre, puis lancer la tâche planifié \Microsoft\Windows\PI\Secure-Boot-Update.

Pour un pilote, c’est souvent une très bonne base quand on veut garder la main sur le processus côté poste.

J’utilise une version modifié du script de FlorianSLZ (Florian Salzmann) que vous pouvez téléchager dans mon GitHub

Remediation Package

Pour un parc large, le Remediation Package reste souvent la méthode la plus propre. L’intérêt est de séparer la détection et la remédiation, ce qui permet de commencer par une vraie vue de l’état du parc avant de pousser quoi que ce soit.

C’est souvent la meilleure option quand le parc est large ou hétérogène et c’est téléchargeable ici Sample Secure Boot Inventory Data Collection script – Microsoft Support

Monitoring : où regarder ?

Rapport natif Intune

Le rapport Secure Boot status dans Intune sert d’abord à inventorier et planifier.

Il permet de voir rapidement les statuts :

• Up to date
• Not up to date
• Not applicable

Il peut aussi aider à repérer les modèles à problème et, selon les cas, la version firmware.

Ce rapport est accessible dans Reports > Windows Autopatch > Windows quality updates > Reports > Secure Boot status

Le status « Not up to date« 

Quand certains devices restent bloqués en Not up to date dans le rapport Intune alors que le socle est déjà propre, une autre piste peut être testée en dépannage ciblé :

WinCsFlags.exe /apply --key F33E0C8E002

Cette commande n’a pas vocation à devenir un mécanisme de déploiement massif. Elle a surtout du sens sur un petit lot de machines déjà patchées, avec Secure Boot activé, firmware déjà vérifié, et statut encore bloqué côté Intune.

Registre/Event Viewer

Quand une machine ne suit pas, il faut regarder localement.

Le registre sous :

HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing

reste la source la plus utile pour comprendre l’état réel du servicing.

L’Event Viewer Windows apporte aussi des signaux utiles, en particulier dans :

Windows Logs / System

avec une attention particulière aux sources :

• TPM
• TPM-WMI

C’est souvent là que les problèmes liés au firmware deviennent visibles.

Windows Security

Windows affiche aussi des informations de statut dans Windows Security > Device security. Sur les devices Enterprise gérés, cet affichage n’est pas toujours visible par défaut.

La clé à connaître est :

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows Defender Security Center\Device security

avec la valeur :

HideSecureBootStates

• 0 : afficher
• 1 : masquer
• non présent : par défaut

C’est utile sur un pilote ou pour donner un point de lecture simple aux équipes support.

Avant :

Après :

Et si je n’utilise pas (encore) Intune ?

Une solution GPO existe aussi. Elle repose sur le nouvel ADMX SecureBoot, avec un besoin possible de mise à jour du Central Store dans SYSVOL.

Le paramètre se trouve sous :

Computer Configuration > Administrative Templates > Windows Components > Secure Boot

Retours terrain

Firmware OEM

C’est très souvent le premier vrai point de blocage en production.
Sur une partie du parc (en particulier les machines plus anciennes), une mise à jour UEFI/BIOS constructeur est nécessaire avant que les certificats 2023 puissent être pris en compte correctement.

Si le parc a 4–5 ans (ou plus), il faut prévoir un audit firmware dès le cadrage du projet (modèles, versions, disponibilité des packages OEM, fenêtres de maintenance).

Données de diagnostic

Si la télémétrie est positionnée sur Off (souvent équivalent au niveau Security selon l’édition/politiques), le mécanisme de mise à jour des certificats ne démarre pas.
Le niveau minimal requis est Required.

Machines virtuelles

Le périmètre ne se limite pas aux postes physiques.
Les VM Hyper-V Gen 2 et les VM Azure sont concernées au même titre.

Pensez aussi au volet serveurs si le périmètre inclut des workloads Secure Boot (golden images, templates, VDI, etc.).

Monitoring d’abord, remédiation ensuite

L’approche la plus maîtrisée consiste à démarrer par une Intune Remediation en détection seule.

Conclusion

La rotation des certificats Secure Boot en 2026 est un chantier transverse : il impacte quasiment tout le parc Windows, y compris des machines qui n’ont pas été revalidées récemment.

Le traiter maintenant est nettement plus simple que d’attendre la dernière ligne droite. Entre les Intune Remediations, le déclenchement via registre, les rapports disponibles et les scripts éprouvés côté communauté, on a aujourd’hui de quoi industrialiser proprement.

Enfin, cela permet égalment de réduire l’exposition à BlackLotus. Ce n’est pas l’objectif principal, mais c’est un gain sécurité concret qu’il serait dommage de laisser de côté.