Cyber Resilience Act (CRA) — Conformité Sécurité pour Éditeurs Logiciels et IoT

#Le Cyber Resilience Act — Règlement UE 2024/2847 applicable en 2027

Pour bien comprendre le CRA, il faut d'abord le distinguer de la directive NIS2. NIS2 (Directive UE 2022/2555) cible les opérateurs — les organisations qui utilisent des systèmes numériques dans des secteurs critiques et qui doivent sécuriser leurs propres opérations. Le Cyber Resilience Act, lui, cible les fabricants — les éditeurs de logiciels, les développeurs d'applications, les constructeurs d'objets connectés, tous ceux qui mettent des produits numériques sur le marché de l'UE. L'analogie est simple : la NIS2 est la réglementation de sécurité des usines ; le CRA est la réglementation de sécurité des machines que ces usines achètent.

Le règlement UE 2024/2847 couvre tout « produit comportant des éléments numériques » — défini à l'article 3(1) comme tout produit matériel ou logiciel et ses solutions de traitement de données à distance qui peut recevoir des données d'un réseau ou qui peut se connecter à d'autres équipements. Cette définition embrasse un spectre très large : smartphones, tablettes, ordinateurs, routeurs, caméras IP, thermostats intelligents, montres connectées, applications mobiles, logiciels de bureau, suites SaaS avec composant téléchargeable, OS embarqués, automates industriels, capteurs IoT industriels, équipements médicaux connectés (en articulation avec le règlement MDR). L'article 2 liste les exclusions : logiciels open source publiés sans intention commerciale (avec une définition précise de ce que « sans intention commerciale » signifie au sens du règlement — les modèles de monétisation indirects sont regardés), produits couverts par d'autres règlements sectoriels de cybersécurité spécifiques (certains équipements aviation EASA, dispositifs médicaux MDR/IVDR sur leur périmètre de sécurité spécifique) où le CRA joue en complémentarité.

Point pratique pour les éditeurs SaaS : si votre offre est 100 % cloud sans aucun composant client téléchargeable (agent, plugin, application mobile, connecteur), la qualification CRA nécessite une analyse au cas par cas à l'article 2 et aux considérants 10 à 18. Si votre offre inclut un composant installé côté client — agent de monitoring, connecteur desktop, application mobile, SDK intégré dans les produits de vos clients — le CRA s'applique. Nehos a développé un arbre de décision de couverture CRA qui traite ces cas en moins d'un jour d'analyse.

#Catégories de risque CRA — Défaut, Important I, Important II, Critique

L'Annexe III du Règlement UE 2024/2847 classe les produits en quatre niveaux, avec des obligations d'évaluation de conformité croissantes selon le niveau de risque.

Catégorie Défaut — La grande majorité des produits avec éléments numériques relève de cette catégorie. Jeux vidéo, applications métier génériques, logiciels de productivité sans fonctions réseau critiques, la plupart des composants IoT grand public non listés en Classe I. Évaluation de conformité : auto-évaluation admise, sur la base de normes harmonisées (EN 18031 en cours d'élaboration par ETSI et CEN/CENELEC) ou de spécifications communes publiées par la Commission. C'est le cas le plus accessible pour les PME éditrices.

Important Classe I — Produits dont la compromission pourrait affecter simultanément un grand nombre d'utilisateurs ou d'infrastructures. L'Annexe III liste explicitement : navigateurs web, gestionnaires de mots de passe, produits VPN (y compris les composants VPN embarqués dans des produits plus larges), systèmes de détection et prévention d'intrusion (IDS/IPS) destinés aux utilisateurs finaux, routeurs pour la maison et PME, commutateurs réseau, micro-contrôleurs à usage général, microprocesseurs de confiance, systèmes d'exploitation pour équipements industriels IoT, infrastructure à clé publique (PKI) et gestion des certificats, solutions de pare-feu pour utilisateurs finaux, équipements réseau industriels. Évaluation de conformité : auto-évaluation admise si le fabricant applique des normes harmonisées couvrant toutes les exigences de l'Annexe I — sinon, évaluation tierce (Organisme Notifié ou mécanisme d'évaluation tiers accrédité).

Important Classe II — Produits à risque encore plus élevé, souvent en position d'infrastructure critique. L'Annexe III liste : hyperviseurs et runtimes de conteneurs (Docker, containerd, VMware ESXi — avec impact sur les opérateurs NIS2 qui les utilisent), systèmes SCADA/DCS industriels et contrôleurs à sécurité intégrée (safety PLC), compteurs intelligents avec fonction de sécurité, microprocesseurs résistants à la falsification (tamper-resistant), serveurs d'accès sécurisé (passerelles d'authentification). Pour la Classe II, l'évaluation de conformité par un Organisme Notifié (Notified Body) est obligatoire — l'auto-évaluation n'est pas admise.

Critique — Les produits de cette catégorie seront définis par actes délégués de la Commission européenne, publiés au plus tard 12 mois après l'entrée en vigueur du règlement. Les premières indications montrent que des composants d'infrastructure critiques souverains (HSM, racines de confiance, protocoles cryptographiques gouvernementaux) seront visés.

#Les 13 obligations de sécurité CRA — Annexe I Partie 1

L'Annexe I Partie 1 du Règlement UE 2024/2847 liste treize exigences essentielles de cybersécurité que tout produit couvert doit respecter. Voici leur traduction opérationnelle pour un éditeur logiciel.

(1) Absence de vulnérabilités connues exploitables à la mise sur le marché. Obligation de livrer un produit exempt de vulnérabilités connues activement exploitées (CVE avec CVSS ≥ 7.0 et exploit public documenté, a minima). Concrètement : audit de sécurité avant chaque release majeure, SBOM maintenu à jour, scan de dépendances systématique en CI/CD.

(2) Configuration sécurisée par défaut. Le produit doit être livré dans un état sécurisé « out of the box » — sans comptes par défaut avec mots de passe hardcodés, sans ports ouverts non nécessaires, sans services activés sans motif fonctionnel. Nehos audite la configuration par défaut en environnement de test isolé.

(3) Protection contre les accès non autorisés. Mécanismes d'authentification robustes (MFA encouragé), contrôle d'accès basé sur les rôles (RBAC), gestion sécurisée des sessions, protection contre le brute-force. Article 13(3) du règlement impose une documentation de ces mécanismes dans le dossier technique.

(4) Protection contre les vecteurs d'attaque courants. Résistance aux patterns d'attaque documentés par l'ENISA et les bases de connaissance publiques (OWASP Top 10, MITRE ATT&CK for ICS pour les produits industriels, CWE Top 25). Nehos applique le Top 10 OWASP LLM en plus pour les produits intégrant des composants IA générative — cf. sécurité LLM OWASP.

(5) Surface d'attaque minimale. Principe du moindre privilège, désactivation des fonctionnalités non utilisées, réduction des composants embarqués aux stricts nécessaires fonctionnels. Critique pour les produits IoT avec OS embarqués : chaque daemon actif inutilement est une surface.

(6) Limitation des effets adverses sur d'autres équipements ou réseaux. Un produit compromis ne doit pas devenir un vecteur d'attaque latéral. Pour les produits réseau (routeurs, commutateurs, agents IoT) : segmentation, limitations de broadcast, protection contre les scans de ports sortants.

(7) Disponibilité sous attaque — Résistance aux DoS. Le produit doit maintenir ses fonctions essentielles sous charge anormale ou attaque par déni de service. Pour les SaaS : rate limiting, circuit breakers, dégradation gracieuse documentée.

(8) Capacité de collecte de données pour l'analyse de sécurité. Le produit doit générer des logs de sécurité exploitables — authentification réussie et échouée, modifications de configuration, accès aux données sensibles, erreurs applicatives — en format structuré (JSON, syslog RFC 5424). Ces logs doivent être transmissibles à un SIEM sans transformation.

(9) Effacement sécurisé des données. Mécanismes de purge irréversible des données utilisateur à la fin du cycle de vie ou sur demande — particulièrement critique pour les équipements IoT revendus ou en fin de support, et pour les SaaS soumis au RGPD (droit à l'oubli article 17 RGPD).

(10) Confidentialité — Chiffrement au repos et en transit. Chiffrement TLS 1.2 minimum (TLS 1.3 recommandé) en transit, chiffrement AES-256 des données sensibles au repos, gestion sécurisée des clés (rotation, stockage HSM ou service dédié). L'article 13(7) du règlement impose une documentation des protocoles cryptographiques utilisés.

(11) Intégrité — Protection contre les modifications non autorisées. Vérification d'intégrité des composants (signatures cryptographiques des binaires, checksums des mises à jour), protection contre la falsification du firmware pour les équipements IoT (Secure Boot), chaîne de build sécurisée (SLSA level 2 minimum recommandé par Nehos).

(12) Surveillance et alertes. Capacité de détection et d'alerte sur les événements de sécurité anormaux en temps réel ou quasi-réel. Pour les SaaS : intégration avec des outils SIEM standards (Elastic Security, Splunk, Wazuh). Pour les IoT : agents légers d'intégrité et de détection d'anomalies comportementales.

(13) Auditabilité. L'ensemble des actions de sécurité significatives (authentification, autorisation, modification de configuration, accès aux données sensibles) doit être tracé de manière immutable et vérifiable. Nehos implémente pgaudit pour les composants Postgres et OpenTelemetry pour la traçabilité applicative distribuée.

#SBOM — Software Bill of Materials, obligation CRA

Le SBOM est l'une des obligations les plus concrètes et les plus opérationnelles du Cyber Resilience Act. L'article 13(3) et l'Annexe I Partie 2 imposent que tout fabricant maintienne un inventaire lisible par machine de l'ensemble des composants logiciels de son produit — dépendances directes, dépendances transitives, bibliothèques tierces, composants open source, versions exactes, licences, et vulnérabilités connues associées.

Un SBOM est un fichier structuré (CycloneDX JSON/XML ou SPDX tag-value ou JSON) qui liste chaque composant logiciel avec son identifiant unique (PURL — Package URL), sa version, sa licence (SPDX license ID), ses hash de vérification (SHA-256 minimum), et les CVE connues au moment de la génération. Le CRA ne prescrit pas de format unique, mais les deux formats dominants dans l'industrie sont CycloneDX (standard OWASP, adopté par la majorité des outils commerciaux) et SPDX (standard Linux Foundation, adopté notamment par les directives sectorielles US NTIA). Nehos livre les deux formats simultanément.

Pour un produit SaaS B2B typique (stack Node.js + Python + Postgres + quelques services tiers), un SBOM généré en 2026 inventorie couramment entre 400 et 2 000 dépendances une fois les transitifs inclus. Les outils utilisés par Nehos : Syft (Anchore — génération de SBOM à partir d'images Docker, de répertoires, de binaires compilés), Grype (Anchore — scan de vulnérabilités sur SBOM existant ou généré à la volée), Trivy (Aqua Security — scanner polyvalent SBOM + vulnérabilités + misconfigurations + secrets), OWASP Dependency-Track (plateforme de gestion continue des risques liés aux composants — tableau de bord, alertes CVE automatiques, historique). Ces outils sont intégrés dans les pipelines CI/CD (GitHub Actions, GitLab CI, Jenkins) de sorte que chaque build génère un SBOM mis à jour et déclenche automatiquement une alerte si un nouveau CVE critique (CVSS ≥ 9.0) apparaît sur une dépendance en production.

L'obligation CRA sur le SBOM ne s'arrête pas à la mise sur le marché initiale. L'Annexe I Partie 2 impose de maintenir le SBOM à jour tout au long du cycle de vie du produit et de le mettre à jour dès la découverte d'une nouvelle vulnérabilité sur un composant listé. Nehos inclut dans tous ses engagements CRA la mise en place de cette boucle de maintenance automatisée, avec alertes Slack/email vers les équipes techniques dès qu'un CVE CVSS ≥ 7.0 touche une dépendance du produit audité.

#Gestion des vulnérabilités — 24h/72h/notification ENISA

L'Annexe I Partie 2 du Règlement UE 2024/2847 établit un régime de gestion des vulnérabilités parmi les plus exigeants jamais imposés par la réglementation européenne. Cinq obligations principales.

1. Accuser réception des rapports de vulnérabilités. Le fabricant doit disposer d'un canal officiel de signalement des vulnérabilités (Vulnerability Disclosure Policy, VDP) et accuser réception dans un délai raisonnable. L'article 13(6) impose de « traiter et corriger les vulnérabilités sans délai injustifié, notamment en fournissant des mises à jour de sécurité ». Nehos aide à rédiger et publier la VDP selon le modèle standardisé security.txt (RFC 9116) et coordonne la publication sur le site officiel du produit.

2. Notification ENISA sous 24 heures — Vulnérabilités activement exploitées. Dès qu'un fabricant prend connaissance d'une vulnérabilité affectant son produit qui est activement exploitée dans la nature, il doit notifier l'ENISA (et le CSIRT national — en France, le CERT-FR de l'ANSSI) dans un délai de 24 heures. Article 14(2)(a) du règlement. Cette notification rapide (early warning) doit contenir : identification du produit, description de la vulnérabilité, indication de l'exploitation active, mesures correctives en cours ou disponibles.

3. Notification ENISA sous 72 heures — Toute vulnérabilité. Dans les 72 heures suivant la prise de connaissance de toute vulnérabilité affectant le produit (pas seulement les exploitées activement), le fabricant doit envoyer une notification complète à l'ENISA via le portail dédié prévu à l'article 16. Article 14(2)(b). Cette notification complète inclut la sévérité CVSS, l'impact potentiel, les produits et versions affectés, et la timeline de correctif.

4. Correction dans un délai raisonnable et fourniture d'un mécanisme de mise à jour. L'article 13(3) impose que le produit dispose d'un mécanisme de mise à jour sécurisée automatique ou facilement déclenché par l'utilisateur. Pour les IoT en particulier, la mise à jour over-the-air (OTA) signée et vérifiée est l'implémentation attendue.

5. Maintien du processus de gestion des vulnérabilités pendant toute la durée de vie du produit. L'article 13(8) impose une durée de support minimale de 5 ans ou correspondant à la durée de vie attendue du produit si elle est inférieure. Cette exigence est particulièrement lourde pour les fabricants IoT dont les produits restent en service 10 à 15 ans — elle oblige à anticiper la fin de vie logicielle bien avant la fin de vie matérielle.

Nehos déploie pour ses clients un processus CVD (Coordinated Vulnerability Disclosure) complet : rédaction et publication de la VDP (security.txt + page dédiée), configuration du portail ENISA (article 16 du règlement), template de notification 24h/72h pré-rempli avec les données produit, intégration des alertes CVE automatiques depuis OWASP Dependency-Track vers le canal de crise de l'équipe sécurité, et formation de l'équipe technique sur le processus de qualification et d'escalade.

#CE Marking et Declaration of Conformity CRA

Le Cyber Resilience Act s'inscrit dans le cadre du Nouveau Cadre Législatif (NCL) européen qui régit le marquage CE. Concrètement, il ajoute les exigences de cybersécurité à la liste des critères que doit satisfaire un produit avec éléments numériques pour apposer le marquage CE lors de sa mise sur le marché de l'UE.

La Déclaration de Conformité (DoC) CRA, prévue à l'article 28, est un document formel par lequel le fabricant prend la responsabilité de la conformité de son produit à l'ensemble des exigences de l'Annexe I. La DoC doit notamment mentionner : identification complète du produit et de ses versions, référence aux normes harmonisées ou spécifications communes appliquées (une fois celles-ci publiées), description de la procédure d'évaluation de conformité suivie, coordonnées du fabricant ou du représentant autorisé UE, date d'établissement.

Pour les produits Important Classe I qui choisissent la voie de l'évaluation tierce (au lieu de l'auto-évaluation), et pour tous les produits Important Classe II, un Organisme Notifié (Notified Body — liste tenue par la Commission européenne via NANDO) doit auditer le dossier technique et délivrer une attestation d'examen CE. Nehos identifie pour ses clients les Organismes Notifiés accrédités en France (BSI, TÜV Rheinland France, Bureau Veritas selon les accréditations disponibles) et prépare le dossier technique dans le format requis — documentation des architectures, procédures de test, rapports d'audit, SBOM, registres des vulnérabilités traitées — pour maximiser les chances d'approbation en premier passage.

#CRA et NIS2 — Complémentarité des deux règlements

Un raccourci fréquent consiste à confondre NIS2 et CRA, ou à croire que l'un remplace l'autre. Ce n'est pas le cas — ils sont complémentaires et ciblent des acteurs différents sur différents maillons de la chaîne de valeur numérique.

La Directive NIS2 (UE 2022/2555, transposée en droit français par la loi n°2023-703 et ses décrets d'application) cible les opérateurs de services essentiels et importants — les entreprises et organisations qui utilisent des systèmes numériques pour fournir leurs propres services (hôpitaux, opérateurs énergie, fournisseurs d'accès Internet, plateformes cloud, services financiers, etc.). Elle leur impose des obligations de gestion des risques, de déclaration d'incidents et de sécurité de leur propre infrastructure.

Le CRA cible les fabricants — les éditeurs de logiciels, les développeurs d'applications, les constructeurs IoT, tous ceux qui mettent des produits avec éléments numériques sur le marché. Il leur impose des obligations sur le produit lui-même, avant qu'il ne soit déployé chez un opérateur.

Pour de nombreux acteurs — notamment les éditeurs SaaS qui sont à la fois fabricants (ils éditent un logiciel soumis au CRA) et opérateurs (ils exploitent l'infrastructure qui fait tourner ce logiciel, potentiellement soumis à NIS2 s'ils rentrent dans un secteur ou un seuil) — les deux règlements s'appliquent simultanément et de manière cumulative. Nehos propose un forfait combiné CRA+NIS2 qui mutualise l'audit initial, la cartographie des actifs et la documentation technique, pour éviter les doublons de coût et assurer la cohérence des deux dossiers de conformité. Voir audit NIS2 pour le détail du volet opérateur.

#Audit CRA Nehos — De l'analyse d'impact à la déclaration de conformité

La méthodologie Nehos pour la mise en conformité CRA se déroule en quatre phases successives, adaptables selon la maturité sécurité initiale et la catégorie CRA du produit.

Phase 1 — Qualification et analyse d'impact (5-10 jours). Trois questions fondamentales : (a) Le produit est-il dans le périmètre CRA (article 2 et considérants 10-18) ? (b) Quelle est sa catégorie (Défaut, Important I, Important II) ? (c) Quelle procédure d'évaluation de conformité s'applique (auto-évaluation vs tierce) ? Cette phase produit un rapport de qualification opposable, qui sera la première pièce du dossier technique.

Phase 2 — Gap analysis sécurité (2-4 semaines). Évaluation de l'écart entre l'état actuel du produit et les 13 exigences de l'Annexe I Partie 1 et les obligations de gestion des vulnérabilités de l'Annexe I Partie 2. Méthodologie : revue de code assistée par outils SAST (Semgrep, SonarQube), tests de pénétration ciblés sur les vecteurs d'attaque courants, revue de l'architecture réseau, audit de la configuration par défaut, revue des processus de build et de release. Livrable : rapport de gap analysis avec scoring par exigence, priorisation des remédiations par impact et faisabilité.

Phase 3 — Remédiation et génération SBOM (4-12 semaines selon scope). Correction des vulnérabilités identifiées en phase 2, hardening de la configuration par défaut, implémentation ou renforcement des contrôles d'accès, mise en place du pipeline SBOM automatisé (Syft + Grype + Trivy + OWASP Dependency-Track), configuration des alertes CVE, rédaction et publication de la VDP, configuration du processus de notification ENISA. Pour les produits Important Classe II : coordination avec l'Organisme Notifié sélectionné.

Phase 4 — Documentation et déclaration de conformité (2-3 semaines). Production du dossier technique complet : description du produit et de ses versions, référence aux normes appliquées, architecture de sécurité documentée, résultats des tests et audits, SBOM livré en CycloneDX + SPDX, registre des vulnérabilités traitées, process de gestion post-marché. Rédaction de la Déclaration de Conformité CE (article 28). Accompagnement au dépôt si organisme notifié requis.

#ROI et anticipation — Cas éditeur SaaS B2B IoT industriel

La valeur commerciale d'une conformité CRA bien gérée en amont est souvent sous-estimée. Trois dimensions de ROI pour les éditeurs que nous accompagnons.

Différenciation commerciale. En 2027, tout acheteur B2B — Direction des Achats, RSSI, juriste — va demander la Déclaration de Conformité CE CRA avant signature d'un contrat impliquant un logiciel ou un dispositif connecté. Les éditeurs conformes auront un avantage décisif sur les cycles de vente face aux concurrents qui découvrent le sujet en urgence. Un cas réel : un éditeur SaaS industriel IoT (outil de supervision de lignes de production) que Nehos a mis en conformité 18 mois avant la deadline s'est qualifié sur deux appels d'offres grands comptes où la conformité CRA était un critère éliminatoire — contrats signés pour 6080 k€ ARR additionnels dont la conformité CRA Nehos a été un facteur déterminant.

Réduction du coût des incidents. Un SBOM maintenu à jour et des alertes CVE automatisées réduisent drastiquement le temps moyen de réponse (MTTR) sur les vulnérabilités critiques. Nos clients IoT mesurent une réduction du MTTR de 72 heures à 8 heures en moyenne après implémentation de OWASP Dependency-Track + pipeline CI/CD. En valeur d'assurance cyber, le passage d'un score de maturité sécurité de 2/5 à 4/5 réduit les primes de 20 à 35 % chez les principaux assureurs du marché français.

Prévention des sanctions. Le CRA prévoit à l'article 64 des sanctions allant jusqu'à 240 M€ ou 2,5 % du chiffre d'affaires mondial annuel pour les fabricants ne respectant pas les exigences essentielles de l'Annexe I, et jusqu'à 160 M€ ou 2 % du CA pour les manquements aux obligations de gestion des vulnérabilités. Pour un éditeur SaaS B2B de 160 M€ de CA, l'exposition maximale est de 4000 k€ — à mettre en regard du coût d'un audit de mise en conformité de 35 à 880 k€ HT.

#Tarification — 22 à 1280 k€ HT

Quatre configurations tarifaires selon le scope et la catégorie CRA du produit.

Qualification CRA seule (5 jours, 4 500 à144 000 € HT). Pour les éditeurs qui veulent d'abord confirmer si leur produit est dans le périmètre CRA et dans quelle catégorie avant de décider d'investir dans une mise en conformité complète. Livrable : rapport de qualification opposable avec arbre de décision documenté article par article.

Audit gap analysis + roadmap (4-8 semaines, 22 à 560 k€ HT). Pour les produits en catégorie Défaut ou Important Classe I. Inclut la qualification, le gap analysis complet sur les 13 exigences Annexe I, le premier SBOM généré (CycloneDX + SPDX), le rapport de vulnérabilités priorisées et la roadmap de remédiation. Ne couvre pas la remédiation elle-même.

Audit + remédiation + SBOM pipeline + documentation DoC (8-16 semaines, 35 à 880 k€ HT). Pour Important Classe I avec mise en conformité opérationnelle complète. Inclut tout ce qui précède plus : remédiation des vulnérabilités prioritaires, pipeline SBOM automatisé intégré CI/CD, configuration OWASP Dependency-Track, rédaction et publication VDP, configuration process ENISA, dossier technique complet et Déclaration de Conformité CE prête à signer.

Mission complète Important Classe II avec préparation Organisme Notifié (4-6 mois, 55 à 1280 k€ HT). Pour hyperviseurs, SCADA industriels, runtime de conteneurs et autres produits Classe II. Inclut tout ce qui précède plus : identification et sélection de l'Organisme Notifié adapté, préparation du dossier de demande d'attestation d'examen CE, accompagnement de l'audit tiers, traitement des non-conformités relevées. Estimation précise sur devis après entretien de qualification : [Réserver un RDV audit CRA](https://calendly.com/raphael-poirier_/decouverte15min-nehos-groupe