L'essentiel en bref
- Le Cyber Resilience Act, règlement (UE) 2024/2847, est entré en vigueur le 10 décembre 2024. Les obligations de signalement de l'article 14 s'appliquent depuis le 11 septembre 2026, et l'ensemble des autres exigences à partir du 11 décembre 2027.
- Une vulnérabilité activement exploitée déclenche un délai en trois étapes : alerte précoce au CSIRT national et à l'ENISA sous 24 heures, notification complète sous 72 heures, rapport final sous 14 jours après la mise à disposition d'une mesure corrective.
- Tout produit comportant des éléments numériques doit avoir une période d'assistance déterminée d'au moins cinq ans, sauf si sa durée de vie prévue est plus courte, avec des mises à jour de sécurité gratuites pendant toute cette période.
- L'annexe I partie II fixe huit obligations de traitement des vulnérabilités. L'une d'entre elles est une nomenclature logicielle (SBOM) dans un format lisible par machine couramment utilisé, couvrant au minimum les dépendances de premier niveau.
- Les amendes atteignent 15 millions d'euros ou 2,5 % du chiffre d'affaires annuel mondial, le montant le plus élevé étant retenu, en cas de manquement aux exigences essentielles ou aux obligations des fabricants prévues aux articles 13 et 14.
Le Cyber Resilience Act en un tableau
Le Cyber Resilience Act est le premier texte européen qui réglemente la cybersécurité des produits et non la sécurité des organisations. Si vous mettez sur le marché de l'Union du matériel ou des logiciels comportant des éléments numériques, il vous concerne, et il vous concerne pendant des années après la vente, pas seulement au moment de la livraison. Tous les chiffres de cet article proviennent du règlement lui-même ou du résumé officiel du texte législatif.
Une idée reçue répandue veut que le CRA soit un sujet pour 2027. Ce n'est pas le cas. Les obligations de signalement de l'article 14 s'appliquent depuis le 11 septembre 2026, et elles couvrent aussi les produits déjà sur le marché, y compris ceux que vous avez livrés il y a des années. La date de 2027 régit la conformité et le marquage CE. Celle de 2026 régit ce qui se passera la prochaine fois que quelqu'un exploitera une vulnérabilité dans votre code.
1. La sécurité dès la conception devient une propriété juridique du produit
En vertu de l'article 13, les fabricants doivent concevoir, développer et fabriquer les produits comportant des éléments numériques de manière à satisfaire aux exigences essentielles en matière de cybersécurité de l'annexe I partie I. Cela couvre une configuration par défaut sécurisée, l'absence de vulnérabilités exploitables connues au moment de la mise sur le marché et la protection de la confidentialité et de l'intégrité des données que le produit traite.
Le changement pratique porte sur la place de la sécurité dans votre processus. L'annexe I partie I est évaluée au moment de la mise sur le marché, donc la preuve doit exister avant la livraison. Il vous faut une évaluation documentée des risques de cybersécurité pour le produit, et elle fait partie de la documentation technique à conserver dix ans après la mise sur le marché ou pendant la période d'assistance, la période la plus longue étant retenue.
Si vous exploitez déjà un système de management de la sécurité de l'information certifié ISO 27001, une bonne partie de la base organisationnelle est en place. Ce qui manque le plus souvent, c'est la preuve au niveau du produit. Un SMSI démontre que votre entreprise pilote la sécurité. Le CRA demande de démontrer qu'une version donnée d'un produit donné le fait.
2. Le traitement des vulnérabilités court sur toute la période d'assistance
L'annexe I partie II fixe huit obligations de traitement des vulnérabilités, applicables aussi longtemps que vous assurez le suivi du produit. Elles couvrent l'identification et la documentation des vulnérabilités et des composants, la correction sans délai, des tests de sécurité réguliers, l'information publique sur les vulnérabilités corrigées, une politique de divulgation coordonnée des vulnérabilités, une adresse de contact publique pour les signalements, la distribution sécurisée des mises à jour et des mises à jour de sécurité gratuites et distribuées séparément des mises à jour fonctionnelles.
Celle qui change le plus les pratiques de développement est la première. Elle exige une nomenclature logicielle dans un format lisible par machine couramment utilisé, couvrant au minimum les dépendances de premier niveau. « Au minimum » est un plancher. Comme la SBOM doit refléter le produit pendant toute la période d'assistance, la traiter comme un document produit une fois par version est le mauvais modèle. Elle appartient à la chaîne de build et se régénère à chaque build.
Reste la période d'assistance elle-même. L'article 13 exige que vous la déterminiez, que vous communiquiez sa date de fin à l'acheteur au moment de l'achat et que vous la fixiez à cinq ans au minimum, sauf si la durée de vie prévue du produit est réellement plus courte. Cinq ans de mises à jour de sécurité gratuites relèvent autant d'une décision commerciale que technique, et beaucoup de feuilles de route produit ne l'ont pas chiffrée.
3. Les signalements suivent un délai de 24 heures, 72 heures et 14 jours depuis septembre 2026
L'article 14 oblige les fabricants à notifier les vulnérabilités activement exploitées et les incidents de sécurité graves simultanément au CSIRT désigné par leur État membre et à l'ENISA, via la plateforme de signalement unique du CRA. La séquence comporte trois étapes.
L'erreur que commettent la plupart des équipes : lire les 24 heures comme un délai pour signaler un problème résolu. Ce n'en est pas un. C'est une obligation d'alerte précoce qui démarre à la prise de connaissance, c'est-à-dire en pratique au moment où le courriel d'un chercheur en sécurité arrive ou où votre supervision détecte une exploitation en conditions réelles. Personne ne dispose d'un correctif en 24 heures. Ce qu'il vous faut en 24 heures, c'est une personne responsable désignée, un accès à la plateforme de signalement et l'autorisation de déclarer sans attendre une revue juridique.
Les micro et petites entreprises sont exonérées d'amende pour le seul dépassement du délai de 24 heures, et les intendants de logiciels libres et open source échappent au régime de sanctions. Aucune de ces deux exceptions ne supprime l'obligation elle-même. Si vous appliquez déjà des processus de signalement au titre de la directive NIS2, la logique des délais vous sera familière. Le déclencheur, en revanche, diffère : NIS2 part des incidents qui affectent vos services, l'article 14 des vulnérabilités présentes dans les produits que vous vendez.
4. Votre classe de produit détermine qui contrôle
Le CRA suit une approche fondée sur les risques, mais pas celle que décrivaient les premiers projets. Le règlement adopté retient trois niveaux au-dessus de la catégorie par défaut, énumérés aux annexes III et IV, et le niveau détermine votre procédure d'évaluation de la conformité au titre de l'article 32.
Notez ce qui ne figure pas dans ce tableau. Il n'existe pas de niveau « hautement critique » dans le texte adopté, et la majorité des produits comportant des éléments numériques relèvent de la catégorie par défaut, où l'auto-évaluation est admise. Si un prestataire ou un consultant vous explique que le CRA impose un organisme notifié à tout produit connecté, vérifiez quelle version du texte il a lue. Lorsque plusieurs catégories peuvent s'appliquer à un même produit, c'est la classe la plus stricte qui prévaut.
La classification n'est pas non plus un exercice ponctuel. Ajoutez une fonction VPN à un produit qui relevait de la catégorie par défaut, et le classement se déplace avec elle. Les équipes qui traitent la classification produit comme un critère de mise en production, et non comme un avis juridique rendu une fois pour toutes, s'en aperçoivent avant qu'une modification substantielle ne réactive leurs obligations.
5. Les composants tiers deviennent votre charge de preuve
L'article 13 exige des fabricants qu'ils fassent preuve de diligence raisonnable lorsqu'ils intègrent des composants provenant de tiers, et qu'ils s'assurent que ces composants ne compromettent pas la sécurité du produit. Vos dépendances ne sont donc plus le problème de conformité de quelqu'un d'autre.
C'est précisément là que la SBOM cesse d'être de la paperasse et devient utile. Vous ne pouvez pas exercer une diligence raisonnable sur un arbre de dépendances que vous n'avez pas recensé, et vous ne pouvez pas répondre à la demande d'une autorité de surveillance du marché au sujet d'un composant dont vous ignoriez la présence dans votre produit. L'obligation s'étend aux composants open source que vous intégrez. Les mainteneurs, eux, sont traités différemment : les intendants de logiciels libres et open source portent des obligations allégées et échappent au régime de sanctions. La responsabilité de ce que vous livrez vous revient donc, et non à eux.
L'écart que les équipes produit découvrent ici est contractuel plutôt que technique. L'analyse des dépendances est un problème résolu. Avoir inscrit au contrat, avant d'en avoir besoin, une voie vers un correctif quand la vulnérabilité se trouve dans le composant d'un fournisseur commercial ne l'est pas. Si un fournisseur ne peut pas s'engager sur un délai de divulgation compatible avec votre fenêtre de 72 heures, c'est une décision d'achat et non une question d'ingénierie.
Pourquoi décembre 2027 est plus serré qu'il n'y paraît
Voici la partie qui figure rarement dans les résumés. La voie de l'auto-évaluation pour les produits importants de classe I suppose que les normes harmonisées soient appliquées intégralement, et ces normes sont encore en cours d'élaboration. Les organismes notifiés n'ont pu commencer à opérer qu'à partir du 11 juin 2026, date d'application du chapitre IV. La voie de conformité la moins coûteuse pour tout un niveau de produits dépend donc de normes inachevées, évaluées par des organismes en activité depuis quelques mois.
Prenez une entreprise de 40 personnes qui vend un équipement de supervision réseau pour environnements industriels. Elle relève de la classe importante I. Si les normes harmonisées de sa catégorie sont publiées et stabilisées à temps, une personne responsable en interne, à environ mi-temps, peut porter la documentation technique, la chaîne SBOM et la politique de divulgation jusqu'à la conformité. Sinon, la même entreprise fera la queue chez un organisme notifié en 2027, avec tous ceux qui ont fait le même pari, et cette capacité est limitée.
De cette asymétrie découle un argument : commencer par les éléments qui ne dépendent de personne d'autre. Votre chaîne SBOM, votre politique de divulgation des vulnérabilités, votre adresse de contact publique et votre décision sur la période d'assistance relèvent entièrement de vous, et aucun de ces points n'attend une norme. Votre processus de signalement au titre de l'article 14 est celui qui porte l'échéance ferme de 2026. Le coût dépend beaucoup plus de ce que vous devez construire de zéro que de n'importe quels frais d'évaluation. Nous ne donnons volontairement pas de montant en euros pour l'évaluation elle-même : les tarifs des organismes notifiés pour les périmètres CRA ne sont pas encore assez établis pour être annoncés sérieusement.
C'est aussi le schéma à attendre désormais : comme le règlement européen sur l'IA, le CRA réglemente ce que vous livrez et non la façon dont vous travaillez. Les équipes produit portent ainsi des obligations qui relevaient auparavant d'une fonction conformité. L'échéance de septembre 2026 représente quelques semaines de préparation pour la plupart des équipes, et un risque de responsabilité réel pour celles qui la sautent. Commencez par le processus de signalement.
Ce que Kertos apporte
Kertos est une plateforme européenne d'automatisation de la conformité. Pour le travail lié au CRA, ce sont les parties répétitives qui s'y prêtent : les preuves de contrôles qui doivent rester à jour en permanence plutôt qu'être rassemblées juste avant une évaluation, les politiques qui ont besoin d'un historique de versions et d'un responsable désigné et les processus de signalement et de divulgation qui doivent exister sous une forme que quelqu'un puisse suivre à trois heures du matin.
Ce qui compte le plus en pratique, c'est le recouvrement. La plupart des entreprises concernées par le CRA portent déjà ISO 27001, souvent aussi NIS2 ou un rapport SOC 2. Les mesures relatives au développement sécurisé, aux relations fournisseurs et à la gestion des vulnérabilités font un travail réel au regard de l'annexe I, et les points communs entre ISO 27001, le RGPD et SOC 2 expliquent pourquoi les cartographier une seule fois, plutôt qu'une fois par référentiel, évite à une petite équipe de refaire quatre fois la même collecte de preuves.
Les clients de Kertos décrivent le changement en termes commerciaux plutôt qu'en termes de conformité. Un cofondateur explique que la conformité est passée « d'un risque à un argument de vente ». C'est à peu près ce que le Cyber Resilience Act fait à la sécurité produit : il fait passer le marquage CE d'un produit connecté d'une formalité à un sujet sur lequel un service achats posera des questions. C'est la logique derrière la conformité vue comme un avantage concurrentiel.
Pour voir comment la plateforme couvre le volet preuves et contrôles, réservez une démonstration.
Questions fréquentes
Quand le Cyber Resilience Act entre-t-il en application ?
Il est entré en vigueur le 10 décembre 2024. Les obligations de signalement de l'article 14 s'appliquent depuis le 11 septembre 2026, et les autres obligations, dont l'évaluation de la conformité et le marquage CE, à partir du 11 décembre 2027. Les produits mis sur le marché avant le 11 décembre 2027 ne relèvent des exigences complètes qu'en cas de modification substantielle. L'obligation de signalement de l'article 14 les couvre dans tous les cas depuis septembre 2026.
À qui s'applique le Cyber Resilience Act ?
Aux fabricants, importateurs et distributeurs qui mettent sur le marché de l'Union des produits comportant des éléments numériques. Cela inclut les logiciels vendus seuls, et pas uniquement le matériel connecté. Les logiciels libres et open source fournis en dehors d'une activité commerciale sortent du champ d'application, et les intendants de logiciels libres et open source ont des obligations allégées et échappent au régime de sanctions.
Quelles sanctions prévoit le Cyber Resilience Act ?
L'article 64 fixe un plafond de 15 millions d'euros ou 2,5 % du chiffre d'affaires annuel mondial, le montant le plus élevé étant retenu, pour les manquements aux exigences essentielles en matière de cybersécurité ou aux obligations des fabricants des articles 13 et 14. Les autres obligations plafonnent à 10 millions d'euros ou 2 %, et la communication d'informations inexactes ou incomplètes aux autorités à 5 millions d'euros ou 1 %.
La SBOM est-elle obligatoire au titre du Cyber Resilience Act ?
Oui. L'annexe I partie II exige une nomenclature logicielle dans un format lisible par machine couramment utilisé, couvrant au minimum les dépendances de premier niveau, et elle doit rester à jour pendant toute la période d'assistance. Une couverture complète de toutes les dépendances transitives n'est pas imposée, mais elle constitue la position la plus prudente, puisque les autorités de surveillance du marché peuvent demander la SBOM que vous détenez.
Quelle est la durée de la période d'assistance au titre du Cyber Resilience Act ?
Cinq ans au minimum, sauf si la durée de vie prévue du produit est plus courte, auquel cas la période d'assistance correspond à cette durée de vie. Vous devez déterminer cette période, indiquer sa date de fin en mois et année au moment de l'achat et fournir des mises à jour de sécurité gratuites pendant toute sa durée. La documentation technique se conserve dix ans après la mise sur le marché ou pendant la période d'assistance, la période la plus longue étant retenue.
