Tout fabricant d'un produit comportant des éléments numériques entrant dans le champ du CRA doit conduire une évaluation des risques de cybersécurité et la conserver par écrit. C'est ce document qui détermine quelles exigences de sécurité du CRA s'appliquent à votre produit, et comment vous les respectez. Les autorités de surveillance du marché peuvent la demander. Sans elle, votre dossier technique est incomplet et votre déclaration de conformité n'a aucun fondement.
Ce guide explique comment conduire l'évaluation, comment la consigner et comment la tenir à jour. Il inclut une cartographie complète des exigences de sécurité, un exemple concret et un squelette de document à copier.
Résumé
- L'évaluation des risques de cybersécurité est obligatoire pour tout produit comportant des éléments numériques entrant dans le champ du CRA. Elle doit exister par écrit avant la mise sur le marché et rester à jour pendant toute la période d'assistance.
- C'est un intrant d'ingénierie, pas de la paperasse. Le CRA attend que l'évaluation oriente la planification, la conception, le développement, la production, la livraison et la maintenance.
- Sa fonction centrale est une décision d'applicabilité. Pour chacune des 13 exigences de sécurité du produit, vous indiquez si elle s'applique à votre produit, et comment vous la mettez en œuvre. Lorsqu'une exigence ne s'applique pas, vous consignez une justification claire.
- Le CRA n'impose aucune méthode. Une matrice probabilité x impact, une modélisation des menaces de type STRIDE ou un processus de type ISO/IEC 27005 conviennent tous, à condition que le résultat soit documenté et reproductible.
- L'évaluation entre dans votre dossier technique. Pour un groupe restreint de produits, ceux que le CRA traite comme des systèmes d'IA à haut risque, elle peut être intégrée à l'évaluation des risques exigée par ces autres textes de l'Union.
- Mettez-la à jour dès qu'une information nouvelle et pertinente apparaît. Nouvelles vulnérabilités, nouvelles fonctionnalités, changements de composants et incidents sont autant de déclencheurs.
- Un exemple concret et un squelette de document sont fournis ci-dessous. Adaptez-les à votre produit.
Important : l'évaluation doit exister avant l'achèvement de l'évaluation de la conformité et la signature de la déclaration de conformité. Une évaluation rétroactive ne peut pas démontrer que son résultat a orienté la planification, la conception et le développement, ce que le CRA demande précisément de montrer.
Qu'est-ce que l'évaluation des risques de cybersécurité du CRA ?
L'évaluation des risques de cybersécurité est une analyse documentée des risques auxquels votre produit est exposé, fondée sur sa finalité prévue et sur les usages raisonnablement prévisibles. Elle couvre les conditions d'utilisation, comme l'environnement opérationnel et les actifs que le produit doit protéger, et elle tient compte de la durée d'utilisation attendue du produit.
L'évaluation produit un résultat central dont tout le reste dépend. Elle indique, pour chaque exigence de sécurité du produit prévue par le CRA, si cette exigence s'applique à votre produit et, le cas échéant, comment votre conception et vos processus la mettent en œuvre. Elle consigne aussi comment vous respectez le socle de sécurité dès la conception et comment vos processus de gestion des vulnérabilités couvrent le produit.
Ce qui entre
- À quoi sert le produit
- Comment il sera vraisemblablement utilisé
- L'environnement dans lequel il fonctionne
- Les actifs à protéger
- Combien de temps il restera en service
L'évaluation
- Identifier les menaces crédibles
- Évaluer les risques
- Décider du traitement
Tenue à jour pendant toute la période d'assistance
Ce qui en sort
- S'applique ou non, pour chacune des 13 exigences de sécurité
- Comment chaque exigence applicable est mise en œuvre
- Une justification écrite pour chaque exclusion
Versée au dossier technique. Éclaire la période d'assistance.
Trois propriétés la distinguent d'un registre de risques d'entreprise générique :
- Elle est spécifique au produit. Ancrée dans l'architecture, les interfaces et les utilisateurs de ce produit précis. Un registre de risques SMSI à l'échelle de l'entreprise ne suffit pas. Notre comparaison avec l'ISO 27001 détaille cet écart.
- C'est un document de cycle de vie. Vous l'utilisez pendant la planification et la conception, pas seulement à la release. Et vous la mettez à jour pendant toute la période d'assistance.
- C'est une preuve. L'évaluation documentée entre dans votre dossier technique, où les autorités peuvent la demander.
Qui en a besoin, et quand
Tout fabricant qui met un produit comportant des éléments numériques sur le marché de l'Union en a besoin, sauf si le produit échappe entièrement au CRA. Dans le champ : le matériel avec firmware, les logiciels autonomes, et les produits dont le traitement de données à distance fait partie de l'offre. La règle s'applique à une société d'un seul développeur comme à un groupe multinational. Les produits exclus par le CRA, comme certains dispositifs médicaux couverts, certains véhicules et les équipements aéronautiques certifiés, suivent leurs propres règles sectorielles. Si vous n'êtes pas sûr que le CRA couvre votre produit, commencez par le guide du champ d'application.
Le calendrier compte plus que la plupart des équipes ne l'anticipent :
- Commencez pendant la planification. L'évaluation doit orienter les décisions de conception. Faites un premier passage pendant que l'architecture est encore facile à modifier.
- Achevez-la et documentez-la avant la mise sur le marché. L'évaluation écrite doit figurer dans le dossier technique au moment de l'expédition du produit.
- Tenez-la à jour pendant toute la période d'assistance. L'évaluation n'est jamais définitive. Elle suit le produit aussi longtemps que vous devez des mises à jour de sécurité.
Une simplification étroite existe. Elle ne couvre que les produits que le CRA traite comme des systèmes d'IA à haut risque et qui relèvent aussi d'autres textes de l'Union exigeant une évaluation des risques. Pour ceux-ci, l'évaluation de cybersécurité peut être intégrée à cette autre évaluation des risques plutôt que de rester un document séparé. Les obligations de contenu restent identiques. Consultez le guide sur le chevauchement avec l'AI Act pour voir comment cela fonctionne en pratique.
Ce que l'évaluation doit contenir
Le CRA fixe un socle minimal de contenu. Votre évaluation doit couvrir trois éléments :
- Le produit en contexte. À quoi sert le produit, ses usages raisonnablement prévisibles, l'environnement dans lequel il fonctionne, les actifs qu'il doit protéger, et sa durée d'utilisation attendue.
- Les décisions d'applicabilité. Pour chacune des 13 exigences de sécurité du produit : s'applique-t-elle à ce produit, et comment est-elle mise en œuvre. Lorsqu'une exigence ne s'applique pas, une justification écrite claire.
- La couverture des processus. Comment le socle de sécurité dès la conception est respecté et comment vos processus de gestion des vulnérabilités couvrent le produit.
Le devoir de justification mérite d'être souligné. « Non applicable » sans motif est un défaut. Nommez les caractéristiques du produit qui écartent l'exigence, et consignez-les par écrit. La justification écrite entre dans le dossier technique avec le reste de l'évaluation.
Au-delà de ce minimum légal, ajoutez les contrôles qui rendent le document défendable : décisions de traitement avec leur risque résiduel, critères d'acceptation, une approbation nominative datée, et un historique des révisions. Le CRA n'impose aucun d'entre eux. Ce sont eux qui montrent que l'évaluation est restée à jour, et qu'une personne responsable a accepté le risque restant.
Choisir une méthode
Le CRA n'impose aucune méthodologie d'évaluation, aucune échelle de notation, aucun modèle. Ce qu'il exige, c'est un résultat documenté qui étaye les décisions d'applicabilité. Choisissez une méthode que votre équipe peut reproduire, et décrivez-la dans l'évaluation afin qu'un relecteur puisse suivre votre raisonnement.
Une règle s'applique quel que soit votre choix. Exprimez chaque risque comme la combinaison de sa probabilité et de l'ampleur de la perte ou de la perturbation qu'il pourrait causer. Dans le CRA, le risque de cybersécurité repose exactement sur ces deux dimensions, de sorte qu'une liste de menaces qui ne note ni l'une ni l'autre n'est pas encore une évaluation.
Choix courants qui fonctionnent :
| Méthode | Ce qu'elle apporte | Convient le mieux à |
|---|---|---|
| Matrice probabilité x impact | Des notations de risque numériques simples et un registre classé | Petites équipes, premières évaluations |
| Modélisation des menaces de type STRIDE | Une identification systématique des menaces par composant et flux de données | Produits à forte composante logicielle avec des diagrammes d'architecture clairs |
| Processus de type ISO/IEC 27005 | Un cycle complet de gestion des risques : contexte, analyse, traitement | Organisations qui exploitent déjà un SMSI |
| Approche menace-risque IEC 62443 | Une analyse par zones et conduits pour les contextes industriels | Produits industriels et OT, voir le guide de l'automatisation industrielle |
Les futures normes harmonisées ne changeront pas ce libre choix de méthode. Le projet de norme-cadre européenne pour la gestion des risques CRA est lui-même neutre sur le plan méthodologique : il s'appuie sur le processus de gestion des risques ISO 31000 sans imposer de modèle de notation. Notre page de suivi des normes harmonisées en suit l'avancement. Et les normes ne remplacent jamais l'évaluation : même un produit qui applique intégralement les normes harmonisées a besoin de sa propre évaluation documentée, et vous devez vérifier que les normes couvrent les risques que vous avez effectivement identifiés.
Quel que soit votre choix, retenez deux règles :
- La méthode doit produire des réponses d'applicabilité. Un tas de risques notés ne suffit pas. Le résultat doit se rattacher aux 13 exigences de sécurité ci-dessous.
- Documentez la méthode. Définitions de l'échelle, formule, seuils d'acceptation. Une notation « 12 (Élevé) » ne veut rien dire si l'échelle n'est pas documentée. L'enregistrement devrait permettre à une autorité de surveillance du marché de vérifier comment chaque risque a été identifié, évalué et traité.
L'évaluation, étape par étape
Un processus en sept étapes qui fonctionne en pratique. Ajustez la profondeur à la complexité et au risque de votre produit.
Étape 1 : définir le périmètre et le contexte
Consignez le nom et la version du produit, sa finalité prévue, les environnements dans lesquels il fonctionnera, et ses utilisateurs. Précisez ce qui est dans le périmètre, y compris les applications compagnons, les backends cloud faisant partie de l'offre, et les composants inclus. Précisez ce qui est hors périmètre et pourquoi.
Étape 2 : identifier les actifs
Listez ce que le produit doit protéger. Les actifs typiques sont les données utilisateur, les identifiants et les clés, l'intégrité du firmware et de la configuration, la disponibilité de la fonction du produit, et le réseau environnant. Notez où réside chaque actif et comment il circule.
Étape 3 : identifier les menaces
Parcourez votre architecture surface par surface. Les interfaces externes d'abord, car c'est par là que les attaquants commencent. Pour chaque interface et chaque flux de données, demandez-vous ce qu'un attaquant pourrait faire : intercepter, usurper, altérer, saturer, extraire. Incluez le mésusage raisonnablement prévisible du produit, pas seulement l'attaque délibérée. Consignez chaque menace crédible avec la vulnérabilité qu'elle exploiterait.
Étape 4 : noter les risques
Notez la probabilité et l'impact de chaque menace à l'aide de votre échelle documentée. Lorsqu'un incident pourrait causer un dommage physique, intégrez l'effet sur la santé et la sécurité des utilisateurs dans la notation de l'impact. Classez les résultats. L'objectif de la notation est la priorisation, pas la précision. Un classement défendable qui oriente les décisions de conception vaut mieux qu'un tableau qui a l'air précis mais que personne n'utilise.
Étape 5 : décider de l'applicabilité des exigences de sécurité
Passez en revue les 13 exigences de sécurité du produit une par une. Pour chacune, indiquez si elle s'applique à ce produit, quels risques identifiés elle traite, et comment vous la mettez en œuvre. Lorsqu'une exigence ne s'applique vraiment pas, écrivez la justification. Le tableau de correspondance complet ci-dessous est votre feuille de travail.
Étape 6 : traiter les risques et consigner les risques résiduels
Pour chaque risque significatif, consignez le contrôle choisi, son lieu de mise en œuvre, et le risque résiduel après contrôle. Définissez des critères d'acceptation et consignez qui a accepté le risque restant. Les risques sans contrôle ont besoin d'une décision d'acceptation explicite et nominative.
Étape 7 : approuver et fixer les déclencheurs de maintenance
Faites approuver l'évaluation par un responsable nommé, avec une date. Définissez ensuite les événements qui la rouvrent : nouvelle information sur une vulnérabilité, nouvelles fonctionnalités, changements de composants ou de fournisseurs, constats d'incident. Ajoutez un tableau d'historique des révisions afin que les autorités puissent voir que le document a vécu.
Cartographier les 13 exigences de sécurité
C'est le cœur de l'évaluation. Le CRA énumère 13 exigences de sécurité du produit, et votre document doit répondre à deux questions pour chacune : s'applique-t-elle, et comment la mettez-vous en œuvre. Le tableau ci-dessous traduit chaque exigence en questions de revue et en preuves typiques.
La colonne exigence reste proche du texte légal. La colonne contrôles ne fait pas partie de la loi : elle liste les mesures et preuves que les équipes utilisent généralement pour montrer que l'exigence est respectée.
| # | Exigence | Contrôles et preuves typiques |
|---|---|---|
| 1 | Mise à disposition sur le marché sans vulnérabilité exploitable connue | Scans de dépendances et de firmware, test d'intrusion, enregistrements de triage montrant les constats résolus avant l'expédition |
| 2 | Configuration sécurisée par défaut, avec la possibilité de réinitialiser le produit à son état d'origine. Le fabricant et l'utilisateur professionnel peuvent convenir autrement pour un produit sur mesure | Revue de la configuration par défaut, aucun mot de passe par défaut, services inutiles désactivés, protocoles sécurisés activés |
| 3 | Vulnérabilités traitables par des mises à jour de sécurité. Lorsque cela est applicable, mises à jour de sécurité automatiques installées dans un délai approprié par défaut, avec une option de désactivation simple, une notification à l'utilisateur et la possibilité de reporter | Conception du mécanisme de mise à jour, politique de mise à jour |
| 4 | Protection contre l'accès non autorisé au moyen de mécanismes de contrôle appropriés, tels que l'authentification et la gestion des identités ou des accès, avec signalement des accès non autorisés possibles | Architecture d'authentification, tests de contrôle d'accès, conception du verrouillage |
| 5 | Confidentialité des données stockées, transmises ou autrement traitées, par exemple par le chiffrement des données pertinentes au repos ou en transit avec des mécanismes à l'état de l'art | Spécifications de chiffrement, procédure de gestion des clés |
| 6 | Intégrité des données, commandes, programmes et configuration contre toute manipulation non autorisée par l'utilisateur, avec signalement des corruptions | Signature du firmware et de la configuration, résultats des tests d'intégrité |
| 7 | Traitement des seules données adéquates, pertinentes et limitées à la finalité prévue du produit (minimisation des données) | Inventaire des données avec justification par élément |
| 8 | Disponibilité des fonctions essentielles et de base, y compris après un incident, avec résilience et atténuation des attaques par déni de service | Conception de la résilience, tests de charge et d'abus |
| 9 | Réduction de l'impact négatif du produit lui-même ou de ses dispositifs connectés sur la disponibilité des services fournis par d'autres dispositifs ou réseaux | Analyse du comportement réseau, limitation de débit |
| 10 | Conçu, développé et produit pour limiter les surfaces d'attaque, y compris les interfaces externes | Inventaire des interfaces, checklist de durcissement, ports de débogage fermés |
| 11 | Conçu, développé et produit pour réduire l'impact d'un incident, à l'aide de mécanismes et techniques appropriés d'atténuation de l'exploitation | Options de build, protections mémoire, isolation (sandboxing), séparation des privilèges |
| 12 | Informations pertinentes pour la sécurité enregistrées et surveillées, couvrant l'accès aux données, services ou fonctions ou leur modification, avec une option de désactivation pour l'utilisateur | Conception de la journalisation, catalogue d'événements |
| 13 | Les utilisateurs peuvent supprimer de manière sécurisée et simple toutes les données et tous les paramètres de façon permanente, et lorsque des données peuvent être transférées vers un autre produit ou système, le transfert se fait de manière sécurisée | Conception de la réinitialisation et de l'effacement, flux de transfert sécurisé |
Deux remarques pratiques sur l'usage du tableau :
- « Lorsque cela est applicable » est une décision propre à chaque produit, et c'est à vous de la défendre. Les exigences s'appliquent sur la base de votre évaluation des risques. Un outil logiciel autonome qui ne détient aucune donnée et aucun paramètre peut justifier l'exclusion de l'exigence de suppression des données. Aucun produit ne peut exclure la capacité de mise à jour simplement parce que les mises à jour sont gênantes.
- La cartographie fait aussi office d'index des preuves de conformité. La colonne contrôles de chaque ligne indique ce qui doit figurer dans le dossier technique, et c'est la matière qu'une évaluation de la conformité examinera.
Couvrir les processus de gestion des vulnérabilités
L'évaluation doit aussi indiquer comment vos processus continus couvrent le produit. Les exigences de processus du CRA sont le pendant opérationnel de la même médaille. Votre évaluation doit confirmer, brièvement et avec des renvois vers les documents propriétaires, que pour ce produit vous :
- identifiez et documentez les vulnérabilités et les composants, y compris un SBOM couvrant au moins les dépendances de premier niveau
- traitez et remédiez aux vulnérabilités sans retard, avec des mises à jour de sécurité livrées séparément des mises à jour fonctionnelles lorsque cela est techniquement faisable
- appliquez des tests et des revues efficaces et réguliers de la sécurité du produit
- une fois une mise à jour publiée, divulguez publiquement la vulnérabilité corrigée avec une description, les produits concernés, les impacts, la gravité et une aide à la remédiation. Un délai justifié est autorisé lorsque les risques de sécurité de la publication l'emportent sur les bénéfices, et seulement jusqu'à ce que les utilisateurs aient eu la possibilité d'appliquer le correctif
- exploitez une politique de divulgation coordonnée des vulnérabilités
- fournissez une adresse de contact pour les signalements de vulnérabilités et facilitez la circulation des informations sur les vulnérabilités potentielles, y compris pour les composants tiers
- distribuez les mises à jour au moyen de mécanismes sécurisés afin que les correctifs arrivent en temps utile, automatiquement lorsque cela s'applique aux mises à jour de sécurité
- diffusez les mises à jour de sécurité sans retard et à titre gratuit, avec des messages d'avis indiquant aux utilisateurs quoi faire. Pour un produit sur mesure, un client professionnel peut convenir autrement, uniquement sur le point de la gratuité
Ces points sont des résumés de travail, pas le texte légal complet. Gardez cette section courte dans votre évaluation, renvoyez vers les documents de processus propriétaires, et vérifiez les exigences complètes dans notre guide de gestion des vulnérabilités.
Exemple concret
Les extraits ci-dessous montrent le niveau de détail qui fonctionne en pratique. Le produit est un capteur environnemental connecté fictif, avec une application compagnon et un tableau de bord cloud.
Extrait du registre des risques
ÉVALUATION DES RISQUES DE CYBERSÉCURITÉ
Produit : SmartSense Pro (SSP-3000)
Version : 2.4.1
Date de l'évaluation : January 2027
Responsable : [Nom, équipe sécurité]
MÉTHODE :
Probabilité x impact, échelles définies à la section 1.
Risque = Probabilité (1-5) x Impact (1-5)
Bandes : Faible (1-4), Moyen (5-9), Élevé (10-16), Critique (17-25)
-------------------------------------------------------------
ID DU RISQUE : R-001
MENACE : Modification non autorisée du firmware
VULNÉRABILITÉ : Un firmware non signé pourrait être installé
IMPACT : 5 - Compromission du dispositif, violation de données
PROBABILITÉ : 3 - Nécessite un accès physique ou au réseau local
RISQUE INHÉRENT : 15 (Élevé)
CONTRÔLE : Vérification de la signature du firmware
MISE EN ŒUVRE : Signature ECDSA P-256 vérifiée avant l'installation
RISQUE RÉSIDUEL : 3 (Faible) - Attaque cryptographique improbable
STATUT : Atténué
-------------------------------------------------------------
ID DU RISQUE : R-002
MENACE : Interception de la communication cloud
VULNÉRABILITÉ : Trafic réseau lisible en transit
IMPACT : 4 - Exposition de données, injection de commandes
PROBABILITÉ : 3 - Réseaux partagés et publics attendus
RISQUE INHÉRENT : 12 (Élevé)
CONTRÔLE : TLS 1.3 avec épinglage de certificat
MISE EN ŒUVRE : Certificat d'autorité épinglé, sans repli
RISQUE RÉSIDUEL : 2 (Faible) - Compromission du certificat improbable
STATUT : Atténué
-------------------------------------------------------------
[Continuer pour tous les risques identifiés...]
RÉSUMÉ DES RISQUES :
Total des risques identifiés : 23
Critique : 0
Élevé : 3 (tous atténués à Faible ou Moyen)
Moyen : 8 (tous atténués à Faible)
Faible : 12 (acceptés ou atténués)
ACCEPTATION DU RISQUE RÉSIDUEL :
Tous les risques résiduels sont dans la tolérance définie à la section 1.
Accepté par : [Responsable sécurité], [Date]
Extrait de l'enregistrement d'applicabilité
APPLICABILITÉ DES EXIGENCES DE SÉCURITÉ
EXIGENCE 3 - MISES À JOUR DE SÉCURITÉ
S'applique : OUI
Risques traités : R-004, R-011
Mise en œuvre : Mises à jour OTA signées. Mises à jour de sécurité
automatiques activées par défaut, désactivation et report possibles
dans les paramètres de l'application. Utilisateurs notifiés dans
l'application et par e-mail.
Preuve : Conception du mécanisme de mise à jour UMD-002
EXIGENCE 12 - JOURNALISATION ET SURVEILLANCE
S'applique : OUI
Risques traités : R-009
Mise en œuvre : Événements de sécurité (échecs d'authentification,
changements de configuration, événements de mise à jour) enregistrés
sur le dispositif et transmis au cloud. Désactivation de la
journalisation disponible dans les paramètres de confidentialité.
Preuve : Conception de la journalisation LD-001, catalogue d'événements
EXIGENCE 13 - SUPPRESSION SÉCURISÉE DES DONNÉES
S'applique : OUI
Risques traités : R-015
Mise en œuvre : La réinitialisation d'usine efface définitivement
toutes les données et tous les paramètres stockés, y compris les
identifiants réseau. Le dispositif ne détient aucune donnée
utilisateur transférable, donc aucun chemin de transfert n'existe.
Preuve : Conception de la réinitialisation et de l'effacement RD-001
[Continuer pour les 13 exigences...]
Notez l'entrée sur la suppression des données : l'exigence couvre toutes les données et tous les paramètres, et les identifiants réseau stockés comptent. Lorsqu'une exigence ne s'applique vraiment pas, l'entrée garde la même forme mais nomme les caractéristiques du produit qui l'écartent. Un outil logiciel autonome sans donnée stockée et sans paramètre pourrait consigner : « Non applicable. Le produit ne détient aucune donnée et aucun paramètre. Il n'y a rien à supprimer. » Cette phrase factuelle est ce qu'une autorité peut évaluer.
Squelette de document
Une structure que vous pouvez copier pour l'évaluation écrite :
ÉVALUATION DES RISQUES DE CYBERSÉCURITÉ - [Produit, version]
1. MÉTHODE
Échelles, formule, bandes de risque, seuils d'acceptation
2. CONTEXTE DU PRODUIT
Finalité prévue / Usage et mésusage prévisibles
Environnement opérationnel / Utilisateurs
Actifs à protéger
Durée d'utilisation attendue
Périmètre : composants inclus, exclusions avec motifs
3. ARCHITECTURE ET SURFACE D'ATTAQUE
Interfaces, flux de données, frontières de confiance
(référence au diagramme)
4. REGISTRE DES RISQUES
Une entrée par menace crédible, notée, avec contrôle,
risque résiduel et statut
5. APPLICABILITÉ DES EXIGENCES DE SÉCURITÉ
Une entrée par exigence (les 13), s'applique oui/non,
mise en œuvre, renvoi vers la preuve, justification si
non applicable
6. SOCLE DE SÉCURITÉ DÈS LA CONCEPTION ET COUVERTURE DES PROCESSUS
Comment le niveau de sécurité global du produit correspond
à ses risques, renvois vers les processus de gestion des
vulnérabilités
7. RISQUE RÉSIDUEL ET ACCEPTATION
Résumé, critères d'acceptation, acceptation nominative
8. APPROBATION ET MAINTENANCE
Responsable, date d'approbation
Déclencheurs de mise à jour
Tableau d'historique des révisions
Tenir l'évaluation à jour
L'évaluation est un document vivant pendant toute la période d'assistance. Rouvrez-la lorsque :
- une nouvelle information sur une vulnérabilité arrive pour le produit ou ses composants, via votre propre surveillance, des rapports de chercheurs ou des avis de fournisseurs
- le produit change, et systématiquement lorsqu'un changement est assez substantiel pour exiger une nouvelle évaluation de la conformité
- des composants changent, y compris de nouveaux fournisseurs et de nouvelles versions de composants tiers ou open source
- un incident vous apprend quelque chose que vos notations n'avaient pas anticipé
Consignez chaque révision dans le tableau d'historique, avec ce qui a changé et pourquoi. Une évaluation datée une seule fois, il y a trois ans, indique à un agent de surveillance du marché que le document est décoratif.
Un devoir de cohérence est facile à manquer. Votre évaluation prend en compte la durée d'utilisation attendue du produit. La période d'assistance que vous déclarez doit refléter cette durée d'utilisation attendue, pondérée par ses propres facteurs légaux. Les deux enregistrements doivent donc concorder. Si votre évaluation anticipe huit ans sur le terrain et que votre période d'assistance déclarée est de cinq ans, révisez la détermination au regard de ces facteurs. Le résultat habituel est une période d'assistance plus longue, pas une note de bas de page expliquant l'écart.
Qui en est responsable, et où elle s'inscrit dans votre flux de travail
Le CRA rend le fabricant responsable. Il n'assigne pas de rôles internes et ne prescrit ni méthodologie d'évaluation des risques ni flux de travail d'équipe. Mais une évaluation que personne ne possède devient obsolète, donc les équipes sur le terrain la répartissent à peu près ainsi :
- Le product owner. Possède le contexte : finalité prévue, usage prévisible, durée d'utilisation attendue. Décide de ce que le produit promet, et valide donc quand la promesse change.
- Les développeurs et architectes. Possèdent le tableau des menaces : interfaces, flux de données, les contrôles qui traitent chaque risque, et la preuve que ces contrôles existent.
- Le responsable sécurité, ou quiconque porte cette casquette. Possède la méthode, le registre, l'enregistrement d'applicabilité et l'approbation. Dans une petite équipe, une seule personne porte les trois casquettes, et cela fonctionne.
Reliez ensuite les déclencheurs de mise à jour aux moments où le travail se produit déjà, afin que l'évaluation ne dépende jamais de la mémoire de quelqu'un :
Où l'évaluation des risques s'inscrit dans votre boucle de livraison
Quatre moments où le travail se produit déjà. Après l'étape 4, la boucle recommence, pour toute la période d'assistance.
1Lancement d'une fonctionnalité
Revue rapide lorsqu'une fonctionnalité touche une interface, stocke de nouvelles données ou franchit une frontière de confiance. La plupart des fonctionnalités ne changent rien.
Vous obtenez : une note « aucun changement », ou des entrées de registre mises à jour
2Exécution CI/CD
La génération du SBOM et les scans de dépendances et de firmware continuent de produire les preuves du registre à chaque build.
Vous obtenez : les artefacts de pipeline vers lesquels pointe le registre
3Release
Confirmez que l'évaluation correspond toujours au produit avant son expédition.
Vous obtenez : une entrée de révision datée. « Revu, aucun changement » compte
4Changement ou incident
Une montée de version de composant ou un constat d'incident rouvre les entrées de registre concernées.
Vous obtenez : une évaluation mise à jour, prête pour le prochain lancement
Les preuves du pipeline proviennent de l'outillage que vous exploitez déjà : la génération du SBOM en CI/CD alimente l'enregistrement des composants, et votre processus de gestion des vulnérabilités est ce qui rouvre les entrées à l'étape 4. Le CRA prescrit le résultat, une évaluation documentée tenue à jour, pas la boucle. La boucle est ce qui rend ce devoir tenable face à la pression réelle de la livraison.
Composants tiers
Le risque de votre produit inclut les composants qu'il contient. Lorsque vous intégrez des composants tiers, y compris des composants open source, vous devez exercer une diligence raisonnable afin qu'ils ne compromettent pas la sécurité du produit. Dans l'évaluation, cela signifie :
- les risques liés aux composants apparaissent dans le registre lorsqu'ils sont significatifs, le SBOM servant d'ossature d'inventaire
- votre approche de sélection et de surveillance des composants est précisée, avec des renvois vers les preuves fournisseurs
- les voies de mise à jour des composants font partie de l'analyse de la capacité de mise à jour
Les mécanismes pratiques, y compris un questionnaire fournisseur, se trouvent dans le guide de diligence raisonnable sur les fournisseurs.
Où vit l'évaluation
L'évaluation écrite fait partie de votre dossier technique, aux côtés de la documentation de conception, des preuves de test et de l'enregistrement de la décision sur la période d'assistance. Conservez la version approuvée, son historique de révisions, et les preuves qu'elle référence, accessibles aussi longtemps que le dossier doit être conservé. Le guide de la documentation technique montre la structure du dossier et où se situe chaque preuve.
Erreurs courantes
- Rédigée après coup. Une évaluation produite la semaine avant l'expédition ne peut pas avoir orienté la conception. Les relecteurs le remarquent.
- Aucune décision d'applicabilité. Un registre de risques seul ne répond pas à la question que pose le CRA. Chacune des 13 exigences a besoin d'une réponse explicite.
- « Non applicable » sans justification. Chaque exclusion a besoin d'un raisonnement écrit dans le dossier.
- Méthode non documentée. Des notations sans échelles, des formules sans définitions.
- Niveau entreprise au lieu du niveau produit. Un registre de risques SMSI couvre votre organisation. Le CRA veut ce produit précis.
- Figée à la release. Aucun historique de révisions, aucun déclencheur de mise à jour, aucun lien avec la surveillance des vulnérabilités.
- Incohérente avec la période d'assistance. Des hypothèses de durée d'utilisation qui contredisent la fenêtre d'assistance déclarée.
- Aucun responsable nommé. Personne ne l'a approuvée, personne n'accepte le risque résiduel, personne ne possède les mises à jour.
Questions fréquentes
L'évaluation des risques de cybersécurité est-elle obligatoire pour tous les produits ?
Oui, pour tout produit entrant dans le champ du CRA, quels que soient la taille de l'entreprise ou la catégorie de produit. Les niveaux de classification changent la voie de conformité, pas le devoir d'évaluation. Même le produit le plus léger dans le champ a besoin de l'évaluation documentée et des décisions d'applicabilité. Les produits exclus par le CRA, comme les dispositifs médicaux couverts et les équipements aéronautiques certifiés, suivent leurs propres règles sectorielles.
Les gestionnaires de logiciel open source ont-ils besoin de cette évaluation des risques ?
Non. Le devoir d'évaluation incombe aux fabricants. Un gestionnaire qui remplit les conditions du CRA relève d'un régime allégé assorti de devoirs propres. Dès que vous commercialisez le produit comme le vôtre, vous êtes le fabricant et le devoir d'évaluation complet s'applique. Le guide des rôles indique de quel côté vous vous situez.
Existe-t-il un modèle ou une méthodologie obligatoire ?
Non. Le CRA exige une évaluation documentée avec un contenu minimal précis, et vous laisse le choix de la méthode. Toute approche reproductible fonctionne si elle produit les décisions d'applicabilité demandées par le CRA. Le squelette de ce guide couvre ce contenu obligatoire et ajoute les contrôles documentaires recommandés.
Nous conduisons déjà des évaluations des risques ISO 27001. Est-ce suffisant ?
Pas à elles seules. Les évaluations ISO 27001 couvrent la sécurité de l'information de votre organisation. L'évaluation du CRA couvre un produit, son architecture et ses utilisateurs, et doit répondre à la question d'applicabilité par exigence. Vous pouvez réutiliser la méthode et les échelles. Vous ne pouvez pas réutiliser le périmètre.
L'évaluation peut-elle faire partie d'une autre évaluation des risques déjà due au titre du droit de l'Union ?
Seulement dans un cas étroit. Les produits que le CRA traite comme des systèmes d'IA à haut risque, et qui relèvent aussi d'autres textes de l'Union exigeant une évaluation des risques, peuvent intégrer l'évaluation de cybersécurité à cette autre évaluation. Pour tout le reste, elle reste autonome. Dans tous les cas, les exigences de contenu restent identiques et le document doit toujours montrer l'analyse de cybersécurité et les décisions d'applicabilité.
À quelle fréquence devons-nous la mettre à jour ?
Il n'y a pas d'intervalle fixe. Le devoir est déclenché par événement : mettez à jour l'évaluation selon les besoins pendant la période d'assistance, et dès qu'une information nouvelle et pertinente apparaît. En pratique, les équipes la rattachent à leur surveillance des vulnérabilités, aux mises à jour de composants et à chaque release du produit, avec en complément une revue de cohérence périodique.
Que se passe-t-il si nous marquons une exigence comme non applicable et qu'une autorité n'est pas d'accord ?
La qualité de votre justification écrite détermine l'issue de l'échange. Une justification factuelle rattachée aux caractéristiques du produit donne à l'autorité une base d'évaluation. Un simple « non applicable » se lit comme une lacune du dossier technique et invite un constat de non-conformité. Si les faits changent, par exemple une nouvelle fonctionnalité commence à stocker des données utilisateur, l'exclusion doit être révisée.