Cyber Resilience Act : ce que les éditeurs de logiciels doivent avoir fait d'ici fin 2027

Qualité et sécurité

Depuis le 11 septembre 2026, les fabricants doivent signaler les vulnérabilités activement exploitées dans leurs produits – y compris pour des produits vendus depuis longtemps. À partir du 11 décembre 2027, le Cyber Resilience Act s'applique pleinement. Qui commercialise dans l'UE des logiciels ou des appareils contenant des logiciels dispose donc encore d'un peu plus d'un an pour adapter ses produits et ses processus.

Qui est concerné par le CRA

Le Cyber Resilience Act, le règlement (UE) 2024/2847, s'applique aux produits comportant des éléments numériques mis sur le marché dans l'UE. Cela inclut aussi bien les appareils dotés de leur propre logiciel de commande que les logiciels purs, par exemple des programmes de bureau ou des add-ins de CAO. Est fabricant quiconque commercialise un tel produit sous son propre nom ou sa propre marque, à titre onéreux ou gratuit. Certains groupes de produits soumis à leurs propres règles, comme les dispositifs médicaux, sont exclus.

Les échéances

Vos tâches d'ici fin 2027

1. Mettre en place le circuit de signalement – immédiatement. En cas de vulnérabilité activement exploitée, une alerte précoce est due dans les 24 heures, une notification dans les 72 heures et un rapport final au plus tard 14 jours après la mise à disposition d'une correction. Pour les incidents de sécurité graves, les mêmes délais s'appliquent pour l'alerte précoce et la notification. Le signalement se fait via la plateforme unique de signalement de l'ENISA. Définissez qui reçoit, évalue et signale les informations – y compris pendant les congés.
2. Classer les produits. Quels produits et quelles versions sont concernés ? S'agit-il d'un produit standard, d'un produit important ou d'un produit critique ? Cela détermine si vous pouvez évaluer vous-même la conformité ou si vous avez besoin d'un organisme notifié.
3. Établir une nomenclature logicielle (SBOM). Le CRA exige une nomenclature dans un format courant lisible par machine, qui contienne au moins les dépendances de premier niveau. Le mieux est qu'elle soit générée automatiquement à chaque build, par exemple au format CycloneDX ou SPDX.
4. Traiter les vulnérabilités. Comparez régulièrement vos composants avec les bases de données publiques de vulnérabilités. Il vous faut une adresse de contact pour les signalements externes, une politique de divulgation coordonnée et des tests de sécurité réguliers. Publiez les vulnérabilités corrigées avec une description à l'intention des utilisateurs.
5. Définir le processus de mise à jour. Les mises à jour de sécurité doivent parvenir aux clients sans délai et en principe gratuitement, séparément des mises à jour fonctionnelles dans la mesure où cela est techniquement possible. La période de support est en règle générale d'au moins cinq ans. Chaque mise à jour de sécurité reste ensuite disponible pendant au moins dix ans ou jusqu'à la fin de la période de support, la durée la plus longue étant retenue.
6. Sécuriser le produit. Sont notamment exigés : aucune vulnérabilité exploitable connue à la livraison, une configuration sûre par défaut avec possibilité de réinitialisation, une protection contre les accès non autorisés, le chiffrement, une surface d'attaque aussi réduite que possible et la journalisation des opérations pertinentes pour la sécurité.
7. Documenter. La documentation technique comprend la description du produit, l'architecture, l'évaluation des risques de cybersécurité, les procédures de traitement des vulnérabilités et les informations destinées aux utilisateurs. Elle constitue la base de la déclaration UE de conformité. Vous devez conserver les deux pendant au moins dix ans ou pendant la durée de la période de support si celle-ci est plus longue.

Par où commencer

Commencez par ce qui s'applique déjà aujourd'hui et qui sera rentable partout par la suite : le circuit de signalement et la SBOM. Sans nomenclature, vous ne savez pas, en cas d'urgence, si une vulnérabilité nouvellement connue concerne votre produit – et le délai de 24 heures court quand même. Les tests automatisés sont un autre élément. Le CRA exige de tester régulièrement et efficacement la sécurité du produit. Des tests exécutés à chaque build fournissent pour cela des preuves traçables.

En cas d'infraction aux exigences essentielles ou aux obligations des articles 13 et 14, des amendes pouvant atteindre 15 millions d'euros ou 2,5 % du chiffre d'affaires annuel mondial sont encourues, le montant le plus élevé étant retenu.

Remarque : cet article donne un aperçu technique et ne constitue pas un conseil juridique. Veuillez clarifier la classification contraignante de votre produit avec votre service juridique ou vos avocats.

Erreurs typiques

• Attendre 2027. Les obligations de signalement s'appliquent depuis le 11 septembre 2026, pour les produits nouveaux comme pour les produits existants.
• « Notre produit est ancien, cela ne nous concerne pas. » Il faut quand même signaler. Et qui modifie substantiellement un produit existant après le 11 décembre 2027 doit ensuite satisfaire à toutes les exigences.
• Établir la SBOM une seule fois à la main. Elle est obsolète dès le build suivant. Elle a sa place dans le processus de build.
• Négliger les composants achetés et open source. Les vulnérabilités se cachent souvent dans les bibliothèques, pas dans le code propre.
• Ne livrer les mises à jour de sécurité qu'avec de nouvelles fonctions. Les clients doivent pouvoir combler une faille sans introduire une nouvelle version.
• Pas d'adresse de contact fixe. Les signalements de vulnérabilités atterrissent dans la boîte de réception générale et y restent.

Sources : règlement (UE) 2024/2847 (Cyber Resilience Act), en particulier art. 13, 14, 64, 69 et 71 ainsi que l'annexe I, EUR-Lex ; Cadida : Cyber Resilience Act. État : octobre 2026.