Mises à jour de l’expiration et du chargeur de démarrage de Windows Production CA 2011

S’applique à
Windows 11 Windows 10 ESU Windows 10 LTSB 2016 ESU Windows Server 2025 Windows Server 2022 Windows Server 2019 Azure

Date de publication d’origine : 22 octobre 2026
ID de la Base de connaissances : 5132953

Depuis le 19 octobre 2026, les certificats de démarrage sécurisé Microsoft émis à l’origine en 2011 ont atteint leur expiration de 15 ans. Cette expiration n’entraîne pas l’arrêt des ordinateurs et n’empêche pas le démarrage de Windows. Les appareils existants continuent de démarrer et d’exécuter Windows normalement. Pour plus d’informations sur la façon dont l’expiration du certificat affecte les appareils Windows, consultez Quand les certificats de démarrage sécurisé expirent sur les appareils Windows. Pour plus d’informations sur le calendrier plus large d’expiration des certificats de démarrage sécurisé 2026 et les autorités de remplacement, consultez Expiration du certificat de démarrage sécurisé Windows et mises à jour de l’autorité de certification.

Public cible

Cet article s’adresse aux professionnels de l’informatique, aux administrateurs d’entreprise et aux ingénieurs de déploiement qui gèrent des flottes Windows physiques, des charges de travail de serveur, des machines virtuelles et des supports d’installation.

Si vous êtes un utilisateur domestique ou personnel dont l’appareil est mis à jour automatiquement via Windows Update, vous n’avez pas besoin d’effectuer les actions décrites dans cet article. Windows Update gère automatiquement les mises à jour des certificats et des fichiers de démarrage pour les appareils personnels. Pour obtenir des conseils axés sur le consommateur, consultez Appareils Windows pour les particuliers, les entreprises et les établissements scolaires avec les mises à jour gérées par Microsoft.

Qu’est-ce qui change ?

Pour protéger les systèmes contre les programmes malveillants avant démarrage et les falsifications non autorisées, les fichiers exécutables Windows s’appuient sur des signatures numériques vérifiées à deux étapes opérationnelles distinctes :

  1. Vérification du démarrage sécurisé avant démarrage : Avant le chargement de Windows, le microprogramme UEFI vérifie la signature numérique du chargeur de démarrage Windows (tels que bootmgfw.efi et cdboot.efi) par rapport aux autorités approuvées de la base de données de signatures autorisées (DB) du microprogramme.

  2. Vérification de l’exécution du système d’exploitation Windows : Après le démarrage de Windows, le noyau du système d’exploitation et les fonctionnalités de sécurité vérifient les signatures numériques Authenticode des pilotes (.sys), des services système et des binaires d’application (.exe, .dll).

Depuis le 19 octobre 2026, le certificat Microsoft Windows Production PCA 2011 a atteint son expiration planifiée et Microsoft a transféré les deux domaines de signature vers des autorités de certification modernes :

Mises à jour du démarrage sécurisé et du chargeur de démarrage (pré-démarrage)

In-Windows système d’exploitation Signature binaire et de catalogue (runtime)

  • Transition vers des pouvoirs de signature de remplacement : Le contenu du système d’exploitation Windows (y compris les fichiers binaires avec signatures Authenticode incorporées et les composants authentifiés par le biais de catalogues de sécurité Windows signés) passe de la mise hors service de Windows Production PCA 2011 aux autorités de certification Microsoft de remplacement. Notez que les autorités de certification de signature restent susceptibles de changer à l’avenir à mesure que les normes cryptographiques et les pratiques de signature évoluent.

  • Arrêt de la signature binaire PCA 2011 : À compter du 19 octobre 2026, Microsoft ne signera plus numériquement aucun catalogue binaire ou de sécurité à l’aide du certificat PCA 2011. Les fichiers binaires existants déjà installés sur les systèmes continuent de s’exécuter normalement, mais ne recevront pas d’autres mises à jour signées avec le certificat 2011.

  • Implications du contrôle des applications et du vérificateur : Les stratégies WDAC (Custom App Control for Business), les catalogues de sécurité signés ou les outils de vérification CI/CD qui épinglent l’approbation à l’autorité PCA 2011 peuvent bloquer les fichiers binaires mis à jour. Des conseils sur l’examen des stratégies et la vérification des logiciels tiers sont décrits dans la section Considérations opérationnelles et impact potentiel .

Considérations opérationnelles et répercussions possibles

Bien que les installations Windows entièrement mises à jour prises en charge soient prises en charge sans problème, les organisations qui appliquent des stratégies de contrôle d’applications personnalisées, des pipelines de vérification de la génération ou des vérifications de certificat de signature spécifiques doivent évaluer les domaines opérationnels suivants :

Stratégies de contrôle des applications (App Control for Business / WDAC)

Si votre organisation utilise App Control for Business ou des catalogues de sécurité signés, examinez vos stratégies pour les règles qui autorisent le code signé par Microsoft par une autorité de certification, un émetteur ou une empreinte spécifique, telle que Microsoft Windows Production PCA 2011. Étant donné que les fichiers binaires et les catalogues de sécurité Windows mis à jour sont signés avec des autorités de certification de remplacement (et non le certificat PCA de 2011), les fichiers peuvent ne pas correspondre à ces règles et peuvent être bloqués lorsqu’ils sont appliqués. Notez que les autorités de certification de signature binaire restent susceptibles d’être modifiées à l’avenir :

  • Symptômes possibles : échec de l’installation des mises à jour de sécurité cumulatives, échec des services au démarrage, blocage de l’exécutable de l’application ou de DLL, et événement d’intégrité du code 3077 dans le journal des événements.

  • Agilité des certificats et changements futurs : Alors que les fichiers binaires et les catalogues de sécurité Windows mis à jour passent aux autorités de remplacement, les certificats de signature et les autorités de certification changeront à l’avenir à mesure que les normes de chiffrement progresseront. Pour cette raison, les stratégies de contrôle des applications et les catalogues de sécurité doivent éviter d’épingler à des autorités, sujets ou empreintes spécifiques, et doivent utiliser à la place des règles d’éditeur ou un héritage de stratégie bien connus qui restent compatibles à mesure que Microsoft fait tourner les certificats de signature au fil du temps.

  • Action requise : Recherchez dans votre XML de stratégie les règles de signataire qui font référence à des autorités de certification Microsoft, y compris les règles héritées d’exemples de stratégies de base. Déployez d’abord les modifications de stratégie en mode audit et examinez les résultats avant de les appliquer. Pour obtenir des étapes de révision de stratégie détaillées et des conseils sur l’écosystème, consultez Préparation de l’écosystème Windows pour la signature de code nouvelle génération.

Applications avec validation de certificat personnalisée, pipelines CI/CD et logiciels de sécurité

La plupart des applications Windows ne sont pas affectées. Les applications ne sont exposées que si elles utilisent une validation personnalisée liée à des certificats Microsoft ou à des algorithmes de signature spécifiques, ou si elles disposent d’un magasin d’approbation privé. Les organisations qui gèrent des applications Windows, des pipelines CI/CD ou des outils de sécurité tiers doivent évaluer les domaines suivants (en notant que les autorités de certification de signature binaire restent susceptibles d’être modifiées à l’avenir) :

  • Validation de certificat d’application personnalisé : Toute application ou tout service qui effectue une validation personnalisée et suppose la présence de PCA 2011, valide des chaînes de certificats spécifiques, épingle des sujets de certificat ou s’appuie sur des caractéristiques de signature fixes peut rencontrer des échecs ou rejeter des fichiers signés par Microsoft que Windows reconnaît comme approuvés. Mettez à jour la validation des applications pour utiliser les API de confiance Windows prises en charge (telles que WinVerifyTrust) plutôt que des vérifications personnalisées liées à des certificats fixes ou à des algorithmes de signature.

  • Logiciel utilisant des magasins d’approbation privés : Vérifiez que toute application, conteneur ou service qui maintient un magasin de confiance privé dispose d’un processus permettant de reconnaître les rotations de certificats Microsoft légitimes.

  • Validation de build et pipelines CI/CD : Les portes de build automatisées et les scanneurs statiques qui appliquent une liste verte statique des autorités de certification attendues peuvent signaler des échecs de vérification (tels que des erreurs d’incompatibilité de stratégie) sur les composants Windows récemment mis à jour. Mettez à jour les listes d’autorisation statiques de signataires pour reconnaître les autorités de certification Microsoft de remplacement et établissez des processus de vérification qui s’adaptent aux rotations futures des autorités de certification à mesure que les normes de signature évoluent.

  • Logiciels antivirus et de sécurité tiers : Certains produits tiers, antivirus, de protection des points de terminaison et de protection des applications inspectent directement les signatures Authenticode. Vérifiez auprès de vos fournisseurs de logiciels qu’ils ont examiné et testé la compatibilité avec les certificats de signature Microsoft de remplacement. Pour obtenir des conseils techniques pour le vérificateur, consultez Préparation de l’écosystème Windows pour la signature de code nouvelle génération.

Déploiement du support de démarrage sur du matériel plus ancien

Avec les futures versions de support de mise à jour, le support d’installation officiel passera au démarrage par défaut avec le gestionnaire de démarrage Windows UEFI CA 2023 :

  • Symptômes possibles : Le démarrage d’un support mis à jour sur un matériel physique dont le micrologiciel UEFI ne dispose pas du certificat 2023 dans sa base de données de signatures autorisées (DB) échouera avec une violation de démarrage sécurisé.

  • Action requise : Pour les anciens matériels sans BIOS OEM mis à jour qui approuve le certificat 2023, un script de réversion du support sera fourni pour configurer le support afin qu’il démarre à l’aide du chargeur de démarrage 2011 gelé.

Comportement du support de démarrage et de la configuration dans le système d’exploitation

La transition du support d’installation et de la configuration du système d’exploitation diffère entre les versions existantes de Windows et les versions futures de Windows :

Support d’installation pour les versions existantes de Windows

  • Chemin de démarrage par défaut sur le support d’installation : Les futures versions multimédias d’installation pour les versions actuellement prises en charge de Windows indexeront le gestionnaire de démarrage Windows signé en 2023 sur \EFI\Boot\bootx64.efi en tant que fichier de démarrage par défaut pour le support de démarrage.

  • Version du support pour le microprogramme plus ancien : Les packages de support d’installation des fichiers binaires de démarrage signés en 2023 et en 2011, en conservant la structure de répertoire existante sur le support et la partition système EFI (ESP) cible. Pour le matériel nécessitant des fichiers de démarrage 2011, un script de réversion du support sera fourni pour configurer le support afin qu’il démarre à l’aide du gestionnaire de démarrage 2011 gelé.

  • Comportement de la mise à niveau sur place : Lors de l’exécution d’une mise à niveau sur place, le programme d’installation de Windows inspecte la base de données de signatures autorisées (DB) du microprogramme. Si le microprogramme fait déjà confiance à l’autorité de certification UEFI de Windows 2023, le programme d’installation provisionne la partition de système EFI cible (ESP) avec le gestionnaire de démarrage signé pour 2023. Si le microprogramme approuve uniquement PCA 2011, le programme d’installation provisionne le gestionnaire de démarrage signé 2011 pour préserver la capacité de démarrage. Après la mise à niveau, la maintenance Windows standard gère les mises à jour de certificat de la base de données du microprogramme, et les mises à jour qualité suivantes transfèrent l’ESP vers le chargeur de démarrage 2023 une fois l’approbation du microprogramme établie.

  • Azure transition média Marketplace : Azure images de galerie de machines virtuelles internes et les pipelines de déploiement d’hôte s’alignent sur le calendrier des supports de démarrage par défaut de 2023.

Support d’installation pour les futures versions de Windows

  • Dans les futures versions principales client et serveur de Windows, le support d’installation ne contiendra que les fichiers binaires de démarrage signés en 2023, et les fichiers binaires de démarrage signés en 2011 seront complètement supprimés du support.

  • Exigence d’approbation du microprogramme pour les versions futures : Les futures versions majeures de Windows nécessitent le certificat Windows UEFI CA 2023 dans le microprogramme Allowed signature database (DB) to boot, installation media, and terminer l’installation de Windows.

Génération de média et scripts de secours

La gestion des médias sur différentes générations de matériel est prise en charge via les scripts suivants :

  • Mise à jour du support de niveau inférieur : Pour le support d’installation existant qui est défini par défaut sur le chargeur de démarrage de 2011, mettez à jour le support pour qu’il soit défini par défaut sur le chargeur de démarrage de 2023 à l’aide de Make2023BootableMedia.ps1. Pour les paramètres de script complets et les instructions de téléchargement, consultez Mise à jour du support de démarrage Windows pour utiliser le gestionnaire de démarrage signé PCA2023.

  • Script de réversion de support pour le microprogramme plus ancien : Lors du déploiement d’un support sur des systèmes avec un microprogramme en attente d’une mise à jour OEM pour le certificat 2023, le script de réversion de support mentionné peut configurer le support pour qu’il démarre à l’aide du chargeur de démarrage gelé 2011.

Forum aux questions

  • La mise à jour du chargeur de démarrage déclenche-t-elle la récupération BitLocker ?

    Pendant que la maintenance Windows fonctionne pour coordonner les mesures de la plateforme pendant les mises à jour, des invites de récupération BitLocker inattendues peuvent se produire en fonction de la configuration du protecteur de l’appareil, des comportements du microprogramme et de l’état du système. Les administrateurs et les propriétaires d’appareils doivent s’assurer que les clés de récupération BitLocker sont sauvegardées de manière sécurisée avant d’appliquer toute mise à jour de la chaîne de démarrage, du microprogramme ou du démarrage sécurisé, y compris les mises à jour qualité Windows mensuelles.

  • Comment les machines virtuelles sont-elles affectées dans Hyper-V, Azure et VMware ?

    Les machines virtuelles Hyper-V de génération 2 reçoivent des certificats mis à jour via des mises à jour Windows cumulatives standard. Les machines virtuelles confidentielles et Trusted Launch d’Azure reçoivent des mises à jour via la maintenance de la plateforme Azure. Pour VMware vSphere, assurez-vous que les hôtes ESXi et les versions matérielles des machines virtuelles sont mis à jour vers des versions qui incluent les certificats 2023 dans les modèles UEFI invités. Pour plus d’informations, consultez Machines virtuelles de lancement approuvé et Machines virtuelles confidentielles dans Azure.

  • Que se passe-t-il si un appareil ne reçoit jamais le certificat 2023 ?

    L’appareil continuera à démarrer à l’aide du chargeur de démarrage signé par Frozen 2011, mais il ne recevra pas de nouveaux correctifs de sécurité pour le chargeur de démarrage si de futures vulnérabilités au niveau du démarrage sont détectées. En outre, les futures versions majeures de Windows nécessiteront le certificat 2023 dans la base de données de signatures autorisées (DB) et le support d’installation bloquera l’installation sur les appareils qui n’en sont pas dotés.

Journal des modifications
Modifier la date Modifier la description
22 octobre 2026 Publication initiale couvrant l’expiration du 19 octobre 2026 Windows Production PCA 2011, le gel du chargeur de démarrage, les futures mises à jour des supports d’installation, les implications du contrôle d’application et les outils de conversion de secours.