Notificación en la Ley de Ciberresiliencia: el artículo 14 explicado

La primera parte de la Ley de Ciberresiliencia con consecuencias reales ya está en vigor: desde el 11 de septiembre de 2026, los fabricantes de hardware y software vendido en la UE deben notificar las vulnerabilidades explotadas activamente y los incidentes de seguridad graves en sus productos, en un plazo de 24 horas, a través de la Plataforma Única de Notificación de ENISA. Esto se aplica también a los productos que ya están en el mercado.

Actualizado el 1 de octubre de 20269 min de lecturaPor el equipo de Dazr Compliance

¿Cuándo tuviste conocimiento?

Orientativo. Los plazos corren desde que se tiene conocimiento; consulta tu legislación nacional y la calculadora completa para opciones como los prestadores de servicios de confianza o una fecha fija.

  • Desde el 11 de septiembre de 2026, los fabricantes deben notificar las vulnerabilidades explotadas activamente y los incidentes graves que afecten a la seguridad de sus productos (artículo 14 del Reglamento (UE) 2024/2847).
  • Tres pasos: aviso temprano en 24 horas, notificación en 72 horas e informe final 14 días después de que haya una corrección disponible (vulnerabilidades) o un mes después de la notificación (incidentes).
  • Las notificaciones van al CSIRT designado como coordinador en el Estado miembro de tu establecimiento principal en la UE y, simultáneamente, a ENISA, a través de la Plataforma Única de Notificación.
  • Se aplica a todos los productos que ya están en el mercado, no solo a los nuevos. El resto de la CRA llega el 11 de diciembre de 2027.

Quién tiene que notificar: fabricantes y productos incluidos

La Ley de Ciberresiliencia (CRA) cubre los productos con elementos digitales: hardware y software cuyo uso previsto o razonablemente previsible incluye una conexión de datos con un dispositivo o una red. Abarca desde routers, cámaras y dispositivos de hogar inteligente hasta aplicaciones de escritorio y móviles, firmware y bibliotecas de software que se venden o se monetizan de otra forma.

Un fabricante es cualquier persona que «desarrolla o fabrica productos con elementos digitales, o que hace que se diseñen, desarrollen o fabriquen productos con elementos digitales, y los comercializa con su nombre o marca, ya sea a título oneroso, con monetización o gratuitamente» (artículo 3(13)). Un importador o distribuidor que pone su propia marca en un producto, o que lo modifica sustancialmente, también se convierte en fabricante (artículo 21).

Puntos a tener en cuenta para las pymes:

  • El SaaS puro, por lo general, queda fuera del ámbito. La CRA cubre la nube solo como «solución de tratamiento de datos a distancia» necesaria para que un producto funcione, como el backend de la aplicación de un termostato inteligente. Los considerandos señalan que los servicios en la nube diseñados al margen de la responsabilidad de un fabricante de productos no están cubiertos, y remiten a NIS2 para SaaS, PaaS e IaaS.
  • Existen exclusiones sectoriales para productos sujetos a sus propios regímenes, como los productos sanitarios, los vehículos de motor, la aviación civil y los equipos marinos.
  • El tamaño no te exime de notificar. Los fabricantes micro y pequeños solo se libran de las multas por incumplir el plazo de aviso temprano de 24 horas (artículo 64(10)(a)), no de la obligación en sí.

Qué desencadena una notificación

1. Una vulnerabilidad explotada activamente

Una vulnerabilidad «respecto de la cual existen pruebas fiables de que un agente malicioso la ha explotado en un sistema sin el permiso del propietario del sistema» (artículo 3(42)). Una vulnerabilidad comunicada por un investigador, o encontrada en tus propias pruebas, no está «explotada activamente» hasta que haya pruebas de un uso malicioso real. A partir de ese momento, el plazo empieza a contar cuando tienes conocimiento de esas pruebas.

2. Un incidente grave con impacto en la seguridad del producto

Según el artículo 14(5), un incidente es grave cuando:

  • afecta negativamente, o puede afectar negativamente, a la capacidad del producto para proteger la disponibilidad, autenticidad, integridad o confidencialidad de datos o funciones sensibles o importantes; o
  • ha dado lugar, o puede dar lugar, a la introducción o ejecución de código malicioso en el producto o en las redes y sistemas de información de un usuario.

El ejemplo clásico es una intrusión en tu cadena de compilación o en tu servidor de actualizaciones que podría distribuir código malicioso a los clientes. Ten en cuenta que el incidente se refiere a la seguridad de tu producto, lo que puede incluir tu propia infraestructura de desarrollo y distribución.

Plazos y contenido

FaseVulnerabilidad explotada activamente (art. 14(2))Incidente grave (art. 14(4))
Aviso tempranoSin demora indebida, en un plazo de 24 horas desde que se tiene conocimiento. Cuando se conozcan, los Estados miembros en los que está disponible el producto.En un plazo de 24 horas. Si se sospecha que ha sido causado por actos ilícitos o malintencionados y, cuando se conozcan, los Estados miembros afectados.
NotificaciónEn un plazo de 72 horas: información general sobre el producto, la naturaleza de la explotación y de la vulnerabilidad, las medidas correctoras o paliativas adoptadas, las medidas que pueden tomar los usuarios y el grado de sensibilidad que atribuyes a la información.En un plazo de 72 horas: la naturaleza del incidente, una evaluación inicial, las medidas adoptadas y las que pueden tomar los usuarios, y la sensibilidad de la información.
Informe finalA más tardar 14 días después de que esté disponible una medida correctora o paliativa: descripción, gravedad e impacto, información sobre el agente malicioso cuando esté disponible y detalles de la actualización de seguridad.En un plazo de un mes después de la notificación de 72 horas: descripción detallada, gravedad e impacto, tipo probable de amenaza o causa raíz, y medidas paliativas aplicadas y en curso.
Informe intermedioSolo si el CSIRT coordinador solicita actualizaciones de estado (art. 14(6)).

Cada fase posterior se aplica «salvo que ya se haya facilitado la información pertinente», por lo que un aviso temprano completo no tiene que repetirse. Usa nuestra calculadora de plazos de brechas para convertir la marca de tiempo del conocimiento en fechas límite concretas y configura recordatorios en el calendario.

Cómo notificar: la Plataforma Única de Notificación

Las notificaciones se envían a través de la Plataforma Única de Notificación (SRP) de ENISA, que entró en funcionamiento el 11 de septiembre de 2026 en portal.cra-srp.enisa.europa.eu. Se presenta al punto de acceso electrónico del CSIRT designado como coordinador en el Estado miembro de tu establecimiento principal en la UE: donde se toman predominantemente las decisiones de ciberseguridad sobre tus productos o, en su defecto, donde emplees a más personal en la UE (artículo 14(7)). ENISA recibe la notificación al mismo tiempo, y el CSIRT coordinador la comparte con los CSIRT de otros Estados miembros en los que el producto está disponible. En casos excepcionales puede retrasar esa difusión por motivos de ciberseguridad.

Los fabricantes sin establecimiento en la UE notifican al CSIRT del Estado miembro en el que está establecido, por este orden, su representante autorizado, su importador o distribuidor para el mayor número de productos, o donde se encuentre la mayoría de sus usuarios.

Según las preguntas frecuentes de ENISA, las personas que notifican en nombre de un fabricante necesitan una cuenta EU Login con autenticación multifactor, y la plataforma se lanzó en inglés. Registra a tus notificadores antes de necesitarlos: un plazo de 24 horas es un mal momento para crear cuentas.

Informar a tus usuarios

El artículo 14(8) añade una obligación fácil de pasar por alto. Tras tener conocimiento de una vulnerabilidad explotada activamente o de un incidente grave, debes informar a los usuarios afectados y, cuando proceda, a todos los usuarios, junto con las medidas paliativas y correctoras que pueden adoptar, cuando proceda en un formato estructurado y legible por máquina. Si no lo haces a tiempo, el CSIRT puede informar a tus usuarios por su cuenta. Una página de avisos de seguridad y un feed CSAF o similar son la respuesta práctica.

Administradores de software de código abierto y componentes de código abierto

Un administrador de software de código abierto es una persona jurídica, distinta de un fabricante, que presta apoyo sistemático al desarrollo de productos específicos de software libre y de código abierto destinados a actividades comerciales y garantiza su viabilidad. Las fundaciones son el ejemplo típico. Los administradores tienen un régimen más ligero (artículo 24): una política de ciberseguridad documentada, cooperación con las autoridades de vigilancia del mercado y notificación con arreglo al artículo 14 solo en la medida en que participen en el desarrollo, o por incidentes que afecten a la infraestructura que proporcionan para el desarrollo. Las preguntas frecuentes de ENISA indican que la notificación de los administradores se aplica a partir del 11 de diciembre de 2027. A los administradores no se les pueden imponer multas con arreglo a la CRA (artículo 64(10)(b)).

Los proyectos de código abierto de aficionados que no se monetizan no son fabricantes. Pero si tú distribuyes un producto que contiene una biblioteca de código abierto y esa biblioteca se explota activamente en tu producto, la obligación de notificar es tuya como fabricante del producto. A partir del 11 de diciembre de 2027 también deberás notificar las vulnerabilidades que encuentres en componentes integrados, incluidos los de código abierto, a quien los mantenga (artículo 13(6)).

El resto del calendario de la CRA

  1. 10 de diciembre de 2024Entrada en vigor de la CRA (publicada en el Diario Oficial el 20 de noviembre de 2024).
  2. 11 de junio de 2026Se aplica el capítulo IV: normas para los organismos de evaluación de la conformidad (organismos notificados).
  3. 11 de septiembre de 2026Se aplica la notificación del artículo 14 a todos los productos incluidos en el ámbito, también a los comercializados antes del 11 de diciembre de 2027 (artículo 69(3)).
  4. 1 de octubre de 2026: estás aquí
  5. 11 de diciembre de 2027Aplicación plena: requisitos esenciales de ciberseguridad (Anexo I), gestión de vulnerabilidades, marcado CE, evaluación de la conformidad, periodos de soporte, documentación técnica y obligaciones de importadores, distribuidores y administradores de código abierto. Los productos comercializados antes de esta fecha solo quedan sujetos a estos requisitos tras una modificación sustancial.
  6. 11 de junio de 2028Caducan los certificados de examen UE de tipo vigentes para requisitos de ciberseguridad con arreglo a otra legislación, salvo que caduquen antes.

Las multas por incumplir el Anexo I o los artículos 13 y 14 alcanzan los 15 millones de EUR o el 2,5 % del volumen de negocios anual mundial, si esta cifra es mayor (artículo 64(2)).

Notificación CRA y NIS2, lado a lado

Los dos regímenes se parecen (24 horas, 72 horas, un informe final), pero responden a preguntas distintas. NIS2 pregunta si tu servicio a los clientes se ha visto significativamente afectado. La CRA pregunta si tu producto está siendo explotado o si su seguridad se ha visto comprometida.

CRA, artículo 14NIS2, artículo 23
QuiénFabricantes de productos con elementos digitales (de cualquier tamaño)Entidades esenciales e importantes de los sectores de los Anexos I y II
DisparadorVulnerabilidad explotada activamente; incidente grave que afecta a la seguridad del productoIncidente significativo que afecta a la prestación de los servicios de la entidad
DestinatarioCSIRT coordinador y ENISA a través de la Plataforma Única de NotificaciónCSIRT nacional o autoridad competente, por los canales nacionales
Cronología24 h / 72 h / final a los 14 días de la corrección (vulnerabilidad) o 1 mes (incidente)Aviso temprano en 24 h / notificación en 72 h / informe final en 1 mes
Desde11 de septiembre de 2026Depende de la transposición nacional (el plazo fue el 17 de octubre de 2024)

Una empresa puede estar en ambos. Un fabricante mediano de equipos de red puede entrar en NIS2 (la fabricación de productos informáticos, electrónicos y ópticos es un sector del Anexo II) y en la CRA. Un compromiso de su servidor de actualizaciones podría ser entonces tanto un incidente significativo según NIS2 como un incidente grave según la CRA, con dos notificaciones por dos canales. Planifica ambos en un único protocolo. Los considerandos de la CRA animan a los Estados miembros a ofrecer puntos únicos de entrada nacionales y, en noviembre de 2025, la Comisión propuso un punto único de entrada a escala de la UE para la notificación de incidentes dentro de su paquete Digital Omnibus. Hasta que exista ese punto en tu país, asume que notificas por separado. Si se ven afectados datos personales, la notificación de brechas del RGPD en 72 horas corre en paralelo a ambas. Si eres una entidad NIS2, nuestro verificador de incidentes significativos de NIS2 te ayuda con la prueba de «significativo».

Lista de comprobación de preparación

  • Haz una lista de tus productos con elementos digitales y de los Estados miembros en los que están disponibles.
  • Determina tu establecimiento principal y, por tanto, tu CSIRT coordinador.
  • Registra al menos dos notificadores en la Plataforma Única de Notificación con EU Login y MFA.
  • Define «explotada activamente» e «incidente grave» en tus procedimientos de vulnerabilidades e incidentes, con ejemplos.
  • Configura la recepción: un contacto de seguridad (por ejemplo, security.txt), una política de divulgación coordinada de vulnerabilidades y la monitorización de inteligencia de amenazas, como el catálogo CISA KEV y los avisos de los CSIRT.
  • Mantén un SBOM para saber en cuestión de horas si un componente explotado está en tus productos.
  • Prepara plantillas para las notificaciones de 24 h, 72 h y final, además de un aviso para usuarios.
  • Registra las marcas de tiempo del conocimiento: el plazo corre desde que tienes conocimiento.
  • Ensaya una vez con un ejercicio de simulación, combinando los plazos de la CRA, NIS2 y el RGPD cuando proceda.

Gestiona los plazos desde un único registro de incidentes

El registro de incidentes de Dazr Compliance anota la hora del conocimiento una sola vez y muestra cada plazo: RGPD 72 horas, NIS2 24 h, 72 h y un mes, y plazos personalizados como el informe final de la CRA. Conserva las evidencias y las referencias de los expedientes de las autoridades en una pista de auditoría exportable.

Preguntas frecuentes

¿Se aplica la notificación CRA a los productos vendidos antes del 11 de diciembre de 2027?

Sí. El artículo 69(3) hace que las obligaciones de notificación del artículo 14 se apliquen a todos los productos incluidos en el ámbito, también a los comercializados antes del 11 de diciembre de 2027. Los requisitos de diseño solo se aplican a esos productos anteriores tras una modificación sustancial.

¿Cuándo empieza a contar el plazo de 24 horas?

Cuando el fabricante tiene conocimiento de la vulnerabilidad explotada activamente o del incidente grave. En el caso de las vulnerabilidades, es cuando dispones de pruebas fiables de explotación maliciosa, no cuando se notificó el fallo por primera vez.

¿Está cubierta nuestra plataforma SaaS por la notificación CRA?

Por lo general no, salvo que sea una solución de tratamiento de datos a distancia sin la cual un producto con elementos digitales no pueda realizar una de sus funciones. El SaaS como tal entra en NIS2 si cumples sus criterios de tamaño y sector.

¿Están exentas las empresas pequeñas?

No. Los fabricantes micro y pequeños también deben notificar. No pueden ser sancionados por incumplir el plazo de 24 horas del aviso temprano, pero el resto de las obligaciones y sanciones siguen aplicándose.

Fuentes (a 1 de octubre de 2026)

Esta guía explica la CRA a fecha de 1 de octubre de 2026 y no constituye asesoramiento jurídico.