Guía de la Comisión Europea sobre la Cyber Resilience Act

La Comisión Europea está elaborando una Comunicación que ofrecerá orientaciones prácticas sobre cómo aplicar el Reglamento (UE) 2024/2847 conocido como Cyber Resilience Act (CRA). Esta norma se articula como un marco horizontal de requisitos de ciberseguridad para los productos con elementos digitales y busca reforzar la ciberresiliencia y el funcionamiento del mercado interior. La Cyber Resilience Act se adoptó en 2024 y será aplicable en su totalidad a partir del 11 de diciembre de 2027. No obstante, el Capítulo IV (artículos 35 a 51) será aplicable desde el 11 de junio de 2026 y el artículo 14 (obligaciones de notificación) será aplicable desde el 11 de septiembre de 2026.

El objetivo declarado de la guía de la Comisión es ayudar a fabricantes, desarrolladores y demás agentes sujetos a esta norma a comprender con mayor precisión sus obligaciones y promover una aplicación coherente del Reglamento en toda la UE. En el proceso de elaboración, la Comisión ha organizado una consulta pública sobre el borrador, cuyos resultados pueden consultarse en su sitio web. La guía, que no será vinculante, se adoptará formalmente cuando estén disponibles todas las versiones lingüísticas y refleja la interpretación de la Comisión.

¿Qué persigue la guía sobre la aplicación de la CRA?

La guía responde al mandato de la propia CRA de ofrecer orientaciones para facilitar su aplicación, con especial atención a microempresas y pymes, y cubrirá, al menos: (i) el ámbito de aplicación (en particular, soluciones de tratamiento de datos a distancia y software libre y de código abierto), (ii) periodos de soporte, (iii) interacción con otra normativa de la UE, y (iv) el concepto de “modificación sustancial”.

Principales contenidos del borrador de guía publicado por la Comisión

A continuación se resumen los ejes más relevantes del borrador sometido a consulta, siguiendo su estructura y los puntos donde previsiblemente se concentrará el impacto práctico para operadores económicos.

1. Alcance de la CRA: “puesta en el mercado”, software, código fuente y conexión de datos

El borrador dedica un bloque significativo a aclarar el alcance material de la CRA y, en particular, cuándo un producto (incluido el software) se considera “puesto en el mercado”. Para el software distribuido por medios digitales, el borrador de la guía indica que la “puesta en el mercado” se produciría, en esencia, cuando la versión se ofrece por primera vez para distribución o uso en el mercado de la UE, y ofrece ejemplos para ilustrar cómo tratar versiones sucesivas.

También aclara cuestiones prácticas sobre combinaciones de hardware y software, tratamiento del código fuente cuando se suministra en el curso de una actividad comercial, la noción de “conexión de datos” (más allá del simple uso de señales eléctricas) y el encaje de sistemas complejos (incluidos aquellos con ciclos de vida largos, dependencias heredadas y restricciones de interoperabilidad), reforzando una lectura basada en el enfoque de riesgo del CRA.

2. Software libre y de código abierto (FOSS): cuándo se aplica la CRA y la figura del administrador (steward)

Uno de los capítulos más sensibles del borrador aborda el tratamiento del free and open-source software (FOSS). La guía propone criterios para determinar cuándo un FOSS queda “bajo la responsabilidad” de un agente y cuándo, por el modo de suministro/monetización, puede considerarse “puesto en el mercado” a efectos de la CRA. Incluye ejemplos de monetización (p. ej., por soporte, servicios asociados, determinados modelos basados en datos personales, donaciones, etc.) y escenarios ilustrativos sobre integración en productos de terceros.

Asimismo, desarrolla la figura de la entidad administradora (open-source software steward), con referencias al concepto de soporte sostenido y a supuestos en los que una misma entidad puede actuar como fabricante para ciertos proyectos y como administradora para otros, con obligaciones diferenciadas.

3. “Modificación sustancial”: reparaciones, repuestos y actualizaciones de software

Otro eje central es la “modificación sustancial”, definida (en síntesis) como un cambio posterior a la puesta en el mercado que afecte al cumplimiento de requisitos esenciales de ciberseguridad o modifique el propósito previsto evaluado. La guía examina cómo tratar reparaciones físicas, repuestos (incluida la distinción entre repuesto “idéntico” y no idéntico) y, especialmente, actualizaciones de software en un contexto de desarrollo iterativo.

Resulta particularmente relevante la orientación de que las actualizaciones de seguridad no deberían considerarse, por regla general, modificaciones sustanciales si se limitan a reducir el riesgo sin alterar el propósito previsto ni introducir nuevos riesgos; y, a la inversa, que incluso cambios aparentemente menores pueden ser sustanciales si alteran materialmente el perfil de riesgo o introducen nuevas superficies de ataque no contempladas.

4. Periodo de soporte: criterio general, mínimo y particularidades para software

Se dedica un apartado específico al periodo de soporte y a cómo determinarlo conforme a la CRA, recordando que el fabricante debe fijarlo considerando criterios de proporcionalidad y que opera un mínimo general de cinco años, salvo que la vida útil del producto con elementos digitales sea inferior. También detalla obligaciones de transparencia (p. ej., indicar la fecha de fin de soporte: al menos mes y año) y el sentido práctico del régimen para productos software con versiones sucesivas.

En el caso de software, la guía admite flexibilidad para dejar de subsanar versiones antiguas cuando los usuarios puedan actualizar a la versión más reciente sin costes adicionales, entendiéndose por tales los costes derivados de dicha actualización, y exigiendo informar adecuadamente al usuario sobre la disponibilidad de la actualización y el fin del soporte de la versión anterior.

5. Productos “importantes” y “críticos”: “funcionalidad esencial” y evaluación de conformidad

El borrador desarrolla el concepto de “funcionalidad esencial” (“core functionality”) como clave para clasificar un producto en las categorías de la CRA (por referencia a anexos y categorías) y, con ello, determinar el procedimiento de evaluación de conformidad aplicable (incluida la lógica de cuándo puede bastar una autoevaluación y cuándo resulta necesaria una evaluación por tercero). Aporta ejemplos (p. ej., sistemas operativos, integración de componentes importantes/críticos en un producto con funcionalidad núcleo distinta) y matiza el alcance de la presunción de conformidad cuando se aplican normas armonizadas que cubren solo parte de los riesgos o funcionalidades.

6. Evaluación de riesgos

En línea con el enfoque del CRA, el borrador insiste en que el fabricante debe realizar una evaluación de riesgos de ciberseguridad y adoptar medidas a nivel de producto para mitigarlos; y, además, ejercer diligencia debida respecto de componentes integrados y dependencias externas. Subraya que la CRA no prevé “transferir” el riesgo a usuarios o terceros mediante meras instrucciones y que la aceptación del riesgo residual se mide por referencia a un umbral regulatorio (nivel de ciberseguridad adecuado según riesgos), y no por el nivel interno de aceptación del riesgo o por criterios puramente comerciales.

7. Tratamiento de datos a distancia (RDPS): cuándo forma parte del producto

El borrador ofrece un test en tres pasos para determinar las soluciones de tratamiento remoto de datos (“remote data processing solution” – “RDPS”) que deben quedar incluidas en el producto: si el tratamiento es “a distancia”, si su ausencia impediría una función del producto y si el software está diseñado o desarrollado por el fabricante o bajo su responsabilidad. También distingue entre RDPS y servicios de terceros no desarrollados bajo responsabilidad del fabricante (que deberían tratarse, en su caso, como “componentes” desde la perspectiva de riesgos y diligencia debida), e incorpora casos de uso (p. ej., aplicación bancaria, termostato inteligente, e-reader, robot industrial, red celular).

8. Obligaciones de notificación (vulnerabilidades explotadas e incidentes graves)

El borrador incluye orientaciones sobre cuándo se considera que el fabricante “tiene conocimiento” de una vulnerabilidad activamente explotada o un incidente grave que compromete la seguridad del producto, y recuerda la lógica escalonada de notificaciones (aviso temprano y posteriores actualizaciones) y el deber de informar a usuarios afectados, con matices de proporcionalidad (por ejemplo, en entornos sensibles).