RED, EN 18031 and CRA Readiness Guide: Respuestas prácticas del Webinar QIMA

La parte más útil del seminario web de QIMA, Navegando por la UE Cybersecurity Compliance for Connected Products, fue la Q&A.

Los fabricantes preguntan acerca de estándares , alcance, variantes de producto, informes de CRA, periodos de soporte y documentación. Estas son las preguntas que surgen cuando el cibercibernético y el CRA RED comienzan a afectar a los productos reales, a los plazos de lanzamiento y a los archivos técnicos.

Este artículo convierte estas preguntas en guía práctica para equipos de productos, ingeniería, conformidad, calidad y certificación.

QIMA creó Cyberexperto para el trabajo de preparación descrito en este artículo: alcance, mapeo de requerimientos, preparación de pruebas, E. nfo de apoyo, y revisión de expertos antes de que un producto llegue a una evaluación formal. El artículo explica primero las decisiones que los fabricantes deben tomar.

Se trata de una recapitulación educativa, no de asesoramiento legal. Los fabricantes deben verificar las obligaciones específicas de cada producto contra el texto legal oficial, las normas armonizadas y la ruta de evaluación de la conformidad seleccionada.

La lección principal: no empezar con el estándar

Un error común es preguntar primero: ¿Qué norma debemos utilizar?

Es demasiado tarde en la lógica.

La mejor primera pregunta es: ¿Qué necesita proporcionar este producto?

La respuesta depende del límite producto, el uso previsto, la conectividad, el manejo de datos, activos, interfaces, la funcionalidad básica, y si son RED, CRA o ambas aplican.

Los requisitos cibernéticos de RED provienen del Radio Equipment Directive y sus requisitos esenciales relacionados con la ciberseguridad según el Artículo 3(3)(d), (e), y (f), que cubren la protección de redes, datos personales y privacidad, y protección contra el fraude. El Reglamento Delegado (UE) 2022/30 activa estos requisitos para clases específicas de equipos de radio, y la Decisión de Ejecución (UE) 2025/138 se refiere a las normas armonizadas que apoyan esos requisitos de ciberseguridad RED.

CRA es más amplio. Se aplica a los productos con elementos digitales colocados en el mercado de la UE cuando su propósito o uso razonablemente predecible incluye una conexión directa o indirecta de datos lógicos o físicos a un dispositivo o red. También crea obligaciones del fabricante en el diseño, desarrollo, producción, mantenimiento, documentación técnica, evaluación de conformidad, periodos de soporte y manejo de vulnerabilidades.

Eso significa que el primer entregable debe ser un mapa de cumplimiento específico del producto.

1. ¿Se reemplazará EN 18031 por EN 40000?

Question from the webinar: Will EN 18031 be replaced by EN 40000?

Respuesta corta: No necesariamente.

Gergely Bakos explicó en el Q&A que EN 18031 y la serie EN 40000 tienen un alcance y cobertura diferentes. EN 18031 es fundamental para el cumplimiento de la ciberseguridad RED: EN 40000 trae otras áreas, incluyendo el manejo de vulnerabilidades, que es importante para la preparación de CRA.

Por lo tanto, los fabricantes no deben suponer que una norma sustituya a la otra.

Para un producto de radio en el ciberescopio RED, EN 18031 puede seguir siendo el camino central para RED. Pero las obligaciones de CRA pueden requerir trabajo adicional, especialmente en lo que se refiere al manejo de vulnerabilidades, reportes, actualizaciones de seguridad y planificación del período de soporte.

Despegue práctico: selección estándar debe seguir el análisis del producto.

Un fabricante debería ser capaz de explicar:

• por qué EN 18031 aplica, o no aplica

• si es necesaria la orientación de EN 40000 para trabajo adicional de CRA

• donde se cubre el manejo de vulnerabilidades

• donde puede ser necesaria la participación del cuerpo notificado

• que evidencia apoya cada decisión

Si la respuesta es sólo “usamos EN 18031”, la selección estándar no está suficientemente documentada.

2. El ámbito de aplicación RED es donde los fabricantes pueden retrasarse antes

La sección de ámbito de Cédric Lévy-Bencheton fue una de las partes más prácticas del seminario web. Su punto era claro: el ámbito cibernético RED no siempre es obvio.

Un producto puede plantear preguntas cibernéticas de RED cuando tiene una interfaz inalámbrica y conectividad habilitada para Internet, incluso si la conexión habilitada para Internet no es inalámbrica.

Ejemplo 1:

Un dispositivo tiene Bluetooth para la configuración y Ethernet para la comunicación de red. El Bluetooth puede ser local, pero la conexión Ethernet puede seguir siendo importante para el ciberalcance RED.

Ejemplo 2:

Un producto utiliza Zigbee y se conecta a través de una pasarela o aplicación móvil. Llamarlo “radio local” no es suficiente. Si la aplicación o la pasarela puede controlar el producto de forma remota, es necesario revisar la conectividad indirecta.

Aviso útil: el tratamiento de los datos personales no implica automáticamente un efecto de privacidad en todos los casos. Un micrófono o amplificador inalámbrico puede procesar audio pero no guardarlo. El análisis de privacidad todavía depende de lo que el producto hace con los datos.

Prueba de ámbito práctico

Antes de decidir el ámbito de aplicación, los fabricantes deben responder a cuatro preguntas:

1. ¿El producto tiene alguna interfaz de radio?

2. ¿El producto tiene conectividad directa o indirecta con Internet?

3. ¿Puede otro sistema, aplicación, puerta de enlace o servicio en la nube controlar el producto?

4. ¿El proceso, almacena, transmite o expone datos relevantes para la protección de la red, la privacidad o la protección contra fraude?

Un archivo de ámbito útil debe incluir un diagrama de conectividad simple. Debe mostrar interfaces inalámbricas, interfaces por cable, aplicaciones móviles, pasarelas, procesamiento en la nube o a distancia, actualizar canales y interfaces de servicio o depuración.

Esto no tiene que ser complicado, tiene que ser preciso.

3. Evaluación de riesgos RED y evaluación de riesgos de ciberseguridad son documentos diferentes

Question from the webinar: EN 18031 does not provide a risk assessment methodology. Does EN 40000 fill that gap?

Respuesta corta: parcialmente, pero no completa.

Cédric explicó que EN 18031 incluye los árboles de decisión y las menciones STRIDE, pero no proporciona a los fabricantes un completo método de modelado de amenazas o evaluación de riesgos de ciberseguridad. EN 40000-1-2 se debatió como guía para los pasos de gestión de riesgos, pero no como un método listo para ser copiado en cada archivo de producto.

La distinción es importante.

Una evaluación de riesgos cibernéticos RED ayuda a determinar qué requisitos legales RED aplican.

Una evaluación de riesgo de ciberseguridad analiza el riesgo real del producto: usuarios, datos, interfaces, exposición, contexto de uso, escenarios de ataque, impacto, controles y riesgo residual.

El ejemplo de la cámara Cédric lo hace sencillo: la misma cámara conectada puede llevar riesgos diferentes en un dormitorio, un jardín o un aparcamiento. El hardware puede ser similar. El contexto no lo es.

Una entrada de riesgo débil dice:

R) El riesgo es bajo.

Una entrada de riesgo útil dice:

✓ La interfaz de servicio Ethernet se utiliza únicamente durante la instalación y el mantenimiento en un entorno físico controlado. No está expuesto durante la operación normal del usuario. Este supuesto está soportado por el procedimiento de servicio, la configuración de la interfaz y la documentación de la instalación. Basado en este contexto de uso, el control de acceso se trata como no aplicable para este activo y la interfaz.

Ese tipo de entrada ayuda a la ingeniería, al cumplimiento y a los evaluadores a entender la decisión.

4. EN 18031 es difícil porque está basado en activos

EN 18031 no es una lista de verificación plana. Pide a los fabricantes que piensen en términos de activos, interfaces, entidades, mecanismos de seguridad, categorías de implementación y árboles de decisiones.

Los activos pueden incluir parámetros confidenciales, parámetros sensibles, funciones, parámetros de datos, activos de seguridad, activos de red, activos de privacidad y activos financieros.

Esto se convierte rápidamente en un producto específico.

Una función de actualización segura, por ejemplo, puede incluir recuperar la actualización, verificarla, instalarla, deshacer después del fallo y registrar el resultado. Un fabricante puede decidir agruparlos como una función de actualización segura. Esto puede ser razonable, pero la agrupación no debe ocultar los detalles de la evaluación.

Un registro práctico de activos debería capturar sólo los campos que son importantes:

Si el registro de activos es débil, E.Info, E.Just, y las respuestas del árbol de decisiones también serán débiles.

5. Los árboles de decisiones necesitan pruebas, no adivinaciones

Los árboles de decisión son fundamentales para la EN 18031. Los evaluadores los usan para determinar si el resultado es PASS, FALLOo NO APLICABLE.

Esto significa que una ruta del árbol de decisiones debe ser documentada como un registro de decisión.

Un registro de decisión debe responder:

• que requerimiento fue evaluado

• que activo e interfaz fueron involucrados

• que ruta fue seguida

• por qué el resultado es PASS, FAIL, o NO APPLICABLE

• qué evidencia apoya el resultado

• si esta decisión afecta a otros requisitos

Ejemplo: Ethernet y comunicación segura

Cédric explicó que Ethernet puede ser difícil porque normalmente no está cifrado y no tiene un control de acceso inherente. Si se aplica el control de acceso a esa interfaz de Ethernet, pueden seguirse requisitos de comunicación seguros.

Una justificación débil diría:

· Ethernet es utilizado sólo por técnicos.

Una justificación más fuerte diría:

✓ La interfaz Ethernet sólo es accesible durante la instalación y mantenimiento en un entorno físico controlado. No se expone a los usuarios finales durante una operación normal. Las condiciones de acceso se describen en la documentación del usuario y del servicio. La interfaz está desactivada o restringida fuera de las condiciones de servicio. Basado en este contexto de uso, la ruta del árbol de decisiones de control de acceso lleva a NOT APPLICABLE para este activo e interfaz. La evidencia de soporte se proporciona en el procedimiento de servicio, configuración de interfaz y documentación de arquitectura de producto.

Esa es la diferencia entre un supuesto y una prueba preparada para la evaluación.

6. E.Info y E.Just debe explicar el producto claramente

La documentación EN 18031 no es sólo una carpeta de documentos de productos.

Necesita explicar lo que se implementa, por qué es relevante, qué activo protege, qué camino de decisión se ha seguido, y dónde se puede comprobar la evidencia.

Cédric destacó que E.Info y E.Just se utilizan durante la evaluación, por lo que necesitan información de las partes interesadas de la ingeniería, el desarrollo, el firmware, el producto y el cumplimiento.

Respuesta débil:

· El producto utiliza el cifrado.

Respuesta más fuerte:

✓ El producto utiliza TLS 1.3 para la comunicación entre el dispositivo y el servicio en la nube. Esto protege los datos de configuración transmitidos y la información del estado del dispositivo de la divulgación y modificación no autorizadas. El mecanismo se aplica a la interfaz de red utilizada para la comunicación en la nube. La implementación se describe en la arquitectura de comunicación y se verifica en el informe de prueba de seguridad. La gestión de certificados se describe en la sección de gestión de claves. Referencias de continuidad: diagrama de arquitectura A-03, informe de prueba T-12, extracto de configuración del firmware F-07.

La respuesta más fuerte es mejor porque le dice al evaluador lo que está protegido, cómo está protegido, por qué importa y dónde verificarlo.

7. Las variantes de producto pueden reutilizar el trabajo, pero sólo con una puntuación

Pregunta del seminario web: Si los dispositivos tienen la misma funcionalidad pero diferentes factores de forma, ¿necesitan verificaciones de conformidad separadas?

Respuesta corta: puede que no necesite empezar de cero, pero necesita evaluar las diferencias.

Los fabricantes deben comenzar con la funcionalidad principal del producto. Si las variantes comparten la misma función básica, puede que algún trabajo sea reutilizable. Pero las diferencias de los factores de forma todavía pueden afectar a los requisitos de seguridad cibernética o a la conformidad con los CRA.

Por ejemplo, una tarjeta y un anillo pueden compartir el firmware y la funcionalidad central. Pero pueden diferir en la exposición física, el comportamiento de la antena, las restricciones de la batería, el proceso de actualización, la probabilidad de pérdida, la interacción del usuario o el contexto de privacidad.

Basta con una tabla de reutilización corta:

El objetivo es evitar el trabajo repetido sin copiar pruebas que no encajen en el producto.

8. El informe CRA comienza antes de la aplicación CRA completa

Pregunta del seminario web: ¿Cuál es la diferencia práctica entre septiembre de 2026 y diciembre de 2027 con arreglo a la CRA?

Respuesta corta: Septiembre de 2026 trata de informar. Diciembre de 2027 es sobre la aplicación completa.

A partir del 11 de septiembre de 2026, los fabricantes deben informar activamente de vulnerabilidades explotadas e incidentes graves que afectan a la seguridad de los productos con elementos digitales. La Comisión Europea explica que el informe incluye una alerta temprana en un plazo de 24 horas una notificación completa dentro de 72 horas, e informes finales dentro del plazo aplicable de 14 días o un mes. Los informes se hacen una vez a través de la Plataforma de Reporte Único CRA, que la ENISA tiene la tarea de establecer.

Las principales disposiciones de la CRA se aplican a partir del 11 de diciembre de 2027, mientras que las obligaciones de notificación se aplican a partir del 11 de septiembre de 2026. El resumen de la Comisión también afirma que las obligaciones de información se aplican a todos los productos con elementos digitales disponibles en el mercado de la UE. incluyendo productos ya comercializados antes del 11 de diciembre de 2027.

El punto práctico de Mihály Pajerich era que la presentación de informes no puede funcionar sin el manejo de vulnerabilidades. Un fabricante no puede informar de lo que no puede detectar, recibir, evaluar, clasificar y escalar.

Proceso mínimo antes de septiembre de 2026

Antes de que comience la obligación de informar, los fabricantes deberían tener:

1. Una vulnerabilidad pública que reporta contacto o formulario web.

2. Un propietario interno para informes de enrutamiento.

3. Una manera de identificar los productos, versiones y componentes afectados.

4. Un proceso de evaluación de gravedad y explotación.

5. Una vía de decisión para la informabilidad.

6. Un proceso para la comunicación del usuario.

7. Una plantilla de registro de incidentes.

Se trata de un mínimo práctico: no tiene por qué ser perfecto, pero tiene que ser utilizable.

9. Múltiples fábricas necesitan un toque de decisión de notificaciónh

Pregunta del seminario web: ¿Quién informa sobre incidentes si una empresa tiene múltiples fábricas bajo la misma dirección?

No todas las fábricas deben informar por separado. Las fábricas o sitios deben tener rutas de informes internas. Una función central del fabricante debe evaluar si el caso debe ser reportado a través de la Plataforma Única de Informes. Si el fabricante está fuera de la UE, el representante autorizado, importador o distribuidor puede estar involucrado dependiendo del caso.

Una prueba útil es un ejercicio de tabla.

Escenario:

Un proveedor informa de una vulnerabilidad en un módulo de comunicación utilizado en tres productos. Un producto ya está en el mercado de la UE. Uno se encuentra en producción, uno todavía está en desarrollo, la explotación activa no está clara. Existe un parche, pero no ha sido probado en todos los productos.

El fabricante debería ser capaz de responder dentro del plazo de presentación de informes:

• qué productos y versiones están afectados

• si la vulnerabilidad es explotada activamente

• si los usuarios necesitan orientación de mitigación

• si es necesario informar

• quién aprueba el informe

• donde se almacena la evidencia

Si esto no se puede hacer en una prueba, el proceso no está listo.

10. La planificación de períodos de apoyo afecta a la ingeniería, no sólo al cumplimiento

Pregunta del seminario web: ¿Cómo deben los fabricantes decidir el período correcto de soporte de seguridad?

Gergemente explicó que cinco años es el punto de inicio predeterminado, pero la vida prevista del producto importa. Es posible que los productos industriales o OTC de larga duración requieran una planificación más larga.

El texto legal de la CRA requiere que los fabricantes determinen un período de apoyo que refleje el tiempo previsto para el uso del producto. También establece que el período de apoyo debe ser de al menos cinco años. a menos que se espere que el producto se utilice por menos de cinco años. El texto oficial-Lex también se refiere al requisito de que las actualizaciones de seguridad permanezcan disponibles durante un mínimo de 10 años o durante el resto del período de soporte.

Esto afecta a la planificación del producto.

Antes del lanzamiento, los fabricantes deben saber:

• cómo se entregarán las actualizaciones

• que mantiene parches de seguridad

• qué compromisos de proveedores son necesarios

• cómo se supervisarán las vulnerabilidades de componentes de terceros

• cómo se comunicará el fin del soporte

• cuánto tiempo de publicación las actualizaciones de seguridad permanecerán disponibles

En el caso de los productos de larga duración, esta decisión debería incluir productos, ingeniería, apoyo, propietarios legales y comerciales.

Donde encaja el ciberexperto

La parte difícil no es leer el reglamento, la parte difícil es recoger información del producto, los requisitos de mapeo, la escritura utilizable E. nfo y E.Just, que conectan evidencia con reclamaciones y saber cuándo se necesita una revisión de expertos.

Ese es el trabajo de preparación Cyberexperto está construido para apoyar.

Cyberexpert ayuda a los fabricantes a estructurar la información del producto, identificar los requisitos aplicables, mapear las expectativas de E.Info, preparar la evidencia, involucrar a los proveedores y prepararse para la autoevaluación, la revisión de expertos o la evaluación del laboratorio.

Si se está preparando para RED cyber ahora, o CRA reporting a continuación, utilice Cyberexpert para verificar qué aplica a su producto, identificar brechas en la documentación y prepararse antes de la evaluación formal.

Un plan de preparación de 30 días

Semana 1: Alcance el producto

Crear un límite de producto, mapa de conectividad, mapa de datos, lista de interfaz, resumen de uso previsto, nota de alcance RED y nota de alcance CRA.

Salida: el equipo sabe qué producto se está evaluando y por qué puede estar en el ámbito de aplicación.

Semana 2: Construye la base EN 18031

Crear el registro de activos, lista de entidades, mapa de interfaz, mapeo inicial de mecanismos de seguridad y suposiciones del árbol de decisiones que necesitan evidencia.

Salida: el equipo puede ver dónde el trabajo de la EN 18031 está claro y dónde falta información sobre el producto.

Semana 3: Comprobar huecos de evidencia

Revise E.Info, E.Just, SBOM, HBOM, manual de usuario, documentación de configuración, servicios expuestos, proceso de actualización, registro, evidencia de prueba y diagramas de arquitectura.

Salida: el equipo sabe qué pruebas existen y lo que todavía necesita trabajo.

Semana 4: Preparar preparación de vulnerabilidad CRA

Configure el contacto de informes de vulnerabilidades, borrador de políticas CVD, proceso de toma de decisiones, inventario de componentes, método de evaluación de severidad, propietario de informes, proceso de notificación del usuario y plantilla de registro de incidentes.

Salida: el fabricante tiene un proceso básico antes de que comience la obligación de informar al CRA.

Qué es importante recordar

Las preguntas del seminario web apuntan a una conclusión práctica:

Los fabricantes necesitan trasladar antes el cumplimiento de la ciberseguridad al desarrollo de productos.

El cibernético RED puede afectar el acceso al mercado ahora. El informe de CRA comienza antes de la aplicación completa de CRA. EN 18031 requiere evidencia específica del producto, no reclamaciones genéricas. La EN 40000 puede ayudar con áreas adicionales, pero no elimina la necesidad de entender el producto primero.

Antes de la próxima reunión de planificación RED o CRA, los fabricantes deberían ser capaces de responder:

• ¿Es el producto en el ámbito del cibernético RED?

• ¿El producto está en el ámbito de CRA?

• ¿Cuál es el límite del producto?

• ¿Cuál es la funcionalidad principal del producto?

• ¿Qué interfaces y rutas de conectividad existen?

• ¿Qué activos necesitan protección?

• ¿Qué senderos decisorios de árboles en la EN 18031 han sido seguidos?

• ¿Pueden justificarse los resultados del PASS, FAL y NOT APPLICABLE?

• ¿E.Info y E.Just son validados por ingeniería?

• ¿Hay un inventario SBOM o componente?

• ¿Hay una vulnerabilidad pública para informar de contacto?

• ¿Quién es dueño de CRA informando internamente?

• ¿Cuál es el período de apoyo?

• ¿Qué evidencia se puede reutilizar entre las variantes de producto?

• ¿Está listo el producto para autoevaluación, revisión de expertos o evaluación de laboratorio?

Si varias respuestas son poco claras, el producto todavía está en la etapa de preparación.

Ese es el momento adecuado para corregir las lagunas antes de que afecten a la evaluación, la certificación o el acceso al mercado.

Para poner estos pasos en la práctica, descargue la lista de comprobación que se muestra a continuación y úselo para revisar su preparación para cibernéticos y CRA.