Éditeurs de logiciels & CRA : la sécurité produit devient obligatoire

De quoi parle CRA ?

Le CRA vise les « produits comportant des éléments numériques » : logiciels et matériels connectés directement ou indirectement à un réseau. Il définit des exigences essentielles de cybersécurité et des obligations de gestion des vulnérabilités, avec des catégories « importantes » et « critiques » soumises à des évaluations plus strictes.

Des régimes particuliers existent, notamment pour les logiciels libres non commerciaux et les produits déjà couverts par une réglementation sectorielle équivalente.

Le secteur « Éditeurs de logiciels » est-il concerné ?

Tout éditeur mettant un logiciel sur le marché européen est, en principe, fabricant d’un produit à éléments numériques. Le niveau d’exigence dépend de la criticité du produit : la plupart des logiciels relèvent du régime de base, certains (outils de sécurité, composants sensibles) des catégories renforcées.

Un régime allégé s’applique à l’open source non commercial ; un composant open source intégré à un produit commercial reste toutefois de la responsabilité de l’éditeur qui le commercialise.

Obligations détaillées

Sanctions & risques

Les manquements aux exigences essentielles de cybersécurité peuvent être sanctionnés jusqu’à 15 M€ ou 2,5 % du chiffre d’affaires mondial ; d’autres manquements relèvent de paliers inférieurs. La non-conformité peut aussi entraîner le retrait ou le rappel du produit du marché.

Pour un éditeur, l’enjeu est double : la sanction et l’accès au marché, le marquage CE cybersécurité devenant une condition de commercialisation.

Calendrier d’application

• 1Entrée en vigueur. Fin 2024.
• 2Obligations de notification. Applicables environ 21 mois après l’entrée en vigueur (courant 2026).
• 3Exigences complètes. Applicables environ 36 mois après l’entrée en vigueur (horizon 2027).

Erreurs fréquentes dans le secteur

• 1« CRA = matériel seulement ». Croire que le CRA ne vise que le hardware, alors qu’un logiciel est un produit à éléments numériques.
• 2Pas de SBOM. Ignorer la nomenclature des composants, ce qui rend la gestion des vulnérabilités impossible.
• 3Absence de politique de correctifs. Ne pas garantir de mises à jour sur la durée de support.
• 4Vulnérabilités non notifiées. Omettre la notification des vulnérabilités activement exploitées.

Cas pratique

Un éditeur d’un logiciel largement déployé découvre qu’une dépendance open source intégrée présente une vulnérabilité activement exploitée. Grâce à son SBOM, il identifie en heures les versions affectées, publie un correctif dans le cadre de sa politique de support et notifie l’ENISA — chaîne de réaction exigée par le CRA et impossible sans nomenclature ni PSIRT en place.

Feuille de route de mise en conformité

1. 1

   Établir un SBOM. Cartographier tous les composants logiciels et leurs dépendances.

2. 2

   Mettre en place un PSIRT. Structurer la gestion et la divulgation coordonnée des vulnérabilités.

3. 3

   Définir la période de support. Fixer et communiquer la durée de fourniture des correctifs.

4. 4

   Préparer la conformité. Constituer la documentation technique et l’évaluation de conformité en vue du marquage CE.

5. 5

   Outiller la notification. Mettre en place le processus de notification des vulnérabilités exploitées à l’ENISA.

Questions fréquentes