El Cyber Resilience Act (CRA) es el Reglamento (UE) 2024/2847, la primera norma europea que impone requisitos horizontales de ciberseguridad a los productos con elementos digitales puestos en el mercado de la Unión. En una frase: si tu empresa fabrica, importa o distribuye hardware o software conectable, el CRA te obliga a integrar seguridad desde el diseño, mantener un SBOM, gestionar vulnerabilidades durante todo el periodo de soporte y notificar a ENISA las vulnerabilidades activamente explotadas. Aquí explicamos qué es el CRA, en qué se diferencia de NIS2 y DORA, a quién obliga, cuáles son las obligaciones núcleo, los plazos (11 de septiembre de 2026 y 11 de diciembre de 2027) y las sanciones, que llegan a 15 millones de euros o el 2,5 por ciento de la facturación mundial.
Qué es el Cyber Resilience Act (CRA)
El Cyber Resilience Act es el Reglamento (UE) 2024/2847 del Parlamento Europeo y del Consejo, publicado en el Diario Oficial el 20 de noviembre de 2024 y en vigor desde el 10 de diciembre de 2024. Al ser un Reglamento (y no una Directiva como NIS2), es directamente aplicable en los 27 Estados miembros sin necesidad de transposición nacional.
Su objeto es un problema concreto: hasta ahora, un router, una cámara IP, un firmware industrial o una librería de software podían venderse en la UE sin ningún requisito mínimo de ciberseguridad ni obligación de parchear fallos. El CRA cierra esa brecha aplicando la lógica del Nuevo Marco Legislativo (el mismo esquema que regula la seguridad de juguetes o maquinaria) a la ciberseguridad: requisitos esenciales, evaluación de la conformidad, marcado CE y vigilancia del mercado.
El concepto central es el de producto con elementos digitales: cualquier producto de software o hardware, y sus soluciones de tratamiento de datos a distancia asociadas, cuya conexión lógica o física a un dispositivo o red sea parte de sus funciones. Abarca desde sistemas operativos, navegadores y gestores de contraseñas hasta sensores IoT, microcontroladores y software empresarial.
En qué se diferencia de NIS2 y DORA
Es la duda más habitual, y la respuesta es clara: regulan cosas distintas.
- NIS2 (Directiva (UE) 2022/2555) regula la seguridad de las redes y sistemas de las entidades esenciales e importantes. Obliga al operador (el hospital, la eléctrica, el MSP) a gobernar su riesgo.
- DORA (Reglamento (UE) 2022/2554) regula la resiliencia operativa digital del sector financiero. Obliga a la entidad financiera a resistir, responder y recuperarse de incidentes TIC.
- CRA regula el producto en sí. Obliga al fabricante a que lo que vende sea seguro y se mantenga seguro.
Dicho de otro modo: NIS2 y DORA miran a la organización que usa u opera tecnología; el CRA mira al que la fabrica y comercializa. Una misma empresa puede estar sujeta a las tres. Un fabricante de equipos de red que vende a hospitales cumple el CRA por su producto, y si además opera infraestructura crítica, puede caer bajo NIS2 como entidad. Para ubicar cada marco recomendamos leer DORA vs NIS2: cuándo aplica cada normativa.
A quién obliga: fabricantes, importadores y distribuidores
El CRA reparte obligaciones entre los operadores económicos de la cadena:
- Fabricante: soporta el grueso de las obligaciones. Diseña, desarrolla y pone el producto en el mercado bajo su nombre o marca. Responde de los requisitos esenciales, la documentación técnica, el marcado CE y la gestión de vulnerabilidades.
- Importador: solo puede introducir productos que cumplan el CRA y cuyo fabricante haya realizado la evaluación de la conformidad. Debe verificar el marcado CE y la documentación.
- Distribuidor: actúa con la diligencia debida, comprueba que el producto lleva marcado CE y las instrucciones, y no comercializa productos que sepa que no cumplen.
Un matiz relevante para el software libre: los desarrolladores de open source sin ánimo comercial quedan en gran medida fuera del ámbito, mientras que las figuras de administrador de software libre (open source steward) que sostienen proyectos usados en productos comerciales asumen obligaciones aligeradas. Quedan excluidos los productos ya cubiertos por normativa sectorial específica (productos sanitarios bajo MDR/IVDR, automoción, aviación) y, con matices, el SaaS puro que no sea una solución de tratamiento a distancia integral al producto.
Categorías de producto y evaluación de la conformidad
No todos los productos siguen la misma vía. El CRA define tres niveles de criticidad:
| Categoría | Ejemplos | Evaluación |
|---|---|---|
| Por defecto (aprox. 90 por ciento) | Software de ofimática, juegos, altavoces inteligentes, discos duros | Autoevaluación (control interno, Módulo A) |
| Importante Clase I (Anexo III) | Gestores de contraseñas, VPN, firewalls, SIEM, gestores de red | Autoevaluación si se aplican normas armonizadas, o tercera parte |
| Importante Clase II (Anexo III) | Hipervisores, cortafuegos industriales, microcontroladores resistentes a manipulación | Evaluación por organismo notificado obligatoria |
| Crítico (Anexo IV) | Pasarelas de contadores inteligentes, tarjetas inteligentes, HSM | Puede exigir certificación europea EUCC |
La consecuencia práctica es que la mayoría de los fabricantes podrán autocertificarse, pero deberán generar y conservar la documentación técnica del Anexo VII, emitir la declaración UE de conformidad y estampar el marcado CE. Los productos de Clase II y críticos necesitan un tercero acreditado.
Obligaciones principales
Los requisitos esenciales viven en el Anexo I, dividido en propiedades del producto (Parte I) y gestión de vulnerabilidades (Parte II).
Seguridad desde el diseño (security by design)
El producto debe entregarse seguro por defecto: sin vulnerabilidades explotables conocidas, con superficie de ataque minimizada, con protección de la confidencialidad, integridad y disponibilidad de los datos, con control de acceso robusto y con mecanismos de actualización seguros (firmados y verificables). En la práctica esto implica modelado de amenazas en el ciclo de desarrollo, hardening de configuración de fábrica y despliegue de un canal de actualización automática cuando sea apropiado. Es el mismo enfoque que aplicamos en proyectos de desarrollo seguro y DevSecOps.
Gestión de vulnerabilidades, SBOM y actualizaciones
La Parte II del Anexo I es la más operativa y la que más transforma la ingeniería:
- SBOM (Software Bill of Materials): el fabricante debe elaborar un inventario de componentes en formato legible por máquina, cubriendo al menos las dependencias de primer nivel. Los formatos estándar son CycloneDX y SPDX, generables con herramientas como
syfto integrables en un OWASP Dependency-Track. - Remediación sin demora: identificar y corregir vulnerabilidades a través de actualizaciones de seguridad, cotejando dependencias contra NVD y OSV.
- Periodo de soporte: entregar actualizaciones de seguridad gratuitas durante al menos 5 años, o durante la vida útil esperada del producto si es inferior.
- Actualizaciones firmadas: distribuir parches por un canal seguro, con firma criptográfica verificable (
sigstore,cosign).
Este bloque conecta directamente con la disciplina de defensa de la cadena de suministro que tratamos en qué es un supply chain attack.
Divulgación coordinada de vulnerabilidades
El CRA exige una política de divulgación coordinada de vulnerabilidades (CVD) y un punto de contacto para que investigadores reporten fallos. En términos concretos: publicar un fichero security.txt (RFC 9116), alinear el proceso interno con ISO/IEC 29147 (divulgación) e ISO/IEC 30111 (tratamiento), y valorar un programa de bug bounty. Explicamos el ecosistema en qué es un programa de bug bounty.
Notificación a ENISA: 24h / 72h / 14 días
Aquí está la novedad que más carga operativa añade. Cuando un fabricante tiene constancia de una vulnerabilidad activamente explotada en su producto, o de un incidente grave con impacto en la seguridad del producto, debe notificar a través de la plataforma única de notificación que gestiona ENISA, con destino al CSIRT coordinador designado:
- Alerta temprana en 24 horas desde que se tiene constancia.
- Notificación de la vulnerabilidad o incidente en 72 horas, con detalles y medidas correctoras o de mitigación adoptadas.
- Informe final en 14 días tras disponer de una medida correctora (para vulnerabilidades explotadas), o en 1 mes en el caso de incidentes graves.
El esquema recuerda al modelo de notificación de NIS2, pero el sujeto obligado es el fabricante del producto, no el operador del servicio.
Calendario de aplicación
El CRA se aplica de forma escalonada:
| Hito | Fecha |
|---|---|
| Publicación en el DOUE | 20 nov 2024 |
| Entrada en vigor | 10 dic 2024 |
| Aplicación de las normas sobre organismos notificados (Capítulo IV) | 11 jun 2026 |
| Obligaciones de notificación a ENISA (artículo 14) | 11 sep 2026 |
| Plena aplicación del resto de obligaciones | 11 dic 2027 |
La lectura estratégica: las obligaciones de reporte llegan antes que el resto. Desde septiembre de 2026 hay que tener montado el flujo de notificación 24h/72h/14 días aunque la conformidad plena del producto no sea exigible hasta diciembre de 2027.
Sanciones
El régimen sancionador del artículo 64 es severo y se estructura en tres niveles:
| Incumplimiento | Multa máxima |
|---|---|
| Requisitos esenciales (Anexo I) y obligaciones de los artículos 13 y 14 | 15 M€ o 2,5 por ciento de la facturación mundial anual, lo que sea mayor |
| Resto de obligaciones | 10 M€ o 2 por ciento |
| Información incorrecta o engañosa a organismos notificados y autoridades de vigilancia | 5 M€ o 1 por ciento |
Como en NIS2, la multa se calcula sobre la facturación mundial del grupo, no solo sobre la actividad europea, lo que sitúa el CRA en el rango sancionador más alto de la regulación digital europea.
Checklist de cumplimiento para fabricantes
- Determina el ámbito: confirma si tu producto es un producto con elementos digitales y clasifícalo (por defecto, importante Clase I o II, crítico).
- Integra seguridad desde el diseño: modelado de amenazas, configuración segura por defecto, canal de actualización firmado.
- Genera el SBOM: adopta CycloneDX o SPDX y automatiza su generación en el pipeline de CI/CD.
- Monta la gestión de vulnerabilidades: monitorización de dependencias (NVD, OSV), remediación y actualizaciones durante al menos 5 años.
- Publica la política CVD:
security.txt, contacto de seguridad y proceso alineado con ISO/IEC 29147 y 30111. - Prepara el flujo de notificación: plantillas y guardia para cumplir 24h/72h/14 días en la plataforma de ENISA.
- Cierra la conformidad: documentación técnica (Anexo VII), declaración UE de conformidad, marcado CE y, para Clase II y críticos, organismo notificado.
- Documenta la información al usuario (Anexo II): periodo de soporte, cómo recibir actualizaciones y cómo reportar vulnerabilidades.
Preguntas frecuentes
¿Qué significa CRA y qué es el Cyber Resilience Act?
CRA son las siglas de Cyber Resilience Act, el Reglamento (UE) 2024/2847. Es la primera norma europea que fija requisitos obligatorios de ciberseguridad para los productos con elementos digitales (hardware y software) durante todo su ciclo de vida, con marcado CE y sanciones.
¿Cuándo entra en vigor el CRA?
Entró en vigor el 10 de diciembre de 2024. Las obligaciones de notificación de vulnerabilidades explotadas se aplican desde el 11 de septiembre de 2026 y el resto de obligaciones desde el 11 de diciembre de 2027.
¿El CRA obliga al software de código abierto?
El software libre desarrollado fuera de una actividad comercial queda en gran parte excluido. Las figuras de administrador de software libre (open source steward) que sostienen proyectos integrados en productos comerciales asumen obligaciones aligeradas, no el régimen completo del fabricante.
¿En qué se diferencia el CRA de NIS2?
NIS2 obliga a las organizaciones (entidades esenciales e importantes) a gestionar la seguridad de sus redes y sistemas. El CRA obliga a los fabricantes a que los productos que ponen en el mercado sean seguros y se mantengan actualizados. Son marcos complementarios que pueden aplicar a la vez.
¿Cuánto tiempo hay que dar soporte de seguridad?
El fabricante debe proporcionar actualizaciones de seguridad gratuitas durante un mínimo de 5 años, salvo que la vida útil esperada del producto sea inferior, en cuyo caso se ajusta a esa vida útil.
Prepara tu producto para el CRA con Secra
En Secra ayudamos a fabricantes a cerrar la brecha con el Cyber Resilience Act: análisis de ámbito y clasificación, SBOM y gestión de vulnerabilidades, diseño del flujo de notificación a ENISA y preparación de la evaluación de la conformidad.
→ Conoce nuestro servicio de desarrollo seguro y DevSecOps
→ Habla con nuestro equipo de consultoría GRC
Lecturas relacionadas
Sobre el autor
Equipo de Secra Solutions
Ethical hackers certificados OSCP, OSEP, OSWE, CRTO, CRTL y CARTE, con más de 7 años de experiencia en ciberseguridad ofensiva. Autores de los CVE-2025-40652 y CVE-2023-3512.