El Reglamento de Ciberresiliencia (UE) 2024/2847, conocido como CRA (Cyber Resilience Act), es la primera norma de la Unión Europea que impone requisitos obligatorios de ciberseguridad a los productos que la gente y las empresas compran, y no solo a las organizaciones que operan redes. Se aplica al hardware y al software comercializados en la UE, desde sensores industriales y electrodomésticos conectados hasta aplicaciones móviles y sistemas operativos. La mayoría de sus obligaciones se aplican desde el 11 de diciembre de 2027, pero la primera ya está vigente: desde el 11 de septiembre de 2026, los fabricantes deben notificar las vulnerabilidades explotadas activamente y los incidentes graves en plazos que se miden en horas. Esta guía explica qué cubre el CRA, qué exige y qué fechas importan.
A quién y a qué se aplica el CRA
El CRA se aplica a los "productos con elementos digitales": cualquier producto de hardware o software, y las soluciones de tratamiento de datos a distancia desarrolladas para él, que se comercialice en la UE. El criterio decisivo es la conexión de datos, no el formato del producto. Si el uso previsto o razonablemente previsible de un producto incluye una conexión directa o indirecta a otro dispositivo o red, es muy probable que quede dentro del ámbito. Un sensor que solo se comunica con una pasarela local sigue contando si esa pasarela llega a internet.
Las obligaciones recaen sobre los operadores económicos. El fabricante soporta la mayor carga, con deberes más ligeros para importadores y distribuidores. El alcance es extraterritorial: una empresa de fuera de la UE que venda un producto conectado en el mercado de la UE queda sujeta a las mismas reglas que una establecida dentro.
Algunos productos quedan fuera del CRA porque ya los regula otra normativa, como los productos sanitarios, los equipos de aviación civil y los vehículos de motor. El software libre y de código abierto tiene un régimen específico y más ligero para los "administradores" (stewards), aunque una empresa que comercialice software de código abierto en el marco de una actividad comercial puede ser tratada como fabricante con el conjunto completo de obligaciones.
El software puramente como servicio (SaaS) queda, por lo general, fuera del CRA y lo cubre en su lugar la Directiva NIS2. Un servicio en la nube solo entra cuando es una "solución de tratamiento de datos a distancia": el fabricante es responsable de ella y el producto no puede realizar una de sus funciones sin ella. El backend que necesita un dispositivo inteligente para funcionar está dentro del ámbito; una aplicación web independiente en la que simplemente inicias sesión, no.
Cómo clasifica el CRA los productos por riesgo
No todos los productos siguen la misma vía de conformidad. El CRA los ordena en niveles según su riesgo.
Los productos por defecto, la gran mayoría, pueden autoevaluarse y colocar el marcado CE sobre esa base. Los productos importantes, recogidos en el Anexo III como Clase I o Clase II, siguen vías más estrictas: la Clase I puede apoyarse en normas armonizadas para autoevaluarse, mientras que la Clase II suele exigir la intervención de un organismo notificado. Los productos críticos, recogidos en el Anexo IV, requieren certificación obligatoria por un tercero.
La clasificación depende de la función principal del producto y, cuando podría encajar en más de una categoría, se aplica la más estricta. El marcado CE es el resultado visible: una vez que el CRA sea plenamente aplicable, un producto con elementos digitales no podrá comercializarse en la UE sin él.
Qué exige el CRA a los fabricantes
Los requisitos de fondo están en el Anexo I del Reglamento (UE) 2024/2847 y se dividen en dos mitades.
La primera se refiere al propio producto. Debe diseñarse, desarrollarse y fabricarse para ser seguro, entregarse con una configuración segura por defecto y estar libre de vulnerabilidades explotables conocidas en el momento de su comercialización. Debe proteger la confidencialidad y la integridad de los datos que trata, reducir su propia superficie de ataque y permitir actualizaciones de seguridad, preferiblemente automáticas cuando proceda.
La segunda se refiere a la gestión de vulnerabilidades a lo largo de la vida del producto. Los fabricantes deben identificar y documentar los componentes que contiene un producto, incluso mediante una lista de materiales de software (SBOM) en un formato de uso común y legible por máquina. Deben tratar y corregir las vulnerabilidades sin demora, proporcionar actualizaciones de seguridad gratuitas durante un periodo de soporte acorde con el tiempo que se espera razonablemente que el producto esté en uso, y mantener una política de divulgación coordinada de vulnerabilidades para que los investigadores tengan una vía clara de comunicar los problemas.
Sobre todo ello se asienta la evidencia que lo demuestra: la documentación técnica, la declaración UE de conformidad y la evaluación de la conformidad adecuada al nivel de riesgo del producto.
La obligación de notificación que ya está vigente
El artículo 14 es la parte del CRA que ya aplica. Desde el 11 de septiembre de 2026, un fabricante que tenga conocimiento de una vulnerabilidad explotada activamente en uno de sus productos, o de un incidente grave que afecte a la seguridad del producto, debe notificarlo con un calendario fijo: una alerta temprana en un plazo máximo de 24 horas desde que tiene 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 se disponga de una medida correctora o de mitigación para una vulnerabilidad, o de un mes desde la notificación de las 72 horas para un incidente grave.
"Explotada activamente" tiene aquí un significado preciso (artículo 3.42): existen pruebas fiables de que un agente malintencionado ha aprovechado la vulnerabilidad en un sistema sin autorización de su propietario. Encontrar un fallo en una auditoría, o puntuarlo como de gravedad alta, no cumple por sí solo ese umbral. Los dos plazos iniciales parten ambos del momento en que el fabricante tiene conocimiento y corren en paralelo; las 72 horas no empiezan cuando se agotan las primeras 24.
La notificación se realiza por un único canal. La plataforma única de notificación de ENISA, operativa desde el 11 de septiembre de 2026, recibe una sola comunicación y la dirige al CSIRT designado como coordinador, determinado por el establecimiento principal del fabricante, y a ENISA. En España, INCIBE-CERT es el CSIRT nacional de referencia para las empresas. Un punto suele pasar desapercibido: la obligación alcanza a los productos que ya están en el mercado, no solo a los comercializados tras la aplicación general en 2027. Esperar a la próxima versión no la elimina.
El calendario del CRA: qué se aplica y cuándo
El CRA entró en vigor el 10 de diciembre de 2024 y se aplica por fases. El 11 de junio de 2026 empezaron a aplicarse las reglas sobre la notificación de los organismos de evaluación de la conformidad. El 11 de septiembre de 2026 empezaron a aplicarse las obligaciones de notificación del artículo 14 y se abrió la plataforma única de notificación de ENISA. El 11 de diciembre de 2027, el grueso de las obligaciones, los requisitos esenciales, la evaluación de la conformidad y el marcado CE, será plenamente aplicable.
La Comisión Europea publicó una guía práctica el 27 de julio de 2026 para ayudar a fabricantes y desarrolladores a prepararse, y los actos de ejecución y delegados van concretando el detalle. El escalonamiento es deliberado: adelanta el deber de avisar a las autoridades cuando un producto está siendo explotado, mucho antes de que entren en juego las reglas más amplias de diseño y documentación.
Cómo encaja el CRA con NIS2, DORA y el RGPD
El CRA no sustituye a las demás normas europeas de ciberseguridad. Convive con ellas y cubre una capa distinta. El CRA regula los productos: la seguridad del hardware y el software que una empresa fabrica y vende. NIS2 regula las organizaciones: los deberes de ciberseguridad y notificación de incidentes de las entidades "esenciales" e "importantes" de sectores definidos. DORA regula el sector financiero: la resiliencia operativa de las entidades financieras y de sus proveedores de TIC críticos. El RGPD regula los datos personales.
Un mismo suceso puede activar más de uno de estos regímenes a la vez, y por eso importa coordinar la respuesta a incidentes entre todos ellos. Existe además un vínculo con el Reglamento de IA: cuando un producto es un sistema de IA de alto riesgo, el trabajo de ciberseguridad y gestión de vulnerabilidades hecho para el Anexo I del CRA puede ayudar a demostrar el cumplimiento de los requisitos de seguridad del propio Reglamento de IA. Una empresa que ya ejecuta ISO 27001 y ENS como un único programa o cumple NIS2 dispone de buena parte de la maquinaria de gobernanza, riesgo y gestión de vulnerabilidades que el CRA presupone, y puede reutilizarla en lugar de construirla dos veces. Para un reglamento europeo hermano de estructura parecida, véase DORA: los cinco pilares, explicados.
Qué ocurre si no se cumple
El CRA prevé sanciones reales. Incumplir los requisitos esenciales de ciberseguridad o las obligaciones básicas del fabricante puede acarrear multas de hasta 15 millones de euros o el 2,5 % del volumen de negocios anual mundial total, la cifra que sea mayor. Otros incumplimientos tienen topes inferiores. Los Estados miembros fijan el detalle del régimen sancionador a través de sus autoridades de vigilancia del mercado, que pueden ordenar que un producto no conforme se ajuste, se retire de la venta o se recupere.
La consecuencia comercial puede pesar antes que cualquier multa. Una vez que el CRA sea plenamente aplicable, sin marcado CE el producto no podrá comercializarse en la UE. Para una empresa que vende en Europa, la conformidad no es un detalle de cumplimiento: es la condición para acceder al mercado.
Cómo prepararse
El trabajo se resume en una lista corta, y el calendario de notificación hace que parte de ella sea urgente. Haz inventario de los productos con elementos digitales que comercializas en la UE y confirma tu papel en cada uno: fabricante, importador o distribuidor. Clasifícalos como por defecto, importantes o críticos, porque eso decide la vía de conformidad. Elabora y mantén un SBOM, para saber qué hay dentro de cada producto y poder actuar rápido cuando un componente resulte vulnerable. Pon en marcha un proceso de gestión de vulnerabilidades y una política de divulgación coordinada, con una responsabilidad interna clara sobre la decisión de notificar.
Asegúrate de que puedes detectar y notificar realmente dentro de las ventanas de 24 y 72 horas: no se puede notificar lo que no se ve, y el envío a la plataforma requiere una cuenta EU Login con autenticación multifactor configurada de antemano. Por último, reutiliza lo que ya tienes. Si un programa de seguridad existente ya te ofrece lo que una licencia por sí sola no cubre, trasládalo en lugar de empezar de cero, y comprueba que tienes visibilidad real de lo que estás exponiendo en internet.
