Contenu

1. Introduction: trois révolutions qui transforment la gestion des PKI

2. Les défis en détail: durée de vie plus courte, wildcard & multidomaine, PKI privée et MS AD CS, complexité SaaS, PQC et souveraineté numérique

3. Les trois piliers de la gestion des certificats en 2026

4. Relever le défi de la souveraineté numérique

5. Exigences élevées: modernisation de votre PKI pour 2026

6. Conclusion et résumé

1. Trois bouleversements dans le monde de la PKI

Trois transformations simultanées vont toucher votre infrastructure PKI en 2026. Elles vous posent des défis urgents, affectent votre PKI dans son ensemble et vous obligent à la repenser fondamentalement.

Premièrement, un défi urgent: la réduction de la durée de validité des certificats

Après le 15 mars 2029, les certificats TLS expireront tous les 47 jours. Les renouvellements seront donc huit à neuf fois plus fréquents et il y aura huit fois plus de certificats à échanger sur différents endpoints. Pour les organisations qui gèrent des centaines de certificats publics, ce n'est pas seulement inconfortable, c'est un risque opérationnel existentiel.

En avril 2025, le CA/Browser Forum a adopté la proposition SC-081v3 impliquant un calendrier contraignant:

• À compter du 15 mars 2026: validité maximale de 200 jours

• À compter du 15 mars 2027: validité maximale de 100 jours

• À compter du 15 mars 2029: validité maximale de 47 jours

Pour plus d'informations à ce sujet, consultez notre article de blog sur la réduction des durées.

Parallèlement, les délais de réutilisation sont également considérablement raccourcis: Après le 15 mars 2029, les données de validation de domaine ne sont désormais valables que 10 jours (au lieu de 398 jours auparavant), et les informations sur le titulaire de l'OV 398 jours (au lieu de 825 jours).

Deuxièmement, un défi large: l'explosion du nombre de certificats

De plus en plus d'appareils, d'applications et de services nécessitent des certificats publics, et surtout privés. DevOps et l'expansion du cloud démultiplient les cas d'application PKI privés. Dans les entreprises types, les identités machines sont désormais plus nombreuses que les identités humaines dans un rapport de 45:1 (Gartner, 2024). Dans les environnements cloud natifs, le rapport est encore plus extrême. L'adoption de l'IA et l'automatisation accentuent l'écart.

Troisièmement, un défi fondamental: la migration vers la cryptographie post-quantique

La NIST IR 8547 de novembre 2024 indique qu'à partir de 2030, les algorithmes de chiffrement classiques RSA et ECDSA seront considérés comme obsolètes. À partir de 2035, ils seront totalement interdits, y compris pour les certificats privés à durée longue de 5 à 10 ans.

L'enjeu

Aujourd'hui déjà, de nombreux cas d'incidents dans lesquels des services sont interrompus après avoir perdu leur protection par chiffrement sont relayés, non sans entraîner de sérieux dommages commerciaux et de réputation pour les organisations en charge. Un sondage mené auprès de la clientèle SwissSign MPKI dans la région DACH en 2025 a révélé que 74% des grandes organisations employant plus de 500 personnes ont connu des interruptions de service au cours des cinq dernières années en raison de certificats échus. Les grands bouleversements à venir augmentent encore considérablement le risque de défaillances de ce type:

• Le 31 juillet 2024, la Bank of England a subi une panne de 91 minutes de son système de paiement CHAPS à cause d'un certificat expiré. Or, le système traite chaque jour plus de 360 milliards de livres sterling. En février 2025, un autre incident de 24 minutes lié à un certificat s'est produit.

• En septembre 2024, Alaska Airlines s'est vu contrainte de rester au sol à Seattle en raison d'une panne informatique due à l'expiration d'un certificat.

• SpaceX Starlink a subi, en avril 2023, une panne mondiale de satellites causée par l'expiration d'un certificat à la station de base.

• En février 2020, 20 millions d'utilisateurs ont tenté en vain d'accéder à Microsoft Teams pendant trois heures. En cause: un certificat d'authentification échu.

Risques aggravés pour la sécurité

Outre des pertes commerciales et des crises de confiance, les certificats oubliés ou mal gérés ouvrent d'importantes failles de sécurité dans lesquelles les escrocs s'empressent de s'engouffrer. Les certificats expirés ou mal configurés exposent les organisations à l'escroquerie et à l'accès non autorisé à des systèmes sensibles.

• Le vol de données dont a été victime Equifax en 2017 n'a pas été détecté pendant 76 jours, car un certificat expiré avait désactivé l'inspection du trafic. Une fois que le certificat a été renouvelé et que les administrateurs ont remarqué l'effraction, les escrocs avaient déjà exfiltré 147 millions d'enregistrements de données personnelles contenant des numéros de sécurité sociale, des dates de naissance, des adresses et certaines données relatives à des cartes de crédit.

Avec les trois défis mentionnés, la probabilité de telles attaques augmentera nettement ces prochaines années.

2. Les défis

2.1 Pourquoi la gestion PKI traditionnelle est vouée à l'échec

Les effets du raccourcissement de la durée de validité

Les raisons du changement: Les durées de validité plus courtes réduisent la fenêtre durant laquelle les clés compromises peuvent être utilisées de manière abusive. La révocation rapide devient moins critique, puisque les certificats expirent d'eux-mêmes. L'automatisation forcée améliore la situation globale en matière de sécurité pour une organisation et augmente également l'agilité en termes de changement de certificats, nécessaire pour doter l'infrastructure et le réseau de nouveaux algorithmes de chiffrement quantiquement sûr («crypto-agilité»).

Ce qui en découle au plan opérationnel: Avec une durée de 47 jours, le nombre de renouvellements quotidiens est multiplié par huit, ce qui est impossible à mettre en œuvre si le processus est manuel.

Sans compter que les organisations doivent aussi revalider la propriété de leurs domaines tous les dix jours. Le CA/Browser Forum a toutefois pris en considération ce problème: la proposition SC-088v3 introduit une nouvelle méthode dite Persistent DCV. Les propriétaires de domaines peuvent définir un enregistrement TXT DNS unique restant valable sur plusieurs émissions de certificats et validée en continu par l'autorité de certification. SwissSign informera sur la nouvelle méthode dans sa CA/B Update Newsletter dès que tout sera prêt.

La branche n'est pas encore prête: Un sondage de SwissSign montre que 90% des organisations employant plus de 500 personnes gèrent encore les certificats, du moins en partie, manuellement. Plus de la moitié d'entre elles ont réfléchi à la manière de se préparer au raccourcissement de la durée de validité ou ont d'ores et déjà procédé à une planification concrète. Seule une organisation sur deux balaie régulièrement le réseau à la recherche de certificats.

Le cas des certificats wildcard et multi-domaines

Pourquoi les certificats wildcard et multi-domaines ne se prêtent pas à l'automatisation: Pour en faciliter l'exploitation et économiser des frais, de nombreuses organisations sécurisent aujourd'hui différents endpoints de domaine via un certificat wildcard: il suffit de renouveler un seul certificat et il n'est pas nécessaire d'avoir plusieurs certificats de domaine unique.

Aujourd'hui déjà, cette stratégie comporte des risques de sécurité: si un certificat wildcard est compromis, toutes les applications associées sont menacées. Il en va de même pour les certificats multi-domaines qui posent en outre le problème BygoneSSL: si un seul domaine change de propriétaire, le nouveau propriétaire peut faire révoquer l'ensemble du certificat, paralysant ainsi tous les autres domaines.

À l'avenir, il faudra également tenir compte du fait que le renouvellement automatisé ne peut en principe pas être réalisé avec des certificats Wildcard, car les protocoles d'automatisation tels que ACME ne fonctionnent que par domaine – l'automatisation nécessite donc des certificats dédiés par point terminal. Les certificats Wildcard nécessitent en outre une validation DNS-01 avec accès API au fournisseur DNS, tandis que les certificats à domaine unique peuvent utiliser la validation HTTP-01, plus simple.

Nous recommandons donc aux organisations de n'utiliser les wildcards que pour des raisons et des applications spécifiques:

• Pour le DNS dynamique: si vous créez et supprimez constamment de nouveaux sous-domaines, par exemple pour des environnements de développement ou des sandbox clients

• Load Balancer et Reverse Proxies: un wildcard sur votre proxy périphérique n'augmente pas considérablement le rayon d'action – une compromission du proxy signifie de toute façon l'accès à tous les sous-domaines

• Pour des raisons de sécurité: si les différents sous-domaines inclus ne doivent pas être immédiatement visibles par le public, car les wildcards les masquent dans les CT-logs publics

Le défi croissant de la PKI privée

Chaque jour de nouveaux cas d'application: La PKI privée bénéficie d'une grande flexibilité, car ses certificats n'étant pas soumis aux règles du CA/Browser Forum, ils ne peuvent pas être utilisés pour la hiérarchie de confiance publique d'Internet. Les certificats privés, émis sur la base d'un certificat racine propre à l'organisation, sont nécessaires tant pour l'authentification WiFi et VPN des utilisateurs et des appareils que pour l'authentification des utilisateurs Microsoft AD, Citrix et NetScaler pour VDI, Intune pour MDM et la gestion des appareils, l'authentification des appareils IdO, les serveurs internes sans accès public, les charges de travail des conteneurs et Kubernetes ainsi que le Service Mesh avec mTLS.

De l'importance de la gouvernance sur ce point aussi: Les défaillances de certificats privés ne font pas les gros titres, mais elles paralysent les systèmes internes critiques en cas de mauvaise gestion. Lorsque des équipes mettent en place leurs propres AC sans visibilité centrale, cela donne lieu à des PKI fantômes. De plus, l'absence de traçabilité d'audit crée des angles morts dans la compliance. La révocation manuelle des certificats, nécessaire lors du départ de membres du personnel ou de la mise hors service d'appareils, est source d'erreurs et risque d'ouvrir des failles de sécurité. L'agilité DevOps peut avoir pour conséquence que des certificats ne soient pas gérés ou révoqués à temps et que des risques de sécurité en découlent.

Microsoft AD CS: toujours indispensable, mais pas suffisant

Situation actuelle: En novembre 2025, Microsoft a intégré la prise en charge PQC (ML-KEM, ML-DSA) dans Windows Server 2025 et dans Windows 11 via l'API CNG. La prise en charge PQC est annoncée pour début 2026 (source) pour ce qui est des Active Directory Certificate Services (ADCS).

Avantages d'AD CS pour la PKI des groupes: Un sondage de SwissSign montre que 80% des grandes organisations de l'espace suisse utilisent AD CS pour leur PKI privée. AD CS offre une intégration Windows native avec enregistrement automatique basé sur les directives de groupe. Il est profondément intégré dans les environnements d'entreprise Windows et se prête parfaitement à la mise à disposition de certificats centrée sur Windows. Le système est au point et les administrateurs Windows le connaissent bien.

Potentiel d'extension d'AD CS pour les groupes: AD CS émet des certificats, mais ne suit pas l'inventaire, la propriété ou le cycle de vie des certificats privés sur l'ensemble de l'infrastructure cliente. L'intégration avec Linux, les conteneurs et les charges de travail cloud est faible. Après des fusions et des acquisitions, il manque la capacité de consolider la visibilité sur plusieurs CA. Les protocoles modernes comme ACME et EST requièrent des outils supplémentaires. S'agissant de cryptographie post-quantique, les mises à jour de schémas sont utiles, mais le changement d'algorithme exige une visibilité qu'AD CS n'offre pas. La ségrégation des droits est très complexe à mettre en place.

La réalité: AD CS ne disparaîtra pas. Les organisations ont toutefois besoin de systèmes supplémentaires comme CLM pour gérer les certificats AD CS conjointement à des certificats publics, des charges de travail cloud et des environnements multi-fournisseurs.

Le mappage de certificat fort (Microsoft KB5014754) qui s'est imposé en février 2025 a ajouté une charge de configuration supplémentaire pour laquelle CLM peut s'avérer utile. Les certificats émis via Intune SCEP/PKCS ou des modèles hors ligne nécessitent désormais des extensions SID. Les organisations qui utilisent encore d'anciennes configurations font face à des erreurs lors de la procédure d'authentification VPN, WiFi et d'appareil.

Propriété décentralisée et complexité SaaS

Situation d'entreprise:L'équipe IT Operations établit des certificats pour l’infrastructure tandis que l'équipe DevOps établis les certificats des applications. Certaines unités d’affaires émettent également leurs certificats pour leurs propres applications. Il n’y a dès lors aucun inventaire central ni aucune directive uniforme, alors même que l’équipe en charge de la sécurité pense que tout est entre ses mains.

La problématique du certificat SaaS: Surveillez les certificats utilisés par votre fournisseur SaaS, y compris ceux exploités par les différents services, afin de vous assurer que les systèmes SaaS critiques restent disponibles. Même si les prestataires sont considérés comme responsables, c'est vous qui accusez les pertes d'affaires ou de confiance en cas de problème.

Les domaines personnalisés que vous avez configurés sur des plateformes SaaS nécessitent en outre des certificats que vous gérez. Les certificats d'intégration API pour l'authentification auprès des services cloud relèvent également de votre responsabilité. Il en va de même pour les certificats mTLS pour l'échange sécurisé de données avec des plateformes externes.

Ces certificats se trouvent en dehors de votre infrastructure de base, mais peuvent néanmoins entraîner des pannes lorsqu'ils expirent. CLM devrait également repérer et suivre ces certificats d'intégration, et pas seulement l'infrastructure interne, le tout de manière automatisée et sans charge de travail supplémentaire pour l'équipe en charge de la sécurité.

2.2 Cryptographie post-quantique: l'échéance approche

La difficulté

Les algorithmes de chiffrement actuels comme RSA et ECDSA ne peuvent pas être déchiffrés avec des ordinateurs classiques. Les ordinateurs quantiques y parviendront. Les attaques «Harvest now, decrypt later» ont déjà lieu aujourd'hui: elles consistent à stocker des données chiffrées en vue d'un futur déchiffrement. De plus, les nouveaux algorithmes nécessitent des clés et des signatures nettement plus longues.

Répercussions sur l'infrastructure: De nombreux appareils plus anciens, l'IdO et l'équipement réseau ne pourront peut-être pas supporter ces certificats plus imposants. Des mises à jour du microprogramme sur l'ensemble de l'infrastructure s'imposeront. S'agissant d'opérations nécessitant un grand nombre de certificats, c'est même la bande passante réseau qui est remise en question. Les certificats avec les nouveaux algorithmes doivent faire l'objet de tests sur l'ensemble de l'infrastructure avant leur utilisation en mode productif.

Calendrier selon NIST IR 8547 de novembre 2024: À partir de 2030, les RSA, ECDSA, EdDSA, DH et ECDH au niveau de sécurité de 112 bits seront considérés comme obsolètes. C'est le NIST américain qui l'affirme, mais cela constituera pratiquement une norme industrielle mondiale. «Obsolète» signifiant qu'il faut en cesser l'utilisation et démarrer la migration alors qu'ils restent autorisés au plan technique. Cela s'applique aux signatures numériques selon FIPS 186 et à l'établissement des clés selon SP 800-56B.

À partir de 2035, ces algorithmes seront totalement interdits. Tous les certificats RSA doivent être remplacés, y compris ceux des certificats privés d'une durée de 5 à 10 ans.

Suite attendue des opérations: Le consensus sectoriel: Gartner recommande de considérer 2029 comme une date butoir dans la pratique afin d'éviter les risques de sécurité et les problèmes opérationnels.

Tous les certificats doivent être migrés vers des algorithmes quantiques tels que ML-KEM, ML-DSA et SLH-DSA. Cela nécessite le remplacement de chaque certificat de votre infrastructure. Les anciens systèmes doivent être testés avec de nouveaux algorithmes, en particulier en ce qui concerne la bande passante et la compatibilité des microprogrammes. Disposer d'un inventaire des certificats est une condition sine qua non dans la planification de la migration. La migration elle-même prendra des années, non pas des mois.

Pourquoi la compatibilité PQC commence par la modernisation de la PKI: La cryptographie post-quantique n'est pas une chimère sur un horizon lointain, mais un projet de migration de 2 à 3 ans qui nécessite les mêmes compétences que la gestion de certificats à courte durée de validité:

• Inventaire transparent: il n'est pas possible de migrer des certificats dont on ne connaît pas l'existence.

• Mise à disposition automatisée: le déploiement PQC manuel de plus de 250 certificats est impossible.

• Application stricte de lignes directrices: les certificats hybrides avec des algorithmes classiques et PQC doivent fonctionner en parallèle pendant la phase de transition, ce qui nécessite des règles claires.

• Agilité algorithmique: l'infrastructure doit prendre en charge simultanément plusieurs algorithmes de chiffrement.

• Tests à grande échelle: les certificats PQC doivent être validés afin de ne pas endommager les applications avant leur mise en production.

Conclusion: les organisations qui relèvent aujourd'hui les défis du raccourcissement des délais de validité maîtriseront la migration PQC de demain. Celles qui ne le font pas devront faire face à deux crises simultanées.

2.3 Le défi de la souveraineté numérique

Exigences SRI 2 à l'adresse des AC en tant que maillon critique de la chaîne d'approvisionnement

La directive de l'union européenne sur la sécurisation des réseaux et des systèmes d'information (SRI 2) considère les autorités de certification comme un maillon critique de la chaîne d'approvisionnement:

Les organisations sont légalement tenues d'évaluer les «points faibles spécifiques de chaque fournisseur direct». Le recours à une autorité de certification américaine doit explicitement tenir compte de la compétence juridique non-européenne. S'agissant d'infrastructures critiques dans les domaines de l'énergie, des transports, de la santé et du secteur public, le principe suivant s'applique: toute révocation de certificats ou divulgation de données clients sur la base de la législation américaine peut donner lieu à des amendes de l'UE. La Commission encourage les infrastructures critiques à faire appel à des prestataires de services de confiance qualifiés par l'UE (Qualified Trust Service Providers, QTSP) et se réserve le droit d'imposer des QTSP pour certains secteurs à l'avenir.

Exigences DORA pour le secteur financier

Plus strict, le Règlement européen sur la résilience opérationnelle numérique (Digital Operational Resilience Act, DORA) applicable aux établissements financiers européens depuis janvier 2025 traite les AC comme des «prestataires TIC tiers».

Les entreprises financières doivent tenir un registre détaillé de tous les prestataires TIC tiers, y compris les AC. DORA exige d'éviter une «dépendance excessive» vis-à-vis d'un seul prestataire ou d'une seule juridiction hors UE. Les entreprises financières doivent recenser tous les sous-traitants de leurs AC. En novembre 2025, les autorités européennes de surveillance ont désigné des prestataires TIC tiers critiques sur la base d'une circulaire publiée en juillet 2025.

Risque de sanction et de révocation

Risque direct: les AC américaines peuvent être contraintes de mettre fin à des relations d'affaires avec des organisations sanctionnées par le gouvernement américain si ces dernières sont directement inscrites sur une «liste noire». Voici un exemple: selon des articles de presse, Karim Khan, le procureur de la Cour pénale internationale, s'est vu refuser l'accès à ses e-mails professionnels à la suite de sanctions de l'administration Trump (bien que Microsoft le conteste). Des organisations russes financières et de défense ont perdu l'accès à certains certificats dans le sillage des sanctions de 2022.

Risque de dommages collatéraux: si des éléments d'une organisation enfreignent par inadvertance des mesures américaines à l'encontre de pays, de branches ou de personnes, l'entité dans son ensemble peut se voir inscrite sur une liste noire, ce qui pourrait entraîner la suspension des services des organisations américaines.

Confiance et réputation

De nombreux citoyens européens et suisses privilégient des solutions locales pour les infrastructures sensibles. La souveraineté numérique gagne en importance dans le débat public au vu des bouleversements géopolitiques que nous vivons. Cela vaut en particulier pour les organisations qui traitent des données relatives à des citoyennes et à des citoyens ou à la clientèle.

3. Les trois piliers de la gestion du cycle de vie des certificats

3.1 Découverte: vous ne pouvez pas gérer ce dont vous n'avez pas connaissance

De quoi s'agit-il: balayage complet de l'ensemble de l'infrastructure pour établir un inventaire exhaustif des certificats.

Méthodes de découverte: L'investigation active et la découverte de réseau englobent HTTPS, LDAP et d'autres ports au-delà des domaines de réseau. La découverte locale de clients équivaut à l'inspection du système de fichiers et de l'espace de stockage des certificats sur les serveurs, les stations de travail et les appareils mobiles. Les importations de prestataires tiers sont basées sur l'API et l'intégration de services cloud comme AWS, Azure et GCP ainsi que des répartiteurs de charge comme F5 et d'autres applications. Le Certificate Transparency Monitoring permet de surveiller en temps réel les certificats émis publiquement.

Comment le mettre en œuvre? Mettez en place des campagnes de scannage selon un calendrier hebdomadaire ou quotidien pour les segments critiques. Installez de petits agents légers sur les endpoints pertinents pour une visibilité continue. Pour l'intégration, servez-vous de plateformes cloud et d'outils d'infrastructure. Reliez votre gestion des cycles de vie de certificats à des plateformes MDM telles qu'Intune, Jamf et Workspace ONE.

Pourquoi est-ce important? Vous ne pouvez pas automatiser le renouvellement de certificats inconnus. La compliance exige une traçabilité d'audit pour tous les actifs cryptographiques. Sans inventaire complet aucune évaluation des risques ni posture de sécurité ne sont possibles. La planification de la migration PQC nécessite de connaître chaque certificat et son algorithme. Grâce à une démarche de découverte complète, il est en outre possible d'identifier les AC non autorisées et les certificats auto-signés (la PKI fantôme).

Profil idéal: Un inventaire en temps réel avec suivi complet du cycle de vie révèle quand chaque certificat a été découvert, émis et renouvelé et avec quelle méthode. Il permet l'identification immédiate d'algorithmes faibles, de certificats arrivant à échéance et d'infractions aux directives. La qualité des certificats est évaluée sur la base des normes NIST, ANSSI et CA/B Forum. Un monitoring centralisé comprenant la responsabilité du propriétaire et des avertissements proactifs avant l'expiration des certificats critiques viennent compléter le tableau.

3.2 Gouvernance: des directives pour une mise à l'échelle

De quoi s'agit-il: établissement et application strictes de directives portant sur l'utilisation des certificats dans l'ensemble de l'organisation. Il y a lieu de répondre aux questions suivantes: qui peut demander quels certificats, avec quels niveaux de confiance et algorithmes, par quels workflows, qui doit autoriser quels certificats?

Éléments centraux de la gouvernance:

• Définissez les autorités de certification approuvées et les niveaux de confiance des certificats pour chaque cas d'application. Par exemple: SwissSign OV TLS pour tous les domaines accessibles au public, SwissSign Private Certificates pour les systèmes internes.

• Définissez des normes cryptographiques: longueur des clés, algorithmes et validité pour chaque type de certificat.

• Établissez des nomenclatures et des exigences en matière de métadonnées.

• Définissez des workflows d'approbation: qui peut demander quoi, avec quelles autorisations?

• Attribuez la propriété au niveau de l'unité d'affaires, de l'équipe ou de la personne individuelle.

• Créez des workflows de remplacement: lorsqu'un utilisateur est supprimé d'un groupe, le certificat est bloqué.

• Définissez des directives en matière de délais de renouvellement, par exemple 5 jours avant l'échéance, et non à la dernière minute.

• Définissez la réponse aux incidents: que se passe-t-il en cas de panne liée à un certificat?

Intégration pour l'application stricte des instructions de service: Votre gestion du cycle de vie des certificats devrait comprendre les systèmes suivants afin de pouvoir déployer pleinement son efficacité: Les systèmes ITSM et de ticketing comme ServiceNow et Jira permettent d'intégrer directement des politiques de certification dans vos workflows existants. CMDB offre une corrélation des actifs et un mapping des propriétaires. Les systèmes SIEM comme Splunk et QRadar offrent un Security Event Forwarding. Active Directory permet l'application stricte des directives basées sur les groupes et le blocage automatique lorsque des utilisateurs ou des appareils sont supprimés des groupes. SCIM automatise la synchronisation des utilisateurs et des groupes. Les fournisseurs d'identité avec OpenID Connect gèrent l'accès CLM.

Profil idéal: Les utilisateurs commerciaux ou informatiques peuvent commander leurs propres certificats avec le niveau de sécurité approprié. Les demandes de certificats non conformes sont automatiquement bloquées avec des explications compréhensibles. Chaque certificat est ainsi clairement rattaché à un propriétaire, un service, une fin et offre pour cela le niveau de confiance approprié. Les journaux d'audit signés numériquement sont infalsifiables et offrent un niveau de détail conforme à la loi. Les rapports de compliance automatisés sont livrés aux responsables de l'organisation conformément au calendrier établi.

3.3 Automatisation: rendre possibles les certificats de 47 jours

De quoi s'agit-il: opérations de certificat de bout en bout – émission, renouvellement, mise à disposition, révocation – sans intervention manuelle.

Qu'est-ce qu'un agent? Les agents sont de petits composants logiciels installés sur des serveurs ou des stations de travail et qui communiquent avec votre plateforme CLM. Ils débusquent les certificats dans des mémoires et des systèmes de fichiers locaux. Ils demandent automatiquement de nouveaux certificats et les installent. Ils procèdent au renouvellement en temps utile avant l'expiration du certificat et signalent le statut au tableau de bord central. Ils font le pont entre les API CLM modernes et les anciens protocoles que vos appareils utilisent déjà. En règle générale, l'agent communique nativement via HTTPS avec le CLM central.

Les agents constituent souvent la meilleure option, car ils offrent un moyen simple d'établir l'automatisation sur les systèmes existants.

La maturité à atteindre: Les renouvellements de certificats prévus se basent sur votre gouvernance et vos politiques. La mise à disposition automatique sur tous les endpoints s'effectue sans interruption de service. Les opérations groupées pour les révocations de masse ou les mises à jour des directives sont possibles sans problème. Les intégrations natives avec des clés de stockage cloud comme Azure Key Vault, AWS Certificate Manager et Google Certificate Manager facilitent la gestion des certificats dans le cloud. Les outils DevOps modernes tels qu'Ansible, Kubernetes cert-manager et Terraform sont pris en charge afin de garantir l'agilité et la sécurité des DevOps.

4. Relever le défi de la souveraineté

Choisir un prestataire européen

Pour les secteurs réglementés de l'espace suisse et européen, le choix d'une autorité de certification européenne et d'un prestataire CLM local contribue à répondre aux exigences d'évaluation des fournisseurs SRI 2 et DORA, à résoudre les préoccupations en matière de résidence des données et à réduire les risques géopolitiques.

Réduire les risques géopolitiques: Pour les secteurs réglementés de l'espace suisse et européen, la décision est stratégique.

Les AC basées dans l'UE sont soumises au droit de l'UE et offrent un alignement sur le RGPD ainsi qu'un risque de sanctions réduit pour les opérations européennes. Si un gouvernement américain sanctionne votre organisation ou une partie de votre organisation, les AC européennes n'ont pas besoin de cesser toute fourniture de services envers vous.

Du fait de leur juridiction suisse, les autorités de certification du pays bénéficient de la perception de la neutralité traditionnelle de la Confédération, ce qui peut être un avantage dans les conflits géopolitiques.

Le statut de «pays tiers sûr» dont la Suisse jouit pour la protection des données, combiné à la compliance ETSI et eIDAS, offre aux organisations européennes à la fois souveraineté et compatibilité réglementaire.

Indépendamment de votre choix: prenez en compte la juridiction de votre autorité de certification et le risque de sanctions en tant qu'élément de votre évaluation du risque SRI 2/DORA auprès de prestataires tiers.

Pour une comparaison CA détaillée, voir notre analyse «Autorités de certification de confiance pour la Suisse et l'Europe».

5. Vos prochaines démarches: moderniser votre PKI pour 2026

Élaborez le cas commercial en interne

Positionnement stratégique: Les lacunes en matière de certificats représentent un risque pour la continuité de vos affaires: quantifiez les incidents passés, si possible, afin d'en rendre les conséquences tangibles. Mentionnez des exigences de compliance comme les règlements SRI 2 et DORA pour le secteur financier, qui exigent une gestion en bonne et due forme des prestataires tiers. Gardez à l'esprit l'échéance des 47 jours. La question n'est pas de savoir si vous passez à l'automatisation, mais quand. Mars 2026, avec un délai maximum de 200 jours, constitue un premier jalon à franchir.

Réflexions sur l'analyse TCO: Calculez approximativement vos coûts actuels: heures consacrées à la gestion manuelle des certificats multipliées par le taux horaire, multiplié par le nombre de renouvellements. Calculez votre situation future sans automatisation: même facture pour une fréquence de renouvellement multipliée par huit. Les lacunes en matière de certificats coûtent déjà très cher aux entreprises et compromettent la sécurité et l'opérabilité de votre entreprise. Énumérez des exemples connus, comme ceux décrit plus haut dans l'article. Comparez: investissement CLM et risque de poursuite de la gestion manuelle.

L'automatisation requiert des certificats de domaine unique. Comparez soigneusement les modèles de prix. Si vous ne pouvez plus utiliser que des certificats de domaine unique à l'avenir, cela peut coûter nettement plus cher selon l'autorité de certification.

Évaluer les prestataires

Critères de sélection CA: Les principales CA offrent toutes des compétences techniques similaires. En ce qui concerne la souveraineté numérique et la qualité du support, prêtez attention aux lieux où sont basés le quartier général, les interlocuteurs et les données.

À cela s'ajoutent les modèles de prix. Voici un exemple: 9 certificats de domaine unique pour 9 couches d'application engendrent 9 fois plus de coûts ailleurs. Chez SwissSign, les coûts pour le même scénario sont multipliés par trois environ, puisque nous facturons par propriétaire et non par numéro de série. Découvrez ici notre comparatif détaillé des autorités de certification pour les organisations régulées en Suisse et Europe.

Critères de sélection CLM: Les capacités de découverte pour le réseau, le cloud, les endpoints et les intégrations de tiers sont décisives, il faut un support de protocole pour ACME, SCEP, EST, WCCE et les agents. Des connecteurs cloud pour AWS, Azure et GCP sont requis. Des connecteurs MDM pour Intune, Jamf et d'autres via SCEP sont importants.

Tout l'écosystème d'intégration doit être calibré sur votre pile: AD, Intune, F5, Kubernetes, SIEM, ITSM, CMDB. Le support multi-CA permet la gestion regroupée des certificats de tous les émetteurs. La souveraineté européenne revêt une importance cruciale pour les secteurs réglementés. La flexibilité de déploiement pour les services sur site, cloud ou hybrides devrait être assurée.

Envisager une démonstration de faisabilité (Proof of Concept)

PoC simples d'accès (généralement gratuits): Un à deux cas d'application dans un environnement de test. Vous pouvez utiliser votre propre infrastructure, par exemple une machine Windows: installer un agent, balayer, faire une démonstration du workflow de remplacement. C'est une bonne façon de mettre en lumière des compétences clés sans engagement.

PoC complexes (éventuellement payants): Y compris Intune, Azure et les environnements AD complexes. Nécessite une configuration individuelle du tenant, ce qui prend plusieurs jours. La configuration peut être exportée chez les bons fournisseurs tels que SwissSign et Evertrust, ce qui permet de la transférer facilement dans votre environnement de production. Cela réduit le temps et les coûts de déploiement pour la mise en œuvre finale.

Décision CLM cloud versus sur site

Quand le CLM cloud est-il judicieux? 

En cas de complexité limitée de l'infrastructure, lorsque seuls des certificats publics sont gérés et qu'aucune intégration AD ou F5 approfondie n'est nécessaire. Pour les workflows basés sur ACME et API qui ne nécessitent pas d'accès privilégié. Lorsque la maîtrise des coûts est importante et qu'aucune infrastructure sur site ne doit être entretenue.

Quand le service sur site est-il pertinent?

Le problème d'intégration avec le CLM cloud: le CLM cloud doit accéder à des systèmes internes, se connecter à Active Directory via LDAP ou LDAPS pour la synchronisation des utilisateurs. Atteindre le répartiteur de charge F5 pour la mise à disposition des certificats, installer des agents de certificats internes sur les serveurs.

Comment le CLM cloud atteint-il ces systèmes? Les options sont limitées. Vous pourriez établir une connexion via Internet, mais votre équipe chargée de la sécurité ne le verrait certainement pas d'un bon œil. Tunnel VPN: souhaitez-vous une connexion VPN permanente entre le fournisseur CLM et vos systèmes internes? Cela signifie qu'un prestataire externe dispose d'un accès réseau 24h/24 et 7j/7 aux systèmes critiques. C'est délicat du point de vue de la compliance. Vos auditeurs poseraient certainement des questions.

Le problème d'identité avec le CLM cloud: le CLM cloud nécessite un accès privilégié. S'agissant d'F5, cela signifie: une authentification admin pour la mise à disposition des certificats. S'agissant d'Intune: un compte privilégié pour la mise en avant des certificats. S'agissant d'AD: un compte de service avec des droits d'écriture. Une clé SSH pour serveur Linux. Des tokens API pour le cluster Kubernetes. Tous ces accès devraient se faire via une plateforme SaaS, ce qui met de nombreuses organisations mal à l'aise pour des raisons de sécurité.

Avantages d'un déploiement sur site: CLM fonctionne au sein de votre périmètre réseau, il existe un accès LDAP direct sans VPN. Les éléments d'authentification nécessaires ne quittent jamais votre infrastructure. Cette procédure répond aux principes de la confiance zéro et vous garantit une souveraineté totale sur les données, d'autant plus en combinaison avec des certificats suisses.

La valeur seuil: à partir d'environ 5000 certificats, un déploiement sur site est généralement plus rentable et plus pertinent sur le plan opérationnel pour les organisations régulées.

6. Conclusion et passage à l'action

Récapitulatif

La convergence de trois grands bouleversements dans le monde de la PKI – des durées de validité de certificats de 47 jours, l'expansion de la PKI privée et la migration PQC à venir – oblige les organisations à automatiser la gestion de leurs certificats. Les organisations qui passent à l'action dès maintenant seront gagnantes:

• Résilience opérationnelle: éviter les pannes de certificats avant qu'elles ne se produisent

• Base PQC: mettre en place l'agilité requise par la migration quantique

• Compliance: souveraineté numérique totale avec les bons fournisseurs CA et CLM comme SwissSign et Evertrust

• Maîtrise des coûts: éviter l'explosion budgétaire due à la fréquence de renouvellement accrue en optant pour le bon CA

• Avantage concurrentiel: opérer sans accroc alors que d'autres improvisent

Vos prochaines démarches

Premièrement: commencez par y voir clair. Vous ne pouvez pas automatiser ce dont vous n'avez pas connaissance. La découverte en est la première étape. Vous saurez quels certificats vous gérez, où ils se trouvent, quand ils arrivent à échéance et à qui ils appartiennent.

Deuxièmement: évaluez votre relation CA et choisissez un fournisseur CLM. Prenez en compte la souveraineté, le modèle de prix (critique pour l'économie de l'automatisation) et la qualité du support – pas uniquement les fonctions techniques. Pour votre fournisseur CLM, les méthodes de découverte modernes et la convivialité ne sont pas réservées aux grands utilisateurs commerciaux. Pour de nombreuses grandes organisations, l'écosystème d'intégration, qui doit être adapté à l'infrastructure, est également déterminant.

Troisièmement: il faut s'y mettre SANS PLUS ATTENDRE. La première échéance pour une durée de cycle TLS/SSL de 200 jours maximum est fixée à mars 2026. Mettez-vous dès maintenant sur les rails au nom de la souveraineté numérique.