La Comisión Europea recopila en una guía los criterios prácticos de aplicación del reglamento de ciberresiliencia

La Comisión Europea ha publicado, el 3-3-2026, un borrador de guía sobre la aplicación del Reglamento (UE) 2024/2847¹ (conocido como reglamento de ciberresiliencia, o Cyber Resilience Act), con el fin de ayudar a los operadores económicos —en particular, microempresas y pymes— a aplicar este reglamento y a homogeneizar su supervisión.

Resumimos los puntos principales de este borrador de guía.

Uso de la guía

Esta guía no será vinculante y la prepara la Comisión por mandato del reglamento de ciberresiliencia (artículo 26).

Ofrece criterios operativos que pueden ser muy útiles para preparar la aplicación de la norma, sobre todo para:

• fabricantes de software distribuido digitalmente;
• empresas que integran componentes de otros fabricantes, incluidos componentes de software libre y código abierto;
• operadores que dependen de servicios en la nube o de tratamiento remoto de datos, y
• entidades que deban documentar la evaluación de riesgos, el período de soporte y los criterios de actualización (artículos 13, 14, 24, 26 y 32 del reglamento).

Aclaraciones del borrador de guía

El documento aclara varias cuestiones del reglamento que resumimos en los apartados siguientes.

Consideración de «software puesto en el mercado»

Si un software autónomo está distribuido digitalmente, la puesta en el mercado se produce cuando la versión correspondiente ha finalizado su fase de fabricación y se ofrece por primera vez para distribución o uso en la Unión Europea en el curso de una actividad comercial.

Las descargas posteriores de esa misma versión no alteran esa fecha, salvo que hay una modificación sustancial (artículo 3.30 del reglamento).

Cuando un hardware necesite un software concreto para cumplir su función, ambos deben tratarse como un único producto con elementos digitales, aunque este se descargue por separado.

Tratamiento del software libre y el de código abierto

La clave es distinguir cuándo se suministra este software en una actividad comercial y cuándo no. En este sentido, el borrado aclara lo siguiente:

1. Este software se considera puesto en el mercado:
   • cuando se cobre un precio,
   • cuando sirva para monetizar otros productos o servicios, o
   • cuando se condicione su uso al tratamiento de datos personales para finalidades distintas de la seguridad, compatibilidad o interoperabilidad.
2. La oferta separada de servicios opcionales de soporte, en cambio, no convierte por sí sola al software en producto comercializado (artículos 3.14, 3.48 y 24 del reglamento).
3. Las donaciones no se califican por sí solas como actividad comercial, salvo que funcionen en la práctica como contraprestación para acceder al software, a sus prestaciones esenciales o a sus actualizaciones.
4. El desarrollo de la figura del «open-source software steward», esto es, la persona jurídica que presta apoyo sostenido a un software libre o de código abierto destinado a actividades comerciales sin llegar a ser el fabricante de ese software.

Modificación sustancial

No cualquier actualización, reparación o sustitución de componentes constituye una modificación sustancial (esta precisión es relevante para los artículos 21, 22 y 69.2 del reglamento). Para que exista, el cambio debe:

• afectar al cumplimiento de los requisitos esenciales de ciberseguridad, o
• alterar la finalidad prevista del producto evaluada inicialmente.

Por tanto:

1. las actualizaciones de seguridad no tienen que considerarse modificaciones sustanciales cuando su finalidad sea reducir el riesgo y no introduzcan nuevas dependencias, nuevos vectores de ataque o un cambio de finalidad del producto, pero
2. sí puede haber modificación sustancial si la actualización altera de forma material la arquitectura de confianza, los flujos de datos o la funcionalidad originalmente evaluada.

Fijación del período de soporte

El período de soporte (artículo 13.8 del reglamento) debe ser, como mínimo, de cinco años, salvo que el tiempo de uso esperado del producto sea menor.

Pero esos cinco años no son un plazo estándar para todos los productos. Si un producto está razonablemente destinado a usarse más tiempo, el soporte deberá extenderse en consecuencia.

Además, el fabricante:

• debe informar claramente en el momento de la compra de la fecha final del soporte (artículo 13.19), y
• puede concentrar la remediación de vulnerabilidades del software en la última versión comercializada (artículo 13.10), siempre que los usuarios puedan actualizar gratuitamente y sin costes adicionales relevantes.

Clasificación de productos importantes y críticos

El borrador se centra en el núcleo funcional (core functionality) del producto. Es esa ‘funcionalidad principal‘ la que determina si el producto es ordinario, importante o crítico y, por tanto, el régimen de evaluación de la conformidad aplicable (artículos 7, 8 y 32 del reglamento).

Además:

• la mera integración de un componente importante o crítico no convierte automáticamente al producto final en uno de esas categorías, y
• el fabricante no puede presentar artificialmente la funcionalidad principal del producto de forma que eluda el régimen reforzado de evaluación de conformidad (incumplir esta obligación puede generar las sanciones previstas en el artículo 64.3).

Soluciones de procesamiento remoto de datos

El borrador de guía entiende que existe una solución de procesamiento remoto de datos (remote data processing solution) (artículo 3.2 del reglamento) cuando concurran tres elementos:

1. que haya tratamiento de datos a distancia;
2. que la ausencia de ese tratamiento impida al producto desempeñar una de sus funciones, y
3. que el software lo haya diseñado y desarrollado el fabricante o bajo su responsabilidad.

Aclara también que si la solución remota es esencial para el funcionamiento del producto, pero la ha  desarrollado otra persona:

• no tendrá esa calificación en sentido estricto;
• pero tendrá que tratarse como una dependencia externa o un componente integrado, con la consiguiente obligación de evaluación de riesgos y de diligencia debida (artículo 13.5).

El borrador ejemplifica esta distinción con varios ejemplos como una aplicación bancaria, un termostato inteligente, un lector de libros electrónicos y un robot industrial.

Notificación de vulnerabilidades y coordinación normativa

El borrador de guía precisa cuándo un fabricante debe considerarse conocedor de una vulnerabilidad explotada activamente o de un incidente grave (artículo 14):  cuando, tras una evaluación inicial, disponga de un grado razonable de certeza.

Desde ese momento comienzan a correr los plazos de 24 o 72 horas, 14 días o un mes, según el tipo de notificación.

Por último, aclara también la interacción del reglamento de ciberresiliencia con otras normas:

1. recuerda la exclusión de determinados productos cubiertos por los reglamentos (UE) 2019/2144,² o (UE) n.º 168/2013,³ y
2. explica cómo pueden aprovecharse, hasta ciertos límites temporales, certificados o decisiones ya emitidos bajo otra normativa sectorial, sin que ello dispense de la evaluación global de riesgos.

Nota final

Al tratarse de un borrador de guía, el contenido todavía puede cambiar. No obstante, refleja el enfoque de la Comisión para la aplicación práctica del reglamento de ciberresiliencia y para la actuación de las autoridades competentes.

También apunta la Comisión a futuras interacciones con otras  normas, como los reglamentos (UE) 2024/1689⁴ y (UE) 2022/2554.⁵