Notificación de incidentes y vulnerabilidades (art. 14)

Las obligaciones de notificación del fabricante del artículo 14 del Reglamento (UE) 2024/2847 se aplican desde el 11 de septiembre de 2026, también a productos ya en el mercado.

Esta página es la recopilación para clientes y operadores. El triage interno: política Security Incident (Notion; puede requerir acceso).

Qué hay que notificar

Solo:

• Vulnerabilidades explotadas activamente — indicios fiables de que un actor malicioso explotó una vulnerabilidad del producto sin permiso del propietario del sistema.
• Incidentes graves con impacto en la seguridad del producto (art. 14(5)): afectan (o pueden) a la disponibilidad, autenticidad, integridad o confidencialidad de datos o funciones sensibles o importantes, o han llevado (o pueden) a la introducción de código malicioso en el producto o en los sistemas del usuario.

Los fallos rutinarios y parches ordinarios no son sucesos del art. 14.

Cómo presenta el fabricante

Una notificación a través de la plataforma única de notificación de ENISA: https://portal.cra-srp.enisa.europa.eu.

• Dirigida al CSIRT designado coordinador del establecimiento principal en la Unión (donde se toman predominantemente las decisiones de ciberseguridad; si no, el establecimiento con más empleados en la Unión), accesible simultáneamente a ENISA (art. 14(7), art. 16).
• Los Assigned Representatives usan un EU Login personal con autenticación multifactor. FAQ SRP de ENISA (3 oct. 2026): la validación de la asociación del fabricante puede ir en paralelo con la primera notificación.
• Si la SRP no está disponible: esperar y presentar cuando vuelva. El contacto directo con el CSIRT no sustituye el depósito en la SRP.
• Las notificaciones voluntarias del art. 15 no están en la primera versión de la SRP.
• El Reglamento Delegado (UE) 2026/881 solo permite al CSIRT receptor retrasar la difusión a otros CSIRT. No pausa los plazos del fabricante.

La persona Primary Assigned Representative sigue TBD (no inventar un nombre). La fila CSIRT sigue TBD hasta confirmar la entidad jurídica / establecimiento principal. Estados miembros de puesta a disposición: todos los EU-27 (abajo).

Assigned Representative, EU Login, CSIRT, SRP — qué significa

Cuatro cosas distintas. Ninguna es un ajuste del producto.

Término	Qué es	Qué hacer
Assigned Representative (AR)	Una persona física nombrada que puede presentar notificaciones art. 14 del fabricante. ENISA espera un AR Primary y recomienda un Secondary. No es el representante autorizado del art. 19 (persona jurídica, solo sin establecimiento en la Unión).	Nombrar a las personas (TBD). Incluirlas en la guardia de incidentes como reportero CRA.
EU Login + MFA	La cuenta personal de la Comisión Europea (EU Login) con autenticación multifactor. No es el login compartido de info@.	Cada AR crea su EU Login, activa MFA y se registra en la SRP. ENISA CRA SRP Guidance — AR User Registration.
CSIRT del establecimiento principal en la UE	El CSIRT nacional designado coordinador del Estado miembro del establecimiento principal (art. 14(7)): donde se toman predominantemente las decisiones de ciberseguridad del producto; si no se puede determinar, el establecimiento de la Unión con más empleados. Sin establecimiento en la Unión: cascada art. 14(7).	Elegir la fila de la lista ENISA de CSIRT designados coordinadores (4 sep. 2026; también el desplegable del portal). No adivinar (ni Bélgica) hasta confirmar entidad / establecimiento principal. Un coordinador incorrecto puede invalidar el envío mientras corre el plazo de 24 h.
Portal SRP	portal.cra-srp.enisa.europa.eu — único cauce válido del art. 14. Una notificación es visible para el CSIRT elegido y ENISA.	Guardarlo en el playbook. Presentar aunque la validación CSIRT de la asociación del fabricante siga pendiente (FAQ ENISA 9).

Estados miembros de puesta a disposición

Posición de trabajo (6 oct. 2026): el producto se pone a disposición en todos los Estados miembros de la UE. Usar esta lista en la alerta temprana de 24 h.

Austria, Belgium, Bulgaria, Croatia, Cyprus, Czechia, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden.

Plazos (art. 14(2) y (4))

1. 24 horas desde el conocimiento — alerta temprana, incluidos los Estados miembros donde el producto se ha puesto a disposición (si procede).
2. 72 horas — notificación más completa: producto, naturaleza del exploit o incidente, medidas tomadas, medidas para usuarios, sensibilidad de la información.
3. Informe final — vulnerabilidad explotada activamente: a más tardar 14 días después de que esté disponible una medida correctora o de mitigación. Incidente grave: en un mes tras la notificación de 72 horas.

Informar a los usuarios (art. 14(8))

Tras conocer una vulnerabilidad explotada activamente o un incidente grave, el fabricante informa a los usuarios afectados (y, si procede, a todos) de esa vulnerabilidad o incidente y, cuando sea necesario, de las medidas de mitigación.

Cómo lo hace Roasthubs:

1. Identificar productos y sitios afectados.
2. Correo a contactos de operador/admin de esos sitios. No esperar la validación CSIRT de la SRP.
3. Publicar un GitHub Security Advisory en roasthubs-os y una fila en avisos de seguridad — de inmediato si los usuarios deben actuar antes de un parche; si no, cuando el arreglo esté disponible (anexo I parte II §4).
4. Seguimiento en la dirección CVD vigilada info@roasthubs.com.
5. Registrar quién / cuándo / por qué canal — alimenta el campo SRP de 72 h «medidas que pueden tomar los usuarios».

Los changelogs de funciones no son el canal del art. 14(8). Los fallos rutinarios no son hechos del art. 14.

Manuales oficiales: ENISA SRP y Comisión notificación CRA.