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
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.
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.
| 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.
À 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.
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.
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
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
Avis fournisseurs, suivi des versions de SDK, propriété des branches de firmware, triage CVE des composants et preuves de propagation des correctifs.
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.
Branche source, version du SDK, firmware Wi-Fi, noyau et clé de signature sont le socle de départ.
Point ACS/USP, marque, configuration par défaut, flux d'approbation et propriétaire de la notification utilisateur sont documentés.
Application mobile, appariement cloud, service maillé et déclaration de période d'assistance restent sous le processus de version du fournisseur.
Suivez si les branches OEM, FAI et marque blanche ont reçu le même correctif de sécurité ou une exception documentée.
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.
- 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.
- Défaillance
- 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.
- Défaillance
- 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.
- Défaillance
- 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.
- Défaillance
- 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.
- Défaillance
- 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é.
- Défaillance
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.
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.
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 |
Dossiers de signature de version Q1 à Q4
- 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.
- 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.
- 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.
- 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 : rôles et vérifications latérales
- 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é.
- 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.
- 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.
- 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.
- 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.