Les exigences essentielles du CRA (annexe I) expliquées

L’annexe I du Cyber Resilience Act tient en deux pages, mais chaque ligne se traduit en décisions de conception, de tests et de processus. Cet article reprend les 21 exigences avec des exemples d’appareils, et indique où les retrouver dans l’ETSI EN 303 645, l’EN 18031-1 et l’IEC 62443.

L’annexe I en bref : deux parties, 21 exigences

L’annexe I du Cyber Resilience Act (règlement (UE) 2024/2847) fixe les exigences essentielles de cybersécurité que tout produit comportant des éléments numériques devra respecter pour être mis sur le marché de l’UE à partir du 11 décembre 2027 (art. 71(2)).

La partie I porte sur le produit. Il doit offrir un niveau de cybersécurité approprié en fonction des risques (point 1), puis, le cas échéant, satisfaire à treize exigences (point 2) : pas de vulnérabilité exploitable connue, configuration sécurisée par défaut, mises à jour de sécurité, protection contre les accès non autorisés, confidentialité et intégrité des données, minimisation des données, disponibilité, limitation de l’impact sur les autres réseaux, réduction de la surface d’attaque et de l’impact d’un incident, journalisation et suppression sécurisée des données.

La partie II porte sur le fabricant : huit exigences de gestion des vulnérabilités pendant toute la période d’assistance, dont une nomenclature des logiciels (SBOM), des tests réguliers, des avis de sécurité, une politique de divulgation coordonnée et des correctifs gratuits diffusés sans retard.

Toutes les exigences de la partie II s’appliquent ; celles de la partie I sont sélectionnées et dimensionnées par l’évaluation des risques, qui justifie aussi celles qui ne s’appliquent pas (art. 13(3) et 13(4)). Pour situer l’annexe I dans le règlement, voir notre guide complet du Cyber Resilience Act.

Comment lire l’annexe I : une logique de risque

L’annexe I ne s’applique pas en bloc : les exigences de gestion des vulnérabilités s’imposent toutes, tandis que les exigences de conception sont choisies et dimensionnées par l’évaluation des risques de cybersécurité du fabricant.

Le point 2 de la partie I commence par « Sur la base de l’évaluation des risques de cybersécurité visée à l’article 13, paragraphe 2 », et les exigences a) à m) s’appliquent « le cas échéant ». Selon l’article 13, cette évaluation est prise en compte de la planification à la maintenance (13(2)) ; elle est documentée, mise à jour pendant la période d’assistance, fondée sur l’utilisation prévue et raisonnablement prévisible, et indique si et comment chaque exigence s’applique (13(3)) ; elle figure dans la documentation technique, avec une justification claire des exigences non applicables (13(4)).

Exemple de la FAQ de la Commission (v1.4, 4.1.3) : un produit dont l’utilisation prévue ne comprend aucun traitement de données personnelles n’a pas besoin de mesures spécifiques pour ces données. Les exigences sont « orientées objectif et neutres sur le plan technologique » (FAQ 4.2.1) : le CRA ne prescrit ni algorithme ni longueur de mot de passe.

Ce que « en fonction des risques » ne veut pas dire

Selon les lignes directrices de la Commission C(2026) 5252 (points 157 à 163, non contraignantes), le risque résiduel s’apprécie au regard d’un niveau de cybersécurité approprié, et non de l’appétence au risque de l’entreprise : la tolérance interne, la stratégie commerciale ou le seul coût ne justifient pas de laisser un risque non traité (points 158 et 163). Le risque ne peut pas être transféré à l’utilisateur pour compenser une faiblesse de conception (point 161). Leviers admis : réduire la surface d’attaque, ajouter des protections, limiter une fonction, restreindre la destination du produit et informer des risques résiduels (points 160 et 162), par exemple un capteur industriel réservé aux environnements de confiance (exemple 66).

Partie I, exigences a) à f) : le socle

Les six premières exigences de l’annexe I, partie I, forment le socle de tout produit connecté : livrer sans faille exploitable connue, sécurisé par défaut, corrigeable par mises à jour, protégé contre les accès non autorisés, et protégeant la confidentialité et l’intégrité des données.

Exigence (annexe I, partie I, point 2)	En pratique	Exemple
a) Pas de vulnérabilité exploitable connue	Comparer la SBOM aux bases de vulnérabilités avant chaque version ; tests selon le risque	Bibliothèque TLS vulnérable mise à jour avant livraison
b) Configuration sécurisée par défaut, réinitialisation	Pas de mot de passe universel, débogage et ports inutiles fermés, retour usine	Caméra livrée avec services d’administration à distance désactivés
c) Mises à jour de sécurité	Automatiques par défaut si pertinent, faciles à désactiver, notifiées, différables temporairement	Thermostat qui installe les correctifs la nuit et prévient l’utilisateur
d) Protection contre les accès non autorisés	Authentification, gestion des identités et des accès, signalement des accès non autorisés	Routeur avec mot de passe unique par appareil et verrouillage après échecs
e) Confidentialité	Chiffrement des données pertinentes au repos et en transit « au moyen de mécanismes de pointe »	Flux vidéo chiffré entre la caméra et l’application
f) Intégrité	Signature des micrologiciels, démarrage sécurisé, intégrité de la configuration et des commandes, signalement des corruptions	Automate qui refuse un micrologiciel non signé

Précisions de la FAQ de la Commission : pour a), le CRA n’exige pas un produit exempt de toute vulnérabilité ; l’exploitabilité s’apprécie au cas par cas, en conditions de fonctionnement effectives, au moment de la mise sur le marché (FAQ 4.2.2 et 4.2.3 ; art. 3, point 41). Pour b), un composant doit être sûr dans la configuration où il est livré, par exemple un microcontrôleur aux interfaces réseau désactivées par défaut (FAQ 4.2.4). Pour d), on oublie souvent de signaler les accès non autorisés.

Partie I, exigences g) à m) : données, résilience, traces, effacement

Les sept exigences suivantes visent à limiter ce que le produit collecte et expose, à préserver ses fonctions essentielles en cas d’attaque, à tracer les événements de sécurité et à permettre l’effacement complet des données.

Exigence (annexe I, partie I, point 2)	En pratique	Exemple
g) Minimisation des données	Ne traiter que les données adéquates, pertinentes et nécessaires à la finalité prévue	Revue des champs envoyés au cloud
h) Disponibilité des fonctions essentielles et de base	Résilience, notamment après un incident, et face au déni de service	Serrure connectée manœuvrable localement si le cloud est inaccessible
i) Limiter l’impact sur d’autres dispositifs ou réseaux	Limitation de débit, comportement réseau maîtrisé	Un appareil compromis ne doit pas devenir un relais d’attaque
j) Limiter les surfaces d’attaque, y compris les interfaces externes	Fermer ce qui ne sert pas	Ports JTAG ou UART désactivés en production
k) Réduire l’impact d’un incident	Cloisonnement, moindre privilège, protections contre l’exploitation	Service réseau exécuté sans droits d’administrateur
l) Journalisation et surveillance	Enregistrer les activités internes pertinentes (accès, modification de données, services, fonctions), désactivable par l’utilisateur	Journal des connexions et changements de configuration
m) Suppression et transfert sécurisés	Supprimer facilement, sûrement et définitivement toutes les données et paramètres ; transfert sécurisé si prévu	Fonction « effacer et réinitialiser » avant revente

La minimisation g) rejoint le RGPD et, en Suisse, la LPD (RS 235.1), sans se confondre avec eux : le CRA vise toutes les données. Un capteur de température sans données personnelles ne l’appliquera pas comme un objet porté de suivi de santé ; la différence se justifie dans l’évaluation des risques (FAQ 4.1.3).

Partie II : les huit exigences de gestion des vulnérabilités

La partie II de l’annexe I oblige le fabricant à organiser la gestion des vulnérabilités pendant toute la période d’assistance, en règle générale d’au moins cinq ans : inventaire des composants, correction, tests, publication, divulgation coordonnée et diffusion sécurisée et gratuite des correctifs.

Point	Ce qu’il faut avoir	Preuve dans la documentation technique
1) Recenser vulnérabilités et composants	SBOM dans un format couramment utilisé et lisible par machine, couvrant au moins les dépendances de niveau supérieur	SBOM (annexe VII, point 2 b))
2) Corriger sans retard	Mises à jour de sécurité, séparées des mises à jour fonctionnelles si techniquement possible	Processus de correction
3) Tester régulièrement	Tests et examens de sécurité efficaces et réguliers	Rapports d’essais (annexe VII, point 6)
4) Publier des avis de sécurité	Description, identification du produit, conséquences, gravité, remèdes ; report possible dans des cas dûment justifiés	Modèle d’avis, historique
5) Divulgation coordonnée	Politique écrite et appliquée	Politique (annexe VII, point 2 b))
6) Faciliter le partage d’informations	Adresse de contact pour signaler les vulnérabilités, y compris des composants tiers	Preuve de l’adresse de contact
7) Distribuer les mises à jour de façon sécurisée	Mécanisme sûr, automatisé le cas échéant	Description de la solution technique
8) Diffuser les correctifs sans retard et gratuitement	Avec des messages d’information ; exception par accord pour un produit sur mesure avec un utilisateur professionnel	Procédure de diffusion

Le CRA n’impose pas de format de SBOM (SPDX et CycloneDX sont des exemples courants). Articles liés : période d’assistance d’au moins cinq ans, sauf durée d’utilisation prévue plus courte (art. 13(8)) ; mises à jour de sécurité disponibles au moins dix ans ou pendant le reste de la période d’assistance si elle est plus longue (art. 13(9)).

Une partie de ces processus sert déjà : depuis le 11 septembre 2026, il faut signaler les vulnérabilités activement exploitées sous 24 heures (art. 14).

Correspondance avec l’EN 303 645, l’EN 18031-1 et l’IEC 62443

En l’absence de normes harmonisées CRA, trois référentiels existants couvrent déjà l’essentiel de l’annexe I : l’ETSI EN 303 645 pour l’IoT grand public, l’EN 18031-1 pour les équipements radio et l’IEC 62443-4-1 et 4-2 pour les composants industriels.

Thème	CRA, annexe I	EN 18031-1:2024	EN 303 645 V3.1.3	IEC 62443-4-2 / 4-1
Analyse de risque	art. 13(2) à (4) ; I, 1)	arbres de décision	5.0 (justifications)	4-1 SR-2
Mots de passe, authentification	I, 2 d)	AUM-1 à AUM-6	5.1	CR 1.1, 1.5, 1.7, 1.11
Contrôle d’accès	I, 2 d)	ACM-1, ACM-2	pas de disposition dédiée	CR 2.1
Communications	I, 2 e) f)	SCM-1 à SCM-4, CRY-1	5.5	CR 3.1, 4.1, 4.3
Secrets et données	I, 2 e) g) m)	SSM, CCK ; EN 18031-2	5.4, 5.8, 5.11, ch. 6	CR 4.1, 4.2
Intégrité du logiciel	I, 2 f)	SUM-2	5.7	CR 3.4, EDR 3.14
Mises à jour, support	I, 2 c) ; II, 2) 7) 8) ; art. 13(8)	SUM-1 à SUM-3	5.3	EDR 3.10
Surface d’attaque	I, 2 b) j) k)	GEC-2 à GEC-6	5.6, 5.13	CR 7.7, EDR 2.13
Résilience	I, 2 h) i)	RLM-1, NMM-1, TCM-1	5.9	CR 7.1, 7.4
Journalisation	I, 2 l)	pas dans la partie 1 (LGM dans l’EN 18031-2)	5.10	CR 2.8
Composants tiers, SBOM	II, 1) ; art. 13(5)	GEC-1	pas de disposition dédiée	4-1 SM-9, SM-10
Vulnérabilités, divulgation	II, 3) à 6) ; art. 14	pas de disposition dédiée	5.2	4-1 DM-1 à DM-6, SVV-3, SVV-4
Documentation, information	art. 13(12) à (19), 31 ; annexes II, VII	GEC-4	5.12	4-1 SG-1 à SG-6

Ce tableau est indicatif : appliquer l’EN 303 645 ou l’EN 18031 ne donne pas présomption de conformité au CRA. Le travail fait pour la RED reste une bonne base : voir notre article sur l’EN 18031.

Même avec une norme harmonisée, l’évaluation des risques reste due (FAQ 4.1.7).

Démontrer la conformité : justifier, tester, documenter

Satisfaire à l’annexe I ne suffit pas : le fabricant doit pouvoir le démontrer, exigence par exigence, dans une documentation technique qui contient l’évaluation des risques, les solutions retenues et les rapports d’essais.

L’annexe VII fixe le contenu : l’évaluation des risques et l’applicabilité des exigences de la partie I (point 3) ; les normes appliquées ou, à défaut, les solutions adoptées pour les parties I et II (point 5) ; les rapports des essais vérifiant la conformité du produit et des processus de gestion des vulnérabilités (point 6).

Méthode que nous recommandons : une matrice de 21 lignes (13 + 8), avec les colonnes « Applicable ? », « Justification », « Mesure » et « Preuve » (essai, revue, document). Elle structure la documentation technique et, le cas échéant, l’examen par un organisme notifié. Le CRA n’impose ni méthode d’évaluation ni laboratoire particulier ; le fabricant reste seul responsable de l’évaluation de la conformité (FAQ 6.5).

Erreurs fréquentes : traiter la cybersécurité comme un essai final ; oublier le cloud du fabricant, car le traitement de données à distance sans lequel le produit ne peut remplir une de ses fonctions fait partie du produit (art. 3, point 2) ; n’avoir ni adresse de signalement ni processus de correction ; déclarer des exigences non applicables sans justification écrite.

Pour savoir où se situe votre produit face aux 21 exigences de l’annexe I, Säfeli réalise une analyse d’écart exigence par exigence, conduit l’analyse de menaces (TARA) qui justifie vos choix et réalise des tests d’intrusion sur les mesures clés. Vérifiez aussi le calendrier du CRA pour planifier ces travaux. Säfeli accompagne ; le fabricant reste responsable de la conformité de son produit. Contactez-nous pour un premier entretien de 30 minutes.