L'essentiel à retenir
- Apple impose des durées de vie de certificats de 200 jours à partir de fin mars 2026, et Amazon émet déjà des certificats de 198 jours. D'ici 2029, elles passeront à 47 jours.
- 81 % des pannes liées aux certificats restent causées par des certificats expirés ou mal configurés. Des durées de vie plus courtes multiplient ce risque.
- 60 % des entreprises exploitent leurs propres autorités de certification (AC) internes, et une grande entreprise moyenne utilise plus de 140 000 certificats internes. La plupart n'ont qu'une supervision centrale minimale.
- La menace « Harvest Now, Decrypt Later » liée à l'informatique quantique impose aux organisations de déployer dès maintenant du TLS hybride (associant ECDHE classique et ML-KEM).
- Les organisations ont besoin d'un inventaire de certificats en temps réel, multi-sources, couvrant l'infrastructure publique et privée, pour suivre le rythme de ces changements.
Les durées de vie des certificats raccourcissent vite
Les changements sont déjà là. Apple impose une durée de vie maximale de 200 jours pour les certificats à partir de fin mars 2026. Amazon a elle aussi commencé à émettre des certificats de 198 jours. Si votre parc compte des certificats de ces fournisseurs, le nombre de certificats dans votre environnement va au moins doubler cette année.
Et ce n'est que le début. En 2027, les durées de vie passent à 100 jours. En 2029, elles atteignent 47 jours.
Voici le calcul qui compte : une durée de vie de 47 jours signifie environ huit fois plus de renouvellements de certificats par an qu'aujourd'hui. Si vous avez actuellement 1 000 certificats publics, vous gérerez 8 000 renouvellements par an d'ici 2029.
Avec ce volume, le renouvellement manuel devient impossible. Mais comme l'a souligné Billy McDiarmid pendant le webinaire, l'automatisation seule ne suffit pas non plus.
« Nous en parlons avec nos clients tous les jours », a déclaré McDiarmid. « Ils viennent nous voir en pensant que tout était automatisé. Puis l'automatisation a échoué dans une partie de leur parc, ou un certificat tiers dont dépendait l'un de leurs services a expiré. »
La fenêtre de remplacement raccourcit aussi. La bonne pratique consistait à commencer la rotation des certificats 30 jours avant l'expiration. Avec des durées de vie plus courtes, vous pourriez n'avoir qu'une fenêtre de sept jours. Il reste donc bien moins de temps pour repérer et corriger une automatisation défaillante.
Et les enjeux sont réels : 81 % des pannes liées aux certificats restent causées par des certificats expirés ou mal configurés. C'est déjà l'une des principales causes d'indisponibilité. Des durées de vie plus courtes, sans les bons outils, aggraveront la situation.
La PKI privée est l'angle mort que vous ignorez probablement
La PKI publique (les certificats qui sécurisent votre site web, vos API publiques et vos domaines externes) concentre l'essentiel de l'attention. Il existe un écosystème bien établi d'AC, d'application des règles par les navigateurs, de journaux de transparence des certificats (CT) et d'exigences de conformité qui maintiennent la PKI publique relativement bien gérée.
La PKI privée, c'est une autre histoire.
Les certificats internes qui sécurisent vos serveurs, VPN, pipelines DevOps, appareils IoT et API internes sont souvent émis par des AC privées internes comme Microsoft Active Directory Certificate Services (ADCS), avec une supervision centrale minimale. Les durées de vie sont fréquemment fixées à plusieurs années, parfois même plusieurs décennies. Il n'y a généralement aucune surveillance externe. Et quand quelque chose tourne mal (une expiration inattendue, une racine compromise, une intermédiaire mal configurée), l'impact peut être grave et difficile à diagnostiquer.
Les chiffres parlent d'eux-mêmes. 60 % des entreprises exploitent leurs propres AC internes. Une grande entreprise utilise en moyenne plus de 140 000 certificats internes. Et 57 % des organisations intègrent désormais le zero trust à leur stratégie de chiffrement, ce qui rend la PKI privée encore plus centrale dans leur fonctionnement.
Le zero trust repose sur un principe simple : ne jamais faire confiance, toujours vérifier. Chaque service reçoit un certificat unique. Chaque connexion utilise le TLS mutuel (mTLS), ce qui signifie que les deux parties doivent présenter un certificat valide signé par une AC de confiance. L'accès est piloté par des politiques, pas par l'emplacement.
La PKI privée rend tout cela possible à grande échelle. Elle donne à chaque service, appareil et utilisateur une identité cryptographique forte. Mais comme le zero trust favorise des certificats de courte durée, renouvelés automatiquement, le volume et la cadence des opérations sur les certificats ne vont qu'augmenter.
Et les conséquences d'une défaillance de la PKI privée dépassent la panne d'un site web. Quand des certificats privés expirent ou cessent de fonctionner, ils peuvent paralyser des lignes de production, des systèmes de technologie opérationnelle (OT) et des services internes dont votre activité dépend. Comme l'a résumé McDiarmid : « Nous ne parlons plus seulement d'un site web en panne ou d'une API qui ne répond pas. Nous parlons de la fabrication de produits qui s'arrête. »
Cryptographie post-quantique : commencez la migration maintenant
La préparation à la cryptographie post-quantique (PQC) ressemble à un problème d'avenir. Les échéances réglementaires pour la migration complète se situent autour de 2030 à 2033. Mais la préparation demande un effort considérable, et une menace exige d'agir dès maintenant.
Lorsqu'un ordinateur quantique cryptographiquement pertinent (CRQC) verra le jour, il cassera la cryptographie à clé publique largement déployée aujourd'hui, y compris RSA et la cryptographie à courbes elliptiques (ECC), pratiquement du jour au lendemain.
La préoccupation immédiate s'appelle « Harvest Now, Decrypt Later ». Des attaquants peuvent dès aujourd'hui capturer des données chiffrées (votre trafic TLS, vos tunnels VPN) et les stocker. Dès qu'un CRQC existera, ils pourront déchiffrer tout ce qu'ils ont collecté. Pour les organisations qui manipulent des données sensibles à longue durée de vie, c'est un risque actuel, pas futur.
Bhushan Lokhande, de Red Sift, a présenté trois étapes pour se préparer à la PQC.
- Étape un : connaître votre situation. On ne protège pas ce qu'on ne voit pas. Constituez un inventaire complet et toujours à jour de vos actifs cryptographiques, sur l'infrastructure publique comme sur l'infrastructure privée interne. Chaque domaine, sous-domaine, certificat et point de terminaison réseau.
- Étape deux : repérer vos maillons faibles. Quels systèmes utilisent des algorithmes que les ordinateurs quantiques casseront ? Il faut pour cela retrouver tous les déploiements RSA et ECC. Vous cherchez aussi les systèmes dépourvus d'agilité cryptographique (ceux qui ne peuvent pas passer à de nouveaux algorithmes sans refonte importante).
- Étape trois : planifier la migration. Tout n'a pas besoin de basculer en même temps. Priorisez les données à longue durée de vie et les systèmes à haut risque, car ce sont eux qui présentent la plus grande exposition au risque « Harvest Now, Decrypt Later ».
La migration comporte deux volets distincts. Côté échange de clés, l'action la plus urgente est de déployer du TLS hybride, en associant ECDHE classique et ML-KEM (anciennement connu sous le nom de Kyber). Cela répond directement au risque « Harvest Now, Decrypt Later » tout en préservant la rétrocompatibilité. Cloudflare, Google et les principaux éditeurs de navigateurs déploient déjà l'échange de clés hybride à grande échelle. Côté signatures numériques, les organisations devraient introduire progressivement les algorithmes post-quantiques standardisés par le NIST, comme ML-DSA et SLH-DSA, à mesure que l'écosystème mûrit.
La préparation à la PQC n'est pas un événement ponctuel. C'est un processus de migration, et vous devriez commencer immédiatement.
Ce que tout cela implique : il vous faut un inventaire de certificats en temps réel
Ces trois évolutions mènent à la même exigence de fond. Il vous faut un inventaire complet et mis à jour en continu de chaque certificat de votre parc, public et privé, dès son émission.
Les tableurs ne suffisent plus. Les analyses quotidiennes non plus. Il faut une ingestion en temps réel des certificats depuis plusieurs sources de découverte : découverte par nom d'hôte, analyse réseau, journaux de transparence des certificats, intégrations avec les fournisseurs cloud et agents sur l'infrastructure privée.
La plupart des organisations sous-estiment aussi la dispersion de leurs autorités de certification. McDiarmid a partagé pendant le webinaire une observation éclairante : la plupart des prospects que Red Sift intègre découvrent des certificats émis par 10 ou 11 autorités de certification différentes, plus des certificats auto-signés, et ce n'est que l'empreinte publique, avant même de regarder à l'intérieur du réseau.
Il vous faut aussi de la visibilité sur votre posture cryptographique : quels points de terminaison prennent en charge un échange de clés résistant au quantique, quels certificats utilisent des algorithmes vulnérables au quantique, et où en est votre parc face aux changements de durée de vie à venir.
Un outil de CLM (Certificate Lifecycle Management) gère l'émission et le renouvellement. Mais en 2026, il vous faut en plus une assurance qui s'ajoute à votre CLM : une solution qui se déploie en quelques minutes, détecte en continu et en temps réel, corrèle les données de certificats avec les journaux CT et le DNS, et couvre les deux côtés du réseau.
Voir la solution en action
Red Sift Certificates assure la surveillance de l'infrastructure publique et privée dans une vue unique, avec des tableaux de bord dédiés à la préparation PQC et à la conformité du cycle de vie des certificats. L'agent PKI privée de la plateforme découvre les certificats dans l'infrastructure interne et les intègre au même inventaire que vos certificats publics.
Parmi les nouvelles capacités prévues en 2026 figurent une intégration ADCS (prévue au T2), une intégration HashiCorp Vault plus tard dans l'année, et un accès MCP (Model Context Protocol) pour que les équipes puissent interroger leur parc de certificats avec l'IA.
Envie de voir où en est votre parc ? Vérifiez la posture de sécurité de votre domaine avec Red Sift Radar Lite pour une évaluation gratuite, ou demandez une démo de Red Sift Certificates pour obtenir une visibilité complète sur votre infrastructure de certificats publique et privée.
