La Ley de Ciberresiliencia (en inglés Cyber Resilience Act o CRA) es un reglamento de la Unión Europea, formalizado como el Reglamento (UE) 2024/2847, que establece requisitos de ciberseguridad para los productos con elementos digitales en el mercado de la Unión. Esta normativa busca garantizar que tanto el hardware como el software conectado sean seguros durante todo su ciclo de vida, desde el diseño hasta su retirada. Contexto y objetivos Presentada por la Comisión Europea en 2022 y adoptada en 2024, la norma responde al aumento de los ciberataques y al coste del cibercrimen. El reglamento soluciona dos problemas estructurales: el bajo nivel de seguridad en los productos (vulnerabilidades y falta de actualizaciones) y la dificultad de los usuarios para identificar dispositivos seguros.
Disposiciones principales La ley obliga a fabricantes, importadores y distribuidores a cumplir requisitos esenciales para obtener el Marcado CE. Se impone el principio de "seguridad por diseño", exigiendo que los productos salgan de fábrica sin vulnerabilidades conocidas y con una configuración segura por defecto.
Asimismo, los fabricantes deben garantizar el manejo de vulnerabilidades y proporcionar actualizaciones de seguridad automáticas durante la vida útil del producto o un mínimo de cinco años. También se establece la obligación de notificar incidentes graves a la Agencia de la Unión Europea para la Ciberseguridad (ENISA) en un plazo de 24 horas.
Ámbito Material y Exclusiones
El CRA se aplica a cualquier producto cuya finalidad prevista o uso razonablemente previsible incluya una conexión de datos directa o indirecta, lógica o física, a un dispositivo o red. Esta definición es intencionalmente amplia, abarcando desde dispositivos del Internet de las Cosas (IoT), sistemas operativos, routers y microservicios, hasta aplicaciones de software comercializadas de forma independiente. Sin embargo, el Reglamento prevé una serie de exclusiones clave para evitar la superposición con otras normativas sectoriales de la UE o por razones de defensa y seguridad nacional. Las exclusiones más significativas incluyen:
Software de código abierto (FOSS): Los componentes de software libre y de código abierto que se suministran o ponen a disposición fuera de una actividad comercial o con fines no lucrativos no están cubiertos por el Reglamento. Sin embargo, si este software se comercializa o integra en un producto en el contexto de una actividad económica, sí estará sujeto a las obligaciones. Productos con regulaciones sectoriales específicas: Quedan excluidos los productos cuya ciberseguridad ya está cubierta exhaustivamente por otras normativas de la UE, tales como los dispositivos médicos y los vehículos a motor. Productos para defensa y seguridad nacional: Los productos diseñados o modificados para fines exclusivamente militares o de seguridad nacional también quedan fuera del ámbito de aplicación material del Reglamento.
Clasificación de productos y obligaciones El Reglamento (UE) 2024/2847 establece un marco de diferenciación para los productos con elementos digitales basado en su nivel de criticidad y el riesgo potencial de ciberseguridad que representan. Según la normativa, la gran mayoría de los dispositivos (se estima que alrededor del 90%) entran en la categoría de riesgo no crítico. Para estos productos, los fabricantes pueden realizar una autoevaluación de conformidad bajo su propia responsabilidad, garantizando que cumplen con los requisitos esenciales sin necesidad de una auditoría externa obligatoria.
No obstante, el reglamento identifica categorías específicas denominadas productos importantes y productos críticos, los cuales están sujetos a procedimientos de evaluación más rigurosos debido a su impacto en la seguridad de la red y los datos:
Clase I (Riesgo importante): Esta categoría incluye software y hardware clave para la seguridad pero de menor complejidad sistémica. Ejemplos citados en los anexos del reglamento incluyen navegadores web independientes, gestores de contraseñas, antivirus, cortafuegos (firewalls), redes privadas virtuales (VPN), gestores de arranque y sistemas operativos para routers de uso general. Para estos productos, se requiere la aplicación de una norma armonizada o, en su defecto, una evaluación por parte de un organismo notificado. Clase II (Mayor riesgo): Abarca productos de mayor complejidad técnica y riesgo de ataque. En este grupo se encuentran los sistemas operativos para servidores, equipos de sobremesa y dispositivos móviles, así como hipervisores, microprocesadores, routers de uso industrial, manipuladores de tokens seguros y tarjetas inteligentes. Para la Clase II, es obligatoria la intervención de un organismo de evaluación de la conformidad externo (tercera parte) para certificar la seguridad.
Además de la clasificación, el reglamento impone un régimen estricto de obligaciones post-venta a los fabricantes, importadores y distribuidores. Destaca el deber de gestión de vulnerabilidades, que obliga a proporcionar actualizaciones de seguridad automáticas y gratuitas durante la vida útil prevista del producto o por un periodo mínimo de cinco años. Asimismo, se establece la obligación de notificar cualquier incidente grave o vulnerabilidad explotada activamente a la Agencia de la Unión Europea para la Ciberseguridad (ENISA) y al CSIRT nacional correspondiente en un plazo máximo de 24 horas tras su detección. El incumplimiento de estas disposiciones puede conllevar sanciones administrativas de hasta 15 millones de euros o el 2,5% del volumen de negocios anual global.
Recepción Inicialmente, la propuesta de ley fue fuertemente criticada por los defensores del código abierto.
Algunas fundaciones de código abierto como la Eclipse Foundation, la Open Source Initiative (OSI) y The Document Foundation han firmado una carta abierta "Open Letter to the European Commission on the Cyber Resilience Act" en la que piden a los responsables políticos europeos que modifiquen la representación de toda esta comunidad de código abierto. Esta carta termina citando que con la política de «free and open source» más del 70% del software en Europa va a ser regulado sin siquiera consultarlo en profundidad, además que si esta se implementa con la redacción de abril sería muy limitante para el desarrollo de código abierto, lo que entra en conflicto con los objetivos ya expresados de la UE de innovación, soberanía digital y prosperidad a futuro.
También la Apache Software Foundation publicó un informe similar con estas quejas y la OSI presentó esta información reunida como solicitud a la Comisión Europea.
A pesar de que Mozilla ha valorado positivamente y apoya los objetivos principales de la ley, también ha criticado la propuesta al no haber referencias claras sobre la actividad comercial que puede incluir a múltiples proyectos de código abierto, la falta de alineación con otras normas de la UE y los requisitos para la divulgación de vulnerabilidades sin parchear.
Steven J. Vaughan-Nichols de The Register argumentó que la suposición subyacente de la CRA sobre seguridad en el software es problemática ya que muchos desarrolladores de código abierto no tienen los ingresos ni siquiera los recursos para garantizar tal seguridad a nivel del estándar gubernamental.
Las enmiendas se publicaron el 1 de diciembre de 2023 como parte de un acuerdo con los colegisladores ante el reclamo de múltiples defensores del código abierto. Como aportaron directores de la Fundación Eclipse, la revisión ha mejorado en términos de proyectos, comunidades, fundaciones de código abierto para su desarrollo y distribución. También remarcan la nueva figura de administrador que reconoce el rol que realizan plataformas o fundaciones como Apache o Eclipse.
La introducción de la figura del "administrador de código abierto" (open source steward), se ha interpretado como un reconocimiento del papel de las fundaciones y plataformas de software libre en la gobernanza de estos proyectos.
Otro suceso importante es el lanzamiento del Open Regulatory Compliance working group, un grupo para ayudar a la comunidad de pequeños desarrolladores con la regulación y especialmente en la CRA y facilitar las gestiones con los organismos reguladores. Oligaciones Específicas para Operadores Económicos El Reglamento de Ciberresiliencia (UE 2024/2847) establece un marco detallado de obligaciones para los distintos operadores económicos que participan en la cadena de suministro de productos con componentes digitales. Esta perspectiva integral persigue el objetivo central de garantizar que la responsabilidad en materia de ciberseguridad no sea un elemento secundario, sino que se incorpore y amplíe de forma constante desde las etapas iniciales del diseño de un producto, continúe durante su comercialización y se mantenga en la gestión de vulnerabilidades a lo largo de todo su ciclo de vida útil.
La estructura normativa del RCR es crucial, ya que traslada la carga de la ciberseguridad a lo largo de toda la cadena de suministro, desde el diseño inicial hasta la disponibilidad del producto en el mercado. La visión subyacente es que la ciberseguridad es un atributo de calidad no negociable que debe ser verificado en cada punto de la cadena.
I. Los Productores (Fabricantes): Responsabilidad Primordial y "Seguridad desde el Diseño" Los productores son los que tienen la responsabilidad principal de asegurar que los productos sean diseñados, concebidos y fabricados con un nivel inherente de ciberseguridad acorde al riesgo que representan. Sus obligaciones son las más amplias y se extienden a lo largo de todo el ciclo de vida del producto.Reglamento (UE) 2024/2847 del Parlamento Europeo y del Consejo, de 23 de octubre de 2024 (Artículo 13, Obligaciones de los fabricantes). Diario Oficial de la Unión Europea.
A. Principio de "Seguridad desde el Diseño y por Defecto" Para lograrlo, deben implementar de manera estricta el principio de "seguridad desde el diseño y por defecto" (security by design and by default). Esta doctrina esencial demanda que los aspectos de ciberseguridad sean un componente esencial e indispensable de todo el proceso de desarrollo del producto, desde su concepción y diseño inicial, pasando por la implementación y las pruebas, hasta su lanzamiento y mantenimiento continuo, en vez de ser características incorporadas después.Reglamento (UE) 2024/2847 del Parlamento Europeo y del Consejo, de 23 de octubre de 2024 (Artículo 18, Principios de seguridad por diseño). Diario Oficial de la Unión Europea.
El mandato de "Security by Design and by Default" obliga a:
Integración Temprana: La ciberseguridad debe ser parte esencial desde la concepción, garantizando que el proceso de desarrollo incorpore la seguridad en cada fase. Configuraciones Seguras por Defecto: Los productos deben ser entregados a los usuarios finales con la configuración más segura posible activada automáticamente, minimizando la superficie de ataque y los posibles errores de configuración por parte del usuario.
B. Gestión de Riesgos y Evaluación de la Conformidad Los compromisos concretos del fabricante comprenden llevar a cabo valoraciones de riesgos detalladas y registradas para detectar y reducir potenciales peligros.Reglamento (UE) 2024/2847 del Parlamento Europeo y del Consejo, de 23 de octubre de 2024 (Artículo 14, Evaluación de riesgos y documentación técnica). Diario Oficial de la Unión Europea. Asimismo, tienen que implementar procedimientos sólidos para manejar y tratar las vulnerabilidades durante todo el ciclo de vida del producto. Además, deben:
Documentación Técnica: Compilar y conservar la documentación técnica completa que demuestre que el proceso de diseño y producción ha cumplido con los requisitos esenciales del RCR.