Le Cyber Resilience Act (CRA), règlement (UE) 2024/2847, change la logique de conformité pour tous les acteurs qui mettent sur le marché des produits comportant des éléments numériques : logiciels, composants, firmware, matériel connecté ou services distants nécessaires au produit. La sécurité devient une exigence produit, suivie pendant tout le cycle de vie, avec des obligations de gestion des vulnérabilités et de signalement dès 2026.

Il ne concerne donc pas uniquement les éditeurs de logiciels dont c’est l’activité principale. Un éditeur SaaS, un fabricant industriel qui intègre du logiciel, un fournisseur de logiciel embarqué, un vendeur de composant logiciel, un distributeur sous marque propre ou une entreprise qui commercialise un produit numérique peut être concerné. 2026 n’est pas une année d’attente : c’est l’année où il faut mettre en place l’organisation de reporting, classifier les produits, préparer les preuves de conformité et sécuriser la chaîne de développement.

1. Ce que le CRA couvre vraiment

Le CRA s’applique aux produits comportant des éléments numériques mis sur le marché de l’Union européenne. La définition couvre les produits logiciels ou matériels, leurs solutions de traitement de données à distance, ainsi que les composants logiciels ou matériels mis sur le marché séparément.

En pratique, une organisation française doit se poser la question dès qu’elle développe, fait développer, fabrique, commercialise ou met à disposition sous son nom un logiciel, une application, un agent, une appliance virtuelle, une bibliothèque, un composant, un équipement connecté ou une solution qui interagit avec un produit numérique. Les produits purement internes, non mis sur le marché, ne se traitent pas de la même manière ; les logiciels libres et open source ont aussi un régime spécifique selon qu’ils sont fournis dans le cadre d’une activité commerciale ou soutenus par un steward open source.

Le CRA distingue notamment :

Catégorie Exemples Impact pour l’organisation concernée
Catégorie par défaut Applications, logiciels métiers, composants courants Conformité CRA et marquage CE, souvent avec auto-évaluation si le produit ne relève pas d’une classe supérieure.
Produits importants classe I Navigateurs, systèmes d’exploitation, gestionnaires de mots de passe, SIEM, PKI, routeurs selon la fonction principale Exigences de conformité plus structurées, avec analyse fine de la catégorie applicable.
Produits importants classe II Hyperviseurs, pare-feu, IDS/IPS, microprocesseurs ou microcontrôleurs résistants aux altérations Recours plus probable à un organisme notifié pour l’évaluation de conformité.
Produits critiques HSM, cartes à puce ou assimilées, passerelles de compteurs intelligents Niveau d’exigence le plus élevé, à anticiper très tôt avec les organismes d’évaluation.

Certains domaines sont exclus ou déjà couverts par des cadres sectoriels spécifiques, par exemple les dispositifs médicaux, certains produits automobiles, l’aviation civile, les équipements marins, la défense ou les produits développés exclusivement pour la sécurité nationale. L’analyse de périmètre doit donc être faite produit par produit, pas uniquement au niveau de l’entreprise.

2. Les obligations de sécurité pour les fabricants et créateurs de produits numériques

Le CRA impose des exigences sur deux plans : la sécurité du produit lui-même et le processus de gestion des vulnérabilités. Pour un créateur de logiciel, un fabricant ou un fournisseur de produit numérique, cela revient à transformer des bonnes pratiques DevSecOps et product security en éléments démontrables.

Sécurité dès la conception

Le fabricant doit évaluer les risques cybersécurité du produit et en tenir compte pendant la planification, la conception, le développement, la production, la livraison et la maintenance. Concrètement, cela suppose de documenter les menaces, les choix d’architecture, les hypothèses de sécurité, les dépendances critiques et les contrôles techniques.

Configuration sécurisée par défaut

Le produit doit limiter l’exposition inutile : services non indispensables désactivés, privilèges minimaux, secrets non embarqués, journalisation utile, mécanismes d’authentification robustes et durcissement des interfaces d’administration.

Gestion des vulnérabilités

L’organisation responsable du produit doit être capable de recevoir, qualifier, corriger et publier les correctifs de sécurité. Cela implique un point de contact sécurité, une politique de divulgation, un suivi des CVE si nécessaire, un processus de triage et un canal clair pour informer les clients.

Maîtrise des composants tiers

Le CRA cite explicitement la diligence sur les composants tiers, y compris open source. Un SBOM, une analyse des dépendances, une politique de mise à jour et des contrôles sur la chaîne CI/CD deviennent des preuves importantes. Le sujet n’est pas seulement de scanner les dépendances, mais de savoir quelles versions sont livrées, où elles sont utilisées et comment les corriger rapidement.

Documentation technique et conformité

Avant la mise sur le marché, le fabricant ou l’acteur qui commercialise le produit sous son nom devra produire une documentation technique, une déclaration UE de conformité et apposer le marquage CE lorsque les obligations générales seront applicables. Les preuves attendues porteront autant sur le produit que sur le processus : analyse de risques, tests, procédures de vulnérabilité, support, informations utilisateur et contrôle des changements.

3. Dates clés : ce qui arrive en 2026

Date Ce qui change Action recommandée pour l’organisation
Maintenant, avril 2026 Le règlement est déjà en vigueur depuis le 10 décembre 2024, même si l’application complète arrive plus tard. Cartographier les produits, identifier les catégories CRA, nommer un responsable conformité produit et lancer l’écart entre pratiques actuelles et exigences CRA.
11 juin 2026 Les règles relatives à la notification des organismes d’évaluation de la conformité commencent à s’appliquer au niveau européen. Si un produit peut être important classe II ou critique, identifier rapidement les besoins d’évaluation tierce et surveiller la disponibilité des organismes notifiés en France.
Juin à décembre 2026 En France, l’ANSSI prévoit l’accréditation et le début de la notification des organismes d’évaluation, sur la base d’une accréditation COFRAC. Préparer les dossiers techniques en avance : architecture, menace, tests, SBOM, processus de vulnérabilité, preuves de durcissement.
11 septembre 2026 Début des obligations de signalement des vulnérabilités activement exploitées et des incidents graves ayant un impact sur la sécurité du produit. Disposer d’une procédure opérationnelle de détection, qualification, décision, notification et communication client, testée avant cette date.
Septembre à décembre 2026 Premiers mois de fonctionnement réel du reporting CRA via la plateforme unique de signalement de l’ENISA. Faire un exercice de crise produit : vulnérabilité exploitée, correctif urgent, notification CERT-FR/ENISA, messages clients, suivi post-correctif.
11 décembre 2027 Application générale des principales obligations CRA : conformité produit, documentation, marquage CE, contrôles de marché. Avoir un système de conformité produit complet, pas un chantier lancé au dernier trimestre 2027.

4. Le reporting obligatoire à partir du 11 septembre 2026

À partir du 11 septembre 2026, les fabricants devront signaler les vulnérabilités activement exploitées et les incidents graves affectant la sécurité d’un produit comportant des éléments numériques. Le signalement se fera via la Single Reporting Platform (SRP) de l’ENISA.

Pour une entreprise établie en France, le signalement sera transmis au CSIRT coordinateur national, c’est-à-dire le CERT-FR de l’ANSSI, et simultanément à l’ENISA sauf cas exceptionnel. Les délais opérationnels à intégrer dans votre procédure sont les suivants :

  • 24 heures après prise de connaissance : alerte précoce.
  • 72 heures après prise de connaissance : notification complète.
  • 14 jours après disponibilité d’une mesure corrective : rapport final pour une vulnérabilité activement exploitée.
  • 1 mois : rapport final pour un incident grave, selon les règles applicables.

Le point critique est la notion de « prise de connaissance ». Une équipe qui découvre une exploitation active un vendredi soir ne peut pas attendre le comité de sécurité du mardi suivant pour décider si le sujet entre dans le CRA. Il faut une matrice de décision, des astreintes, des modèles de notification et une chaîne de validation courte.

5. Qui contrôle en France ?

Le CRA est un règlement européen directement applicable, mais sa mise en œuvre française mobilise plusieurs acteurs. L’ANSSI joue un rôle central comme autorité notifiante pour les organismes d’évaluation de la conformité et comme appui technique. Le CERT-FR, rattaché à l’ANSSI, est le CSIRT coordinateur pour les signalements CRA en France.

La surveillance de marché est assurée en France par l’ANFR. En cas de non-conformité, les mesures peuvent aller jusqu’au retrait du marché du produit ou à des sanctions financières. L’ANSSI indique un plafond pouvant atteindre 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial du fabricant selon les cas.

Le point à retenir : la conformité CRA ne se résume pas à un document juridique. Les autorités pourront demander des preuves techniques et organisationnelles : comment le produit a été conçu, testé, maintenu et corrigé, quel que soit le métier principal de l’entreprise qui le met sur le marché.

6. Plan d’action pour les créateurs de logiciels et produits numériques

  1. Inventorier les produits et composants commercialisés : logiciels autonomes, modules, agents, appliances, SDK, connecteurs, services de traitement distant nécessaires au produit.
  2. Classifier chaque produit : catégorie par défaut, important classe I, important classe II, critique ou hors périmètre documenté.
  3. Formaliser l’analyse de risques produit : menaces, actifs protégés, utilisateurs, interfaces exposées, dépendances, hypothèses de déploiement.
  4. Mettre en place une gestion de vulnérabilités vérifiable : point de contact, politique de divulgation, triage, SLA internes, correctifs, advisory, conservation des preuves.
  5. Produire et maintenir un SBOM : dépendances directes et transitives, versions livrées, licences, vulnérabilités connues, capacité de patch rapide.
  6. Sécuriser la CI/CD : revues de code, SAST, SCA, détection de secrets, signatures ou contrôles d’intégrité, séparation des droits, traçabilité des releases.
  7. Préparer le reporting 2026 : procédure 24h/72h, rôles, astreinte, modèles de décision, test de simulation avant le 11 septembre 2026.
  8. Préparer la documentation de conformité : architecture, tests, preuves de durcissement, documentation utilisateur, support period, déclaration de conformité.

Pour les organisations déjà engagées dans SOC 2, ISO 27001, SecNumCloud, NIS2 ou un programme AppSec mature, une partie des contrôles existe souvent déjà. Le travail CRA consiste alors à rattacher ces contrôles au produit, à la version livrée et aux obligations de mise sur le marché.

7. Erreurs fréquentes à éviter

  • Attendre décembre 2027 : le reporting démarre en septembre 2026, et les dossiers techniques ne se construisent pas après coup.
  • Traiter le CRA comme une conformité purement juridique : les preuves attendues sont aussi techniques.
  • Confondre scan de vulnérabilités et gestion des vulnérabilités : il faut aussi qualifier, corriger, communiquer et tracer.
  • Oublier les composants open source : un composant intégré dans un produit commercial reste une responsabilité de l’acteur qui met ce produit sur le marché.
  • Ne pas définir la période de support : le CRA attend une gestion des vulnérabilités pendant la période de support du produit.

Sources officielles utiles

Conclusion

Pour les créateurs de logiciels, fabricants et fournisseurs de produits numériques en France, 2026 est le vrai démarrage opérationnel du CRA. Le 11 juin 2026 structure l’écosystème des organismes notifiés ; le 11 septembre 2026 impose le reporting des vulnérabilités activement exploitées et des incidents graves ; le 11 décembre 2027 rendra les obligations générales pleinement applicables.

Le bon angle d’attaque est simple : partir du portefeuille produit, documenter les risques, durcir le SDLC, organiser la gestion des vulnérabilités et tester le processus de notification avant septembre 2026. C’est ce qui fera la différence entre une conformité subie et une sécurité produit maîtrisée.

Pour structurer cette préparation, voir aussi nos ressources sur la sécurité du code et de la CI/CD, les liens entre pentest et conformité, et nos services d’audit et de pentest.