CRA
CRA — Reglamento (UE) 2024/2847
El Reglamento de Ciberresiliencia obliga a quien pone software o hardware conectado en el mercado europeo: SBOM, periodo de soporte declarado, notificación de vulnerabilidades explotadas en 24 horas y marcado CE.
- A quién aplica
- Fabricantes, importadores y distribuidores que introduzcan o comercialicen en el mercado de la Unión productos con elementos digitales, es decir, cualquier producto de software o hardware cuya utilización prevista incluya una conexión de datos, directa o indirecta, a un dispositivo o red. Las obligaciones de evaluación de la conformidad varían según el producto sea ordinario, importante (anexo III, clases I y II) o crítico (anexo IV). Quedan fuera, entre otros, los productos ya cubiertos por normativa sectorial específica y el software libre desarrollado fuera de una actividad comercial.
- Plazo
- Aplicable en su totalidad desde el 11 de diciembre de 2027. El artículo 14, que impone la notificación de vulnerabilidades explotadas activamente e incidentes graves, se aplica antes: desde el 11 de septiembre de 2026. El capítulo IV, sobre organismos notificados, desde el 11 de junio de 2026.
- Referencia oficial
- Reglamento (UE) 2024/2847, de 23 de octubre de 2024
Por qué el CRA se parece más al marcado CE que a la NIS2
El Reglamento (UE) 2024/2847 no regula cómo proteges tu organización, sino qué puedes vender. Es legislación de producto, del mismo linaje que las normas que obligan a poner el marcado CE en un juguete o una lavadora. La consecuencia práctica es que el incumplimiento no se paga sólo en multa: se paga en que la autoridad de vigilancia del mercado te retira el producto.
Esto cambia quién es el dueño interno del proyecto. En NIS2 o DORA el expediente lo lleva el área de seguridad o de cumplimiento. En el CRA lo lleva ingeniería de producto, porque casi todas las obligaciones se resuelven en el ciclo de desarrollo: SBOM, gestión de vulnerabilidades, actualizaciones firmadas, política de divulgación.
El calendario escalonado importa más de lo que parece
El reglamento entró en vigor el 10 de diciembre de 2024 pero se aplica por tramos. El capítulo IV, que regula los organismos notificados, desde el 11 de junio de 2026. El artículo 14, que impone la notificación de vulnerabilidades explotadas activamente e incidentes graves, desde el 11 de septiembre de 2026. Y el resto, desde el 11 de diciembre de 2027.
Ese orden no es casual y tiene una lectura operativa: la primera obligación que te alcanza no es la de diseñar mejor, es la de contar lo que te pasa. Antes de que nadie te exija un expediente técnico completo, ya tienes que ser capaz de detectar una explotación activa y notificarla en 24 horas por un canal formal.
Tres categorías de producto, tres niveles de prueba
El anexo III lista los productos importantes en dos clases —gestores de contraseñas, antivirus, VPN, sistemas operativos, microprocesadores con funciones de seguridad y varias decenas más— y el anexo IV los productos críticos. Cuanto más arriba en esa escala, menos margen hay para la autoevaluación y más peso tiene el tercero independiente. Determinar en qué categoría cae tu producto es la primera decisión del proyecto, porque cambia por completo el coste y el plazo de la conformidad.
Qué se paga por no cumplir
El artículo 64.2 fija multas administrativas de hasta 15 millones de euros o, si el infractor es una empresa, hasta el 2,5 % del volumen de negocios mundial total del ejercicio anterior, la cifra que sea mayor, para el incumplimiento de los requisitos esenciales del anexo I y de las obligaciones de los artículos 13 y 14. Otros incumplimientos bajan a 10 millones o el 2 %, y facilitar información incorrecta, incompleta o engañosa a un organismo notificado o a una autoridad de vigilancia, a 5 millones o el 1 %. El artículo 64.10 modula la aplicación a microempresas y pequeñas empresas en determinados supuestos.
Obligaciones
-
Diseñar conforme a los requisitos esenciales del anexo I
El artículo 13.1 exige que el producto se haya diseñado, desarrollado y producido conforme a los requisitos esenciales de ciberseguridad de la parte I del anexo I. No es una lista que se cumpla al final: la obligación recae sobre el proceso de desarrollo, y por eso la evidencia mira hacia atrás, a decisiones de diseño ya tomadas.
Evidencia exigible
Documentación técnica del anexo VII que incluya, requisito a requisito, cómo se implementa y —cuando alguno no aplique— la justificación clara y expresa de por qué no aplica a ese producto, tal como exige el artículo 13.4.
-
Documentar una evaluación de riesgos de ciberseguridad y mantenerla viva
Los apartados 2 a 4 del artículo 13 obligan a realizar una evaluación de los riesgos de ciberseguridad del producto, tenerla en cuenta en planificación, diseño, desarrollo, producción, entrega y mantenimiento, documentarla, actualizarla durante todo el periodo de soporte e incluirla en la documentación técnica. La evaluación debe indicar si los requisitos de seguridad del punto 2 de la parte I del anexo I son aplicables y de qué modo se implementan.
Evidencia exigible
El documento de evaluación con versión, fecha y autor, vinculado a la versión concreta del producto, más el historial que demuestre que se actualizó tras los cambios relevantes y no sólo en el lanzamiento inicial.
-
Mantener un SBOM legible por máquina
El punto 1 de la parte II del anexo I obliga a identificar y documentar las vulnerabilidades y componentes contenidos en el producto, incluido el trazado de una lista de materiales de software en un formato de uso común y legible por máquina que cubra, como mínimo, las dependencias de primer nivel. El artículo 13.25 permite además que las autoridades de vigilancia del mercado soliciten el SBOM en el marco de evaluaciones de dependencia a escala de la Unión.
Evidencia exigible
El fichero SBOM en un formato de uso común, con fecha de generación y trazabilidad inequívoca a la versión del producto entregada. Un SBOM generado a mano en una hoja de cálculo no cumple el requisito de «legible por máquina».
-
Ejercer diligencia debida sobre componentes de terceros y reportar aguas arriba
El artículo 13.5 exige diligencia debida al integrar componentes de terceros, incluidos componentes de software libre no comercializados. El 13.6 añade una obligación poco conocida: al identificar una vulnerabilidad en un componente integrado, el fabricante debe reportarla a quien fabrica o mantiene ese componente, remediarla en su propio producto y, si ha desarrollado una modificación que la corrige, compartir el código o la documentación con el mantenedor, cuando proceda en formato legible por máquina.
Evidencia exigible
Registro de comunicaciones al mantenedor del componente con fecha y contenido —una incidencia pública, un correo archivado o una propuesta de cambio— junto al criterio documentado de diligencia debida aplicado antes de integrar el componente.
-
Publicar una política de divulgación coordinada y un punto de contacto único
Los puntos 5 y 6 de la parte II del anexo I obligan a establecer y aplicar una política de divulgación coordinada de vulnerabilidades y a facilitar una dirección de contacto para reportarlas. El artículo 13.17 exige designar un punto de contacto único que permita a los usuarios comunicarse directa y rápidamente con el fabricante, y el anexo II obliga a que ese punto figure en la información que acompaña al producto.
Evidencia exigible
La política publicada en una URL estable, con fecha de versión y plazos de respuesta comprometidos, y el registro de recepciones que demuestre que el canal está vivo: fecha de entrada, acuse y fecha de resolución de cada reporte.
-
Notificar vulnerabilidades explotadas activamente e incidentes graves
El artículo 14 impone dos secuencias paralelas ante el CSIRT designado como coordinador y ENISA, a través de la plataforma única de notificación del artículo 16. Para una vulnerabilidad explotada activamente: alerta temprana en 24 horas desde que se tiene conocimiento, notificación de la vulnerabilidad en 72 horas e informe final como máximo 14 días después de que exista una medida correctora o mitigadora. Para un incidente grave que afecte a la seguridad del producto: alerta temprana en 24 horas, notificación del incidente en 72 horas e informe final en el plazo de un mes desde esa notificación. El CSIRT puede además pedir informes intermedios.
Evidencia exigible
Acuse de la plataforma única de notificación con sello de tiempo para cada hito, y el registro interno del momento de «conocimiento» y —en el caso de la vulnerabilidad— de la fecha en que la corrección estuvo disponible, que es la que abre el plazo de 14 días.
-
Determinar, justificar y publicar el periodo de soporte
El artículo 13.8 exige determinar un periodo de soporte que refleje el tiempo durante el cual se espera que el producto esté en uso, con un suelo de cinco años salvo que la vida útil prevista sea menor. La información que se tuvo en cuenta para determinarlo se incluye en la documentación técnica. El artículo 13.19 obliga a especificar de forma clara y accesible la fecha de fin de soporte, al menos mes y año, en el momento de la compra. Y el artículo 13.9 exige que cada actualización de seguridad siga disponible al menos 10 años tras su publicación, o durante el resto del periodo de soporte si es mayor.
Evidencia exigible
Captura o prueba documental de dónde aparece la fecha de fin de soporte en el punto de venta, embalaje o medio digital, junto al expediente que justifica el cálculo del periodo conforme a los criterios del artículo 13.8.
-
Seguir el procedimiento de evaluación de la conformidad de tu clase de producto
El artículo 32 gradúa la exigencia. Un producto ordinario puede acogerse al control interno de producción (módulo A). Un producto importante de clase I del anexo III sólo puede autoevaluarse si aplica íntegramente normas armonizadas, especificaciones comunes o un esquema europeo de certificación de nivel «sustancial»; si no, pasa a examen UE de tipo (módulos B y C) o aseguramiento de calidad total (módulo H). Un producto importante de clase II va obligatoriamente a un procedimiento con organismo notificado o a un esquema europeo de nivel al menos «sustancial». Los productos críticos del anexo IV exigen esquema europeo de certificación cuando concurran las condiciones del artículo 8.1.
Evidencia exigible
La declaración UE de conformidad y, cuando el procedimiento lo requiera, el certificado del organismo notificado o del esquema europeo, con el alcance y la versión del producto identificados. Si te apoyas en normas armonizadas para evitar el organismo notificado, la evidencia es el análisis que demuestra que las aplicaste íntegramente.