A partir del 11 de septiembre de 2026, los fabricantes sujetos al CRA deben notificar las vulnerabilidades explotadas activamente y los incidentes graves a través de la ENISA Single Reporting Platform. Esta guía explica qué activa una notificación, cómo funcionan los plazos de 24 horas, 72 horas, 14 días y 1 mes, y dónde encajan CVD, VEX y la información a los usuarios.
Resumen
- La notificación urgente empieza el 11 de septiembre de 2026: ambos flujos usan alerta temprana de 24h y notificación de 72h; el informe final vence 14 días después de que exista una medida correctora o mitigadora para vulnerabilidades, y en 1 mes desde la notificación de 72h para incidentes graves.
- Envía una sola vez por la ENISA SRP: la plataforma dirige el informe al CSIRT coordinador y lo hace accesible para ENISA.
- La explotación activa exige pruebas fiables de que un actor malicioso explotó la vulnerabilidad en un sistema sin permiso; la divulgación, un PoC público o una demostración de investigador no bastan por sí solos.
- La política CVD es obligatoria: escrita, publicada, aplicada y conectada con la puerta de notificación cuando el triaje detecta explotación activa.
- VEX apoya las decisiones de notificabilidad al documentar si una CVE en un componente SBOM afecta realmente al producto.
- Los detalles de sanciones van en la guía de ejecución: las notificaciones tardías o ausentes pueden crear exposición sancionadora seria; consulta sanciones y ejecución del CRA para los niveles y excepciones PYME.
El modelo de notificación en la práctica: alerta temprana, notificación detallada, informe final y remisión a la guía de ejecución.
Qué debe notificarse
La notificación CRA tiene dos flujos obligatorios de eventos y una obligación de informar a usuarios. La obligación recae en el fabricante del producto con elementos digitales comercializado en el mercado de la UE:
- Notificar toda vulnerabilidad explotada activamente del producto simultáneamente al CSIRT coordinador y a ENISA, con cadencia 24h / 72h / 14d.
- Notificar todo incidente grave que afecte a la seguridad del producto, con cadencia 24h / 72h / 1 mes.
- Informar a los usuarios afectados sobre la vulnerabilidad o incidente y sobre las medidas correctoras, sin demora indebida.
Esta página también cubre dos controles adyacentes que alimentan la decisión de notificar: la política CVD obligatoria y evidencias de aplicabilidad como VEX. Ninguna de estas obligaciones tiene umbral de tamaño. Las microempresas y pequeñas empresas reciben solo una exención sancionadora estrecha para la alerta temprana de 24h; no están exentas de notificar.
La ENISA Single Reporting Platform (SRP)
La SRP es el canal único para las notificaciones CRA obligatorias de vulnerabilidades e incidentes. Existe porque el fabricante debe notificar al CSIRT coordinador y a ENISA a través de una plataforma de notificación, en lugar de presentar expedientes separados en cada Estado miembro donde el producto esté disponible. ENISA establece y gestiona la plataforma.
Cómo funciona en la práctica:
- Presentas una sola vez, usando el punto final electrónico del CSIRT designado como coordinador.
- La presentación va dirigida al CSIRT coordinador y es accesible simultáneamente para ENISA, salvo que se aplique el mecanismo excepcional de retraso de difusión.
- El CSIRT coordinador difunde después la notificación a los CSIRT de otros Estados miembros donde el producto se haya comercializado. Esa difusión secundaria es responsabilidad del CSIRT, no del fabricante.
- La regla de retraso permite al CSIRT aplazar la difusión por motivos justificados de ciberseguridad en circunstancias excepcionales. La divulgación coordinada también puede permitir retraso con consentimiento del fabricante.
Estado a junio de 2026: la SRP sigue prevista para estar operativa el 11 de septiembre de 2026, con un periodo de pruebas previo. ENISA ha indicado que el manual de acceso e instrucciones de registro, junto con material de formación y simulacros, se publicarán durante junio de 2026, por lo que los detalles del proceso de alta siguen pendientes de publicación. ENISA también ha confirmado que en esta fase no se proporcionará una API de la SRP, así que planifica la preparación para la notificación en torno a la presentación directa a través de la plataforma. Para los detalles del proceso de registro, consulta alta en la SRP de ENISA. Consulta la página de la Comisión sobre notificación CRA y la página ENISA SRP antes de confiar en un paso concreto de registro.
Qué deben preparar ahora los fabricantes: identificar el CSIRT coordinador, preaprobar plantillas para los envíos de 24h, 72h e informe final en ambos flujos, y definir una rotación de guardia fuera de horario. Las plantillas y procesos no se pueden diseñar mientras corre el reloj de 24 horas.
Plazos de notificación en detalle
Tanto las vulnerabilidades como los incidentes graves siguen un modelo escalonado. Los relojes difieren en el tramo del informe final.
Calendario de notificación
| Fase | Vulnerabilidad | Incidente grave | Ancla del plazo |
|---|---|---|---|
| Alerta temprana | 24 horas | 24 horas | El fabricante toma conocimiento |
| Notificación detallada | 72 horas | 72 horas | El fabricante toma conocimiento |
| Informe final | 14 días desde que hay medida correctora o mitigadora disponible | 1 mes desde la notificación de incidente de 72h | Ancla distinta por flujo |
| Información a usuarios | Sin demora indebida | Sin demora indebida | Información a usuarios |
Qué contiene cada envío
Alerta temprana (24 horas). La alerta temprana es un aviso, no un análisis completo. Para vulnerabilidades debe enviarse sin demora indebida y dentro de las 24 horas desde el conocimiento, e indicar, cuando proceda, los Estados miembros donde el fabricante sabe que el producto se ha comercializado. Para incidentes graves debe indicar al menos si se sospecha que el incidente fue causado por actos ilícitos o maliciosos. Las plantillas internas pueden añadir versión, severidad, alcance de impacto y responsable, pero son campos operativos, no todos mínimos legales.
Notificación detallada (72 horas). En esta etapa conviven dos obligaciones. La notificación de vulnerabilidad de 72h se aplica a vulnerabilidades explotadas activamente y aporta información general sobre el producto, explotación, vulnerabilidad, medidas tomadas, medidas para usuarios y sensibilidad cuando proceda. La notificación de incidente de 72h se aplica a incidentes graves y aporta información general sobre el incidente, evaluación inicial, medidas tomadas, medidas para usuarios y sensibilidad cuando proceda.
Informe final. Para vulnerabilidades, el reloj de 14 días empieza cuando hay una medida correctora o mitigadora disponible, no en el descubrimiento ni en la notificación de 72h. El informe final debe incluir al menos descripción, severidad e impacto de la vulnerabilidad, información disponible sobre actores maliciosos y detalles de la actualización de seguridad u otras medidas correctoras. Para incidentes graves, el reloj de 1 mes se ancla a la notificación de 72h y el informe final debe incluir al menos descripción detallada del incidente, severidad e impacto, tipo de amenaza o causa probable, y medidas de mitigación aplicadas o en curso.
- Conocimiento del fabricante. El reloj de 24 horas empieza cuando el fabricante conoce pruebas fiables de explotación activa.
- +24h alerta temprana. Presenta la alerta inicial a través de la ENISA Single Reporting Platform.
- +72h notificación detallada. Añade detalles técnicos, versiones afectadas, estado de explotación y mitigación.
- Medida disponible. Para vulnerabilidades, el reloj del informe final empieza aquí, no en el descubrimiento.
- +14d informe final. Presenta los detalles finales requeridos para el flujo de vulnerabilidad o incidente grave.
Los incidentes graves comparten los pasos iniciales de 24h y 72h; el informe final vence 1 mes después de la notificación de 72h.
Campos de datos en la plantilla de notificación SRP
Las FAQ de la SRP de ENISA (P16) enumeran los campos esperados en cada fase de notificación. ENISA los presenta como campos que serán obligatorios (directamente del CRA o por consecuencia lógica) u opcionales, por lo que deben tratarse como provisionales hasta que la plataforma sea definitiva. Códigos: X obligatorio, O opcional, C copiado del paso anterior por defecto o actualizado, A automatizado (no se muestra al notificador), I obligatorio si la información está disponible.
| # | Campo | 24h | 72h | Final |
|---|---|---|---|---|
| Campos comunes | ||||
| 1 | Tipo de notificación (vulnerabilidad / incidente) | X | C | C |
| 2 | Nivel de notificación (24h / 72h / final) | X | X | X |
| 3 | Hora de notificación, 24h | A | A | A |
| 4 | Hora de notificación, 72h | A | A | A |
| 5 | Hora de notificación, final | A | A | A |
| 6 | Notificador | A | A | A |
| 7 | Fabricante | X | C | C |
| 8 | Producto | X | C | C |
| 9 | Tipo de producto (por defecto / importante / crítico) | O | C | C |
| 10 | Categoría del producto (si el tipo es importante o crítico) | O | C | C |
| 11 | Estados miembros donde el producto está disponible | I | C | C |
| 12 | Título | X | C | C |
| Vulnerabilidad | ||||
| v13 | ID CVE | O | C | C |
| v14 | ID EUVD | O | C | C |
| v15 | Información general, en particular: | O | X | C |
| v16 | a. Naturaleza general de la vulnerabilidad | O | X | C |
| v17 | b. Naturaleza general del exploit | O | X | C |
| v18 | Medidas correctoras o mitigadoras adoptadas | O | X | C |
| v19 | Medidas correctoras o mitigadoras que pueden tomar los usuarios | O | X | C |
| v20 | Sensibilidad de la información considerada | O | I | C |
| v21 | Fecha en que una medida correctora o mitigadora quedó disponible | O | O | X |
| v22 | Descripción completa de la vulnerabilidad, incluidos: | O | O | X |
| v23 | a. Severidad de la vulnerabilidad | O | O | X |
| v24 | b. Impacto de la vulnerabilidad | O | O | X |
| v25 | Actor malicioso que ha explotado o está explotando la vulnerabilidad | O | O | I |
| v26 | Detalles sobre la actualización de seguridad u otras medidas correctoras | O | O | X |
| Incidente | ||||
| i13 | Incidente del que se sospecha causado por actos ilícitos o maliciosos | X | C | C |
| i14 | Información general sobre la naturaleza del incidente | O | X | C |
| i15 | Fecha y hora en que se detectó el incidente | O | X | C |
| i16 | Fecha y hora en que ocurrió el incidente | O | X | C |
| i17 | Evaluación inicial del incidente | O | X | C |
| i18 | Medidas correctoras o mitigadoras adoptadas | O | X | C |
| i19 | Medidas correctoras o mitigadoras que pueden tomar los usuarios | O | X | C |
| i20 | Sensibilidad de la información considerada | O | I | C |
| Descripción detallada del incidente, incluidos: | O | O | X | |
| i21 | a. Severidad del incidente (criterios más abajo) | O | O | X |
| i23 | b. Impacto del incidente | O | O | X |
| i24 | Tipo de amenaza o causa raíz probable | O | O | X |
| i25 | Medidas de mitigación aplicadas y en curso | O | O | X |
Criterios de severidad (i22): un incidente es grave si (1) afecta negativamente, o puede afectar negativamente, a la capacidad del producto de proteger la disponibilidad, autenticidad, integridad o confidencialidad de datos o funciones sensibles o importantes; o (2) ha llevado, o puede llevar, a la introducción o ejecución de código malicioso en el producto o en los sistemas de red e información de un usuario.
Fuente: FAQ SRP de ENISA, P16.
Qué activa una obligación de notificación
La notificación CRA tiene dos categorías de activación: vulnerabilidades explotadas activamente e incidentes graves que afectan a la seguridad del producto.
1. Vulnerabilidades explotadas activamente
Una vulnerabilidad explotada activamente es una vulnerabilidad del producto para la que existen pruebas fiables de que un actor malicioso la explotó en un sistema sin permiso. El fabricante también debe haber tomado conocimiento de esa explotación antes de que empiece el reloj de notificación.
Esto no equivale a divulgación pública, PoC publicado ni demostración de explotabilidad en laboratorio. Esas señales pertenecen a la gestión de vulnerabilidades y triaje CVD salvo que creen pruebas fiables de explotación maliciosa contra un sistema real.
2. Incidentes graves
Un incidente grave es un incidente que afecta a la seguridad del producto y cumple cualquiera de los criterios siguientes:
- afecta negativamente, o puede afectar negativamente, a la capacidad del producto de proteger la disponibilidad, autenticidad, integridad o confidencialidad de datos o funciones sensibles o importantes; o
- ha llevado, o puede llevar, a la introducción o ejecución de código malicioso en el producto o en los sistemas de red e información de un usuario.
Escenarios notificables y no notificables
| Escenario | ¿Notificable? | Por qué |
|---|---|---|
| Investigador informa una vulnerabilidad en privado | No | Sin pruebas de explotación; tratar por CVD |
| PoC publicado en GitHub | No | La publicación no es explotación |
| Cliente informa actividad compatible con explotación | Evaluar | Notifica si la evidencia es suficientemente fiable para mostrar explotación activa |
| Vulnerabilidad detectada explotándose en el mundo real | Sí | Prueba fiable de uso malicioso |
| Componente de la SBOM con CVE conocida explotada | Evaluar | Solo notificable si la explotación afecta a tu producto (VEX importa aquí) |
| Tu producto es objetivo de actores de amenaza nombrados | Sí | Prueba directa de explotación |
| Malware genérico usa una clase de vulnerabilidad que tiene tu producto | Evaluar | Solo si tu implementación concreta está afectada |
Conocimiento y evidencia
La definición del CRA usa pruebas fiables, no certeza forense. Evidencias útiles pueden incluir telemetría de explotación, informes de compromiso de clientes, inteligencia de amenazas que nombre tu producto o registros que muestren comportamiento de explotación contra el producto. Si la evidencia aún no es fiable, mantén el evento en triaje CVD o de incidente; si se vuelve fiable, el reloj de 24 horas empieza cuando el fabricante toma conocimiento.
Entrada CVD y puerta de notificación
La política CVD es el proceso de entrada que convierte informes externos en triaje estructurado. Cuando ese triaje produce pruebas fiables de explotación activa, el reloj de notificación urgente corre en paralelo con la remediación y la divulgación coordinada. La política es obligatoria para todo producto con elementos digitales, sin umbral de tamaño. Una página CVD pública más un archivo security.txt en /.well-known/security.txt es la forma práctica de hacer descubrible el canal de reporte.
Para la política CVD, incluidos contenidos, ventanas de divulgación, lenguaje de safe harbour y plantillas de comunicación con investigadores, consulta la guía de divulgación coordinada de vulnerabilidades CRA. Para ver cómo CVD encaja en el ciclo de gestión de vulnerabilidades, consulta gestión de vulnerabilidades CRA.
VEX y aplicabilidad de vulnerabilidades
VEX (Vulnerability Exploitability eXchange) es una declaración estructurada y legible por máquina sobre si una vulnerabilidad en un componente SBOM afecta realmente a un producto concreto. Convierte coincidencias CVE en un estado defendible específico del producto:
| Estado | Significado |
|---|---|
not_affected |
La vulnerabilidad existe en el componente pero no afecta a este producto. Se espera una justificación. |
affected |
La vulnerabilidad afecta a este producto. Se espera acción y recomendación. |
fixed |
La vulnerabilidad estaba presente y fue remediada en esta versión. |
under_investigation |
Estado aún no determinado; evaluación en curso. |
Para notificación, la pregunta clave es aplicabilidad más explotación activa. Una vulnerabilidad marcada como affected y respaldada por pruebas fiables de explotación activa puede iniciar el reloj de alerta temprana de 24h. Una vulnerabilidad marcada como not_affected con justificación sólida respalda una decisión de no notificar. El CRA no nombra VEX, pero VEX es una forma práctica de conservar esa justificación. Para formatos y detalles, consulta la guía de implementación VEX.
Alivio para fabricantes pequeños
Las microempresas y pequeñas empresas (definidas como menos de 50 empleados y un volumen de negocios anual o un balance general de hasta 10 millones de euros; microempresas: menos de 10 empleados, 2 millones de euros) quedan exentas de multas solo por incumplir la primera alerta temprana de 24h. El alivio cubre únicamente esa primera etapa.
Sigue siendo obligatorio, sin alivio pyme:
- La notificación detallada de 72h.
- El informe final de 14 días para vulnerabilidades y el informe final de 1 mes para incidentes graves.
- La política CVD.
- Las demás obligaciones de seguridad del producto, incluido el requisito de no tener vulnerabilidades explotables conocidas.
Las medianas empresas no están cubiertas. Es una excepción sancionadora estrecha, no un régimen de notificación reducido. La estructura completa está en sanciones y ejecución del CRA.
Errores habituales
- Esperar certeza forense antes de iniciar el reloj. Las pruebas fiables bastan; el CRA no exige una investigación forense completada antes de la alerta temprana.
- Confundir CVD con notificación urgente. Un informe de investigador es entrada CVD; la notificación urgente empieza con pruebas fiables de explotación activa.
- Punto único de fallo en la escalada. Una sola persona autorizada para notificar no puede ser el cuello de botella de un viernes por la noche.
- Primer contacto con el CSIRT coordinador durante un incidente. Establece relación y ruta ahora, sin reloj corriendo.
- No publicar política CVD. Se requiere una política pública; un documento interno no basta.
- No tomar decisiones de aplicabilidad. Sin VEX o registro equivalente, es difícil defender por qué una CVE conocida en tu SBOM no es explotable en tu producto.
- Tratar el lanzamiento de la SRP como problema futuro. Plantillas, guardias y relaciones CSIRT deben existir antes de septiembre de 2026.
Preguntas frecuentes
¿Cuándo empiezan las obligaciones de notificación CRA?
La notificación obligatoria de vulnerabilidades e incidentes CRA empieza el 11 de septiembre de 2026. Desde esa fecha, los fabricantes deben usar la ENISA Single Reporting Platform para alerta temprana de 24h, notificación de 72h e informes finales. Las obligaciones más amplias de seguridad de producto, incluido el requisito de "sin vulnerabilidades explotables conocidas", se aplican desde el 11 de diciembre de 2027.
¿Qué es la ENISA Single Reporting Platform (SRP)?
La SRP es el canal único para notificaciones CRA obligatorias y notificaciones voluntarias. El fabricante presenta una vez por el endpoint del CSIRT coordinador; la notificación es accesible simultáneamente para ENISA salvo que aplique el mecanismo excepcional de retraso de difusión. La guía actual de la Comisión y ENISA dice que la plataforma estará operativa el 11 de septiembre de 2026, con un periodo de pruebas antes; ENISA ha indicado que la funcionalidad de notificación voluntaria se habilitará después del 11 de septiembre de 2026. Sigue la página de notificación CRA de la Comisión y la página ENISA SRP para detalles de registro.
¿Es obligatoria una política CVD?
Sí. Todo fabricante CRA necesita una política CVD y un canal práctico para recibir informes de vulnerabilidades. El reglamento no prescribe una plantilla completa, pero una política defendible suele cubrir alcance, métodos de contacto, tratamiento de respuestas, timing de divulgación, comunicación con investigadores y la puerta de escalada por explotación activa. security.txt no se nombra en el CRA, pero es una forma práctica de publicar la dirección de contacto exigida por las obligaciones de gestión de vulnerabilidades.
¿Qué es VEX y lo necesito para cumplir el CRA?
VEX no es obligatorio por nombre, pero un registro de aplicabilidad es muy útil. Documenta si una CVE en un componente SBOM está not_affected, affected, fixed o under_investigation para una versión concreta del producto. Esa evidencia apoya la prioridad de remediación y la decisión de que una CVE conocida no es notificable porque no afecta al producto. Para formatos y detalles, consulta la guía de implementación VEX.
¿Qué multas se aplican por notificaciones tardías o ausentes?
Las notificaciones tardías o ausentes pueden crear exposición sancionadora seria; solo existe una excepción estrecha para microempresas y pequeñas empresas respecto de la primera alerta de 24h. Consulta sanciones y ejecución del CRA para la estructura completa.
¿Dónde presento si mi producto se vende en varios Estados miembros?
Presenta una vez por el endpoint SRP de tu CSIRT coordinador. Para un fabricante de la UE, es el Estado miembro donde se toman predominantemente las decisiones de ciberseguridad del producto. Si no hay establecimiento principal en la Unión, usa la cadena de respaldo: representante autorizado, importador, distribuidor y mayor concentración de usuarios. No presentas por separado en cada Estado miembro.
¿El reloj de 24 horas se pausa en fines de semana o festivos?
No. Los relojes de notificación corren en tiempo natural. Los plazos de 24h y 72h corren desde el conocimiento del fabricante; el informe final de vulnerabilidad corre desde la disponibilidad de una medida correctora o mitigadora; el informe final de incidente grave corre desde la notificación de 72h. La cobertura de fines de semana y festivos es un requisito operativo, no opcional.
¿Cómo interactúa la notificación CRA con NIS 2?
La notificación CRA y la notificación NIS 2 pueden aplicar al mismo evento, pero no son la misma obligación. La CRA es a nivel de producto y va por la SRP. NIS 2 es a nivel de entidad o servicio y sigue el canal nacional NIS 2 para incidentes significativos. Hasta que ENISA, la Comisión o autoridades nacionales publiquen guía final de enrutamiento, cualquier afirmación de que una presentación satisface ambos regímenes debe tratarse como no confirmada.