Preguntas frecuentes sobre la Ley de Ciberresiliencia de la UE

Sí, si se cumplen las condiciones de ámbito de aplicación de la CRA. Un producto con elementos digitales puede ser software, hardware, una solución de tratamiento de datos a distancia que forme parte del producto o un componente de software o hardware comercializado por separado.

El software suministrado como producto puede estar incluido en el ámbito de aplicación si cumple la definición de la CRA y las condiciones de comercialización. Esto incluye las aplicaciones independientes y el firmware. Aplique las mismas condiciones de ámbito a las herramientas de desarrollo y a los componentes de software, en vez de decidir según su denominación.

Más información en Productos incluidos en el ámbito de aplicación.

El SaaS independiente o un servicio en la nube desarrollado fuera de la responsabilidad del fabricante no constituye automáticamente un producto con elementos digitales. Una función en la nube es pertinente para la CRA cuando cumple la definición de tratamiento de datos a distancia.

El tratamiento de datos a distancia forma parte del producto cuando se realiza a distancia, el producto lo necesita para ejecutar una de sus funciones y el software de tratamiento ha sido diseñado o desarrollado por el fabricante o bajo su responsabilidad.

Más información en Productos incluidos en el ámbito de aplicación.

No. La CRA utiliza conceptos de conexión de datos, no una regla simple basada en el acceso a internet. Una conexión puede ser lógica o física, directa o indirecta.

Entre los ejemplos pertinentes se incluyen:

• conexiones lógicas mediante API, sockets de red, tuberías, archivos, sesiones HTTPS del navegador o protocolos de correo electrónico;
• conexiones físicas mediante USB, Ethernet, fibra, bus de campo, Wi-Fi, Bluetooth, NFC u otros enlaces de radio;
• conexiones indirectas mediante un sistema anfitrión que, a su vez, pueda conectarse a un dispositivo o a una red.

Más información en Productos incluidos en el ámbito de aplicación.

Por lo general, no. La Guía Azul explica que no hay comercialización cuando un producto se fabrica para uso propio. La Comisión aplica este criterio en sus preguntas frecuentes a ejemplos de la CRA, como las herramientas de desarrollo y configuración que un fabricante crea para uso propio.

La respuesta cambia si posteriormente la herramienta se comercializa como producto independiente. En ese caso, debe evaluarse como cualquier otro producto de software o hardware con elementos digitales.

Más información en Comercialización.

Los productos comercializados antes del 11 de diciembre de 2027 no quedan sujetos a todos los requisitos de la CRA solo por llegar esa fecha. Quedarán sujetos a esos requisitos si, a partir de esa fecha, se someten a una modificación sustancial.

La obligación de notificación del artículo 14 es distinta. Se aplica desde el 11 de septiembre de 2026 a los productos con elementos digitales incluidos en el ámbito de aplicación de la CRA, incluidos los comercializados antes del 11 de diciembre de 2027.

Más información en Comercialización y Notificación de vulnerabilidades.

Las preguntas frecuentes de la Comisión distinguen las unidades ya comercializadas de las que se comercialicen por primera vez. Las unidades que ya se hayan comercializado pueden seguir poniéndose a disposición cuando venza el período de soporte declarado.

Las unidades comercializadas por primera vez son distintas. Si el fabricante comercializa unidades adicionales, debe establecer para ellas un período de soporte con arreglo al artículo 13(8).

Más información en Período de soporte.

No. El suministro gratuito no determina por sí solo la respuesta. La CRA distingue entre el desarrollo no comercial de software libre y de código abierto y el software comercializado en el marco de una actividad comercial.

Las orientaciones de julio de 2026 distinguen el acceso de pago al software o a su mantenimiento de los servicios opcionales relacionados con software disponible gratuitamente. Las ediciones de pago pueden constituir suministro comercial; la consultoría opcional por sí sola no convierte la versión gratuita en comercial. La monetización de servicios a través del software, o la exigencia de tratar datos personales —más allá de lo necesario para mejorar la seguridad, la compatibilidad o la interoperabilidad del software— como condición de uso, también puede hacer que el suministro sea comercial.

Más información en Funciones y obligaciones y Productos incluidos en el ámbito de aplicación.

Sí, pero únicamente conforme a la regla de pruebas del artículo 4(3). El software solo debe ponerse a disposición durante el período limitado necesario para las pruebas y debe indicar claramente que no cumple la CRA y que no estará disponible para fines distintos de las pruebas.

Las preguntas frecuentes de la Comisión también remiten al considerando 37: el fabricante debería publicar ese software solo después de una evaluación de riesgos y debería cumplir, en la medida de lo posible, los requisitos de seguridad y de gestión de vulnerabilidades.

Sí. El artículo 13(11) permite mantener archivos públicos de software para mejorar el acceso de los usuarios a versiones históricas. Se debe informar a los usuarios de forma clara y fácilmente accesible sobre los riesgos del software sin soporte.

Un archivo no equivale a soporte activo. La cuestión es si el usuario puede entender que la versión archivada ya no tiene soporte y conlleva riesgos de seguridad.

No. Las preguntas frecuentes de la Comisión indican que la CRA no exige a los fabricantes garantizar que un producto esté libre de todas las vulnerabilidades.

En el momento de comercializar el producto, el requisito pertinente del anexo I se refiere a las vulnerabilidades explotables conocidas, atendiendo a la evaluación de riesgos de ciberseguridad del fabricante y a los hechos disponibles en ese momento.

Más información en Requisitos esenciales de ciberseguridad y Evaluación de riesgos de ciberseguridad.

No. El fabricante debe evaluar si la vulnerabilidad es pertinente para el producto y qué riesgo genera. La solución debe ser adecuada a ese riesgo.

Una solución puede consistir en un parche, pero también en otra medida, como un aviso, instrucciones de configuración, una alternativa provisional, información actualizada para los usuarios o una actualización de software posterior. La CRA exige abordar y corregir las vulnerabilidades sin demora, en función de los riesgos que planteen los productos con elementos digitales.

Más información en Registros de gestión de vulnerabilidades.

No. Cinco años es una salvaguarda mínima, no el período predeterminado para todos los productos. Puede ser necesario un período de soporte más largo cuando sea razonable esperar que el producto se utilice durante más tiempo.

Solo se permite un período de soporte inferior cuando se prevea que el producto se utilizará durante menos de cinco años. En ese caso, el período de soporte corresponde al tiempo de uso previsto.

Más información en Período de soporte.

El fabricante notifica una vulnerabilidad explotada activamente que esté presente en su producto. Si la vulnerabilidad procede de un componente integrado y puede explotarse en el producto, debe notificarla el fabricante del producto. El fabricante del componente también debe notificarla si este se comercializó como producto propio.

Si la vulnerabilidad del componente no puede explotarse en el producto del fabricante, no se activa por ese motivo la obligación de notificación del artículo 14. El fabricante puede seguir teniendo obligaciones de coordinación con los proveedores o de gestión de vulnerabilidades.

Más información en Notificación de vulnerabilidades.

No. Las preguntas frecuentes de la Comisión explican que un fabricante puede integrar componentes sin marcado CE, incluidos los que no se hayan comercializado y los que se hayan comercializado antes de que la CRA sea aplicable.

Aun así, el fabricante debe ejercer la diligencia debida para que el componente no comprometa la ciberseguridad del producto final.

Más información en SBOM y registros de componentes.

Por lo general, no. Las preguntas frecuentes de la Comisión indican que no existe una obligación general de poner la documentación técnica a disposición de los clientes o del público.

La excepción importante son los programas de software libre y de código abierto de clase I o II del anexo III cuando el fabricante quiera acogerse a la autoevaluación del artículo 32(5). En ese caso, la documentación técnica debe hacerse pública.

Más información en Documentación técnica y Evaluación de la conformidad.

No. Los proyectos de normas pueden ser útiles para preparar el trabajo, pero no crean una presunción de conformidad con arreglo al artículo 27. Esta presunción depende de una norma armonizada cuya referencia se haya publicado en el Diario Oficial de la Unión Europea.

Se aplica la misma distinción a los proyectos prEN 40000 y a los proyectos de normas específicas de producto. Los fabricantes pueden utilizarlos para preparar pruebas y comprobar por separado su estado de publicación y cita.

Más información en Normas armonizadas y presunción de conformidad.