Skip to content
Cyber Resilience & Data Security

Getting Ahead of Shrinking Certificate Lifespans and the Quantum Clock

Why automated certificate management and crypto-agility can’t wait.


Points clés à retenir

  • La durée de vie des certificats passera de 398 à 47 jours d’ici mars 2029, la « réutilisation de la validation de domaine » étant réduite à seulement 10 jours, ce qui rendra le renouvellement manuel obsolète et rendra nécessaire la gestion automatique du cycle de vie des certificats (CLM).
  • Des opérations de type « Harvest Now, Decrypt Later » (collecter maintenant, décrypter plus tard) sont déjà en cours pour stocker des données à longue durée de vie en vue d’un décryptage futur à l’aide d’ordinateurs quantiques, ce qui représente une menace immédiate pour les données sensibles chiffrées dont la durée de conservation est plus longue.
  • L’inventaire des certificats et des clés cryptographiques est un élément crucial que les entreprises doivent commencer à mettre en place dès maintenant, car un inventaire continu et automatisé constitue la première étape vers une cyber-résilience et une agilité cryptographique à long terme.

Le problème qui se cache en arrière-plan

La plupart des réseaux d’entreprise modernes s’appuient sur une couche cachée composée de certificats numériques et de cryptographie que la plupart des gens ne voient jamais. Cette couche vérifie la fiabilité des machines et sécurise les flux de données, mais comme les identités de machines dépassent désormais celles des humains dans un rapport de plus de 80 pour 1 dans une entreprise moyenne, selon l’étude de CyberArk sur les identités de machines, il est facile de sous-estimer l’importance de la couche cryptographique et des certificats.

Une façon utile d’envisager un certificat numérique est de le considérer comme un badge d’identification pour une machine. Si le badge est valide, les portes s’ouvrent automatiquement et personne n’y prête attention, mais dès que ce badge expire ou est mal configuré, la porte cesse de s’ouvrir, quelle que soit la légitimité de la machine qui se trouve derrière. Un seul certificat expiré peut mettre hors service des sites web, perturber les API qui permettent aux applications de communiquer entre elles, interrompre des transactions et entraîner des violations de conformité, tout en érodant la confiance des utilisateurs.

Pendant des années, les organisations ont géré les certificats manuellement, mais deux changements vont rendre cette gestion manuelle impossible à maintenir. Premièrement, la durée de vie maximale des certificats TLS (Transport Layer Security) publics, le protocole qui sécurise votre navigateur, va être réduite à seulement 47 jours d’ici 2029. Deuxièmement, l’arrivée prochaine d’ordinateurs quantiques suffisamment puissants pour briser le chiffrement actuel impose une transition vers la cryptographie post-quantique. Ces deux enjeux convergent vers une même solution : une approche de la gestion du cycle de vie des certificats (CLM) régie, automatisée et « crypto-agile ».

La feuille de route derrière la réduction de la durée de vie des certificats

La durée de validité des certificats TLS publics ne cesse de se réduire depuis une décennie. Début 2023, Google a publié pour la première fois sa feuille de route intitulée « Moving Forward, Together », qui proposait de réduire la durée de validité des certificats de 398 à 90 jours dans l’espoir d’inciter le secteur à s’orienter vers l’automatisation. Apple a accéléré ce calendrier en octobre 2024 en soumettant un projet de vote au CA/Browser Forum, l’organisme sectoriel au sein duquel les autorités de certification et les éditeurs de navigateurs établissent des règles communes. La proposition d’Apple, soutenue par Sectigo, Google Chrome et Mozilla, a été approuvée en avril 2025 sous la référence SC-081v3.

Cette réduction s’effectue par étapes. La durée maximale, qui était auparavant de 398 jours, est déjà passée à 200 jours en mars 2026 ; elle sera ramenée à 100 jours en mars 2027, puis finalement à 47 jours en mars 2029. Concrètement, une organisation qui renouvelle actuellement chaque certificat environ une fois par an devra bientôt renouveler tous ses certificats à peu près tous les mois et demi ; à l’étape finale, tout processus reposant sur la demande et l’installation manuelles des certificats par une personne échouera.

Les éditeurs de navigateurs prônent ces durées de vie plus courtes afin d’imposer l’automatisation, ce qui élimine l’erreur humaine à l’origine de la plupart des interruptions de service liées aux certificats. Elles permettent également à l’ensemble du Web d’adopter de nouvelles normes cryptographiques en quelques semaines plutôt qu’en plusieurs années, puisque les anciens certificats sont rapidement remplacés. De plus, elles contribuent à réduire la dépendance vis-à-vis des anciens systèmes de révocation, qui souffrent de problèmes de performances et de confidentialité. Enfin, si un journal de transparence des certificats (un registre public des certificats émis) venait à être invalidé, les certificats à courte durée de vie réduiraient considérablement le nombre de certificats devant être remplacés dans l’urgence.

Le casse-tête de la validation

Si la limite de 47 jours fait la une des journaux et retient l’attention, le changement le plus perturbateur pourrait bien concerner la validation du contrôle de domaine (DCV). La DCV est le processus consistant à prouver à une autorité de certification (CA) que vous contrôlez le domaine pour lequel vous demandez un certificat. Historiquement, une fois qu’une organisation avait prouvé sa propriété, l’AC pouvait réutiliser cette preuve pendant 398 jours maximum ; or, selon la norme SC-081v3, cette période de réutilisation sera réduite à 200 jours en 2026, puis à seulement 10 jours d’ici mars 2029.

Cela crée un réel déséquilibre, car même une organisation ayant entièrement automatisé l’installation des certificats se retrouvera bloquée si elle ne peut pas prouver à nouveau la propriété du domaine tous les 10 jours. Tout retard dans la validation interrompt l’ensemble du processus d’émission et entraîne directement des interruptions de service.

La solution pratique à ce problème consiste à adopter le protocole ACME (Automatic Certificate Management Environment) avec validation automatisée via l’API DNS-01, afin que la preuve de propriété s’effectue de manière programmatique plutôt que d’attendre l’intervention d’une personne.

La menace quantique et le calendrier

Alors que la durée de vie des certificats diminue, les algorithmes qu’ils contiennent sont confrontés à une menace quantique. Les infrastructures à clé publique (PKI) traditionnelles s’appuient sur la cryptographie asymétrique pour sécuriser les signatures numériques, les échanges de clés et les connexions TLS. Un ordinateur quantique suffisamment puissant exécutant l’algorithme de Shor pourrait complètement contourner ces systèmes. Attendre que l’informatique quantique soit suffisamment puissante pour déchiffrer n’est pas une option viable ; comme l’a écrit Vidya Shankaran, directrice technique sur le terrain chez Commvault : « La date exacte du Q-Day reste peut-être incertaine. Mais la direction prise ne l’est pas. »

Selon les estimations, le Q-Day, c’est-à-dire le moment où un ordinateur quantique pourra briser le chiffrement à clé publique, devrait survenir dans les 5 à 10 prochaines années. Cependant, ce serait une erreur de considérer cela comme un problème futur. Les acteurs malveillants mènent déjà des opérations de type « Harvest Now, Decrypt Later » (HNDL) : ils interceptent et stockent dès aujourd’hui le trafic chiffré dans l’intention de le déchiffrer une fois que l’informatique quantique aura atteint sa maturité. Les données qui doivent rester confidentielles pendant des années, telles que les dossiers médicaux, la propriété intellectuelle et les informations financières, sont de fait exposées dès le moment où elles sont collectées.

Le gouvernement fédéral américain a réagi en conséquence : en juin 2026, la Maison Blanche a publié le décret présidentiel n° 14412, intitulé « Securing the Nation Against Advanced Cryptographic Attacks » (Protéger la nation contre les attaques cryptographiques avancées), qui fixe des échéances bien en avance sur l’objectif initial du NIST pour 2035 : les systèmes fédéraux de grande valeur doivent adopter l’établissement de clés post-quantiques d’ici fin 2030 et les signatures numériques post-quantiques d’ici fin 2031.

Malgré cette urgence, les progrès réels vers une « crypto-agilité » au niveau des entreprises ont été lents. Le rapport « DigiCert Quantum Readiness Outlook » a révélé que plus de la moitié des organisations interrogées s’attendent à ce que le chiffrement asymétrique classique soit piraté d’ici cinq ans, mais que seules 7 % ont déployé une cryptographie quantique ou hybride sur l’ensemble de leur parc de certificats, et que le niveau de Readiness global n’a progressé que de 2 points de pourcentage au cours de l’année écoulée.

Pourquoi la « crypto-agilité » est-elle importante ?

Le pont le plus pratique entre la cryptographie classique et la cryptographie post-quantique est le certificat composite hybride, qui combine un algorithme classique (RSA ou ECC) avec un algorithme post-quantique (ML-DSA, le schéma de signature normalisé basé sur les treillis) au sein d’un seul certificat X.509. La combinaison des deux dans un seul certificat est conçue pour que celui-ci reste valide aussi longtemps que l’un ou l’autre des algorithmes, ce qui est essentiel, car les algorithmes post-quantiques sont récents et n’ont pas encore résisté à d’innombrables tentatives d’attaques comme l’a fait le RSA.

Cependant, les clés et signatures post-quantiques pèsent plusieurs kilo-octets plutôt que quelques centaines d’octets, ce qui augmente la latence du réseau, présente un risque de fragmentation des paquets lors de la négociation TLS et ajoute une surcharge de calcul pouvant nécessiter des mises à niveau matérielles pour les appareils aux ressources limitées. C’est précisément pour cette raison que la « crypto-agilité » est essentielle ; les organisations doivent pouvoir tester, déployer et faire tourner les algorithmes sans avoir à reconfigurer leur infrastructure sous-jacente à chaque évolution des normes.

Gestion automatisée du cycle de vie des certificats

La gestion manuelle des certificats n’est pas seulement inefficace ; c’est un véritable handicap opérationnel. Lorsque les certificats sont stockés dans des feuilles de calcul, hors de vue, les organisations perdent toute visibilité, ce qui se traduit par des identifiants périmés, des tailles de clés insuffisantes, des algorithmes de signature obsolètes et des configurations non conformes que personne ne remarque jusqu’à ce qu’un problème survienne. Les interruptions de service qui en résultent peuvent semer la confusion chez les utilisateurs, perturber le chiffre d’affaires et retomber sur l’équipe la moins préparée à les expliquer.

Une plateforme CLM complète résout ce problème tout au long du cycle de vie d’un certificat :

  • Détection : analyse continue des environnements cloud, des centres de données, des conteneurs et des domaines externes afin d’identifier tous les certificats en cours d’utilisation.
  • Surveillance : suivi en temps réel des dates d’expiration, des algorithmes, de la force des clés et de la conformité aux politiques de sécurité.
  • Validation : utilisation d’une intégration API directe avec les autorités de certification publiques et privées, tout en automatisant la validation et les validations de domaines
  • Installation : déploiement programmatique des certificats et clés renouvelés via ACME ou des API sécurisées, sans intervention manuelle.
  • Révocation : il est nécessaire d’effectuer une révocation rapide, guidée par des politiques, afin qu’un certificat compromis puisse être remplacé ou révoqué partout simultanément, plutôt que d’être recherché machine par machine.

L’étape de découverte recèle également un avantage : l’inventaire des certificats géré par une plateforme CLM constitue, en effet, le point de départ de l’inventaire cryptographique requis pour la planification de la migration post-quantique, ce qui peut transformer une corvée de conformité en une longueur d’avance.

Identités non humaines et IA agentique

Le problème d’échelle est aggravé par la manière dont les applications modernes sont conçues. Les conteneurs, les pods Kubernetes, les machines virtuelles, les appareils de l’Internet des objets (IoT) et les API ont tous besoin de leurs propres identifiants, et bon nombre de ces charges de travail n’existent que pendant quelques minutes ou quelques heures avant de prendre fin. Aucune équipe humaine ne peut émettre et retirer des certificats à une telle vitesse.

Pour suivre ce rythme effréné, des agents d’IA peuvent être utilisés pour détecter, émettre, renouveler et gérer les certificats de manière autonome, tout en restant dans le cadre des garde-fous existants tels que les politiques de sécurité, le contrôle d’accès basé sur les rôles (RBAC) et les pistes d’audit centralisées. Il en résulte une automatisation à la vitesse des machines sans renoncer à la gouvernance d’entreprise.

Par où commencer

  1. La première étape vers la « crypto-agilité » et la résilience à l’échelle de l’entreprise est d’ordre organisationnel plutôt que technique. Conformément aux recommandations du NIST, les entreprises doivent mettre en place une équipe centrale chargée des services d’identité des machines, qui gère la plateforme CLM, normalise les modèles de certificats et assure les intégrations avec les autorités de certification (CA) publiques et privées. Les responsables d’applications individuels et les équipes DevOps, quant à eux, doivent être chargés d’intégrer les renouvellements automatisés dans leurs propres pipelines de déploiement, en utilisant la plateforme centrale comme un service partagé. Cette répartition des responsabilités garantit la cohérence de la gouvernance tout en éliminant les transferts manuels qui provoquent des interruptions de service.
  2. Les organisations doivent dès à présent remplacer les techniques et workflows de validation manuels par ACME et la validation automatisée DNS-01, bien avant l’arrivée de la fenêtre de 10 jours prévue pour la validation par certificat (DCV), tout en supprimant progressivement chaque processus manuel de renouvellement et de validation.
      1. En parallèle, les organisations doivent réaliser un inventaire complet de leurs actifs cryptographiques afin d’identifier les clés codées en dur, les algorithmes obsolètes et les chemins de confiance de longue durée protégeant les données sensibles.
      2. La préparation post-quantique doit débuter dans un environnement contrôlé plutôt qu’en production. Un laboratoire de test dédié doit être mis en place pour permettre aux équipes de tester des certificats composites hybrides et des mises à niveau « crypto-agiles » dans un bac à sable. En développant des applications sur des bibliothèques cryptographiques modulaires connectées à une plateforme CLM dynamique, les entreprises peuvent acquérir une véritable « crypto-agilité » : la capacité à faire tourner les clés, les chiffrements et les algorithmes à travers leur infrastructure à mesure que les normes évoluent, sans avoir à tout reconstruire.

Le fil conducteur qui relie toutes ces recommandations est l’inventaire. L’étape de découverte d’une plateforme CLM n’est pas une simple formalité préalable à la véritable mise en œuvre ; c’est la même rigueur dont les organisations auront besoin à chaque niveau de Readiness quantique. Les certificats sont des identités non humaines, et les mêmes questions s’appliquent aux comptes de service, aux agents d’IA, aux dépendances open source et aux algorithmes enfouis dans le code des applications : que possédons-nous, que protège-t-il et quels éléments sont les plus importants pour l’entreprise ?

Les entreprises qui renforcent dès maintenant leurs capacités d’inventaire, en commençant par les certificats, trouveront le reste de la transition bien moins intimidant, car la hiérarchisation des priorités deviendra un calcul plutôt qu’une supposition. Considérer les prochaines années comme une fenêtre de planification plutôt que comme un délai de grâce aidera les entreprises à effectuer cette transition selon leurs propres conditions, au lieu de laisser une panne prendre la décision à leur place.

Caitlin Dodson est stagiaire pour l’été 2026 au sein de la division FCTO – Amériques chez Commvault.

More related posts


Thumbnail_Blog-Clumio-Chat-2026

Meet Clumio Chat: An AI Assistant to Help Evaluate Cloud-Native Data Protection

Read more about Meet Clumio Chat: An AI Assistant to Help Evaluate Cloud-Native Data Protection
Thumbnail_Blog-Clumio-Fedramp-2026

Clumio Advances Cloud-Native Cyber Resilience with FedRAMP® Milestone

Read more about Clumio Advances Cloud-Native Cyber Resilience with FedRAMP® Milestone
Thumbnail_Blog-Lateral-Access-2026

Private Cloud Data Security Technical Guide

Read more about Private Cloud Data Security Technical Guide