El Acta de Resiliencia Cibernética (CRA) de la Unión Europea (UE) marca una regulación definitoria para todos los productos que contienen elementos digitales. Con el despliegue regulatorio completo marcado para el 11 de diciembre de 2027, y otros requisitos obligatorios que llegarán incluso antes, es esencial que los equipos de ingeniería y los gerentes de producto comprendan la legislación. Después de todo, los fabricantes tienen la responsabilidad principal de garantizar que todos los dispositivos cumplan con las normas antes de su lanzamiento al mercado.
Junto con la responsabilidad total en caso de incidentes de ciberseguridad, las sanciones por incumplimiento son severas:
- Multas de hasta 15 millones de euros o el 2.5% del volumen de negocios anual global, con productos no conformes prohibidos, retirados o retirados del mercado de la UE.
- Pérdida del marcado CE, lo que significa que los productos no pueden venderse legalmente en la UE.
- Posible exclusión automática de licitaciones y asociaciones, ya que muchas solicitudes de propuestas (RFP) requieren soluciones conformes con el CRA.
Además, los fabricantes que no cumplan corren el riesgo de perder credibilidad y confianza en el mercado, ya que los clientes de sectores críticos (como los del gobierno, financiero e industrial) evitan productos que carecen de garantías de seguridad integrales.
Dado estos riesgos, los diseñadores de sistemas deben ahora considerar las implicaciones de seguridad de las elecciones clave de hardware y software desde el inicio del proceso de diseño, ya que ambos afectarán el cumplimiento a largo plazo y, por lo tanto, el acceso al mercado. Este artículo definirá los principales compromisos de seguridad de un fabricante bajo el CRA antes de destacar las actualizaciones por aire (OTA) como una estrategia poderosa para mantener el cumplimiento a largo plazo. Luego delineará un marco de software robusto para entregar estas actualizaciones de manera segura y proporcionará un ejemplo de una solución comercial disponible en el mercado (COTS) que se alinea con estos principios.
Compromisos de seguridad bajo el CRA
Desde dispositivos de consumo hasta componentes de infraestructura distribuida, los sistemas modernos de borde sufren de un número creciente de vulnerabilidades de seguridad. Los problemas de firmware obsoleto y los protocolos de comunicación inseguros pueden llevar a violaciones de datos y accesos no autorizados que comprometen la integridad del dispositivo. En consecuencia, el CRA exige varias medidas para mantener una superficie de ataque mínima:
Primero, los fabricantes deben proteger los dispositivos contra manipulaciones no autorizadas y garantizar la integridad del software desde el primer arranque. Aunque el CRA no define un marco específico para lograr esto, el arranque seguro, en combinación con una raíz de confianza (RoT), sirve como una base fundamental para cumplir con este requisito.
El arranque seguro utiliza criptografía para garantizar que solo el software auténtico y verificado se ejecute en el dispositivo. Esta RoT forma el primer eslabón en una cadena de confianza que autentica cada etapa del proceso de arranque para asegurar la integridad del dispositivo, como se muestra en Figura 1. Si, por ejemplo, un hash de un componente de software está cifrado con una clave privada que no coincide con las claves públicas en la RoT, ya sea debido a manipulación o corrupción, el proceso de arranque se detendrá o restringirá las capacidades del sistema superior (como el acceso a la red) para evitar que potenciales malware o botnets se propaguen.
Los fabricantes deben asegurar la integridad a través de una gestión continua de vulnerabilidades y actualizaciones de seguridad oportunas durante todo el ciclo de vida del producto. El CRA define un período de soporte obligatorio de al menos 5 años, o la vida útil esperada del producto si es más corta, y requiere que los fabricantes proporcionen una fecha de fin de soporte especificada al momento del lanzamiento al mercado.
Cuando se descubre una vulnerabilidad explotada activamente, los fabricantes deben divulgarla a su Equipo Nacional de Respuesta a Incidentes de Seguridad Informática (CSIRT) y a la Agencia Europea de Seguridad de Redes e Información (ENISA), la agencia de ciberseguridad de la UE. Este compromiso de reporte entra en vigor el 11 de septiembre de 2026, con los siguientes requisitos de tiempo:
- 24 horas: Los informes de advertencia temprana deben enviarse a ENISA y al CSIRT nacional.
- 72 horas: Debe generarse una notificación formal de vulnerabilidad que detalle el exploit y cómo afecta a un sistema.
- 14 días: Debe presentarse un informe final una vez que esté disponible un parche de seguridad.
Naturalmente, la gestión continua de vulnerabilidades requiere algún nivel de monitoreo de amenazas en tiempo real. Los marcos públicos como el sistema de Vulnerabilidades y Exposiciones Comunes (CVE) pueden ayudar a los fabricantes a detectar y parchear nuevas amenazas en componentes de software de terceros, incluso antes de que sean explotadas activamente dentro de sus propios dispositivos.
Como apoyo a lo anterior, el CRA también obliga a los fabricantes a mantener documentación técnica para cada actualización. En particular, debe proporcionarse una software bill-of-materials (SBOM) en un formato legible por máquina, como CycloneDX o SPDX, que cubra al menos todas las dependencias de primer nivel. Este formato permite a las herramientas automatizadas analizar cada build software frente a bases de datos CVE para identificar nuevas vulnerabilidades en cuanto son notificadas. Los equipos DevSecOps pueden entonces distribuir parches que corrigen problemas internos sin introducir software de terceros.
Además de las SBOM, la conformidad con el CRA requiere una documentación extensa que incluya una evaluación de alto nivel de los riesgos de seguridad, diagramas de la arquitectura del sistema con una descripción del proceso de desarrollo y descripciones del proceso de gestión de vulnerabilidades (véase la Figura 2). Estos elementos se utilizan para verificar que el sistema sea secure-by-design conforme a las directrices del CRA. La documentación registrada debe conservarse durante todo el ciclo de vida del dispositivo y ponerse a disposición de auditores, autoridades de vigilancia y organismos notificados durante 10 años después de la introducción en el mercado, o durante la duración de un periodo de soporte más largo.
Por último, una declaración formal de conformidad (DoC) permite a los fabricantes utilizar el marcado CE para acceder al mercado de la UE. El documento DoC contiene información como el nombre y la dirección del fabricante, una identificación única del producto y referencias a los estándares y especificaciones técnicas utilizados para demostrar la conformidad. Para determinados productos digitales que entran en las categorías CRA “Important Class I”, “Important Class II” y “Critical”, también deben incluirse los datos de un auditor externo encargado de verificar la conformidad. Entre estos dispositivos se incluyen sistemas de control industrial, gateways IoT y software para accesos privilegiados, en los que eventuales brechas podrían causar daños más amplios a las infraestructuras.
Al firmar una DoC, los fabricantes asumen plena responsabilidad por la conformidad con el CRA. Considerando el alcance de estos compromisos, las actualizaciones OTA representan la forma más eficaz de distribuir rápidamente parches y mantener la integridad de los dispositivos conectados. Sin embargo, las actualizaciones OTA continuas requieren una arquitectura software sofisticada, diseñada específicamente para soportar actualizaciones alineadas con el CRA.
Diseñar una infraestructura software para parches de seguridad OTA periódicos
Según el CRA, los equipos DevSecOps trabajan bajo una fuerte presión temporal cuando deben identificar, caracterizar y resolver problemas de seguridad tras su descubrimiento. Para simplificar la gestión de la seguridad, los dispositivos embebidos se benefician de los siguientes ajustes arquitectónicos:
- Integrated telemetry reporting: al recopilar datos sobre el estado de salud de los dispositivos y enviarlos a una plataforma cloud, los fabricantes pueden identificar rápidamente bugs o exploits en los dispositivos conectados. El telemetry reporting también permite a los equipos verificar la eficacia de los nuevos parches en pruebas reales limitadas antes del rollout en toda la flota.
- Arquitectura software altamente modular y containerizada: el aislamiento de amenazas contribuye a reducir la superficie de ataque si un dispositivo se ve comprometido. Por ejemplo, la containerización impide que un ataque a la interfaz de usuario pueda acceder al código core del sistema operativo (OS). También permite que los componentes software individuales sigan funcionando mientras otros se actualizan, reduciendo el downtime operativo. Del mismo modo, el software modular acelera la identificación de vulnerabilidades y reduce los requisitos de datos OTA —y por tanto los costes— en comparación con actualizaciones de código monolíticas.
- Mecanismos de rollback: las interrupciones y anomalías durante las actualizaciones OTA pueden impedir la correcta instalación de los parches, causando potencialmente el bricking del dispositivo. Los mecanismos de rollback garantizan que un dispositivo siempre pueda volver a un estado operativo si una actualización falla, permitiendo a los fabricantes cumplir los compromisos previstos por el CRA y mantener la integridad del dispositivo.
Como es comprensible, las actualizaciones OTA seguras requieren túneles cifrados end-to-end para garantizar que los parches no puedan verse comprometidos durante la transmisión y que solo firmware firmado y verificado pueda ejecutarse en un dispositivo. Para satisfacer los requisitos de documentación relativos a cada parche publicado, los fabricantes se benefician de frameworks de desarrollo software que proporcionan generación automatizada de SBOM y logging.
Sin embargo, implementar frameworks alineados con el CRA puede representar una carga significativa para los desarrolladores que construyen software desde cero, especialmente con plazos regulatorios que se acercan rápidamente. Afortunadamente, las soluciones COTS pueden ayudar a los equipos a cumplir los requisitos de compliance en los tiempos previstos.
Aprovechar frameworks software COTS para la alineación con el CRA
Los frameworks software COTS ofrecen diversas ventajas especialmente relevantes para el CRA. La primera es la aceleración del desarrollo para reducir el time-to-market. Del mismo modo, aunque la responsabilidad legal del cumplimiento sigue recayendo en los fabricantes, las soluciones de terceros ya probadas también pueden reducir el riesgo de incurrir en blind spots regulatorios. Además, al colaborar con partners comerciales, los fabricantes pueden obtener soporte adicional a largo plazo para su infraestructura software, aliviando aún más la carga de los desarrolladores.
Un ejemplo de este tipo de solución es Clea OS de SECO, una arquitectura software personalizable diseñada para sistemas seguros de nivel industrial y dotada de muchas funcionalidades que simplifican el cumplimiento del CRA. Basado en el proyecto open-source Yocto, Clea OS ofrece reproducibilidad y trazabilidad para las auditorías CRA, con funcionalidades de generación automatizada de SBOM en apoyo de las obligaciones documentales.
A diferencia de muchos sistemas operativos cerrados, Clea OS está concebido como una base Linux OS ligera y controlada, que minimiza los componentes innecesarios para reducir la superficie de ataque y mejorar la seguridad y la resiliencia generales. La containerización está habilitada mediante Docker para aislar amenazas y permitir la operatividad 24/7 durante las actividades de patching. Esto se apoya además en el particionamiento A/B, que asegura la presencia constante de una imagen firmware funcional en el dispositivo y permite el rollback del firmware activo en caso de fallo de una actualización.
Además, Clea OS soporta secure boot, actualizaciones OTA firmadas digitalmente, monitorización continua de dispositivos en tiempo real en combinación con el ecosistema Clea más amplio de SECO (como se ilustra en la Figura 3) y un Cyber Security Package. Al permitir que los fabricantes maximicen las oportunidades de detección de amenazas y patching, este soporte facilita el cumplimiento de los requisitos del CRA relativos a largos periodos de soporte, abordando directamente requisitos clave como mecanismos de actualización seguros, gestión continua de vulnerabilidades e integridad del sistema.
La existencia de soluciones COTS, entre ellas Clea OS de SECO, demuestra que el cumplimiento del CRA no tiene por qué ser tan complejo como podría parecer inicialmente. Al animar a los equipos de desarrollo a utilizar frameworks software listos para usar que permiten altos niveles de personalización, los fabricantes pueden simplificar la transición hacia un nuevo escenario de ciberseguridad, llevando al mismo tiempo al mercado productos diferenciados.