¿Qué es el Cyber Resilience Act?

La ley de la UE que establece normas de ciberseguridad para productos de hardware y software, y lo que exige a las empresas que los fabrican

El Cyber Resilience Act (CRA), Reglamento (UE) 2024/2847, es un reglamento de la UE que establece requisitos de ciberseguridad obligatorios para los productos con elementos digitales: hardware y software que se conectan a un dispositivo o a una red, desde routers y dispositivos de hogar inteligente hasta aplicaciones, sistemas operativos y componentes de software vendidos por separado. Entró en vigor el 10 de diciembre de 2024. Los fabricantes tienen que notificar las vulnerabilidades explotadas activamente y los incidentes graves desde el 11 de septiembre de 2026, y el resto del reglamento se aplica desde el 11 de diciembre de 2027.

Los fabricantes asumen la mayoría de las obligaciones. Evalúan el riesgo de ciberseguridad, construyen sus productos conforme a los requisitos esenciales del anexo I, mantienen una lista de materiales de software (SBOM), gestionan las vulnerabilidades durante un periodo de soporte de al menos cinco años, superan una evaluación de la conformidad y colocan el marcado CE. Los importadores y distribuidores comprueban que se haya hecho. Las multas alcanzan €15 millones o el 2,5 % del volumen de negocios anual mundial.

CRACI automatiza una parte importante de las evidencias que necesitan estas obligaciones: registra como SBOM los componentes que incorpora cada build, los vuelve a comprobar frente a nuevas vulnerabilidades después de la distribución y exporta evidencias de auditoría para su documentación técnica. Cuando hay que notificar una vulnerabilidad, CRACI presenta las notificaciones del CRA a las autoridades en su nombre. Consulte cómo apoya CRACI el cumplimiento del CRA.

Miniatura del vídeo: What the Cyber Resilience Act asks manufacturers to do — What the Cyber Resilience Act asks manufacturers to do

El ámbito del Reglamento (UE) 2024/2847, las fechas en que empieza a aplicarse, los plazos de notificación y dónde se sitúan las obligaciones sobre la SBOM y la gestión de vulnerabilidades.

Petteri Pulkkinen y Erika Marttinen en Kubernetes Community Days Helsinki 2026, 8:03 a 15:20 de SBOMbastic: Getting Ready for Upcoming EU Cybersecurity Regulation in Software Supply Chains.

Fechas clave

Fecha	Qué ocurre
23 de octubre de 2024	El Parlamento Europeo y el Consejo adoptan el Reglamento (UE) 2024/2847
20 de noviembre de 2024	Publicación en el Diario Oficial de la Unión Europea
10 de diciembre de 2024	Entrada en vigor
11 de junio de 2026	Se aplican las normas sobre la notificación de organismos de evaluación de la conformidad (capítulo IV)
11 de septiembre de 2026	Se aplica la notificación de vulnerabilidades explotadas activamente e incidentes graves (artículo 14), también para los productos ya comercializados
11 de diciembre de 2027	Se aplica el resto del reglamento

Aspectos clave del CRA

Requisitos de seguridad obligatorios

Los productos deben cumplir los requisitos esenciales de ciberseguridad del anexo I al introducirse en el mercado y durante todo su periodo de soporte.

Clasificación basada en el riesgo

La mayoría de los productos pertenecen a la categoría por defecto. Los productos importantes y críticos se someten a vías de evaluación de la conformidad más estrictas.

Gestión de vulnerabilidades

Los fabricantes mantienen una SBOM, corrigen las vulnerabilidades sin demora y notifican las explotadas activamente en un plazo de 24 horas.

Marcado CE

Tras una evaluación de la conformidad, el fabricante firma una declaración UE de conformidad y coloca el marcado CE.

Documentación y transparencia

La documentación técnica se conserva durante al menos 10 años o durante el periodo de soporte, y los usuarios saben cuándo termina el soporte.

Vigilancia del mercado

Las autoridades nacionales pueden solicitar documentación, ordenar medidas correctoras o retiradas e imponer multas.

The CRA timeline is ticking

Key milestones you need to prepare for under the Cyber Resilience Act.

Notified body rules apply

June 2026

Vulnerability reporting enforcement

September 2026

We are here

Full application of the CRA act

December 2027

Notified body rules apply

June 2026

Vulnerability reporting enforcement

September 2026

We are here

Full application of the CRA act

December 2027

€15M

maximum fine, or 2.5% of global annual turnover

24 hours

to send an early warning of an actively exploited vulnerability

72 hours

to follow up with a full vulnerability notification

¿A quién afecta el CRA?

Fabricantes

Cualquiera que desarrolle o fabrique un producto con elementos digitales, o lo encargue, y lo comercialice con su propio nombre o marca, ya sea de pago o gratuito. Los fabricantes de fuera de la UE están cubiertos cuando venden en ella.

Importadores y distribuidores

Los importadores y distribuidores deben comprobar que un producto lleva el marcado CE y que el fabricante ha cumplido sus obligaciones antes de ponerlo a disposición en la UE.

Software de código abierto

Solo está cubierto el código abierto suministrado en el transcurso de una actividad comercial. Los administradores de software de código abierto siguen un régimen ligero, y los fabricantes siguen siendo responsables de los componentes de código abierto que integran.

Proveedores de software y SaaS

Está cubierto el software vendido como producto, igual que el backend en la nube que un producto necesita para funcionar. El software como servicio por sí solo se rige por NIS2 y no por el CRA.

Fuera del ámbito: los productos ya regulados por las normas de la UE sobre productos sanitarios, diagnóstico in vitro y homologación de vehículos, los productos de aviación certificados, los equipos marinos, las piezas de repuesto idénticas y los productos creados exclusivamente para la seguridad nacional o la defensa (artículo 2).

Categorías de producto y evaluación de la conformidad

Todo fabricante realiza una evaluación de la conformidad antes de introducir un producto en el mercado. La vía depende de la categoría del producto.

Categoría	Ejemplos	Evaluación de la conformidad
Por defecto	La mayoría de los productos con elementos digitales que no figuran en los anexos III o IV	Se permite la autoevaluación (control interno)
Importante, clase I (anexo III)	Gestión de identidades y accesos, navegadores, gestores de contraseñas, VPN, sistemas operativos, routers y switches, productos de seguridad para el hogar inteligente	Autoevaluación solo si se aplican normas armonizadas, especificaciones comunes o un esquema de certificación; en caso contrario, un organismo notificado
Importante, clase II (anexo III)	Hipervisores y entornos de ejecución de contenedores, cortafuegos y sistemas de detección de intrusiones, microprocesadores y microcontroladores resistentes a la manipulación	Evaluación por terceros a cargo de un organismo notificado o un esquema europeo de certificación de ciberseguridad
Crítico (anexo IV)	Dispositivos de hardware con cajas de seguridad, pasarelas de contadores inteligentes, tarjetas inteligentes y elementos seguros	Un certificado europeo de ciberseguridad cuando la Comisión lo exija; en caso contrario, evaluación por terceros

Requisitos esenciales

El anexo I establece dos grupos de requisitos esenciales. El primero abarca el propio producto, a partir de una evaluación documentada del riesgo de ciberseguridad:

Ninguna vulnerabilidad explotable conocida al introducir el producto en el mercado
Una configuración segura por defecto
Actualizaciones de seguridad, automáticas por defecto cuando proceda
Protección frente a accesos no autorizados, y de la confidencialidad y la integridad de los datos
Minimización de datos, disponibilidad de las funciones esenciales y una superficie de ataque limitada
Eliminación segura y permanente de los datos y ajustes del usuario

El segundo abarca cómo gestiona el fabricante las vulnerabilidades:

Una SBOM que abarque, como mínimo, las dependencias de nivel superior
Corrección de las vulnerabilidades sin demora, con actualizaciones de seguridad separadas de las de funcionalidad cuando sea posible
Pruebas y revisiones de seguridad periódicas
Una política de divulgación coordinada de vulnerabilidades y un contacto para notificarlas
Divulgación pública de las vulnerabilidades corregidas cuando haya una actualización disponible
Distribución segura y gratuita de las actualizaciones, con mensajes de aviso

Los fabricantes también fijan un periodo de soporte de al menos cinco años, salvo que se prevea que el producto se utilice durante menos tiempo, mantienen disponible cada actualización de seguridad durante al menos 10 años, y conservan la documentación técnica y la declaración UE de conformidad durante al menos 10 años o durante el periodo de soporte, lo que sea más largo (artículo 13).

Obligaciones y plazos de notificación

Desde el 11 de septiembre de 2026, los fabricantes notifican las vulnerabilidades explotadas activamente y los incidentes graves a través de la plataforma única de notificación, al CSIRT designado como coordinador en su principal Estado miembro de la UE y a ENISA al mismo tiempo (artículo 14). Esto también se aplica a los productos ya comercializados.

Paso	Vulnerabilidad explotada activamente	Incidente grave
Alerta temprana	En las 24 horas siguientes a tener conocimiento	En las 24 horas siguientes a tener conocimiento
Notificación	En un plazo de 72 horas, con detalles del producto, del exploit y de las posibles mitigaciones	En un plazo de 72 horas, con una evaluación inicial y las posibles mitigaciones
Informe final	A más tardar 14 días después de que esté disponible una medida correctora o de mitigación	En el plazo de un mes desde la notificación del incidente

Los fabricantes también deben informar a los usuarios afectados y, cuando proceda, a todos los usuarios, con las medidas de mitigación que puedan adoptar. Cumplir un plazo de 24 horas depende de saber en cuestión de horas qué productos y versiones contienen el componente vulnerable, y para eso sirve una SBOM por versión.

Sanciones

Los Estados miembros fijan las sanciones, dentro de estos máximos (artículo 64). Las autoridades de vigilancia del mercado también pueden ordenar medidas correctoras, la retirada del mercado o la recuperación de un producto.

Infracción	Multa administrativa máxima
Requisitos esenciales de ciberseguridad (anexo I) y obligaciones del fabricante (artículos 13 y 14)	Hasta €15 millones o el 2,5 % del volumen de negocios anual mundial total, si esta cifra es superior
Otras obligaciones, incluidas las de importadores y distribuidores, la declaración de conformidad, el marcado CE, la documentación técnica y la evaluación de la conformidad	Hasta €10 millones o el 2 % del volumen de negocios anual mundial total, si esta cifra es superior
Información incorrecta, incompleta o engañosa facilitada a organismos notificados o autoridades de vigilancia del mercado	Hasta €5 millones o el 1 % del volumen de negocios anual mundial total, si esta cifra es superior

Las microempresas y pequeñas empresas no reciben multas por incumplir el plazo de 24 horas de la alerta temprana, y los administradores de software de código abierto no reciben multas por ninguna infracción.

El código abierto y el CRA

El software libre y de código abierto solo está cubierto cuando se suministra en el transcurso de una actividad comercial, y alojar un proyecto en un repositorio abierto o un gestor de paquetes no supone por sí mismo su comercialización. Los administradores de software de código abierto, personas jurídicas como las fundaciones que apoyan proyectos de código abierto destinados a uso comercial, deben tener una política de ciberseguridad documentada, cooperar con las autoridades de vigilancia del mercado y notificar las vulnerabilidades explotadas activamente en la medida en que participen en el desarrollo (artículo 24).

Para los fabricantes, el código abierto es un componente como cualquier otro. Deben actuar con la diligencia debida al integrarlo, notificar las vulnerabilidades que encuentren al proyecto que lo mantiene y compartir las correcciones que desarrollen (artículo 13). Por eso importa la SBOM: es el registro de qué componentes de código abierto, y en qué versiones, se distribuyen en cada versión del producto.

Qué significa el CRA para los equipos de desarrollo

Hoy, un producto es en su mayor parte código ajeno: bibliotecas de código abierto, paquetes descargados de registros, imágenes base de contenedores, SDK de terceros y las herramientas de build y los pipelines de CI/CD que lo ensamblan todo. El ataque a SolarWinds pasó por un sistema de build, y Log4Shell fue una vulnerabilidad en una biblioteca muy utilizada; ambos llegaron a productos terminados. El CRA hace al fabricante responsable de todo ello, incluida la diligencia debida sobre los componentes de terceros y de código abierto que integra (artículo 13).

En la práctica, los equipos que se preparan para el CRA:

Saben qué se distribuye en cada versión, porque producen una SBOM de cada build en un formato legible por máquina como CycloneDX o SPDX en lugar de una sola vez al lanzar
Monitorizan las versiones publicadas, no solo la rama principal, porque una vulnerabilidad encontrada después del lanzamiento sigue teniendo que corregirse sin demora durante el periodo de soporte
Acuerdan políticas de dependencias: cómo se eligen y revisan los componentes nuevos, con qué rapidez se incorporan las actualizaciones y qué hallazgos bloquean un lanzamiento
Ensayan el plazo de 24 horas: quién confirma la explotación activa, quién presenta la alerta temprana y quién informa a los usuarios
Conservan las evidencias sobre la marcha, ya que los registros de build, las SBOM y los resultados de las pruebas alimentan la documentación técnica que debe conservarse durante al menos 10 años

Para ver los requisitos como una hoja de ruta paso a paso, consulte la guía del CRA. Consulte también qué exige el CRA a una SBOM y cómo apoya CRACI el cumplimiento del CRA.

Preguntas frecuentes sobre el Cyber Resilience Act

Respuestas breves a las preguntas que más hacen los fabricantes sobre el CRA

¿Qué es el Cyber Resilience Act?

El Cyber Resilience Act (CRA), Reglamento (UE) 2024/2847, es un reglamento de la UE que establece requisitos de ciberseguridad obligatorios para los productos de hardware y software con elementos digitales introducidos en el mercado de la UE. Hace a los fabricantes responsables de la seguridad desde el diseño y durante un periodo de soporte de al menos cinco años, incluidas la gestión de vulnerabilidades, una SBOM y la notificación de las vulnerabilidades explotadas activamente.

¿Cuándo se aplica el Cyber Resilience Act?

Entró en vigor el 10 de diciembre de 2024. Las obligaciones de notificación del artículo 14 se aplican desde el 11 de septiembre de 2026, las normas sobre los organismos de evaluación de la conformidad desde el 11 de junio de 2026 y el resto del reglamento desde el 11 de diciembre de 2027.

¿Se aplica el CRA al software y al SaaS?

Está cubierto el software vendido o suministrado como producto, incluidas las aplicaciones, los sistemas operativos, el firmware y los componentes de software introducidos en el mercado por separado. Los servicios en la nube solo están cubiertos como tratamiento remoto de datos de un producto, por ejemplo el backend en la nube que permite controlar un dispositivo de hogar inteligente. El software como servicio por sí solo se rige por NIS2 (considerando 12).

¿Se aplica el CRA al software de código abierto?

Solo al código abierto suministrado en el transcurso de una actividad comercial. Los proyectos de código abierto no comerciales quedan fuera de su ámbito. Los administradores de software de código abierto, como las fundaciones que apoyan proyectos destinados a uso comercial, siguen un régimen ligero y no pueden ser multados. Los fabricantes que integran componentes de código abierto en sus productos siguen siendo plenamente responsables de ellos.

¿Cuáles son los requisitos de notificación del CRA?

Los fabricantes notifican las vulnerabilidades explotadas activamente y los incidentes graves a través de la plataforma única de notificación a su CSIRT coordinador y a ENISA: una alerta temprana en un plazo de 24 horas, una notificación en un plazo de 72 horas y un informe final en un plazo de 14 días desde la corrección, para las vulnerabilidades, o de un mes, para los incidentes. También informan a los usuarios afectados.

¿Exige el CRA una SBOM?

Sí. El anexo I, parte II, exige una lista de materiales de software en un formato de uso común y legible por máquina que abarque, como mínimo, las dependencias de nivel superior. Forma parte de la documentación técnica y se entrega a una autoridad de vigilancia del mercado cuando la solicita; no hace falta publicarla.

¿Cuáles son las sanciones del CRA?

Hasta €15 millones o el 2,5 % del volumen de negocios anual mundial por incumplir los requisitos esenciales o las obligaciones del fabricante, hasta €10 millones o el 2 % por otras obligaciones y hasta €5 millones o el 1 % por inducir a error a las autoridades. Las microempresas y pequeñas empresas no reciben multas por incumplir el plazo de 24 horas de la alerta temprana.

¿Se aplica el CRA a los productos ya comercializados?

Las obligaciones de notificación sí, desde el 11 de septiembre de 2026. Por lo demás, los productos introducidos en el mercado antes del 11 de diciembre de 2027 solo quedan sujetos al CRA si se modifican sustancialmente después de esa fecha.

Obtenga las evidencias que necesita su proceso del CRA

Vea cómo CRACI registra SBOM de sus builds, monitoriza lo que ha distribuido y presenta las notificaciones del CRA en su nombre

Reservar una demo Compruebe si el CRA se le aplica