01Qué es esto
Art. 26 exige a la Comisión que publique orientación para ayudar a los operadores económicos a aplicar la CRA, con especial atención a facilitar el cumplimiento para las pequeñas y medianas empresas. El 27 de julio de 2026 la Comisión aprobó el contenido de dicha orientación (referencia del documento C(2026) 5252). Consta de unas 80 páginas y aborda las preguntas que los fabricantes formulan con más frecuencia.
La orientación es no vinculante y no modifica la ley: una interpretación autorizada de la CRA solo puede provenir del Tribunal de Justicia de la UE. Pero las autoridades de vigilancia del mercado y los organismos notificados la utilizan como referencia para una lectura coherente y armonizada, por lo que es el complemento natural del Reglamento.
La Comisión ha aprobado la orientación como draft. Se adoptará formalmente, y solo entonces será aplicable, una vez que estén disponibles todas las versiones lingüísticas de la UE. Cabe esperar que el texto sea definitivo, pero la fecha de adopción formal debe considerarse aún pendiente.
Publicado a través del Sitio web de implementación de la CRA ↗ (documento C(2026) 5252, orientación sobre la aplicación de Regulation (EU) 2024/2847).
02Qué cuenta como un producto
La mayor parte de la orientación trata sobre ámbito de aplicación, el área más consultada. Un producto con elementos digitales es un producto de software o hardware (y su procesamiento remoto de datos) cuyo uso incluye una conexión de datos directa o indirecta. Art. 3(1)
- El lugar donde se ejecuta el software lo determina; el software que se ejecuta en el dispositivo del usuario (una aplicación descargada, una extensión de navegador, un cliente instalado localmente) es un producto con elementos digitales. El software al que simplemente se accede de forma remota a través de un navegador no lo es, únicamente por ese motivo.
- Aplicaciones web y sitios web; una aplicación web utilizada únicamente a través de un navegador, y un sitio web que se limita a presentar información, generalmente no son productos con elementos digitales. Entran en el ámbito de aplicación solo cuando constituyen un procesamiento remoto de datos que sustenta la función de un producto.
- Código fuente; la definición de software de la CRA abarca tanto el código máquina como el código fuente, pero el mero hecho de compartir código de código abierto en un repositorio público generalmente no constituye una "puesta en el mercado". Art. 3(4)
Si no está seguro de dónde se sitúa su producto, el Fast Check y el explicación en lenguaje claro recorren el ámbito de aplicación en la práctica.
03Software de código abierto
La orientación expone en detalle el régimen adaptado y más ligero para el código abierto. El software de código abierto no comercial desarrollado fuera de una actividad comercial queda, en gran medida, fuera del ámbito de aplicación; el elemento desencadenante es actividad comercial y si el software se pone en el mercado.
- Cuándo el FOSS está "puesto en el mercado"; la orientación analiza el cobro de un precio, la monetización de servicios relacionados o la exigencia de datos personales, el soporte de pago, las donaciones, los mecanismos de financiación y las estructuras sin ánimo de lucro, así como la integración de FOSS por parte de otros fabricantes.
- Responsables de software de código abierto; un conjunto definido y proporcionado de obligaciones centradas en apoyar la seguridad y la viabilidad continuada del software.
- FOSS importante; los productos importantes (clase I o II) que se ponen en el mercado como software libre y de código abierto pueden seguir los procedimientos de conformidad más ligeros de la categoría por defecto. Art. 32(5)
04Modificaciones sustanciales
Si un cambio es una modificación sustancial determina si se necesita una nueva evaluación de conformidad. El Considerando 39 lo enmarca así: un producto se considera sustancialmente modificado cuando un cambio altera su nivel de riesgo de ciberseguridad de una manera que el fabricante no había considerado ya en su evaluación de riesgos. Art. 3(30)
- Las actualizaciones de seguridad generalmente no son modificaciones sustanciales; su finalidad es reducir el riesgo, por lo que una corrección de seguridad que no cambie la finalidad prevista del producto ni introduzca nuevos riesgos no cuenta, por sí sola.
- Se trata de riesgo, no de tamaño; el criterio es el impacto del cambio en el perfil de riesgo de ciberseguridad (nuevos vectores de amenaza, nuevos escenarios de ataque, o una probabilidad o impacto modificados), no la magnitud del cambio.
- La consecuencia; un producto sustancialmente modificado se considera recién puesto en el mercado. Cuando alguien distinto del fabricante original realiza el cambio, asume las obligaciones de fabricante respecto a la parte modificada. Art. 21 · 22
El Guía de marcado CE abarca la evaluación de conformidad que desencadena una nueva puesta en el mercado.
05Período de soporte
El período de soporte es el tiempo durante el cual deben gestionarse las vulnerabilidades. Debe reflejar durante cuánto tiempo el producto está razonablemente previsto que se utilice. Art. 13(8)
- Cinco años es el valor por defecto, no un mínimo; el período puede ser más corto cuando se espere que el producto esté en uso menos de cinco años, y los productos que razonablemente se espera que estén en uso durante más tiempo deben tener períodos de soporte más largos.
- Informar a los usuarios; indicar la fecha de finalización (al menos el mes y el año) en el momento de la compra, y notificar a los usuarios cuando expire, siempre que sea técnicamente viable. Art. 13(19)
- Flexibilidad para el software; los fabricantes pueden, en determinadas condiciones, corregir las vulnerabilidades únicamente en la última versión, cuando los usuarios puedan actualizar de forma gratuita y sin coste adicional. Art. 13(10)
- Tras una modificación sustancial; reevaluar el período con arreglo a los mismos criterios; no se reinicia ni se prolonga automáticamente.
Planifique el suyo con el planificador de período de soporte y fin de vida útil.
06Productos importantes y críticos
La clasificación determina la vía de conformidad. Un producto es importante if its funcionalidad principal coincide con una categoría del Annex III (clase I o II), y crítico si coincide con el Annex IV; todo lo demás es un producto por defecto que puede autoevaluarse. Art. 7 · 8 · 32
- La funcionalidad principal es el criterio; las características principales del producto, sin las cuales no cumpliría su finalidad prevista. Las funciones accesorias no cambian la clase, y la mera integración de un componente importante o crítico no convierte a todo el producto en importante o crítico: un smartphone que incorpora un sistema operativo no es en sí mismo un "sistema operativo".
- Una funcionalidad principal; a efectos de elegir la vía de conformidad, se considera que un producto tiene una única funcionalidad principal, identificada en su documentación técnica.
- Las definiciones de categoría; las descripciones técnicas de las categorías importante y crítica se establecen en Commission Implementing Regulation (EU) 2025/2392.
Compare su producto con las categorías mediante el clasificador de clase de producto.
07Procesamiento remoto de datos
Las soluciones de procesamiento remoto de datos forman parte de un producto con elementos digitales únicamente cuando son necesario para que el producto realice sus funciones. Art. 3(2) La orientación ofrece un criterio práctico: si el procesamiento se realiza "a distancia"; si su ausencia impediría que el producto realizara una de sus funciones; y si el software fue diseñado y desarrollado por el fabricante, o bajo su responsabilidad.
Ilustra el criterio con casos prácticos resueltos (una aplicación de banca móvil, un termostato inteligente, un lector de libros electrónicos, un robot industrial y una red celular) que muestran dónde se sitúa el límite entre un producto y un mero servicio.
08Notificación y vulnerabilidades
La orientación también aclara las obligaciones continuas: los Article 14 reporting de vulnerabilidades explotadas activamente e incidentes graves, y el Annex I vulnerability-handling requisitos: notificar aguas arriba y compartir las correcciones de seguridad, abordar las vulnerabilidades explotables conocidas, y llevar a cabo pruebas y revisiones de seguridad eficaces y periódicas. Art. 14 · Annex I
Las obligaciones de notificación son aplicables a partir del 11 September 2026. Consulte la guía dedicada guía de notificación de incidentes y vulnerabilidades para los plazos de 24 horas / 72 horas / 14 días y la plataforma única de notificación de ENISA.
09Otras fuentes oficiales
La orientación se sitúa junto a otros dos puntos de referencia oficiales que conviene leer conjuntamente.
Un documento de preguntas frecuentes, publicado por primera vez el 3 December 2025 y actualizado a medida que surgen nuevas preguntas: Aplicación del Reglamento de Ciberresiliencia: preguntas frecuentes ↗
Normas armonizadas. Los requisitos esenciales del Anexo I están redactadas en términos de resultados; una vez que una norma armonizada pertinente se cita en el Diario Oficial, seguirla otorga una presunción de conformidad. La solicitud de normalización de la Comisión M/606 fue aceptada por CEN, CENELEC y ETSI en 2025 y abarca alrededor de 41 normas. Se esperan las dos normas horizontales principales (desarrollo seguro y gestión de vulnerabilidades) para el 30 August 2026, las normas de producto verticales para el 30 October 2026, y las normas horizontales restantes para el 30 October 2027, aproximadamente un año antes de la aplicación plena.
