Cyber Resilience Act (CRA) : obligations, calendrier et sanctions pour les fabricants
de logiciels

Vous éditez un logiciel, une brique IoT ou un firmware, et vous le vendez en Europe. Jusqu'ici, la sécurité de votre produit relevait de votre bonne volonté, de la pression de vos clients et, au mieux, d'un audit de temps en temps. Ce temps-là se termine. Avec le Cyber Resilience Act (règlement UE 2024/2847), l'Union européenne fait de la cybersécurité une condition d'accès au marché : pas conforme, pas de marquage CE, donc interdiction de vendre. Et derrière, des amendes qui montent à 15 millions d'euros ou 2,5 % du chiffre d'affaires mondial.

Le texte est déjà en vigueur, mais ses obligations s'étalent dans le temps. Beaucoup d'équipes ont coché « décembre 2027 » dans un coin de leur tête et sont passées à autre chose. C'est une erreur, car la première échéance qui mord tombe bien avant : dès septembre 2026. Cet article fait le tri : qui est concerné (et qui ne l'est pas), le calendrier exact article par article, ce que le règlement exige concrètement, ce que vous risquez, et par où commencer sans se noyer.

Qui est concerné par le Cyber Resilience Act ?

Le CRA s'applique aux produits comportant des éléments numériques (products with digital elements) mis à disposition sur le marché de l'Union. La formule est large à dessein : elle couvre aussi bien le matériel que le logiciel, dès lors qu'il y a une connexion de données, directe ou indirecte, avec un appareil ou un réseau. Un logiciel de gestion vendu en licence, un routeur, une caméra connectée, une application mobile, une bibliothèque commerciale, un système d'exploitation : tous entrent dans le champ.

Le règlement vise plusieurs acteurs de la chaîne, mais fait peser l'essentiel des obligations sur le fabricant (le manufacturer, celui qui développe ou fait développer le produit et le commercialise sous son nom). Les importateurs et distributeurs héritent d'obligations de vérification : ils doivent s'assurer que le produit qu'ils mettent sur le marché porte bien le marquage CE et sa documentation. Point important pour les éditeurs hors UE : le CRA s'applique quel que soit le lieu d'établissement. Vendre dans l'Union depuis les États-Unis ou l'Inde suffit à être dans le périmètre, et il faudra désigner un opérateur économique responsable établi dans l'UE.

Le cas SaaS : concerné ou pas ?

C'est la question qui revient sans cesse, et la réponse mérite d'être précise. Un logiciel distribué en mode SaaS (une application accessible à distance, sans logiciel installé chez le client) n'est pas couvert par le CRA en tant que tel. Le service en ligne pur relève plutôt de NIS2. Mais l'exclusion connaît une exception nette : les solutions de traitement de données à distance (remote data processing solutions). Si une partie de votre traitement s'exécute côté serveur et qu'elle est nécessaire au bon fonctionnement d'un produit avec éléments numériques (par exemple le back-end sans lequel votre objet connecté ne marche pas), alors cette composante distante est traitée comme une partie du produit et tombe, elle, sous le CRA.

Les exclusions

Certains produits sortent du champ parce qu'ils sont déjà couverts par une réglementation sectorielle : les dispositifs médicaux, les véhicules à moteur, l'aviation civile, ou encore les produits développés à des fins de sécurité nationale et de défense. Le logiciel libre développé hors activité commerciale est très largement hors périmètre ; les stewards open source (fondations, mainteneurs organisés) héritent en revanche d'un jeu d'obligations allégé et sur mesure. Le mot qui compte est « commercial » : une dépendance open source que vous intégrez dans un produit vendu reste, elle, pleinement de votre responsabilité de fabricant.

Le calendrier réel du CRA : trois dates à retenir

Le règlement est entré en vigueur le 10 décembre 2024, mais ses obligations ne se déclenchent pas d'un bloc. Elles arrivent en trois vagues, et confondre ces dates coûte cher. Voici la seule chronologie qui compte :

  CYBER RESILIENCE ACT — calendrier d'application

  10 déc. 2024  ┃ Entrée en vigueur du règlement (UE) 2024/2847.
                ┃ Le compte à rebours démarre. Rien à faire encore,
                ┃ tout à préparer.
                ┃
  11 juin 2026  ┃ Entrée en application des règles sur les organismes
                ┃ d'évaluation de la conformité (organismes notifiés).
                ┃ La "tuyauterie" de certification se met en place.
                ┃
  11 sept. 2026 ┃ >>> OBLIGATIONS DE SIGNALEMENT (article 14) <<<
                ┃ Signaler à l'ENISA + CSIRT national toute vuln.
                ┃ ACTIVEMENT EXPLOITÉE et tout incident grave.
                ┃ S'applique AUSSI aux produits DÉJÀ sur le marché.
                ┃
  11 déc. 2027  ┃ Application PLEINE : exigences essentielles,
                ┃ évaluation de conformité, marquage CE, doc technique.
                ┃ Pas conforme = interdit à la vente.

La vague qu'on sous-estime, c'est celle du 11 septembre 2026. À cette date, l'article 14 du règlement impose de signaler les vulnérabilités activement exploitées et les incidents graves. Et contrairement au reste du texte, cette obligation frappe aussi les produits déjà sur le marché. Vous ne pouvez donc pas vous dire « je m'occuperai du CRA pour mes prochaines versions » : dès l'automne 2026, chaque produit que vous vendez peut déclencher l'obligation de signalement. Un produit mis sur le marché avant décembre 2027 ne bascule dans le régime complet (marquage CE, conformité) que s'il subit une modification substantielle après cette date, mais le signalement, lui, s'applique dans tous les cas.

Les obligations de signalement (article 14) : le compte à rebours de 24 heures

C'est la partie la plus opérationnelle, et celle qui prend le plus d'équipes de court. Dès qu'un fabricant a connaissance qu'une vulnérabilité de son produit est activement exploitée (ou qu'un incident grave affecte la sécurité du produit), une horloge démarre. Le signalement passe par la plateforme de signalement unique de l'ENISA, avec relais vers le CSIRT national du pays où le fabricant a son établissement principal. La cadence est stricte et se déroule en trois temps :

Vingt-quatre heures, ce n'est pas un délai que l'on improvise le jour venu. Il faut une chaîne d'escalade définie à l'avance : qui détecte, qui qualifie une exploitation active, qui décide, qui rédige et soumet le signalement. Il faut aussi savoir, à l'instant où l'alerte tombe, quels produits et quelles versions embarquent le composant vulnérable, sur quels marchés ils ont été mis à disposition. Sans cet inventaire, les 24 heures s'évaporent en réunions de crise. C'est précisément là que la connaissance de sa surface d'exposition et de sa chaîne d'approvisionnement logicielle cesse d'être un confort pour devenir une obligation de fait.

Les exigences essentielles : la sécurité par défaut, pour de vrai

Le cœur du CRA se trouve dans son annexe I, qui liste les exigences essentielles de cybersécurité. Elle se lit en deux parties : les propriétés du produit (partie I) et les processus de traitement des vulnérabilités (partie II). L'esprit est simple à énoncer, plus exigeant à tenir : un produit doit être sûr par conception et par défaut, et le rester pendant toute sa vie.

Partie I : les propriétés attendues du produit

• Aucune vulnérabilité exploitable connue à la sortie. On ne livre pas un produit avec des failles déjà documentées non corrigées. C'est le socle : le fameux secure by default n'est plus un slogan marketing, c'est une condition de mise sur le marché.
• Configuration sécurisée par défaut. Pas de mot de passe d'usine trivial, pas de service ouvert inutilement, possibilité de réinitialiser à un état sûr. Le produit sort de la boîte durci, pas à durcir.
• Surface d'attaque minimisée. On réduit les interfaces exposées, on désactive ce qui ne sert pas, on applique le moindre privilège.
• Protection des données et contrôle d'accès. Confidentialité et intégrité par le chiffrement, authentification robuste, journalisation des accès et des événements de sécurité pertinents.

Partie II : le traitement des vulnérabilités dans la durée

• Un SBOM (Software Bill of Materials). Le fabricant doit établir et tenir à jour un inventaire lisible par machine de tous les composants du produit, y compris les dépendances open source et les bibliothèques tierces. C'est la pièce qui, le jour d'une alerte type Log4Shell, vous dit en minutes (et non en semaines) si vous êtes touché et où. Formellement rattaché aux exigences 2027, le SBOM est en pratique le prérequis du signalement de 2026 : sans lui, impossible de tenir les 24 heures.
• Corriger sans délai. Les vulnérabilités identifiées doivent être traitées et remédiées via des mises à jour de sécurité, distribuées gratuitement et de façon sécurisée (mises à jour signées, canal fiable, idéalement automatiques).
• Tester régulièrement. Le règlement attend des revues et des tests de sécurité réguliers du produit. C'est l'articulation naturelle avec l'analyse statique, l'analyse dynamique et le test d'intrusion : prouver, pas supposer.
• Une politique de divulgation coordonnée. Un point de contact public, un processus pour recevoir et traiter les signalements de chercheurs, et la diffusion d'informations sur les vulnérabilités corrigées (avis de sécurité).
• Une période de support définie et publiée. L'article 13 fixe une durée minimale de cinq ans à compter de la mise sur le marché (moins seulement si la durée de vie attendue du produit est plus courte). Pendant tout le support, le fabricant fournit des mises à jour de sécurité. Fini le produit vendu puis abandonné au bout de dix-huit mois.

Évaluation de conformité et classes de produits

Tous les produits ne subissent pas le même niveau de contrôle. Le CRA les range par criticité, et le mode d'évaluation de la conformité en découle :

• Produits par défaut (la grande majorité) : auto-évaluation. Le fabricant vérifie lui-même la conformité, rédige la documentation technique, appose le marquage CE et signe une déclaration UE de conformité.
• Produits importants (classes I et II de l'annexe III) : gestionnaires de mots de passe, VPN, navigateurs, antivirus, microcontrôleurs, etc. La classe I peut passer par des normes harmonisées ; à défaut, ou pour la classe II, l'intervention d'un organisme notifié (évaluation tierce) est requise.
• Produits critiques (annexe IV) : le niveau le plus strict, avec possibilité d'imposer une certification européenne de cybersécurité.

Savoir dans quelle classe tombe votre produit conditionne l'effort et le délai : une auto-évaluation se pilote en interne, une évaluation par organisme notifié se planifie des mois à l'avance. C'est l'une des premières questions à trancher.

Les sanctions : jusqu'à 15 millions d'euros

Le CRA n'est pas une recommandation. Le règlement gradue les amendes administratives selon la gravité du manquement, et les plafonds sont dissuasifs :

• Jusqu'à 15 M€ ou 2,5 % du chiffre d'affaires mondial annuel (le plus élevé des deux) pour le non-respect des exigences essentielles de l'annexe I et des obligations des articles 13 et 14.
• Jusqu'à 10 M€ ou 2 % pour le non-respect des autres obligations du règlement (documentation, marquage, etc.).
• Jusqu'à 5 M€ ou 1 % pour la fourniture d'informations incorrectes, incomplètes ou trompeuses aux organismes notifiés ou aux autorités de surveillance.

Au-delà de l'amende, la sanction la plus concrète reste commerciale : une autorité de surveillance du marché peut exiger le retrait ou le rappel d'un produit non conforme. Perdre l'accès au marché européen fait bien plus mal, pour la plupart des éditeurs, qu'une ligne dans le compte de résultat.

CRA, NIS2 et DORA : comment ça s'articule

Ces trois textes forment le socle réglementaire cyber de l'Union, et ils se complètent plus qu'ils ne se répètent. Le point de bascule pour ne pas s'emmêler : le CRA vise le produit, NIS2 vise l'organisation, DORA vise le secteur financier.

• CRA vs NIS2. Le CRA impose une sécurité de base au niveau du produit, là où la directive NIS2 impose une gestion des risques et une gouvernance au niveau de l'entité (mesures organisationnelles, signalement d'incidents, responsabilité des dirigeants). Un éditeur peut être fabricant au sens du CRA et entité essentielle ou importante au sens de NIS2 : il cumule alors les deux régimes. Bonne nouvelle : la définition d'« incident » du CRA est empruntée à NIS2, ce qui limite la divergence des processus.
• CRA vs DORA. Le règlement DORA régit la résilience opérationnelle numérique des acteurs financiers, avec notamment ses tests d'intrusion avancés (TLPT). Si vous fournissez un logiciel à une banque, votre produit relève du CRA, tandis que votre client financier vous verra comme un prestataire TIC critique sous l'angle DORA.

Le point commun de ces trois textes ? Aucun ne se satisfait de bonnes intentions : tous réclament des preuves. Si votre organisation est déjà engagée dans une mise en conformité NIS2, l'essentiel de la démarche CRA s'y greffe ; le détail de cette continuité est développé dans notre article sur l'audit NIS2 par le pentest.

Par où commencer concrètement

La conformité CRA ne se décrète pas la veille de l'échéance. Elle se construit, et elle commence toujours par la même étape : savoir ce qu'on a. On ne protège, on ne documente et on ne signale que ce que l'on connaît.

• Inventorier les produits et leurs versions. Quels produits avec éléments numériques mettez-vous sur le marché européen ? Lesquels embarquent une composante distante « nécessaire » ? La cartographie de votre surface d'attaque externe révèle souvent des actifs exposés que personne ne rattachait plus à un produit maintenu, et c'est exactement le genre d'angle mort que le CRA ne pardonne pas.
• Établir le SBOM et surveiller les composants. L'analyse de composition logicielle (SCA) génère l'inventaire des dépendances et vous alerte quand l'une d'elles devient vulnérable. C'est le moteur du signalement à 24 heures : notre module d'analyse de composition logicielle tient ce SBOM à jour et le corrèle en continu aux vulnérabilités publiées.
• Tester pour prouver, pas pour se rassurer. Les revues et tests réguliers de l'annexe I trouvent leur meilleure réponse dans un pentest web qui exerce réellement le produit et documente ce qu'il casse. Pour comprendre pourquoi un scan automatisé ne suffit pas à cet égard, voyez pentest vs scan de vulnérabilité.
• Formaliser les processus. Politique de divulgation coordonnée, chaîne d'escalade pour le signalement, période de support publiée, mécanisme de mise à jour signée. C'est la part la moins technique et la plus souvent négligée : sans elle, aucune preuve technique ne suffit.

À retenir

• Le Cyber Resilience Act (règlement UE 2024/2847) impose la cybersécurité par défaut à tout produit avec éléments numériques vendu dans l'UE ; le SaaS pur en est exclu, sauf les solutions de traitement de données à distance nécessaires à un produit.
• Trois dates : entrée en vigueur le 10 décembre 2024, signalement des vulnérabilités exploitées dès le 11 septembre 2026 (y compris pour les produits déjà vendus), application pleine le 11 décembre 2027.
• L'article 14 impose une cadence de signalement stricte : 24 h (alerte), 72 h (notification), 14 jours (rapport final), via la plateforme unique de l'ENISA.
• Les exigences essentielles (annexe I) réclament sécurité par défaut, SBOM, mises à jour gratuites, divulgation coordonnée et une période de support d'au moins cinq ans (article 13).
• Les sanctions montent à 15 M€ ou 2,5 % du CA mondial, et une autorité peut exiger le retrait du produit : perdre le marché UE fait souvent plus mal que l'amende.
• CRA (produit), NIS2 (organisation) et DORA (finance) se cumulent : une démarche de conformité déjà lancée sert de socle aux autres.

La bonne nouvelle, c'est que la première marche du CRA (savoir ce que vous exposez et de quoi vos produits sont faits) est aussi celle qui rend tout le reste possible. C'est le métier d'own2pwn : cartographier votre surface, inventorier vos composants et prouver, par le test, que vos produits tiennent. Si vous voulez cadrer votre échéance CRA avec quelqu'un qui parle autant règlement que technique, la page contact vous met en lien direct avec un pentester.