La loi européenne sur la cyber-résilience : un guide pratique sur la cryptographie et l’ PKI , destiné aux éditeurs de logiciels de type « Software »

Pendant des années, la cryptographie est restée en arrière-plan de l’ingénierie de l’ software , un détail dont les équipes ne discutaient que rarement en dehors d’un examen de sécurité. La loi européenne sur la cyber-résilience(CRA) la place désormais au cœur de la réglementation des produits. En vertu de la CRA, les choix cryptographiques intégrés à votre software déterminent désormais s’il peut légalement être commercialisé sur le marché européen.

Ce mécanisme, c'est le marquage CE. Ce même marquage, qui régit la sécurité physique et électrique des produits de l'UE, s'étend désormais à la cybersécurité de tout produit comportant un élément numérique. Si votre produit ne respecte pas les exigences essentielles du CRA, il ne pourra pas porter le marquage CE.

Sans le marquage « CE », le produit ne peut pas être commercialisé. Cette règle s'applique à tout fabricant qui met sur le marché de l'UE un produit comportant des éléments numériques, quel que soit le lieu d'implantation de l'entreprise.

Ce qu'exige réellement la loi sur la cyber-résilience

La loi sur la cyber-résilience, officiellement le règlement (UE) 2024/2847, est la première législation horizontale de l'Union européenne fondée sur le principe de « sécurité dès la conception » pour les produits comportant des éléments numériques. Le terme « horizontale » signifie qu'elle s'applique à l'ensemble des secteurs d'activité plutôt que de cibler un secteur en particulier. Le principe de « sécurité dès la conception » implique que la sécurité doit être intégrée au produit dès le départ, et non ajoutée ultérieurement.

Le règlement divise les obligations en deux parties. L'annexe I, partie I, porte sur la conception en matière de sécurité des produits : les caractéristiques qu'un produit doit présenter au moment de sa mise sur le marché. L'annexe I, partie II, porte sur la gestion des vulnérabilités tout au long du cycle de vie : comment détecter, corriger et communiquer les vulnérabilités une fois que le produit est sur le marché. Se conformer au CRA implique de respecter ces deux parties, et pas seulement de renforcer la version initiale.

Qui est concerné ?

La CRA remplit un large éventail de fonctions tout au long de la chaîne d'approvisionnement de l'software :

• Software les éditeurs et les développeurs, notamment les applications autonomes software et les applications intégrées software.
• Solutions de traitement de données à distance qui font partie intégrante d'un produit, c'est-à-dire sans lesquelles celui-ci ne peut remplir sa fonction.
• Open-source les gestionnaires qui commercialisent leurs software .
• Les importateurs et les distributeurs, qui doivent s'assurer que le fabricant d'un produit a respecté ses obligations.

Si vous développez, commercialisez ou revendez des « software » destinés au marché de l’Union européenne, vous êtes très certainement soumis à certaines obligations en vertu de la CRA.

Catégories « Par défaut », « Important » et « Critique »

L'ACR classe les produits en fonction de leur niveau de risque. La plupart des produits relèvent de la catégorie « par défaut ». Au-dessus se situent les classes « importantes » (classe I et classe II) et la catégorie « critique », qui sont soumises à des obligations plus strictes en matière d'évaluation de la conformité. Plusieurs exemples de produits « importants » relèvent clairement des domaines de l'informatique et de l'software, notamment les systèmes de gestion des identités, les VPN software et les pare-feu. Si votre produit remplit une fonction de sécurité similaire à celles-ci, attendez-vous à ce que le niveau d'exigence en matière de preuves soit plus élevé. Dans certains cas, cela implique un examen par un organisme notifié plutôt qu'une simple autodéclaration.

Pourquoi est-ce important ? Le marquage « CE », les délais et les sanctions

L'argument commercial est clair. Un produit « software » non conforme perd le marquage CE indispensable pour accéder au marché de l'UE. Une lacune en matière de CRA constitue donc un problème de chiffre d'affaires et de distribution, et pas seulement un problème de sécurité.

Les sanctions viennent renforcer ce point. Les amendes peuvent atteindre 15 millions d'euros ou 2,5 % du chiffre d'affaires annuel mondial total, le montant le plus élevé étant retenu. Ce plafond s'applique aux infractions aux exigences essentielles de l'annexe I et aux obligations prévues aux articles 13 et 14 ; les autres obligations sont soumises à des plafonds inférieurs.

Comment le modèle CRA s'applique à la cryptographie et PKI

Le CRA aborde la cryptographie à travers plusieurs domaines de contrôle interdépendants de l’annexe I. Chacun d’entre eux désigne une propriété de sécurité, et la plupart d’entre eux s’appuient sur une infrastructure à clé publique (PKI) qui permet de mettre en œuvre cette propriété à grande échelle. Voici comment ces éléments s’articulent entre eux.

Confidentialité des données stockées et en transit

L'annexe I, partie I, section 2, point e), exige que les produits garantissent la confidentialité des données concernées à l'aide d'un cryptage de pointe, tant au repos qu'en transit. Dans la pratique, cette protection repose sur une autorité de certification ( PKI ) qui délivre les certificats de session et de service utilisés pour établir des canaux cryptés et protéger les données stockées.

Intégrité des données, des commandes et de la configuration

L'annexe I, partie I, section 2(f), exige la protection de l'intégrité des données, commandes, programmes et configurations stockés, transmis et traités contre toute manipulation non autorisée par l'utilisateur, ainsi que la notification des altérations. Une configuration signée et des canaux authentifiés, adossés à des certificats, vous permettent de prouver qu'une configuration ou un paramètre provient d'une source fiable et est parvenu à destination sans avoir été modifié. command

Configuration et identité sécurisées par défaut

L'annexe I, partie I, sections 2(b) et 2(d), impose des paramètres par défaut sécurisés et un contrôle d'accès basé sur l'identité. Le point 2(b) exige également la possibilité de réinitialiser le produit à son état d’origine, tandis que le point 2(d) impose la notification de tout accès non autorisé éventuel. L’objectif concret est de disposer d’une identité unique pour chaque service ou instance, attribuée lors du déploiement, plutôt que d’un identifiant par défaut partagé fourni avec chaque exemplaire. Les identités basées sur des certificats permettent à chaque charge de travail de s’authentifier en tant qu’elle-même.

Mécanisme de mise à jour sécurisé

L'annexe I, partie I, section 2, point c), ainsi que l'annexe I, partie II, points 7 et 8, exigent la mise en place d'un mécanisme de mise à jour sécurisé. Les mises à jour doivent être distribuées sans délai et gratuitement pendant toute la durée de la période de support obligatoire. Elles doivent également être signées cryptographiquement, afin que les destinataires puissent en vérifier l'authenticité avant de les installer. La signature de code est le mécanisme de contrôle qui permet de garantir cette vérification.

Visibilité des composants cryptographiques

Le suivi des composants fait l’objet d’une disposition explicite. L’annexe I, partie II, point (1), impose aux fabricants d’identifier et de documenter les vulnérabilités et les composants, y compris une nomenclature « software » au format lisible par machine couvrant au moins les dépendances de premier niveau. Les exigences spécifiques à la cryptographie sont définies dans l’annexe K, une annexe intersectorielle en cours d’élaboration dans le cadre des normes ETSI CYBER-EUSR, conformément à la demande de normalisation M/606. Celle-ci devrait définir une liste blanche de mécanismes cryptographiques s’inspirant des recommandations de l’ENISA. L’objectif est de vous permettre d’identifier les bibliothèques et algorithmes cryptographiques intégrés à votre « software » et à ses dépendances. Cela vous permet d’évaluer l’exposition aux risques et d’apporter rapidement des correctifs lorsqu’un composant s’avère vulnérable.

Suppression sécurisée des données

L'annexe I, partie I, section 2(m), exige la prise en charge de la suppression sécurisée et définitive des données et des paramètres. Pour les services de type « software » qui gèrent des locataires ou des environnements clients, cela inclut la destruction des clés cryptographiques lors de la désaffiliation ou de la mise hors service, afin que les données retirées ne puissent pas être récupérées.

Se préparer à l'audit : les questions que poseront les auditeurs

Les évaluations de conformité CRA, qu’elles soient autodéclarées ou examinées par un organisme notifié, se concentrent sur des preuves tangibles plutôt que sur des déclarations d’intention. Une intention écrite de chiffrer les données n’a que peu de valeur sans la preuve que le mécanisme existe et fonctionne. Utilisez les points clés ci-dessous comme liste de contrôle pour effectuer votre auto-évaluation :

• Documentation relative à l'évaluation des risques justifiant vos choix en matière de conception cryptographique.
• Une identité cryptographique unique pour chaque service, instance ou locataire.
• Un pipeline de mises à jour signées qui vérifie les signatures avant l'installation, avec les mises à jour automatiques activées par défaut.
• Un inventaire des composants cryptographiques qui recense les dépendances héritées d'open-source .
• Procédures d'effacement sécurisé et de destruction des clés en cas de départ d'un collaborateur ou de mise hors service.
• Engagements relatifs à la durée de support, consignés par écrit et communiqués. La durée minimale est de cinq ans ; elle est plus longue lorsque le produit est destiné à être utilisé pendant une période plus longue, et plus courte uniquement lorsque la durée d'utilisation prévue est inférieure à cinq ans.

Par où commencer : un parcours pratique de préparation

Vous n'êtes pas obligé de répondre à toutes les exigences en même temps, mais l'ordre dans lequel vous les traitez a son importance. Voici un ordre qui semble efficace :

1. Vérifiez que votre processus de signalement au titre de l’article 14 est bien opérationnel. Cela implique la désignation d’un responsable, la mise en place d’un circuit de réception des signalements de vulnérabilités et d’incidents, ainsi que la possibilité de déposer un avertissement précoce dans les 24 heures, une notification dans les 72 heures et un rapport final via la plateforme unique de signalement de l’ENISA et votre CSIRT de coordination.
2. Assurez-vous d'avoir une bonne visibilité sur vos actifs cryptographiques, car on ne peut ni protéger ni justifier ce que l'on ne voit pas.
3. Attribuer des identités uniques aux services et aux instances afin de remplacer les identités par défaut partagées.
4. Mettre en place un pipeline de mise à jour signé, comprenant une vérification avant l'installation.
5. Établir un inventaire des composants cryptographiques, y compris les dépendances de type « open-source ».
6. Documenter les décisions de conception fondées sur les risques qui sous-tendent chaque choix.

Commencez tôt. Les exigences essentielles entreront en vigueur en décembre 2027, mais les obligations de signalement des vulnérabilités prendront effet dès septembre 2026. Les modifications de conception mentionnées ci-dessus nécessitent du temps pour être planifiées, testées et déployées sur un produit commercialisé.

Comment Keyfactor vous aider

Keyfactor offre aux éditeurs de solutions « software » une feuille de route concrète pour passer des exigences de la CRA à leur mise en œuvre, en associant chaque domaine de contrôle à une fonctionnalité que vous pouvez déployer.

Keyfactor AgileSec traite la question de la visibilité des composants cryptographiques. Il détecte et recense les bibliothèques cryptographiques, les algorithmes, les clés et les protocoles présents dans votre code, vos terminaux, vos charges de travail dans le cloud et vos dépendances. Il évalue ensuite les risques, ce qui vous permet de hiérarchiser les mesures correctives et de démontrer votre exposition aux risques auprès d'un évaluateur.

EJBCA fournit une base « PKI » pour la confidentialité, l’intégrité et une gestion des identités sécurisée par défaut. Il émet les certificats qui protègent les données en transit et au repos. Il attribue des identités uniques aux services et aux instances, remplaçant ainsi les identifiants partagés, et prend en charge la destruction des clés cryptographiques pour garantir une sortie et une mise hors service en toute sécurité.

Keyfactor SignServer, en collaboration avec Keyfactor Signum, assure le mécanisme de mise à jour sécurisée. Ces deux entités signent cryptographiquement les mises à jour d’ software s et les artefacts de publication, à l’aide de clés protégées par hardware et de journaux d’audit signés, afin que les destinataires puissent vérifier leur authenticité tout au long de la période de support.

Keyfactor Command assure la cohérence opérationnelle. Il automatise le cycle de vie des certificats associés à ces identités et canaux, offrant ainsi aux équipes de sécurité une visibilité en continu, un renouvellement automatisé et une gouvernance centralisée dans tous les environnements.

Pris individuellement, ces produits répondent aux exigences spécifiques du CRA en matière de contrôle. Ensemble, ils constituent le « Trust Control Plane » d’ Keyfactor. Il s’agit d’un système unique permettant de surveiller votre infrastructure cryptographique, d’analyser les risques, de fournir des identités fiables, d’orchestrer les actions et de régir l’ensemble conformément aux politiques en vigueur. Il s’agit là de la même boucle continue que le CRA vous demande de démontrer, depuis la conception initiale jusqu’à la fin de la période de support.

Prêt à intégrer vos obligations au titre de la CRA dans un plan de préparation opérationnelle ? Demander une démo.

Vous avez des questions sur la loi sur la cyber-résilience ? Nous avons les réponses.

What is the EU Cyber Resilience Act?
The Cyber Resilience Act (Regulation (EU) 2024/2847) is the EU’s first horizontal law mandating secure-by-design cybersecurity for products with digital elements, meaning software or hardware products and their remote data processing solutions.. It ties compliance directly to CE marking and splits obligations into product security design and lifecycle vulnerability handling.

Does the CRA apply to software companies outside the EU?
Yes. It applies to any manufacturer that places a product with digital elements on the EU market, regardless of where the company is based. Software producers, open-source stewards that distribute commercially, and importers and distributors all carry obligations.

When do CRA requirements take effect?
 The Article 14 reporting obligations have applied since September 11, 2026, and they cover products already on the EU market. The provisions on notified bodies have applied since June 11, 2026. The essential requirements, conformity assessment, and CE marking apply from December 11, 2027

What are the penalties for non-compliance?
Penalties reach 15 million euros or 2.5 percent of global total annual revenue, whichever is higher. Non-compliant software also loses the CE mark required for EU market access, making this a market-access issue as much as a security one.

What cryptographic controls does the CRA require?
The CRA addresses cryptography through several Annex I control areas. These cover confidentiality and integrity of data, secure-by-default configuration and identity, signed updates, cryptographic component visibility, and secure data deletion including key destruction. Each choice must be justified by a product-specific risk assessment.

What is a cryptographic component inventory and why does it matter?
It is a record of every cryptographic library and algorithm embedded in your software, including inherited open-source dependencies. Assessors expect it, and without one you cannot quickly determine what is exposed when a component vulnerability is disclosed.

Which products face stricter CRA obligations?
Important (Class I and II) and Critical categories carry stricter conformity assessment obligations than the default category. In IT and software, this includes identity management systems and VPN software.

How does PKI support CRA compliance?
PKI underpins the CRA’s core cryptographic requirements. Certificates encrypt data in transit and at rest and provision unique service and device identities. They also sign software updates, so recipients can verify authenticity throughout the support period.