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 :
- 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.
- 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.
- Attribuer des identités uniques aux services et aux instances afin de remplacer les identités par défaut partagées.
- Mettre en place un pipeline de mise à jour signé, comprenant une vérification avant l'installation.
- Établir un inventaire des composants cryptographiques, y compris les dépendances de type « open-source ».
- 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.
Qu'est-ce que la loi européenne sur la cyber-résilience ?
La loi surla cyber-résilience (règlement (UE) 2024/2847) est la première législation horizontale de l'UE imposant une cybersécurité intégrée dès la conception pour les produits comportant des éléments numériques, c'est-à-dire les produits software ou hardware et leurs solutions de traitement des données à distance. Elle lie directement la conformité au marquage CE et répartit les obligations entre la conception sécurisée des produits et la gestion des vulnérabilités tout au long de leur cycle de vie.
La CRA s'applique-t-elle aux entreprises d'software s situées en dehors de l'UE ?
Oui. Elle 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. Les producteurs Software , les gestionnaires open-source qui assurent la distribution à des fins commerciales, ainsi que les importateurs et les distributeurs sont tous soumis à des obligations.
Quand les exigences du CRA entrent-elles en vigueur ?
Les obligations de déclaration prévues à l’article 14 s’appliquent depuis le 11 septembre 2026 et concernent les produits déjà commercialisés sur le marché de l’UE. Les dispositions relatives aux organismes notifiés s’appliquent depuis le 11 juin 2026. Les exigences essentielles, l’évaluation de la conformité et le marquage CE s’appliquent à compter du 11 décembre 2027.
Quelles sont les sanctions en cas de non-conformité ?
Les sanctions peuvent atteindre 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial total, le montant le plus élevé étant retenu. Les software s non conformes perdent également le marquage « CE » requis pour accéder au marché de l’UE, ce qui fait de cette question un enjeu d’accès au marché autant qu’une question de sécurité.
Quels sont les contrôles cryptographiques exigés par la CRA ?
La CRA aborde la cryptographie à travers plusieurs domaines de contrôle de l'annexe I. Ceux-ci couvrent la confidentialité et l'intégrité des données, la configuration et l'identité « sécurisées par défaut », les mises à jour signées, la visibilité des composants cryptographiques, ainsi que la suppression sécurisée des données, y compris la destruction des clés. Chaque choix doit être justifié par une évaluation des risques spécifique au produit.
Qu'est-ce qu'un inventaire des composants cryptographiques et pourquoi est-il important ?
Il s'agit d'un registre répertoriant toutes les bibliothèques et tous les algorithmes cryptographiques intégrés à votre software, y compris les dépendances héritées de open-source . Les auditeurs s'attendent à ce que vous en disposiez, et sans cet inventaire, vous ne pouvez pas déterminer rapidement quelles sont les vulnérabilités exposées lorsqu'une faille de sécurité touchant un composant est révélée.
Quels sont les produits soumis à des obligations CRA plus strictes ?
Les catégories « importantes » (classes I et II) et « critiques » sont soumises à des obligations d’évaluation de la conformité plus strictes que la catégorie par défaut. Dans le domaine des technologies de l’ software, cela inclut les systèmes de gestion des identités et les VPN software.
Comment « PKI » facilite-t-il la mise en conformité avec les exigences de la CRA ?
«PKI » répond aux exigences cryptographiques fondamentales de la CRA. Les certificats chiffrent les données en transit et au repos, et attribuent des identités uniques aux services et aux appareils. Ils signent également les mises à jour d’ software , ce qui permet aux destinataires de vérifier leur authenticité tout au long de la période de support.
