Dans cet article, je vais partager un dashboard Log Analytics vous permettant de surveiller l’état de l’expiration des certificats Windows Secure Boot sur vos appareils Intune.
Comme vous le savez sûrement, les certificats Secure Boot expireront en juin 2026. Je ne vais pas aborder ce sujet en détail ici, car de nombreuses ressources existent déjà sur le sujet.
Vous trouverez ci‑dessous quelques articles intéressants :
https://www.tbone.se/2026/01/09/update-secure-boot-certificate-by-using-intune-remediation
https://patchmypc.com/blog/the-secure-boot-status-report-intune
https://support.microsoft.com/en-us/topic/windows-secure-boot-certificate-expiration-and-ca-updates-7ff40d33-95dc-4c3c-8725-a9b95457578e
https://blog.mindcore.dk/2026/02/windows-secure-boot-certificate-expiration-2026/
https://scloud.work/intune-secure-boot-certificate-updates/
Dans cet article, je vais partager un dashboard Log Analytics permettant de surveiller l’état de ces certificats sur vos appareils. Vous pourrez ainsi visualiser :
- L’état du certificat sur les appareils
- L’état de mise à jour minimale du BIOS pour le certificat
- L’état de Secure Boot
- L’état du déploiement du certificat UEFICA2023
État du certificat sur les appareils
Ici, nous vérifions l’état du déploiement du certificat via la clé de registre suivante : HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\UEFICA2023Status
État de la version minimale du BIOS pour le certificat
Dans cette partie, nous vérifions le résultat de la commande suivante :
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbdefault).bytes) -match 'Windows UEFI CA 2023')Cette commande permet de vérifier si dbdefault contient le certificat Windows UEFI CA 2023.
Elle peut retourner True ou False :
- True : l’appareil dispose de la version minimale du BIOS
- False : l’appareil n’a pas la version minimale du BIOS
⚠️ Cette commande peut échouer sur certains modèles ou machines virtuelles.
État de Secure Boot
Dans cette partie, nous vérifions si Secure Boot est activé ou non.
Tâche planifiée Secure Boot
Nous vérifions ici l’état de la tâche planifiée Secure-Boot-Update.
Journaux d’événements
Nous vérifions les ID d’événements suivants dans le journal Système :
- 1801 : Mise à jour initiée, redémarrage requis
- 1808 : Mise à jour terminée avec succès
- 1795 : Erreur renvoyée par le firmware
- 1796 : Erreur enregistrée avec code d’erreur
- 1800 : Redémarrage nécessaire
- 1802 : Problème de firmware connu, mise à jour bloquée
- 1803 : Mise à jour KEK correspondante introuvable
La solution
- Création d’un script de remédiation
- Script exécuté chaque jour
- Il collecte les infos sur le poste
- Et les envoie à Log Analytics
Le dashboard
Le tableau de bord est organisé en deux onglets :
- Overview
- Details
Vous trouverez d’abord un résumé rapide de votre situation.
Premiers compteurs :
- État global du certificat Secure Boot
- État de mise à jour minimale du BIOS
- Certificat trouvé dans ActiveDB
- Certificat trouvé dans ActiveDB
- État du Secure Boot
- État de la tâche planifiée Secure Boot Update
- État du déploiement du certificat UEFICA2023
Puis :
- Modèles nécessitant une mise à jour BIOS
- Modèles avec BIOS à jour
- Modèles nécessitant une mise à jour du certificat
- Modèles avec certificat à jour
Détails
Cet onglet fournit les détails sur ce qui doit être mis à jour et sur quels appareils.
Appareils avec certificat non prêt
Nous vérifions la clé de registre UEFICA2023Status située dans : HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing
Le champ « Deployment status » correspondant à UEFICA2023Status peut être :
- Updated : Mise à jour Secure Boot CA 2023 terminée
- InProgress : Mise à jour en cours, en attente d’un redémarrage ou de l’exécution de la tâche planifiée
- NotStarted : Déploiement prévu mais non encore exécuté
Appareils en attente de redémarrage
Nous listons les appareils où :
- UEFICA2023Status = InProgress
- Dernier redémarrage > 7 jours
- Dernier event ID = 1800
Appareils nécessitant une mise à jour BIOS
Nous vérifions la valeur retournée par : (Get-SecureBootUEFI dbdefault).bytes
Deux valeurs possibles :
- True : BIOS à jour
- False : BIOS non à jour
Sources à télécharger
Cliquez sur l’image GitHub ci‑dessous pour récupérer les fichiers suivants :
Utilisation de Log Analytics v1
Cette partie concerne l’envoi de données vers Log Analytics via l’API Data Collector.
Cette API est dépréciée, mais vous pouvez encore l’utiliser pour surveiller votre certificat Secure Boot.
Pour créer ce rapport, nous aurons besoin des informations suivantes :
- Workspace ID
- Primary key
- Nom du custom log
Pour les obtenir : Log Analytics Workspace > Agents management
Vous y trouverez Workspace ID et Primary key.
Si la clé primaire n’est pas visible :
- Ouvrez Azure Portal
- Ouvrez Cloud Shell
- Exécutez :
az monitor log-analytics workspace get-shared-keys --resource-group <Your resource group> --workspace-name <Your workspace> --query "primarySharedKey"Ensuite :
- Ouvrez le fichier Detection.ps1
- Renseignez :
- $CustomerID : Workspace ID
- $ShareKey : Primary key
Utilisation de Log Analytics v2
L’API Data Collector est dépréciée. Voici comment configurer le processus Log Ingestion API.
Création de l’App Registration
Cette application servira à s’authentifier et envoyer les données à Log Analytics.
- Allez dans le portail Azure
- Allez dans App registrations
- Cliquez sur New registration
- Nommez l’application
- Laissez les valeurs par défaut
- Cliquez sur Register
- Allez dans Certificates & secrets
- Allez dans Client secrets
- Cliquez sur New client secret
- Nommez le secret
- Choisir une durée
- Cliquez sur Add
- Copiez le secret
Créer un Data Collection Endpoint
- Allez dans le portail Azure
- Allez dans Monitor
- Allez dans Data Collection Endpoints
- Cliquez sur Create
- Nommez le DCE
- Choisissez Subscription, resource group, région
- Cliquez sur Review + Create
- Une fois créé, ouvrir le DCE
- Allez dans Overview
- Copiez la valeur Logs Ingestion
Créer un custom log (DCR)
Le DCR définit la structure de la table et la manière dont les données sont envoyées.
- Allez dans Log Analytics workspace
- Allez dans Settings > Tables
- Cliquez sur Create
- Cliquez sur New custom log (DCR based)
- Nommez le : SecureBootCertificate
- Cliquez sur Create a new data collection rule
- Choisissez Subscription, resource group
- Nommez le DCR
- Sélectionnez le DCR
- Cliquez sur Next
- Cliquez sur Browse for files
- Sélectionnez SecureBootCertificate_CL.json
- Cliquez sur Next puis Create
- Ouvrir le DCR
- Allez dans Overview
- Copiez immutableId
Donner les permissions à l’application
- Ouvrir le DCR
- Allez dans Access Control (IAM)
- Cliquez sur Add role assignment
- Cherchez et ajoutez le rôle Monitoring Metrics Publisher
- Cliquez sur Next
- Cliquez sur User, group, or service principal
- Cliquez sur Select members
- Sélectionnez l’app registration
- Cliquez sur Review + assign
Créer le script de remédiation
- Allez dans Devices
- Allez dans Remediations
- Cliquez sur Create script package
- Nommez le
- Next
- Detection script file
- Pour Data Collector API : Detection.ps1
- Pour Log Ingestion API : Detection_LAv2.ps1
- Cliquez sur Next
- Sélectionnez le groupe
- Choisissez la planification
- Cliquez sur Apply
- Cliquez sur Create
Ajouter le workbook
Le rapport est disponible sur GitHub.
Fichiers disponibles :
- Log Analytics v1 : Workbook.json ou Workbook2.json
- Log Analytics v2 : Workbook_LAv2.json
Il faudra procéder comme ci-dessous :
- Allez dans Log Analytics workspace
- Allez dans votre workspace
- Allez dans Monitoring > Workbooks
- Cliquez sur New
- Cliquez sur Advanced editor
- Supprimez le contenu
- Collez le contenu du JSON
- Cliquez sur Apply
- Cliquez sur Done editing > Save