RED, EN 18031 et le Guide de préparation de l'ARC : Réponses pratiques du webinaire de QIMA

La partie la plus utile du webinaire de QIMA, de la conformité à la cybersécurité de l’UE pour les produits connectésétait la Q&A.

Les fabricants ont demandé à propos des normes , du cadrage, des variantes de produits, des rapports de l'ARC, des périodes de support et de la documentation. Telles sont les questions qui se posent lorsque la cyber et l'ARC RED commencent à affecter les produits réels, les échéanciers de lancement et les dossiers techniques.

Cet article transforme ces questions en conseils pratiques pour les équipes de produits, d'ingénierie, de conformité, de qualité et de certification.

QIMA a construit Cyberexpert pour les travaux de préparation décrits dans cet article : cadrage, cartographie des besoins, préparation des preuves, E. L'article explique d'abord les décisions que les fabricants doivent prendre.

Il s'agit d'un récapitulatif éducatif et non d'un conseil juridique. Les fabricants devraient vérifier les obligations spécifiques aux produits en fonction du texte légal officiel, des normes harmonisées et de la voie choisie pour l'évaluation de la conformité.

La leçon principale: ne commencez pas par la norme

Une erreur commune est de se demander d'abord quelle norme devrions-nous utiliser?

C'est trop tard dans la logique.

La meilleure première question est la suivante: De quoi ce produit a-t-il besoin pour prouver ?

La réponse dépend de la limite de produit , de l'utilisation prévue, de la connectivité, du traitement des données, des actifs, des interfaces, de la fonctionnalité de base, et que le ROUD, le CRA ou les deux s'appliquent.

Les exigences cybernétiques RED proviennent de la Directive sur les équipements radio et de ses exigences essentielles liées à la cybersécurité au titre de l'Article 3(3)(d), (e) et (f), couvrant la protection des réseaux, la données personnelles et la vie privée, et la protection contre la fraude. Le Règlement délégué (UE) 2022/30 active ces exigences pour les catégories spécifiques d'équipements radio, et la Décision d'exécution (UE) 2025/138 concerne les normes harmonisées soutenant ces exigences cybersécuritaires RED.

CRA est plus large. Il s'applique aux produits avec des éléments numériques mis sur le marché de l'UE lorsque leur objectif prévu ou leur usage raisonnablement prévisible inclut une connexion logique ou physique directe ou indirecte à un appareil ou un réseau. Cela crée également des obligations pour le fabricant en matière de conception, développement, production, maintenance, documentation technique, évaluation de conformité, périodes de support et gestion des vulnérabilités.

Cela signifie que le premier livrable doit être une carte de conformité spécifique au produit.

1. Est-ce que EN 18031 sera remplacé par EN 40000?

Question du webinaire : Est-ce que EN 18031 sera remplacé par EN 40000 ?

Réponse courte : Pas nécessairement.

Gergely Bakos a expliqué dans les Q&A que la série EN 18031 et la série EN 40000 ont une portée et une couverture différentes. EN 18031 est un élément central de la conformité à la cybersécurité RED.

Les fabricants ne doivent donc pas supposer qu'une norme remplace simplement l'autre.

Pour un produit radio de portée cyber ROUGE EN 18031 peut toujours être le chemin central du RED. Mais les obligations de l'ARC peuvent nécessiter un travail supplémentaire, en particulier en ce qui concerne la gestion des vulnérabilités, la déclaration, les mises à jour de sécurité et la planification de la période de soutien.

Conclusion pratique : la sélection des normes devrait suivre l'analyse du produit.

Un fabricant devrait être en mesure d'expliquer :

• pourquoi EN 18031 s'applique, ou ne s'applique pas

• si une orientation de la norme EN 40000 est nécessaire pour un travail additionnel de l'ARC

• où la gestion des vulnérabilités est couverte

• où une implication du corps notifié peut être nécessaire

• dont la preuve est à la base de chaque décision

Si la réponse est « nous utilisons EN 18031 », la sélection standard n’est pas suffisamment documentée.

2. La portée ROUGE est là où les fabricants peuvent être retardés tôt

La section de portée du Cédric Lévy-Bencheton était l’une des parties les plus pratiques du webinaire. Son point était clair : portée cyber ROUGE n'est pas toujours évidente.

Un produit peut poser des questions sur le ROUGE lorsqu'il possède une interface sans fil et une connectivité Internet, même si la connexion Internet n'est pas sans fil.

Exemple 1:

Un périphérique a Bluetooth pour la configuration et Ethernet pour la communication réseau. Le Bluetooth peut être local, mais la connexion Ethernet peut toujours avoir de l'importance pour la portée cyber ROUGE (RED).

Exemple 2:

Un produit utilise le Zigbee et se connecte via une passerelle ou une application mobile. Appeler « radio locale » ne suffit pas. Si l'application ou la passerelle peut contrôler le produit à distance, la connectivité indirecte doit être revue.

Avertissement utile : le traitement des données personnelles ne signifie pas automatiquement qu'il y a un effet sur la vie privée dans chaque cas. Un microphone ou un amplificateur sans fil peut traiter l'audio mais pas le stocker. L'analyse de confidentialité dépend toujours de ce que le produit fait avec les données.

Test de portée pratique

Avant de décider du champ d'application, les fabricants devraient répondre à quatre questions :

1. Est-ce que le produit a une interface radio ?

2. Le produit dispose-t-il d'une connexion directe ou indirecte à Internet ?

3. Un autre système, une application, une passerelle ou un service cloud peuvent-ils contrôler le produit ?

4. Est-ce que le processus, stocker, transmettre ou exposer des données pertinentes à la protection du réseau, à la vie privée ou à la protection de la fraude?

Un fichier de portée utile devrait inclure un diagramme de connectivité simple. Il devrait montrer les interfaces sans fil, les interfaces câblées, les applications mobiles, les passerelles, le traitement cloud ou à distance, les canaux de mise à jour et les interfaces de service ou de débogage.

Cela n'a pas besoin d'être compliqué mais doit être précis.

3. L'évaluation du risque RED et l'évaluation du risque de cybersécurité sont des documents différents

Question du webinaire : EN 18031 ne fournit pas de méthodologie d'évaluation des risques. Est-ce que EN 40000 remplit cette lacune ?

Réponse courte : partiellement, mais pas complètement.

Cedric a expliqué que EN 18031 inclut les arbres décisionnels et mentionne STRIDE, mais cela ne donne pas aux fabricants une méthode complète de modélisation des menaces ou d'évaluation des risques de cybersécurité. La norme EN 40000-1-2 a été discutée pour guider les étapes de la gestion des risques, mais pas comme une méthode prête à l'emploi qui peut être copiée dans chaque fiche produit.

La distinction est importante.

Une évaluation des risques cybersécuritaires RED aide à déterminer quelles exigences légales RED s'appliquent.

Une évaluation des risques de cybersécurité examine le risque réel du produit : utilisateurs, données, interfaces, exposition, contexte d'utilisation, scénarios d'attaque, impact, contrôle et risque résiduel.

L’exemple de la caméra du Cedric rend cela simple. La même caméra connectée peut comporter des risques différents dans une chambre, un jardin ou un parking. Le matériel peut être similaire. Le contexte ne l'est pas.

Une faible entrée de risque dit :

<unk> Le risque est faible.

Une entrée de risque utile dit :

✓ L'interface de service Ethernet n'est utilisée que pendant l'installation et la maintenance dans un environnement physique contrôlé. Elle n'est pas exposée lors du fonctionnement normal de l'utilisateur. Cette hypothèse est prise en charge par la procédure de service, la configuration de l'interface et la documentation d'installation. Basé sur ce contexte d'utilisation, le contrôle d'accès est traité comme non applicable pour cet actif et cette interface.

Ce type d’entrée aide l’ingénierie, la conformité et les évaluateurs à comprendre la décision.

4. EN 18031 est difficile car il est basé sur des actifs

EN 18031 n'est pas une liste de contrôle plate. Il demande aux fabricants de penser en termes d'actifs, d'interfaces, d'entités, de mécanismes de sécurité, de catégories d'implémentation et d'arborescence.

Les actifs peuvent comprendre des paramètres confidentiels, des paramètres sensibles, des fonctions, des paramètres de données, des actifs de sécurité, des actifs de réseau, des actifs de confidentialité et des actifs financiers.

Cela devient rapidement spécifique au produit.

Par exemple, une fonction de mise à jour sécurisée peut inclure la récupération de la mise à jour, la vérification, l'installation, le retour en arrière après échec et la journalisation du résultat. Un fabricant peut décider de les regrouper comme une seule fonction de mise à jour sécurisée. Cela peut être raisonnable, mais le regroupement ne doit pas cacher les détails qui sont importants pour l'évaluation.

Un registre d'actifs pratique ne devrait saisir que les champs qui sont importants :

Si le registre des actifs est faible, E.Info, E.Just, et les réponses à l'arborescence des décisions seront également faibles.

5. Les arbres décisionnels ont besoin de preuves, pas de suppositions

Les arbres décisionnels sont au centre de la norme EN 18031. Les fabricants les utilisent pour décider si une exigence s’applique. Les évaluateurs les utilisent pour déterminer si le résultat est PASS, FAIL, ou PAS APPLICABLE.

Cela signifie qu'un chemin de décision doit être documenté en tant que dossier de décision.

Un dossier de décision devrait répondre :

• dont l'exigence a été évaluée

• de quelle ressource et de quelle interface étaient impliquées

• quel chemin a été suivi

• pourquoi le résultat est PAS, FAIL, ou PAS APPLICABLE

• quelles preuves soutiennent le résultat

• si cette décision affecte d'autres exigences

Exemple : Ethernet et communication sécurisée

Cédric a expliqué que Ethernet peut être difficile parce qu'il est généralement non chiffré et n'a pas de contrôle d'accès inhérent. Si le contrôle d'accès s'applique à cette interface Ethernet, des exigences de communication sécurisées peuvent suivre.

Une faible justification dirait:

<unk> Ethernet n'est utilisé que par les techniciens.

Une justification plus forte dirait :

✓ L'interface Ethernet n'est accessible que pendant l'installation et la maintenance dans un environnement physique contrôlé. Les conditions d'accès sont décrites dans la documentation de l'utilisateur et du service. L'interface est désactivée ou restreinte en dehors des conditions de service. Basé sur ce contexte d'utilisation, l'arborescence de la décision de contrôle d'accès mène à PAS APPLICABLE pour cette ressource et cette interface. Les preuves étayantes sont fournies dans la procédure de service, la configuration de l'interface et la documentation sur l'architecture du produit.

C'est la différence entre une hypothèse et des preuves prêtes à être évaluées.

6. E.Info et E.Just devraient expliquer clairement le produit

La documentation EN 18031 n'est pas seulement un dossier de documents produits.

Elle doit expliquer ce qui est mis en œuvre, pourquoi il est pertinent, quel atout il protège, quel chemin de décision a été suivi et où les preuves peuvent être vérifiées.

Cédric a souligné que E.Info et E.Just sont utilisés lors de l'évaluation, donc ils ont besoin de commentaires d'ingénierie, de développement, de firmware, de produits et de conformité.

Réponse faible :

<unk> Le produit utilise le chiffrement.

Réponse plus forte:

✓ Le produit utilise TLS 1.3 pour la communication entre l'appareil et le service cloud. Ceci protège les données de configuration transmises et les informations d'état de l'appareil contre la divulgation et la modification non autorisées. Le mécanisme s'applique à l'interface réseau utilisée pour la communication dans le cloud. La mise en œuvre est décrite dans l'architecture de communication et vérifiée dans le rapport de test de sécurité. La gestion des certificats est décrite dans la section Gestion des clés. Références de preuves: diagramme d'architecture A-03, rapport de test T-12, extrait de configuration du microprogramme F-07.

La meilleure réponse est meilleure parce qu'elle indique à l'évaluateur ce qui est protégé, comment il est protégé, pourquoi il compte et où le vérifier.

7. Les variantes de produit peuvent réutiliser le travail, mais uniquement avec une raison d'être

Question du webinaire : Si les appareils ont la même fonctionnalité mais des facteurs de formulaire différents, ont-ils besoin de vérifications de conformité séparées ?

Réponse courte : vous n'avez peut-être pas besoin de commencer à partir de zéro, mais vous devez évaluer les différences.

Les fabricants devraient commencer par la fonctionnalité de base du produit. Si les variantes partagent la même fonction de base, certains travaux peuvent être réutilisables. Mais les différences entre les facteurs de formulaire peuvent toujours affecter les exigences de cybersécurité ou la conformité de l'ARC.

Par exemple, une carte et un anneau peuvent partager des fonctionnalités de microprogramme et de base. Mais ils peuvent différer en termes d'exposition physique, de comportement d'antenne, de contraintes de batterie, de processus de mise à jour, de probabilité de perte, d'interaction des utilisateurs ou de contexte de confidentialité.

Une table de réutilisation courte suffit :

Le but est d'éviter les travaux répétés sans copier les preuves qui ne correspondent pas au produit.

8. Les déclarations de l'ARC commencent avant la demande complète de l'ARC

Question du webinaire : Quelle est la différence pratique entre septembre 2026 et décembre 2027 sous l'ARC ?

Réponse courte : Septembre 2026 est une question de rapports. Décembre 2027 concerne l'application complète.

À compter du 11 septembre 2026, les fabricants doivent signaler les vulnérabilités exploitées activement et les incidents graves qui affectent la sécurité des produits avec des éléments numériques. La Commission européenne explique que le rapport comprend un avertissement précoce dans les 24 heures, une notification complète dans les 72 heures et les rapports finaux dans le délai applicable de 14 jours ou d'un mois. Les rapports sont rédigés une fois par le biais de la plate-forme unique de rapport de l'ARC, que l'ENISA est chargée d'établir.

Les principales dispositions de l’ARC s’appliquent à partir du 11 décembre 2027, tandis que les obligations de déclaration s’appliquent à partir du 11 septembre 2026. Le résumé de la Commission indique également que les obligations de déclaration s'appliquent à tous les produits dont les éléments numériques sont disponibles sur le marché de l'UE. y compris les produits déjà mis sur le marché avant le 11 décembre 2027.

Le point pratique de Mihaïly Pajerich était que les rapports ne peuvent pas fonctionner sans une gestion de vulnérabilité. Un fabricant ne peut pas signaler ce qu’il ne peut détecter, recevoir, évaluer, classer et escalader.

Processus minimum avant Septembre 2026

Avant le début de l'obligation de déclaration, les fabricants devraient avoir:

1. Un contact de signalement de vulnérabilité publique ou un formulaire Web.

2. Un propriétaire interne pour les rapports de routage.

3. Un moyen d'identifier les produits, les versions et les composants affectés.

4. Un processus d'évaluation de la gravité et de l'exploitation.

5. Un chemin de décision pour la déclaration.

6. Un processus de communication utilisateur.

7. Un modèle d'enregistrement d'incident.

Il s'agit d'un minimum pratique, qui ne doit pas être parfait, mais qui doit être utilisable.

9. Plusieurs usines ont besoin d'une seule arme de décision de déclarationh

Question du webinaire : Qui rapporte des incidents si une entreprise a plusieurs usines sous la même planche ?

Toutes les usines ne doivent pas signaler séparément. Les usines ou sites devraient avoir des voies de rapport internes. Une fonction centrale du fabricant doit évaluer si le cas doit être signalé via la plateforme de signalement unique. Si le fabricant est en dehors de l'UE, le représentant autorisé, l'importateur ou le distributeur peuvent être impliqués selon le cas.

Un test utile est un exercice de table .

Scénario :

Un fournisseur signale une vulnérabilité dans un module de communication utilisé dans trois produits. Un produit est déjà sur le marché européen. Le premier est en production, le premier est toujours en développement, l'exploitation active n'est pas claire. Un correctif existe mais il n'a pas été testé sur chaque produit.

Le fabricant doit être en mesure de répondre dans les délais de rapport:

• quels produits et versions sont affectés

• si la vulnérabilité est activement exploitée

• si les utilisateurs ont besoin de conseils d'atténuation

• si un rapport est nécessaire

• qui approuve le rapport

• où la preuve est stockée

Si cela ne peut pas être fait dans un test, le processus n'est pas prêt.

10. La planification de la période de soutien affecte l'ingénierie, pas seulement la conformité

Question du webinaire : Comment les fabricants devraient-ils décider de la période de support de sécurité correcte ?

Gergely a expliqué que cinq ans est le point de départ par défaut, mais la durée de vie prévue du produit importe. Les produits industriels ou OT à longue durée de vie peuvent nécessiter une planification plus longue.

Le texte législatif de l'ARC exige des fabricants qu'ils déterminent une période d'appui reflétant le moment où le produit devrait être utilisé. Il stipule également que la période de soutien doit être d'au moins cinq ans, à moins que le produit ne soit utilisé pour moins de cinq ans. Le texte officiel EUR-Lex fait également référence à l'exigence que les mises à jour de sécurité restent disponibles pour un minimum de 10 ans ou pour le reste de la période de soutien.

Cela affecte la planification du produit.

Avant le lancement, les fabricants devraient savoir :

• comment les mises à jour seront envoyées

• qui maintient des correctifs de sécurité

• quels engagements de fournisseur sont nécessaires

• comment les vulnérabilités de composants tiers seront surveillées

• comment la fin du support sera communiquée

• combien de temps les mises à jour de sécurité publiées resteront disponibles

Pour les produits de longue durée, cette décision devrait inclure des produits, des ingénieurs, du soutien, des propriétaires légaux et des propriétaires commerciaux.

Là où Cyberexpert s'adapte

La partie dure n'est pas de lire le règlement, la partie dure est la collecte des informations de produit, les exigences de mappage, l'écriture de E utilisable. nfo et E.Just, reliant des éléments de preuve aux réclamations, et sachant quand un examen expert est nécessaire.

C'est le travail de préparation que Cyberexpert est construit pour soutenir.

Cyberexpert aide les fabricants à structurer les informations sur les produits, à identifier les exigences applicables, à cartographier les attentes de E.Info, à préparer les preuves, à impliquer les fournisseurs, et à se préparer à l'autoévaluation, à l'examen d'expert ou à l'évaluation de laboratoire.

Si vous vous préparez maintenant pour le cyber RED, ou pour le prochain rapport CRA, utilisez Cyberexpert pour vérifier ce qui s'applique à votre produit, identifier les lacunes de documentation et préparer vos preuves avant l'évaluation formelle.

Un plan de préparation de 30 jours

Semaine 1 : Porter le produit

Créer une limite de produit, une carte de connectivité, une carte de données, une liste d'interface, un résumé d'utilisation, une note de portée RED et une note de portée de l'ARC.

Résultat : l'équipe sait quel produit est en cours d'évaluation et pourquoi il peut être en portée.

Semaine 2 : Construire la base EN 18031

Créer le registre des actifs, la liste des entités, la carte des interfaces, la cartographie initiale du mécanisme de sécurité et les hypothèses de l'arborescence des décisions qui nécessitent des preuves.

Résultat: l'équipe peut voir où le travail de EN 18031 est clair et où les informations sur le produit sont manquantes.

Semaine 3 : Vérifier les lacunes des preuves

Examen E.Info, E.Just, SBOM, HBOM, manuel d'utilisation, documentation de configuration, services exposés, processus de mise à jour, enregistrement, preuves de test et diagrammes d'architecture.

Résultat : l'équipe sait quelles preuves existent et ce qui a encore besoin de travail.

Semaine 4 : Préparer la vulnérabilité de l'ARC

Mettre en place le contact de signalement de vulnérabilité, le projet de politique CVD, le processus d'admission, l'inventaire des composants, la méthode d'évaluation de la gravité, le propriétaire du signalement, le processus de notification des utilisateurs et le modèle d'enregistrement des incidents.

Résultat : le fabricant a un processus de base avant le début de l'obligation de déclaration de l'ARC.

Ce qui est important à retenir

Les questions du webinaire portent sur une conclusion pratique :

Les fabricants doivent intégrer la conformité en matière de cybersécurité plus tôt dans le développement des produits.

Le ROUGE cyber peut affecter l'accès au marché maintenant. La déclaration de l'ARC commence avant l'application complète de l'ARC. EN 18031 nécessite des preuves spécifiques à un produit, et non des allégations génériques. EN 40000 peut aider à d'autres domaines, mais il n'élimine pas le besoin de comprendre le produit en premier.

Avant la prochaine réunion de planification RED ou de l'ARC, les fabricants devraient être en mesure de répondre :

• Le produit est-il dans la portée cyber du ROUGE ?

• Le produit est-il dans la portée de l'ARC?

• Quelle est la limite du produit ?

• Quelle est la fonctionnalité principale du produit ?

• Quelles interfaces et chemins de connectivité existent ?

• Quels sont les actifs qui ont besoin d'être protégés ?

• Quels chemins de décision ont été suivis par EN 18031?

• Peut-on justifier les résultats PASS, FAIL et NON APPLICABLES ?

• Est-ce que E.Info et E.Just sont validés par l'ingénierie ?

• Y a-t-il un inventaire SBOM ou des composants ?

• Y a-t-il un contact public de signalement de vulnérabilité?

• Qui est propriétaire de la déclaration de l'ARC en interne?

• Quelle est la période de soutien ?

• Quelles preuves peuvent être réutilisées entre les variantes de produits?

• Le produit est-il prêt à être autoévalué, examiné par un expert ou évalué en laboratoire?

Si plusieurs réponses sont floues, le produit est encore à l'étape de préparation.

C'est le moment idéal pour combler les lacunes avant qu'elles n'affectent l'évaluation, la certification ou l'accès au marché.

Pour mettre ces étapes en pratique, téléchargez la liste de contrôle pratique ci-dessous et utilisez-la pour examiner votre cyber RED et votre préparation à l'ARC.