Notificación CRA de vulnerabilidades e incidentes

Desde el 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.

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:

1. Notificar toda vulnerabilidad explotada activamente del producto simultáneamente al CSIRT coordinador y a ENISA, con cadencia 24h / 72h / 14d.
2. Notificar todo incidente grave que afecte a la seguridad del producto, con cadencia 24h / 72h / 1 mes.
3. 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 de la difusión permite al CSIRT coordinador aplazar la difusión posterior en circunstancias excepcionales, por motivos justificados de ciberseguridad y durante el tiempo estrictamente necesario. El fabricante puede pedirlo y puede señalar lo sensible que es la información, pero la decisión es del CSIRT, no tuya. Existe además un segundo retraso, distinto, para una vulnerabilidad de la que el CSIRT coordinador ha tenido conocimiento a través de un procedimiento de divulgación coordinada. Ahí el CSIRT puede retener la notificación por motivos justificados de ciberseguridad, durante un plazo no superior al estrictamente necesario y hasta que las partes de esa divulgación consientan en divulgarla. Conviene tenerlo presente si llevas un proceso de divulgación coordinada, pero aquí la decisión también es del CSIRT, así que no cuentes con que el embargo aguante.
• Las circunstancias excepcionales particulares (PEC) son un mecanismo aparte y más estrecho. Se aplican solo a la notificación de 72 horas de una vulnerabilidad explotada activamente, y solo cuando la explotación se limita al Estado miembro de tu coordinador, cuando una divulgación más amplia iría contra los intereses esenciales de ese Estado, o cuando la propia difusión crearía un riesgo de ciberseguridad alto e inminente. Lo activas con un selector en la plataforma y puedes añadir una justificación; decide el CSIRT coordinador. Mientras se mantiene, ENISA sigue recibiendo un conjunto reducido: que se ha presentado una notificación, la información general del producto, la naturaleza general de la explotación y que se han alegado motivos de seguridad. La notificación completa llega cuando termina el retraso. La orientación de ENISA sobre las PEC detalla el procedimiento.

Estado, 11 de septiembre de 2026: la SRP está disponible desde el 11 de septiembre de 2026 en portal.cra-srp.enisa.europa.eu. Eliges el rol Assigned Representative y accedes con EU Login: cuenta personal y con autenticación multifactor obligatoria. Ese rol es la cuenta de la SRP que notifica en nombre de un fabricante o de un administrador de código abierto, y no equivale a un representante autorizado del CRA. ENISA actualizó sus preguntas frecuentes y la guía de registro del Assigned Representative el 10 de septiembre de 2026, y las guías de interfaz y de notificación el 9 de septiembre de 2026. El 9 de septiembre de 2026 publicó además un AR User Manual de 55 páginas, el recorrido pantalla a pantalla del registro, de las tres fases de presentación y de la actualización de una notificación. El glosario de la SRP va por la versión 1.3 y es la referencia campo por campo. Está solo en inglés. La lista de CSIRT coordinadores lleva fecha de 10 de septiembre de 2026. En esta primera versión no hay API: se notifica por la interfaz de la plataforma. La notificación voluntaria tampoco está en el lanzamiento, llega más adelante. ENISA marca toda su documentación como sujeta a cambios. Crea ya tu cuenta EU Login, consulta la guía de alta en la SRP de ENISA y escribe a cra-srp-helpdesk@enisa.europa.eu si necesitas ayuda.

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

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.

1. Conocimiento del fabricante. El reloj de 24 horas empieza cuando una evaluación inicial rápida da al fabricante un grado razonable de certeza de que una vulnerabilidad de su producto se está explotando activamente.
2. +24h alerta temprana. Presenta la alerta inicial a través de la ENISA Single Reporting Platform.
3. +72h notificación detallada. Añade detalles técnicos, versiones afectadas, estado de explotación y mitigación.
4. Medida disponible. Para vulnerabilidades, el reloj del informe final empieza aquí, no en el descubrimiento.
5. +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

El glosario de la SRP de ENISA es la referencia campo por campo de lo que la plataforma pide en cada fase. La versión 1.3 enumera 39 campos: 18 comunes a los dos flujos, 12 que solo se aplican a una vulnerabilidad explotada activamente y 9 que solo se aplican a un incidente grave. Está solo en inglés y ENISA lo marca como conocimiento disponible actualmente y sujeto a cambios. Códigos: X obligatorio, O opcional, C copiado del paso anterior por defecto o actualizado, I obligatorio si la información está disponible, - no aplicable en esa fase.

Criterios de severidad (i34): 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: Glosario de la SRP de ENISA, versión 1.3, última actualización de 10 de septiembre de 2026.

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

Conocimiento y evidencia

La definición del CRA usa pruebas fiables para identificar una vulnerabilidad explotada activamente. El conocimiento es una prueba distinta: tras una evaluación inicial rápida, el fabricante debe tener un grado razonable de certeza de que una vulnerabilidad de su producto se está explotando activamente. No hace falta terminar una investigación forense.

Entrada CVD y puerta de notificación

La política CVD es el proceso de entrada que convierte informes externos en triaje estructurado. Si el triaje indica explotación activa, evalúala de inmediato. El reloj de notificación empieza cuando esa evaluación inicial da al fabricante un grado razonable de certeza. 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:

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. Bastan una evaluación inicial rápida y un grado razonable de certeza; no hace falta terminar una investigación forense.
• Confundir CVD con notificación urgente. Un informe de investigador es entrada CVD; la notificación urgente empieza cuando la evaluación inicial da al fabricante un grado razonable de certeza sobre la 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 la notificación por la SRP como problema futuro. Plantillas, guardias y relaciones CSIRT deben existir antes del primer evento notificable.

1. El glosario marca este campo como obligatorio en la alerta temprana de 24 horas y, en la misma fila, indica que llega en la próxima versión de la plataforma. Hasta que llegue esa versión puede que no lo veas en pantalla. Conserva tu propia marca temporal de conocimiento y prepárate para aportarla en cualquiera de los dos casos. ↩︎

2. El glosario indica que en la versión actual este campo se titula «Date and time when the incident was detected (UTC time)». La detección no es lo mismo que el conocimiento, así que registra las dos cosas. ↩︎