Dossier de sécurité produit CRA 2026 avec ISO 27001

Un fabricant d’objets connectés convoque sa RSSI, Maria, à une réunion un vendredi après-midi. L’équipe commerciale vient d’obtenir un accord de distribution européen. Le service juridique demande si l’entreprise peut démontrer sa conformité au Cyber Resilience Act. L’ingénierie indique que le développement sécurisé est « globalement couvert », car la revue de code, les SAST et l’application des correctifs existent. Les achats répondent que les fournisseurs sont couverts par des accords de confidentialité. Les équipes produit gèrent les dépendances de micrologiciel dans un outil, les inventaires d’API cloud dans un autre et les tickets de vulnérabilités dans Jira. La conformité dispose d’éléments de preuve de certification ISO/IEC 27001:2022, mais ils sont organisés autour du SMSI de l’entreprise, et non autour de chaque produit mis sur le marché de l’UE.

Puis la question inconfortable arrive : « Si une autorité de l’UE, un client, un organisme notifié ou un grand distributeur demande le dossier de sécurité produit en 2026, pouvons-nous le produire en une semaine ? »

Pour de nombreux éditeurs logiciels, fabricants d’appareils intelligents et fournisseurs de services connectés, la réponse honnête est non. Non pas parce qu’ils ne disposent pas de contrôles de sécurité, mais parce que leurs éléments de preuve de sécurité produit sont dispersés. Les enregistrements de développement sécurisé restent côté ingénierie. Les SBOM sont générés à chaque build, mais ne sont pas gouvernés. La divulgation coordonnée des vulnérabilités existe sous forme de page web, mais elle n’est pas toujours reliée au triage, aux corrections, aux avis de sécurité et à la surveillance après mise sur le marché. La sécurité fournisseur est enfouie dans les contrats d’achat. Le signalement des incidents relève des opérations de sécurité, tandis que la documentation de conformité relève de la conformité produit.

Le Cyber Resilience Act de l’UE modifie le modèle opérationnel. La cybersécurité des produits n’est plus seulement une bonne pratique ou un engagement contractuel. Elle devient une obligation d’éléments de preuve tout au long du cycle de vie. Les organisations doivent être en mesure de montrer comment les exigences de cybersécurité sont intégrées à la conception, au développement, à la mise en production, à la gestion des vulnérabilités, aux mises à jour et à la surveillance après la mise sur le marché du produit.

C’est ici qu’ISO/IEC 27001:2022 devient puissante, si elle est utilisée correctement. Elle n’est pas, à elle seule, un dispositif de certification produit, mais ses contrôles relatifs au SMSI, aux risques, aux actifs, aux fournisseurs, au développement sécurisé, aux vulnérabilités et aux incidents peuvent fournir l’ossature d’un dossier de sécurité produit CRA. L’objectif n’est pas de créer un autre silo de conformité. L’objectif est de transformer votre SMSI existant en système d’éléments de preuve au niveau produit.

Comme l’indique le Zenith Blueprint : feuille de route en 30 étapes pour auditeurs de Clarysec à la phase 2, étape 8, Architecture des éléments de preuve :

« Les éléments de preuve ne doivent pas être collectés à la fin du cycle d’audit. Ils doivent être conçus dans le contrôle, attribués à un propriétaire, horodatés par le processus et réutilisables pour chaque obligation qui pose la même question avec des termes différents. »

Cette phrase résume le cœur de la préparation au CRA. La question n’est pas seulement : « Avons-nous un développement sécurisé ? » La question est : « Pouvons-nous prouver le développement sécurisé, la connaissance des composants, la gestion des vulnérabilités et la surveillance après mise sur le marché pour ce produit, cette version, cette mise en production et ce marché ? »

Le dossier de sécurité produit CRA est un système vivant d’éléments de preuve

Un dossier de sécurité produit CRA ne doit pas être traité comme un PDF statique produit une seule fois avant la mise en production puis oublié. Il doit s’agir d’un dossier structuré qui retrace l’histoire de sécurité du produit, de la conception jusqu’à la fin du support.

Un dossier utile explique :

1. Ce qu’est le produit et l’usage auquel il est destiné.
2. Quels logiciels, micrologiciels, services cloud et dépendances tierces il inclut.
3. Quels risques de cybersécurité ont été appréciés.
4. Quelles exigences de sécurité ont été appliquées.
5. Comment le développement sécurisé a été réalisé.
6. Comment les vulnérabilités sont reçues, triées, corrigées et divulguées.
7. Comment les mises à jour sécurisées sont fournies.
8. Comment les fournisseurs et les composants open source sont contrôlés.
9. Comment les incidents et les vulnérabilités activement exploitées sont escaladés.
10. Comment le produit est surveillé après sa mise sur le marché.

Pour un RSSI, il s’agit d’un enjeu d’éléments de preuve du SMSI. Pour un responsable de la conformité produit, il s’agit de documentation technique. Pour l’ingénierie, il s’agit de DevSecOps et de gouvernance des mises en production. Pour les dirigeants, il s’agit d’accès au marché et de maîtrise de la responsabilité.

L’erreur consiste à traiter ces sujets comme des chantiers distincts. Le modèle le plus efficace consiste à constituer un dossier d’éléments de preuve au niveau produit, cartographié avec les contrôles ISO/IEC 27001:2022 et ISO/IEC 27002:2022, puis à établir des correspondances entre ces mêmes éléments de preuve et NIS2, DORA, GDPR, NIST et COBIT 2019 lorsque c’est pertinent.

Le Zenith Controls : guide de conformité croisée de Clarysec décrit cela comme une chaîne contrôle–élément de preuve–auditeur :

« Un dossier d’éléments de preuve de conformité croisée doit relier chaque obligation au contrôle opérationnel, à l’objet récurrent d’élément de preuve, au propriétaire responsable et à l’angle d’audit qui sera utilisé pour l’éprouver. »

C’est la discipline requise pour se préparer au CRA. Le dossier de sécurité produit n’est pas un simple répertoire. C’est la couche de traduction entre l’ingénierie produit, la gouvernance de la sécurité, l’évaluation de conformité et l’assurance demandée par les clients.

Construire d’abord l’ossature des éléments de preuve produit

Le dossier nécessite une structure cohérente avant que les équipes commencent à y déposer des enregistrements. Sans ossature claire, les éléments de preuve deviennent un empilement de captures d’écran, d’exports et de PDF de politiques qu’aucun auditeur ne peut suivre.

Pour les ateliers de préparation au CRA, Clarysec recommande généralement la structure suivante de dossier de sécurité produit pour les organisations qui exploitent déjà un SMSI ISO/IEC 27001:2022.

Ce tableau ne remplace pas les obligations légales de documentation technique. Il donne à l’entreprise un modèle opérationnel pour les démontrer.

Dans le Zenith Blueprint, la phase 1, étape 3 porte sur la définition du champ d’application et des limites. Pour le CRA, cette étape devient spécifique au produit. Définissez la famille de produits, les versions logicielles, les hypothèses de déploiement, les rôles utilisateurs, les services connectés, les canaux de mise à jour et la période de support. Si le champ d’application du SMSI est « plateforme SaaS d’entreprise et de gestion des appareils », le dossier CRA doit néanmoins répondre à une question plus précise : « Quel produit comportant des éléments numériques est mis sur le marché de l’UE, et qu’inclut ce produit ? »

Cartographier le développement sécurisé avec des enregistrements au niveau produit

Le cœur du dossier de sécurité produit est constitué par les éléments de preuve de la sécurité dès la conception. ISO/IEC 27001:2022 fournit le système de gouvernance. ISO/IEC 27002:2022 fournit les lignes directrices de mise en œuvre au moyen de contrôles tels que A.8.25 Cycle de vie du développement sécurisé, A.8.27 Architecture système sécurisée et principes d’ingénierie, A.8.28 Programmation sécurisée et A.8.29 Tests de sécurité pendant le développement et l’acceptation.

Le changement essentiel consiste à passer d’allégations génériques de développement sécurisé à des enregistrements propres à chaque mise en production. « Nous effectuons des revues de code » ne suffit pas. Le dossier doit montrer quelle version a été revue, quels risques ont été pris en compte, quels tests de sécurité ont réussi, quelles vulnérabilités ont été acceptées ou corrigées, et qui a approuvé la mise en production.

La Politique de développement sécurisé Enterprise de Clarysec est conçue pour imposer cette traçabilité des éléments de preuve. Dans la clause 6.1, Exigences du cycle de vie du développement sécurisé, elle indique :

« Chaque mise en production de produit ou de service doit conserver des éléments de preuve documentés des exigences de sécurité, de la revue de conception, des activités de programmation sécurisée, des tests de sécurité, des décisions de remédiation des vulnérabilités et de l’approbation de mise en production avant le déploiement en production. »

Cette clause est utile pour le CRA, car elle transforme le développement sécurisé en schéma d’éléments de preuve répétable. Un auditeur n’a pas besoin de déduire que le développement sécurisé a eu lieu. Il peut examiner l’enregistrement de mise en production.

Pour un thermostat intelligent, un dispositif médical IoT, un capteur industriel ou un produit connecté à une offre SaaS, les éléments de preuve de développement sécurisé doivent inclure :

• Exigences de sécurité produit cartographiées avec les risques identifiés.
• Modèle de menace ou analyse des cas d’abus pour le produit et les services connectés.
• Revue d’architecture, incluant les frontières de confiance et les interfaces externes.
• Norme de programmation sécurisée et preuve de prise de connaissance ou de formation des développeurs.
• SAST, DAST, analyse de la composition logicielle, analyse des secrets et analyse des micrologiciels, le cas échéant.
• Tickets de remédiation pour les constats à haut risque.
• Enregistrements d’acceptation du risque avec approbation métier et sécurité.
• Liste de contrôle du jalon de mise en production montrant que les critères de sécurité ont été respectés.
• Éléments de preuve de signature cryptographique et d’intégrité des mises à jour.
• Hypothèses relatives à la période de support et à la fin de vie.

D’autres normes renforcent la méthode. ISO/IEC 27005 soutient l’approche par les risques qui sous-tend ces enregistrements. ISO/IEC 27017 est utile lorsque des services cloud font partie de l’écosystème produit. ISO/IEC 27035 soutient la gestion des incidents. ISO/IEC 29147 et ISO/IEC 30111 sont particulièrement pertinentes pour la divulgation et la gestion des vulnérabilités. ISO/IEC 27036 soutient la sécurité fournisseur, qui devient importante lorsque le produit inclut des logiciels externalisés, des modules embarqués, des services cloud managés ou des bibliothèques tierces.

Dans Zenith Controls, les éléments de preuve de développement sécurisé CRA sont généralement cartographiés autour de thèmes de contrôle ISO/IEC 27002:2022 tels que la sécurité de l’information dans la gestion de projet, le cycle de vie du développement sécurisé, la programmation sécurisée, les tests de sécurité, la gestion des changements et la gestion des vulnérabilités techniques. Le guide les relie également à l’inventaire des actifs et aux contrôles fournisseurs, car aucun processus de développement sécurisé n’est complet si l’organisation ne peut pas identifier les composants qu’elle livre.

Traiter le SBOM comme un élément de preuve produit réglementé

Le Software Bill of Materials est souvent traité comme un artefact technique. Pour la préparation au CRA, il doit être traité comme un élément de preuve produit.

Un SBOM utile indique quels composants sont présents dans le produit, quelles versions sont utilisées, d’où ils proviennent, quelles licences s’appliquent, quelles vulnérabilités les affectent et quelles mises en production les contiennent. Pour les micrologiciels et les produits embarqués, cela peut inclure les paquets de système d’exploitation, les bootloaders, les bibliothèques, les pilotes, les conteneurs, les modules tiers et les dépendances côté cloud nécessaires au fonctionnement du produit.

Le problème est que de nombreuses organisations génèrent des SBOM sans les gouverner. Un pipeline de build peut produire un fichier SPDX ou CycloneDX, mais personne n’en valide l’exhaustivité. Les outils de sécurité peuvent signaler des vulnérabilités, mais les résultats ne sont pas reliés aux versions du produit. Les achats peuvent approuver un fournisseur, mais la liste des composants de ce fournisseur n’est pas rapprochée du produit mis en production.

La Politique de gestion des actifs Enterprise de Clarysec traite cette lacune de gouvernance dans la clause 5.2, Inventaire des informations et des actifs associés :

« Les actifs informationnels et les composants technologiques associés doivent être identifiés, attribués à un propriétaire, classifiés le cas échéant et maintenus dans un inventaire permettant l’appréciation des risques, la gestion des vulnérabilités, le contrôle des changements et les éléments de preuve d’audit. »

Pour le CRA, cette clause devient spécifique au produit. Le SBOM fait partie de l’inventaire des composants technologiques associés. Il lui faut un propriétaire, une règle de conservation, un processus de validation et un lien avec la gestion des vulnérabilités.

Une règle pratique d’éléments de preuve SBOM est simple : chaque version de produit mise en production doit disposer d’un inventaire approuvé des composants, pouvant être rapproché de l’artefact de mise en production. Si l’organisation ne peut pas relier le SBOM à l’image exacte du micrologiciel, au paquet applicatif, au condensat de conteneur ou à la version SaaS, le SBOM constitue un élément de preuve faible.

Si plus de deux lignes échouent, le problème n’est généralement pas l’outil SBOM. C’est la gouvernance. Le dossier de sécurité produit doit consigner une action corrective dans le SMSI, car une faiblesse des éléments de preuve CRA constitue également un problème d’efficacité des contrôles ISO/IEC 27001:2022.

Relier la CVD à la gestion des vulnérabilités et à la gouvernance des mises en production

La divulgation coordonnée des vulnérabilités est l’un des domaines les plus visibles de la préparation au CRA, car les chercheurs externes, les clients et les autorités peuvent la tester directement. Publier une page de divulgation des vulnérabilités ou un fichier security.txt est utile, mais ce n’est que la porte d’entrée. Le dossier de sécurité produit doit prouver que les processus internes fonctionnent.

Un ensemble défendable d’éléments de preuve CVD et de gestion des vulnérabilités doit inclure :

• Canal public de divulgation et consignes de soumission.
• Processus d’accusé de réception auprès des chercheurs.
• Critères de triage, incluant l’évaluation de la gravité et de l’exploitabilité.
• Analyse d’impact produit.
• Propriété de la remédiation et délais cibles.
• Modèles d’avis client et de communication de mise à jour.
• Éléments de preuve du développement et des tests de correctifs sécurisés.
• Enregistrements de publication coordonnée, le cas échéant.
• Retours d’expérience et analyse des tendances récurrentes de vulnérabilités.

La Politique de gestion des vulnérabilités Enterprise de Clarysec, clause 6.3, Réception, triage et remédiation des vulnérabilités, indique :

« Les vulnérabilités signalées doivent être journalisées, évaluées au regard des actifs et produits affectés, priorisées selon le risque et l’exploitabilité, attribuées à un propriétaire responsable et suivies jusqu’à la remédiation, la vérification, la communication et la clôture. »

Cette clause relie la CVD au SBOM, à l’inventaire des actifs, aux tickets d’ingénierie, à la gestion des mises en production et à la surveillance après mise sur le marché. C’est également la clause que les auditeurs testeront naturellement : montrer l’enregistrement de réception, montrer les produits affectés, montrer le triage, montrer la correction, montrer la communication client, montrer la clôture.

Votre Politique de gestion des incidents de sécurité de l’information existante doit également être étendue afin de couvrir les vulnérabilités produit qui deviennent des incidents ou nécessitent une notification externe. ISO/IEC 27002:2022 A.5.24 couvre la planification et la préparation de la gestion des incidents, A.5.25 couvre l’appréciation et la décision relatives aux événements de sécurité de l’information, A.5.26 couvre la réponse aux incidents de sécurité de l’information et A.5.27 couvre les enseignements tirés des incidents.

Dans Zenith Controls, la gestion des vulnérabilités est traitée à la fois comme préventive et corrective. Le volet préventif inclut l’inventaire, le développement sécurisé, la surveillance des fournisseurs et la configuration sécurisée. Le volet correctif inclut la détection, le triage, l’application des correctifs, la communication et l’escalade des incidents. Cette distinction est importante, car la gestion des vulnérabilités après mise sur le marché fait partie de l’obligation de cycle de vie du produit, et non d’un sujet accessoire.

Les éléments de preuve fournisseurs sont la faiblesse cachée

Le dossier de sécurité produit sera souvent le plus fortement éprouvé lorsque le fabricant dépend d’autres acteurs. Cela inclut les modules embarqués, le développement externalisé de micrologiciels, les composants en marque blanche, l’hébergement cloud, les SDK mobiles, les services de paiement, les bibliothèques cryptographiques et les prestataires de support managés.

Le schéma d’échec courant est l’abstraction contractuelle. Le fabricant déclare : « Notre fournisseur en est responsable. » Sous l’angle de la sécurité produit, cela ne suffit pas. L’organisation doit montrer que le risque fournisseur est identifié, que les exigences de sécurité sont communiquées, que les éléments de preuve sont collectés, que les vulnérabilités sont coordonnées et que les changements sont contrôlés.

La Politique de sécurité des tiers et des fournisseurs Enterprise de Clarysec, clause 7.1, Exigences de sécurité fournisseur, indique :

« Les fournisseurs qui développent, exploitent, traitent, supportent ou affectent de manière significative des systèmes d’information, produits ou services doivent être évalués selon le risque et être soumis à des exigences de sécurité couvrant les accès, la gestion des vulnérabilités, la notification des incidents, la sous-traitance, la continuité et la fourniture d’éléments de preuve. »

Pour le CRA, l’expression « affectent de manière significative les produits » est critique. Si un composant fournisseur peut introduire une vulnérabilité, perturber les mises à jour, exposer des données client ou compromettre l’intégrité d’un appareil, il relève du dossier de sécurité produit.

La même politique peut également soutenir la contractualisation du SBOM. La clause 7.3 indique :

« Pour tous les composants logiciels, bibliothèques ou systèmes d’exploitation tiers destinés à être intégrés aux “produits comportant des éléments numériques” de l’entreprise, le fournisseur doit fournir, sur demande, un Software Bill of Materials (SBOM) lisible par machine dans un format standard tel que SPDX ou CycloneDX. Cette exigence doit être intégrée à tous les contrats d’achat et fournisseurs. »

Un dossier d’éléments de preuve fournisseur robuste doit inclure la classification des fournisseurs selon l’impact produit, les exigences de sécurité dans les contrats, les éléments de preuve de développement sécurisé des fournisseurs pour les composants critiques, les engagements des fournisseurs en matière de divulgation des vulnérabilités, les SBOM ou déclarations de composants lorsque cela est possible, les délais de support des correctifs et de fin de vie, les enregistrements de revue périodique et les circuits d’escalade pour les vulnérabilités provenant de fournisseurs.

ISO/IEC 27002:2022 A.5.19, A.5.20 et A.5.21 fournissent les principaux thèmes de contrôle fournisseur. ISO/IEC 27036 approfondit la sécurité des relations fournisseurs. En termes de conformité croisée, NIS2 met l’accent sur la chaîne d’approvisionnement et la gestion des vulnérabilités. DORA met l’accent sur le risque TIC lié aux tiers pour les entités financières. GDPR devient pertinent lorsque le produit ou ses services cloud traitent des données à caractère personnel. COBIT 2019 considère la gouvernance des fournisseurs comme un enjeu de gouvernance des technologies d’entreprise, et non seulement comme un sujet d’opérations de sécurité.

La surveillance après mise sur le marché transforme les éléments de preuve en opérations

Les organisations les plus matures en matière de sécurité produit pensent au-delà de la mise en production. Elles se demandent : « Comment saurons-nous que ce produit est devenu risqué une fois déployé sur le terrain ? »

La surveillance après mise sur le marché doit capter les signaux issus des flux de vulnérabilités, du renseignement sur les exploits, du support client, de la télémétrie, des programmes de bug bounty ou des signalements de chercheurs, des notifications fournisseurs, des journaux cloud, des enregistrements d’incidents et des données de performance terrain. Elle doit également inclure une revue périodique du risque produit lorsque les conditions de menace évoluent.

La Politique de journalisation et de surveillance Enterprise de Clarysec, clause 5.4, Surveillance et revue de sécurité, indique :

« Les événements pertinents pour la sécurité doivent être collectés, revus, escaladés et conservés de manière à soutenir la détection en temps utile, l’investigation, la réponse aux incidents, les rapports de conformité et l’amélioration continue. »

Pour les produits connectés, cela doit être interprété avec précaution. La surveillance doit respecter la vie privée, la minimisation des données et les contraintes légales, en particulier lorsque la télémétrie inclut des données à caractère personnel ou des données opérationnelles client. La cartographie avec GDPR est importante. Les équipes de sécurité produit doivent travailler avec les équipes Protection des données pour définir quelle télémétrie est nécessaire à la sécurité, comment elle est minimisée, combien de temps elle est conservée et comment les clients sont informés.

Les éléments de preuve de surveillance après mise sur le marché doivent inclure un plan de surveillance de la sécurité produit, les sources de renseignement sur les vulnérabilités, les canaux de réception des signalements clients, les canaux de notification fournisseur, le périmètre de revue de la télémétrie ou des journaux, les comptes rendus de revue périodique des risques produit, le suivi de l’adoption des correctifs, l’analyse des tendances d’incidents et les contributions à la revue de direction.

Dans le Zenith Blueprint, la phase 5, étape 30 porte sur l’amélioration continue et la préparation à la surveillance. Pour le CRA, c’est à ce stade que le dossier de sécurité produit devient un dossier vivant. Chaque mise en production, vulnérabilité, changement fournisseur et signal terrain doit mettre à jour l’enregistrement des éléments de preuve.

Un seul dossier d’éléments de preuve, plusieurs questions de conformité

Un dossier de sécurité produit CRA bien conçu réduit les doublons, car les mêmes éléments de preuve répondent à plusieurs questions de conformité. Le vocabulaire change, mais la réalité des contrôles est souvent similaire.

Zenith Controls est conçu pour cette réutilisation. Il cartographie les thèmes de contrôle ISO/IEC 27002:2022 avec des attributs tels que la finalité préventive, détective et corrective des contrôles, les concepts de cybersécurité, les capacités opérationnelles et les propriétés de sécurité. Pour le CRA, cela aide un RSSI à expliquer pourquoi un même objet d’élément de preuve, par exemple une revue de sécurité de mise en production, soutient le développement sécurisé, le traitement des risques, le contrôle des changements, la gestion des vulnérabilités et la préparation à l’audit.

Se préparer aux différents angles d’audit

Un dossier de sécurité produit CRA peut être éprouvé par un auditeur ISO, une équipe d’audit interne, une équipe d’assurance client, un examinateur de conformité produit, une autorité de régulation, un évaluateur utilisant NIST ou un auditeur COBIT formé par ISACA. Chacun posera des questions similaires sous un angle différent.

Le même point faible sera exposé différemment. Si les SBOM sont générés mais non conservés, l’auditeur ISO voit un problème de maîtrise des enregistrements et de contrôle opérationnel. L’évaluateur NIST voit une faiblesse de gestion des actifs et des vulnérabilités. L’auditeur COBIT voit une gouvernance faible des actifs informationnels. L’examinateur produit voit une documentation technique insuffisante.

Une feuille de route en 30 étapes, adaptée à la préparation au CRA

Le Zenith Blueprint évite aux équipes conformité de se lancer directement dans la collecte documentaire. Pour le CRA, la feuille de route en 30 étapes devient un programme d’éléments de preuve de sécurité produit.

La phase 1 commence par la cartographie des obligations et du champ d’application. Identifiez les produits, versions, composants, services cloud et processus de support inclus dans le périmètre. Confirmez l’usage prévu, les catégories d’utilisateurs, les marchés et la période de support de sécurité.

La phase 2 construit l’architecture des éléments de preuve. Définissez l’index du dossier de sécurité produit, les propriétaires des éléments de preuve, les exigences de conservation, la structure du référentiel et le processus d’approbation. Alignez-vous sur les systèmes d’ingénierie plutôt que d’imposer des dépôts manuels.

La phase 3 met en œuvre les contrôles opérationnels. Le développement sécurisé, la génération de SBOM, la gestion des vulnérabilités, les éléments de preuve fournisseurs, les jalons de mise en production, les mises à jour sécurisées et l’escalade des incidents doivent fonctionner comme de véritables processus.

La phase 4 teste la préparation à l’audit. Sélectionnez une mise en production produit et réalisez un audit à blanc. L’équipe peut-elle récupérer le SBOM ? Peut-elle prouver les tests de sécurité ? Peut-elle montrer comment une vulnérabilité a été triée ? Peut-elle relier les éléments de preuve fournisseurs aux composants du produit ?

La phase 5 intègre la surveillance et l’amélioration. La surveillance après mise sur le marché, l’analyse des tendances de vulnérabilités, les revues fournisseurs et les contributions à la revue de direction maintiennent le dossier à jour.

Ce sprint révèle généralement la réalité très rapidement. Les organisations échouent rarement parce qu’elles ne disposent d’aucun contrôle. Elles échouent parce que les contrôles ne sont pas connectés au niveau produit.

Lacunes fréquentes de préparation au CRA avant 2026

Chez les éditeurs logiciels, fabricants d’appareils et fournisseurs de services connectés, les lacunes récurrentes sont constantes.

Premièrement, le champ d’application du SMSI est trop centré sur l’entreprise. Il couvre l’organisation, mais pas suffisamment le détail du cycle de vie des produits. La correction consiste à créer des annexes et des dossiers d’éléments de preuve au niveau produit.

Deuxièmement, les SBOM existent mais ne sont pas fiables. Ils sont générés par des outils, mais ne sont pas revus, approuvés, conservés ni reliés aux décisions relatives aux vulnérabilités. La correction consiste à mettre en place une gouvernance SBOM, et pas seulement une production de SBOM.

Troisièmement, la CVD est visible publiquement, mais pas mature opérationnellement. Les signalements arrivent, mais les critères de triage, les objectifs de réponse, les approbations d’avis de sécurité et les éléments de preuve de clôture sont incohérents. La correction consiste à intégrer la CVD à la gestion des vulnérabilités, à la gestion des incidents et à la gestion des mises en production.

Quatrièmement, les éléments de preuve fournisseurs sont trop superficiels. Les fournisseurs critiques sont approuvés commercialement, mais ne sont pas évalués selon leur impact sur la sécurité produit. La correction consiste à classifier les fournisseurs selon le risque produit et à imposer des éléments de preuve pour les composants critiques.

Cinquièmement, la surveillance après mise sur le marché est réactive. Les équipes répondent aux vulnérabilités urgentes, mais ne réalisent pas de revues périodiques des risques produit. La correction consiste à planifier une revue de sécurité après mise sur le marché liée aux rapports de direction.

Sixièmement, les éléments de preuve d’audit sont trop manuels. Les équipes conformité recherchent des captures d’écran. La correction consiste à concevoir les éléments de preuve dès l’origine, en utilisant les systèmes d’ingénierie, les flux de tickets et les référentiels comme sources faisant autorité.

Constituer le dossier d’éléments de preuve avant que l’échéance ne vous l’impose

Le Cyber Resilience Act favorise les organisations capables de prouver la sécurité produit comme une discipline opérationnelle. Il crée un risque pour celles qui traitent les éléments de preuve comme un exercice de conformité de dernière minute.

Commencez par un produit. Constituez un dossier de sécurité produit. Cartographiez-le avec ISO/IEC 27001:2022 et ISO/IEC 27002:2022. Joignez les éléments de preuve de développement sécurisé, le SBOM, les enregistrements CVD, l’assurance fournisseur et la surveillance après mise sur le marché. Réalisez une simulation d’audit avant qu’un tiers ne le fasse pour vous.

Clarysec peut vous aider à accélérer ce parcours avec le Zenith Blueprint, Zenith Controls, la Politique de développement sécurisé Enterprise, la Politique de gestion des vulnérabilités, la Politique de gestion des actifs, la Politique de sécurité des tiers et des fournisseurs, la Politique de journalisation et de surveillance et la Politique de gestion des incidents de sécurité de l’information.

Votre question la plus importante pour le CRA 2026 n’est pas : « Avons-nous des contrôles de sécurité ? »

C’est : « Pouvons-nous prouver la sécurité produit, mise en production par mise en production, composant par composant, vulnérabilité par vulnérabilité, après que le produit est déjà sur le marché ? »

Constituez dès maintenant le dossier d’éléments de preuve, reliez-le à votre SMSI et rendez chaque future mise en production produit prête pour l’audit dès la conception.