NIS2 & DORA en vigueur. EU AI Act arrive — réservez une démo
Tous les référentiels
Cadre réglementaire

Conformite Cyber Resilience Act, entierement automatisee

Le CRA impose la cybersecurite pour tous les produits comportant des elements numeriques vendus dans l'UE. Matproof couvre la securite des la conception, la gestion des vulnerabilites, la gestion des SBOM, le signalement a l'ENISA et l'evaluation de conformite.

Demander une démo

Qu'est-ce que le Cyber Resilience Act (CRA) ?

Le Cyber Resilience Act (Reglement 2024/2847) est un reglement europeen etablissant des exigences horizontales de cybersecurite pour les produits comportant des elements numeriques - englobant a la fois le materiel et le logiciel vendus sur le marche europeen. Publie au Journal officiel le 20 novembre 2024, il repond aux risques croissants de cybersecurite poses par les produits connectes, des appareils domestiques intelligents et routeurs aux systemes d'exploitation et logiciels de controle industriel.

Le CRA comble une lacune reglementaire importante : alors que les cadres existants de l'UE traitent de la securite des reseaux et de l'information (NIS2) et de la resilience sectorielle (DORA), aucune reglementation horizontale n'exigeait auparavant que la cybersecurite soit integree des la conception des produits. Le CRA impose aux fabricants, importateurs et distributeurs de s'assurer que les produits respectent les exigences essentielles de cybersecurite tout au long de leur cycle de vie, y compris la gestion continue des vulnerabilites et les mises a jour de securite.

Les obligations cles comprennent la securite des la conception et par defaut (Annex I Partie I), la gestion systematique des vulnerabilites (Annex I Partie II), la maintenance de la nomenclature logicielle (SBOM), le signalement rapide des vulnerabilites a l'ENISA et aux CSIRT nationaux, les mises a jour de securite gratuites pendant la periode de support du produit (minimum 5 ans) et l'evaluation de conformite avec marquage CE. Les produits sont classes en categories par defaut, Classe I, Classe II et critique, avec un niveau d'evaluation croissant.

Le CRA suit une mise en oeuvre progressive : les obligations de signalement des vulnerabilites s'appliquent a partir du 11 septembre 2026, et le reglement complet s'applique a partir du 11 decembre 2027. Cela donne aux fabricants le temps d'adapter leurs processus de developpement de produits, d'etablir des workflows de gestion des vulnerabilites et de se preparer aux evaluations de conformite.

Qui doit se conformer au CRA ?

Le CRA s'applique a tous les operateurs economiques impliques dans la mise sur le marche de l'UE de produits comportant des elements numeriques. Un produit comportant des elements numeriques est tout produit logiciel ou materiel et ses solutions de traitement de donnees a distance incluant une connexion directe ou indirecte, logique ou physique, a un appareil ou un reseau :

Fabricants

  • Fabricants de materiel (appareils IoT, routeurs, produits domotiques)
  • Developpeurs de logiciels (applications, systemes d'exploitation, micrologiciels)
  • Fabricants de systemes embarques (controleurs industriels, ECU automobiles)
  • Fournisseurs SaaS dont le logiciel est un composant du produit
  • Responsables de logiciels open source (fondations commerciales)
  • Entreprises integrant des composants tiers dans leurs produits

Importateurs et distributeurs

  • Importateurs UE de produits fabriques hors UE
  • Distributeurs mettant des produits sur le marche de l'UE
  • Places de marche en ligne vendant des produits comportant des elements numeriques
  • Integrateurs systemes assemblant des produits a partir de composants
  • Revendeurs de logiciels et de materiel
  • Distributeurs de produits en marque blanche

Les services SaaS purs qui n'impliquent pas la mise sur le marche d'un produit sont generalement exclus du champ du CRA (ils peuvent relever de NIS2). Cependant, si le SaaS inclut des composants logiciels telechargeables, des micrologiciels ou une integration d'appareils IoT, ces elements sont concernes. Les logiciels open source developpes dans un contexte non commercial sont egalement exclus, bien que les responsables de logiciels open source (par ex. les fondations commerciales maintenant des bibliotheques critiques) aient des obligations specifiques au titre de l'Article 25.

Not sure if you're compliant?

Take the free CRA readiness assessment — 10 questions, 3 minutes.

Check your readiness

Exigences cles du CRA

1. Exigences essentielles de cybersecurite (Annex I Partie I)

Les produits doivent etre concus, developpes et fabriques pour assurer un niveau de cybersecurite adapte a leurs risques. Cela inclut : aucune vulnerabilite exploitable connue au moment de la mise sur le marche, configuration securisee par defaut sans mots de passe par defaut, protection de la confidentialite et de l'integrite des donnees, minimisation du traitement des donnees, mecanismes de controle d'acces, minimisation de la surface d'attaque, enregistrement des informations pertinentes pour la securite et mecanisme de mise a jour securise. Les produits doivent egalement etre resilients face aux attaques par deni de service.

2. Gestion des vulnerabilites (Annex I Partie II)

Les fabricants doivent etablir et maintenir un processus systematique d'identification, de documentation et de remediation des vulnerabilites tout au long du cycle de vie du produit. Cela inclut des tests de securite reguliers, une remediation rapide par des mises a jour de securite gratuites, une politique de divulgation coordonnee des vulnerabilites pour les chercheurs externes, la divulgation publique des vulnerabilites corrigees avec identifiants CVE, des mecanismes de partage d'informations sur les vulnerabilites et un mecanisme de distribution securisee des mises a jour. Les correctifs doivent etre fournis gratuitement et sans retard indu.

3. Gestion des SBOM (Annex I.2(9))

Les fabricants doivent generer et maintenir une nomenclature logicielle (SBOM) documentant toutes les dependances de premier niveau, les composants, les bibliotheques et le code tiers inclus dans leurs produits. Le SBOM permet une evaluation rapide des vulnerabilites lors de la publication de nouveaux CVE, la transparence de la chaine d'approvisionnement et le signalement reglementaire. Il doit etre mis a jour tout au long de la periode de support du produit et mis a la disposition des autorites de surveillance du marche sur demande.

4. Signalement des vulnerabilites a l'ENISA (Article 14)

Lorsqu'un fabricant a connaissance d'une vulnerabilite activement exploitee ou d'un incident de securite grave, il doit le signaler au CSIRT designe et a l'ENISA selon des delais stricts : une alerte precoce dans les 24 heures suivant la prise de connaissance, une notification detaillee de la vulnerabilite dans les 72 heures incluant l'evaluation de la severite et l'etat de la remediation, et un rapport final dans les 14 jours. Les utilisateurs doivent egalement etre informes sans retard indu de la vulnerabilite et des mesures correctives disponibles.

5. Evaluation de conformite et marquage CE (Articles 28-32)

Avant de mettre un produit sur le marche de l'UE, les fabricants doivent realiser une evaluation de conformite, preparer une Declaration de conformite UE (Annex V) et apposer le marquage CE. Les produits par defaut peuvent utiliser l'auto-evaluation (Annex VI Partie I). Les produits de Classe I (Annex III - par ex. gestion d'identite, VPN, pare-feu) necessitent la conformite aux normes harmonisees ou une evaluation par un tiers. Les produits de Classe II (Annex IV - par ex. systemes d'exploitation, compteurs intelligents) necessitent une evaluation obligatoire par un tiers. Les produits critiques necessitent un examen de type UE.

6. Periode de support du produit (Article 13(7))

Les fabricants doivent definir et communiquer la periode de support du produit pendant laquelle ils fourniront des mises a jour de securite - au minimum 5 ans ou la duree de vie prevue du produit, selon la plus longue. Pendant cette periode, toutes les mises a jour de securite doivent etre fournies gratuitement et sans retard indu. La periode de support doit etre clairement communiquee aux utilisateurs au moment de l'achat. Les fabricants doivent egalement planifier et executer des transitions responsables de fin de vie lorsque le support prend fin.

7. Documentation technique (Annex VII)

Les fabricants doivent maintenir une documentation technique complete couvrant : la description du produit et son usage prevu, l'evaluation des risques de cybersecurite, les informations de conception et de developpement incluant l'architecture et les flux de donnees, les informations sur les processus de gestion des vulnerabilites, les normes harmonisees ou specifications communes appliquees, les resultats de l'evaluation de conformite et les preuves du respect des exigences essentielles. La documentation doit etre conservee pendant 10 ans ou la periode de support, selon la plus longue.

Sanctions en cas de non-conformite au CRA

Le CRA etablit un cadre de sanctions echelonne applique par les autorites nationales de surveillance du marche. Les sanctions sont calculees comme le montant le plus eleve entre un montant fixe et un pourcentage du chiffre d'affaires annuel mondial :

Jusqu'a 15 M EUR / 2,5 %

pour le non-respect des exigences essentielles de cybersecurite (Annex I) - la categorie la plus severe

Jusqu'a 10 M EUR / 2 %

pour le non-respect des autres obligations du fabricant, y compris le signalement des vulnerabilites et l'evaluation de conformite

Jusqu'a 5 M EUR / 1 %

pour la fourniture d'informations incorrectes, incompletes ou trompeuses aux autorites de surveillance du marche ou aux organismes notifies

Retrait du marche

les autorites peuvent ordonner le retrait du produit, le rappel ou la restriction de disponibilite sur le marche de l'UE jusqu'a l'atteinte de la conformite

Les autorites de surveillance du marche disposent de larges pouvoirs incluant la capacite de realiser des tests de produits, de demander de la documentation, d'acceder aux locaux et d'emettre des mesures correctives contraignantes. Les produits non conformes peuvent etre interdits du marche de l'UE dans leur integralite. Pour les responsables de logiciels open source, les sanctions sont proportionnees a leur taille et part de marche.

Comment se preparer a la conformite CRA

Avec les obligations de signalement des vulnerabilites a partir du 11 septembre 2026 et l'application complete a partir du 11 decembre 2027, les fabricants doivent commencer leur preparation des maintenant :

  1. 1

    Inventaire et classification des produits

    Creez un inventaire complet de tous les produits comportant des elements numeriques. Classifiez chaque produit selon les categories du CRA : par defaut, Classe I (Annex III), Classe II (Annex IV) ou critique. Identifiez la procedure d'evaluation de conformite appropriee pour chaque classe de produit.

  2. 2

    Generation de SBOM et cartographie des dependances

    Mettez en place la generation automatisee de SBOM pour tous les produits. Documentez tous les composants, bibliotheques et dependances. Croisez avec les bases de donnees CVE et mettez en place une surveillance continue des vulnerabilites nouvellement divulguees dans votre chaine d'approvisionnement logicielle.

  3. 3

    Processus de gestion des vulnerabilites

    Etablissez un processus systematique de gestion des vulnerabilites couvrant l'identification, la documentation, la remediation et la divulgation. Mettez en place des canaux de divulgation coordonnee des vulnerabilites. Developpez la capacite a respecter les delais de signalement ENISA de 24 h/72 h/14 j. Testez le processus avec des scenarios de vulnerabilite simules.

  4. 4

    Integration de la securite des la conception

    Integrez les exigences essentielles de cybersecurite du CRA dans votre cycle de developpement produit. Mettez en place des configurations securisees par defaut, un controle d'acces, une minimisation de la surface d'attaque et des mecanismes de mise a jour securises. Effectuez des tests de securite tout au long du developpement, pas seulement avant la mise en production.

  5. 5

    Preparation a l'evaluation de conformite

    Preparez la documentation technique conformement a l'Annex VII. Pour les produits de Classe I/II, faites appel a des organismes notifies pour l'evaluation par un tiers. Preparez la Declaration de conformite UE et la documentation du marquage CE. Assurez-vous que votre systeme de gestion de la qualite supporte la conformite continue.

  6. 6

    Periode de support et infrastructure de mise a jour

    Definissez les periodes de support pour tous les produits (minimum 5 ans). Construisez une infrastructure securisee de livraison des mises a jour. Etablissez des processus de planification de fin de vie et de communication avec les utilisateurs. Assurez-vous de pouvoir fournir des correctifs de securite gratuits tout au long de la periode de support.

Questions frequentes sur le CRA

Qu'est-ce que le Cyber Resilience Act ?

Le CRA (Reglement 2024/2847) est un reglement europeen etablissant des exigences horizontales de cybersecurite pour les produits comportant des elements numeriques. Il impose la securite des la conception, la gestion des vulnerabilites, la gestion des SBOM et le signalement des incidents a l'ENISA. Le signalement des vulnerabilites debute en septembre 2026, l'application complete a partir de decembre 2027.

Qui doit se conformer au CRA ?

Le CRA s'applique aux fabricants, importateurs et distributeurs de produits comportant des elements numeriques mis sur le marche de l'UE. Cela inclut tout produit materiel ou logiciel disposant d'une connexion reseau. Les services SaaS purs sont generalement exclus sauf s'ils incluent des composants telechargeables.

Quels sont les delais de signalement des vulnerabilites du CRA ?

Les fabricants doivent envoyer une alerte precoce au CSIRT designe dans les 24 heures suivant la prise de connaissance d'une vulnerabilite activement exploitee, une notification detaillee dans les 72 heures et un rapport final dans les 14 jours. Les utilisateurs doivent egalement etre informes sans retard indu.

Qu'est-ce qu'un SBOM et pourquoi le CRA l'exige-t-il ?

Une nomenclature logicielle (SBOM) est un inventaire detaille de tous les composants logiciels d'un produit. Le CRA exige des SBOM pour permettre le suivi des vulnerabilites, la transparence de la chaine d'approvisionnement et une reponse plus rapide aux incidents lorsque des vulnerabilites sont decouvertes dans des composants tiers.

Comment le CRA classifie-t-il les produits ?

Les produits par defaut utilisent l'auto-evaluation. Les produits de Classe I (par ex. VPN, pare-feu) necessitent la conformite aux normes ou une evaluation par un tiers. Les produits de Classe II (par ex. systemes d'exploitation) necessitent une evaluation obligatoire par un tiers. Les produits critiques necessitent un examen de type UE.

Quelle est la periode de support minimale au titre du CRA ?

Les fabricants doivent fournir des mises a jour de securite gratuites pendant au moins 5 ans ou la duree de vie prevue du produit, selon la plus longue. La periode de support doit etre clairement communiquee aux utilisateurs au moment de l'achat.

CRA Readiness Assessment

Assess your Cyber Resilience Act readiness

Take the free assessment

Fonctionnalités clés

Securite des la conception (Annex I)

Suivez et documentez les exigences essentielles de cybersecurite de la conception du produit a sa livraison. Parametres securises par defaut, minimisation de la surface d'attaque et controle d'acces - le tout avec preuves a l'appui.

Gestion des vulnerabilites (Annex I.2)

Identification, documentation et remediation systematiques des vulnerabilites. Processus de divulgation coordonnee avec piste d'audit complete et integration SBOM.

Gestion des SBOM (Annex I.2(9))

Generez et maintenez des nomenclatures logicielles (SBOM). Suivez tous les composants, bibliotheques et dependances. Croisement automatique avec les bases de donnees de vulnerabilites connues.

Signalement ENISA/CSIRT (Art. 14)

Respectez les delais de 24 h pour l'alerte precoce, 72 h pour la notification et 14 jours pour le rapport final. Modeles preconstruits, workflows automatises et suivi des echeances.

Evaluation de conformite (Art. 32)

Auto-evaluation pour les produits par defaut, evaluation tierce guidee pour les Classes I/II. Generation de la Declaration de conformite UE et documentation du marquage CE.

Gestion de la periode de support (Art. 13(7))

Suivez les periodes de support des produits (minimum 5 ans), la livraison des mises a jour de securite et les transitions de fin de vie. Alertes automatisees et documentation de conformite.

Pourquoi Matproof

Couvre toutes les exigences essentielles de cybersecurite du CRA
Generation automatisee de SBOM et suivi des vulnerabilites
Modeles de signalement ENISA/CSIRT preconstruits avec suivi des echeances
100 % de residence des donnees dans l'UE (heberge en Allemagne)

CRA Readiness Assessment

Assess your Cyber Resilience Act readiness

Take the free assessment

Témoignages clients

Les équipes qui ne redoutent plus la saison des audits.

85 %de préparation en moins

Matproof nous a fait gagner des mois de préparation d'audit. Nous avons connecté nos outils le lundi et dès le vendredi, nous avions des preuves cartographiées selon DORA. Notre auditeur a été impressionné par la profondeur de la piste d'audit.

Ho

Head of Compliance

Series B Fintech, Germany

* Company names anonymized for privacy. All quotes from real compliance professionals using Matproof.

Prêt à commencer ?

Prêt à commencer ?

Découvrez comment Matproof automatise la conformité pour votre organisation.

Demander une démo