Secure Boot : vérifier et déployer les nouveaux certificats Windows 2023

L’essentiel à retenir

Secure Boot protège la phase de démarrage d’un ordinateur UEFI en vérifiant que les composants exécutés avant Windows sont signés par une autorité approuvée.

Plusieurs certificats Microsoft créés en 2011 arrivent à expiration en 2026 :

Un appareil qui n’a pas encore reçu les nouveaux certificats :

• continue normalement à démarrer dans la majorité des cas ;
• continue à recevoir les mises à jour Windows habituelles ;
• peut cependant ne plus recevoir de nouvelles protections du démarrage ;
• peut rencontrer à terme des difficultés autour des révocations, du gestionnaire de démarrage ou de certains chargeurs tiers.

Microsoft gère automatiquement la transition sur une part importante des appareils. Les entreprises qui administrent leur parc doivent néanmoins :

1. inventorier les postes ;
2. vérifier Secure Boot et BitLocker ;
3. installer les mises à jour Windows et firmware requises ;
4. déployer par groupes pilotes ;
5. suivre les événements TPM-WMI ;
6. traiter les appareils bloqués par leur firmware.

À quoi sert Secure Boot ?

Le firmware UEFI démarre avant Windows.

Secure Boot utilise plusieurs bases de confiance stockées dans le firmware :

• PK, la Platform Key généralement contrôlée par le constructeur ;
• KEK, les Key Exchange Keys autorisant les mises à jour des bases ;
• DB, la base des signatures autorisées ;
• DBX, la base des signatures révoquées et interdites.

Le démarrage peut être représenté ainsi :

Mise sous tension
      │
      ▼
Firmware UEFI
      │
      ├── Vérification des pilotes UEFI et Option ROM
      │
      ▼
Windows Boot Manager
      │
      ├── Vérification de la signature
      │
      ▼
Chargement de Windows

Secure Boot vise notamment les menaces capables de s’exécuter avant le système d’exploitation :

• bootkits ;
• gestionnaires de démarrage malveillants ;
• pilotes UEFI non approuvés ;
• composants révoqués mais encore présents.

Pourquoi remplacer les certificats de 2011 ?

Les certificats ont une durée de validité limitée.

La transition vers les certificats 2023 doit permettre à Microsoft et aux constructeurs de continuer à :

• signer les nouveaux gestionnaires de démarrage ;
• mettre à jour les bases Secure Boot ;
• ajouter de nouvelles révocations ;
• bloquer des composants de démarrage vulnérables ;
• maintenir la chaîne de confiance après l’expiration des certificats historiques.

L’expiration ne signifie pas que l’ordinateur s’éteint à minuit ou devient immédiatement inutilisable.

Elle signifie surtout qu’un poste resté sur l’ancienne chaîne de confiance peut ne plus recevoir les évolutions de sécurité futures de la phase de démarrage.

Quelles bases doivent être mises à jour ?

Microsoft précise que la base DB et la base KEK doivent recevoir les certificats 2023 correspondants.

KEK

Le nouveau certificat :

Microsoft Corporation KEK 2K CA 2023

permet d’autoriser les futures mises à jour des bases DB et DBX.

DB

La base autorisée doit notamment recevoir :

Windows UEFI CA 2023
Microsoft UEFI CA 2023
Microsoft Option ROM UEFI CA 2023

Les deux derniers certificats séparent désormais :

• la confiance accordée aux chargeurs UEFI tiers ;
• la confiance accordée aux Option ROM des périphériques.

Cette séparation donne un contrôle plus fin aux constructeurs et administrateurs.

Étape 1 : identifier les appareils UEFI

Avec Informations système

Appuyez sur :

Windows + R

Saisissez :

msinfo32

Vérifiez :

• Mode BIOS : UEFI ;
• État du démarrage sécurisé : Activé.

Un poste configuré en mode BIOS hérité n’utilise pas Secure Boot de la même manière.

Avec PowerShell

Ouvrez PowerShell en administrateur :

Confirm-SecureBootUEFI

Résultats possibles :

True

Secure Boot est actif.

False

Le matériel est compatible, mais Secure Boot est désactivé.

Cmdlet not supported on this platform

La machine n’est probablement pas démarrée en mode UEFI ou ne prend pas en charge cette fonction.

Étape 2 : vérifier BitLocker avant toute modification

Secure Boot participe aux mesures de démarrage utilisées par le TPM et BitLocker.

Une modification du firmware ou de la chaîne de confiance peut provoquer une demande de clé de récupération.

Vérifiez l’état de BitLocker :

Get-BitLockerVolume

Ou :

manage-bde -status

Pour chaque poste chiffré, confirmez que la clé de récupération est stockée dans l’emplacement prévu :

• Microsoft Entra ID ;
• Active Directory ;
• solution MDM ;
• coffre-fort sécurisé ;
• compte Microsoft pour certains postes particuliers.

Ne vous contentez pas de savoir que « BitLocker est activé ».

Vérifiez que la clé :

• existe ;
• correspond au bon appareil ;
• est accessible pendant la fenêtre de maintenance ;
• n’est pas stockée uniquement sur le poste concerné.

Étape 3 : relever le constructeur, le modèle et le firmware

La réussite dépend en partie du firmware UEFI fourni par le constructeur.

Collectez les informations suivantes :

Get-CimInstance Win32_ComputerSystem |
    Select-Object Manufacturer, Model

Get-CimInstance Win32_BIOS |
    Select-Object SMBIOSBIOSVersion, ReleaseDate

Créez un inventaire :

$computer = Get-CimInstance Win32_ComputerSystem
$bios = Get-CimInstance Win32_BIOS

[PSCustomObject]@{
    Ordinateur   = $env:COMPUTERNAME
    Constructeur = $computer.Manufacturer
    Modele       = $computer.Model
    BIOS         = $bios.SMBIOSBIOSVersion
    DateBIOS     = $bios.ReleaseDate
    SecureBoot   = try { Confirm-SecureBootUEFI } catch { 'Non pris en charge' }
}

Consultez ensuite le site du constructeur pour rechercher :

• mise à jour BIOS ou UEFI ;
• mention des certificats Secure Boot 2023 ;
• problème connu ;
• procédure spécifique ;
• restriction sur un ancien modèle.

Étape 4 : vérifier les mises à jour Windows requises

Installez les mises à jour cumulatives et de maintenance recommandées pour la version de Windows utilisée.

Pour un poste non géré :

Paramètres → Windows Update → Rechercher des mises à jour

Pour un parc administré :

• Windows Update for Business ;
• Microsoft Intune ;
• WSUS selon la stratégie ;
• outil RMM ;
• solution de gestion de parc.

Redémarrez lorsque cela est demandé.

La transition Secure Boot peut nécessiter plusieurs cycles :

1. installation d’une mise à jour Windows ;
2. exécution d’une tâche planifiée ;
3. écriture dans les variables UEFI ;
4. redémarrage ;
5. installation d’un nouveau gestionnaire de démarrage ;
6. nouveau redémarrage ;
7. application d’autres certificats ou révocations.

Un seul redémarrage n’est donc pas toujours suffisant.

Étape 5 : vérifier la tâche planifiée Secure-Boot-Update

Windows utilise une tâche planifiée :

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

Elle s’exécute comme Local System, au démarrage puis périodiquement.

Vérifiez sa présence avec PowerShell :

Get-ScheduledTask \
  -TaskPath '\Microsoft\Windows\PI\' \
  -TaskName 'Secure-Boot-Update'

Affichez son état :

Get-ScheduledTaskInfo \
  -TaskPath '\Microsoft\Windows\PI\' \
  -TaskName 'Secure-Boot-Update'

La tâche ne doit pas être supprimée ou désactivée.

Étape 6 : vérifier l’état dans le Registre

Microsoft utilise notamment la clé :

HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing

Affichez les propriétés disponibles :

Get-ItemProperty \
  -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing'

La valeur suivante est particulièrement utile :

UEFICA2023Status

Pour la lire :

(Get-ItemProperty \
  -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing' \
  -ErrorAction SilentlyContinue).UEFICA2023Status

Une valeur indiquant que le statut est mis à jour, associée aux événements de succès, confirme la progression.

L’absence de la clé peut signifier :

• processus non démarré ;
• système non éligible ;
• tâche désactivée ;
• Secure Boot désactivé ;
• mises à jour prérequises absentes.

Étape 7 : examiner les événements TPM-WMI

Les événements sont enregistrés dans le journal Système, source :

TPM-WMI

Vous pouvez les filtrer avec PowerShell :

Get-WinEvent \
  -FilterHashtable @{
      LogName      = 'System'
      ProviderName = 'Microsoft-Windows-TPM-WMI'
  } \
  -MaxEvents 100 |
  Select-Object TimeCreated, Id, LevelDisplayName, Message

Événements de succès utiles

Événements d’échec ou d’attente

Étape 8 : vérifier directement les variables UEFI

PowerShell peut lire les variables Secure Boot lorsque la machine le permet.

Lire KEK

Get-SecureBootUEFI -Name KEK

Lire DB

Get-SecureBootUEFI -Name db

Recherche textuelle des certificats

Cette méthode fournit un contrôle complémentaire :

$kek = [System.Text.Encoding]::ASCII.GetString(
    (Get-SecureBootUEFI -Name KEK).Bytes
)

$db = [System.Text.Encoding]::ASCII.GetString(
    (Get-SecureBootUEFI -Name db).Bytes
)

[PSCustomObject]@{
    KEK2023 = $kek -match 'Microsoft Corporation KEK 2K CA 2023'
    WindowsUEFICA2023 = $db -match 'Windows UEFI CA 2023'
    MicrosoftUEFICA2023 = $db -match 'Microsoft UEFI CA 2023'
    OptionROMUEFICA2023 = $db -match 'Microsoft Option ROM UEFI CA 2023'
}

Les résultats True indiquent que les chaînes recherchées sont présentes dans les variables lues.

Ce contrôle doit être corrélé avec :

• le statut Registre ;
• les événements ;
• l’état de Secure Boot ;
• le gestionnaire de démarrage ;
• le firmware constructeur.

Étape 9 : créer un groupe pilote

Microsoft recommande un déploiement progressif.

Le groupe pilote doit inclure plusieurs profils :

• un modèle courant ;
• un modèle ancien encore supporté ;
• un ordinateur portable ;
• un poste avec BitLocker ;
• une machine utilisant PXE si cela existe ;
• un poste avec dock ou carte d’extension ;
• une VM de génération UEFI lorsque l’hyperviseur est concerné.

Évitez pour le premier groupe :

• serveur unique critique ;
• poste d’un dirigeant en déplacement ;
• machine sans clé BitLocker ;
• matériel sans accès console ;
• système industriel ;
• appareil dont le firmware n’est plus supporté.

Étape 10 : définir les contrôles du pilote

Avant la mise à jour :

• version de Windows ;
• version UEFI ;
• Secure Boot actif ;
• BitLocker et clé disponible ;
• ordre de démarrage ;
• présence de PXE ;
• état de la tâche planifiée ;
• événements existants ;
• certificats présents.

Après la mise à jour et les redémarrages :

• démarrage normal ;
• absence de demande BitLocker répétée ;
• réseau ;
• dock et périphériques ;
• gestionnaire de démarrage ;
• événements 1043, 1044, 1045, 1799 ou 1808 selon l’étape ;
• UEFICA2023Status ;
• certificats dans KEK et DB ;
• mises à jour Windows toujours opérationnelles.

Déployer progressivement dans l’entreprise

Une organisation peut utiliser plusieurs vagues :

Pilote technique
      │
      ▼
Utilisateurs volontaires
      │
      ▼
Modèles matériels courants
      │
      ▼
Postes distants
      │
      ▼
Serveurs et appareils particuliers

Laissez suffisamment de temps pour observer :

• plusieurs redémarrages ;
• les événements ;
• les incidents BitLocker ;
• les problèmes de firmware ;
• le fonctionnement de PXE ;
• le retour de l’outil de gestion.

Cas 1 : événement 1801 persistant

L’événement 1801 indique que les certificats mis à jour ne sont pas appliqués au firmware.

Vérifiez :

1. Secure Boot actif ;
2. système Windows pris en charge ;
3. mises à jour Windows installées ;
4. tâche Secure-Boot-Update active ;
5. firmware récent ;
6. événements 1795, 1796, 1802 ou 1803 ;
7. redémarrages réalisés.

Ne forcez pas la modification directement dans l’UEFI.

Si le firmware refuse l’écriture, recherchez une mise à jour constructeur.

Cas 2 : récupération BitLocker une seule fois

Microsoft documente un scénario où la première mesure TPM ne reflète pas encore correctement les nouvelles variables Secure Boot.

Le poste peut demander la clé une fois, puis démarrer normalement aux redémarrages suivants.

Actions :

1. saisir la clé de récupération ;
2. vérifier les événements ;
3. mettre le firmware à jour ;
4. effectuer un nouveau redémarrage ;
5. confirmer que la demande ne revient pas.

Cas 3 : BitLocker demandé à chaque démarrage

Une cause possible est un ordre de démarrage configuré avec PXE avant le disque local.

Le firmware mesure alors deux chemins différents :

• chargeur PXE encore signé avec l’ancienne autorité ;
• gestionnaire Windows local signé avec l’autorité 2023.

Vérifiez l’ordre de démarrage.

Lorsque PXE n’est pas nécessaire :

• placez Windows Boot Manager en premier ;
• désactivez le démarrage réseau.

Lorsque PXE est nécessaire :

• mettez à jour l’infrastructure de démarrage ;
• utilisez des composants signés avec les nouvelles autorités ;
• testez avant généralisation.

Cas 4 : l’appareil ne démarre plus après une réinitialisation Secure Boot

Réinitialiser Secure Boot aux valeurs d’usine peut effacer les certificats ajoutés.

Si le gestionnaire de démarrage Windows utilise déjà le certificat 2023 mais que le firmware est revenu à une base ancienne, il peut ne plus lui faire confiance.

Microsoft fournit un outil de récupération :

SecureBootRecovery.efi

La procédure générale documentée consiste à :

1. utiliser un second PC Windows à jour ;
2. copier C:\Windows\Boot\EFI\SecureBootRecovery.efi ;
3. préparer une clé USB FAT32 ;
4. placer le fichier sous \EFI\BOOT\ ;
5. le renommer selon l’architecture, par exemple bootx64.efi ;
6. démarrer l’appareil depuis la clé ;
7. laisser l’outil restaurer la confiance nécessaire ;
8. mettre ensuite le firmware à jour.

Cas 5 : le firmware bloque définitivement le KEK

La mise à jour du KEK doit être autorisée par la Platform Key du constructeur.

Sur certains anciens appareils :

• le constructeur ne fournit plus la clé ou le firmware nécessaire ;
• l’événement 1803 se répète ;
• la valeur AvailableUpdates reste bloquée ;
• le processus ne peut pas terminer la maintenance.

Windows ne peut pas contourner cette limite de manière prise en charge.

Il faut alors :

• contacter le constructeur ;
• rechercher un firmware officiel ;
• évaluer le maintien du matériel ;
• planifier son remplacement si la chaîne de confiance ne peut plus être maintenue.

Générer un rapport PowerShell simple

Le script suivant rassemble des informations sans modifier le poste :

$secureBoot = try {
    Confirm-SecureBootUEFI
} catch {
    'Non pris en charge ou accès refusé'
}

$computer = Get-CimInstance Win32_ComputerSystem
$bios = Get-CimInstance Win32_BIOS
$servicingPath = 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing'
$servicing = Get-ItemProperty -Path $servicingPath -ErrorAction SilentlyContinue

$events = Get-WinEvent \
    -FilterHashtable @{
        LogName      = 'System'
        ProviderName = 'Microsoft-Windows-TPM-WMI'
        Id           = 1043,1044,1045,1795,1796,1797,1798,1799,1800,1801,1802,1803,1808
    } \
    -MaxEvents 20 \
    -ErrorAction SilentlyContinue

[PSCustomObject]@{
    Ordinateur       = $env:COMPUTERNAME
    Constructeur     = $computer.Manufacturer
    Modele           = $computer.Model
    BIOS             = $bios.SMBIOSBIOSVersion
    SecureBoot       = $secureBoot
    UEFICA2023Status = $servicing.UEFICA2023Status
    DernierEvenement = $events | Select-Object -First 1 -ExpandProperty Id
    DateEvenement    = $events | Select-Object -First 1 -ExpandProperty TimeCreated
}

Testez ce script sur les versions réellement utilisées avant de le déployer à grande échelle.

Les erreurs à éviter

Activer Secure Boot à distance sans vérifier la configuration

Une machine installée en mode BIOS ou avec un ancien système peut ne plus démarrer.

Ne pas sauvegarder les clés BitLocker

Une demande de récupération peut alors transformer une maintenance en perte d’accès.

Modifier directement PK, KEK, DB ou DBX

Ces bases font partie de la chaîne de confiance du firmware.

Déployer sur tous les modèles en même temps

Les implémentations UEFI varient fortement.

Ignorer le firmware constructeur

Windows orchestre la mise à jour, mais le firmware écrit et conserve les variables.

Réinitialiser Secure Boot aux valeurs d’usine

Les valeurs d’usine d’un ancien firmware peuvent ne pas contenir les certificats 2023.

Considérer l’événement 1799 comme la fin complète

Il confirme le nouveau gestionnaire de démarrage, mais l’événement 1808 et les autres contrôles donnent une vision plus complète.

Checklist avant pilote

• ☐ Les modèles et firmwares sont inventoriés.
• ☐ Secure Boot est actif sur les appareils pilotes.
• ☐ Les clés BitLocker sont accessibles.
• ☐ Les mises à jour Windows sont installées.
• ☐ Le firmware constructeur est à jour.
• ☐ L’ordre de démarrage est documenté.
• ☐ PXE est identifié.
• ☐ La tâche Secure-Boot-Update existe.
• ☐ Les événements TPM-WMI sont collectés.
• ☐ Un accès physique ou hors bande existe.
• ☐ Le média de récupération est préparé.
• ☐ Le plan de communication est défini.

Checklist après déploiement

• ☐ Le poste démarre normalement.
• ☐ BitLocker ne demande pas la clé à répétition.
• ☐ Secure Boot reste actif.
• ☐ Le statut UEFICA2023Status progresse correctement.
• ☐ Les événements de succès attendus sont présents.
• ☐ Aucun événement d’échec persistant n’est ignoré.
• ☐ Les certificats 2023 sont visibles dans KEK et DB.
• ☐ Windows Update fonctionne toujours.
• ☐ Les périphériques et Option ROM fonctionnent.
• ☐ Le démarrage PXE fonctionne si nécessaire.
• ☐ L’outil de gestion retrouve la machine.
• ☐ L’inventaire a été mis à jour.

Conclusion

L’expiration des certificats Secure Boot de 2011 ne provoque pas l’arrêt immédiat des ordinateurs.

Elle marque cependant une transition importante de la chaîne de confiance Windows.

Les appareils qui ne reçoivent pas les certificats 2023 risquent de ne plus bénéficier des futures protections appliquées au démarrage.

Une stratégie professionnelle consiste à :

1. inventorier les modèles ;
2. vérifier Secure Boot et BitLocker ;
3. installer les mises à jour Windows et firmware ;
4. lancer un pilote ;
5. suivre les événements ;
6. traiter les appareils bloqués ;
7. élargir progressivement le déploiement.

Le point le plus important est de ne pas traiter Secure Boot comme une simple option Windows. La mise à jour traverse plusieurs couches : système, gestionnaire de démarrage, TPM et firmware du constructeur.

Besoin d’accompagner votre parc Windows ?

AGE-Info accompagne les TPE et PME dans la maintenance et la sécurisation de leurs postes.

Nous pouvons notamment :

• inventorier les appareils ;
• vérifier Secure Boot et BitLocker ;
• préparer un groupe pilote ;
• suivre les événements de mise à jour ;
• contrôler les firmwares ;
• organiser un déploiement progressif ;
• préparer les procédures de récupération ;
• documenter l’état du parc.