Exigences essentielles CRA : les 13 points de l'annexe I

L’essentiel. L’annexe I du Cyber Resilience Act (règlement (UE) 2024/2847) se divise en deux parties : la partie I décrit les propriétés de sécurité que le produit doit présenter, la partie II les processus de gestion des vulnérabilités que le fabricant doit faire tourner. La partie I comporte une exigence chapeau — point (1), sécurité appropriée au risque — puis 13 exigences détaillées au point (2), de (a) à (m). Ces 13 exigences ne sont pas une case à cocher : l’article 13(3) impose qu’elles ne s’appliquent que « le cas échéant », sur la base de l’analyse de risque, laquelle doit indiquer par écrit lesquelles s’appliquent, comment, et pourquoi les autres sont écartées. Le manquement à l’annexe I est sanctionné jusqu’à 15 millions d’euros ou 2,5 % du chiffre d’affaires mondial (art. 64(2)). Échéance d’application intégrale : 11 décembre 2027.

Le 27 juillet 2026, la Commission européenne a publié sa première communication d’orientation sur l’application du CRA — la communication C(2026) 5252 et son annexe, environ 80 pages construites autour de 67 exemples pratiques, sur le fondement de l’article 26 du règlement. Elle clarifie le périmètre, la notion de modification substantielle, la durée du support et le signalement. Elle ne touche à aucune date. Et elle confirme, en creux, ce que je constate chez les éditeurs et fabricants que j’accompagne : le blocage n’est presque jamais technique, il est méthodologique. Les équipes lisent les 13 points de l’annexe I comme une liste de contrôle à cocher, alors que le règlement les a conçus comme un résultat d’analyse de risque à documenter.

Voici donc l’annexe I telle qu’il faut la lire pour construire un dossier de conformité qui tienne devant une autorité de surveillance du marché.

Annexe I : deux parties, deux logiques à ne pas mélanger

L’erreur de cadrage la plus fréquente consiste à traiter l’annexe I comme un bloc homogène. Elle ne l’est pas.

La partie I porte sur les propriétés du produit. Elle décrit ce que l’objet livré doit faire ou empêcher : résister à l’accès non autorisé, chiffrer les données, limiter la surface d’attaque. C’est une exigence de conception, évaluée au moment de la mise sur le marché — et réévaluée à chaque modification substantielle au sens de l’art. 3(30), c’est-à-dire toute modification postérieure à la mise sur le marché qui affecte la conformité aux exigences de l’annexe I. Pour un logiciel livré en continu, ce point mérite un arbitrage explicite en interne : à partir de quel changement repasse-t-on par l’évaluation de conformité ?

La partie II porte sur les processus du fabricant. Ses 8 points imposent d’identifier et documenter les vulnérabilités et composants (y compris via un SBOM), de corriger sans délai, de tester régulièrement, de publier les correctifs, de tenir une politique de divulgation coordonnée, de fournir un point de contact, de distribuer les mises à jour de façon sécurisée et gratuite. C’est une exigence d’organisation, évaluée en continu pendant toute la période de support. Je l’ai traitée séparément dans le guide de gestion des vulnérabilités CRA, parce qu’elle relève d’un chantier différent : elle mobilise le PSIRT et l’ingénierie de production, pas les architectes produit.

Une conséquence pratique, souvent négligée : dans les procédures d’évaluation de conformité de l’annexe VIII, un organisme notifié n’examine pas seulement la conception du produit. Il réalise aussi des audits périodiques pour vérifier que les processus de la partie II sont effectivement mis en œuvre. Une conformité produit impeccable avec un processus vulnérabilités inexistant ne passe pas.

Le point (1) : l’exigence chapeau qui ne se négocie pas

Le point (1) de la partie I est court et sans condition : les produits comportant des éléments numériques « sont conçus, développés et fabriqués de manière à garantir un niveau approprié de cybersécurité en fonction des risques ».

Deux mots comptent. Approprié : le CRA ne fixe pas de niveau absolu, il exige une proportionnalité au risque — un gestionnaire de mots de passe et un thermostat connecté ne sont pas tenus au même standard. Conçus, développés et fabriqués : l’exigence couvre la chaîne complète, pas le seul livrable. Un produit sécurisé issu d’une chaîne de build non maîtrisée ne satisfait pas le point (1).

Contrairement aux 13 exigences du point (2), le point (1) ne comporte aucune clause de non-applicabilité. Il n’existe pas de produit dispensé de « sécurité appropriée en fonction des risques ». L’article 13(3) demande d’ailleurs à l’analyse de risque d’indiquer comment le fabricant applique ce point (1) — c’est-à-dire d’expliciter la démarche de sécurité par conception elle-même, et pas seulement ses résultats.

Les 13 exigences du point (2), traduites en obligations concrètes

Le point (2) s’ouvre par la formule décisive : « Sur la base de l’évaluation des risques de cybersécurité visée à l’article 13, paragraphe 2, et le cas échéant ». Suivent 13 exigences.

Réf.	Exigence de l’annexe I	Ce que cela veut dire en pratique
(a)	Absence de vulnérabilité exploitable connue à la mise sur le marché	Scan et revue du SBOM avant chaque release ; blocage de la mise sur le marché si une CVE exploitable subsiste
(b)	Configuration sécurisée par défaut, avec possibilité de réinitialisation	Pas de mot de passe usine partagé, services non nécessaires désactivés, fonction « retour à l’état initial »
©	Correction des vulnérabilités par mises à jour de sécurité	Canal de mise à jour ; mise à jour automatique activée par défaut lorsque pertinent, avec opt-out clair et report temporaire possible
(d)	Protection contre l’accès non autorisé, et signalement des accès	Authentification, gestion des identités et des accès, journalisation des tentatives d’accès
(e)	Confidentialité des données stockées, transmises ou traitées	Chiffrement au repos et en transit selon l’état de l’art
(f)	Intégrité des données, commandes, programmes et configurations	Signature du firmware, contrôle d’intégrité, alerte en cas de corruption
(g)	Minimisation des données traitées	Ne collecter que ce qui est adéquat, pertinent et limité à la finalité du produit
(h)	Disponibilité des fonctions essentielles, y compris après incident	Résilience, mode dégradé, mesures anti-déni de service
(i)	Non-dégradation des autres appareils et réseaux	Le produit ne doit pas devenir un relais d’attaque ni saturer le réseau hôte
(j)	Limitation des surfaces d’attaque, interfaces externes comprises	Fermeture des ports inutiles, réduction des interfaces de debug, désactivation des API non utilisées
(k)	Réduction de l’impact d’un incident	Mécanismes d’atténuation de l’exploitation : ASLR, sandboxing, cloisonnement des privilèges
(l)	Information de sécurité par enregistrement et suivi de l’activité interne	Journalisation des accès et modifications de données, services et fonctions — avec opt-out utilisateur
(m)	Suppression sécurisée et définitive des données et paramètres	Fonction d’effacement fiable ; transfert sécurisé si les données sont portables

Ce qui doit être vrai le jour de la mise sur le marché : (a) et (b)

Le point (a) est le plus brutal à appliquer parce qu’il est binaire : un produit ne peut pas être mis sur le marché avec une vulnérabilité exploitable connue. Non pas « corrigée dans les 30 jours », mais absente. En pratique, cela impose de placer une porte de sortie dans le pipeline de release, adossée au SBOM, et d’accepter qu’elle bloque parfois une livraison commerciale. C’est là que la conformité CRA entre en collision avec la roadmap — et c’est un arbitrage de direction générale, pas d’équipe sécurité.

Le point (b) — la configuration sécurisée par défaut — est celui qui a le plus d’effets de bord produit. Il condamne les identifiants d’usine partagés, exige de livrer avec les services non indispensables désactivés, et impose une fonction de retour à l’état initial. Le règlement ménage une seule exception : un accord contraire entre le fabricant et un utilisateur professionnel pour un produit sur mesure. Cette exception ne couvre pas un produit standard vendu en volume avec une configuration « client ».

Le socle mises à jour : le point ©

Le point © est plus prescriptif qu’il n’y paraît. Il ne demande pas seulement de pouvoir corriger : il demande, lorsque c’est applicable, des mises à jour de sécurité automatiques installées dans un délai approprié, activées par défaut, avec un mécanisme d’opt-out clair et facile à utiliser, la notification des mises à jour disponibles, et la possibilité de les reporter temporairement.

Cette exigence se prolonge dans l’annexe II, point 8(e), qui impose de documenter à l’utilisateur comment désactiver ce réglage par défaut. Et elle s’articule avec la durée de la période de support : l’art. 13(8) fixe un plancher de cinq ans, sauf lorsque la durée d’utilisation attendue du produit est plus courte. Sur ce point précis, la communication du 27 juillet 2026 apporte une lecture utile de la façon dont cette durée doit être déterminée et justifiée.

Contrôle d’accès et protection des données : (d), (e), (f), (g)

Ces quatre exigences constituent le cœur du recouvrement avec le RGPD, et il faut les lire ensemble. Le point (d) impose des mécanismes de contrôle d’accès et le signalement des accès non autorisés possibles. Les points (e) et (f) protègent la confidentialité et l’intégrité — « données à caractère personnel ou non », précise le texte, ce qui règle une question fréquente : le CRA ne s’intéresse pas qu’aux données personnelles.

Le point (g) est celui qui surprend le plus les ingénieurs : le CRA impose la minimisation des données en tant qu’exigence de cybersécurité produit, avec une formulation directement calquée sur l’art. 5(1)© RGPD (« adéquates, pertinentes et limitées à ce qui est nécessaire au regard de la finalité prévue »). Autrement dit, un produit qui remonte de la télémétrie inutile n’est pas seulement discutable au regard du RGPD : il est non conforme au CRA. J’ai détaillé ces points de jonction dans l’analyse de l’intersection entre CRA et RGPD.

Disponibilité et confinement : (h), (i), (j), (k)

Le point (h) porte sur la disponibilité des fonctions « essentielles et de base », y compris après un incident : il faut donc avoir défini, produit par produit, ce qui relève du socle fonctionnel à préserver en mode dégradé. Le point (i) est une exigence de bon voisinage réseau — un produit ne doit pas dégrader la disponibilité des services fournis par d’autres appareils ou réseaux. C’est la réponse du législateur aux botnets d’objets connectés.

Les points (j) et (k) sont des exigences d’architecture : limiter les surfaces d’attaque, y compris les interfaces externes, et réduire l’impact d’un incident par des mécanismes d’atténuation de l’exploitation. Ils ne se satisfont pas par un correctif tardif ; ils se démontrent par des choix de conception documentés dans la documentation technique de l’annexe VII.

Traçabilité et fin de vie : (l) et (m)

Le point (l) impose de fournir des informations de sécurité en enregistrant et en surveillant l’activité interne pertinente — accès ou modification de données, services et fonctions. Il comporte une réserve rarement remarquée : un mécanisme d’opt-out pour l’utilisateur. La journalisation n’est donc pas absolue, ce qui est cohérent avec la logique de minimisation du point (g) et évite de faire du journal de sécurité un dispositif de surveillance.

Le point (m) impose la possibilité de supprimer de façon sécurisée, définitive et simple l’ensemble des données et paramètres, et de transférer ces données de manière sécurisée lorsque le transfert est possible. C’est l’exigence à examiner en priorité si votre produit stocke des données personnelles : elle est le support technique du droit à l’effacement de l’art. 17 RGPD.

« Le cas échéant » : l’article 13(3) est le vrai pivot du dossier

Voici le point que je vois manquer dans neuf dossiers CRA sur dix.

Les 13 exigences du point (2) ne s’appliquent pas mécaniquement à tous les produits. Elles s’appliquent « sur la base de l’évaluation des risques de cybersécurité » et « le cas échéant ». Mais cette souplesse a un prix : l’article 13(3) exige que l’analyse de risque soit documentée, mise à jour pendant la période de support, et qu’elle indique explicitement :

• si les exigences de la partie I, point (2), s’appliquent au produit et, si oui, de quelle manière ;
• comment ces exigences sont mises en œuvre, à la lumière de l’analyse de risque ;
• comment le fabricant applique le point (1) de la partie I et les exigences de la partie II.

Et l’annexe VII, point 3, impose de verser cette analyse — y compris la démonstration de l’applicabilité des exigences de la partie I — dans la documentation technique conservée dix ans.

La conséquence opérationnelle est simple à énoncer, exigeante à tenir : écarter une exigence n’est pas un choix silencieux, c’est une décision motivée. Un produit sans interface réseau peut légitimement écarter le point (i) ; un produit qui ne stocke aucune donnée peut discuter le point (m). Mais dans les deux cas, il faut le dire, l’écrire, et relier la justification à l’analyse de risque. Un dossier qui se contente d’un tableau à 13 cases « conforme » sans traçabilité vers l’analyse de risque est un dossier fragile — c’est d’ailleurs le premier point sur lequel une autorité de surveillance du marché exerce sa demande motivée.

Je recommande une matrice à quatre colonnes, tenue comme un document vivant : référence de l’exigence — applicable oui/non — justification renvoyant à un scénario de risque identifié — preuve de mise en œuvre (spécification, test, rapport). C’est exactement le type de traçabilité réglementaire que des outils comme Legiscope structurent pour le RGPD, et que la même discipline permet de tenir pour le CRA.

Ce que les normes harmonisées ne vous apportent pas encore

Un mot d’avertissement sur le calendrier, parce qu’il commande la charge de travail.

L’article 27 du CRA prévoit une présomption de conformité pour les produits conformes à des normes harmonisées dont les références ont été publiées au Journal officiel de l’Union européenne. C’est le mécanisme classique du nouveau cadre législatif : appliquer la norme dispense de démontrer la conformité à l’exigence essentielle correspondante.

Or, à ce jour, aucune norme harmonisée CRA n’a été citée au JOUE. Le mandat de normalisation M/606, accepté en avril 2025 par le CEN, le CENELEC et l’ETSI, porte sur une quarantaine de normes, dont environ quinze horizontales. Les deux normes horizontales structurantes (développement sécurisé et gestion des vulnérabilités) sont attendues pour l’été 2026, les normes verticales à l’automne 2026, le solde en 2027. Tant qu’une référence n’est pas citée au JOUE, la présomption de l’art. 27 n’est disponible pour aucune catégorie de produit.

Concrètement : jusqu’à la publication des références, la démonstration de conformité à l’annexe I repose intégralement sur votre analyse de risque et vos preuves techniques. Attendre les normes pour commencer le travail de l’article 13(3) est le plus mauvais calcul possible — d’autant que la communication du 27 juillet 2026, non contraignante, ne se substitue pas non plus à une norme harmonisée.

Calendrier et plan d’action

Échéance	Ce qui s’applique
11 juin 2026	Dispositions relatives aux organismes notifiés (chapitre IV) — désignation en cours
11 septembre 2026	Signalement des vulnérabilités activement exploitées et incidents graves (art. 14) : alerte précoce à 24 h, notification à 72 h, rapport final à 14 jours après correctif
11 décembre 2027	Application intégrale : exigences essentielles de l’annexe I, marquage CE, documentation technique

Le détail phase par phase figure dans le calendrier d’application du CRA. Dans l’ordre, pour les 17 mois qui restent :

1. Classer le produit (par défaut, important classe I ou II, critique) : c’est ce classement qui détermine la procédure d’évaluation — voir les 3 classes de produits du CRA.
2. Conduire et écrire l’analyse de risque de l’art. 13(2)-(3), avec la matrice d’applicabilité des 13 exigences. C’est le document fondateur, pas un livrable de fin de projet.
3. Traiter en parallèle la partie II : SBOM, politique de divulgation coordonnée, point de contact, canal de mise à jour — l’échéance de septembre 2026 arrive avant celle de décembre 2027.
4. Constituer la documentation technique de l’annexe VII au fil de l’eau, et non en rétro-ingénierie six mois avant la date butoir.
5. Préparer la déclaration UE de conformité et le marquage CE, en identifiant tôt si un organisme notifié est requis.

Le rappel de proportionnalité, enfin : le manquement aux exigences essentielles de l’annexe I et aux obligations des articles 13 et 14 relève du palier le plus élevé de l’art. 64(2) — 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial, le montant le plus élevé étant retenu. Les autres manquements relèvent du palier à 10 millions d’euros ou 2 %. Le détail du régime figure dans l’analyse des sanctions du Cyber Resilience Act.

Ce qu’il faut retenir

• L’annexe I comporte deux parties : propriétés du produit (partie I) et processus de gestion des vulnérabilités du fabricant (partie II). Deux chantiers, deux équipes, deux calendriers.
• La partie I se lit en deux temps : une exigence chapeau inconditionnelle au point (1) — sécurité appropriée au risque, sur toute la chaîne conception-développement-fabrication — puis 13 exigences au point (2), de (a) à (m).
• Ces 13 exigences ne s’appliquent que « le cas échéant », mais l’art. 13(3) oblige à documenter par écrit lesquelles s’appliquent, comment elles sont mises en œuvre, et à verser cette analyse dans la documentation technique de l’annexe VII, conservée dix ans.
• Trois exigences recoupent directement le RGPD : (e) et (f) sur la confidentialité et l’intégrité (art. 32(1) RGPD), (g) sur la minimisation (art. 5(1)© RGPD), (m) sur l’effacement (art. 17 RGPD).
• Aucune norme harmonisée CRA n’est encore citée au JOUE : la présomption de conformité de l’art. 27 est indisponible, et la charge de la démonstration repose entièrement sur votre analyse de risque.
• Sanction du palier haut pour l’annexe I : 15 M€ ou 2,5 % du CA mondial (art. 64(2)). Application intégrale au 11 décembre 2027, signalement dès le 11 septembre 2026.

FAQ

Les 13 exigences de l’annexe I s’appliquent-elles à tous les produits ?

Non. Le point (2) de la partie I les subordonne à l’analyse de risque et à la formule « le cas échéant ». Mais l’article 13(3) impose d’indiquer dans l’analyse de risque documentée si chaque exigence s’applique, de quelle manière, et comment elle est mise en œuvre : une exigence écartée doit donc l’être de façon motivée et traçable, jamais implicitement.

Quelle différence entre la partie I et la partie II de l’annexe I ?

La partie I décrit les propriétés de sécurité que le produit lui-même doit présenter, appréciées à la mise sur le marché et à chaque modification substantielle (art. 3(30)). La partie II décrit les huit processus de gestion des vulnérabilités que le fabricant doit faire fonctionner pendant toute la période de support : SBOM, correction sans délai, tests réguliers, publication des correctifs, divulgation coordonnée, point de contact, distribution sécurisée et gratuite des mises à jour.

La communication de la Commission du 27 juillet 2026 modifie-t-elle les exigences de l’annexe I ?

Non. La communication C(2026) 5252, adoptée sur le fondement de l’art. 26, est expressément non contraignante : elle ne change ni les obligations, ni les échéances. Elle éclaire l’interprétation du périmètre, de la modification substantielle, de la période de support et du signalement, et les autorités de surveillance du marché s’y référeront. Seule une norme harmonisée citée au JOUE ouvre la présomption de conformité de l’art. 27.

Que risque un fabricant qui ne respecte pas les exigences essentielles ?

Le non-respect des exigences essentielles de l’annexe I et des obligations des articles 13 et 14 est passible d’une amende administrative pouvant atteindre 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial de l’exercice précédent, le montant le plus élevé étant retenu (art. 64(2)). Les autorités de surveillance du marché peuvent en outre exiger le retrait ou le rappel du produit.

---

Recevez nos analyses conformité chaque semaine. CRA, NIS2, RGPD, AI Act : les échéances qui comptent et ce qu’il faut faire, décryptés par un docteur en droit des technologies. Inscrivez-vous à la newsletter.

Thiébaut Devergranne est docteur en droit des nouvelles technologies (Paris II) et exerce depuis plus de vingt ans dans ce domaine, dont six années au sein des services du Premier ministre (SGDN/DCSSI). Il est le fondateur de donneespersonnelles.fr et de Legiscope.