Les exigences de l'annexe I, et la règle qui commande tout
Treize propriétés du produit, huit obligations de gestion des vulnérabilités, et la règle qui commande tout : justifier ce qui ne s'applique pas.
Sur cette page
L'annexe I contient vingt et une exigences : treize propriétés que le produit doit présenter (partie I, point 2) et huit obligations de gestion des vulnérabilités qui pèsent sur le fabricant (partie II). Elles conditionnent la mise à disposition sur le marché à compter du 11 décembre 2027 (art. 6 et art. 71). Elles ne s'appliquent pas toutes à tous les produits, et c'est le point que presque personne ne lit correctement.
Treize propriétés, mais pas treize cases à cocher
Les treize propriétés ne forment pas une liste de contrôle universelle. Elles sont introduites par une phrase qui les subordonne à votre propre évaluation des risques, et le règlement vous demande alors de justifier celles que vous écartez.
L'article 13, paragraphe 3 dit ce que doit contenir cette évaluation, et c'est très précis. Elle indique « si et, dans l'affirmative, de quelle manière » les exigences de l'annexe I, partie I, point 2 sont applicables au produit concerné. Elle indique également de quelle manière le fabricant applique l'annexe I, partie I, point 1 et les exigences de gestion des vulnérabilités de la partie II.
La conséquence est écrite à l'article 13, paragraphe 4, dernière phrase : lorsque certaines exigences essentielles ne sont pas applicables au produit, le fabricant fait figurer une justification claire dans la documentation technique. Autrement dit, le Cyber Resilience Act (CRA) ne vous impose pas les treize propriétés : il vous impose de justifier celles qui ne s'appliquent pas. C'est la différence entre un questionnaire rempli et un dossier opposable, et c'est la seule chose qu'un contrôle regardera.
Pour savoir en deux minutes si ces exigences vous visent et à quel titre, le diagnostic pose treize questions au maximum, sans création de compte : commencer le diagnostic.
Partie I : ce que le produit doit être
Les treize propriétés sont regroupées ici en cinq familles, qui n'existent pas dans le règlement mais rendent la lecture tenable. Le code officiel figure en regard de chacune.
Ce que vaut le produit le jour où il est vendu. Cette famille protège l'acheteur contre un produit livré déjà vulnérable, ou livré ouvert.
2 a)être mis à disposition sur le marché sans vulnérabilité exploitable connue.2 b)être mis à disposition sur le marché avec une configuration de sécurité par défaut, sauf accord contraire pour un produit sur mesure, y compris la possibilité de réinitialiser le produit à son état d'origine.
Ce qui permet de le réparer ensuite. Cette famille protège la capacité à corriger une faille sans remplacer le produit.
2 c)être conçus de façon à ce que leurs vulnérabilités puissent être corrigées par des mises à jour de sécurité, y compris, le cas échéant, par des mises à jour automatiques régulières activées par défaut mais faciles à désactiver, par la communication aux utilisateurs des mises à jour disponibles et par la possibilité de les différer temporairement.
Qui entre, et ce qu'on peut en savoir. Cette famille protège contre l'accès non autorisé et rend l'incident constatable après coup.
2 d)assurer la protection contre les accès non autorisés par des mécanismes de contrôle appropriés, y compris par des systèmes d'authentification, d'identité ou de gestion des accès, et signaler tout accès non autorisé.2 l)fournir des informations relatives à la sécurité en enregistrant et en surveillant les activités internes pertinentes, y compris l'accès ou la modification des données, des services ou des fonctions, tout en laissant à l'utilisateur la possibilité de désactiver le mécanisme.
Ce que deviennent les données. Cette famille protège les données de l'utilisateur pendant et après l'usage du produit.
2 e)protéger la confidentialité des données stockées, transmises ou traitées, par exemple en chiffrant les données pertinentes au repos ou en transit au moyen de mécanismes de pointe.2 f)protéger l'intégrité des données, des commandes, des programmes et de la configuration contre toute manipulation ou modification non autorisée par l'utilisateur, et signaler les corruptions.2 g)ne traiter que les données adéquates, pertinentes et limitées à ce qui est nécessaire au regard de la finalité prévue du produit, ce que le règlement appelle la minimisation des données.2 m)donner aux utilisateurs la possibilité de supprimer facilement, en toute sécurité et de manière permanente toutes les données et tous les paramètres, et permettre un transfert sécurisé lorsque ces données peuvent être portées vers d'autres produits ou systèmes.
Ce qui se passe quand cela tourne mal. Cette famille protège le service rendu, le voisinage réseau du produit, et limite la casse.
2 h)protéger la disponibilité des fonctions essentielles et de base, notamment après un incident, y compris par des mesures de résilience et d'atténuation face aux attaques par déni de service.2 i)réduire au maximum les répercussions négatives générées par les produits eux-mêmes ou par les appareils connectés sur la disponibilité des services fournis par d'autres dispositifs ou réseaux.2 j)être conçus, développés et fabriqués de manière à limiter les surfaces d'attaque, y compris les interfaces externes.2 k)être conçus, développés et fabriqués de manière à réduire les répercussions d'un incident, en utilisant des mécanismes et des techniques appropriés de limitation de l'exploitation de failles.
Une exigence est placée avant ces treize propriétés et ne se discute pas : les produits sont conçus, développés et fabriqués de manière à garantir un niveau de cybersécurité approprié en fonction des risques (annexe I, partie I, point 1).
Partie II : ce que le fabricant doit tenir
Les huit obligations de la partie II ne portent pas la même conditionnalité que les treize propriétés. Leur phrase d'introduction est sans réserve : « Les fabricants des produits comportant des éléments numériques : ». Le « le cas échéant » de la partie I, point 2 n'y figure pas, l'article 6, point b) exige que les processus du fabricant soient conformes à la partie II sans condition, et l'article 13, paragraphe 3 demande à l'évaluation des risques d'indiquer de quelle manière ces exigences sont appliquées, et non si elles le sont.
Quatre d'entre elles portent sur la connaissance et la correction :
II.1recenser et documenter les vulnérabilités et les composants des produits, notamment par l'établissement d'une nomenclature des logiciels dans un format couramment utilisé et lisible par machine couvrant au moins les dépendances de niveau supérieur.II.2gérer et corriger sans retard les vulnérabilités, y compris par des mises à jour de sécurité ; lorsque cela est techniquement possible, les nouvelles mises à jour de sécurité sont fournies séparément des mises à jour de fonctionnalité.II.3soumettre régulièrement les produits à des tests et examens de sécurité efficaces.II.7prévoir des mécanismes de distribution sécurisée des mises à jour et, le cas échéant, automatiser les mises à jour de sécurité.
Quatre autres portent sur ce que le fabricant doit dire, et à qui :
II.4dès la publication d'une mise à jour de sécurité, communiquer sur les vulnérabilités corrigées : description, identification du produit concerné, conséquences, gravité, et informations claires aidant les utilisateurs à y remédier.II.5mettre en place et appliquer une politique de divulgation coordonnée des vulnérabilités.II.6faciliter le partage d'informations sur les vulnérabilités potentielles des produits et des composants tiers qu'ils contiennent, y compris en fournissant une adresse de contact pour le signalement.II.8veiller à ce que les correctifs soient diffusés sans retard et, sauf accord contraire pour un produit sur mesure, « gratuitement », accompagnés de messages consultatifs.
Ce que cela demande concrètement
L'ordre de travail découle du texte lui-même. L'évaluation des risques vient en premier, parce que c'est elle qui décide de l'applicabilité (art. 13, paragraphes 2 et 3). Elle est documentée et mise à jour selon les besoins pendant la période d'assistance, et elle entre dans la documentation technique de l'annexe VII (art. 13, paragraphe 4).
Vient ensuite la justification des exigences écartées, qui est la pièce la plus souvent absente et la plus facile à demander lors d'un contrôle. Puis la nomenclature des logiciels, qui n'est pas un livrable ponctuel mais un état à régénérer à chaque version. C'est le travail que le dossier technique assemble, produit par produit.
Questions fréquentes
Dois-je satisfaire les treize exigences de l'annexe I ?
Pas nécessairement. Les treize propriétés de la partie I, point 2 s'appliquent « le cas échéant », sur la base de l'évaluation des risques de cybersécurité de l'article 13, paragraphe 2. Celle-ci indique si chacune est applicable à votre produit et, dans l'affirmative, de quelle manière elle est mise en oeuvre (art. 13, paragraphe 3). Ce qui est en revanche obligatoire, c'est de faire figurer une justification claire dans la documentation technique pour chaque exigence écartée (art. 13, paragraphe 4).
Les huit obligations de gestion des vulnérabilités sont-elles également conditionnelles ?
Non, pas de la même façon. Leur phrase d'introduction ne comporte pas de réserve, l'article 6, point b) exige sans condition que les processus mis en place par le fabricant soient conformes à l'annexe I, partie II, et l'article 13, paragraphe 3 demande à l'évaluation des risques d'indiquer de quelle manière ces exigences sont appliquées. Certaines contiennent des réserves internes, par exemple l'automatisation des mises à jour « le cas échéant » au point 7, mais l'obligation elle-même n'est pas subordonnée à l'évaluation des risques.
Qu'est-ce que la nomenclature des logiciels exigée par le CRA ?
Le règlement la définit comme un document officiel contenant les détails et les relations avec la chaîne d'approvisionnement des différents composants utilisés dans la fabrication du produit (art. 3, point 39). L'annexe I, partie II, point 1 impose un format couramment utilisé et lisible par machine, couvrant au moins les dépendances de niveau supérieur. La Commission peut préciser par acte d'exécution le format et les éléments de cette nomenclature (art. 13, paragraphe 24), ce qui n'est pas fait à ce jour.
La documentation technique doit-elle être publique ?
Non, en règle générale. Elle est tenue à la disposition des autorités de surveillance du marché pendant au moins dix ans après la mise sur le marché, ou pendant la période d'assistance si celle-ci est plus longue (art. 13, paragraphe 13). Une exception existe : un fabricant dont le produit répond aux critères de logiciel libre et ouvert et relève d'une catégorie de l'annexe III peut choisir les procédures de l'article 32, paragraphe 1 à condition de rendre publique sa documentation technique au moment de la mise sur le marché (art. 32, paragraphe 5).
Faut-il attendre les normes harmonisées pour travailler sur l'annexe I ?
Les normes harmonisées ouvriraient la présomption de conformité de l'article 27, et aucune n'est citée au Journal officiel de l'Union à ce jour. Cela ne suspend rien : l'article 71 fixe l'application au 11 décembre 2027 sans la subordonner à leur publication. Ce qui est stable dès maintenant est aussi ce qui prend le plus de temps, c'est-à-dire l'évaluation des risques, la nomenclature des logiciels et les processus de gestion des vulnérabilités.
Savoir si le règlement vous concerne
Treize questions pour savoir si le règlement vous concerne, à quel titre, et ce qui s’applique déjà à vous. Sans frais, sans compte.