Guía de cumplimiento CRA Clase I: routers, módems y switches
Resumen
Un router Wi-Fi doméstico, un router-módem, un módem de internet, un nodo de red mesh o un switch debería planificarse normalmente como producto Clase I importante. La salvedad es la función principal: un router comercializado sobre todo como firewall, IDS/IPS, pasarela VPN o aparato de gestión de red puede necesitar un análisis de categoría distinto.
La primera acción de evidencia es un memorando de clasificación y límites para el CPE o dispositivo de red exacto. Debe identificar el hardware, el firmware, la interfaz WAN, la pila inalámbrica, la interfaz de administración LAN, la app móvil, la nube del ISP o del proveedor, el canal de gestión remota, el mecanismo de actualización, el inventario de componentes, el periodo de soporte y cualquier modificación de firmware por marca blanca o por el ISP.
| Variante de producto | Clase CRA probable | Por qué |
|---|---|---|
| Router Wi-Fi de consumo | Clase I importante | La conectividad a internet y el enrutado son la función principal |
| Módem-router o CPE del ISP | Clase I importante | El producto conecta a los clientes a internet |
| Módem independiente de cable, DSL o fibra / ONT | Clase I importante cuando está destinado a la conexión a internet | La función de módem de internet es la función principal del producto |
| Kit Wi-Fi mesh | Clase I importante | Los nodos mesh forman el producto router o la familia de productos |
| Punto de acceso móvil 4G/5G | Clase I importante | La WAN celular sigue siendo conectividad a internet |
| Switch gestionable | Clase I importante | La conmutación más un plano de gestión encaja en la función de producto de red y amplía el límite de evidencia |
| Switch no gestionable o no configurable | Caso por caso | Comprueba si es un producto con elementos digitales y si existe algún plano de gestión, ruta de actualización de firmware, función en nube o app, o cualquier otra función conectada antes de tratarlo como equipo de red gestionado |
| Router VPN | Caso por caso, normalmente Clase I importante | La VPN puede ser la función más específica si así se comercializa |
| Router comercializado como firewall, UTM o IPS | Caso por caso, posiblemente Clase II importante | El firewall o la prevención pueden pasar a ser la función principal |
| Firmware comercial de router vendido por separado | Caso por caso | El propio software puede ser el producto router |
| CPE con marca del ISP sobre hardware OEM | Clase I importante, sensible al rol | El marcado de marca blanca o los cambios de firmware pueden desplazar los deberes del fabricante |
Base de la clasificación
La CRA trata routers, módems de internet y switches como productos Clase I importantes, lo que no es lo mismo que el estado de firewall Clase II. Las funciones de seguridad adicionales no mueven un router a Clase II mientras el enrutado y la conectividad a internet sigan siendo su función principal comercializada.
El producto no es Crítico solo por estar en el borde de la red. La lista Crítica es más estrecha y no incluye los routers de consumo ni los CPE del ISP en su conjunto.
¿Qué cuenta como producto router?
Un producto router, módem o switch puede incluir más que la carcasa de plástico:
- gestor de arranque, sistema operativo, núcleo, controladores inalámbricos, pila WAN y servicios LAN;
- módem, ONT, silicio de switch Ethernet, comportamiento de la VLAN de gestión y control PoE cuando exista;
- interfaz web de administración, emparejamiento por app móvil y portal de configuración local;
- TR-069, USP/TR-369 u otro canal de gestión remota;
- nube del proveedor o del ISP usada para acceso remoto, controles parentales, telemetría, coordinación mesh u orquestación de actualizaciones;
- servicio de actualización de firmware, claves de firma, imagen de recuperación y proceso de soporte.
El expediente de evidencia también debe registrar lo que queda fuera del producto: la cuenta de ISP del cliente, los dispositivos de hogar inteligente de terceros, las reglas de red creadas por el usuario, el módem del usuario cuando se vende por separado y los sistemas del operador aguas abajo que no suministra el fabricante.
¿Qué ruta de conformidad debería planificar el fabricante?
Clase I importante no implica automáticamente que todo router necesite evaluación por tercero, pero tampoco se debe asumir el control interno. Si el fabricante puede usar la ruta general de control interno y ha aplicado plenamente las normas armonizadas pertinentes, las especificaciones comunes o un esquema europeo de certificación de ciberseguridad apropiado con nivel de garantía al menos sustancial para los requisitos esenciales aplicables, puede estar disponible. Si esas referencias no existen, solo se aplican parcialmente, no se aplican o no cubren todos los requisitos pertinentes, planifica el examen UE de tipo más control interno de producción, o el aseguramiento total de la calidad. La mecánica general de la ruta y lo que debe contener la declaración UE de conformidad viven en las guías de evaluación de la conformidad y declaración de conformidad; esta página cubre solo la elección específica del router.
Si la misma variante de hardware también se comercializa como firewall, pasarela VPN, aparato de gestión de red o plataforma de seguridad gestionada, crea un memorando de clasificación separado para ese SKU.
¿Cómo se relaciona el plazo de ciberseguridad de la RED con la CRA?
La mayoría de routers y módems conectados a internet contienen una radio (Wi-Fi, un módem celular o similar), y ese subconjunto con radio ya ha cruzado una puerta de ciberseguridad antes de la llegada de la CRA. Desde el 1 de agosto de 2025 los requisitos de ciberseguridad de la Directiva de Equipos Radioeléctricos (RED Artículo 3.3 puntos d, e y f, fijados por el Reglamento Delegado (UE) 2022/30) se aplican a los equipos radioeléctricos conectados a internet, como routers Wi-Fi, nodos mesh, módems-router y pasarelas celulares. Un dispositivo puramente cableado, como un router solo Ethernet o un módem DSL, cable o fibra sin radio, queda fuera del ámbito de ciberseguridad de la RED, pero todos ellos siguen siendo productos con elementos digitales bajo la CRA. Los deberes de notificación de la CRA empiezan el 11 de septiembre de 2026 y la CRA es plenamente aplicable el 11 de diciembre de 2027, cuando la derogación por parte de la Comisión del Reglamento Delegado de ciberseguridad de la RED, mediante el Reglamento Delegado (UE) 2026/339, surte efecto para que ambos regímenes no se solapen.
Para un fabricante de routers la lectura práctica es:
- Entre el 1 de agosto de 2025 y el 10 de diciembre de 2027, los equipos radioeléctricos aplicables cumplen los requisitos de ciberseguridad de la RED; la ruta armonizada pasa por la serie EN 18031, con ETSI EN 303 645 como línea base de consumo sobre la que se construye.
- Desde el 11 de diciembre de 2027 los mismos deberes de ciberseguridad pasan a la CRA, con sus obligaciones más amplias de ciclo de vida: configuración segura por defecto, proceso de gestión de vulnerabilidades, declaración del periodo de soporte y los deberes de notificación que ya empiezan el 11 de septiembre de 2026.
- Un router ya introducido en el mercado antes del 11 de diciembre de 2027 entra en el ámbito de la CRA solo si se modifica sustancialmente después de esa fecha. La única excepción es el deber de notificación, que se aplica a todos los productos en el ámbito, incluidas las unidades ya vendidas.
- La norma armonizada de la CRA específica para routers en preparación es ETSI EN 304 627 (Routers, módems y switches), que se asigna a Clase I punto 12 y a los requisitos esenciales de ciberseguridad. Sigue siendo borrador, así que planifica la ruta de conformidad sobre las normas efectivamente citadas en el momento, y reutiliza los controles construidos para la RED (valores seguros por defecto, actualizaciones firmadas, control de acceso) como base del expediente CRA en lugar de iniciar un proyecto aparte.
¿Qué evidencia debe estar preparada?
| Área de evidencia | Qué capturar para un router o un router-módem | Por qué importa |
|---|---|---|
| Finalidad prevista | Router doméstico, CPE del ISP, módem, ONT, sistema mesh, punto de acceso móvil, switch, router VPN, switch gestionable | La clase sigue a la variante real del producto y a las afirmaciones |
| Superficie de ataque WAN | DHCP, PPPoE, IPv6, proxy DNS, NAT, valores por defecto del firewall, postura de administración remota | El lado WAN recibe tráfico no fiable antes de que el usuario haya configurado nada |
| Administración LAN | Interfaz web, API local, portal de configuración, política de contraseñas, recuperación de cuenta, controles de acceso | Aquí ocurren la mayoría de errores de configuración y propiedad |
| Inalámbrico | Valores por defecto WPA2/WPA3, decisión sobre WPS, aislamiento de invitados, alta de SSID/contraseña, firmware del chip Wi-Fi | Los valores inalámbricos por defecto se convierten en los valores de seguridad del hogar |
| Gestión remota | TR-069, USP/TR-369, nube del proveedor, nube del ISP, acceso remoto desde app móvil | Suele ser la diferencia entre un equipo aislado y un producto gestionado en flota |
| Ruta de actualización | Firmware firmado, protección anti-retroceso, versiones empujadas por el ISP, partición de recuperación, aviso de actualización | Las actualizaciones del router deben cubrir el periodo de soporte y sobrevivir a las ramas OEM/ISP |
| Evidencia de proveedores | SDK del SoC, proveedor Wi-Fi/banda base, gestor de arranque, núcleo, pila TLS, servicios DNS/DHCP | Los fabricantes de routers heredan una superficie amplia de componentes de terceros |
| Evidencia de roles | Responsabilidades de OEM, ISP, importador, distribuidor y marca blanca | El CPE con marca y las bifurcaciones de firmware pueden cambiar quién es titular del expediente CRA |
¿Qué detalles de la arquitectura del router no deberían pasarse por alto?
La evidencia del router tiene que seguir al dispositivo de borde que realmente se envía. Un router Wi-Fi de retail, un router-módem del ISP, una ONT PON, un módem de cable, un punto de acceso móvil, un nodo mesh y un switch gestionable tienen distintos riesgos de exposición WAN, gestión remota y rama de firmware.
| Punto de control de arquitectura | Pregunta de evidencia para router, módem o switch |
|---|---|
| Cadena de arranque y recuperación | Identifica la ROM de arranque, el gestor de arranque, el estado de arranque seguro, la imagen A/B o de banco único, el disparador de recuperación, el contador anti-retroceso y el comportamiento de reseteo de fábrica. Conserva las pruebas de abuso de retroceso y recuperación. |
| WAN y aprovisionamiento | Aprovisionamiento separado para WAN Ethernet, PPPoE, DHCP, IPv6, DOCSIS/PON/celular y los perfiles del operador. Muestra qué servicios procesan entradas WAN no autenticadas antes de que exista la interfaz de administración. |
| Capa Wi-Fi y banda base | Sigue los blobs de firmware Wi-Fi, la configuración de dominio regulatorio, los forks de hostapd/wpa_supplicant, la decisión sobre WPS y el alta mesh. El firmware del proveedor entra en la lista de seguimiento de avisos. |
| Gestión remota | Para TR-069/CWMP, USP/TR-369, nube del proveedor o nube del ISP, registra la identidad del controlador, la confianza de certificado, el comportamiento de solicitud de conexión, el alcance de comandos y la auditabilidad. |
| Control de switch y mesh | La interfaz del switch gestionable, SNMP/API, las VLAN, el espejo de puertos, PoE, EasyMesh o los controladores mesh propietarios necesitan sus propias comprobaciones de exposición del plano de gestión. Para switches no gestionables o no configurables, comprueba primero si existe alguna superficie digital de gestión o actualización. |
| Ramas del ISP y de marca blanca | Mantén una matriz de ramas que muestre la build OEM, el fork del ISP, el perfil de operador, la aprobación OTA, el titular del periodo de soporte y la ruta de aviso al usuario. |
| Fabricación y devoluciones | Registra los secretos por dispositivo, las credenciales impresas, la política de shell de depuración, el estado UART/JTAG, el borrado RMA y la desvinculación en nube. |
El lado WAN es donde el dispositivo procesa por primera vez entradas no autenticadas, y ese lado cambia con la tecnología de acceso. Un router de retail con WAN Ethernet, un router-módem de cable, una ONT de fibra y un punto de acceso celular no comparten el mismo canal de aprovisionamiento ni el mismo par aguas arriba.
¿Cómo es una evaluación de riesgos real de un router?
Úsalo como ejemplo de la profundidad esperada en una evaluación de riesgos del archivo del producto. El fabricante sigue teniendo que ejecutar la evaluación contra el router real, el chipset del módem, la pila inalámbrica, el canal de gestión remota, los SDK de proveedor, la titularidad de la actualización, las afirmaciones de venta y la promesa del periodo de soporte.
Perfil de producto de ejemplo
Producto de ejemplo: ExampleCo HomeRouter R1, un router doméstico Wi-Fi 7 vendido en la UE a través de canales de retail y marca blanca del ISP. Tiene WAN Ethernet, cuatro puertos LAN, Wi-Fi de invitados, una interfaz web local de administración, alta desde app móvil, gestión remota opcional del ISP, OTA de firmware firmado, comprobaciones automáticas de actualización, servicios DNS/DHCP, perfiles de control parental y una imagen de recuperación.
El límite del producto incluye el hardware del router, el gestor de arranque, el núcleo, los controladores Wi-Fi, los servicios WAN, los servicios LAN, los valores por defecto del firewall, la interfaz web local, el emparejamiento por app móvil, la nube del proveedor para acceso remoto, el agente opcional de gestión remota del ISP, el servicio OTA, la imagen de recuperación, el sitio web de soporte, la entrada de divulgación coordinada y el proceso de avisos. Excluye el módem del cliente cuando se vende por separado, la suscripción al ISP, los dispositivos de hogar inteligente de terceros, el proveedor de identidad del usuario y los sistemas OSS/BSS del ISP aguas abajo, salvo que el mismo operador económico los suministre como parte del producto.
Documenta los supuestos sobre el uso doméstico esperado, el aprovisionamiento del ISP, la titularidad de administración y los modos de despliegue no soportados.
Archivo del producto | memorando de límite del SKU | archivo de riesgos | DoC | registro CE | declaración del periodo de soporte
Inventario de componentes | inventario de servicios | pruebas de valores inalámbricos por defecto | pruebas de actualización segura | revisión de gestión remota
Avisos del proveedor, registro de versiones del SDK, titularidad de la rama de firmware, triaje de CVE por componente y evidencia de propagación de parches.
Conserva la matriz de ramas, el registro de versiones de actualización, la trazabilidad de aprobaciones del ISP, el registro de avisos y el registro de decisión de notificación para vulnerabilidades explotadas activamente o incidentes graves de seguridad.
La rama fuente, la versión del SDK, el firmware Wi-Fi, el núcleo y la clave de firma son la línea base de partida.
El endpoint ACS/USP, la marca, la configuración por defecto, el flujo de aprobación y el titular del aviso al usuario quedan documentados.
La app móvil, el emparejamiento en nube, el servicio mesh y la declaración del periodo de soporte se mantienen bajo el proceso de versión del proveedor.
Sigue si las ramas OEM, ISP y de marca blanca recibieron la misma corrección de seguridad o una excepción documentada.
Inventario de activos
| Activo | Por qué importa | Dónde reside |
|---|---|---|
| Control de tráfico WAN-a-LAN | Controla la exposición del hogar a internet | NAT, valores por defecto del firewall, red del núcleo |
| Cuenta de administración y sesiones del router | Concede control sobre DNS, Wi-Fi, redirección de puertos, actualizaciones y reseteo | Interfaz web, app móvil, almacén local de tokens, cuenta en nube |
| Credenciales Wi-Fi y aislamiento de invitados | Los valores por defecto débiles exponen la red doméstica y los dispositivos conectados | Configuración Wi-Fi, flujo de alta, reglas de la red de invitados |
| Credencial de gestión remota | Una credencial de control de flota puede afectar a muchos routers | Agente TR-069/USP, almacén de certificados, ACS/nube del ISP |
| Ancla de confianza de firma de firmware | Protege el canal de actualización del router | Gestor de arranque, almacenamiento seguro, servicio OTA |
| Configuración DNS/DHCP | Puede redirigir a los usuarios o romper la conectividad | Servicios locales, interfaz de administración, aprovisionamiento del ISP |
| Estado de gestión del switch | Las VLAN, el aislamiento de puertos, el PoE y el acceso de gestión pueden exponer redes aguas abajo | Interfaz del switch gestionable, CLI, SNMP/API, configuración del ASIC del switch |
| Estado de aprovisionamiento del módem/ONT | El registro, el modo puente/router y las credenciales de gestión afectan al borde de internet | Firmware del módem, perfil del operador, agente de gestión remota |
| Registros de soporte y diagnóstico | Pueden revelar SSID, números de serie, IP, vínculos con cuentas de cliente y datos de fallo | Registros del dispositivo, app móvil, portal de soporte |
| Estado de la rama de firmware | El desvío entre ramas ISP/OEM puede dejar vulnerabilidades sin parchear | Sistema Git/release del OEM, fork del ISP, repositorio OTA |
| Estado de arranque seguro y anti-retroceso | Protege la ruta de recuperación e impide que vuelvan imágenes con vulnerabilidades conocidas | Gestor de arranque, estado de eFuse/RPMB/TPM, registros de producción |
| Firmware Wi-Fi/banda base | El firmware de la radio puede afectar a la autenticación, la disponibilidad y la exposición de red | Chip Wi-Fi, blob de firmware, SDK del proveedor, imagen de producción |
Límites de confianza
| Entorno | Exposición esperada | Consecuencia de riesgo |
|---|---|---|
| Interfaz WAN | Expuesta continuamente a tráfico de red no fiable | Fallos del parser y servicios expuestos pueden comprometer el dispositivo |
| LAN y red de configuración | Compartida con equipos del hogar y dispositivos IoT | Atacantes locales pueden ir contra la administración, el descubrimiento y los valores débiles |
| Interfaz inalámbrica | Alcanzable desde proximidad física | WPS, alta débil o fallos de aislamiento de invitados exponen la LAN |
| Plano de gestión del switch | Alcanzable desde la VLAN de administración, la LAN o las herramientas del operador según la configuración | Los valores por defecto débiles pueden exponer VLAN, control PoE o puertos espejo |
| Ruta de gestión remota | Alcanza al dispositivo desde la infraestructura del proveedor o del ISP | La fuga de credenciales o el compromiso del ACS pueden escalar entre muchos routers |
| Ruta OTA y de recuperación | Recibe imágenes de firmware privilegiadas | Una firma débil o el retroceso socavan todas las correcciones de seguridad |
| Rama ISP/marca blanca | Puede alterar firmware, endpoints de nube y periodo de soporte | Los deberes pueden desplazarse cuando una marca controla decisiones de versión y soporte |
Escenarios de amenaza
| ID | Escenario de amenaza | Activo en riesgo | Punto de entrada |
|---|---|---|---|
| R1 | El endpoint de administración WAN está habilitado por defecto o por el perfil del ISP | Cuenta de administración, configuración del router | WAN |
| R2 | La contraseña de primer uso es compartida, predecible o se imprime de forma reutilizada entre lotes | Cuenta de administración, credenciales Wi-Fi | Alta |
| R3 | Un fallo del parser DHCP, IPv6, DNS o PPPoE puede activarse antes de la autenticación | Integridad del router, disponibilidad | Servicios WAN |
| R4 | La credencial TR-069 o USP se filtra y permite cambios de configuración remotos | Credencial de gestión remota, DNS, canal de firmware | Gestión del ISP/proveedor |
| R5 | La recuperación OTA acepta firmware sin firmar o anterior | Integridad del firmware | OTA / recuperación |
| R6 | El Wi-Fi de invitados puede enrutar a dispositivos LAN o a la interfaz de administración | Equipos del hogar, administración del router | Inalámbrico / LAN |
| R7 | El alta por WPS o QR puede abusarse tras la puesta en marcha inicial | Credencial Wi-Fi | Alta inalámbrica |
| R8 | El shell de depuración, telnet, SSH o UART sigue accesible en producción | Integridad del router, secretos | Firmware / físico |
| R9 | El fork de firmware del ISP omite una corrección de seguridad del OEM | Estado de la rama de firmware | Proceso de versión |
| R10 | El token de acceso remoto de la app móvil sigue siendo válido tras la transferencia o reseteo de fábrica del router | Cuenta de administración, propiedad | Nube / app |
| R11 | Un fallo en la nube de DNS o control parental crea un comportamiento de respaldo inseguro | Integridad DNS, disponibilidad | Dependencia de nube |
| R12 | Una vulnerabilidad del proveedor en el SDK del SoC, el firmware Wi-Fi o un demonio de red empaquetado no se triada durante el soporte | Integridad del router, disponibilidad | Componente del proveedor |
| R13 | La interfaz del switch gestionable o SNMP/API se expone en la LAN del usuario con credenciales por defecto débiles | Estado de gestión del switch, integridad de VLAN | LAN / plano de gestión |
| R14 | El perfil de aprovisionamiento del módem o ONT habilita administración remota o comportamiento de modo puente fuera del estado de versión evaluado | Estado de aprovisionamiento del módem/ONT, exposición WAN | Aprovisionamiento del operador |
| R15 | El modo de recuperación, el arranque con reseteo mantenido o la recuperación TFTP aceptan una imagen no autenticada o degradada | Integridad del firmware, estado de arranque seguro | Gestor de arranque / recuperación |
| R16 | El firmware Wi-Fi, el alta mesh o el comportamiento WPS difieren entre revisiones de hardware sin evidencia de versión | Credenciales Wi-Fi, aislamiento de invitados | Inalámbrico / SDK del proveedor |
| R17 | El alcance de comandos USP/TR-369 o TR-069 permite más de lo previsto por el perfil de operador | Credencial de gestión remota, DNS, OTA | Gestión del ISP/proveedor |
| R18 | La vinculación de app o el token de propiedad en nube sobreviven al reseteo de fábrica o a la devolución al ISP | Cuenta de administración, propiedad | Reseteo / cuenta en nube |
Registro de riesgos inicial
| ID | Probabilidad | Impacto | Decisión inicial | Razonamiento |
|---|---|---|---|---|
| R1 | Baja | Alto | Tratar antes de la versión | La exposición de administración remota da control directo y es fácil de escanear |
| R2 | Media | Alto | Tratar antes de la versión | Los hogares suelen mantener los valores por defecto salvo que el alta fuerce el cambio |
| R3 | Media | Alto | Tratar antes de la versión | Los parsers WAN quedan expuestos antes de la autenticación |
| R4 | Media | Severo | Tratar antes de la versión | Los fallos de gestión remota pueden escalar por toda una flota de ISP |
| R5 | Baja | Severo | Tratar antes de la versión | El retroceso de firmware puede mantener vivas builds vulnerables conocidas |
| R6 | Media | Medio | Tratar antes de la versión | El aislamiento de invitados es una expectativa básica del usuario |
| R7 | Media | Medio | Tratar antes de la versión | Los ataques por proximidad física son realistas en pisos y espacios compartidos |
| R8 | Media | Alto | Tratar antes de la versión | El acceso de depuración es una vía de escape recurrente desde producción |
| R9 | Media | Alto | Tratar antes de la versión | El desvío entre ramas es previsible cuando las versiones OEM e ISP se separan |
| R10 | Media | Alto | Tratar antes de la versión | La reventa del router y la devolución al ISP son flujos previsibles |
| R11 | Baja | Medio | Tratar antes de la versión | Los controles que dependen de la nube necesitan respaldo seguro |
| R12 | Media | Alto | Tratar antes de la versión | La pila de componentes del router recibe vulnerabilidades durante todo el soporte |
| R13 | Media | Alto | Tratar antes de la versión | La configuración del switch gestionable puede afectar a muchos dispositivos aguas abajo |
| R14 | Baja | Alto | Tratar antes de la versión | El desvío de aprovisionamiento puede exponer el borde de internet a escala de flota |
| R15 | Media | Severo | Tratar antes de la versión | La recuperación es una ruta privilegiada que pueden alcanzar atacantes y equipos de servicio |
| R16 | Media | Alto | Tratar antes de la versión | El comportamiento de radio y mesh cambia a menudo con los SDK de proveedor y las revisiones de hardware |
| R17 | Media | Severo | Tratar antes de la versión | Los errores en el alcance de gestión remota pueden afectar a flotas enteras |
| R18 | Media | Alto | Tratar antes de la versión | Las devoluciones del router, la reventa y los cambios de ISP son eventos normales del ciclo de vida |
Asignación de controles y evidencias
| Amenazas | Control de diseño | Evidencia que el fabricante debería conservar |
|---|---|---|
| R1, R8 | Administración WAN deshabilitada por defecto, inventario de servicios de producción, reglas de firewall para gestión, sin telnet ni shell de fábrica | Escaneos de exposición, lista de comprobación de imagen de producción, diff de lista de servicios |
| R2, R7 | Secreto de configuración único o creación forzada de credenciales, ventana corta de emparejamiento, WPS deshabilitado o justificado, límites de tasa | Prueba de alta, evidencia de generación de credenciales, revisión de configuración inalámbrica |
| R3 | Endurecimiento del parser, fuzzing, separación de privilegios de servicio, postura WAN por defecto a denegar | Informes de fuzzing, diseño de aislamiento de servicios, triaje de fallos |
| R4 | Autenticación mutua, rotación de certificados, aprovisionamiento de mínimo privilegio, revisión de perfil ACS/USP | Revisión de seguridad de gestión remota, registro de ciclo de vida de certificados |
| R5 | Arranque seguro, firmware firmado, contador de versión monótono, comprobaciones de firma de la imagen de recuperación | Informe de prueba OTA, rechazo de retroceso, prueba de recuperación |
| R6 | Aislamiento de la red de invitados, interfaz de administración no alcanzable desde invitados, pruebas de regresión entre nodos mesh | Prueba de aislamiento de red, prueba de roaming mesh |
| R9 | Matriz de ramas OEM/ISP, política de fusión de parches, aprobación de versión, alineación de fin de soporte | Matriz de ramas, registro de propagación de parches, trazabilidad de aprobaciones del ISP |
| R10 | Flujo de transferencia de propiedad, desvinculación en nube en el reseteo, revocación de tokens, borrado del dispositivo devuelto | Prueba de reseteo, prueba de transferencia de propiedad, lista de comprobación RMA |
| R11 | Comportamiento de respaldo del DNS local, modo de fallo seguro del control parental, aviso claro al usuario | Prueba de modo de fallo, evidencia de notificación al usuario |
| R12 | Monitorización del inventario de componentes, entrada de avisos del proveedor, titular del componente de firmware, trazabilidad de notas de versión | Diff del inventario de componentes, registro de avisos, registro de decisión por componente |
| R13 | Vinculación del plano de gestión, configuración única de administración, SNMP/API deshabilitado o endurecido por defecto, pruebas de aislamiento de VLAN | Escaneo de exposición, prueba de configuración por defecto, revisión de gestión del switch |
| R14 | Perfil de aprovisionamiento evaluado, restricciones de administración remota, control de cambios del operador, traza de retroceso y auditoría | Registro del perfil de aprovisionamiento, auditoría de configuración de flota, trazabilidad de aprobaciones del operador |
| R15 | Recuperación autenticada, imagen de recuperación firmada, estado anti-retroceso, aviso de recuperación física cuando proceda | Prueba de abuso de recuperación, registro de cadena de arranque, rechazo de retroceso |
| R16 | Matriz de revisiones de hardware, inventario de firmware Wi-Fi, pruebas de regresión de WPS/mesh, revisión de dominio regulatorio | Matriz de revisiones, registro de firmware de radio, pruebas de configuración inalámbrica |
| R17 | Perfil de gestión remota de mínimo privilegio, inventario de certificados de controlador, auditoría y aprobación de comandos | Revisión de perfil TR-069/USP, registro de ciclo de vida de certificados, muestra de auditoría |
| R18 | Flujo de transferencia de propiedad, desvinculación en nube en el reseteo, borrado en devolución al ISP, revocación de tokens | Prueba de reseteo, lista de comprobación de dispositivo devuelto, evidencia de desvinculación en nube |
Riesgo residual tras los controles
| Área residual | Por qué permanece | Evidencia de operación |
|---|---|---|
| Desvío entre ramas del ISP | La aprobación de versión de OEM e ISP puede ir a velocidades distintas | Matriz de ramas, ruta de escalado, revisión de delta entre versiones |
| Compromiso de equipos del hogar | El malware en un cliente LAN puede atacar la administración local o los ajustes DNS | Controles de autenticación local, revocación de tokens, alertas de administración |
| Nuevas vulnerabilidades WAN | El código orientado a WAN sigue recibiendo tráfico hostil durante el periodo de soporte | Monitorización de explotación, cadencia de fuzzing, proceso de actualización de emergencia |
| Retraso de firmware del proveedor | Los proveedores de Wi-Fi y SoC pueden publicar correcciones en sus propios tiempos | Registro de SLA del proveedor, notas de mitigación, proceso de aviso al cliente |
¿Cómo deberían funcionar el soporte, las actualizaciones y la notificación?
Para el ejemplo HomeRouter R1, el archivo CRA práctico debería incluir el modelo operativo del periodo de soporte, no solo la evidencia de versión previa al mercado.
| Área operativa | Evidencia a preparar |
|---|---|
| Periodo de soporte | Una motivación del periodo de soporte para el SKU de retail y el SKU de marca del ISP, con la fecha de fin (mes/año) visible en la compra y en la interfaz del router cuando sea técnicamente viable. Salvo que el uso previsto sea más corto, planifica al menos cinco años. |
| Disponibilidad de actualizaciones de seguridad | Las correcciones de firmware de seguridad y los paquetes de actualización de seguridad permanecen recuperables durante al menos 10 años después de su emisión, o durante el resto del periodo de soporte si es mayor. Las imágenes de recuperación, los hashes, las notas de versión y las decisiones de retroceso deben conservarse como evidencia, pero no todo paquete no de seguridad debe describirse como un compromiso legal de disponibilidad a 10 años. |
| Matriz de ramas OEM e ISP | Qué rama de firmware se evalúa, quién la firma, quién aprueba la versión, quién es titular de las correcciones de emergencia y cómo llegan las correcciones de seguridad aguas arriba a las builds de marca blanca. |
| Contacto único de vulnerabilidades | Un contacto directo de notificación de vulnerabilidades para el fabricante en cuestión, no solo el soporte al abonado o un chatbot exclusivamente automatizado. Si un ISP es fabricante para un SKU con marca, el ISP es titular de una ruta de entrada para reportes de seguridad de producto. |
| Diligencia de componentes | Monitorización del inventario de componentes para el núcleo, el firmware inalámbrico, los servicios DNS/DHCP, la pila TLS, los SDK móviles y el agente de gestión remota, con triaje de avisos del proveedor, notificación aguas arriba y compartición de correcciones cuando proceda. |
| Flujo de explotación activa | Notificación a través de la plataforma única de reporte al CSIRT designado como coordinador y a ENISA: alerta temprana en 24 horas, notificación de seguimiento en 72 horas, informe final de vulnerabilidad en los 14 días siguientes a que esté disponible una medida correctora o mitigadora, y aviso a los usuarios afectados o instrucciones de mitigación cuando proceda. |
| Flujo de incidente grave de seguridad de producto | Notificación a través de la misma plataforma y destinatarios: alerta temprana en 24 horas, notificación de seguimiento en 72 horas, informe final de incidente en el mes siguiente a la notificación del incidente, y coordinación con el cliente/ISP incluyendo aviso al usuario cuando proceda. |
| Índice del archivo técnico | Identidad del producto, diagrama de límite, activos WAN/LAN/inalámbricos, modelo de amenazas, registro de riesgos, controles, evidencia de pruebas, inventario de componentes, proceso de actualización, proceso de vulnerabilidades, motivación del periodo de soporte, instrucciones, declaración y registro de la ruta de conformidad. |
¿Qué puertas de validación se ejecutan antes de la versión?
Una versión de router no debería pasar con una nota general de "seguridad revisada". Lista las decisiones concretas que pueden detener el envío, y da a cada una el fallo que evita, el control que la cierra y el artefacto que demuestra que el control se ejecuta de verdad.
- G1Credenciales de primer usoBloquear versión
- Fallo
Una contraseña de administración o Wi-Fi compartida o predecible, o un secreto impreso reutilizado en un lote.
- Control
Secreto único por dispositivo o creación forzada de credencial; WPS apagado o justificado.
- Prueba
Prueba de alta y evidencia de generación de credenciales.
- Fallo
- G2Exposición WAN tras el aprovisionamientoBloquear versión
- Fallo
La administración remota, o un servicio innecesario o no evaluado que procesa entradas WAN no autenticadas, es alcanzable antes de que el usuario haya configurado nada.
- Control
Administración WAN apagada por defecto, postura por defecto a denegar, endurecimiento del parser y lista mínima de servicios.
- Prueba
Escaneo de exposición WAN tras el aprovisionamiento.
- Fallo
- G3Aislamiento inalámbrico y de invitadosBloquear versión
- Fallo
La red de invitados puede enrutar a dispositivos LAN o llegar a la interfaz de administración.
- Control
Aislamiento de invitados por defecto; interfaz de administración no alcanzable desde invitados; regresión entre nodos mesh.
- Prueba
Prueba de aislamiento de red y de roaming mesh.
- Fallo
- G4Ruta de actualización y recuperaciónBloquear versión
- Fallo
OTA o recuperación acepta una imagen de firmware sin firmar o más antigua.
- Control
Arranque seguro, imágenes firmadas, contador de versión monótono y rechazo de retroceso.
- Prueba
Resultado de prueba de retroceso fallido y de abuso de recuperación.
- Fallo
- G5Alcance de gestión remotaBloquear salvo documentación
- Fallo
El alcance de comandos TR-069 o USP permite al controlador cambiar más que el perfil de operador evaluado.
- Control
Perfil de mínimo privilegio, inventario de certificados de controlador, auditoría de comandos.
- Prueba
Revisión del perfil y muestra de auditoría de comandos.
- Fallo
- G6Pila del proveedorEnviar con monitorización
- Fallo
Aparece una vulnerabilidad en el SDK del SoC, el firmware Wi-Fi o un demonio de red empaquetado durante la ventana de soporte.
- Control
Inventario de componentes con titular asignado, vigilancia de avisos y preparación de backport.
- Prueba
Decisión de triaje del componente afectado.
- Fallo
¿Quién es titular del desarrollo del router desde el concepto hasta el soporte?
La titularidad de una versión del router cambia de manos a medida que pasa de definición de producto a flota en marcha en los hogares y en las redes del ISP. El carril de abajo asigna a cada etapa un único responsable, el registro que ese responsable mantiene al día y la puerta que tiene que cerrarse antes de empezar la siguiente etapa.
Cada transición es un punto de congelación: el límite se fija antes de empezar la arquitectura, la intención de diseño antes del código, la build antes de la verificación y la versión antes de enviarse, tras lo cual el firmware se mantiene operativo durante la ventana de soporte. Un reporte de vulnerabilidad, un aviso de ISP o de proveedor, o un fallo en campo, reabren el siguiente memorando de límite, lista de amenazas e inventario de componentes, no los que ya se enviaron.
¿Qué registros de evidencia pertenecen al expediente?
El expediente debe permitir al revisor seguir la decisión del router desde la identidad del producto hasta los controles de seguridad. Cada fila apunta a un registro mantenido, no a una carpeta de capturas de pantalla inconexas.
| Área de evidencia | Qué capturar para un router, router-módem o switch |
|---|---|
| Identidad del producto | Modelo, revisiones de hardware, SoC y chipset Wi-Fi, tipo de WAN, rama de firmware, versión de la app móvil, opciones de switch/mesh |
| Finalidad prevista | Router doméstico, CPE del ISP, módem de internet, ONT, kit mesh, punto de acceso móvil, switch gestionable o router VPN, con las variantes de retail y de marca del ISP nombradas |
| Archivo de diseño de ciberresiliencia | Exposición WAN, valores por defecto LAN e inalámbricos, autoridad de gestión remota, ruta OTA y de recuperación, lista de amenazas y plan de tratamiento |
| Inventario de componentes | Gestor de arranque, núcleo, firmware Wi-Fi, pila WAN-PHY/módem, servicio DNS/DHCP, pila TLS, agente de gestión remota, SDK móviles, con titulares nombrados y vigilancia de avisos |
| Valores seguros por defecto | Sin credencial por defecto compartida, administración WAN apagada por defecto, actualizaciones firmadas, rechazo de retroceso, aislamiento de invitados, puertos de depuración bloqueados, inventario de servicios tras el aprovisionamiento |
| Mecanismo de actualización | Firmware firmado, imagen de recuperación, estado anti-retroceso, mapa de ramas ISP/OEM, aviso de actualización al usuario |
| Gestión de vulnerabilidades | Política de divulgación, punto de contacto único, flujo de triaje, vigilancia de avisos por componente, enrutado de avisos ISP/marca blanca |
| Instrucciones de usuario | Alta segura, configuración de contraseña e invitados, ajustes de actualización, divulgación de fin de soporte, desmantelamiento y reseteo |
| Trazabilidad y contacto | Información de tipo/lote/número de serie, contacto del fabricante o del ISP, fecha de fin del periodo de soporte y un contacto único de notificación de vulnerabilidades que no sea solo un bot automatizado |
¿Qué contiene un inventario de componentes de router?
La CRA exige un inventario de componentes en formato legible por máquina que identifique los componentes del producto y cubra al menos las dependencias de nivel superior, sin nombrar todavía un único formato fijo. Los fabricantes de routers normalmente eligen CycloneDX o SPDX. El detalle transversal sobre la mecánica del inventario de componentes vive en la guía del inventario de componentes dedicada; esta sección cubre el árbol específico del router.
Una versión de router envía varios elementos digitales con ciclos de actualización separados, no un único binario. Dos patrones cumplen el mínimo de la CRA: un inventario de componentes a nivel de producto con secciones separadas por elemento (gestor de arranque, núcleo, firmware Wi-Fi, pila WAN-PHY, demonios de red, TLS, agente de gestión remota e interfaz web, cada uno con versión fijada), o un inventario por elemento enviado, refrescado en cada versión. Cualquiera es aceptable mientras sea legible por máquina y se cubran las dependencias de nivel superior.
¿Qué comprueba la firma de versión?
La firma antes de la versión para la UE debería poder cerrar cuatro carpetas de registros, mostradas como Q1 a Q4. El índice completo del expediente está en el mapa de evidencia anterior; las cuatro preguntas aquí son solo las que bloquean la versión cuando una carpeta está vacía.
| Carpeta | Pregunta de versión | Puntero de evidencia específico del router |
|---|---|---|
| Q1 Memorando de motivación de la clasificación | ¿Por qué se clasifica así este producto? | Función principal (enrutado y conectividad a internet), uso previsto, afirmaciones de venta, variante retail vs. ISP y ruta de conformidad elegida |
| Q2 Inventario de elementos enviados | ¿Qué es exactamente el producto? | Hardware del router, firmware, servicios WAN/LAN/inalámbricos, interfaz web, agente de gestión remota, servicio OTA, endpoints de nube y los sistemas excluidos del cliente/ISP |
| Q3 Lote de pruebas de valores seguros por defecto | ¿Qué se ha asegurado por defecto y cómo se actualizará de forma segura? | Sin credencial por defecto compartida, administración WAN apagada por defecto, actualizaciones firmadas, rechazo de retroceso, aislamiento de invitados, decisión sobre WPS, puertos de depuración bloqueados, inventario de servicios tras el aprovisionamiento |
| Q4 Proceso de gestión de vulnerabilidades | ¿Cómo se gestionarán las vulnerabilidades y los incidentes graves tras el envío? | Contacto público, política de divulgación, flujo de triaje, vigilancia de avisos por componente, enrutado de avisos ISP/marca blanca, preparación de notificación a 24 y 72 horas |
Carpetas de firma de versión Q1 a Q4
- Q1 Memorando de motivación de la clasificación. ¿Por qué Clase I punto 12? Función principal, uso previsto, afirmaciones de venta, variante retail vs. ISP y ruta de conformidad elegida.
- Q2 Inventario de elementos enviados. Hardware del router, firmware, servicios WAN/LAN/inalámbricos, interfaz web, agente de gestión remota, servicio OTA, endpoints de nube y sistemas excluidos del cliente/ISP.
- Q3 Lote de pruebas de valores seguros por defecto. Sin credencial por defecto compartida, administración WAN apagada por defecto, actualizaciones firmadas, rechazo de retroceso, aislamiento de invitados, decisión sobre WPS, puertos de depuración bloqueados.
- Q4 Proceso de gestión de vulnerabilidades. Contacto público, política de divulgación, flujo de triaje, vigilancia de avisos por componente y preparación de notificación para alertas, notificaciones e informes finales.
Sign-off gate: si falta un registro, la versión no se firma.
¿Cómo se traspasa el router al importador, distribuidor, ISP y operador?
Traspaso entre operadores económicos: roles y comprobaciones laterales
- 01 Fabricante / OEM. Titular del pack de versión: declaración, CE, índice del archivo, ventana de soporte y contacto de vulnerabilidades.
- 02 Importador. Verifica el pack, CE, índice del archivo, fecha de soporte y contacto de vulnerabilidades, y confirma que la build recibida es la evaluada: ajustes de país inalámbrico, perfiles del ISP, certificados de gestión remota, emparejamiento de app y endpoints OTA. Pausa el envío si alguno es dudoso.
- 03 Distribuidor. Comprueba CE visible, documentación suministrada, declaraciones de soporte y actualización, y no añade afirmaciones como "pasarela de seguridad", "firewall empresarial" o "aparato VPN gestionado" que queden fuera del límite evaluado. Pausa el listado si exagera el soporte, no cuadra con la declaración o sigue vendiendo tras un problema conocido.
- 04 ISP o marca blanca. La marca, la gestión en nube, la titularidad de actualización y la operación de gestión remota pueden, por sí solas, activar obligaciones de fabricante. Colocar el router bajo su propio nombre, o modificarlo sustancialmente (firmware con marca, nueva nube, nuevo canal de actualización), lo convierte en el fabricante para esa oferta, así que el archivo del proveedor no sustituye su propio análisis de rol.
- 05 Operador o abonado. Recibe avisos y actualizaciones, y reporta los problemas. No es fabricante.
Comprobación lateral A. El mandato del representante autorizado es opcional, pero cuando existe debe estar por escrito y cubrir el mantenimiento de la declaración y la documentación a disposición y la cooperación con las autoridades. Un fabricante no UE sin uno usa la cascada: importador, distribuidor, luego mayor base de usuarios. Si no hay un operador establecido en la Unión en la cadena de notificación, el endpoint de notificación recae sobre el Estado miembro donde se localice el mayor número de usuarios.
Comprobación lateral B. Un importador o distribuidor con marca propia, o cualquier modificador sustancial, pasa a ser fabricante para la oferta afectada.
Preguntas frecuentes
¿Es un router Clase II porque tenga firewall?
Por defecto, no. Un router normal es habitualmente Clase I importante. Pasa a ser una pregunta de Clase II cuando el firewall, la detección o la prevención de intrusiones son la función principal del producto.
¿Está cubierto un router suministrado por el ISP?
Sí, si se introduce en el mercado de la UE como producto con elementos digitales. La cuestión práctica clave es quién es el fabricante para el firmware con marca, el periodo de soporte, el canal de actualización y el proceso de vulnerabilidades.
¿Es un router Crítico?
No. Los routers de consumo, los router-módem del ISP y los switches no son Críticos solo por ser importantes para el acceso a la red.
¿Cambia la respuesta un firmware comercial de router de código abierto?
Puede cambiarla. Una imagen de firmware suministrada comercialmente o una distribución de aparato pueden ser, por sí mismas, un producto con elementos digitales. El fabricante debe documentar qué se introduce en el mercado y quién es titular de las actualizaciones y la gestión de vulnerabilidades.
Si el software cumple realmente con software libre y de código abierto y entra en una categoría importante, la CRA tiene una opción específica de conformidad en la que la documentación técnica requerida es pública en el momento de la introducción en el mercado. No apliques esa ruta a un fork de firmware privado del ISP o a un aparato comercial solo porque incluya paquetes de código abierto.
¿Cumplir el plazo de ciberseguridad de la RED significa que un router ya cumple la CRA?
No. Desde el 1 de agosto de 2025 los equipos radioeléctricos conectados a internet cumplen los requisitos de ciberseguridad de la Directiva de Equipos Radioeléctricos, y esos controles (valores seguros por defecto, integridad de actualización, protección de acceso) son la base adecuada. Pero la CRA añade un ciclo de vida más amplio: un proceso documentado de gestión de vulnerabilidades, una fecha publicada de fin del periodo de soporte, seguridad por defecto en todo el producto y deberes de notificación. El Reglamento Delegado de ciberseguridad de la RED queda derogado desde el 11 de diciembre de 2027, cuando la CRA toma el relevo.
Disparador de re-revisión: trata el archivo RED como punto de partida y haz un análisis de brechas contra los requisitos esenciales de la CRA antes del 11 de diciembre de 2027.
¿Qué norma armonizada aplica a un router bajo la CRA?
Para la fase de equipos radioeléctricos, el conjunto armonizado es la serie EN 18031, construida sobre ETSI EN 303 645 como línea base de consumo. La norma de la CRA específica para routers en preparación es ETSI EN 304 627 (Routers, módems y switches), que se asigna a Clase I punto 12. Sigue siendo borrador, así que confirma las normas citadas y cualquier restricción de armonización en el momento de la evaluación.
Registro de conformidad: un memorando breve que nombre las normas en las que se apoya, la versión, cualquier restricción que no encaje en el producto y la ruta de conformidad resultante.
¿Se trata un switch gestionable como un router, y entra un switch no gestionable en el ámbito?
Un switch gestionable tiene un plano de gestión (interfaz web, CLI, SNMP/API, VLAN) y una ruta de actualización de firmware, así que normalmente se trata como equipo de red Clase I importante con su propia evidencia de plano de gestión. Un switch puramente no gestionable, no configurable, sin superficie de gestión, sin actualización de firmware y sin función conectada, necesita una comprobación caso por caso sobre si es siquiera un producto con elementos digitales.
Registro de límite: una nota de una línea por SKU de switch que indique si existe una superficie de gestión o actualización.
¿Los kits Wi-Fi mesh son uno o varios productos?
Los nodos mesh que forman un sistema son habitualmente el producto router o la familia de productos. Evalúa el kit tal como se envía: el nodo controlador, los nodos satélite, el flujo de alta y el protocolo de control mesh. La confianza entre nodos y el saludo de alta son parte de la superficie de ataque inalámbrica.
Registro de límite: nombra los nodos del kit, el protocolo de control mesh y el método de alta en el memorando de límites.
¿Está cubierto un módem o ONT independiente si solo hace puente?
Un módem, módem de cable o ONT de fibra destinado a la conexión a internet es habitualmente Clase I importante, incluso en modo puente, porque la función de módem de internet es la función principal del producto y el dispositivo sigue teniendo firmware, un canal de aprovisionamiento y a menudo un agente de gestión remota. Modo puente frente a modo router cambia la exposición, no la clasificación básica.
Registro de límite: registra el canal de aprovisionamiento, el agente de gestión remota y si el modo puente o el modo router es el valor evaluado por defecto.
¿Entra en el ámbito un punto de acceso móvil 4G o 5G?
Sí. La WAN celular sigue siendo conectividad a internet, así que un punto de acceso móvil o un router 4G/5G es habitualmente Clase I importante. La ruta de aprovisionamiento celular y el manejo de SIM/eSIM son parte de la superficie de ataque WAN.
Registro de límite: nombra el módulo celular, la ruta de aprovisionamiento y el canal de gestión.
¿Cuánto tiempo debe soportarse y actualizarse un router?
El periodo de soporte es de al menos cinco años, salvo que el tiempo de uso previsto sea menor; muchos routers y CPE del ISP funcionan mucho más, así que el archivo debe declarar una ventana que el fabricante pueda cumplir y mostrar la fecha de fin antes de la compra. Las actualizaciones de seguridad deben permanecer recuperables al menos diez años después de su emisión, o durante el resto del periodo de soporte si es mayor. Las reglas generales viven en las guías de conceptos básicos del periodo de soporte y divulgación del fin de soporte.
Registro de soporte: una motivación del periodo de soporte para el SKU de retail y el SKU de marca del ISP, con la fecha de fin visible en la compra y en la interfaz del router cuando sea viable.
¿Qué cuenta como actualización segura para un router?
Una imagen de firmware firmada, verificada por una cadena de arranque seguro, con un contador de versión monótono para que no pueda reinstalarse una build anterior vulnerable, y una ruta de recuperación que también rechace imágenes sin firmar o degradadas. Las actualizaciones empujadas por el ISP y las del OEM deben seguir las dos esta ruta.
Artefacto de prueba: un log de verificación de actualización firmada, una prueba de retroceso fallido y una prueba de abuso de recuperación para la build de firmware exacta.
¿Cambia TR-069 o USP la gestión remota el límite del producto?
Si el fabricante o el ISP suministra el canal de gestión remota, está dentro del límite y es una ruta de control de flota, no solo una característica del operador. El servidor de autoconfiguración del operador, el mecanismo de solicitud de conexión, el alcance de comandos y la confianza de certificado pertenecen todos a la evaluación.
Evidencia: un inventario de certificados de controlador y una matriz de alcance de comandos vinculada al perfil de operador evaluado.
¿Quién es el fabricante para el CPE con marca del ISP?
Quien introduce el producto en el mercado bajo su propio nombre o marca, o modifica sustancialmente el producto evaluado. Un ISP que rebrandea hardware OEM, bifurca el firmware, opera la nube de gestión o es titular del canal de actualización puede asumir las obligaciones de fabricante para ese SKU con marca, incluido el contacto de notificación de vulnerabilidades.
Registro de rol: una división por escrito de quién es titular de la declaración, la rama de firmware, el canal de actualización, el periodo de soporte y el contacto de notificación.
¿Cuál es el primer elemento de evidencia que debería crear un fabricante de routers?
Un memorando breve de clasificación y límite para el SKU exacto: router, router-módem, kit mesh, switch, hotspot o router VPN. Nombra el tipo de WAN, la pila inalámbrica, la superficie de administración LAN, el canal de gestión remota, los servicios en nube, la titularidad de actualización, el periodo de soporte y los sistemas excluidos.
Registro de clasificación: un memorando de una página al que puedan apuntar la evaluación de riesgos, la elección de la ruta de conformidad, el pack del importador y la declaración del periodo de soporte.
¿Qué pasa si se encuentra una vulnerabilidad en el firmware del router tras la versión?
Aplica medidas correctoras de forma inmediata y prepárate para la secuencia de notificación: una alerta temprana en 24 horas para una vulnerabilidad explotada activamente, una notificación en 72 horas, un informe final cuando esté disponible una medida correctora o mitigadora, y notificación al usuario. Para un router la medida correctora suele ser una actualización de firmware firmada empujada a las ramas OEM, ISP y de marca blanca, con una excepción documentada cuando una rama no puede tomar la misma corrección. La mecánica general de notificación vive en las guías de gestión de vulnerabilidades y divulgación coordinada de vulnerabilidades.
Registro de acción correctora: modelos y ramas de firmware afectados, el artefacto de actualización firmada, la traza de propagación entre ramas, el texto del aviso al usuario y la referencia de notificación.
¿Cuándo debe actualizarse la evaluación de riesgos del router?
Cada vez que un router enviado cambia de forma que mueve un límite de confianza: un nuevo tipo de WAN, un nuevo perfil de gestión remota, un cambio de SDK de Wi-Fi o SoC, una nueva dependencia de nube, un cambio en el alta mesh, un cambio en el comportamiento del puerto de depuración o una nueva rama del ISP. Una nota de versión no basta si el cambio reabre una exposición o una ruta de autoridad. Los deberes de notificación se aplican desde el 11 de septiembre de 2026, así que la política de divulgación y el contacto único deben estar funcionando antes de esa fecha.
Disparador de re-revisión: cualquier cambio en exposición WAN, valores inalámbricos por defecto, alcance de gestión remota, ruta de actualización, componentes del proveedor o rama del ISP reabre el memorando de límite y la evaluación de riesgos.