Cyber Resilience Act CRA Produits Numériques

Exigences essentielles CRA : security by design

Le CRA impose aux fabricants des exigences essentielles de cybersécurité avant la mise sur le marché : (1) Sécurité par conception et par défaut — pas de vulnérabilités connues lors de la mise sur le marché, sécurité activée par défaut (pas de mots de passe universels, paramètres sécurisés par défaut) ; (2) Authentification et contrôle d'accès — mécanismes d'authentification appropriés, protection contre les accès non autorisés ; (3) Protection des données — chiffrement des données au repos et en transit, minimisation de la collecte de données ; (4) Disponibilité — résilience aux attaques DoS de base pour les produits dont la disponibilité est critique ; (5) Gestion des mises à jour — capacité de mise à jour sécurisée du logiciel embarqué, vérification de l'intégrité des mises à jour ; (6) Surface d'attaque minimale — désactivation des interfaces et services inutilisés, suppression des credentials par défaut.

Ces exigences s'appliquent pendant tout le cycle de vie du produit, pas seulement lors de sa mise sur le marché initiale. Les fabricants doivent maintenir un processus de surveillance des vulnérabilités connues, notifier les vulnérabilités découvertes, et fournir des correctifs de sécurité sans frais supplémentaires pendant la durée de support.

SBOM et obligations de divulgation des vulnérabilités

Le CRA impose la fourniture d'un SBOM (Software Bill of Materials) pour les produits numériques, détaillant les composants logiciels tiers inclus (bibliothèques open source, frameworks, dependencies). Le SBOM doit être fourni aux autorités de surveillance du marché sur demande et doit permettre d'identifier rapidement les composants affectés par de nouvelles vulnérabilités (ex. : si une bibliothèque Log4j est utilisée dans un produit, le fabricant doit être capable de l'identifier via son SBOM et de fournir une mise à jour rapidement).

La divulgation coordonnée des vulnérabilités (CVD — Coordinated Vulnerability Disclosure) est imposée par le CRA : les fabricants doivent mettre en place un processus de réception et de traitement des rapports de vulnérabilités provenant de chercheurs de sécurité et du public (programme de bug bounty ou adresse de contact dédiée type security@). Les vulnérabilités activement exploitées doivent être notifiées à l'ENISA et à l'autorité nationale dans les 24h, avec rapport final dans les 14 jours. Ce mécanisme de notification est distinct de (et complémentaire à) NIS2 qui couvre les incidents sur les entités essentielles/importantes.

Transition et impact sur les éditeurs de logiciels

Le CRA a un impact majeur sur les éditeurs de logiciels (ISV — Independent Software Vendors) commercialisant des produits sur le marché européen. Les principaux changements : obligation de support sécurité pendant 5 ans minimum (forçant une refonte des modèles de fin de vie des produits — les logiciels avec support limité doivent avoir des plans de maintenance de sécurité clairs), obligation de SBOM (nécessite l'outillage SCA — Software Composition Analysis — pour maintenir un SBOM à jour), processus de gestion des vulnérabilités formalisé (de la réception du rapport à la fourniture du patch), et potentiel marquage CE pour les produits conformes (similaire à d'autres régulations produit).

Les petites entreprises et startups éditrices de logiciels sont particulièrement impactées par les coûts de mise en conformité CRA. La Commission européenne a prévu des mesures d'accompagnement pour les PME (délais supplémentaires, accès à des ressources de formation). Des clusters et associations sectorielles (TECH.EU, Syntec Numérique en France) travaillent à des guides pratiques d'implémentation du CRA pour les éditeurs de logiciels de taille moyenne.