Microsoft répond aux questions clés alors que l'échéance de Secure Boot approche
Avec l'expiration prévue du certificat original Microsoft Secure Boot KEK le 24 juin 2026, Microsoft a organisé sa deuxième session en direct « Ask Microsoft Anything » (AMA) le 4 juin pour répondre aux préoccupations restantes des administrateurs IT et des clients d'entreprise. Cette session a offert des informations approfondies sur les mises à jour de Secure Boot, abordant les déploiements en entreprise, la compatibilité des machines virtuelles, les scénarios de démarrage PXE et bien plus encore.
Qu'est-ce qui change le 24 juin 2026 ?
La question la plus pressante était de savoir si le 24 juin marquait une fin définitive pour le certificat Secure Boot KEK CA 2011. Selon Scott Shell, cette date d'expiration ne constitue pas une échéance stricte qui met fin à toutes les fonctionnalités. L'expiration de la clé KEK n'affecte pas immédiatement le processus de déploiement manuel basé sur le registre ou les charges de mise à jour existantes, qui continueront de fonctionner comme auparavant.
Cependant, après le 24 juin, Microsoft perdra la capacité de signer de nouvelles charges DBX, essentielles pour révoquer les chargeurs d'amorçage compromis. Les appareils sans certificat KEK mis à jour pourraient manquer de futures révocations, devenant potentiellement moins sécurisés avec le temps. Le certificat DB, cependant, reste valide jusqu'en octobre, permettant à Microsoft de signer des gestionnaires de démarrage supplémentaires pendant cette période intermédiaire.
La mise à jour de juin élargit la couverture à haute confiance
La mise à jour du patch Tuesday de juin classera la grande majorité des appareils grand public comme étant de haute confiance, sur la base des données de diagnostic de Microsoft. Kevin Sullivan a précisé que la classification des appareils va au-delà des noms de fabricants et de modèles pour inclure la version et la date du firmware. Cela signifie que même des modèles identiques pourraient être classés différemment en fonction de leur firmware.
Pour aider les administrateurs IT, le rapport de surveillance Intune fournit une vue détaillée de l'état des appareils, y compris la classification de haute confiance, le statut d'application des mises à jour et les appareils nécessitant une intervention manuelle. Le rapport est complété par un script PowerShell de remédiation pour une flexibilité supplémentaire.
Gestion des appareils en statut « temporairement en pause »
Certains clients d'entreprise ont signalé des appareils bloqués dans un statut « temporairement en pause ». Microsoft a expliqué que cela se produit lorsque des problèmes de compatibilité au niveau du firmware rendent les mises à jour risquées. Dans de tels cas, une mise à jour du firmware OEM est nécessaire pour résoudre le problème. Une fois le firmware mis à jour, l'appareil passe dans une nouvelle catégorie de classification.
Les administrateurs doivent utiliser les données en direct d'Intune ou le fichier CSV GitHub pour suivre précisément le statut des appareils, car les catégories en pause ne se mettent pas à jour rétroactivement. La page d'accueil Secure Boot de Microsoft inclut des liens vers les pages de support des OEM pour localiser les mises à jour de firmware.
Conseils pour les déploiements manuels
Pour les appareils qui ne sont pas dans la catégorie de haute confiance, Microsoft a déconseillé d'attendre une classification automatique. Les administrateurs devraient initier des déploiements manuels en définissant des valeurs de registre ou en utilisant les paramètres de politique Intune. Le flux de travail recommandé comprend :
- Extraire le rapport de surveillance Intune pour identifier les appareils non mis à jour.
- Tester le processus de mise à jour sur des appareils représentatifs pour chaque modèle ou variante de firmware.
- Étendre progressivement le déploiement après des tests réussis.
Microsoft a souligné que les mises à jour manuelles contribuent à enrichir les données de télémétrie, améliorant le système pour d'autres organisations ayant des appareils similaires.
Appareils avec Secure Boot désactivé
Pour les appareils avec Secure Boot désactivé, les mises à jour des certificats ne peuvent pas être appliquées. Si Secure Boot est réactivé ultérieurement, des incompatibilités entre les bases de confiance du firmware et les signatures des gestionnaires de démarrage peuvent entraîner des échecs de démarrage. La récupération nécessite une installation manuelle du certificat 2023 dans le firmware.
Les machines virtuelles Azure Gen 2 avec démarrage sécurisé ou de confiance activé disposent déjà du certificat 2023, tandis que les machines virtuelles Gen 1 ne sont pas compatibles avec Secure Boot.
Critères de classification à haute confiance
Les appareils plus anciens atteignent souvent une classification à haute confiance plus rapidement que les plus récents, car leur population plus restreinte permet une validation statistique plus rapide. Pour les modèles récents largement déployés, la mise à jour de juin devrait considérablement élargir la catégorie de haute confiance.
Les environnements de démarrage PXE nécessitent une gestion minutieuse
Pour les environnements de démarrage PXE, les appareils avec le certificat 2011 continueront de démarrer tant que le certificat n'est pas révoqué dans la liste DBX. Cependant, la transition vers des chargeurs d'amorçage signés avec le certificat 2023 nécessite de s'assurer que tous les appareils de l'environnement font confiance au nouveau certificat. Pendant la transition, il est recommandé de maintenir des supports de démarrage signés par les deux certificats.
Windows 10 et les versions plus anciennes des systèmes d'exploitation
Le mécanisme de mise à jour Secure Boot est identique sur Windows 10 (sous ESU), Windows 11 et les versions de serveur plus anciennes. Cependant, les appareils plus anciens peuvent manquer de données de télémétrie, rendant les mises à jour manuelles nécessaires.
Outils de diagnostic et ressources
Les journaux d'événements, en particulier le journal TPM-WMI, sont essentiels pour diagnostiquer les problèmes de Secure Boot. Les principaux indicateurs incluent :
- L'erreur 1803 pour les clés de plateforme invalides ou non signées.
- La vérification des certificats KEK et DB pour les versions 2023.
La ressource centrale de Microsoft, aka.ms/GetSecureBoot, fournit un guide complet, des scripts de diagnostic et des liens vers les firmwares OEM. Les administrateurs sont encouragés à suivre le conseil de Microsoft « tester d'abord un appareil » pour garantir des mises à jour fluides.
En résumé, le déploiement progressif et les outils de diagnostic de Microsoft sont conçus pour minimiser les perturbations tout en assurant la conformité à Secure Boot. Les administrateurs IT sont encouragés à agir rapidement pour éviter les risques potentiels liés à la sécurité à l'approche de l'échéance d'expiration de KEK.
