La notificación del Cyber Resilience Act ya es obligatoria: qué ha cambiado y qué hacer este trimestre
Por Kike Gandia · Hardware y OT · 9 min de lectura

El 11 de septiembre de 2026 el artículo 14 del Reglamento (UE) 2024/2847, el Cyber Resilience Act, pasó a aplicarse. Ese mismo día ENISA puso en marcha la capacidad operativa inicial de su plataforma única de notificación (SRP, por sus siglas en inglés). Desde entonces, un fabricante de productos con elementos digitales que tiene conocimiento de que una vulnerabilidad de su producto se está explotando activamente, o de un incidente grave que afecta a su seguridad, tiene que notificarlo en plazos de horas.
La pregunta ya no es si hay que notificar, sino cómo funciona la notificación en la práctica. Las preguntas frecuentes que ENISA publicó con la plataforma responden a varias dudas que antes del lanzamiento se resolvían por intuición, y en algún caso la respuesta oficial va en contra de lo que se venía recomendando.
Lo que obliga desde el 11 de septiembre. Notificar las vulnerabilidades activamente explotadas y los incidentes graves que afecten a la seguridad del producto, a la vez al CSIRT designado como coordinador y a ENISA, a través de la plataforma única de notificación. Alcanza también a los productos que ya estaban en el mercado.
- 24 h
- alerta temprana (desde que se tiene conocimiento)
- 72 h
- notificación (desde que se tiene conocimiento)
- 14 días
- informe final de vulnerabilidad (desde que hay medida correctora)
- 1 mes
- informe final de incidente grave (desde la notificación de 72 h)
Qué ha pasado y qué queda por delante
- 11 de diciembre de 2025 — Acto delegado sobre la difusión
La Comisión adopta el Reglamento Delegado (UE) 2026/881, que fija en qué condiciones excepcionales un CSIRT puede retrasar, por motivos de ciberseguridad, la difusión de una notificación a otros CSIRT. - 10 de septiembre de 2026 — Lista de CSIRT coordinadores
ENISA publica la lista de CSIRT designados como coordinadores. Para España, la entrada remite a las páginas de INCIBE-CERT de respuesta a incidentes y de asignación y publicación de CVE. - 11 de septiembre de 2026 — El artículo 14 se aplica y la plataforma abre
Empieza la obligación de notificar y la SRP entra en funcionamiento. En esta primera fase solo admite las notificaciones obligatorias del artículo 14. - 11 de diciembre de 2027 — Aplicación plena
Todos los requisitos del reglamento pasan a ser exigibles, y se aplican las obligaciones de notificación de los administradores de software de código abierto del artículo 24.3.
Qué hay que notificar y qué no
El artículo 14 no pide notificar cualquier vulnerabilidad: solo las que se están explotando activamente, y los incidentes graves. Un incidente es grave cuando afecta o puede afectar a la capacidad del producto de proteger la disponibilidad, la autenticidad, la integridad o la confidencialidad de datos o funciones sensibles o importantes, o cuando ha llevado o puede llevar a introducir o ejecutar código malicioso en el producto o en los sistemas del usuario (artículo 14.5).
| Situación | ¿Hay que notificar? | Matiz |
|---|---|---|
| Vulnerabilidad de tu producto explotada activamente | Sí: 24 h, 72 h y 14 días | El informe final cuenta desde que existe una medida correctora o mitigadora, no desde el conocimiento |
| Incidente grave que afecta a la seguridad del producto | Sí: 24 h, 72 h y un mes | El informe final cuenta desde la notificación de las 72 horas |
| Vulnerabilidad sin indicios de explotación | No por el artículo 14 | Hay que corregirla igualmente; la notificación voluntaria del artículo 15 aún no está disponible en la plataforma |
| Explotación que ya conocías antes del 11 de septiembre de 2026 | No retroactivamente | Si tienes conocimiento de la explotación después de esa fecha, sí, aunque la vulnerabilidad fuera conocida de antes |
| Producto introducido en el mercado antes de diciembre de 2027 | Sí | La obligación de notificar cubre todo el catálogo dentro del ámbito del reglamento, sin excepción por antigüedad |
Cada entrega tiene un contenido mínimo distinto. Para una vulnerabilidad, la alerta temprana indica en qué Estados miembros sabes que se ha comercializado el producto; la notificación añade información general del producto, la naturaleza del exploit y de la vulnerabilidad y las medidas correctoras tomadas y las que pueden tomar los usuarios; y el informe final describe la vulnerabilidad con su gravedad e impacto, la información disponible sobre el actor malicioso y el detalle de la actualización de seguridad. Para un incidente grave, la secuencia es paralela: si se sospecha de un acto ilícito o malintencionado, una evaluación inicial y, al final, la causa raíz y las medidas de mitigación aplicadas y en curso.
Una obligación aparte: informar a los usuarios. El artículo 14.8 obliga además a informar a los usuarios afectados, y cuando proceda a todos, de la vulnerabilidad o del incidente y de las medidas que pueden tomar. Notificar al CSIRT no cubre esta obligación.
La letra pequeña de la plataforma
Estas son las respuestas de las preguntas frecuentes de ENISA que más afectan a cómo se organiza un equipo para notificar:
- Una vez Una sola notificación por suceso
- Aunque el fabricante tenga varias filiales en la UE o una matriz fuera de ella, cada vulnerabilidad explotada o incidente grave se notifica una vez. La coordinación interna para que no se dupliquen es responsabilidad del fabricante.
- CSIRT Elegir mal el CSIRT invalida la notificación
- El destinatario es el CSIRT coordinador del Estado del establecimiento principal, donde se toman de forma predominante las decisiones de ciberseguridad sobre los productos. Si no se puede determinar, cuenta el Estado con más empleados en la UE. Si eliges el CSIRT equivocado, la notificación puede invalidarse y habrá que reenviarla.
- 72 h El contador de la plataforma se adelanta
- En la versión actual, el contador de 72 horas marca el vencimiento 48 horas después de enviar la alerta temprana, porque cuenta desde ese envío y no desde el conocimiento. Una notificación puede aparecer como vencida antes de tiempo: el reloj que vale es el tuyo.
- Manual Solo navegador y solo en inglés
- La plataforma no tiene API en esta fase y está disponible únicamente en inglés. La notificación voluntaria del artículo 15 y una posible API llegarán en fases posteriores.
- Alta El alta, cuando haya que notificar
- ENISA recomienda registrarse e iniciar la validación solo cuando haya que enviar una notificación. Con una cuenta EU Login con doble factor ya creada, el registro lleva unos minutos, y la validación del CSIRT corre en paralelo: mientras tanto se pueden enviar hasta veinte notificaciones de ese fabricante.
- Fuera UE Sin establecimiento en la UE
- El CSIRT se determina en este orden: el del Estado del representante autorizado, el del importador, el del distribuidor y, en último término, el del Estado con más usuarios del producto.
Un consejo que conviene revisar. Antes del lanzamiento se repetía que había que darse de alta en la plataforma por adelantado. La recomendación oficial es la contraria: el alta se completa en minutos cuando hace falta. Lo que no se improvisa el día del incidente es todo lo demás: las cuentas EU Login con doble factor de quienes van a notificar, el CSIRT coordinador identificado y los datos del producto a mano.
España: a quién llega tu notificación
Para un fabricante con establecimiento principal en España, el CSIRT coordinador es INCIBE-CERT: la entrada de España en la lista de ENISA remite a sus páginas de respuesta a incidentes y de coordinación de vulnerabilidades. La notificación no se envía por los canales nacionales habituales, sino por la plataforma de ENISA, que la hace llegar a la vez al CSIRT y a la agencia.
La otra mitad del cuadro, la autoridad de vigilancia del mercado, sigue pendiente. En diciembre de 2025 la Secretaría de Estado de Telecomunicaciones e Infraestructuras Digitales abrió una consulta pública sobre la norma que designará a las autoridades del CRA, y en ella planteaba asumir la vigilancia del mercado, atribuir al Centro Criptológico Nacional el papel de autoridad notificante y apoyarse en INCIBE como laboratorio técnico, sin potestades públicas. A fecha de este artículo no hemos localizado esa norma publicada en el BOE. Eso no suspende nada: el reglamento es directamente aplicable y la obligación de notificar ya es exigible. El detalle está en la guía del CRA para fabricantes.
Qué hacer este trimestre
- 1 — Identificar destinatario y responsables
Determina tu CSIRT coordinador según el establecimiento principal y decide quién notifica. Esas personas necesitan una cuenta EU Login con doble factor antes de que ocurra nada. - 2 — Definir qué es «tener conocimiento»
Es el hecho que arranca el reloj y el que tendrás que acreditar. Deja por escrito quién decide que una vulnerabilidad está explotada activamente y con qué criterios: reportes recibidos, avisos de CSIRT, catálogos públicos de vulnerabilidades explotadas o tu propia telemetría. - 3 — Montar dos temporizadores
El informe final de una vulnerabilidad cuenta desde que existe la medida correctora; el de un incidente grave, desde la notificación de las 72 horas. Llévalos fuera de la plataforma, que hoy calcula el vencimiento de las 72 horas desde la alerta temprana. - 4 — Tener abierto el canal de entrada
Sin un canal para recibir reportes de vulnerabilidades (security.txt, un formulario de seguridad o un programa de divulgación), te enterarás tarde o por terceros. - 5 — Preparar la comunicación a usuarios
Una plantilla para la información del artículo 14.8, con quién la aprueba y por qué canal sale, para no redactarla con el reloj corriendo. - 6 — Inventariar lo que ya está en el mercado
La obligación alcanza a productos antiguos y descatalogados. Necesitas saber qué referencias siguen en manos de clientes y quién puede preparar una corrección para cada una. - 7 — Ensayarlo
Un simulacro de mesa con una vulnerabilidad explotada ficticia muestra en una mañana dónde se pierden las primeras veinticuatro horas.
Lo que viene
El siguiente hito es el 11 de diciembre de 2027, con la aplicación plena del reglamento. En paralelo, la propuesta Digital Omnibus que la Comisión presentó el 19 de noviembre de 2025 incluye un punto único de notificación de incidentes de ciberseguridad y de datos. Sigue siendo una propuesta: según el seguimiento del Parlamento Europeo actualizado a 20 de septiembre de 2026, la votación del mandato negociador del Consejo prevista para el 26 de junio se canceló y el proyecto de informe del Parlamento acumula más de 1.750 enmiendas. No conviene diseñar el proceso de notificación contando con ella.
Si quieres situar tu producto antes de ponerte con el proceso, el clasificador interactivo del CRA te dice en qué categoría cae y la ficha de alcance CRA dimensiona el trabajo. El calendario completo del CRA está en plazos del Cyber Resilience Act, el del resto de la normativa europea en el calendario de compliance UE, y si quieres que lo montemos contigo, en nuestra consultoría de adecuación al CRA.
Servicio relacionado
consultoría de adecuación al Cyber Resilience Act
Temas de este artículo
#Cyber-Resilience-Act #CRA #ENISA #Notificación-de-vulnerabilidades #INCIBE-CERT #Cumplimiento
Seguir leyendo
- ¿En qué cajón cae tu producto? Un clasificador interactivo del Cyber Resilience Act
- Calendario de compliance europeo 2026-2030: CRA, AI Act, Data Act y todo lo que viene
- KOMPLIANCE: la auditoría que se ve mientras ocurre y la plataforma que se queda después
- Cómo se ataca una planta industrial: el salto de IT al metal, explicado con una máquina
- Serie Análisis de Hardware – Parte 7 Depuración Avanzada de Microcontroladores ARM con JTAG y Bus Pirate
Fuentes
- Reglamento (UE) 2024/2847 — Cyber Resilience Act (EUR-Lex)
- ENISA — preguntas frecuentes de la plataforma única de notificación del CRA (SRP)
- ENISA — lanzamiento de la plataforma única de notificación del CRA
- ENISA — lista de CSIRT designados como coordinadores
- Comisión Europea — obligaciones de notificación del CRA
- Reglamento Delegado (UE) 2026/881 — condiciones para retrasar la difusión de notificaciones
- Ministerio para la Transformación Digital — consulta pública sobre la designación de autoridades del CRA (diciembre de 2025)
- Parlamento Europeo — Legislative Train: propuesta Digital Omnibus (2025/0360(COD))