Cyber Resilience Act: la nueva obligación de notificar vulnerabilidades e incidentes en 24 horas

Qué deben comunicar los fabricantes desde el 11 de septiembre de 2026, cómo se cuentan los plazos y qué implica para la gobernanza de IA.

La novedad afecta a una decisión empresarial concreta: quién recibe una alerta técnica, quién determina sus consecuencias jurídicas y quién dispone de información y facultades para comunicarla a tiempo. Una empresa puede tener buenos controles preventivos y descubrir, durante un incidente, que nadie ha preparado ese procedimiento.

Para actuar correctamente hay que identificar el producto, el papel de la organización y el problema de seguridad. También deben coordinarse las obligaciones sobre datos personales, servicios esenciales o actividad financiera que resulten aplicables. Esa preparación conecta la ciberresiliencia con la gobernanza de la inteligencia artificial, pero el CRA comprende también productos que no utilizan IA.

1. El calendario del Cyber Resilience Act y la obligación que ya se aplica

El Reglamento UE 2024/2847, conocido como Reglamento de Ciberresiliencia, establece requisitos comunes de ciberseguridad para productos con elementos digitales comercializados en la Unión Europea. Abarca su diseño, desarrollo y gestión de vulnerabilidades, junto con la documentación y la evaluación de conformidad correspondientes.

Su entrada en vigor se produjo el 10 de diciembre de 2024. Desde el 11 de junio de 2026 se aplica el capítulo relativo a los organismos de evaluación de la conformidad. El artículo 14, dedicado a las obligaciones de información de los fabricantes, se aplica desde el 11 de septiembre de 2026. La aplicación general llegará el 11 de diciembre de 2027.

Esta diferencia tiene una consecuencia: esperar a 2027 para organizar las notificaciones deja sin atender una obligación actual. Además, el artículo 69.3 extiende la notificación a productos incluidos que se hayan introducido en el mercado antes de esa fecha. La antigüedad del producto no basta para descartarlo.

2. Qué empresas y productos deben revisar su situación

El CRA se aplica a productos de hardware y software cuya utilización prevista o razonablemente previsible implique una conexión de datos, directa o indirecta, con otro dispositivo o una red. La conexión puede ser física o lógica. Su ámbito va más allá de los aparatos conectados directamente a internet.

Pueden quedar comprendidos dispositivos domésticos conectados, equipos industriales, programas informáticos y componentes comercializados separadamente. La comprobación debe atender a sus funciones y forma de suministro. Una conexión exclusivamente eléctrica, por ejemplo, no acredita por sí sola la conexión de datos que exige la norma.

La condición de fabricante tampoco se limita a quien produce un equipo en una fábrica. Puede corresponder a quien desarrolla software o encarga su desarrollo y lo comercializa bajo su nombre o marca. Las decisiones sobre marca propia, comercialización y modificaciones del producto requieren una revisión jurídica.

Utilizar tecnología adquirida a un proveedor no convierte automáticamente a una empresa en fabricante. Un hotel que emplea una aplicación de reservas o una sociedad que contrata herramientas de IA debe distinguir esa utilización de la comercialización de productos propios. También deben diferenciarse las obligaciones de fabricantes, importadores y distribuidores, respetando el calendario aplicable a cada una.

Los servicios en la nube necesitan especial atención. El software como servicio, o SaaS, no queda incluido automáticamente. Determinadas soluciones de tratamiento remoto diseñadas bajo responsabilidad del fabricante y necesarias para una función del producto pueden formar parte de este. La etiqueta comercial del servicio resulta insuficiente para resolver su encaje.

Existen exclusiones, entre ellas determinados productos sanitarios y productos cubiertos por normas específicas. El software libre y de código abierto suministrado fuera de una actividad comercial queda excluido del Reglamento. Las pymes, en cambio, no disfrutan de una exención general por su tamaño. El diagnóstico debe justificar cada conclusión y conservar la información técnica utilizada.

La cadena de suministro introduce otra cuestión frecuente. Un producto puede incorporar bibliotecas, programas o servicios de otros proveedores. Que el defecto proceda de uno de esos componentes no permite al fabricante desentenderse de su producto. Debe comprobar si la vulnerabilidad está presente y puede aprovecharse en él, qué versiones están afectadas y qué medidas existen. Un inventario de componentes de software, con sus versiones y dependencias, facilita esa comprobación y ayuda a localizar a los proveedores necesarios. La notificación que presente un tercero tampoco permite presumir, sin analizar el caso, que las obligaciones propias han quedado atendidas.

3. Las dos situaciones que obligan a notificar

El artículo 14 establece dos supuestos diferenciados. El primero es una vulnerabilidad aprovechada activamente: existen pruebas fiables de que un actor malintencionado la ha explotado en un sistema sin autorización de su propietario.

Descubrir un fallo potencial, asignarle una gravedad técnica elevada o demostrar su explotación en una prueba autorizada no equivale, por sí solo, a ese supuesto. La diferencia está en la evidencia de aprovechamiento malicioso. Pensemos en un fabricante que recibe pruebas de que atacantes están utilizando un defecto de autenticación de su producto para acceder a sistemas ajenos.

El segundo supuesto es un incidente grave que repercute en la seguridad del producto. El Reglamento contempla incidentes que afectan o pueden afectar negativamente a su capacidad para proteger la disponibilidad, autenticidad, integridad o confidencialidad de datos o funciones sensibles o importantes. También comprende los que introducen o pueden introducir o ejecutar código malicioso en el producto o en los sistemas de sus usuarios.

Un ejemplo sería comprometer el mecanismo de actualización de un programa y utilizarlo para distribuir código malicioso. La valoración debe considerar las consecuencias posibles previstas en la norma, aunque todavía no se hayan materializado todas.

La obligación CRA puede existir sin una filtración de datos personales. A su vez, una interrupción ordinaria del servicio no constituye necesariamente un incidente grave notificable. Para resolverlo, el equipo técnico debe aportar los hechos y el análisis jurídico debe comprobar los criterios legales.

4. Cómo se cuentan las 24 y las 72 horas

Los dos primeros plazos parten del mismo momento de conocimiento. Las 72 horas no se añaden a las primeras 24. Tanto la alerta temprana como la notificación posterior deben presentarse sin demora indebida, dentro de sus respectivos máximos.

Supongamos que el fabricante conoce el supuesto notificable el viernes 11 de septiembre a las 09:00. El límite de la alerta temprana será el sábado 12 a las 09:00. El de la notificación ampliada será el lunes 14 a las 09:00. Son horas continuas: el fin de semana obliga a disponer de una respuesta organizada.

El momento relevante tampoco puede trasladarse artificialmente a la reunión del comité o a la aprobación de un informe interno. Conviene registrar cuándo se recibió la información, qué evidencias existían y cómo evolucionó la valoración. Conocer una vulnerabilidad potencial y conocer su aprovechamiento activo son situaciones distintas que deben quedar documentadas.

La información exigida aumenta por fases. La alerta permite advertir inicialmente del problema. La comunicación de las 72 horas amplía la información disponible sobre el producto, la vulnerabilidad o el incidente y las medidas adoptadas o recomendadas. El informe final desarrolla sus características y consecuencias y, según el supuesto, las causas probables y las soluciones disponibles.

El Reglamento permite que la información pertinente ya presentada evite repeticiones y contempla actualizaciones a petición del coordinador. No exige concluir toda la investigación en 72 horas. Sí exige comunicar lo disponible con rigor, identificar lo que sigue en investigación y completar el expediente conforme al procedimiento.

5. La plataforma de ENISA y la información a los usuarios

La Single Reporting Platform de ENISA, operativa desde el 11 de septiembre de 2026, canaliza estas notificaciones. La regla general es su presentación al CSIRT designado como coordinador y el acceso simultáneo de ENISA. Los CSIRT son equipos especializados en respuesta a incidentes de seguridad informática.

La elección del coordinador sigue los criterios del artículo 14.7, empezando por el establecimiento principal del fabricante en la Unión. La lista oficial de ENISA remite, para España, a INCIBE-CERT. Un correo ordinario de asistencia no debe confundirse con el procedimiento formal de notificación.

Prepararse implica conocer los accesos y las facultades de representación. ENISA exige cuentas personales EU Login con autenticación multifactor y recomienda iniciar el registro en la plataforma cuando sea necesario notificar. La validación se desarrolla en paralelo y no impide presentar inicialmente la comunicación, conforme a sus instrucciones operativas.

El artículo 14.8 exige informar a los usuarios afectados y, cuando proceda, a todos los usuarios, incluyendo las medidas pertinentes para reducir las consecuencias. Esa comunicación debe ser comprensible y permitir actuar. La notificación a las autoridades y el aviso a usuarios cumplen funciones diferentes y deben prepararse de forma coordinada.

La gestión de la confidencialidad merece atención específica. Avisar a un usuario puede exigir identificar versiones afectadas, explicar cómo actualizar y recomendar medidas temporales, evitando divulgar detalles que faciliten nuevos ataques. El Reglamento contempla mecanismos excepcionales para limitar o aplazar la difusión de información entre autoridades. Su existencia no autoriza al fabricante a retrasar unilateralmente la notificación mientras prepara una solución. El procedimiento debe permitir trasladar información sensible por el canal adecuado y justificar las precauciones solicitadas.

El mero acto de notificar no incrementa por sí mismo la responsabilidad del notificante, conforme al artículo 17.4, aunque tampoco elimina las responsabilidades derivadas del propio incidente.

6. La coordinación entre las obligaciones de notificación

Una misma crisis puede afectar a productos, datos personales y servicios sometidos a regulación sectorial. Cada empresa debe identificar sus obligaciones y las de otras entidades implicadas, con sus respectivos umbrales, autoridades y plazos.

El RGPD exige al responsable del tratamiento notificar determinadas brechas a la autoridad competente sin demora indebida y, cuando sea posible, dentro de las 72 horas desde su conocimiento. Existe una excepción cuando sea improbable que la brecha entrañe un riesgo para los derechos y libertades. El encargado informa al responsable sin demora indebida, y la comunicación a los afectados responde a requisitos propios.

La Directiva NIS2 se ocupa de incidentes significativos en entidades comprendidas en su ámbito. Su esquema general incluye alerta en 24 horas, notificación en 72 horas e informe final posterior, con especialidades. En España debe comprobarse la normativa nacional aplicable a la entidad antes de trasladar esos plazos a una actuación concreta.

DORA regula la resiliencia operativa digital de determinadas entidades financieras. Tiene criterios y plazos propios para incidentes graves relacionados con las TIC. Su regulación de notificaciones contempla, como regla, un aviso inicial dentro de las cuatro horas siguientes a la clasificación como grave y antes de superar 24 horas desde el conocimiento, con reglas específicas para la clasificación posterior.

Tampoco procede sumar automáticamente cuatro obligaciones. Deben aplicarse las reglas de especialidad, incluida la relación entre DORA y NIS2. Un incidente puede generar una notificación CRA para el fabricante y otra obligación distinta para el cliente financiero que utiliza su producto. La coordinación comienza por asignar correctamente cada responsabilidad.

Un supuesto ayuda a visualizarlo. Una empresa comercializa cámaras conectadas con software propio. Un cliente detecta accesos no autorizados a las grabaciones y avisa al fabricante. Este confirma que se está aprovechando un fallo del producto. El fabricante deberá valorar y atender su obligación CRA desde que conozca el supuesto notificable. El cliente, si actúa como responsable de las grabaciones, analizará además la brecha conforme al RGPD. Ambos necesitarán información compartida sobre lo ocurrido, pero sus destinatarios, plazos y decisiones jurídicas pueden ser diferentes. El contrato debe facilitar esa colaboración sin condicionar una comunicación legalmente exigible a la aprobación de la otra parte. Tampoco debe darse por supuesto que ambos tuvieron conocimiento en el mismo momento.

7. El Ómnibus Digital y su relación con la gobernanza de IA

La propuesta general de Ómnibus Digital busca simplificar obligaciones y coordinar notificaciones. A 16 de septiembre de 2026, su procedimiento legislativo continúa en curso. La plataforma del CRA no permite dar por cumplidos, sin análisis adicional, todos los deberes previstos en otras normas.

Este expediente debe distinguirse del Ómnibus sobre IA, al que dedicamos nuestros análisis sobre la reforma del AI Act y su publicación y efectos sobre el artículo 50. Cada calendario debe aplicarse a la obligación concreta que regula.

Para las organizaciones que desarrollan o utilizan IA, la conexión práctica es clara. Un inventario útil debe relacionar cada sistema con sus productos, versiones, proveedores y responsables. La documentación debe permitir saber quién detecta un fallo, quién puede detener un despliegue y quién conserva las evidencias.

El análisis de las 16 guías de la AESIA ya situaba la ciberseguridad, la trazabilidad y la gestión de incidentes dentro del cumplimiento de IA. El CRA añade su propio análisis de producto y obligaciones. Cumplir una norma no demuestra automáticamente el cumplimiento completo de la otra.

El artículo 12 del CRA prevé una coordinación específica con determinados sistemas de IA de alto riesgo. Su alcance es limitado y condicionado. Los equipos deben comprobar la concurrencia de ambos regímenes, sus requisitos y sus fechas, sin utilizar una certificación o una política interna como sustituto de ese análisis.

8. Diez medidas para preparar una respuesta que funcione

La preparación debe adaptarse al tamaño, los productos y la organización. Estas medidas ayudan a convertir las obligaciones en actuaciones comprobables.

1. Inventariar los productos. Identificar funciones, versiones, mercados y sociedades responsables. Documentar las razones de inclusión o exclusión, así como las cuestiones técnicas pendientes. El inventario debe actualizarse cuando cambien el producto o su comercialización.
2. Asignar responsables y suplentes. Determinar quién recibe las alertas, quién decide y quién presenta las notificaciones. La dirección debe facilitar capacidad de actuación fuera del horario habitual cuando resulte necesaria.
3. Preparar el acceso al canal oficial. Comprobar las cuentas, autenticación y datos necesarios, siguiendo las instrucciones vigentes de ENISA. Las credenciales y facultades deben corresponder a las personas que realmente intervendrán.
4. Registrar el conocimiento del incidente. Establecer cómo llegan las alertas de proveedores, investigadores, clientes y equipos internos. Conservar sus fechas y evidencias para justificar el inicio del cómputo y las decisiones posteriores.
5. Definir criterios de valoración. Separar fallos potenciales, aprovechamiento activo e incidentes graves. Las puntuaciones técnicas ayudan, pero la decisión debe responder a los supuestos legales y revisarse cuando aparezca información adicional.
6. Coordinar los equipos. Seguridad y producto aportan hechos y medidas. Legal determina obligaciones. Protección de datos participa cuando corresponda. Una persona debe mantener una cronología compartida que evite versiones contradictorias.
7. Revisar los contratos tecnológicos. Pactar avisos de proveedores con margen suficiente, colaboración, acceso a evidencias y responsabilidades de corrección. Encargar un desarrollo a un tercero no resuelve por sí solo quién responde legalmente.
8. Preparar comunicaciones diferenciadas. Disponer de modelos para autoridades y usuarios, adaptados a cada fase. Los textos deben distinguir hechos confirmados, información provisional y medidas recomendadas, sin adelantar conclusiones todavía no verificadas.
9. Conservar el expediente. Guardar notificaciones, justificantes, evaluaciones y actualizaciones. También interesa documentar por qué un hecho se consideró inicialmente no notificable y qué información motivó un cambio posterior de criterio.
10. Realizar un ejercicio interno. Simular un supuesto realista y comprobar tiempos, sustituciones y disponibilidad de información. El resultado debe servir para corregir fallos del procedimiento antes de que ocurra un incidente efectivo.

9. La preparación para diciembre de 2027

La aplicación general incorporará exigencias sobre seguridad desde el diseño, evaluación de riesgos, documentación, gestión de vulnerabilidades y conformidad. Las categorías de productos importantes y críticos condicionarán los procedimientos aplicables. El marcado CE deberá responder al cumplimiento de los requisitos correspondientes.

También habrá que determinar correctamente el período de soporte. Debe reflejar el tiempo esperado de utilización y, como regla, alcanzar al menos cinco años, salvo productos cuya utilización prevista sea inferior. Esto afecta a decisiones sobre mantenimiento, actualizaciones y contratos que conviene preparar con antelación.

El artículo 64 contempla multas de hasta 15 millones de euros o, para empresas, el 2,5 % del volumen de negocio anual mundial del ejercicio anterior, si resulta superior, para determinadas infracciones. Ese régimen sancionador sigue el calendario general de diciembre de 2027. Su tratamiento exige atender también a las excepciones y criterios de proporcionalidad previstos, sin presentar esas cuantías como una sanción automática vigente desde septiembre de 2026.

10. Cómo puede ayudar Delvy

Desde el área de IA y Gobernanza Digital de Delvy acompañamos la preparación jurídica de la ciberresiliencia, en coordinación con protección de datos y contratación tecnológica. El servicio comienza por determinar qué productos y sociedades están incluidos y qué obligaciones corresponden a cada uno.

A partir de ese diagnóstico, podemos preparar el protocolo de respuesta, revisar contratos y elaborar las plantillas de comunicación. Ante un incidente, el acompañamiento comprende su valoración jurídica, el cálculo de plazos y la preparación y seguimiento de las notificaciones, trabajando con los responsables técnicos del cliente.

El resultado debe ser utilizable por quienes gestionan el producto: un mapa de obligaciones por sociedad, responsables identificados, plazos y documentos de trabajo. También podemos ordenar las actuaciones necesarias para diciembre de 2027 y coordinar su seguimiento con los proyectos de IA ya iniciados. Cuando una empresa resulte ajena al ámbito directo del CRA, el análisis servirá para concretar las implicaciones que puedan existir en sus compras tecnológicas o contratos con fabricantes. Así se ajusta el trabajo a una necesidad real y se evita imponer procedimientos que no correspondan a su actividad.

La investigación forense, la corrección y las pruebas técnicas requieren especialistas y una coordinación definida. El alcance y la disponibilidad deben acordarse conforme a las necesidades de cada organización.

José Morato (IP-IT & AI Partner) y Pablo Sáez Hurtado (AI Senior Counsel)