Preguntas y Respuestas del Webinar ya disponible bajo demanda

El CRA no exige mantener el mismo nivel técnico durante todo el ciclo de vida, sino definir una estrategia de seguridad justificável en el tiempo.

Los puntos clave son:

• Periodo de soporte bien definido

Debe ser coherente con la vida útil del producto (mínimo 5 años, pero en entornos industriales se esperan periodos más largos).

• Diseño orientado a mantenibilidad

El producto debe permitir actualizaciones, control de versiones y trazabilidad desde el inicio.

• Gestión continua de vulnerabilidades

El fabricante debe ser capaz de gestionar y mitigar vulnerabilidades durante todo el periodo de soporte.

Los organismos evaluadores no van a exigir soporte indefinido, sino que comprobarán que existe un modelo de soporte coherente, documentado y sostenible.

El CRA no funciona como otras regulaciones basadas en listados cerrados de productos fuera de alcance.
Si un producto entra en la definición de “producto con elementos digitales”, en principio está dentro del ámbito del CRA.

Lo que sí cambia es el nivel de exigencia, no el hecho de aplicar o no la regulación.

Sí, el CRA prevé el desarrollo de normas armonizadas (serie prEN 40000-1-x) que permitirán demostrar el cumplimiento, de forma similar a lo que ocurre hoy con EN 18031 en el contexto de RED.

Sin embargo, hay dos puntos clave:

1. A día de hoy no existe un equivalente directo a EN 18031 que cubra el CRA de forma completa. Su alcance será más amplio, ya que deberán cubrir no solo requisitos técnicos de producto, sino también aspectos de ciclo de vida, como gestión de vulnerabilidades y soporte.
2. En la práctica, estas normas facilitarán la evaluación de conformidad, pero no sustituirán la necesidad de tener procesos definidos.

Por eso, como comentamos en el Webinar, trabajar ya con EN 18031 sigue siendo válido como base técnica para prepararse para el CRA.

El CRA, como norma general, no se aplica de forma retroactiva a productos que ya han sido comercializados antes de su entrada en aplicación.

Es decir, productos que ya están desplegados no requieren, en principio, una reevaluación completa bajo el nuevo marco.

Sin embargo, cuando hablamos de productos legacy que siguen en catálogo o se siguen poniendo en el mercado, la situación es diferente.

En ese caso, el fabricante debe asegurarse de que cumplen con los requisitos del CRA en el momento de su nueva comercialización.

Además, independientemente de la obligación regulatoria inicial, el CRA pone mucho foco en el ciclo de vida, por lo que incluso en productos ya desplegados es recomendable mantener una gestión básica de vulnerabilidades y soporte de seguridad, especialmente en entornos críticos.

En general, un SaaS puro no está directamente en el ámbito del CRA.

El reglamento se aplica principalmente a productos con elementos digitales (software o hardware que se comercializa como producto), y no a servicios en la nube por sí mismos.

Sin embargo, hay un matiz clave:

• Si el SaaS forma parte necesaria del funcionamiento de un producto (por ejemplo, backend de un dispositivo IoT), puede considerarse parte del sistema y entrar indirectamente en el alcance.
• Si es un SaaS independiente (acceso web/API sin producto asociado), normalmente queda fuera del scope del CRA, estando más alineado con otros marcos como NIS2 u otras regulaciones.

En este caso, el producto estará dentro del alcance tanto del CRA como de la RED, aunque cada normativa cubre aspectos distintos.

Al tratarse de un dispositivo IoT con software y conectividad, se considera un producto con elementos digitales, por lo que debe cumplir el CRA en aspectos de seguridad desde el diseño y gestión durante todo el ciclo de vida. A su vez, al incorporar un módulo radio, sigue siendo un equipo radioeléctrico, por lo que también aplica la Directiva RED.

A nivel regulatorio, es importante tener en cuenta que los requisitos de ciberseguridad que anteriormente se introducían en RED se integran progresivamente en el CRA para evitar duplicidades.

Esto tiene una implicación práctica relevante: si un fabricante ya está trabajando el cumplimiento de RED (por ejemplo, apoyándose en EN 18031), tendrá gran parte del trabajo técnico ya avanzado de cara al CRA, especialmente en lo que respecta a arquitectura de seguridad, mecanismos y evidencias.

Actualmente, Alter Technology no es organismo notificado para el CRA, ya que el proceso de designación de organismos notificados en este contexto aún no se ha iniciado.

No obstante, contar con esta acreditación es una de las prioridades estratégicas de la compañía, con el objetivo de estar preparados en cuanto el marco de acreditación esté disponible.

Los vertical standards (estándares sectoriales o específicos de producto) están orientados principalmente a definir cómo debe diseñarse y protegerse técnicamente un producto.

En el caso de IoT, su alcance suele centrarse en aspectos como la arquitectura, los mecanismos de seguridad (autenticación, comunicaciones, actualizaciones, etc.) y la validación técnica. Es decir, cubren sobre todo la fase de diseño e implementación del producto.

Sin embargo, no suelen abarcar de forma completa el ciclo de vida del producto. Ese es precisamente el ámbito que refuerza el CRA, que introduce obligaciones continuas como la gestión de vulnerabilidades, el soporte de seguridad o la trazabilidad en el tiempo.

Esto implica que los vertical standards son una muy buena base técnica, pero deben complementarse con procesos de ciclo de vida para cumplir plenamente con el CRA.

En la práctica, un producto bien alineado con estos estándares tendrá gran parte del trabajo técnico ya resuelto, y el esfuerzo adicional estará en llevar esa base al terreno operacional y continuo.

Jesús Rodríguez es uno de los ingenieros de ciberseguridad del departamento de Cybersecurity & Digital Services de Alter Technology, con una trayectoria de 5 años en la compañía. Durante este tiempo, ha obtenido un gran conocimiento en dispositivos conectados y entornos de red trabajando con una gran variedad de clientes y fabricantes del área de las telecomunicaciones. En los últimos años se ha especializado en normativa europea de ciberseguridad (CRA, RED, EN18031), realizando evaluaciones de conformidad a fabricantes y participando activamente en las certificaciones. Dando así un plus de calidad a sus productos.