La ciberseguridad de un producto electrónico ya no puede quedar pendiente para la fase de certificación. El Cyber Resilience Act introduce requisitos que condicionan decisiones tomadas durante su diseño y desarrollo.
Qué es el Cyber Resilience Act y a qué productos afecta
El Cyber Resilience Act establece requisitos de ciberseguridad para determinados productos que incorporan funciones digitales y se comercializan en la Unión Europea.
Del producto conectado al producto con elementos digitales
El CRA, aprobado mediante el Reglamento (UE) 2024/2847, afecta tanto a productos completos como a determinados componentes que se comercializan por separado.
Wi-Fi, Bluetooth y otras tecnologías de comunicación forman parte de productos cada vez más diversos. Cuando un dispositivo puede intercambiar información con otros equipos o redes, también aparecen riesgos relacionados con su seguridad, su funcionamiento y la información que gestiona.
La evolución tecnológica ha hecho más compleja la seguridad de estos productos. Para una empresa que desarrolla hardware y software, las cuestiones de ciberseguridad están relacionadas con la arquitectura electrónica, las comunicaciones, el firmware y la gestión posterior del producto.
El CRA entró en vigor el 10 de diciembre de 2024. Sus principales obligaciones serán aplicables desde el 11 de diciembre de 2027, aunque las obligaciones de notificación de vulnerabilidades e incidentes empezarán a aplicarse el 11 de septiembre de 2026.
La ciberseguridad empieza durante el desarrollo del producto
El CRA incorpora requisitos que afectan a la planificación, el diseño, el desarrollo, la producción y el mantenimiento de los productos con elementos digitales. La evaluación de riesgos de ciberseguridad debe formar parte del desarrollo.
Evaluar los riesgos antes de tomar decisiones de diseño
El fabricante tiene que identificar los riesgos asociados al producto y utilizar ese análisis para determinar las medidas necesarias, documentándolas como parte de la información técnica exigida por el reglamento.
Esto condiciona decisiones que en muchos proyectos se toman mucho antes de pensar en la certificación. La arquitectura del hardware, la selección de componentes, las interfaces de comunicación, el firmware o los mecanismos de actualización pueden afectar directamente a la superficie de ataque del producto.
Por eso, el concepto de security by design tiene una aplicación muy concreta en ingeniería. La seguridad debe considerarse al definir la arquitectura y no añadirse cuando el hardware ya está cerrado y el producto preparado para producción.
Una modificación tardía puede obligar a revisar diseños, componentes, software o pruebas ya realizadas. Anticipar estos requisitos permite detectar antes los problemas que podrían comprometer la conformidad del producto.
Hardware, software y componentes también forman parte de la seguridad
La ciberseguridad de un producto no depende de una única capa. Las decisiones tomadas sobre sus componentes y sobre la relación entre hardware, firmware y software pueden condicionar el resultado final.
La seguridad debe integrarse en toda la arquitectura
Integrar un componente desarrollado por un tercero no exime al fabricante de su responsabilidad sobre el producto que pone en el mercado. El análisis debe contemplar los elementos que forman parte del producto y los riesgos que pueden introducir.
La arquitectura electrónica y el software deben avanzar de forma coordinada. Una vulnerabilidad puede estar relacionada con un componente, una interfaz de comunicación, una función del firmware o una aplicación que interactúa con el dispositivo.
El CRA establece requisitos específicos para la gestión de vulnerabilidades y exige que el fabricante las gestione durante el periodo de soporte. Esto incluye procesos para identificar, corregir y comunicar vulnerabilidades de acuerdo con las obligaciones establecidas.
Qué ocurre cuando el producto llega al mercado
Durante el ciclo de vida del producto, el fabricante mantiene responsabilidades relacionadas con la ciberseguridad y la gestión de vulnerabilidades.
Notificación de vulnerabilidades e incidentes
Desde el 11 de septiembre de 2026, los fabricantes deberán notificar las vulnerabilidades explotadas activamente y determinados incidentes graves que afecten a la seguridad de sus productos con elementos digitales. La primera alerta deberá presentarse en un plazo de 24 horas desde que el fabricante tenga conocimiento del problema y la notificación completa, en un plazo de 72 horas.
Esto requiere disponer de procesos capaces de detectar vulnerabilidades, evaluar su impacto y responder con rapidez. La gestión de seguridad deja de estar vinculada únicamente al lanzamiento y pasa a formar parte de la operación del producto durante su periodo de soporte.
También conviene distinguir entre los productos nuevos y los que ya están comercializados. Los productos con elementos digitales puestos en el mercado antes del 11 de diciembre de 2027 quedan sujetos a las obligaciones principales del CRA cuando, a partir de esa fecha, sean objeto de una modificación sustancial. Las obligaciones de notificación, en cambio, se aplicarán también a productos que ya estuvieran en el mercado.
El CRA también afecta a la conformidad del producto
Para comercializar un producto en la Unión Europea, el fabricante debe demostrar que cumple los requisitos de ciberseguridad que le correspondan.
No todos los productos siguen el mismo proceso de evaluación
El CRA establece distintos procedimientos de evaluación de conformidad. La mayoría de productos pueden seguir procedimientos internos, mientras que determinadas categorías consideradas importantes o críticas requieren una evaluación más exigente y, en algunos casos, la intervención de un organismo notificado.
Una vez cumplidos los requisitos aplicables, el producto debe completar el proceso de conformidad correspondiente y llevar el marcado CE. La documentación técnica y las evidencias generadas durante el desarrollo forman parte de ese proceso.
Preparar el producto desde el principio
Para Centrius, el CRA plantea una cuestión de ingeniería antes que de certificación: cómo incorporar los requisitos de ciberseguridad a un producto que todavía se está diseñando.
La certificación se prepara mucho antes de solicitarla
Cuando un producto ya está diseñado, los cambios necesarios para corregir un problema de ciberseguridad pueden afectar al hardware, al software, a los componentes o incluso al proceso de fabricación. Por eso revisamos estos aspectos durante la concepción del producto, cuando todavía podemos tomar decisiones con margen y evitar problemas en fases avanzadas del desarrollo.
También trabajamos con empresas que ya tienen productos en el mercado y necesitan adaptarlos a las nuevas exigencias. El CRA plantea así una necesidad tanto para nuevos desarrollos como para determinados productos existentes.
La ingeniería de producto debe conectar arquitectura, hardware, software, componentes, pruebas, documentación y conformidad desde las primeras fases. El objetivo es llegar al final del desarrollo con un producto preparado para cumplir los requisitos que le corresponden, no descubrirlos cuando todo lo demás ya está decidido.
