Cómo presentar una notificación CRA en la plataforma única de ENISA, según su propio manual

El artículo 14(7) del Cyber Resilience Act, Reglamento (UE) 2024/2847, dice que las notificaciones de un fabricante sobre una vulnerabilidad explotada activamente o un incidente grave «se presentarán a través de la plataforma única de notificación a que se refiere el artículo 16». No por correo electrónico a un CSIRT, no mediante un portal nacional: a través de la plataforma. ENISA la abrió el 11 de septiembre de 2026, el día en que empezó la obligación, en portal.cra-srp.enisa.europa.eu, y publicó junto a ella un manual de usuario, un glosario de cada campo, un conjunto de páginas de guía y 31 respuestas a preguntas frecuentes.

Este artículo es la lectura de esos documentos de principio a fin, para un fabricante que nunca ha visto la plataforma y se la encontrará en la hora uno de un incidente. Todo lo que sigue procede de las propias páginas de ENISA tal como estaban el 12 de septiembre de 2026, o del Reglamento. Donde la plataforma hace algo que el Reglamento no prevé, se dice.

Qué es la plataforma, y qué no es todavía

La plataforma de ENISA es la que el artículo 16(1) le mandó construir: «ENISA establecerá una plataforma única de notificación. El funcionamiento cotidiano de dicha plataforma única de notificación será gestionado y mantenido por ENISA». Su sentido es que usted presente una sola vez. La notificación se pone a disposición de ENISA y del CSIRT designado como coordinador que usted seleccionó, y ese CSIRT la difunde a los coordinadores de los demás Estados miembros donde usted indicó que el producto está disponible, y a su autoridad de vigilancia del mercado. Difundir es trabajo de ellos, no suyo.

Cuatro límites en el lanzamiento, cada uno recogido en las FAQ de ENISA:

• Solo admite notificaciones obligatorias del artículo 14. La notificación voluntaria del artículo 15, por fabricantes o por cualquier otro, no está disponible en el lanzamiento. Las obligaciones de los administradores de software de código abierto del artículo 24(3) se aplican desde el 11 de diciembre de 2027, y la plataforma las admitirá entonces.
• Está solo en inglés. Más idiomas se revisarán en una fase posterior; la ficha informativa se está traduciendo, la plataforma no.
• No hay API. En palabras de ENISA, no se proporciona ninguna interfaz de programación en la versión inicial, así que las notificaciones deben presentarse a través de la interfaz de la plataforma. Un fabricante con muchos productos presenta cada una a mano.
• Una notificación por vulnerabilidad o incidente, para todo el grupo. Tenga las filiales que tenga un fabricante en la UE y esté donde esté su matriz, las FAQ dicen que se requiere una notificación y que coordinarse internamente para que se presente exactamente una es responsabilidad del fabricante.

Quién inicia sesión: los representantes asignados

La plataforma no conoce empresas. Conoce personas, llamadas representantes asignados, que actúan por un fabricante. Cada una necesita una cuenta EU Login personal con la autenticación multifactor activada; las FAQ dicen que la cuenta puede crearse por adelantado, que no se usa ningún mecanismo de autenticación corporativa y que, como las cuentas EU Login son personales, quien notifica usa la suya.

Hay dos roles. El Primary AR se registra directamente: abre la plataforma, selecciona el rol, selecciona el CSIRT designado como coordinador en un desplegable, se autentica mediante EU Login, acepta el acuerdo legal, confirma el nombre y el correo que suministra EU Login e introduce el nombre del fabricante. Eso crea el fabricante en la plataforma y somete la asociación entre persona y fabricante a la validación del coordinador. Hay un Primary AR por fabricante. Un Secondary AR se incorpora por invitación por correo de un Primary AR cuya asociación ya ha sido validada y figura como Verified; el enlace de invitación caduca a los 7 días. Puede haber hasta 20 Secondary AR por fabricante. Un Secondary AR puede presentar y actualizar notificaciones, pero solo ve las que él mismo presentó; el Primary AR ve todo lo presentado para el fabricante, gestiona la asociación e invita o retira a los demás. Un Secondary AR puede reclamar el rol de Primary, sujeto a la aprobación del coordinador.

Dos cosas sobre la validación importan en la hora uno. Primera, no le bloquea: el coordinador valida la asociación después del registro y en paralelo a la notificación, y un representante no verificado puede presentar hasta 20 notificaciones antes de que la verificación sea obligatoria. Segunda, ENISA le pide que no lo haga pronto. Su guía dice que se aconseja a los fabricantes «registrarse e iniciar el proceso de validación solo cuando necesiten presentar una notificación concreta, en lugar de registrarse de forma preventiva», para contener la carga de validación de los coordinadores, y añade que con un EU Login ya creado el registro lleva unos minutos. La preparación es, pues, el EU Login con MFA, para quien notifica y un suplente; el registro es una tarea del día mismo.

Las condiciones de uso, versión 1.0 de 10 de septiembre de 2026, añaden la parte que su departamento jurídico querrá ver: al registrarse o presentar, los usuarios «declaran y garantizan que son el o los representantes asignados de su organización y que están autorizados a actuar en su nombre», y el coordinador puede verificarlo. Ponga la autorización por escrito antes del día en que haga falta.

Qué coordinador elegir

El desplegable del registro, y el campo de cada notificación, es el CSIRT designado como coordinador del Estado miembro donde el fabricante tiene su establecimiento principal en la Unión, que el artículo 14(7) define como el Estado «en el que se toman predominantemente las decisiones relacionadas con la ciberseguridad de sus productos con elementos digitales», o, si no puede determinarse, el Estado con más empleados; y, sin establecimiento principal en la Unión, el Estado del representante autorizado, después el del importador, el del distribuidor y el Estado con más usuarios. Las FAQ de ENISA repiten toda la cascada y añaden una consecuencia que el Reglamento no explicita: «si se selecciona el CDaC equivocado, la notificación puede ser invalidada y deberá volver a presentarse al CDaC correcto». Una alerta roja en el panel es la forma en que se entera.

ENISA publicó la lista de coordinadores el 10 de septiembre de 2026, y en dos Estados no es el CSIRT nacional. La lista, y las dos excepciones, están en un artículo aparte; la tabla también está en la página de plazos de notificación.

Las tres presentaciones, y qué pide cada una

El artículo 14 exige tres presentaciones: una alerta temprana en las 24 horas siguientes al conocimiento, una notificación en 72 horas y un informe final. En la plataforma son tres pestañas de un mismo registro de notificación. Abre una notificación nueva para la alerta temprana, vuelve al mismo registro para la notificación de 72 horas y otra vez para el informe final; cada fase posterior viene rellenada con lo que introdujo antes, y el glosario marca cada campo como requerido, opcional o arrastrado de la fase anterior. La tabla de abajo es la columna de requisitos del glosario, por fase. Los campos que solo aplican a un tipo se marcan AEV para una vulnerabilidad explotada activamente y SI para un incidente grave.

Esa es la estructura propia del Reglamento con los límites de los campos dibujados encima. El artículo 14(2)(a) pide a la alerta temprana que indique «cuando proceda, los Estados miembros en cuyo territorio el fabricante tenga conocimiento de que su producto con elementos digitales ha sido comercializado»; ese es el campo de Estados miembros, requerido desde el primer minuto. El artículo 14(2)(b) pide a la notificación de 72 horas información general sobre el producto, la naturaleza general del exploit y de la vulnerabilidad, las medidas correctoras o de mitigación adoptadas y las que pueden adoptar los usuarios, y cuán sensible considera el fabricante la información; esos son los campos que pasan de opcionales a requeridos en la segunda fase. El artículo 14(2)(c) pide al informe final la gravedad y el impacto, el actor cuando se conozca, y la actualización de seguridad o medida correctora; la tercera columna.

Dos restricciones prácticas del glosario: un título admite 255 caracteres y un resumen 4.000, y toda marca de tiempo se introduce en UTC. El glosario también pide no poner detalles técnicos confidenciales en el título y, si la hora del conocimiento es una estimación, decirlo en la descripción. Una nota al pie conviene conocerla antes de buscar un campo que no está: para una vulnerabilidad, el glosario marca la fecha de conocimiento como requerida y luego dice que el campo «estará disponible en la próxima versión de la plataforma»; para un incidente existe hoy con el nombre «fecha y hora en que se detectó el incidente».

El contador que la plataforma calcula mal, según ella misma

El panel muestra contadores para la notificación de 72 horas y el informe final, con correos recordatorio y alertas de retraso gobernados por ellos. La FAQ 26 dice cómo se calculan, y vale la pena leerla dos veces. El contador de 72 horas «muestra una fecha/hora límite 48 horas después de la presentación de la alerta temprana de 24 horas», no 72 horas después de tener conocimiento. Si presentó la alerta temprana en la hora cuatro, la plataforma mostrará la notificación como vencida en la hora 52, y «en algunos casos, una notificación puede mostrarse como atrasada antes de que hayan transcurrido 72 horas desde que el fabricante o el administrador de software de código abierto tuvo conocimiento del suceso». ENISA dice que la lógica se cambiará en una versión futura para usar el campo de conocimiento. Hasta entonces el reloj de la plataforma no es el reloj del Reglamento, y las FAQ dicen que los contadores «no sustituyen la responsabilidad de los fabricantes» de cumplir los plazos propios del artículo 14.

Para el informe final hay dos contadores y uno falta a propósito. Para un incidente grave, la plataforma cuenta un mes desde la presentación de la notificación de 72 horas, que es el artículo 14(4)(c). Para una vulnerabilidad explotada activamente no hay contador, porque el artículo 14(2)(c) corre 14 días desde que una medida correctora o de mitigación está disponible, y la plataforma no puede conocer esa fecha hasta que usted la introduce. Es la misma distinción que la mayoría de los textos sobre los plazos del CRA pasan por alto, y la razón por la que la calculadora de nuestra página de plazos pide la fecha del parche por separado.

Después de pulsar enviar

Un borrador guardado solo lo ve usted. Presentar la alerta temprana la almacena, la hace accesible al coordinador y a ENISA, y envía un correo y una alerta al coordinador, a ENISA y a cada representante del fabricante. Los coordinadores de los demás Estados miembros que usted nombró no reciben nada automáticamente: la guía de ENISA dice que los CSIRT afectados «recibirán la alerta temprana solo tras la difusión manual por el CSIRT designado como coordinador». Lo mismo vale para la notificación de 72 horas y el informe final.

Puede actualizar una notificación en cualquier fase hasta que se presenta el informe final; la plataforma la hace entonces no editable, y una notificación que el coordinador ha cerrado tampoco puede actualizarse. Una actualización alerta al coordinador, a ENISA y a cualquier CSIRT que ya recibió la notificación. Las alertas del panel son azules mientras no se leen; las rojas «aparecen solo cuando se ha producido una acción excepcional o crítica», siendo el ejemplo de ENISA que el coordinador ha invalidado una presentación.

Pedir que se retrase la difusión

El artículo 16(2) dice que el coordinador «difundirá sin demora la notificación» a los coordinadores de los Estados miembros donde el producto está disponible, y luego abre dos excepciones. En circunstancias excepcionales, «en particular a petición del fabricante y a la luz del nivel de sensibilidad de la información notificada indicado por el fabricante», el coordinador puede retrasar la difusión por motivos justificados de ciberseguridad durante el tiempo estrictamente necesario. Y en «circunstancias especialmente excepcionales», cuando el fabricante indica en la notificación de 72 horas una de tres cosas, solo llegan a ENISA el hecho de la notificación, la información general sobre el producto, la naturaleza general del exploit y el hecho de que se alegaron motivos, hasta que se difunde la notificación completa. Las tres, literalmente:

(a) que la vulnerabilidad notificada ha sido explotada activamente por un agente malintencionado y, según la información disponible, no ha sido explotada en ningún otro Estado miembro distinto del CSIRT designado como coordinador al que el fabricante ha notificado la vulnerabilidad; (b) que toda difusión ulterior inmediata de la vulnerabilidad notificada daría lugar probablemente al suministro de información cuya divulgación sería contraria a los intereses esenciales de ese Estado miembro; o (c) que la vulnerabilidad notificada plantea un riesgo elevado inminente de ciberseguridad derivado de su difusión ulterior;

En la plataforma esto es un conmutador, disponible en exactamente un lugar: la notificación de 72 horas de una vulnerabilidad explotada activamente. Activarlo muestra un «PEC delay reason» con los tres motivos como casillas y una justificación opcional de 800 caracteres «que puede ayudar al CSIRT designado como coordinador a decidir». El estado de difusión pasa a «72h Submitted under PEC», ENISA recibe solo la información limitada, y la decisión de si difundir y cuándo es del coordinador, no del fabricante. Un conmutador es una petición.

Lo que el coordinador puede hacer con esa petición lo fija ahora el Reglamento Delegado (UE) 2026/881 de la Comisión de 11 de diciembre de 2025, publicado en el Diario Oficial el 20 de abril de 2026. El artículo 3 permite al coordinador retrasar la difusión solo cuando los riesgos de ciberseguridad de difundir superan sus beneficios, esos riesgos no pueden gestionarse con restricciones como el Traffic Light Protocol, y se cumple una de cuatro condiciones: el fabricante ha dicho que se espera una mitigación eficaz en 72 horas, en cuyo caso el retraso termina si no llega; la notificación contiene lo suficiente para construir un exploit, «en particular cuando la vulnerabilidad puede ser identificada y explotada fácilmente por agentes con capacidades y recursos limitados»; el coordinador puede compartir lo suficiente para que los demás CSIRT mitiguen sin la notificación completa; o el coordinador supo de la vulnerabilidad como intermediario de confianza en una divulgación coordinada. En el segundo y tercer caso la notificación completa sale en cuanto hay una mitigación disponible. Los artículos 4 y 5 añaden motivos que tienen que ver con los destinatarios, no con el fabricante: un CSIRT, o la propia plataforma, que ha sufrido un incidente que pone en duda su capacidad de mantener confidencial la notificación.

Así que la descripción honesta del conmutador es esta: si tiene un parche en camino en tres días, o los detalles darían a un atacante poco cualificado un exploit funcional, dígalo, marque el motivo que corresponda y dé al coordinador los hechos en los 800 caracteres. Luego planifique como si la difusión ocurriera de todos modos.

Si la plataforma está caída

FAQ 25: si la plataforma no está disponible temporalmente, espere a que vuelva y presente entonces. Si entretanto considera necesaria una comunicación inmediata, puede contactar directamente con su coordinador, pero «la notificación debe presentarse igualmente a través de la SRP en cuanto vuelva a estar disponible». Algunos coordinadores han publicado un plan alternativo: el NCSC irlandés da una dirección de correo de emergencia para el caso en que ENISA haya declarado la plataforma fuera de servicio, y dice que los envíos a ella solo se aceptan entonces. El artículo 17(6) obliga a cada coordinador a prestar asistencia sobre el artículo 14, «en particular» a los fabricantes que sean microempresas o pequeñas y medianas empresas; el servicio de asistencia de ENISA se alcanza por correo desde la página de FAQ.

Cinco cosas que las FAQ zanjan

1. No hay notificación retroactiva. Un fabricante que ya tenía conocimiento de la explotación activa antes del 11 de septiembre de 2026 no está obligado a notificarla ahora; el conocimiento después de esa fecha activa la obligación aunque la vulnerabilidad en sí fuera antigua o conocida.
2. Los productos ya en el mercado están incluidos. El artículo 14 se aplica desde el 11 de septiembre de 2026 a todo producto con elementos digitales dentro del ámbito del Reglamento, incluidos los introducidos en el mercado antes del 11 de diciembre de 2027.
3. Componentes de terceros. Para una vulnerabilidad en un componente que usted integra, ENISA remite a la sección 5.4 de las FAQ de la Comisión sobre la aplicación y al apartado 218 de las orientaciones de la Comisión de 27 de julio de 2026, en lugar de responder con sus propias palabras. Léalos antes de decidir que no es usted quien tiene que notificar.
4. La notificación no aumenta su responsabilidad. Artículo 17(4): «el mero hecho de la notificación ... no expondrá a la persona física o jurídica notificante a una mayor responsabilidad».
5. Tras el parche, la vulnerabilidad se hace pública. Artículo 17(5): una vez disponible una actualización de seguridad u otra medida correctora, ENISA añade la vulnerabilidad notificada a la base de datos europea de vulnerabilidades, de acuerdo con el fabricante.

Qué preparar antes de necesitar nada de esto

• Cuentas EU Login con autenticación multifactor para la persona que notifica y un suplente, creadas hoy, y una autorización escrita para ambos.
• Su Estado miembro y su coordinador, decididos según el artículo 14(7) y escritos en el procedimiento de incidentes, para que nadie elija entre entradas de un desplegable en la hora uno.
• Un inventario de productos con los identificadores exactos de versión, compilación, modelo o firmware que pide el campo de versión, y una lista de los Estados miembros donde se comercializa cada producto, porque ese campo es requerido en la alerta temprana.
• Una convención para «tener conocimiento», y una regla de que la marca de tiempo se registra en UTC en el momento en que se fija.
• Un borrador de una página con los campos de la alerta temprana en un documento del que pueda copiar: título de menos de 255 caracteres, resumen de menos de 4.000, las dos fechas, los Estados miembros.
• El nombre de quien decide, dentro de las primeras 72 horas, si se marca la casilla de circunstancias excepcionales, y con qué hechos.

La plataforma no hará nada de esto por usted, y este artículo tampoco. Lo que puede hacer es convertir la hora uno en cuestión de teclear en vez de leer.

Fuentes

• ENISA, páginas de la Single Reporting Platform: la página principal, las FAQ (actualizadas el 11 de septiembre de 2026), las páginas de guía sobre registro de usuarios, presentación y actualización de notificaciones, funciones de la interfaz y circunstancias especialmente excepcionales (actualizadas el 9 y el 10 de septiembre de 2026), el glosario SRP, el AR User Manual y las condiciones de uso v1.0 de 10 de septiembre de 2026, todos leídos el 12 de septiembre de 2026.
• ENISA, List of CSIRTs Designated as Coordinators, actualizada por última vez el 10 de septiembre de 2026.
• Reglamento (UE) 2024/2847, artículos 14, 16 y 17, y artículo 71(2).
• Reglamento Delegado (UE) 2026/881 de la Comisión de 11 de diciembre de 2025, artículos 3 a 5, DO L de 20 de abril de 2026.
• Comisión Europea, orientaciones C(2026) 5252 de 27 de julio de 2026, y las FAQ sobre la aplicación del CRA, sección 5.
• NCSC de Irlanda, página sobre las obligaciones de notificación del Cyber Resilience Act, actualizada el 11 de septiembre de 2026.

Esto no es asesoramiento jurídico. El glosario es una tabla de 39 campos y las FAQ son 31 preguntas; ambos son lo bastante cortos para leerlos antes de necesitarlos.