Cyber Resilience Act

El Cyber Resilience Act es el Reglamento (UE) 2024/2847, de 23 de octubre de 2024, sobre requisitos horizontales de ciberseguridad para los productos con elementos digitales. Obliga directamente, sin transposición nacional, y es una norma de producto y no de gestión: alcanza al hardware y al software puestos en el mercado europeo cuya finalidad prevista o uso razonablemente previsible incluya una conexión de datos, directa o indirecta, lógica o física, a un dispositivo o a una red. El artículo 2 deja fuera lo que ya regula otra norma sectorial: productos sanitarios, vehículos, aviación civil, equipos marinos y lo desarrollado exclusivamente para la defensa.

Entrada en vigor y aplicación son fechas distintas. Entró en vigor el 10 de diciembre de 2024, a los veinte días de su publicación, pero el artículo 71 lo declara aplicable a partir del 11 de diciembre de 2027. Dos bloques se adelantan: el capítulo IV, sobre notificación de los organismos de evaluación de la conformidad, desde el 11 de junio de 2026, y el artículo 14, el que obliga al fabricante a notificar, desde el 11 de septiembre de 2026.

La clasificación decide quién verifica. La mayoría de los productos van por el régimen por defecto, donde basta el control interno del fabricante. Los productos importantes del anexo III se reparten en clase I, diecinueve categorías entre las que hay navegadores, gestores de contraseñas, sistemas operativos y enrutadores, y clase II, cuatro: hipervisores y contenedores, cortafuegos y sistemas de detección o prevención de intrusiones, y microprocesadores y microcontroladores resistentes a manipulaciones. En la clase II el artículo 32 excluye el control interno: exige examen UE de tipo con conformidad con el tipo (módulos B y C) o aseguramiento de calidad total (módulo H), ambos con organismo notificado, salvo que medie un esquema europeo de certificación de nivel al menos sustancial. Por encima quedan los productos críticos del anexo IV, donde la Comisión puede exigir por acto delegado un certificado europeo de nivel al menos sustancial.

Los requisitos de fondo están en el anexo I: las propiedades de seguridad del producto y la gestión de vulnerabilidades durante el período de soporte. Ese período dura al menos cinco años, salvo que se prevea un uso más corto, y entonces vale ese tiempo; cada actualización de seguridad publicada sigue disponible un mínimo de diez años; y su fecha final, con mes y año, se indica de forma clara al comprar. El anexo I pide además documentar los componentes con una nomenclatura de materiales legible por máquina, que es la idea de un software bill of materials, sin obligar a publicarla.

El hueco al que apunta la regulación es el producto conectado que se vende y se olvida: firmware con credenciales incrustadas, sin mecanismo de actualización y sin proceso para atender el aviso de una vulnerabilidad que encuentre un investigador. Para el atacante ese es el objetivo fiable: un dispositivo que no se puede actualizar sigue siendo vulnerable toda su vida. Y un producto hereda las vulnerabilidades de sus componentes, así que un ataque a la cadena de suministro contra una dependencia se convierte en un problema que el fabricante tiene que detectar y comunicar.

La parte que más procesos rompe es el artículo 14, porque el reloj no lo arranca el fabricante. La obligación se dispara con una vulnerabilidad aprovechada activamente, definida como aquella de la que existen pruebas fiables de que un agente malintencionado la ha aprovechado en un sistema sin autorización de su propietario, y esas pruebas suelen aparecer fuera: un cliente, un investigador, un CSIRT. Desde ahí hay alerta temprana en veinticuatro horas y notificación en setenta y dos, a la vez al CSIRT designado como coordinador y a la ENISA, y un informe final catorce días después de que exista una medida correctora o paliativa.

Para los incidentes graves los plazos iniciales son los mismos y el informe final no: un mes desde la notificación de las setenta y dos horas. Y notificar tampoco agota el deber: el apartado 8 obliga a informar además a los usuarios afectados.

El último fallo es de identidad. Los artículos 21 y 22 convierten en fabricante, con los artículos 13 y 14 encima, a quien introduce un producto en el mercado con su nombre o su marca y a quien realiza una modificación sustancial de uno ya comercializado. Un integrador que reetiqueta hardware ajeno no es un distribuidor: es el fabricante de lo que vende.

Los tres se citan juntos y no compiten entre sí. El CRA regula el producto, NIS2 a la organización que presta el servicio, y el marcado CE es la declaración con la que un producto se comercializa. Un fabricante español de dispositivos conectados puede estar en los tres a la vez.

La consecuencia práctica es que la evidencia se solapa y los canales no. Lo del producto va por la plataforma única de notificación que el artículo 16 encarga a la ENISA, al nodo del CSIRT coordinador del Estado donde el fabricante tenga su establecimiento principal en la Unión, donde se toman de forma predominante las decisiones de ciberseguridad sobre sus productos. El mismo hecho, si afecta además a la operación de la entidad, puede ir por el canal nacional de NIS2.

Confundir la entrada en vigor con la aplicación. La que marca el cumplimiento es la segunda.

Dar por hecho que el catálogo antiguo queda a salvo. Lo comercializado antes del 11 de diciembre de 2027 solo queda sujeto si sufre después una modificación sustancial, pero el deber de notificar del artículo 14 se aplica a todo.

Fijar el período de soporte por conveniencia comercial. Debe reflejar el tiempo de uso previsto, con un suelo de cinco años.

Reetiquetar producto ajeno creyéndose distribuidor. Vender con marca propia convierte en fabricante, con los artículos 13 y 14 completos.

Tratar la nomenclatura de materiales como un documento comercial. El anexo I la pide legible por máquina y con las dependencias de máximo nivel como mínimo; que no haya que publicarla no significa que no haya que tenerla.

Clasifica el catálogo primero, producto por producto: fuera de ámbito, régimen por defecto, anexo III clase I, anexo III clase II o anexo IV. Esa decisión fija el coste y el calendario, porque decide si basta el control interno. Desde el Reglamento de Ejecución (UE) 2025/2392 esas categorías tienen descripción técnica publicada, así que la clasificación se argumenta contra un texto.

Decide después el período de soporte de cada producto y escribe el razonamiento: qué uso se prevé, qué esperan razonablemente los usuarios y qué obliga el resto del Derecho de la Unión. Al lado va la disponibilidad de las actualizaciones durante diez años, que es un compromiso de archivo más que de ingeniería.

Monta el proceso de notificación antes del 11 de septiembre de 2026 y ensáyalo: quién decide que hay pruebas fiables de aprovechamiento activo, quién redacta en veinticuatro horas, quién tiene credenciales en la plataforma, qué CSIRT es el coordinador y cómo se avisa a los usuarios afectados. El primer intento no debería coincidir con el primer incidente.

Y produce la evidencia técnica de forma continua: comercializar sin vulnerabilidades explotables conocidas se demuestra con pruebas fechadas y un registro de corrección, no con una declaración. Un ciclo de pentesting sobre el producto, con su retest, sirve a la conformidad y a la gestión de vulnerabilidades a la vez.

Una evaluación contra lo que espera el CRA prueba las propiedades del anexo I: si el producto sale libre de fallos explotables conocidos, si impone integridad en el arranque mediante arranque seguro, si las actualizaciones están autenticadas y llegan al parque ya desplegado, y si los componentes están inventariados. En productos industriales el marco de control suele ser IEC 62443. El hallazgo se ata a las dos cosas, la vulnerabilidad técnica y la obligación que toca.

Lo segundo que se audita no es el producto sino el proceso: si hay un punto por el que entran los avisos, si alguien decide la clasificación, si los plazos de veinticuatro y setenta y dos horas tienen dueño, y si la nomenclatura de materiales se genera en cada compilación o se escribió una vez.

No asesoramos sobre el alcance jurídico ni sobre los deberes de notificación, y lo decimos. Lo que aportamos es la evidencia técnica, en una forma que puedan leer un organismo notificado o el equipo de conformidad de un cliente. Esto forma parte de cómo probamos un producto contra sus obligaciones de seguridad.

¿Desde cuándo se aplica el CRA? Entró en vigor el 10 de diciembre de 2024 y será aplicable con carácter general desde el 11 de diciembre de 2027. Se adelantan el capítulo IV, sobre los organismos de evaluación de la conformidad, al 11 de junio de 2026, y las obligaciones de notificación del fabricante al 11 de septiembre de 2026.

¿A qué productos se aplica? A los productos con elementos digitales cuya finalidad prevista o uso razonablemente previsible incluya una conexión de datos, directa o indirecta, a un dispositivo o a una red. Quedan fuera, entre otros, los productos sanitarios, los vehículos, la aviación civil y los equipos marinos.

¿Cuánto tiene que durar el soporte? Al menos cinco años, salvo que se prevea que el producto se utilice menos tiempo, y entonces el período de soporte es ese tiempo previsto. Cada actualización de seguridad publicada sigue disponible un mínimo de diez años, y la fecha final del soporte se indica al comprar.

¿Qué hay que notificar y en cuánto tiempo? Las vulnerabilidades aprovechadas activamente y los incidentes graves, al CSIRT coordinador y a la ENISA a la vez: alerta temprana en veinticuatro horas y notificación en setenta y dos. El informe final llega catorce días después de que exista una medida correctora, o en un mes si es un incidente grave.

¿Cuáles son las multas? Incumplir los requisitos esenciales del anexo I o las obligaciones de los artículos 13 y 14 llega hasta 15.000.000 EUR o el 2,5 % del volumen de negocio total anual mundial, si esta cifra es superior. Ese es el tramo más alto del reglamento, y el resto de obligaciones tiene topes menores.