Ce que votre produit doit porter, et comment le prouver
Les vingt et une exigences de l'annexe I, la classe qui décide de la voie d'évaluation, la période d'assistance, et la règle qui commande tout le reste.
Sur cette page
- La classe ne change pas les exigences, elle change qui vérifie
- Le coeur du règlement : justifier ce qui ne s'applique pas
- Les treize propriétés, en cinq familles
- Les huit obligations de gestion des vulnérabilités ne sont pas conditionnelles
- La période d'assistance, et le coût que personne ne provisionne
- Où tout cela se range : la documentation technique
- Situer votre produit avant de constituer le dossier
À compter du 11 décembre 2027, un produit comportant des éléments numériques ne peut plus être mis sur le marché de l'Union s'il ne satisfait pas aux exigences essentielles de l'annexe I : treize propriétés attendues du produit et huit obligations de gestion des vulnérabilités. Ces exigences sont les mêmes pour tous les produits, mais la façon de démontrer qu'elles sont satisfaites dépend de la classe. Et surtout, le règlement ne vous impose pas les treize propriétés : il vous impose de justifier celles qui ne s'appliquent pas.
La classe ne change pas les exigences, elle change qui vérifie
Le Cyber Resilience Act (CRA) distingue quatre régimes : le produit par défaut, le produit important de classe I, le produit important de classe II et le produit critique. Les exigences de fond ne varient pas, ce sont toujours celles de l'annexe I.
Ce qui varie est la procédure d'évaluation de la conformité, et donc votre calendrier et votre budget. Pour un produit par défaut, le fabricant choisit librement l'une des procédures de l'article 32, paragraphe 1, dont le contrôle interne. Pour un produit de classe I, énuméré à l'annexe III, le contrôle interne n'est ouvert que si des normes harmonisées, des spécifications communes ou un schéma européen de certification d'un niveau au moins substantiel sont appliqués intégralement ; à défaut, l'organisme notifié devient la voie obligée (art. 32, paragraphe 2). Pour un produit de classe II, cette échappatoire n'existe pas (art. 32, paragraphe 3). Pour un produit critique, énuméré à l'annexe IV, un certificat européen de cybersécurité peut être imposé par acte délégué ; à défaut, c'est le régime de la classe II qui s'applique (art. 32, paragraphe 4).
Le classement se fait sur un critère unique : la fonctionnalité de base du produit (art. 7, paragraphe 1).
Un fait change la lecture de tout ce qui précède : aucune norme harmonisée n'est citée au Journal officiel de l'Union à ce jour, et la présomption de conformité de l'article 27 n'est ouverte pour aucune catégorie de produit. En l'état des textes publiés, la voie du contrôle interne n'est donc pas praticable pour un produit de classe I, et aucun organisme notifié n'est enregistré à ce jour.
Le coeur du règlement : justifier ce qui ne s'applique pas
C'est le point le plus méconnu du CRA et celui qui sépare un questionnaire d'un dossier opposable. Les treize propriétés de l'annexe I ne forment pas une liste de contrôle universelle, et le règlement le dit dans la phrase qui les introduit.
L'annexe I, partie I, point 2 s'ouvre ainsi : « Sur la base de l'évaluation des risques de cybersécurité visée à l'article 13, paragraphe 2, les produits comportant des éléments numériques doivent, le cas échéant ». Deux membres portent tout le sens, « sur la base de l'évaluation des risques » et « le cas échéant ».
L'article 13, paragraphe 3 est précis sur ce que cette évaluation doit contenir : 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, et comment elles sont mises en oeuvre. L'article 13, paragraphe 4 en tire la conséquence dans sa dernière phrase : lorsque certaines exigences essentielles ne sont pas applicables, le fabricant fait figurer une justification claire dans la documentation technique.
Autrement dit, écarter une exigence est permis, l'écarter sans l'écrire ne l'est pas. C'est la pièce la plus souvent absente d'un dossier et la plus facile à demander lors d'un contrôle.
Les treize propriétés, en cinq familles
Les treize propriétés portent sur ce que le produit est et sur ce qu'il devient. Les familles ci-dessous n'existent pas dans le règlement, elles rendent la liste lisible.
Ce que vaut le produit le jour de la vente : aucune vulnérabilité exploitable connue à la mise à disposition sur le marché, configuration de sécurité par défaut et réinitialisation possible (2 a), 2 b)).
Ce qui permet de le réparer ensuite : une conception qui rend les vulnérabilités corrigeables par mise à jour de sécurité, activée par défaut mais désactivable (2 c)).
Qui entre, et ce qu'on peut en savoir : contrôle des accès non autorisés avec signalement, journalisation désactivable par l'utilisateur (2 d), 2 l)).
Ce que deviennent les données : confidentialité, intégrité, minimisation, effacement et portabilité sécurisés (2 e), 2 f), 2 g), 2 m)).
Ce qui se passe quand cela tourne mal : disponibilité des fonctions essentielles après un incident, absence de nuisance aux autres réseaux, surface d'attaque limitée, effets d'un incident réduits (2 h), 2 i), 2 j), 2 k)).
Une exigence les précède 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).
Les huit obligations de gestion des vulnérabilités ne sont pas conditionnelles
La partie II de l'annexe I ne porte pas la même réserve que la partie I. Sa phrase d'introduction est sans condition, l'article 6, point b) exige que les processus du fabricant y soient conformes, et l'article 13, paragraphe 3 demande d'indiquer de quelle manière ces exigences sont appliquées, et non si elles le sont.
Quatre obligations portent sur la connaissance et la correction : recenser les composants et établir une nomenclature des logiciels lisible par machine couvrant au moins les dépendances de niveau supérieur, corriger sans retard, tester régulièrement, distribuer les mises à jour de manière sécurisée. Quatre portent sur ce que le fabricant dit et à qui : publier l'information sur les vulnérabilités corrigées, tenir une politique de divulgation coordonnée, fournir une adresse de contact pour le signalement, diffuser les correctifs sans retard.
Elles courent pendant toute la période d'assistance : un dossier constitué puis refermé est faux à la version suivante.
La période d'assistance, et le coût que personne ne provisionne
La période d'assistance est la durée pendant laquelle le fabricant doit traiter les vulnérabilités de son produit. Elle est d'au moins cinq ans, sauf lorsque le produit est censé pouvoir être utilisé moins longtemps, auquel cas elle correspond à la durée d'utilisation prévue (art. 13, paragraphe 8).
Deux chiffres s'y ajoutent, et le second est celui qu'on oublie. Chaque mise à jour de sécurité reste disponible, après son émission, pendant dix ans au minimum ou pendant le reste de la période d'assistance, la période la plus longue étant retenue (art. 13, paragraphe 9) : le décompte part de l'émission du correctif, pas de la mise sur le marché. Et la date de fin de la période d'assistance, mois et année au minimum, est précisée au moment de l'achat (art. 13, paragraphe 19).
Cette durée ne se choisit pas, elle se justifie. Le fabricant la fixe en tenant compte, en particulier, des attentes raisonnables des utilisateurs, de la nature du produit et du droit de l'Union applicable à sa durée de vie, et les informations retenues figurent dans la documentation technique (art. 13, paragraphe 8). Les autorités de surveillance du marché contrôlent nommément l'application de ces critères (art. 52, paragraphe 16).
Où tout cela se range : la documentation technique
Tout ce qui précède aboutit à une seule pièce, la documentation technique. Elle contient au minimum les éléments de l'annexe VII (art. 31, paragraphe 1), et elle est établie avant la mise sur le marché puis tenue à jour au moins pendant la période d'assistance (art. 31, paragraphe 2).
L'annexe VII y range la description générale du produit et ses versions, la conception et les processus de gestion des vulnérabilités avec la nomenclature des logiciels, l'évaluation des risques, et les informations ayant déterminé la période d'assistance. Elle est tenue à disposition des autorités de surveillance du marché dix ans au moins après la mise sur le marché, ou pendant la période d'assistance si celle-ci est plus longue (art. 13, paragraphe 13).
Situer votre produit avant de constituer le dossier
Le diagnostic détermine le rôle, la classe et la voie d'évaluation applicables à un produit donné. Treize questions au maximum, deux minutes, sans création de compte : commencer le diagnostic.
Les fiches de cet intercalaire
Les classes de produits, et ce que la classe change
La fiche donne les dix-neuf catégories de la classe I, les quatre de la classe II et les trois de l'annexe IV dans les libellés du règlement, avec la procédure d'évaluation attachée à chacune. Pour qui doit savoir dans quelle case tombe son produit et ce que cela implique en délai et en budget.
Les exigences de l'annexe I, et la règle qui commande tout
La fiche reprend les treize propriétés et les huit obligations une par une, avec leur libellé officiel et leur code, et démonte la mécanique de l'applicabilité conditionnelle. Pour le responsable produit qui prépare l'analyse d'écart et doit savoir ce qu'il faut prouver, point par point.
La période d'assistance, et ce qu'elle engage vraiment
La fiche distingue les trois durées à ne pas confondre, détaille les sept critères de détermination et le coût des deux erreurs de calibrage. Pour qui doit arrêter une durée défendable et l'inscrire dans son plan produit, et pour l'acheteur qui veut en faire un critère de choix.
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.