Le CRA en bref
Le règlement (UE) 2024/2847, dit Cyber Resilience Act, a été publié au Journal officiel de l'UE le 20 novembre 2024 et est entré en vigueur le 10 décembre 2024. Jusqu'ici, la réglementation cyber européenne visait des organisations (NIS2, DORA) ou des données (RGPD). Le CRA vise le produit : tout matériel ou logiciel comportant des éléments numériques mis sur le marché européen devra être conçu, développé et maintenu selon des exigences de cybersécurité vérifiables, avec marquage CE à la clé.
Pour un éditeur, le changement de logique est réel : la sécurité du produit devient une condition d'accès au marché, au même titre que la sécurité électrique d'un appareil. Et contrairement à NIS2, il n'y a pas de seuil de taille : une PME de 5 personnes qui édite un logiciel distribué est dans le périmètre.
Le calendrier : trois dates à retenir
Le règlement (UE) 2024/2847 est en vigueur. Aucune obligation opérationnelle à cette date, mais le compte à rebours démarre.
Les règles de notification des organismes d’évaluation de la conformité (chapitre IV) s’appliquent, pour que les évaluateurs tiers soient prêts avant l’échéance principale.
Signalement des vulnérabilités activement exploitées et des incidents graves : alerte sous 24 h, notification sous 72 h, rapport final sous 14 jours ou 1 mois.
Exigences essentielles de l’annexe I, documentation technique, évaluation de conformité et marquage CE pour tout produit mis sur le marché.
L'échéance qui approche est celle du 11 septembre 2026. Elle est souvent sous-estimée parce qu'elle ne porte pas sur la conception du produit : elle porte sur votre capacité à réagir et notifier en heures. C'est une obligation de processus, et un processus ne s'improvise pas le jour de l'incident.
Êtes-vous concerné ?
Le CRA s'applique aux « produits comportant des éléments numériques » mis à disposition sur le marché de l'UE dans le cadre d'une activité commerciale : logiciels vendus ou distribués (applications de bureau, apps mobiles, clients lourds, agents installés, firmwares), matériel connecté, et bibliothèques ou composants commerciaux intégrés à d'autres produits.
Trois cas limites concentrent l'essentiel des questions que nous recevons :
- Le SaaS pur est hors périmètre CRA. Un service accessible uniquement par navigateur relève de NIS2 le cas échéant, pas du CRA. Mais dès qu'un éditeur SaaS distribue aussi un composant installé (app mobile, agent de collecte, CLI, connecteur on-premise), ce composant est un produit au sens du CRA.
- Le traitement de données à distance intégré au produit est couvert. Si votre objet connecté ou votre application dépend d'un back-end cloud pour fonctionner, ce back-end entre dans le périmètre de sécurité du produit.
- L'open source non commercial est largement exempté, avec un régime allégé pour les fondations et mainteneurs (« open-source stewards »). En revanche, monétiser un logiciel open source (support payant, version entreprise) ramène dans le régime général.
Le 11 septembre 2026 : l'obligation de signalement
À partir de cette date, l'article 14 impose aux fabricants de signaler deux types d'événements : toute vulnérabilité activement exploitée affectant leur produit, et tout incident grave ayant un impact sur la sécurité du produit. Le signalement se fait auprès du CSIRT désigné coordinateur (en France, le CERT-FR rattaché à l'ANSSI) et de l'ENISA, via une plateforme de signalement unique.
Le processus est en trois temps, sur le modèle de NIS2 :
- Alerte précoce sous 24 heures après avoir eu connaissance de l'exploitation active ou de l'incident.
- Notification détaillée sous 72 heures, avec l'évaluation de la vulnérabilité, les mesures correctives ou d'atténuation disponibles.
- Rapport final : sous 14 jours après disponibilité d'un correctif pour une vulnérabilité, sous 1 mois pour un incident.
À noter : l'obligation couvre les vulnérabilités exploitées dans votre produit chez vos clients, pas seulement un incident sur votre propre infrastructure. Cela suppose de savoir ce qui se passe sur le terrain : canal de remontée client, veille sur les composants embarqués, et politique de divulgation coordonnée pour que les chercheurs puissent vous joindre.
Ce qui reste dû pour décembre 2027
L'application générale du 11 décembre 2027 porte sur les exigences essentielles de l'annexe I. Les plus structurantes pour un éditeur :
- Livrer les produits sans vulnérabilité exploitable connue et avec une configuration sécurisée par défaut.
- Maintenir un processus de gestion des vulnérabilités : identification, traitement sans délai, tests de sécurité réguliers, divulgation coordonnée.
- Établir et tenir à jour un SBOM (inventaire des composants logiciels) dans un format machine-readable.
- Fournir des mises à jour de sécurité gratuites pendant la période de support, au minimum 5 ans sauf durée de vie plus courte du produit.
- Constituer la documentation technique et passer l'évaluation de conformité : auto-évaluation pour la majorité des produits, évaluation tierce pour les catégories importantes (classe I et II) et critiques.
Les sanctions suivent le modèle des règlements récents : jusqu'à 15 M€ ou 2,5 % du chiffre d'affaires annuel mondial pour le non-respect des exigences essentielles.
Par où commencer : six chantiers dans l'ordre
01Cartographier ce qui relève du CRA
Listez vos produits distribués : applications installées, clients lourds, apps mobiles, agents, firmwares, bibliothèques commerciales. Séparez ce qui est du SaaS pur (NIS2) de ce qui est mis sur le marché comme produit.
02Mettre en place un canal de signalement de vulnérabilités
Une politique de divulgation coordonnée (CVD), un point de contact publié, et un processus interne qui route une vulnérabilité critique vers la direction en heures, pas en semaines. C’est aussi une exigence de l’annexe I.
03Préparer le processus 24 h / 72 h
Le délai de 24 heures ne se tient pas sans préparation : qui qualifie l’exploitation active, qui notifie, avec quelles informations. Un runbook testé une fois à blanc vaut mieux qu’une procédure écrite jamais déroulée.
04Produire un SBOM et suivre les composants
L’inventaire des composants logiciels (SBOM) au format machine-readable devient un livrable attendu. Commencez par vos produits phares : la chaîne de dépendances est souvent là où les vulnérabilités arrivent.
05Tester la sécurité du produit et documenter les preuves
L’annexe I attend des produits livrés sans vulnérabilité exploitable connue et des tests réguliers. Un pentest applicatif documenté, avec re-test des corrections, constitue la preuve la plus directe pour le dossier technique.
06Planifier le support et les mises à jour de sécurité
Les correctifs de sécurité doivent être fournis gratuitement pendant la période de support (5 ans par défaut, sauf durée de vie plus courte du produit). Cela se budgète et se contractualise dès maintenant.
Le point commun des chantiers 2, 3 et 5 : ils produisent des preuves. C'est là que le test d'intrusion s'insère naturellement dans une préparation CRA. Un pentest applicatif documenté démontre que le produit a été testé contre les vulnérabilités exploitables connues, le re-test prouve que les corrections tiennent, et le rapport alimente directement la documentation technique. Pour un éditeur qui vend à des grands comptes, ces mêmes preuves servent déjà aux questionnaires sécurité : le CRA ne fait que rendre obligatoire ce que vos acheteurs demandent déjà.
Questions fréquentes
Mon SaaS est-il concerné ?
En principe non : le SaaS pur relève de NIS2. Mais vérifiez vos composants distribués (app mobile, agent, CLI, connecteur on-premise) : eux sont des produits au sens du CRA. Et si votre service est le back-end indispensable d'un produit connecté, il entre dans le périmètre de ce produit.
Le pentest est-il obligatoire ?
Le règlement n'impose pas le mot, il impose le résultat : des produits livrés sans vulnérabilité exploitable connue et testés régulièrement. Le pentest documenté est le moyen le plus direct de produire cette preuve.
Que risque un éditeur qui ignore l'échéance de septembre 2026 ?
Le non-respect des obligations de signalement expose aux sanctions administratives du règlement, mais le risque le plus immédiat est commercial : les distributeurs et importateurs ont leurs propres obligations de vigilance et commenceront à demander des garanties CRA à leurs fournisseurs, comme les donneurs d'ordre le font déjà avec NIS2.
Sources
- Règlement (UE) 2024/2847 (Cyber Resilience Act), EUR-Lex : texte intégral, calendrier d'application à l'article 71.
- Commission européenne, Cyber Resilience Act : page officielle, guides et actes d'exécution.
- ENISA : plateforme de signalement unique prévue par l'article 16.