Naviguer dans la conformité à la cybersécurité de l'UE pour les produits connectés: Réponses expertes à vos questions sur le RED et l'ARC
17 juil. 2026
Lors de notre webinaire, Naviguant dans la conformité de Cybersécurité de l'UE pour les produits connectés, les participants ont soulevé des questions détaillées sur la Cyber Resilience Act (CRA), Exigences de cybersécurité RED, classification des produits, évaluation de conformité, rapport d'incident, systèmes nuageux et périodes de support de la sécurité.
Nous avons répondu à plusieurs questions durant la session en direct. Pour les prises de contrôle principales du webinaire, y compris la portée ROUGE, l'évaluation du risque EN 18031, la documentation, la préparation des preuves, et la préparation des rapports de l'ARC, lisez notre RED, EN 18031 et notre Guide de préparation à l'ARC : Réponses pratiques du webinaire de l'ACMI.
Nous n'avons pas pu répondre à toutes les questions durant la session, donc nos experts en cybersécurité ont préparé les réponses supplémentaires ci-dessous.
Cet article reflète le statut de réglementation et de normalisation à compter de juillet 2026. Les obligations de déclaration de l'ARC s'appliquent à partir du 11 septembre 2026, tandis que les principales exigences de l'ARC s'appliquent à partir du 11 décembre 2027.
Ces réponses fournissent des conseils techniques généraux. La bonne voie de classification et d'évaluation de la conformité pour un produit spécifique doit être déterminée à l'aide de sa documentation technique complète, utilisation, utilisation raisonnablement prévisible, connectivité et architecture de sécurité.
Question 1 : Nous avons un portefeuille de cryptomonnaies froid sous la forme d'une carte NFC. Ses fonctions principales sont le stockage, l'envoi et la réception de cryptomonnaies sans KYC. Il fonctionne à travers une application mobile utilisant NFC. Quelles normes et restrictions harmonisées peuvent s'appliquer?
La correspondance la plus proche sous la réglementation de mise en œuvre (UE) 2025/2392 sera probablement « cartes à puce ou appareils similaires» y compris les éléments sécurisés, qui est une catégorie de produits critiques.
Cela est dû au fait que la fonctionnalité principale de la carte semble être un stockage sécurisé de clés de chiffrement et la signature de transactions dans un facteur de formulaire de carte. Toutefois, une classification précise nécessite une évaluation minutieuse.
Quelle puce se trouve à l'intérieur de la carte?
La description technique de l'annexe IV exige que l'élément sécurisé fournisse une résistance aux attaques au moins à AVA_VAN.4 en vertu de critères communs.
Selon la puce, le produit peut être classé comme suit :
Un élément sécurisé à base de JavaCard chez AVA_VAN.4 peut être classé comme étant critique.
Une puce résistante aux manipulations chez AVA_VAN.2 ou AVA_VAN.3 peut être classée comme importante Classe II.
Un microcontrôleur de sécurité au-dessous de AVA_VAN.2 peut être classé comme important classe I.
Une puce de mémoire NFC simple avec traitement cryptographique effectué dans un logiciel ailleurs restera probablement dans la catégorie par défaut.
Quelle est la véritable fonctionnalité fondamentale du produit dans son ensemble?
Selon l'ébauche des directives de l'ARC, la classification est fondée sur la fonctionnalité unique du produit dans son ensemble.
Dans ce cas, la fonctionnalité de base est décrite plus précisément comme un stockage sécurisé des clés et la signature des transactions, plutôt que d'envoyer et de recevoir des crypto-actifs. La diffusion de la transaction vers la blockchain est normalement effectuée par l'application mobile, pas par la carte.
Cette distinction est importante lorsque l'on compare le produit avec les descriptions techniques du Règlement de mise en oeuvre.
Quelle est la voie de l'évaluation de la conformité si le produit est classé comme Critique?
L'article 32, paragraphe 4, de l'ARC, exige une certification européenne de cybersécurité pour les produits critiques. Le système concerné devrait être l'EUCC, qui repose sur des critères communs et le profil de protection applicable pour les éléments sécurisés.
Les normes harmonisées et la certification EUCC peuvent toutes deux fournir une présomption de conformité avec les exigences de Cybersécurité essentielle de l'ARC, mais leur utilisation dépend de la catégorie de produit et des conditions applicables.
Deux points doivent être vérifiés avant de s'appuyer sur un certificat EUCC pour la conformité de l'ARC.
1. Alignement entre la limite du produit et la cible de l'évaluation
Un certificat EUCC ne couvre que ce qui est inclus dans son objectif d'évaluation défini, ou TOE.
Le fabricant doit vérifier que la limite TOE couvre tout ce qui est inclus dans l'allégation de conformité de l'ARC. Selon la conception du produit, cela peut inclure :
L'élément sécurisé
Firmware
L'application de portefeuille fonctionnant sur l'élément sécurisé
L'interface NFC
L'application mobile, où elle fait partie du produit
Tout traitement backend qui est qualifié de solution de traitement de données à distance
2. L'acte délégué de l'ARC n'a pas encore été délivré
La loi déléguée définissant les conditions dans lesquelles l'EUCC prévoit la présomption de conformité avec l'ARC n'a pas encore été adoptée.
Jusqu'à ce qu'il s'applique, les produits Critiques doivent suivre la procédure de repli pour les produits importants de la classe II. Cela nécessite une évaluation par une tierce partie obligatoire à l'aide du Module B plus Module C, ou Module H, avec un corps notifié.
L'acte délégué définira également le niveau d'assurance EUCC requis, qui doivent être au moins « substantielles » et peuvent être « élevées », selon le risque identifié.
Quelles normes planifiées peuvent être pertinentes?
Les deux normes au niveau de la plate-forme et du niveau de l'application peuvent être pertinentes :
prEN 50764, exigences de Cybersécurité pour les plateformes de cartes à puce et autres dispositifs similaires, y compris les éléments sécurisés. Cela couvre les éléments sécurisés du matériel et de la plate-forme du microprogramme. Elle sera normalement pertinente pour le fabricant de la puce, mais elle peut également s’appliquer lorsque le fabricant du portefeuille conçoit sa propre puce.
prEN 18330, exigences de Cybersécurité pour les cartes à puce ou appareils similaires, y compris les éléments sécurisés, couche d'application. Cela couvre l'application de portefeuille fonctionnant sur l'élément sécurisé et est plus directement pertinent pour le fabricant de portefeuille.
prEN 40000-1-2, prEN 40000-1-3, et prEN 40000-1-4, normes horizontales couvrant les principes de résilience cybernétique, conformité basée sur les risques, gestion des vulnérabilités et exigences de cybersécurité génériques.
Au moment de la rédaction, ces normes n'ont pas été citées dans le Journal officiel de l'Union européenne comme des normes harmonisées de l'ARC. Ils ne donnent donc pas encore la présomption de conformité.
La prochaine étape consiste à identifier la puce et son niveau de certification de critères communs, à définir la limite précise du produit, à documenter le rôle de l’application mobile. et répertorie la fonctionnalité principale du produit en fonction des descriptions techniques dans la mise en œuvre du règlement (UE) 2025/2392.
Une fois que prEN 50764 et prEN 18330 sont publiés, leurs sections de portée devraient être examinées avec soin afin de déterminer comment elles s'appliquent au produit spécifique et comment les responsabilités sont réparties entre la plate-forme des éléments sécurisés et l'application en cours d'exécution.
Lorsque la classification demeure incertaine, le fabricant devrait consulter l'autorité de surveillance du marché pertinente ou l'organisme d'évaluation de la conformité avant de choisir une voie d'évaluation de la conformité.
Question 2 : La norme EN 18031 sera-t-elle remplacée par EN 40000 ?
EN 18031 ne doit pas être vu comme étant directement remplacé par EN 40000.
Dans le cadre de la directive sur les équipements radioélectriques, l'approche préférée pour démontrer le respect des exigences en matière de cybersécurité prévue à l'article 3, paragraphe 3, point d), 3(3)e) et 3(3)f) doivent appliquer la série harmonisée EN 18031, en tenant compte des restrictions incluses dans sa référence au Journal officiel.
À partir du 11 décembre 2027, les produits couverts par l'ARC devront se conformer aux exigences de cybersécurité essentielle de l'ARC et utiliser des normes conformes ou harmonisées en vertu de la LCC.
EN 40000 est une série standard plus large liée au CRA avec plusieurs pièces. Par exemple, EN 40000-1-3 se concentre sur la gestion des vulnérabilités, tandis que d'autres parties traitent des processus de conformité basés sur les risques et des exigences de cybersécurité génériques.
Les exigences de sécurité spécifiques aux produits doivent toujours être sélectionnées en fonction de l’évaluation et de la classification des risques du produit.
EN 18031 peut donc demeurer une preuve technique utile lorsque ses exigences sont pertinentes. Cependant, la conformité de l'ARC exigera du fabricant qu'il répertorie les risques du produit et les exigences de cybersécurité essentielles de l'ARC par rapport aux pièces EN 40000 applicables. des normes spécifiques à un produit, ou d'autres spécifications techniques justifiées.
Question 3 : Si nous avons plusieurs appareils avec la même fonctionnalité mais des facteurs de formulaire différents, tels que les cartes et les anneaux, devons-nous effectuer deux fois les contrôles de conformité?
Chaque type de produit distinct, y compris chaque facteur de formulaire, doit être couvert par l'évaluation de conformité et la déclaration de conformité de l'UE. Pour une carte et un anneau, cela signifie normalement évaluer les deux types de produits.
Cependant, le nombre pratique de travaux répétés dépend du module d'évaluation de la conformité sélectionné.
Module H, assurance qualité complète
Le module H peut être la route la plus efficace dans cette situation.
L’organisme notifié évalue et certifie le système de gestion de la qualité du fabricant couvrant les types de produits pertinents. L'ajout d'un nouveau facteur de formulaire peut alors être traité comme une extension au système de qualité existant, plutôt que comme une réévaluation complète depuis le début.
Module B + Module C
Dans le cadre du Module B plus Module C, un certificat d'examens distinct de type UE peut être requis pour chaque type de produit.
Cependant, les résultats des tests, la documentation technique et d'autres preuves de la première évaluation peuvent être réutilisés lorsque la technologie sous-jacente est identique, y compris :
L'élément sécurisé
Firmware
Fonctions cryptographiques
Architecture de sécurité
Mettre à jour les mécanismes
Lorsque la fonctionnalité de base et l'architecture de sécurité sont les mêmes, l'évaluation supplémentaire devrait se concentrer sur les différences introduites par le facteur de formulaire, comme l'interface physique, l'intégration matérielle, la résistance aux altérations et la surface d'attaque.
Le module H peut être la voie la plus efficace pour les fabricants qui envisagent de mettre sur le marché plusieurs variantes de produits connexes. Le traitement des modèles individuels et des types de produits doit être confirmé auprès du corps notifié sélectionné.
Question 4 : Une passerelle telle qu'une passerelle utilisée pour contrôler les lumières ZigBee serait-elle considérée comme un produit par défaut ou important ?
La classification nécessite une analyse approfondie des fonctionnalités fondamentales du produit sur la base de sa documentation complète.
Cela comprend :
Objectif prévu
Documentation technique
Instructions à utiliser
Matériel promotionnel
Implémentation technique réelle
Le fabricant doit prendre cette décision. Une classification ne peut être présumée à partir du mot « passerelle » seul.
Selon le test « entièrement assorti» décrit dans le guide de l'ARC ébauche, la fonctionnalité de base du produit doit correspondre pleinement à la description technique d’une catégorie de l’annexe III ou de l’annexe IV pour être considérée comme importante ou critique.
Pour une passerelle ZigBee dont la fonctionnalité principale documentée est le contrôle local intelligent de la maison comme le basculement ou la gradation des lumières, deux catégories peuvent paraître pertinentes.
Routeur
La description technique des routeurs exige que le produit établisse et contrôle le flux de données entre différents réseaux en utilisant des mécanismes de protocole de routage et des algorithmes à la couche réseau.
Un pont de protocole utilisé pour le contrôle de l'appareil peut ne pas correspondre à cette définition, mais le résultat doit être vérifié par rapport à l'implémentation technique réelle.
Produits maison intelligents avec des fonctionnalités de sécurité
Cette catégorie s'applique aux produits de maison intelligente dont la fonctionnalité principale est liée à la sécurité physique des consommateurs, comme des serrures de porte connectées, des caméras et des systèmes d'alarme.
Le contrôle de la lumière ne correspond pas entièrement à cette description.
Si la fonctionnalité de base du produit ne correspond pas entièrement à une description technique de l’annexe III ou de l’annexe IV, elle restera généralement dans la catégorie par défaut.
Cependant, le résultat peut être différent si la documentation complète du produit montre que le routage sur Internet ou une fonction de sécurité explicite fait partie de ses fonctionnalités principales.
Question 5 : Qui devrait signaler les incidents par le biais de la plateforme de déclaration unique si une entreprise se compose de plusieurs usines opérant sous la même marque ?
Le rapport ne doit pas être soumis séparément par chaque usine.
Elle devrait être soumise par la société ou le fabricant légal responsable de la mise sur le marché du produit européen.
Dans la pratique, toutes les usines devraient signaler les problèmes pertinents en interne à une seule équipe responsable de la sécurité des produits ou à une seule équipe responsable de l'ARC.
Cette équipe centrale devrait :
Décidez si le cas répond aux exigences de l'ARC en matière de déclaration
Collecter les informations requises
Préparer la notification
Soumettez-le par le biais de la plateforme de reporting unique
Coordonner toutes les communications requises aux utilisateurs
À des fins de déclaration, l’emplacement concerné est normalement le principal établissement du fabricant dans l’UE.
Cela signifie généralement l'établissement où sont prises les principales décisions de cybersécurité concernant le produit. Si cela ne peut être déterminé, cela peut être lié à l'établissement de l'UE qui compte le plus grand nombre de travailleurs.
L’entreprise devrait donc avoir un seul détenteur central de l’information et un processus d’escalade interne clair couvrant toutes les usines et tous les sites.
Question 6 : EN 18031 n'explique pas comment effectuer l'évaluation des risques ou fournir un modèle.
L'ARC n'exige pas des fabricants qu'ils utilisent une méthodologie spécifique d'évaluation des risques liés à la cybersécurité.
Les fabricants peuvent choisir leur propre approche, à condition qu'elle leur permette de documenter :
Identification des risques
Analyse et évaluation des risques
Traitement des risques
La relation entre les risques identifiés et les exigences de Cybersécurité essentielle de l'ARC
Les décisions prises lors de l'évaluation
L'évaluation des risques doit appuyer les obligations énoncées dans l'article 13 de l'ARC et les exigences en matière de documentation technique à l'annexe VII.
Les sources actuelles d'orientation incluent :
La FAQ sur la mise en œuvre de l’ARC de la Commission européenne, en particulier la section expliquant la portée, les extrants et la documentation requises.
Les directives de l’ARC de la Commission sur l’évaluation des risques liés à la cybersécurité et le traitement des risques
BSI TR-03183-1, qui fournit une méthodologie détaillée et étape par étape pour l'évaluation des risques, structurée autour des exigences de l'Annexe I du CRA
La norme prEN 40000-1-2 en développement devrait fournir un processus structuré de conformité basé sur le risque. Cependant, il ne doit pas être traité comme un modèle obligatoire qui peut être appliqué sans modification à chaque produit.
Question 7 : L'ARC s'applique-t-elle aux produits qui se connectent l'un à l'autre, comme les détecteurs de fumée liés, même s'ils ne se connectent pas à Internet ou à une application?
Oui, ils peuvent relever du champ d'application de l'ARC.
L'ARC définit un produit avec des éléments numériques comme un produit dont le but visé ou l'utilisation raisonnablement prévisible comprend un produit direct ou indirect, connexion de données logiques ou physiques à un périphérique ou réseau.
Une connexion Internet ou une application mobile n'est donc pas nécessaire.
Les détecteurs de fumée liés qui échangent des données directement entre eux peuvent répondre à cette définition parce qu'ils ont une connexion directe à un autre appareil ou réseau.
Que le produit soit par défaut, important ou critique doit ensuite être évalué séparément en fonction de sa fonctionnalité de base.
Question 8 : Comment l'ARC affecte-t-elle les distributeurs qui ajoutent de la valeur en installant une image de système d'exploitation Windows ou Linux personnalisée ?
L'installation d'une image personnalisée du système d'exploitation exigera très probablement du distributeur qu'il vérifie s'il a pris les obligations du fabricant en vertu de la Loi sur les produits de l'ARC.
Il y a deux situations principales dans lesquelles un distributeur devient un fabricant en vertu de l'article 21 de l'ARC :
Le distributeur met le produit sur le marché sous son propre nom ou marque de commerce.
Le distributeur effectue une modification substantielle du produit.
Une modification substantielle est un changement qui:
Affecte la conformité avec les exigences de Cybersécurité essentielle de l'ARC, ou
Modifie l'objectif prévu pour lequel le produit a été évalué à l'origine
Une image personnalisée du système d'exploitation peut changer :
Configurations de sécurité
Composants logiciels installés ou supprimés
Paramètres de sécurité par défaut
Services réseau
Mettre à jour les mécanismes
Permissions
Journalisation
La surface globale de l'attaque
Ces changements sont susceptibles d'affecter la conformité aux exigences de cybersécurité essentielle de l'ARC et peuvent donc être considérés comme une modification substantielle.
Lorsque la modification est substantielle, le distributeur devient le fabricant du produit modifié et assume les obligations pertinentes de l'ARC.
Celles-ci peuvent inclure :
Évaluation du risque de cybersécurité
Documentation technique
Évaluation de la conformité
Marquage CE
Gestion des vulnérabilités
Mises à jour de sécurité
Rapports d'incident et de vulnérabilité
Le distributeur ne peut pas se fier uniquement à la conformité de l'ARC de Microsoft, un distributeur Linux ou le fabricant de périphériques originaux. La conformité doit être évaluée et démontrée pour le produit final configuré mis sur le marché.
Question 9. Comment les systèmes cloud sont-ils évalués en vertu de l'ARC si nous n'utilisons pas l'infrastructure AWS, Azure ou Google Cloud ?
Le fournisseur de cloud n'est pas le facteur décisif.
Ce qui importe, c'est que le cloud ou le backend processing soit qualifié comme une Solution de traitement de données à distance, ou RDPS.
L'ARC inclut un RDPS dans la définition d'un produit comportant des éléments numériques lorsque les conditions suivantes sont remplies :
Les données sont traitées à distance, en dehors de l’appareil ou de l’environnement local de l’utilisateur.
La solution de traitement a été conçue ou développée par ou sous la responsabilité du fabricant.
Sans ce traitement, le produit n'a pas pu exécuter l'une de ses fonctions.
Lorsque ces conditions sont remplies, le backend fait partie du produit avec des éléments numériques et doit se conformer aux exigences applicables de l'annexe I de l'ARC.
Un RDPS n'a pas besoin de fonctionner sur une infrastructure de cloud publique tierce.
Le traitement à distance peut se qualifier comme un RDPS lorsqu'il s'exécute sur:
Les propres serveurs du fabricant
Un nuage privé
Infrastructure sur place
Infrastructure gérée par un autre fournisseur
Ne pas utiliser AWS, Azure ou Google Cloud ne crée pas d'exemption.
Les services SaaS, PaaS ou IaaS autonomes conçus et développés indépendamment d'un produit particulier ne sont généralement pas conformes à la définition du produit de l'ARC. D'autres lois, dont NIS2, peuvent encore s'appliquer à ces services.
Les fabricants doivent évaluer leurs systèmes de gestion de fonds en fonction des critères de la DSR au cas par cas. Lorsqu'ils sont admissibles, ils doivent être inclus dans la limite des produits, dans l'évaluation des risques, dans la documentation technique et dans l'évaluation de la conformité.
Question 10. Les contrôleurs multimédia de l'industrie du divertissement utilisent les ports Wi-Fi et Ethernet pour contrôler les produits. Le protocole utilisé, Art-Net, est différent de l'Internet, ces produits sont-ils dans le cadre de la cybersécurité RED ou de l'ARC ?
Pour l'ARC, le point pertinent est la définition d'un produit comportant des éléments numériques.
Un produit fait partie de la portée générale de l'ARC lorsque l'objectif visé ou l'utilisation raisonnablement prévisible comprend une utilisation directe ou indirecte, connexion de données logiques ou physiques à un périphérique ou réseau.
Un contrôleur multimédia qui communique par Wi-Fi ou Ethernet peut donc relever de la portée de l'ARC, même si le protocole d'application est Art-Net.
Le nom du protocole spécifique ne détermine pas si le produit est dans sa portée.
Pour la cybersécurité RED, une évaluation plus détaillée est nécessaire.
Le fabricant doit déterminer si l'équipement radio peut communiquer par Internet, soit directement soit par le biais d'un autre équipement.
L'utilisation d'Art-Net ne place pas automatiquement le produit hors de la portée de la cybersécurité RED. Le fabricant devrait examiner l'architecture de connectivité complète, y compris les passerelles, les routeurs, les systèmes de télécommande et tout accès possible à Internet.
Question 11. Pouvez-vous fournir des conseils sur la sélection de la période de soutien à la sécurité?
La période de soutien par défaut prévue par la Loi est d'au moins cinq ans.
Toutefois, le fabricant doit également tenir compte de la durée de vie prévisible du produit.
Une période plus courte peut être justifiée lorsque le produit devrait raisonnablement être utilisé pendant moins de cinq ans. Une période plus longue est nécessaire lorsque le produit devrait rester utilisé plus longtemps.
La période de soutien devrait être prise en considération :
Le but prévu du produit
Durée de vie prévue de son fonctionnement
Les attentes de l'utilisateur
L'environnement dans lequel il est utilisé
La disponibilité des produits de remplacement
Les périodes de support des composants incorporés
Dépendances sur les systèmes d'exploitation, applications ou services externes
Exigences légales et contractuelles pertinentes
Les produits utilisés dans la technologie opérationnelle, les systèmes industriels, les infrastructures de construction ou d'autres environnements à long terme peuvent nécessiter une période de soutien bien plus longue que cinq ans.
La période de support choisie devrait être justifiée dans l'évaluation des risques, documentée dans la documentation technique et communiquée aux utilisateurs.
Question 12. L'ARC exige-t-elle la déclaration séparée de la même vulnérabilité pour différents dispositifs, comme une carte et un anneau disponibles en plusieurs couleurs?
Un rapport peut couvrir la même vulnérabilité pour toutes les variantes de produits concernés.
L'article 14 de l'ARC oblige les fabricants à déclarer les vulnérabilités exploitées activement contenues dans un produit comportant des éléments numériques. La notification doit inclure des informations générales sur les produits concernés.
L'ARC n'exige pas de rapports distincts pour chaque :
Couleur
UGS
Facteur de formulaire
Variante commerciale
Si la même vulnérabilité affecte à la fois la carte et l'anneau parce qu'ils partagent le même firmware, logiciel, élément sécurisé, ou autre composant vulnérable, une notification couvrant toutes les variantes affectées est appropriée.
La notification devrait identifier clairement toutes les affectées :
Types de produits
Modèles
Versions matérielles
Version du firmware ou du logiciel
Si la carte et l'anneau utilisent des implémentations de microprogramme ou de sécurité différentes et qu'une seule est affectée, une déclaration séparée peut être appropriée parce que les produits sont techniquement différents.
Le fabricant devrait indiquer explicitement toutes les variantes affectées dans la notification. Cela permet au même rapport de couvrir toute la famille de produits touchés sans soumissions inutiles en double.
Question 13. Cyberexpert est-il une plateforme basée sur le cloud? Utilise-t-il une API publique, et comment la cohérence de ses sorties est-elle garantie ?
Oui. Cyberexpert est une plate-forme SaaS basée sur le cloud.
Les utilisateurs y accèdent grâce à une interface Web sécurisée où les informations sur les produits, les évaluations, les exigences et les preuves sont gérées de façon centralisée.
Cela permet aux équipes de :
Collaborer sur les activités de conformité
Progression du parcours
Gérer la preuve du produit
Maintenir une trace d'audit cohérente
Cyberexpert est conçu comme une plate-forme extensible plutôt que comme une application IA autonome.
Elle peut s'intégrer à des services externes tels que:
Fournisseurs d'identité
Systèmes de gestion de vulnérabilité
Dépôts de documents
Plateformes de conformité de l'entreprise
La réponse de l’expert confirme que les intégrations externes sont prises en charge. La disponibilité d'une API publique et des options d'intégration spécifiques devraient être confirmées directement par l'équipe Cyberexpert.
La cohérence des sorties est supportée par plusieurs couches :
Flux de travail structurés
Logique de l'évaluation déterministe
Examen des experts humains si nécessaire
Une base de connaissances contrôlée et organisée
Orchestrer les IA normalisées
Génération augmentée de récupération à l'aide de sources contrôlées
La valeur fondamentale de Cyberexpert vient de sa logique de conformité et de son flux de travail structuré. L’AI participe au processus, mais les résultats sont fondés sur des sources contrôlées, des informations sur les produits et des règles d’évaluation définies.
Question 14. Est-ce qu'une radio intelligente utilisée principalement pour la radio sur Internet, Spotify et la lecture des médias relève de l'ARC ?
« Oui. »
Une radio intelligente fait partie de la portée de l'ARC parce que son objectif est de relier directement un réseau.
Le périphérique initie et maintient la communication bidirectionnelle sur IP. Par exemple, il envoie des requêtes de connexion et de session et reçoit des données de flux audio.
Cela constitue une connexion logique directe à un réseau.
Le fait que le produit ait pour principal objectif l’écoute radio ou la lecture de médias ne le retire pas de la portée générale de l’ARC.
Sa classification par défaut, importante, ou produit critique doit être évalué séparément en fonction de ses fonctionnalités fondamentales et des descriptions techniques dans la mise en œuvre du règlement (UE) 2025/2392.
Lorsque le produit utilise le Wi-Fi, le Bluetooth ou une autre technologie radio elle peut également être couverte par la Directive sur les équipements radio et nécessiter une évaluation séparée de la cybersécurité RED.
Préparation de la conformité au RED et à l'ARC
Les noms de produits et les étiquettes de connectivité ne suffisent pas pour déterminer les obligations du RED ou de l'ARC.
Les fabricants doivent définir la limite du produit, documenter la fonctionnalité principale du produit, identifier chaque chemin de connectivité, déterminer la catégorie de produit applicable et relier chaque conclusion de conformité à des preuves techniques.
Cyberexpert aide les fabricants à structurer ce travail, à identifier les exigences applicables, à préparer des preuves et à déterminer où un examen expert ou une évaluation formelle de la conformité est nécessaire.
Partager ceci sur
