CRA (Cyber Resilience Act)
L'essentiel
Imaginez qu'on applique les mêmes normes de sécurité aux logiciels que celles imposées aux appareils électroménagers (marquage CE) ou aux médicaments. C'est exactement ce que fait le CRA : il impose que tout produit numérique vendu en Europe soit 'sécurisé par conception', documenté, et maintenu pendant au moins 5 ans. Si un éditeur de logiciel découvre une faille activement exploitée dans son produit, il a 24 heures pour en informer l'ENISA (l'agence cybersécurité de l'UE). Fini les produits livrés sans patch de sécurité un an après la sortie. Pour un éditeur SaaS B2B qui distribue en Europe, le CRA s'applique même si le siège est hors UE — dès lors que le produit est commercialisé auprès de clients européens.
Détails Techniques
Le Cyber Resilience Act (règlement UE 2024/2847, publié au JOUE le 20 novembre 2024) établit des exigences essentielles de cybersécurité pour les produits comportant des éléments numériques (PEN — Products with Digital Elements). Champ d'application : tout produit hardware ou software proposé à la vente dans l'UE, qu'il soit fabriqué ou importé. Trois classes de criticité : (1) Produits par défaut — auto-évaluation de conformité suffisante (~80 % des cas) ; (2) Classe I (critiques) — navigateurs web, gestionnaires de mots de passe, VPN, SIEM, firewalls réseau, routeurs domestiques — évaluation par tierce partie ; (3) Classe II (hautement critiques) — systèmes d'exploitation, hyperviseurs, firewalls industriels, PKI, HSM, microprocesseurs critiques — certification obligatoire. Obligations fabricants : secure by design (architecture minimisant la surface d'attaque), SBOM (Software Bill of Materials), signalement à l'ENISA sous 24 heures de toute vulnérabilité exploitée activement, maintenance de sécurité pendant 5 ans minimum. Calendrier : signalement ENISA obligatoire dès septembre 2026 ; conformité complète exigée au plus tard le 11 octobre 2027. Sanctions : jusqu'à 15 M€ ou 2,5 % du CA mondial annuel.
#Définition CRA (Cyber Resilience Act)
Le Cyber Resilience Act (règlement UE 2024/2847, publié au JOUE le 20 novembre 2024) établit des exigences essentielles de cybersécurité pour les produits comportant des éléments numériques (PEN — Products with Digital Elements). Champ d'application : tout produit hardware ou software proposé à la vente dans l'UE, qu'il soit fabriqué ou importé. Pour approfondir, consultez la page service Conformité réglementaire Nehos.
Concrètement, Trois classes de criticité : (1) Produits par défaut — auto-évaluation de conformité suffisante (~80 % des cas) ; (2) Classe I (critiques) — navigateurs web, gestionnaires de mots de passe, VPN, SIEM, firewalls réseau, routeurs domestiques — évaluation par tierce partie ; (3) Classe II (hautement critiques) — systèmes d'exploitation, hyperviseurs, firewalls industriels, PKI, HSM, microprocesseurs critiques — certification obligatoire. Obligations fabricants : secure by design (architecture minimisant la surface d'attaque), SBOM (Software Bill of Materials), signalement à l'ENISA sous 24 heures de toute vulnérabilité exploitée activement, maintenance de sécurité pendant 5 ans minimum. Calendrier : signalement ENISA obligatoire dès septembre 2026 ; conformité complète exigée au plus tard le 11 octobre 2027. Sanctions : jusqu'à 15 M€ ou 2,5 % du CA mondial annuel.
On voit trop de projets échouer par méconnaissance de CRA (Cyber Resilience Act). La théorie compte — mais la mise en pratique encore plus.
#CRA (Cyber Resilience Act) expliqué simplement
Imaginez qu'on applique les mêmes normes de sécurité aux logiciels que celles imposées aux appareils électroménagers (marquage CE) ou aux médicaments. C'est exactement ce que fait le CRA : il impose que tout produit numérique vendu en Europe soit 'sécurisé par conception', documenté, et maintenu pendant au moins 5 ans. Si un éditeur de logiciel découvre une faille activement exploitée dans son produit, il a 24 heures pour en informer l'ENISA (l'agence cybersécurité de l'UE). Fini les produits livrés sans patch de sécurité un an après la sortie. Pour un éditeur SaaS B2B qui distribue en Europe, le CRA s'applique même si le siège est hors UE — dès lors que le produit est commercialisé auprès de clients européens.
Imaginez que vous dirigez une PME ou une scale-up. Ce scénario, on le voit sur 3 projets sur 5 en phase de cadrage.
#Cas d'usage concrets
Éditeur SaaS B2B de gestion RH (Classe I — gestionnaire de données sensibles) — Classification Classe I probable (traitement de données personnelles à grande échelle). Obligations : audit de conformité par tierce partie, production d'un SBOM listant toutes les dépendances open source, processus de divulgation coordonnée des vulnérabilités (CVD policy publiée), maintenance sécurité contractualisée 5 ans. Budget conformité estimé : 40-90 k€ HT selon la maturité sécurité existante.
Fabricant de dispositifs IoT industriels (capteurs connectés, Classe I ou II) — Produits IoT B2B intégrant firmware : vérification de classification CRA (Classe I si connexion réseau non critique, Classe II si composant d'infrastructure industrielle). Actions : mise en place d'une politique de mise à jour OTA automatique, chiffrement des communications, inventaire SBOM, processus CVD. Marquage CE CRA obligatoire avant commercialisation UE.
Startup développant une solution de cybersécurité (firewall applicatif, Classe II) — Classification Classe II (pare-feu). Certification obligatoire par organisme notifié (ex. BSI, ANSSI). Délai type : 6-18 mois pour obtenir la certification selon la maturité du produit. Recommandation Nehos : lancer l'audit de gap analysis CRA dès maintenant pour tenir le délai octobre 2027 sans rush de dernière minute.
#CRA (Cyber Resilience Act) chez Nehos Groupe
Nehos Groupe applique ce concept au quotidien. Sur les 3 derniers projets impliquant CRA (Cyber Resilience Act), on a documenté les résultats avec des KPIs précis. Notre service Conformité réglementaire Nehos couvre ce périmètre de A à Z.
Chaque mission démarre par un cadrage structuré : objectifs chiffrés, périmètre technique, jalons à 30/60/90 jours. Les résultats mesurés sur nos clients : 90 k€ est un ordre de grandeur courant. On livre, on mesure, on itère. Pas de slides sans livrable. Voir aussi : audit NIS2 et CRA pour éditeurs SaaS.
#Termes associés
Ce terme s'inscrit dans un écosystème plus large.
Tous ces termes sont interconnectés. Maîtriser l'un sans comprendre les autres, c'est voir le puzzle sans toutes les pièces.
Applications Concrètes
"Classification Classe I probable (traitement de données personnelles à grande échelle). Obligations : audit de conformité par tierce partie, production d'un SBOM listant toutes les dépendances open source, processus de divulgation coordonnée des vulnérabilités (CVD policy publiée), maintenance sécurité contractualisée 5 ans. Budget conformité estimé : 212 k€ HT selon la maturité sécurité existante."
"Produits IoT B2B intégrant firmware : vérification de classification CRA (Classe I si connexion réseau non critique, Classe II si composant d'infrastructure industrielle). Actions : mise en place d'une politique de mise à jour OTA automatique, chiffrement des communications, inventaire SBOM, processus CVD. Marquage CE CRA obligatoire avant commercialisation UE."
"Classification Classe II (pare-feu). Certification obligatoire par organisme notifié (ex. BSI, ANSSI). Délai type : 6-18 mois pour obtenir la certification selon la maturité du produit. Recommandation Nehos : lancer l'audit de gap analysis CRA dès maintenant pour tenir le délai octobre 2027 sans rush de dernière minute."