Preguntas frecuentes

La clasificación se basa en la funcionalidad principal del producto, no en cada función que incluya. Si la función principal coincide con una categoría incluida en el Anexo III, el producto es «importante» (Clase I o II); si coincide con el Anexo IV, es «crítico»; en caso contrario, es «por defecto». Una capacidad como la gestión de identidades o una VPN, incluida únicamente como función, no convierte al producto en «importante» a menos que esa sea su finalidad principal. Cuando podría aplicarse más de una categoría, se aplica la clase más estricta. Art. 7

El software de código abierto no comercial desarrollado fuera de una actividad comercial queda en gran medida fuera del ámbito de aplicación. Los administradores de software de código abierto tienen un conjunto de obligaciones más ligero y adaptado. Los componentes de código abierto suministrados en el marco de una actividad comercial pueden quedar dentro del ámbito de aplicación.

Los servicios independientes por lo general quedan fuera del CRA. Sin embargo, las soluciones de tratamiento de datos a distancia que son necesarias para que un producto realice sus funciones se consideran parte de dicho producto y están incluidas en el ámbito de aplicación. Estar fuera del CRA no significa no estar regulado: los servicios web y en la nube pueden estar sujetos a otras normas de la UE, en particular NIS2 (Directive (EU) 2022/2555) para entidades medianas y grandes de los sectores cubiertos, y el GDPR para los datos personales. Art. 3(2)

Sí. El CRA se aplica a los productos introducidos en el mercado de la UE con independencia del lugar en que esté establecido el fabricante. Los fabricantes establecidos fuera de la UE deben garantizar que un operador económico establecido en la Unión sea responsable de las obligaciones pertinentes.

Se reparten en dos partes del Anexo I: las propiedades de seguridad que debe tener el producto (seguro por defecto, confidencialidad, integridad, disponibilidad, superficie de ataque minimizada, actualizaciones de seguridad) y los procesos de tratamiento de vulnerabilidades que debe aplicar el fabricante (SBOM, subsanación, divulgación coordinada). Anexo I

Sí. Los fabricantes deben identificar y documentar los componentes contenidos en el producto, lo que incluye elaborar una lista de materiales de software (SBOM) en un formato de uso común y legible por máquina. Anexo I · II(1)

El período de soporte es el tiempo durante el cual el fabricante debe proporcionar actualizaciones de seguridad. Debe reflejar el período durante el cual se espera razonablemente que el producto esté en uso: cinco años por defecto, más corto cuando el uso previsto sea más corto y más largo cuando sea más largo. Art. 13(8)

Las vulnerabilidades explotadas activamente y los incidentes graves que afecten a la seguridad del producto deben notificarse a ENISA y al CSIRT correspondiente. Debe enviarse una alerta temprana en un plazo de 24 horas desde que se tenga conocimiento, seguida de una notificación más completa y de un informe final. Art. 14

El Reglamento entró en vigor el 10 de diciembre de 2024. Las obligaciones de notificación son aplicables a partir de septiembre de 2026 (21 meses después) y la mayor parte de las obligaciones se aplican a partir de diciembre de 2027 (36 meses después). Art. 71

El incumplimiento de los requisitos esenciales o de las obligaciones del fabricante puede dar lugar a multas de hasta 15 millones de € o el 2,5 % del volumen de negocios anual mundial total, si esta cifra es superior. A otras infracciones y al suministro de información incorrecta se aplican límites máximos inferiores.

Sí, desde el 11 de septiembre de 2026, el día en que comenzó la propia obligación del Art. 14. La plataforma está operativa en portal.cra-srp.enisa.europa.eu; usted selecciona el rol de Representante autorizado e inicia sesión con una cuenta de EU Login que tenga habilitada la autenticación multifactor. ENISA publicó la dirección en sus preguntas frecuentes sobre la SRP el 10 de septiembre de 2026, junto con un manual de usuario para representantes autorizados y los términos y condiciones de la plataforma. Cuatro elementos no llegaron con ella: la notificación voluntaria con arreglo al Art. 15, una API de notificación, un campo de conocimiento para vulnerabilidades explotadas activamente, y un contador de 72 horas que mide desde el conocimiento y no desde el envío de su alerta temprana, lo que significa que el reloj en pantalla puede mostrar una notificación como vencida antes de que haya transcurrido el plazo legal. Por ahora, la plataforma funciona solo en inglés. Consulte la guía de notificación. Art. 14 · 16

La solicitud de normalización M/606 de la Comisión fue aceptada por CEN, CENELEC y ETSI en 2025, y abarca alrededor de 41 normas (horizontales y específicas de producto). Tras la propuesta de modificación de la Comisión de julio de 2026 al M/606, que retrasó los plazos de 2026 en dos meses, las dos normas horizontales principales (desarrollo seguro y tratamiento de vulnerabilidades) se esperan ahora para el 31 de octubre de 2026, las normas verticales de producto para el 31 de diciembre de 2026, y las restantes normas horizontales para el 30 de octubre de 2027, antes de la plena aplicación en diciembre de 2027. Seguir una norma armonizada citada otorga una presunción de conformidad. Anexo I

Lleve a cabo la vía de evaluación de la conformidad correspondiente a la clase de su producto, recopile la documentación técnica, redacte y firme la declaración UE de conformidad y, a continuación, coloque el marcado CE. Los productos por defecto pueden autoevaluarse; los productos importantes y críticos requieren vías más estrictas. Art. 28 · 32

Empiece con el CRA Fast Check para confirmar el ámbito de aplicación y la clase, siga la guía redactada para su función y utilice la matriz de conformidad para seguir hasta el final los requisitos esenciales.

Las obligaciones de notificación del artículo 14 se vuelven exigibles. A partir de esa fecha, los fabricantes deben notificar las vulnerabilidades explotadas activamente y los incidentes graves a ENISA y al CSIRT competente a través de la plataforma única de notificación. Es la primera de las principales obligaciones del CRA en entrar en vigor, con bastante antelación a la aplicación plena el 11 de diciembre de 2027. Véase el guía de notificación. Art. 14 · 71

No. Solo las vulnerabilidades explotadas activamente y incidentes graves que afectan a la seguridad de su producto son notificables en virtud del artículo 14. Las vulnerabilidades que detecte y corrija antes de que sean explotadas se gestionan mediante su proceso ordinario de gestión de vulnerabilidades, no el canal de notificación. El guía de notificación establece la prueba y los plazos. Art. 14

A través de la plataforma única de notificación de ENISA, operativa desde el 11 de septiembre de 2026 en portal.cra-srp.enisa.europa.eu, que dirige su notificación a ENISA y al CSIRT nacional competente. Debe enviar una alerta temprana en un plazo de 24 horas desde que tenga conocimiento, una notificación más completa en un plazo de 72 horas y un informe final en un plazo de 14 días desde que esté disponible una medida correctiva para una vulnerabilidad, o en un plazo de un mes desde la notificación de 72 horas en el caso de un incidente grave. El acceso se realiza mediante EU Login con autenticación multifactor. Consulte la guía paso a paso guía de notificación. Art. 14 · 16

Por lo general, no por sí solo. La Orientación de la Comisión aclara que el software que se ejecuta en el dispositivo del usuario (una aplicación descargada, una extensión del navegador, un cliente instalado localmente) es un producto con elementos digitales, mientras que una aplicación web utilizada únicamente a través de un navegador, o un sitio web que se limita a presentar información, no lo es. Un servicio remoto solo queda cubierto cuando se trata de un tratamiento de datos a distancia necesario para que un producto realice sus funciones. Estar fuera del CRA no equivale a no estar regulado: un servicio exclusivamente web aún puede estar sujeto a NIS2 (para proveedores medianos y grandes) y al GDPR. Art. 3 Véase la Resumen de la orientación de la Comisión.

Puede cambiar la respuesta, porque el CRA regula productos, no servicios. El mismo código empaquetado como aplicación instalable (incluida una compilación con Capacitor, Electron o similar) se ejecuta en el dispositivo del usuario y es un producto con elementos digitales, por lo que el CRA se aplica. Si se entrega únicamente como aplicación web progresiva en el navegador, es un servicio web y, como producto, por lo general queda fuera del CRA; el backend con el que se comunica solo queda comprendido cuando se trata de un tratamiento de datos a distancia que un producto necesita para realizar sus funciones. Dos advertencias: un servicio exclusivamente web no está exento de regulación (NIS2 puede aplicarse a proveedores medianos y grandes, y el GDPR a los datos personales), y la frontera entre producto y servicio puede difuminarse, por lo que conviene tratar «publicar una PWA» como una decisión de arquitectura y no como una exención garantizada. Art. 3 Véase la Resumen de la orientación de la Comisión.

Solo cuando la actualización es una modificación sustancial: un cambio que altera el riesgo de ciberseguridad del producto de una manera que su evaluación de riesgos no cubría previamente. Las actualizaciones de seguridad ordinarias, por lo general, no son modificaciones sustanciales. Cuando una actualización es sustancial, el producto modificado se considera recién puesto en el mercado y se requiere una nueva evaluación de conformidad para las partes afectadas. Art. 3(30) El Orientación de la Comisión establece el criterio.