Guide de conformité CRA Classe I : routeurs, modems, switches

Résumé

Un routeur Wi-Fi domestique, un modem-routeur, un modem internet, un nœud Wi-Fi maillé ou un switch doit normalement se planifier comme un produit Important Classe I. La nuance porte sur la fonction principale : un routeur commercialisé d'abord comme pare-feu, IDS/IPS, passerelle VPN ou équipement de gestion de réseau peut nécessiter une analyse de catégorie différente.

La première action de preuve est une note de classification et de périmètre pour le CPE ou l'équipement réseau exact. Elle doit identifier le matériel, le firmware, l'interface WAN, la pile sans fil, l'IHM d'administration LAN, l'application mobile, le cloud FAI ou fournisseur, le canal de gestion à distance, le mécanisme de mise à jour, l'inventaire des composants, la période d'assistance et toute modification de firmware sous marque blanche ou par le FAI.

Variante produit Classe CRA probable Pourquoi
Routeur Wi-Fi grand public Important Classe I La connectivité internet et le routage sont la fonction principale
Modem-routeur ou CPE de FAI Important Classe I Le produit raccorde les clients à internet
Modem câble, DSL ou fibre / ONT autonome Important Classe I s'il est destiné à la connexion internet La fonction de modem internet est la fonction principale du produit
Kit Wi-Fi maillé Important Classe I Les nœuds maillés forment le produit routeur ou la famille de produits
Hotspot mobile 4G/5G Important Classe I Le WAN cellulaire reste de la connectivité internet
Switch administrable Important Classe I La commutation plus un plan de gestion correspond à la fonction d'équipement réseau et élargit le périmètre de preuves
Switch non administrable ou non configurable Cas par cas Vérifiez s'il s'agit d'un produit comportant des éléments numériques et s'il existe un plan de gestion, une voie de mise à jour de firmware, une fonction cloud/app ou toute autre fonction connectée avant de le traiter comme un équipement réseau administrable
Routeur VPN Cas par cas, souvent Important Classe I Le VPN peut être la fonction la plus spécifique s'il est commercialisé ainsi
Routeur commercialisé comme pare-feu, UTM ou IPS Cas par cas, possiblement Important Classe II Pare-feu ou prévention peuvent devenir la fonction principale
Firmware de routeur commercial vendu seul Cas par cas Le produit logiciel peut lui-même être le produit routeur
CPE sous marque FAI avec matériel OEM Important Classe I, sensible au rôle Marquage blanc ou modifications de firmware peuvent déplacer les obligations du fabricant

Base de classification

Décision de classification pour un routeur, modem ou switch. Une question initiale sur la fonction principale commercialisée se divise en trois branches. Branche A, mise en avant : un routeur, modem internet ou switch administrable est Important Classe I point 12 parce que routage et connectivité internet sont la fonction principale. Branche B : un boîtier commercialisé surtout comme pare-feu ou système de détection et de prévention d'intrusion pose la question Classe II point 2. Branche C : un switch non administrable ou non configurable, ou une image de firmware open source commerciale, nécessite une vérification cas par cas. Une note de bas de page indique que filtrage de paquets, contrôle parental ou client VPN ne suffisent pas à eux seuls à faire passer un routeur en Classe II.
La première question de classification porte sur la fonction principale commercialisée : un routeur ou modem reste Classe I point 12 ; un boîtier d'abord pare-feu pose la question Classe II point 2.

Le CRA traite routeurs, modems internet et switches comme produits Important Classe I, ce qui n'est pas la même chose que le statut pare-feu Classe II. Les fonctions de sécurité supplémentaires ne déplacent pas un routeur en Classe II tant que routage et connectivité internet restent sa fonction principale commercialisée.

Le produit n'est pas Critique au seul motif qu'il se trouve en périphérie du réseau. La liste Critique est plus restreinte et n'inclut pas les routeurs grand public ni les CPE de FAI dans leur ensemble.

Qu'est-ce qui compte comme produit routeur ?

Un produit routeur, modem ou switch peut inclure plus que le boîtier plastique :

  • chargeur d'amorçage, système d'exploitation, noyau, pilotes sans fil, pile WAN et services LAN ;
  • modem, ONT, silicium de switch Ethernet, comportement du VLAN de gestion et contrôle PoE le cas échéant ;
  • IHM web d'administration, appariement par application mobile et portail de configuration local ;
  • TR-069, USP/TR-369 ou autre canal de gestion à distance ;
  • cloud fournisseur ou FAI utilisé pour l'accès distant, le contrôle parental, la télémétrie, la coordination maillée ou l'orchestration des mises à jour ;
  • service de mise à jour de firmware, clés de signature, image de récupération et processus d'assistance.

Le dossier de preuves doit aussi consigner ce qui est hors du produit : le compte FAI du client, les équipements domotiques tiers, les règles de réseau définies par l'utilisateur, le modem séparé lorsqu'il est vendu à part, et les systèmes opérateur en aval non fournis par le fabricant.

Quelle voie d'évaluation de la conformité le fabricant doit-il planifier ?

Important Classe I ne signifie pas automatiquement que chaque routeur a besoin d'une évaluation par tierce partie, mais le contrôle interne ne doit pas être supposé acquis. Si le fabricant peut utiliser la voie générale du contrôle interne et a pleinement appliqué les normes harmonisées pertinentes, des spécifications communes ou un schéma européen de certification de cybersécurité approprié à un niveau d'assurance au moins substantiel pour les exigences essentielles applicables, cette voie peut être disponible. Si ces références n'existent pas, ne sont que partiellement appliquées, ne sont pas appliquées ou ne couvrent pas toutes les exigences pertinentes, planifiez l'examen UE de type plus le contrôle interne de la production ou l'assurance qualité complète. La mécanique générale de la voie et le contenu requis de la déclaration UE de conformité figurent dans les guides évaluation de la conformité et déclaration de conformité ; cette page ne couvre que le choix propre au routeur.

Si la même variante matérielle est aussi commercialisée comme pare-feu, passerelle VPN, équipement de gestion de réseau ou plateforme de sécurité administrée, créez une note de classification distincte pour ce SKU.

Comment la date limite de cybersécurité RED s'articule-t-elle avec le CRA ?

La plupart des routeurs et modems connectés à internet contiennent une radio (Wi-Fi, modem cellulaire ou équivalent), et ce sous-ensemble équipé de radio a déjà franchi un seuil de cybersécurité avant l'arrivée du CRA. Depuis le 1 août 2025, les exigences de cybersécurité de la directive sur les équipements radioélectriques (RED article 3.3, points d, e et f, fixées par le règlement délégué (UE) 2022/30) s'appliquent aux équipements radio connectés à internet, comme les routeurs Wi-Fi, les nœuds maillés, les modems-routeurs et les passerelles cellulaires. Un équipement purement filaire, comme un routeur Ethernet uniquement ou un modem DSL, câble ou fibre sans radio, reste hors du champ cybersécurité de la RED, mais chacun reste un produit comportant des éléments numériques au titre du CRA. Les obligations de signalement du CRA commencent le 11 septembre 2026 et le CRA devient pleinement applicable le 11 décembre 2027, date à laquelle l'abrogation par la Commission du règlement délégué cybersécurité RED via le règlement délégué (UE) 2026/339 prend effet pour éviter que les deux régimes ne se chevauchent.

Chronologie reliant la date limite de cybersécurité des équipements radio au CRA. Depuis le 1 août 2025, les équipements radio connectés à internet respectent les exigences de cybersécurité de la RED (points d, e et f). Le règlement délégué cybersécurité RED est ensuite abrogé par le règlement délégué (UE) 2026/339, et le CRA devient pleinement applicable le 11 décembre 2027, avec des obligations de signalement qui commencent le 11 septembre 2026. Une voie parallèle des normes montre la série EN 18031 pour la phase RED, ETSI EN 304 627 comme norme routeur CRA en projet, et la série EN 40000 horizontale en projet.
Les fabricants de routeurs franchissent un seuil de cybersécurité des équipements radio à partir d'août 2025 ; les mêmes obligations passent sous le CRA à partir de décembre 2027.

Pour un fabricant de routeurs, la lecture pratique est la suivante :

  • Entre le 1 août 2025 et le 10 décembre 2027, les équipements radio applicables respectent les exigences de cybersécurité de la RED ; la voie harmonisée passe par la série EN 18031, avec ETSI EN 303 645 comme socle grand public sur lequel elle s'appuie.
  • À partir du 11 décembre 2027, les mêmes obligations de cybersécurité relèvent du CRA, avec ses obligations de cycle de vie plus larges : configuration sécurisée par défaut, processus de gestion des vulnérabilités, déclaration de la période d'assistance et obligations de signalement qui commencent dès le 11 septembre 2026.
  • Un routeur déjà mis sur le marché avant le 11 décembre 2027 ne relève du CRA que s'il est substantiellement modifié après cette date. La seule exception est l'obligation de signalement, qui s'applique à tout produit dans le champ, y compris aux unités déjà vendues.
  • La norme harmonisée CRA propre aux routeurs en préparation est ETSI EN 304 627 (routeurs, modems et switches), qui correspond à la Classe I point 12 et aux exigences essentielles de cybersécurité. C'est encore un projet, donc planifiez la voie de conformité sur les normes effectivement citées au moment voulu, et réutilisez les contrôles construits pour la RED (configuration par défaut sécurisée, mises à jour signées, contrôle d'accès) comme base du dossier CRA plutôt que de lancer un projet séparé.

Quelles preuves faut-il préparer ?

Domaine de preuves Ce qu'il faut capturer pour un routeur ou modem-routeur Pourquoi cela importe
Utilisation prévue Routeur domestique, CPE de FAI, modem, ONT, système maillé, hotspot mobile, switch, routeur VPN, switch administrable La classe suit la variante de produit réelle et les arguments commerciaux
Surface d'attaque WAN DHCP, PPPoE, IPv6, proxy DNS, NAT, valeurs par défaut du pare-feu, posture d'administration distante Le côté WAN reçoit du trafic non fiable avant toute configuration utilisateur
Administration LAN IHM web, API locale, portail de configuration, politique de mot de passe, récupération de compte, contrôles d'accès La plupart des erreurs de configuration et de propriété s'y produisent
Sans fil Valeurs par défaut WPA2/WPA3, décision WPS, isolation invité, intégration SSID/mot de passe, firmware de la puce Wi-Fi Les valeurs par défaut sans fil deviennent les valeurs par défaut de sécurité du foyer
Gestion à distance TR-069, USP/TR-369, cloud fournisseur, cloud FAI, accès distant par application mobile C'est souvent ce qui distingue un boîtier d'un produit géré en flotte
Voie de mise à jour Firmware signé, protection contre le retour arrière, versions poussées par le FAI, partition de récupération, notification de mise à jour Les mises à jour de routeur doivent couvrir la période d'assistance et survivre aux branches OEM/FAI
Preuves fournisseurs SDK du SoC, fournisseur Wi-Fi/bande de base, chargeur d'amorçage, noyau, pile TLS, services DNS/DHCP Les fabricants de routeurs héritent d'une vaste surface de composants tiers
Preuves de rôle Responsabilités OEM, FAI, importateur, distributeur et marque blanche Le CPE sous marque et les forks de firmware peuvent changer le propriétaire du dossier CRA

Quels détails d'architecture de routeur ne faut-il pas manquer ?

Les preuves de routeur doivent suivre l'équipement périphérique réellement expédié. Un routeur Wi-Fi grand public, un modem-routeur de FAI, un ONT PON, un modem câble, un hotspot mobile, un nœud maillé et un switch administrable présentent des expositions WAN, des risques de gestion à distance et des risques de branche de firmware différents.

Composants internes d'une passerelle routeur, représentés en quatre bandes horizontales par plan. Le plan données contient le port WAN, le switch LAN, la radio Wi-Fi et l'accélération matérielle. Le plan contrôle, qui tourne sur le CPU du SoC, contient le routage et le NAT, le pare-feu, le DHCP et le DNS, et l'authentification Wi-Fi. Le plan gestion contient la console d'administration web, SSH, SNMP, l'agent TR-069 et USP, et le client de mise à jour OTA. La couche plateforme contient le démarrage sécurisé, les bancs de firmware A et B, et la flash plus la DRAM. Chaque plan est un groupe distinct de composants qui appartient au dossier produit du fabricant.
Le routeur se divise en quatre plans : transmission des données, logiciel de contrôle sur le CPU, accès de gestion, et la plateforme qui démarre et stocke l'ensemble. Les quatre appartiennent au dossier produit.
Carte en étoile de qui parle au routeur. Le routeur se trouve au centre, à l'intérieur d'une frontière de dossier produit en pointillés. Côté foyer : un appareil d'administration local et le LAN et les appareils IoT du foyer. Côté opérateur et internet : l'internet non fiable, le serveur d'auto-configuration FAI ou opérateur, le serveur de mise à jour de firmware et le cloud fournisseur. Sept flux étiquetés traversent la frontière : liaison WAN montante, trafic LAN, association Wi-Fi, administration locale, gestion à distance, mise à jour de firmware signée et télémétrie fournisseur.
Chaque flux ici traverse la frontière du dossier produit : liaison WAN montante, LAN et Wi-Fi vers le foyer, administration locale, gestion à distance opérateur, mises à jour signées et télémétrie cloud. Le dossier doit tous les prendre en compte.
Point d'architecture Question de preuves pour routeur, modem ou switch
Chaîne de démarrage et récupération Identifiez la ROM de démarrage, le chargeur d'amorçage, l'état du démarrage sécurisé, l'image A/B ou en banc unique, le déclencheur de récupération, le compteur anti-retour-arrière et le comportement de remise à zéro usine. Conservez les tests d'abus de retour arrière et de récupération.
WAN et provisionnement Séparez Ethernet WAN, PPPoE, DHCP, IPv6, provisionnement DOCSIS/PON/cellulaire et profils opérateur. Montrez quels services analysent les entrées WAN non authentifiées avant que l'IHM d'administration n'existe.
Couche Wi-Fi et bande de base Suivez les blobs de firmware Wi-Fi, la configuration du domaine réglementaire, les forks hostapd/wpa_supplicant, la décision WPS et l'intégration maillée. Le firmware fournisseur entre dans le suivi des avis.
Gestion à distance Pour TR-069/CWMP, USP/TR-369, cloud fournisseur ou cloud FAI, enregistrez l'identité du contrôleur, la confiance des certificats, le comportement des requêtes de connexion, la portée des commandes et l'auditabilité.
Contrôle switch et maillage IHM de switch administrable, SNMP/API, VLAN, miroir de port, PoE, EasyMesh ou contrôleurs maillés propriétaires nécessitent leurs propres vérifications d'exposition du plan de gestion. Pour les switches non administrables ou non configurables, vérifiez d'abord s'il existe une surface numérique de gestion ou de mise à jour.
Branches FAI et marque blanche Tenez une matrice de branches montrant le build OEM, le fork FAI, le profil opérateur, l'approbation OTA, le responsable de la période d'assistance et la voie de notification utilisateur.
Fabrication et retour Enregistrez les secrets par appareil, les identifiants imprimés, la politique de shell de débogage, l'état UART/JTAG, l'effacement RMA et la désassociation cloud.

Le côté WAN est l'endroit où l'équipement analyse pour la première fois des entrées non authentifiées, et ce côté change avec la technologie d'accès. Un routeur grand public Ethernet WAN, un modem-routeur câble, un ONT fibre et un hotspot cellulaire ne partagent pas le même canal de provisionnement ni le même pair amont.

Variantes de technologie d'accès WAN pour un équipement périphérique internet. Un modem DSL se connecte à un DSLAM au central ; un modem câble se connecte à un CMTS via une liaison chiffrée et authentifiée par certificat avec BPI+ ou SEC ; un ONT fibre se connecte à travers un séparateur passif à un OLT ; un port Ethernet WAN se connecte à un switch amont ; et un module cellulaire se connecte à un réseau mobile. Chaque variante note ce qui change à la frontière de confiance WAN : le pair d'accès, le canal de provisionnement et l'entrée non authentifiée qui atteint l'équipement en premier.
La frontière WAN diffère selon la technologie d'accès : DSL, câble, fibre, Ethernet ou cellulaire changent chacun le pair d'accès et la première entrée non authentifiée.

À quoi ressemble une véritable évaluation de risques de routeur ?

Utilisez cela comme exemple de la profondeur attendue dans une évaluation de risques de dossier produit. Le fabricant doit toujours mener l'évaluation sur le routeur réel, le chipset modem, la pile sans fil, le canal de gestion à distance, les SDK fournisseurs, la propriété des mises à jour, les arguments commerciaux et la promesse de période d'assistance.

Profil du produit d'exemple

Produit d'exemple : ExampleCo HomeRouter R1, un routeur domestique Wi-Fi 7 vendu dans l'UE par les canaux de vente au détail et de marque blanche FAI. Il dispose d'un WAN Ethernet, de quatre ports LAN, d'un Wi-Fi invité, d'une IHM web locale d'administration, d'une intégration par application mobile, d'une gestion à distance FAI optionnelle, d'un firmware OTA signé, de vérifications automatiques de mise à jour, de services DNS/DHCP, de profils de contrôle parental et d'une image de récupération.

Le périmètre produit inclut le matériel du routeur, le chargeur d'amorçage, le noyau, les pilotes Wi-Fi, les services WAN, les services LAN, les valeurs par défaut du pare-feu, l'IHM web locale, l'appariement par application mobile, le cloud fournisseur pour l'accès distant, l'agent FAI optionnel de gestion à distance, le service OTA, l'image de récupération, le site d'assistance, la réception de divulgation coordonnée et le processus d'avis. Il exclut le modem du client lorsqu'il est vendu séparément, l'abonnement FAI, les équipements domotiques tiers, le fournisseur d'identité de l'utilisateur et les systèmes OSS/BSS du FAI en aval, sauf si le même opérateur économique les fournit dans le cadre du produit.

Cycle de vie de provisionnement pour le routeur d'exemple, de l'usine au retour. Étape un, usine : identité par appareil, identifiants uniques, certificats et un SSID par défaut. Étape deux, attachement WAN : Ethernet, PPPoE, DOCSIS, PON ou cellulaire détermine la première entrée non authentifiée. Étape trois, provisionnement : l'opérateur ou le fournisseur lie un profil ACS ou USP et la portée des commandes. Étape quatre, intégration : changement forcé de mot de passe, isolation invité et décision WPS. Étape cinq, firmware : un socle signé qui rejette les retours arrière. Étape six, remise à zéro, revente ou RMA : désassociation cloud, révocation de jetons et effacement de l'appartenance au maillage. Une bande inférieure liste les tests négatifs qui doivent passer à chaque transition.
Chaque étape du cycle de vie nomme ce qui change et le contrôle qui prouve que le mauvais acteur ne peut pas prendre le contrôle du routeur.
Périmètre de preuves du HomeRouter R1 Le dossier du routeur doit relier matériel, firmware, sans fil, gestion cloud, variantes FAI et opérations sur la période d'assistance.
Plus de dépendance opérateur
Environnement client et FAI Hypothèses de déploiement
Compte FAI Modem séparé Appareils domotiques Terminaux du foyer Outils OSS du FAI
Evidence

Documentez les hypothèses sur l'usage domestique attendu, le provisionnement FAI, la propriété de l'administration et les modes de déploiement non pris en charge.

Là où commence le produit du fabricant de routeur
Matériel routeur Mis sur le marché de l'UE
WAN Switch LAN Radios Wi-Fi SoC Bouton de remise à zéro Emplacement de récupération
Evidence

Dossier produit | note de périmètre SKU | dossier de risques | déclaration UE de conformité | enregistrement CE | déclaration de période d'assistance

Firmware et services Surface d'attaque à évaluer
Chargeur d'amorçage Noyau DNS/DHCP IHM web TR-069 / USP Agent OTA
Evidence

Inventaire des composants | inventaire des services | tests des valeurs par défaut sans fil | tests de mise à jour sécurisée | revue de gestion à distance

Couche fournisseur Diligence sur les composants routeur
SDK du SoC Firmware Wi-Fi Pilote Ethernet Bibliothèque TLS Service DNS SDK mobile
Evidence

Avis fournisseurs, suivi des versions de SDK, propriété des branches de firmware, triage CVE des composants et preuves de propagation des correctifs.

Pendant la période d'assistance
Flotte CPE en service Mises à jour et transfert de rôle
Correctifs firmware OEM Fusions de branches FAI Avis de sécurité Notifications utilisateur Signalement d'exploitation
Evidence

Tenez à jour la matrice de branches, le registre des versions de mise à jour, la trace d'approbation FAI, le registre des avis et le registre des décisions de signalement pour les vulnérabilités activement exploitées ou les incidents de sécurité graves.

Le CPE sous marque FAI nécessite des preuves particulières car le produit peut répartir conception, marque, approbation de firmware, gestion à distance et assistance utilisateur entre différents opérateurs économiques.
Fenêtre d'exposition au premier démarrage pour le routeur d'exemple. Une chronologie va de la mise sous tension, où les valeurs par défaut usine sont actives, à l'intégration, où les valeurs par défaut sont remplacées et la fenêtre est fermée. Entre les deux, une fenêtre d'exposition reste ouverte et quatre choses peuvent déjà atteindre le routeur avant que l'utilisateur ne modifie quoi que ce soit : l'entrée WAN depuis DSL, DOCSIS, PON ou cellulaire analysée avant connexion ; le SSID et le mot de passe par défaut livrés ; un serveur opérateur TR-069 ou USP qui peut lier un profil ; et les points d'extrémité cloud fournisseur, d'appariement mobile et OTA. Une bande liste ce qui ferme la fenêtre à l'intégration : changement forcé de mot de passe, socle de firmware signé, gestion à distance à portée limitée et isolation du réseau invité.
Release gate: l'ingénierie firmware détient le socle de premier démarrage, la sécurité produit détient le test d'exposition, et le support détient les preuves de remise à zéro et de RMA. Artifact: registre de provisionnement, scan d'exposition après configuration, test de rejet de retour arrière et résultat de transfert ou désassociation.
Question answered: avant que le foyer ne modifie le moindre réglage, quelle entrée WAN, quel profil opérateur et quel service par défaut peuvent déjà atteindre le routeur ?
Frontière de commandes de gestion à distanceTR-069/CWMP, USP/TR-369, cloud fournisseur et cloud FAI doivent être cadrés comme voies de contrôle de flotte.
Domaine de commande
Action typique
Question de risque
Preuve à conserver
Configuration
DNS, Wi-Fi, pare-feu, redirection de port ou mode pont.
Le contrôleur peut-il changer plus que ce que le profil évalué autorise ?
Matrice de portée des commandes et échantillon d'audit.
Diagnostics
Journaux, compteurs de paquets, statistiques de ligne ou paquet de support.
L'export divulgue-t-il SSID, jetons, identifiants client ou topologie ?
Test de masquage et inventaire des données.
Firmware
Mise à jour approuvée par l'opérateur, image de récupération ou changement de branche.
Un build ancien ou régional incorrect peut-il être poussé ?
Manifeste signé, carte des branches et rejet de retour arrière.
Propriété
Appariement cloud, migration FAI, retour ou revente d'équipement.
Le propriétaire précédent, le FAI ou le jeton d'application peut-il encore contrôler le boîtier ?
Tests de remise à zéro, de désassociation et de migration.
Evidence gate: la gestion à distance est une voie de contrôle de flotte, pas seulement une fonctionnalité opérateur. Le dossier de version doit lier chaque identité de contrôleur à la portée des commandes et à la branche de firmware. Artifact: revue de profil TR-069/USP, inventaire des certificats de contrôleurs et échantillon d'audit des commandes.
Question answered: quelle commande de gestion à distance peut changer DNS, pare-feu, firmware ou état de propriété, et qui a approuvé cette portée ?
Matrice de branches OEM, FAI et marque blancheLe même matériel peut être livré avec des propriétaires d'assistance, des points cloud et un calendrier de correctifs différents.
Base OEMFirmware de référence et inventaire des composants

Branche source, version du SDK, firmware Wi-Fi, noyau et clé de signature sont le socle de départ.

Fork FAIProfil opérateur et porte de version

Point ACS/USP, marque, configuration par défaut, flux d'approbation et propriétaire de la notification utilisateur sont documentés.

SKU vente au détailCloud fournisseur et appariement applicatif

Application mobile, appariement cloud, service maillé et déclaration de période d'assistance restent sous le processus de version du fournisseur.

Fusion de correctifPropagation des correctifs de sécurité

Suivez si les branches OEM, FAI et marque blanche ont reçu le même correctif de sécurité ou une exception documentée.

Patch gate: la promesse de période d'assistance suit la branche de firmware que les utilisateurs reçoivent effectivement. Evidence: matrice de branches, écart d'inventaire des composants par branche, trace d'approbation FAI, propriétaire de version sous marque blanche et exception documentée lorsqu'une branche ne peut pas prendre le même correctif.
Question answered: lorsque l'OEM corrige une vulnérabilité de routeur, comment chaque branche FAI, vente au détail et marque blanche prouve-t-elle que le correctif a atteint ses utilisateurs ?

Inventaire des actifs

Actif Pourquoi cela importe Où il se trouve
Contrôle du trafic WAN-LAN Contrôle l'exposition du foyer à internet NAT, valeurs par défaut du pare-feu, réseau du noyau
Compte et sessions d'administration du routeur Donne le contrôle sur DNS, Wi-Fi, redirection de port, mises à jour et remise à zéro IHM web, application mobile, magasin de jetons local, compte cloud
Identifiants Wi-Fi et isolation invité Des valeurs par défaut faibles exposent le réseau domestique et les appareils connectés Configuration Wi-Fi, flux d'intégration, règles de réseau invité
Identifiant de gestion à distance Un identifiant de contrôle de flotte peut affecter de nombreux routeurs Agent TR-069/USP, magasin de certificats, ACS/cloud FAI
Ancre de confiance pour la signature de firmware Protège le canal de mise à jour du routeur Chargeur d'amorçage, stockage sécurisé, service OTA
Configuration DNS/DHCP Peut rediriger les utilisateurs ou couper la connectivité Services locaux, IHM d'administration, provisionnement FAI
État de gestion du switch VLAN, isolation de port, PoE et accès de gestion peuvent exposer les réseaux en aval IHM de switch administrable, CLI, SNMP/API, configuration ASIC du switch
État de provisionnement modem/ONT Enregistrement, mode pont/routeur et identifiants de gestion affectent la périphérie internet Firmware du modem, profil opérateur, agent de gestion à distance
Journaux d'assistance et de diagnostic Peuvent révéler SSID, numéros de série, IP, liens vers le compte client et données de plantage Journaux d'appareil, application mobile, portail d'assistance
État de la branche de firmware La dérive entre branches FAI/OEM peut laisser des vulnérabilités non corrigées Système Git/version OEM, fork FAI, dépôt OTA
État de démarrage sécurisé et anti-retour-arrière Protège la voie de récupération et empêche le retour d'images connues vulnérables Chargeur d'amorçage, état eFuse/RPMB/TPM, registres de production
Firmware Wi-Fi/bande de base Le firmware radio peut affecter l'authentification, la disponibilité et l'exposition réseau Puce Wi-Fi, blob de firmware, SDK fournisseur, image de production

Frontières de confiance

Environnement Exposition attendue Conséquence de risque
Interface WAN Continuellement exposée au trafic réseau non fiable Bogues d'analyseur et services exposés peuvent compromettre l'équipement
LAN et réseau de configuration Partagés avec les terminaux du foyer et les appareils IoT Des attaquants locaux peuvent cibler l'administration, la découverte et les valeurs par défaut faibles
Interface sans fil Joignable depuis la proximité physique WPS, intégration faible ou défaillances d'isolation invité exposent le LAN
Plan de gestion du switch Joignable depuis le VLAN d'administration, le LAN ou les outils opérateur selon la configuration Des valeurs par défaut faibles peuvent exposer VLAN, contrôle PoE ou ports miroirs
Voie de gestion à distance Atteint l'équipement depuis l'infrastructure fournisseur ou FAI Fuite d'identifiant ou compromission ACS peut s'étendre à de nombreux routeurs
Voie OTA et récupération Reçoit des images de firmware privilégiées Signature faible ou retour arrière annule tous les correctifs de sécurité
Branche FAI/marque blanche Peut modifier firmware, points cloud et période d'assistance Les obligations peuvent se déplacer quand une marque contrôle les décisions de version et d'assistance

Scénarios de menace

ID Scénario de menace Actif à risque Point d'entrée
R1 Le point d'administration WAN est activé par défaut ou par profil FAI Compte d'administration, configuration du routeur WAN
R2 Le mot de passe à la première utilisation est partagé, prévisible ou imprimé d'une manière réutilisée entre lots Compte d'administration, identifiants Wi-Fi Intégration
R3 Une faille d'analyseur DHCP, IPv6, DNS ou PPPoE peut être déclenchée avant authentification Intégrité du routeur, disponibilité Services WAN
R4 Les identifiants TR-069 ou USP fuitent et permettent des changements de configuration à distance Identifiant de gestion à distance, DNS, canal de firmware Gestion FAI/fournisseur
R5 La récupération OTA accepte du firmware non signé ou plus ancien Intégrité du firmware OTA / récupération
R6 Le Wi-Fi invité peut router vers les appareils LAN ou l'IHM d'administration Terminaux du foyer, administration du routeur Sans fil / LAN
R7 L'intégration WPS ou par QR peut être détournée après la configuration initiale Identifiant Wi-Fi Intégration sans fil
R8 Shell de débogage, telnet, SSH ou UART reste accessible en production Intégrité du routeur, secrets Firmware / physique
R9 Un fork de firmware sous marque FAI omet un correctif de sécurité OEM État de la branche de firmware Processus de version
R10 Le jeton d'accès distant de l'application mobile reste valide après transfert ou remise à zéro usine du routeur Compte d'administration, propriété Cloud / application
R11 Une défaillance du cloud DNS ou de contrôle parental crée un comportement de repli non sûr Intégrité DNS, disponibilité Dépendance cloud
R12 Une vulnérabilité fournisseur dans le SDK du SoC, le firmware Wi-Fi ou un démon réseau livré n'est pas triée pendant l'assistance Intégrité du routeur, disponibilité Composant fournisseur
R13 L'IHM ou SNMP/API d'un switch administrable est exposée sur le LAN utilisateur avec des identifiants par défaut faibles État de gestion du switch, intégrité du VLAN LAN / plan de gestion
R14 Le profil de provisionnement modem ou ONT active l'administration distante ou un comportement en mode pont en dehors de l'état de version évalué État de provisionnement modem/ONT, exposition WAN Provisionnement opérateur
R15 Le mode de récupération, le démarrage par maintien de la remise à zéro ou la récupération TFTP accepte une image non authentifiée ou rétrogradée Intégrité du firmware, état de démarrage sécurisé Chargeur d'amorçage / récupération
R16 Le firmware Wi-Fi, l'intégration maillée ou le comportement WPS diffèrent entre révisions matérielles sans preuves de version Identifiants Wi-Fi, isolation invité Sans fil / SDK fournisseur
R17 La portée des commandes USP/TR-369 ou TR-069 autorise plus que le profil opérateur prévu Identifiant de gestion à distance, DNS, OTA Gestion FAI/fournisseur
R18 L'appariement applicatif ou le jeton de propriété cloud survit à la remise à zéro usine ou au retour FAI Compte d'administration, propriété Remise à zéro / compte cloud

Registre des risques initial

ID Probabilité Impact Décision initiale Justification
R1 Faible Élevé Traiter avant la version L'exposition d'administration distante donne un contrôle direct et est facile à scanner
R2 Moyenne Élevé Traiter avant la version Les utilisateurs domestiques conservent souvent les réglages par défaut sauf si l'intégration force le changement
R3 Moyenne Élevé Traiter avant la version Les analyseurs WAN sont exposés avant authentification
R4 Moyenne Sévère Traiter avant la version Les défaillances de gestion à distance peuvent s'étendre à toute une flotte FAI
R5 Faible Sévère Traiter avant la version Le retour arrière de firmware peut maintenir en vie des builds connus vulnérables
R6 Moyenne Moyen Traiter avant la version L'isolation invité est une attente utilisateur fondamentale
R7 Moyenne Moyen Traiter avant la version Les attaques de proximité physique sont réalistes en appartements et espaces partagés
R8 Moyenne Élevé Traiter avant la version L'accès de débogage est une voie d'échappement de production récurrente
R9 Moyenne Élevé Traiter avant la version La dérive de branches est prévisible quand les versions OEM et FAI se séparent
R10 Moyenne Élevé Traiter avant la version Les flux de revente de routeur et de retour FAI sont prévisibles
R11 Faible Moyen Traiter avant la version Les contrôles dépendant du cloud nécessitent un comportement de repli sûr
R12 Moyenne Élevé Traiter avant la version Les piles de composants de routeur reçoivent des vulnérabilités tout au long de l'assistance
R13 Moyenne Élevé Traiter avant la version La configuration des switches administrables peut affecter de nombreux appareils en aval
R14 Faible Élevé Traiter avant la version La dérive de provisionnement peut exposer la périphérie internet à l'échelle d'une flotte
R15 Moyenne Sévère Traiter avant la version La récupération est une voie privilégiée que les attaquants et les équipes service peuvent atteindre
R16 Moyenne Élevé Traiter avant la version Le comportement radio et maillé change souvent avec les SDK fournisseurs et les révisions matérielles
R17 Moyenne Sévère Traiter avant la version Les erreurs de portée de gestion à distance peuvent affecter des flottes
R18 Moyenne Élevé Traiter avant la version Les retours de routeur, les reventes et les échanges FAI sont des événements normaux du cycle de vie

Cartographie des contrôles et des preuves

Menaces Contrôle de conception Preuve que le fabricant doit conserver
R1, R8 Administration WAN désactivée par défaut, inventaire des services de production, règles de pare-feu pour la gestion, pas de telnet ni shell usine Scans d'exposition, liste de vérification d'image de production, diff de liste des services
R2, R7 Secret de configuration unique ou création forcée d'identifiants, fenêtre d'appariement courte, WPS désactivé ou justifié, limites de débit Test d'intégration, preuves de génération d'identifiants, revue de configuration sans fil
R3 Durcissement des analyseurs, fuzzing, séparation des privilèges de services, posture WAN par défaut de rejet Rapports de fuzzing, conception d'isolation des services, triage des plantages
R4 Authentification mutuelle, rotation de certificats, provisionnement à moindre privilège, revue de profil ACS/USP Revue de sécurité de la gestion à distance, registre du cycle de vie des certificats
R5 Démarrage sécurisé, firmware signé, compteur de version monotone, vérifications de signature de l'image de récupération Rapport de tests OTA, rejet de retour arrière, test de récupération
R6 Isolation du réseau invité, IHM d'administration injoignable depuis l'invité, tests de régression sur les nœuds maillés Test d'isolation réseau, test d'itinérance maillée
R9 Matrice de branches OEM/FAI, politique de fusion de correctifs, approbation de version, alignement de fin d'assistance Matrice de branches, registre de propagation des correctifs, trace d'approbation FAI
R10 Flux de transfert de propriété, désassociation cloud à la remise à zéro, révocation de jetons, effacement des équipements retournés Test de remise à zéro, test de transfert de propriété, liste de vérification RMA
R11 Comportement de repli DNS local, mode de défaillance sûr du contrôle parental, notification utilisateur claire Test de mode de défaillance, preuves de notification utilisateur
R12 Suivi de l'inventaire des composants, réception des avis fournisseurs, propriétaire des composants de firmware, traçabilité des notes de version Diff d'inventaire des composants, journal des avis, registre des décisions de composants
R13 Liaison du plan de gestion, configuration unique d'administration, SNMP/API désactivés ou durcis par défaut, tests d'isolation VLAN Scan d'exposition, test de configuration par défaut, revue de gestion du switch
R14 Profil de provisionnement évalué, restrictions d'administration distante, contrôle des changements opérateur, retour arrière et piste d'audit Registre du profil de provisionnement, audit de configuration de flotte, trace d'approbation opérateur
R15 Récupération authentifiée, image de récupération signée, état anti-retour-arrière, avertissement de récupération physique le cas échéant Test d'abus de récupération, registre de chaîne de démarrage, rejet de retour arrière
R16 Matrice de révisions matérielles, inventaire de firmware Wi-Fi, tests de régression WPS/maillage, revue de domaine réglementaire Matrice de révisions, registre de firmware radio, tests de configuration sans fil
R17 Profil de gestion à distance à moindre privilège, inventaire des certificats de contrôleurs, audit et approbation des commandes Revue de profil TR-069/USP, registre du cycle de vie des certificats, échantillon d'audit
R18 Flux de transfert de propriété, désassociation cloud à la remise à zéro, effacement au retour FAI, révocation de jetons Test de remise à zéro, liste de vérification d'équipement retourné, preuves de désassociation cloud

Risque résiduel après contrôles

Domaine résiduel Pourquoi il subsiste Preuve opérationnelle
Dérive de branches FAI Les approbations de version OEM et FAI peuvent avancer à des rythmes différents Matrice de branches, voie d'escalade, revue de delta de version
Compromission de terminal du foyer Un malware sur un client LAN peut encore attaquer l'administration locale ou les réglages DNS Contrôles d'authentification locaux, révocation de jetons, alertes d'administration
Nouvelles vulnérabilités WAN Le code exposé au WAN continue de recevoir du trafic hostile pendant la période d'assistance Surveillance des exploits, cadence de fuzzing, processus de mise à jour d'urgence
Retard de firmware fournisseur Les fournisseurs Wi-Fi et SoC peuvent publier des correctifs selon leur propre calendrier Registre SLA fournisseur, notes d'atténuation, processus d'avis client

Comment doivent fonctionner le support, les mises à jour et la déclaration ?

Pour l'exemple HomeRouter R1, le dossier CRA pratique doit inclure le modèle opérationnel de la période d'assistance, pas seulement les preuves de version pré-marché.

Domaine opérationnel Preuves à préparer
Période d'assistance Une justification de période d'assistance pour le SKU vente au détail et le SKU sous marque FAI, avec la date de fin en mois/année visible à l'achat et dans l'IHM du routeur lorsque c'est techniquement faisable. Sauf si l'usage attendu est plus court, planifiez au moins cinq ans.
Disponibilité des mises à jour de sécurité Les correctifs firmware de sécurité et les paquets de mises à jour de sécurité restent récupérables pendant au moins 10 ans après publication, ou pour le reste de la période d'assistance si elle est plus longue. Les images de récupération, empreintes, notes de version et décisions de retour arrière doivent être conservées comme preuves, mais tout paquet non lié à la sécurité ne doit pas être décrit comme une obligation légale de disponibilité de 10 ans.
Matrice de branches OEM et FAI Quelle branche de firmware est évaluée, qui la signe, qui approuve la version, qui détient les correctifs d'urgence, et comment les correctifs de sécurité amont atteignent les builds sous marque blanche.
Contact unique pour les vulnérabilités Un contact direct de signalement de vulnérabilité pour le fabricant officiel, pas seulement l'assistance abonné ou un chatbot uniquement automatique. Si un FAI est fabricant pour un SKU sous marque, le FAI détient une voie de réception pour les signalements de sécurité produit.
Diligence sur les composants Suivi de l'inventaire des composants pour noyau, firmware sans fil, services DNS/DHCP, pile TLS, SDK mobiles et agent de gestion à distance, avec triage des avis fournisseurs, notification amont et partage des correctifs lorsque approprié.
Flux d'exploitation active Signalement via la plateforme unique de signalement au CSIRT désigné comme coordinateur et à l'ENISA : alerte précoce sous 24 heures, notification de suivi sous 72 heures, rapport final de vulnérabilité dans les 14 jours après qu'une mesure corrective ou d'atténuation est disponible, et avis aux utilisateurs impactés ou instructions d'atténuation lorsque approprié.
Flux d'incident de sécurité produit grave Signalement via la même plateforme et aux mêmes destinataires : alerte précoce sous 24 heures, notification de suivi sous 72 heures, rapport final d'incident dans un mois après la notification d'incident, et coordination client/FAI incluant l'avis utilisateur lorsque approprié.
Table des matières du dossier produit Identité du produit, schéma de périmètre, actifs WAN/LAN/sans fil, modèle de menaces, registre des risques, contrôles, preuves de tests, inventaire des composants, processus de mise à jour, processus de vulnérabilité, justification de la période d'assistance, instructions, déclaration et registre de la voie de conformité.

Quelles barrières de validation se ferment avant la publication ?

Une publication de routeur ne doit pas passer sur une mention générique « sécurité revue ». Listez les décisions précises qui peuvent retenir l'expédition, et donnez à chacune la défaillance contre laquelle elle protège, le contrôle qui la ferme et l'artefact qui prouve que le contrôle s'exécute effectivement.

Barrières de publication du routeur et registres de clôture Six décisions qu'un fabricant de routeur doit pouvoir clore avant la signature, chacune avec un artefact de preuve nommé.
  1. G1Identifiants à la première utilisationBloquer la publication
    • Défaillance

      Un mot de passe d'administration ou Wi-Fi partagé ou prévisible, ou un secret imprimé réutilisé entre lots.

    • Contrôle

      Secret unique par appareil ou création forcée d'identifiants ; WPS désactivé ou justifié.

    • Preuve

      Test d'intégration et preuves de génération d'identifiants.

  2. G2Exposition WAN après provisionnementBloquer la publication
    • Défaillance

      L'administration distante, ou un service inutile ou non évalué qui analyse des entrées WAN non authentifiées, est joignable avant que l'utilisateur n'ait configuré quoi que ce soit.

    • Contrôle

      Administration WAN désactivée par défaut, posture de rejet par défaut, durcissement des analyseurs et liste de services minimale.

    • Preuve

      Scan d'exposition WAN après provisionnement.

  3. G3Isolation sans fil et invitéBloquer la publication
    • Défaillance

      Le réseau invité peut router vers les appareils LAN ou atteindre l'IHM d'administration.

    • Contrôle

      Isolation invité par défaut ; IHM d'administration injoignable depuis l'invité ; régression sur les nœuds maillés.

    • Preuve

      Test d'isolation réseau et d'itinérance maillée.

  4. G4Voie de mise à jour et récupérationBloquer la publication
    • Défaillance

      OTA ou récupération accepte une image de firmware non signée ou plus ancienne.

    • Contrôle

      Démarrage sécurisé, images signées, compteur de version monotone et rejet de retour arrière.

    • Preuve

      Résultat de test d'échec de retour arrière et d'abus de récupération.

  5. G5Portée de la gestion à distanceBloquer sauf si documenté
    • Défaillance

      La portée des commandes TR-069 ou USP permet au contrôleur de changer plus que le profil opérateur évalué.

    • Contrôle

      Profil à moindre privilège, inventaire des certificats de contrôleurs, audit des commandes.

    • Preuve

      Revue de profil et échantillon d'audit des commandes.

  6. G6Pile fournisseurExpédier avec surveillance
    • Défaillance

      Une vulnérabilité apparaît dans le SDK du SoC, le firmware Wi-Fi ou un démon réseau livré pendant la fenêtre d'assistance.

    • Contrôle

      Inventaire des composants avec propriétaire nommé, suivi des avis et préparation au rétroportage.

    • Preuve

      Décision de triage du composant affecté.

Bloquer la publicationBloquer sauf si documentéExpédier avec surveillance
Chaque barrière de publication associe une défaillance qui arrête l'expédition à l'enregistrement qui la ferme.

Qui prend en charge le développement du routeur du concept à l'assistance ?

La responsabilité d'une publication de routeur change de mains à mesure qu'il passe d'une définition produit à une flotte qui fonctionne dans les foyers des clients et sur les réseaux des FAI. Le couloir ci-dessous donne à chaque phase un responsable principal, le registre tenu à jour par ce responsable, et la barrière qui doit se fermer avant que la phase suivante ne commence.

Couloir de responsabilité pour une publication de routeur sur six phases du concept à l'assistance : concept, conception, firmware, publication, opérations et assistance. Chaque phase nomme le responsable principal, le registre tenu à jour et la barrière de revue. Des marqueurs de gel séparent les phases : gel du périmètre, gel de la conception, gel du candidat, gel de la décision, exploitation continue. Une boucle de retour en pointillés revient de l'assistance au concept, signalant que les signalements de vulnérabilité, les avis FAI et fournisseurs et les résultats de bogues exploités rouvrent la prochaine note de périmètre, liste de menaces et inventaire des composants.
Le couloir de responsabilité affecte le propriétaire de registre, la barrière de clôture et le déclencheur de revue à chaque étape de construction.

Chaque transition est un point de gel : le périmètre est fixé avant que l'architecture ne commence, l'intention de conception avant le code, le build avant la vérification, et la publication avant l'expédition, après quoi le firmware est maintenu en fonctionnement pendant la fenêtre d'assistance. Un signalement de vulnérabilité, un avis FAI ou fournisseur, ou une défaillance terrain rouvre la prochaine note de périmètre, liste de menaces et inventaire des composants plutôt que celle qui a déjà été expédiée.

Quels enregistrements de preuves figurent dans le dossier ?

Le dossier doit permettre à un relecteur de suivre la décision routeur de l'identité du produit aux contrôles de sécurité. Chaque ligne renvoie à un registre tenu à jour, pas à un dossier de captures éparses.

Domaine de preuves Ce qu'il faut capturer pour un routeur, modem-routeur ou switch
Identité du produit Modèle, révisions matérielles, SoC et chipset Wi-Fi, type de WAN, branche de firmware, version d'application mobile, options switch/maillage
Utilisation prévue Routeur domestique, CPE de FAI, modem internet, ONT, kit maillé, hotspot mobile, switch administrable ou routeur VPN, avec les variantes vente au détail et sous marque FAI nommées
Dossier de conception de cyber-résilience Exposition WAN, valeurs par défaut LAN et sans fil, autorité de gestion à distance, voie OTA et récupération, liste de menaces et plan de traitement
Inventaire des composants Chargeur d'amorçage, noyau, firmware Wi-Fi, pile WAN-PHY/modem, service DNS/DHCP, pile TLS, agent de gestion à distance, SDK mobiles, avec propriétaires nommés et suivi des avis
Valeurs par défaut sécurisées Aucun identifiant par défaut partagé, administration WAN désactivée par défaut, mises à jour signées, rejet de retour arrière, isolation invité, ports de débogage verrouillés, inventaire des services après provisionnement
Mécanisme de mise à jour Firmware signé, image de récupération, état anti-retour-arrière, carte des branches FAI/OEM, notification utilisateur de mise à jour
Gestion des vulnérabilités Politique de divulgation, point de contact unique, flux de triage, suivi des avis de composants, acheminement des avis FAI/marque blanche
Instructions utilisateur Intégration sécurisée, configuration du mot de passe et du réseau invité, paramètres de mise à jour, divulgation de fin d'assistance, mise hors service et remise à zéro
Traçabilité et contact Informations de type/lot/série, contact du fabricant ou du FAI, date de fin de période d'assistance et contact unique de signalement de vulnérabilité qui n'est pas seulement un bot automatisé

Qu'est-ce qui entre dans un inventaire des composants de routeur ?

Le CRA exige un inventaire des composants lisible par machine qui identifie les composants du produit et couvre au moins les dépendances de premier niveau, sans nommer encore un format fixe. Les fabricants de routeurs choisissent normalement CycloneDX ou SPDX. Le détail transversal sur la mécanique de l'inventaire des composants figure dans le guide SBOM dédié ; cette section couvre l'arbre propre au routeur.

Une publication de routeur livre plusieurs éléments numériques avec des cycles de mise à jour séparés, pas un binaire unique. Deux modèles répondent au minimum CRA : un inventaire des composants au niveau produit avec sections par élément (chargeur d'amorçage, noyau, firmware Wi-Fi, pile WAN-PHY, démons réseau, TLS, agent de gestion à distance et IHM web, chacun épinglé en version), ou un inventaire par élément livré rafraîchi à chaque version. L'un ou l'autre convient s'il est lisible par machine et couvre les dépendances de premier niveau.

Arbre enraciné de gauche à droite de l'inventaire des composants pour une publication de routeur. La racine est la publication du routeur. Huit branches atteignent les éléments numériques de premier niveau qui sont livrés dans un routeur : chargeur d'amorçage et chaîne de démarrage sécurisé, noyau et système d'exploitation, firmware Wi-Fi, pile WAN-PHY et modem, démons réseau, bibliothèque TLS, agent de gestion à distance, et IHM web d'administration. Chaque branche liste des composants typiques en feuilles d'exemple, et un badge à droite nomme le schéma d'identifiant (PURL, CPE, ID fournisseur, signature ou empreinte de compilation). Une note en pied de page rappelle le minimum CRA : dépendances de premier niveau dans un format couramment utilisé et lisible par machine tel que CycloneDX ou SPDX.
L'inventaire des composants doit couvrir chaque élément numérique de premier niveau, son contenu habituel et la preuve de version associée.

Que vérifie la signature de version ?

La signature avant la publication UE doit pouvoir fermer quatre dossiers d'enregistrements, indiqués Q1 à Q4 ci-dessous. L'index complet du dossier figure dans la carte des preuves plus haut ; les quatre questions ici sont seulement celles qui bloquent la publication quand un dossier est vide.

Dossier Question de publication Renvoi de preuves propre au routeur
Q1 Note de justification de classification Pourquoi ce produit est-il classé ainsi ? Fonction principale (routage et connectivité internet), utilisation prévue, arguments commerciaux, variante vente au détail vs FAI et voie de conformité choisie
Q2 Inventaire des éléments livrés Qu'est-ce que le produit exactement ? Matériel du routeur, firmware, services WAN/LAN/sans fil, IHM web, agent de gestion à distance, service OTA, points cloud et systèmes client/FAI exclus
Q3 Paquet de tests des valeurs par défaut sécurisées Qu'est-ce qui a été sécurisé par défaut et comment sera-t-il mis à jour en toute sécurité ? Aucun identifiant par défaut partagé, administration WAN désactivée par défaut, mises à jour signées, rejet de retour arrière, isolation invité, décision WPS, ports de débogage verrouillés, inventaire des services après provisionnement
Q4 Processus de gestion des vulnérabilités Comment les vulnérabilités et incidents graves seront-ils gérés après l'expédition ? Contact public, politique de divulgation, flux de triage, suivi des avis de composants, acheminement des avis FAI/marque blanche, préparation aux notifications à 24 heures et 72 heures
Scène de signature de version. Quatre dossiers d'enregistrements sont posés sur le bureau de revue, étiquetés Q1 à Q4 : Q1 note de justification de classification, Q2 inventaire des éléments livrés, Q3 paquet de tests des valeurs par défaut sécurisées et Q4 processus de gestion des vulnérabilités. Des flèches partant de chaque dossier convergent vers un sceau d'approbation de version marqué d'une coche. Une note liste les vérifications préalables : dossiers épinglés à la branche de firmware et à la ligne de base fournisseur, propriétaire nommé avec préparation aux notifications à 24 heures et 72 heures, et un paquet de tests des valeurs par défaut sécurisées couvrant les identifiants par appareil et la posture d'administration WAN. Une note en pied de page rappelle la barrière : si un enregistrement manque, la publication ne sort pas.
Evidence: épinglez chacun des quatre enregistrements à la version exacte de firmware qu'il signe, de sorte que la même publication puisse être rouverte plus tard sans avoir à reconstituer la réponse.
Avant la signature, le fabricant doit pouvoir pointer quatre enregistrements : justification de classification, inventaire des éléments livrés, tests des valeurs par défaut sécurisées et préparation à la gestion des vulnérabilités.

Dossiers de signature de version Q1 à Q4

  1. Q1 Note de justification de classification. Pourquoi Classe I point 12 ? Fonction principale, utilisation prévue, arguments commerciaux, variante vente au détail vs FAI et voie de conformité choisie.
  2. Q2 Inventaire des éléments livrés. Matériel du routeur, firmware, services WAN/LAN/sans fil, IHM web, agent de gestion à distance, service OTA, points cloud et systèmes client/FAI exclus.
  3. Q3 Paquet de tests des valeurs par défaut sécurisées. Aucun identifiant par défaut partagé, administration WAN désactivée par défaut, mises à jour signées, rejet de retour arrière, isolation invité, décision WPS, ports de débogage verrouillés.
  4. Q4 Processus de gestion des vulnérabilités. Contact public, politique de divulgation, flux de triage, suivi des avis de composants et préparation au signalement pour alertes, notifications et rapports finaux.

Barrière de signature : si un enregistrement manque, la publication n'est pas signée.

Comment le routeur se transmet-il à l'importateur, au distributeur, au FAI et à l'opérateur ?

Transfert d'opérateurs économiques pour une publication de routeur. Le paquet de version du fabricant ou OEM voyage le long d'un rail de flux à travers l'acceptation pré-marché de l'importateur, la diligence visible du distributeur, le FAI ou la marque blanche qui peut devenir le fabricant, et l'opérateur ou abonné. Une ligne de conditions d'arrêt nomme les cas qui suspendent l'expédition ou la vente : non-correspondance du paquet, de la traçabilité, de la date d'assistance ou du contact de vulnérabilité, ou une branche de firmware ou un profil de gestion à distance différent du build évalué. La vérification latérale A explique que le mandat du mandataire est optionnel et qu'un fabricant non-UE sans mandataire utilise la cascade importateur, distributeur et plus grand nombre d'utilisateurs. La vérification latérale B explique qu'un importateur ou distributeur sous marque propre, ou un modificateur substantiel tel qu'un fork de firmware sous marque ou un nouveau cloud de gestion, devient le fabricant pour cette offre.
La carte de transfert montre qui détient chaque vérification pré-vente et ce qui arrête le routeur à chaque rôle.

Transfert d'opérateurs économiques : rôles et vérifications latérales

  1. 01 Fabricant / OEM. Détient le paquet de version : déclaration, marquage CE, index du dossier, fenêtre d'assistance et contact de vulnérabilité.
  2. 02 Importateur. Vérifie le paquet, le marquage CE, l'index du dossier, la date d'assistance et le contact de vulnérabilité, et confirme que le build reçu est le build évalué : réglages pays sans fil, profils FAI, certificats de gestion à distance, appariement applicatif et points OTA. Suspend l'expédition si l'un d'eux est douteux.
  3. 03 Distributeur. Vérifie le marquage CE visible, les documents fournis, les déclarations d'assistance et de mise à jour, et n'ajoute pas d'affirmations telles que « passerelle de sécurité », « pare-feu professionnel » ou « équipement VPN administré » qui sortent du périmètre évalué. Suspend la mise en vente si elle survend l'assistance, ne correspond pas à la déclaration ou continue après divulgation d'un problème connu.
  4. 04 FAI ou marque blanche. Marque, gestion cloud, propriété des mises à jour et exploitation de la gestion à distance peuvent à elles seules déclencher des obligations de fabricant. Placer le routeur sous son propre nom, ou le modifier substantiellement (firmware sous marque, nouveau cloud, nouveau canal de mise à jour), en fait le fabricant pour cette offre, donc le dossier fournisseur ne remplace pas sa propre analyse de rôle.
  5. 05 Opérateur ou abonné. Reçoit avis et mises à jour et remonte les problèmes. Pas fabricant.

Vérification latérale A. Le mandat du mandataire est optionnel, mais lorsqu'il existe il doit être écrit et couvrir la conservation de la déclaration et de la documentation et la coopération avec les autorités. Un fabricant non-UE sans mandataire utilise la cascade : importateur, distributeur, puis plus grande base d'utilisateurs. Sans opérateur établi dans l'Union dans la chaîne de signalement, le point de signalement revient à l'État membre où se trouvent le plus d'utilisateurs.

Vérification latérale B. Un importateur ou distributeur sous marque propre, ou tout modificateur substantiel, devient le fabricant pour l'offre concernée.

Questions fréquentes

Un routeur est-il en Classe II parce qu'il a un pare-feu ?

Pas par défaut. Un routeur normal est généralement Important Classe I. Il devient une question Classe II lorsque pare-feu, détection ou prévention d'intrusion est la fonction principale du produit.

Un routeur fourni par le FAI est-il couvert ?

Oui, s'il est mis sur le marché de l'UE comme produit comportant des éléments numériques. La question pratique clé est de savoir qui est le fabricant pour le firmware sous marque, la période d'assistance, le canal de mise à jour et le processus de vulnérabilité.

Un routeur est-il Critique ?

Non. Les routeurs grand public, les modems-routeurs FAI et les switches ne sont pas Critiques au seul motif qu'ils sont importants pour l'accès au réseau.

Le firmware de routeur open source commercial change-t-il la réponse ?

Cela peut. Une image de firmware ou une distribution d'équipement fournie commercialement peut elle-même être un produit comportant des éléments numériques. Le fabricant doit documenter ce qui est mis sur le marché et qui détient les mises à jour et la gestion des vulnérabilités.

Si le logiciel se qualifie réellement comme logiciel libre et open source et entre dans une catégorie Importante, le CRA prévoit une option de conformité spécifique où la documentation technique requise est publique lors de la mise sur le marché. N'appliquez pas cette voie à un fork privé de firmware FAI ou à un équipement commercial au seul motif qu'il inclut des paquets open source.

Atteindre la date limite cybersécurité RED signifie-t-il qu'un routeur est déjà conforme CRA ?

Non. Depuis le 1 août 2025, les équipements radio connectés à internet respectent les exigences de cybersécurité de la directive sur les équipements radioélectriques, et ces contrôles (valeurs par défaut sécurisées, intégrité des mises à jour, protection d'accès) sont le bon socle. Mais le CRA ajoute un cycle de vie plus large : un processus documenté de gestion des vulnérabilités, une date de fin de période d'assistance publiée, une sécurité par défaut sur l'ensemble du produit et des obligations de signalement. Le règlement délégué cybersécurité RED est abrogé à compter du 11 décembre 2027, date à laquelle le CRA prend le relais.

Déclencheur de revérification : traitez le dossier RED comme point de départ et évaluez les écarts par rapport aux exigences essentielles du CRA avant le 11 décembre 2027.

Quelle norme harmonisée s'applique à un routeur au titre du CRA ?

Pour la phase équipements radio, l'ensemble harmonisé est la série EN 18031, s'appuyant sur ETSI EN 303 645 comme socle grand public. La norme CRA propre aux routeurs en préparation est ETSI EN 304 627 (routeurs, modems et switches), qui correspond à la Classe I point 12. C'est encore un projet, donc confirmez les normes citées et toute restriction d'harmonisation au moment de l'évaluation.

Registre de conformité : une courte note nommant les normes invoquées, la version, toute restriction qui ne convient pas au produit, et la voie de conformité résultante.

Un switch administrable est-il traité comme un routeur, et un switch non administrable est-il dans le champ ?

Un switch administrable a un plan de gestion (IHM web, CLI, SNMP/API, VLAN) et une voie de mise à jour de firmware, il est donc normalement traité comme équipement réseau Important Classe I avec ses propres preuves de plan de gestion. Un switch purement non administrable, non configurable, sans surface de gestion, sans mise à jour de firmware et sans fonction connectée nécessite une vérification cas par cas pour savoir s'il est un produit comportant des éléments numériques tout court.

Registre de périmètre : une note d'une ligne par SKU de switch indiquant s'il existe une surface de gestion ou de mise à jour.

Les kits Wi-Fi maillés sont-ils un produit ou plusieurs ?

Les nœuds maillés qui forment un système sont normalement le produit routeur ou la famille de produits. Évaluez le kit tel qu'il est livré : le nœud contrôleur, les nœuds satellites, le flux d'intégration et le protocole de contrôle maillé. La confiance entre nœuds et la poignée de main d'intégration font partie de la surface d'attaque sans fil.

Registre de périmètre : nommez les nœuds du kit, le protocole de contrôle maillé et la méthode d'intégration dans la note de périmètre.

Un modem ou ONT autonome est-il couvert s'il ne fait que faire le pont ?

Un modem, modem câble ou ONT fibre destiné à la connexion internet est normalement Important Classe I, même en mode pont, parce que la fonction de modem internet est la fonction principale du produit et que l'équipement a toujours du firmware, un canal de provisionnement et souvent un agent de gestion à distance. Le mode pont versus routeur change l'exposition, pas la classification de base.

Registre de périmètre : consignez le canal de provisionnement, l'agent de gestion à distance et si le mode pont ou routeur est la valeur par défaut évaluée.

Un hotspot mobile 4G ou 5G est-il dans le champ ?

Oui. Le WAN cellulaire reste de la connectivité internet, donc un hotspot mobile ou un routeur 4G/5G est normalement Important Classe I. La voie de provisionnement cellulaire et la gestion SIM/eSIM font partie de la surface d'attaque WAN.

Registre de périmètre : nommez le module cellulaire, la voie de provisionnement et le canal de gestion.

Combien de temps un routeur doit-il être pris en charge et mis à jour ?

La période d'assistance est d'au moins cinq ans sauf si la durée d'utilisation attendue est inférieure ; beaucoup de routeurs et de CPE FAI fonctionnent bien plus longtemps, donc le dossier doit nommer une fenêtre que le fabricant peut effectivement tenir et montrer la date de fin avant l'achat. Les mises à jour de sécurité doivent rester récupérables pendant au moins dix ans après publication, ou pour le reste de la période d'assistance si elle est plus longue. Les règles générales figurent dans les guides période d'assistance et divulgation de fin d'assistance.

Registre d'assistance : une justification de période d'assistance pour le SKU vente au détail et le SKU sous marque FAI, avec la date de fin visible à l'achat et dans l'IHM du routeur lorsque c'est faisable.

Qu'est-ce qu'une mise à jour sécurisée pour un routeur ?

Une image de firmware signée, vérifiée via une chaîne de démarrage sécurisé, avec un compteur de version monotone pour qu'un build vulnérable plus ancien ne puisse pas être réinstallé, et une voie de récupération qui rejette aussi les images non signées ou rétrogradées. Les mises à jour poussées par le FAI et celles de l'OEM doivent toutes deux suivre cette voie.

Artefact de test : un journal de vérification de mise à jour signée, un test d'échec de retour arrière et un test d'abus de récupération pour le build de firmware exact.

La gestion à distance TR-069 ou USP change-t-elle le périmètre du produit ?

Si le fabricant ou le FAI fournit le canal de gestion à distance, il est à l'intérieur du périmètre et constitue une voie de contrôle de flotte, pas seulement une fonctionnalité opérateur. Le serveur d'auto-configuration de l'opérateur, le mécanisme de requête de connexion, la portée des commandes et la confiance des certificats appartiennent tous à l'évaluation.

Evidence : un inventaire des certificats de contrôleurs et une matrice de portée des commandes liés au profil opérateur évalué.

Qui est le fabricant pour un CPE sous marque FAI ?

Quiconque met le produit sur le marché sous son propre nom ou marque, ou modifie substantiellement le produit évalué. Un FAI qui remarque du matériel OEM, forke le firmware, exploite le cloud de gestion ou détient le canal de mise à jour peut endosser les obligations de fabricant pour ce SKU sous marque, y compris le contact de signalement de vulnérabilité.

Registre de rôle : une répartition écrite de qui détient la déclaration, la branche de firmware, le canal de mise à jour, la période d'assistance et le contact de signalement.

Quelle est la première preuve qu'un fabricant de routeur doit créer ?

Une courte note de classification et de périmètre pour le SKU exact : routeur, modem-routeur, kit maillé, switch, hotspot ou routeur VPN. Nommez le type de WAN, la pile sans fil, la surface d'administration LAN, le canal de gestion à distance, les services cloud, la propriété des mises à jour, la période d'assistance et les systèmes exclus.

Registre de classification : une note d'une page que l'évaluation des risques, le choix de la voie de conformité, le paquet importateur et la déclaration de période d'assistance peuvent tous référencer.

Que faire si une vulnérabilité est découverte dans le firmware de routeur après publication ?

Prenez des mesures correctives immédiatement et soyez prêt à la séquence de signalement : une alerte précoce à 24 heures pour une vulnérabilité activement exploitée, une notification à 72 heures, un rapport final lorsqu'une mesure corrective ou d'atténuation est disponible, et une notification utilisateur. Pour un routeur, la mesure corrective est généralement une mise à jour de firmware signée poussée à travers les branches OEM, FAI et marque blanche, avec une exception documentée lorsqu'une branche ne peut pas prendre le même correctif. La mécanique générale de signalement figure dans les guides gestion des vulnérabilités et divulgation coordonnée des vulnérabilités.

Registre d'action corrective : modèles et branches de firmware affectés, artefact de mise à jour signée, trace de propagation par branche, texte d'avis utilisateur et référence de notification.

Quand l'évaluation des risques du routeur doit-elle être mise à jour ?

Chaque fois qu'un routeur expédié change d'une manière qui déplace une frontière de confiance : un nouveau type de WAN, un nouveau profil de gestion à distance, un changement de SDK Wi-Fi ou SoC, une nouvelle dépendance cloud, un changement d'intégration maillée, un changement de comportement de port de débogage ou une nouvelle branche FAI. Une note de version ne suffit pas si le changement rouvre une exposition ou une voie d'autorité. Les obligations de signalement s'appliquent à compter du 11 septembre 2026, donc la politique de divulgation et le contact unique doivent fonctionner avant cette date.

Déclencheur de revérification : tout changement d'exposition WAN, de valeurs par défaut sans fil, de portée de gestion à distance, de voie de mise à jour, de composants fournisseurs ou de branche FAI rouvre la note de périmètre et l'évaluation des risques.

Étapes suivantes

Commencez par la note de périmètre au niveau SKU : routeur, modem-routeur, kit maillé, switch, routeur VPN ou variante pare-feu. Ensuite, cartographiez firmware, pile sans fil, gestion à distance, services cloud, composants fournisseurs, propriété des mises à jour et période d'assistance dans le dossier produit ; la structure transversale de ce dossier figure dans le guide de documentation technique.