La Ley Europea de Ciberresiliencia (Reglamento (UE) 2024/2847) canaliza por un único cauce las vulnerabilidades notificables y los incidentes graves de todo fabricante: la Plataforma Única de Notificación de ENISA, disponible en portal.cra-srp.enisa.europa.eu desde el 11 de septiembre de 2026. Esta página cubre qué preparar, cómo funciona el registro y cómo articular una escalada interna que encaje en el reloj de 24 horas. Para las cadencias, véase notificación de vulnerabilidades.
Resumen
- La Plataforma Única de Notificación es el único canal de notificación, y está en portal.cra-srp.enisa.europa.eu. Selecciona el rol Assigned Representative, inicia sesión con EU Login y una sola presentación llega a la vez a tu CSIRT coordinador y a ENISA. El correo electrónico a un CSIRT nacional no es un sustituto.
- Las cuentas EU Login son personales y exigen autenticación multifactor. No hay un inicio de sesión de empresa compartido. Un AR primario por fabricante y hasta 20 AR secundarios, todos ellos personas con nombre y apellidos.
- Prepárate antes del primer evento notificable. El reloj de 24 horas no se detiene por problemas de registro o de enrutamiento. Mantén listos los datos de entidad jurídica, producto, contactos y escalada.
- Los fabricantes y los administradores de comunidad de programas informáticos de código abierto son los obligados. Los importadores y distribuidores informan al fabricante. No presentan notificaciones ellos mismos. Un mandato de representante autorizado puede cubrir la notificación de un fabricante no perteneciente a la UE.
- Separa los fines de cada contacto. El punto único de contacto para los usuarios es el canal orientado al usuario. El contacto de autoridad de la plataforma debe gestionarse por separado para que ENISA y el CSIRT coordinador lleguen al equipo de notificación.
- El enrutamiento al CSIRT sigue al establecimiento principal. Las notificaciones se dirigen al CSIRT designado como coordinador en el Estado miembro del establecimiento principal, con una cadena de reserva para fabricantes no pertenecientes a la UE detallada en enrutamiento al CSIRT más abajo. La lista de coordinadores de ENISA lleva fecha de 10 de septiembre de 2026, y elegir el coordinador equivocado puede invalidar la notificación.
El alta es una tarea de preparación. El reloj empieza con el conocimiento, no en el momento en que decides registrarte.
Qué dice el CRA sobre la Plataforma Única de Notificación
ENISA crea y opera la Plataforma Única de Notificación (SRP). Los Estados miembros y ENISA pueden establecer sus propios nodos finales para notificaciones electrónicas bajo esa arquitectura. De ahí se derivan tres hechos operativos:
- ENISA opera la plataforma. Los Estados miembros y ENISA pueden establecer además sus propios nodos finales para notificaciones electrónicas.
- Una sola presentación llega a ambos niveles. El fabricante presenta a través del nodo final del CSIRT coordinador, y la notificación queda simultáneamente accesible para ENISA.
- El enrutamiento transfronterizo ocurre dentro de la plataforma. El CSIRT receptor difunde la notificación a los demás CSIRT cuyo territorio el fabricante haya indicado como afectado.
La Plataforma Única de Notificación es el canal de la alerta temprana de 24 horas, la notificación de 72 horas y el informe final. La notificación voluntaria no está disponible en la apertura. ENISA sitúa esa funcionalidad en una fase posterior, así que el primer día la plataforma solo acepta notificaciones obligatorias. Quien pensara usarla para comunicaciones voluntarias de vulnerabilidades o de incidentes evitados tendrá que esperar.
Quién debe registrarse
Los fabricantes son los responsables de la notificación obligatoria por la Plataforma Única de Notificación. La obligación recae sobre los fabricantes de productos con elementos digitales, no sobre el resto de la cadena de suministro.
Los administradores de comunidad de programas informáticos de código abierto también notifican, pero no hasta el 11 de diciembre de 2027. El CRA les da una fecha de inicio posterior a la de los fabricantes, así que un administrador dispone de quince meses más para montar el proceso. Desde esa fecha debe notificar las vulnerabilidades explotadas activamente cuando participa en el desarrollo del producto afectado, y los incidentes graves que afecten a los sistemas que aporta para ese desarrollo. Hay un matiz que se le escapa a mucha gente: la fecha posterior va unida al rol de administrador, no a la organización. Si esa misma organización introduce además un producto en el mercado como fabricante, ese producto está dentro del ámbito desde el 11 de septiembre de 2026.
Los importadores y distribuidores informan al fabricante. No se registran en la plataforma, no presentan notificaciones ellos mismos ni heredan el reloj de 24 horas. Su deber es informar al fabricante sin demora indebida cuando tengan conocimiento de una vulnerabilidad. Véase importador y distribuidor.
Los fabricantes no pertenecientes a la UE necesitan claridad de enrutamiento. Un mandato escrito de representante autorizado puede cubrir la notificación obligatoria porque las exclusiones aplicables al representante autorizado no incluyen la propia notificación. Sin establecimiento principal en la Unión, el enrutamiento sigue la cadena de reserva: representante autorizado, importador, distribuidor y, en último lugar, concentración de usuarios.
Requisitos previos al registro
Siete elementos que la organización debería tener listos antes del registro. ENISA marca sus orientaciones como sujetas a cambios, así que trata las pantallas como documentadas y no como definitivas; aun así, la falta de cualquiera de estos elementos retrasará la primera presentación.
| Requisito | Lo que necesita |
|---|---|
| Entidad jurídica en el Estado miembro del establecimiento principal | Un registro inequívoco de entidad jurídica que te permita seleccionar el CSIRT coordinador correcto al registrarte (el Estado "en el que se adopten de forma predominante las decisiones relativas a la ciberseguridad de sus productos con elementos digitales"). |
| Punto único de contacto para los usuarios | Un canal orientado al usuario que "no limitará dichos medios a herramientas automatizadas". Los buzones de solo respuesta automática no cumplen el requisito. Publicado en la información para el usuario que acompaña al producto. |
| Contacto de seguridad orientado a las autoridades | Un contacto para ENISA y el CSIRT coordinador, operativamente distinto del canal orientado al usuario. Los campos exactos del registro siguen sujetos a las especificaciones de ENISA. |
| Cuentas EU Login, personales y con MFA | El registro usa una cuenta EU Login personal con autenticación multifactor activada; créala de antemano en ecas.ec.europa.eu. La SRP no añade un inicio de sesión de empresa aparte, así que cada persona que presenta entra con su propia identidad. El CSIRT coordinador valida que esa persona puede actuar en nombre del fabricante después del primer acceso, en paralelo con la notificación y sin bloquear la presentación. |
| Decisión sobre el CSIRT coordinador, por escrito | Elige tu CSIRT designado como coordinador en la lista publicada por ENISA antes del primer evento y deja constancia del motivo. ENISA indica que una notificación enviada al coordinador equivocado puede quedar invalidada y que hay que volver a presentarla ante el correcto. |
| Inventario del catálogo de productos | Una lista actualizada de los productos y los Estados miembros en los que cada uno se ha comercializado. Sin ella, la alerta temprana no puede indicar correctamente los territorios afectados. |
| Escalada interna documentada | Un procedimiento escrito que lleve a la organización desde la detección hasta la presentación a la plataforma en menos de 24 horas, con cobertura fuera de horario. "Sin demora indebida y en cualquier caso en un plazo de 24 horas" no deja margen para escaladas improvisadas. |
Calendario: del corte al primer evento notificable
Fijado: la dirección de la plataforma y la fecha de inicio del 11 de septiembre de 2026. ENISA hizo pruebas de usuario, de seguridad y técnicas con los CSIRT nacionales, el CRA Expert Group y una selección de fabricantes, y no añadió más pruebas antes de la apertura. Todavía en movimiento: ENISA marca cada página de orientación como conocimiento disponible actualmente y sujeta a cambios, la Comisión aún puede precisar el formato y los procedimientos de notificación mediante acto de ejecución, y la propia ENISA ha dicho que la lógica del contador de 72 horas cambiará en una versión posterior. Esta página refleja la FAQ y la guía de registro de ENISA del 10 de septiembre de 2026, la guía de la interfaz y la guía de notificación del 9 de septiembre de 2026, el AR User Manual en su versión 1.1, actualizada por última vez el 10 de septiembre de 2026, el SRP Glossary versión 1.3 y la lista de coordinadores con fecha de 10 de septiembre de 2026. Verifica frente a la página oficial de la SRP de ENISA antes de dar por definitiva cualquier pantalla concreta.
Fuentes oficiales de ENISA
ENISA indica que sus orientaciones reflejan el conocimiento disponible actualmente y pueden cambiar. Consulta estas fuentes antes de dar por definitivo un paso concreto.
| Documento | Enlace | Estado según ENISA |
|---|---|---|
| Portal de la SRP | portal.cra-srp.enisa.europa.eu | Disponible desde el 11 de septiembre de 2026 |
| CRA SRP - AR User Manual (55 páginas) | AR User Manual (PDF directo) | Versión 1.1, actualizado por última vez el 10 de septiembre de 2026 |
| CRA SRP guidance, Particular Exceptional Circumstances (PEC) | Orientación sobre PEC | Actualizada en septiembre de 2026 |
| CRA Single Reporting Platform, Terms and Conditions | Términos y condiciones | Actualizados el 10 de septiembre de 2026 |
| Página de la SRP de ENISA | Single Reporting Platform (SRP) | Página del programa, ficha informativa y vídeos |
| Preguntas frecuentes sobre la SRP | Frequently Asked Questions | Actualizada el 10 de septiembre de 2026 |
| CRA SRP Glossary, campo por campo | CRA SRP Glossary | Versión 1.3 |
| List of CSIRTs Designated as Coordinators | Lista de coordinadores | Actualizada el 10 de septiembre de 2026 |
| CRA Single Reporting Platform Factsheet (PDF, en inglés) | www.enisa.europa.eu/media/57221 | Solo en inglés, sin fecha de versión en el archivo |
| CRA SRP - AR User registration | AR User registration | Actualizada el 10 de septiembre de 2026 |
| CRA SRP - AR Notification submission and update | AR Notification submission and update | Actualizada el 9 de septiembre de 2026 |
| CRA SRP - AR Interface functions | AR Interface functions | Actualizada el 9 de septiembre de 2026 |
| CRA SRP Status | Página de estado de la SRP | Indicador de disponibilidad en tiempo real. En el momento de escribir esto muestra las dos lecturas a la vez |
| Página de la Comisión sobre notificación y FAQ de aplicación del CRA | CRA reporting | La sección 5 cubre la notificación |
| Orientación de aplicación de la Comisión | Orientación, 27 de julio de 2026 | La sección 9.1 cubre la notificación |
El SRP Glossary conviene leerlo antes de la primera presentación, no durante. Cubre 39 campos: 18 comunes, más 12 para una vulnerabilidad explotada activamente y 9 para un incidente grave. De cada campo da el significado, cómo rellenarlo, un ejemplo, el formato esperado y si es obligatorio, opcional, obligatorio si se dispone de la información, o si se arrastra de la fase anterior. Está solo en inglés y es ya la única referencia de campos: la FAQ te remite aquí en lugar de enumerarlos ella misma. Fíjate en lo que esos 39 no incluyen. Las marcas de tiempo de la notificación y el notificante los rellena la plataforma por ti, y la fase de notificación la eliges tú en vez de prepararla como campo de datos, así que ninguno de ellos aparece en el glosario ni hay que redactarlo por adelantado.
Dirección de asistencia de ENISA para la plataforma: cra-srp-helpdesk@enisa.europa.eu. Otras dos direcciones cubren la seguridad de la propia plataforma, no la de tus productos: un incidente de seguridad que afecte a la plataforma se comunica a cra-srp-security@enisa.europa.eu, y una vulnerabilidad que encuentres en la plataforma misma, a responsible-disclosure@enisa.europa.eu, la dirección que figura en el security.txt de ENISA. Ninguna de las dos es una vía para notificaciones CRA sobre tus propios productos.
Flujo de registro
ENISA actualizó su guía paso a paso de registro el 10 de septiembre de 2026 y sigue marcándola como sujeta a cambios. Para el recorrido pantalla a pantalla, con capturas del registro, de las tres fases de presentación y de la actualización de una notificación, la referencia más completa es el AR User Manual de ENISA.
Assigned Representative es un rol de la plataforma, no una figura jurídica. ENISA llama Assigned Representative (AR) al usuario de la SRP que presenta notificaciones en nombre de un fabricante o de un administrador de comunidad de programas informáticos de código abierto. Es un rol de la cuenta en la SRP, distinto del representante autorizado del CRA, que se designa por mandato escrito. La guía se aplica también cuando un fabricante establecido en la UE no ha designado representante autorizado.
Para un AR primario, el flujo es:
- Abre portal.cra-srp.enisa.europa.eu, selecciona tu rol de AR y continúa.
- Selecciona en el desplegable el CSIRT designado como coordinador. Identificar el correcto es responsabilidad del fabricante.
- Inicia sesión con EU Login.
- Lee y acepta el acuerdo legal.
- Confirma tus datos personales precargados, que vienen de EU Login y no se pueden editar en la plataforma.
- Introduce el nombre del fabricante y, de forma opcional, información adicional.
La plataforma crea entonces la entidad del fabricante, tu cuenta pasa a Active con el rol AR Primary User, la asociación se envía a tu CSIRT coordinador para su validación y recibes un correo de confirmación. Con una cuenta EU Login que ya funcione, esto lleva minutos.
Un AR secundario se registra de otra forma: parte de la invitación recibida por correo, inicia sesión con EU Login, confirma sus datos personales precargados y acepta la asociación con el fabricante.
Un AR primario por fabricante, más hasta 20 AR secundarios. En la plataforma llevan las etiquetas de rol AR Primary User y AR Backup User.
- El AR primario tiene las funciones administrativas: gestionar la entidad del fabricante e invitar o retirar AR secundarios. ENISA restringe esa invitación: solo está disponible para un AR primario cuya asociación AR-fabricante haya validado el CSIRT coordinador y figure como Verified. Hasta entonces no puedes añadir a tu persona de reserva. La asociación se valida por fabricante, así que un AR que actúa para varios fabricantes queda verificado con cada uno por separado.
- Un AR secundario se incorpora desde una invitación por correo y confirma los datos precargados del fabricante. Si ese registro no se completa en 7 días, el estado pasa a Invitation Expired y hay que enviar la invitación otra vez.
- Un AR secundario puede reclamar después el rol primario.
Nombrar un secundario es opcional. Hazlo de todos modos, porque las cuentas EU Login son personales, no hay un inicio de sesión de empresa al que recurrir y el reloj de 24 horas no espera a quien tenga la única cuenta.
La validación corre en paralelo y no bloquea tus notificaciones. El CSIRT coordinador valida la asociación AR-fabricante después del primer acceso. Que la validación esté pendiente no te impide presentar notificaciones, pero sí te impide invitar a un AR secundario. Los procedimientos y los plazos de tramitación varían según el CSIRT. ENISA pide a los fabricantes que no se registren de forma preventiva y que inicien el registro y la validación cuando de verdad necesiten presentar una notificación, lo que mantiene manejable la cola de validación de cada CSIRT.
Un AR sin validar puede presentar hasta 20 notificaciones para un fabricante antes de que la validación pase a ser obligatoria. La FAQ de ENISA, su guía de la interfaz y el AR User Manual dan todos la misma cifra. Trata ese margen como una válvula de seguridad frente a una cola de validación lenta, no como holgura con la que planificar, y completa la validación.
Nuestra lectura del consejo de ENISA: divídelo en dos. Crea ahora las cuentas EU Login personales y activa la autenticación multifactor, porque esa parte depende de un dispositivo, un teléfono y la agenda de alguien. Deja el registro en la SRP para el día en que lo necesites, exactamente como pide ENISA.
Ten esto listo antes de empezar:
- Entidad jurídica: quién es el fabricante y dónde se encuentra su establecimiento principal.
- Contacto de autoridad: el contacto de la plataforma para los mensajes de ENISA y del CSIRT coordinador, separado del canal orientado al usuario.
- Cobertura de productos: el catálogo de productos y los Estados miembros donde se comercializan los productos afectados.
- Enrutamiento del coordinador: la asignación del CSIRT conforme a las reglas de establecimiento principal y de reserva.
Tras el registro, el mismo nodo final gestiona las presentaciones posteriores: la alerta temprana de 24 horas, la notificación de 72 horas, los informes intermedios solicitados por el CSIRT y el informe final.
No hay API de la Plataforma Única de Notificación en la versión inicial. ENISA dice que las organizaciones pueden automatizar sus flujos internos de notificación e integrar la notificación CRA en sus propios sistemas, y que la funcionalidad de API podría estudiarse en una fase futura, pero la presentación en sí ocurre en la interfaz. El reparto práctico: automatiza la preparación, no la presentación. Saca de tus propios sistemas el nombre y la versión del producto, los Estados miembros afectados y el identificador CVE o EUVD, deja un borrador listo para pegar y que lo pegue una persona con nombre y apellidos.
Los contadores de la plataforma no son tu plazo
La plataforma muestra contadores para la notificación de 72 horas y para el informe final, y manda correos de recordatorio contra ellos. ENISA es explícita: existen para dar visibilidad y no sustituyen a las obligaciones de notificación. En esta versión hay tres detalles que importan.
- El contador de 72 horas cuenta desde tu alerta temprana, no desde el conocimiento. Muestra una fecha límite 48 horas después de haber presentado la alerta temprana de 24 horas. Si presentas la alerta temprana al final de la ventana de 24 horas, la plataforma puede marcar la notificación como fuera de plazo mientras tú sigues dentro del plazo legal. ENISA dice que una versión futura lo calculará desde la fecha de conocimiento.
- No hay contador para el informe final de una vulnerabilidad explotada activamente. El motivo que da ENISA es que el plazo depende de la fecha y la hora en que esté disponible una medida correctora o de mitigación, y eso no es una fecha hacia la que la plataforma pueda contar. Para los incidentes graves, el contador muestra un mes desde la notificación de 72 horas.
- El campo de conocimiento de una vulnerabilidad explotada todavía no está resuelto. El SRP Glossary marca "Date and time when you become aware of the Actively Exploited Vulnerability" como obligatorio en la alerta temprana de 24 horas y, en la misma fila, indica que el campo llega en la próxima versión de la plataforma. Sobre el papel es obligatorio y puede que en pantalla todavía no esté. Guarda tu propia marca de tiempo del conocimiento y prepárate para aportarla en cualquiera de los dos casos. Para los incidentes existe un campo relacionado, pero en esta versión el SRP Glossary lo llama "Date and time when the incident was detected (UTC time)", que no es lo mismo que el conocimiento.
Así que guarda la marca de tiempo del conocimiento en tu propio sistema y arranca ahí tu propio reloj. El contador de la plataforma es un recordatorio. El plazo lo fija la ley.
Qué debe contener cada notificación a la Plataforma Única de Notificación
El artículo 14 define tres fases de notificación por evento notificable. Los requisitos de contenido difieren entre el flujo de vulnerabilidad explotada activamente y el flujo de incidente grave.
Vulnerabilidad explotada activamente:
| Fase | Plazo | Contenido mínimo requerido |
|---|---|---|
| Alerta temprana | 24 h desde el conocimiento | Indicación de que una vulnerabilidad está siendo explotada activamente. Estados miembros donde el producto está disponible, si se conocen. |
| Notificación de vulnerabilidad | 72 h desde el conocimiento | Información general sobre el producto. Naturaleza general del exploit y de la vulnerabilidad. Medidas correctoras o de mitigación adoptadas. Medidas que los usuarios pueden tomar. Indicación de sensibilidad. |
| Informe final | 14 días tras disponer de una medida correctora o de mitigación | Descripción de la vulnerabilidad, incluida su gravedad e impacto. Información sobre posibles actores maliciosos que la hayan explotado, si está disponible. Detalles de la actualización de seguridad o medida correctora. |
Incidente grave con impacto en la seguridad del producto:
| Fase | Plazo | Contenido mínimo requerido |
|---|---|---|
| Alerta temprana | 24 h desde el conocimiento | Indicación de si se sospecha que el incidente fue causado por actos ilícitos o maliciosos. Estados miembros donde el producto está disponible, si se conocen. |
| Notificación del incidente | 72 h desde el conocimiento | Naturaleza del incidente. Evaluación inicial. Medidas correctoras o de mitigación adoptadas. Medidas que los usuarios pueden tomar. Indicación de sensibilidad. |
| Informe final | 1 mes tras la notificación de 72 h | Descripción detallada del incidente, incluida su gravedad e impacto. Tipo de amenaza o causa raíz que probablemente lo desencadenó. Medidas de mitigación aplicadas y en curso. |
El CSIRT designado como coordinador también puede solicitar un informe intermedio entre la notificación de 72 h y el informe final. Ninguno de los dos flujos exige identificadores CVE ni puntuaciones CVSS en la fase de alerta temprana. La obligación de 24 h es notificar, no haber completado el análisis. El detalle técnico completo va en la notificación y en el informe final.
Escalada interna: cumplir el reloj de 24 horas
El reloj de 24 horas empieza con el conocimiento, no con la confirmación. Lo difícil es pasar de "acabamos de enterarnos" a "acabamos de presentar" en menos de 24 horas, incluso fuera del horario laboral. Un proceso de triaje que "habitualmente tarda 48 horas" es estructuralmente no conforme. La detección, el triaje, la revisión legal en paralelo y la presentación deben caber en el mismo día natural, también en fin de semana y fuera de horario.
| Paso | ¿Dentro de las 24h? | Notas |
|---|---|---|
| Detección | Sí | Ingeniería interna, informes de clientes, monitorización, inteligencia de amenazas, recepción de CVD. Las rutas de triaje para "aprovechada activamente" e "incidente grave" deben ser distintas. |
| Triaje | Sí | Use las señales de puntuación de gravedad (CVSS / EPSS / KEV) como entradas. El detonante es la evidencia de explotación; la gravedad por sí sola no lo es. |
| Revisión legal | En paralelo | Una espera en serie por la aprobación legal hace perder las 24 horas. El fabricante puede señalar la sensibilidad y la plataforma puede aplazar la difusión por motivos relacionados con la ciberseguridad. |
| Alerta temprana a la Plataforma Única de Notificación | Sí | Flujo de vulnerabilidad o flujo de incidente grave. |
| Notificación de 72h | Después de 24h | En un plazo de 72 horas desde el conocimiento. |
| Informe final | 14 días (vuln.) / 1 mes (incidente) | Vulnerabilidades: 14 días desde que la medida correctora esté disponible. Incidentes graves: un mes desde la notificación de 72 horas. |
Enrutamiento al CSIRT
El enrutamiento al CSIRT sigue al establecimiento principal del fabricante en la Unión, es decir, el Estado miembro donde se adoptan de forma predominante las decisiones de ciberseguridad del producto. Si eso no puede determinarse, se usa el Estado miembro donde esté tu establecimiento en la UE con mayor número de empleados. Sin establecimiento principal en la Unión, la cadena de reserva va en este orden: el Estado miembro donde tu representante autorizado actúa por el mayor número de productos, luego el importador que introduce el mayor número en el mercado, luego el distribuidor que comercializa el mayor número y, por último, el Estado miembro con mayor número de usuarios.
La lista de CSIRT designados como coordinadores de ENISA lleva fecha de 10 de septiembre de 2026 e incluye una página de contacto por cada Estado miembro. Confirma tu coordinador contra esa lista y deja por escrito el motivo de la elección, porque ENISA ya avisa de que una notificación presentada al coordinador equivocado puede quedar invalidada y hay que volver a presentarla ante el correcto. El plazo corre desde el conocimiento, no desde un nuevo inicio, así que las horas perdidas en una segunda presentación salen de tu propio presupuesto. Tras la presentación, la difusión transfronteriza a los CSIRT de otros Estados miembros afectados se produce dentro de la plataforma.
Una notificación por evento, incluso con filiales en la UE
ENISA ha resuelto una duda que aparece en toda estructura de grupo: para una misma vulnerabilidad explotada activamente o un mismo incidente grave solo se exige una notificación, aunque el fabricante tenga varias sucursales o filiales en la UE, o una matriz fuera de ella. Coordinarse dentro de esa estructura es tarea del propio fabricante.
Lee bien el límite, porque es más estrecho de lo que a la gente le gustaría. Se trata de un fabricante con sucursales y filiales, no de una licencia para que dos fabricantes jurídicamente distintos del mismo grupo compartan una única presentación. Cuando dos entidades introducen cada una sus propios productos en el mercado, cada una carga con su propio deber.
Los dos modos de fallo merecen quedar escritos en el procedimiento. Dos filiales notifican el mismo evento y el CSIRT coordinador recibe duplicados que parecen dos fabricantes. O cada entidad da por hecho que notificó la otra y no llega nada dentro de las 24 horas. Designa la entidad que presenta y la persona que presenta antes del evento, no durante.
Plataforma Única de Notificación frente al contacto directo con el CSIRT nacional
Enviar un correo electrónico directamente a un CSIRT nacional no satisface la obligación de notificación del CRA, aunque el fabricante tenga una relación de trabajo previa con ese CSIRT.
| Canal | ¿Obligatorio para notificaciones CRA? | Qué cubre |
|---|---|---|
| Plataforma Única de Notificación | Sí | Notificaciones de vulnerabilidades explotadas activamente. Notificaciones de incidentes graves. Notificaciones de 72 h e informes finales. |
| Contacto directo con el CSIRT nacional | No | Coordinación de divulgación coordinada de vulnerabilidades. Intercambio de inteligencia de amenazas sectorial. Colaboración informal en respuesta a incidentes. |
Los fabricantes con una relación previa con un CSIRT nacional pueden mantenerla para la coordinación CVD y el intercambio de inteligencia sectorial. Lo que debe pasar por la Plataforma Única de Notificación: toda notificación obligatoria bajo el artículo 14. La plataforma gestiona automáticamente el enrutamiento transfronterizo a los CSIRT de otros Estados miembros afectados. Una sola presentación llega a todos los CSIRT relevantes.
Si no eres fabricante, la plataforma no es tu canal. Esta versión solo acepta notificaciones obligatorias del artículo 14 presentadas por fabricantes. Un investigador de seguridad, un usuario, un importador o un distribuidor que quiera comunicar una vulnerabilidad acude directamente al CSIRT nacional correspondiente. ENISA indica que una presentación de cualquier otra persona puede quedar marcada como inválida en la plataforma.
Si la plataforma está caída. La respuesta de ENISA es esperar y presentar cuando vuelva a estar disponible. Si consideras que la comunicación inmediata no puede esperar, puedes contactar mientras tanto con tu CSIRT coordinador directamente, pero la notificación tiene que pasar después por la plataforma. El contacto directo es un añadido, nunca un sustituto, y no amplía el plazo. Conserva un registro con marca de tiempo de la caída, de lo que intentaste y de cualquier contacto directo que hayas hecho.
Errores comunes
- Dar de alta EU Login y la autenticación multifactor durante el incidente. ENISA pide que no te registres en la plataforma de forma preventiva, y es razonable. Eso no significa dejar la identidad para el día del evento. Crea ahora las cuentas personales, activa el multifactor y prueba el inicio de sesión, para que el registro el mismo día sea de verdad cuestión de minutos.
- Dejar que la plataforma te diga cuál es el plazo. En esta versión, el contador de 72 horas cuenta desde tu alerta temprana más 48 horas, y puede que el campo de conocimiento de una vulnerabilidad explotada todavía no esté en pantalla aunque el glosario lo marque obligatorio. Lleva tu propio reloj.
- Que notifiquen dos filiales, o ninguna. Una notificación por evento y por fabricante, y alguien tiene que ser el responsable. Designa en el procedimiento la entidad que presenta y la persona que presenta.
- Que una sola persona tenga la única cuenta. Nombra un AR primario y al menos un AR secundario, y completa la invitación dentro de los 7 días antes de que caduque.
- Adivinar el CSIRT coordinador durante un incidente. La lista está publicada. Un coordinador equivocado puede invalidar la notificación y costarte horas que no tienes.
- Un
security@genérico con respuesta automática. Entra en conflicto con el requisito del canal orientado al usuario y no es apto como canal de autoridad de la Plataforma Única de Notificación. - Sin productos asignados al registro, o con datos obsoletos. La alerta temprana debe indicar los Estados miembros donde el producto se ha comercializado. Sin un inventario actualizado, la alerta temprana queda incompleta.
- Sin SLA interno para el reloj de 24 horas. La ruta de detección a presentación necesita un presupuesto de tiempo explícito.
- Notificar por correo electrónico al CSIRT nacional. La Plataforma Única de Notificación es el canal obligatorio. El correo a un CSIRT nacional no es equivalente.
- Tratar al representante autorizado como una dirección de reenvío. El mandato del representante autorizado de un fabricante no perteneciente a la UE debe cubrir expresamente la notificación. El representante autorizado debe estar preparado para apoyar la presentación a la plataforma.
Preguntas frecuentes
¿Está activa la Plataforma Única de Notificación?
La plataforma está en portal.cra-srp.enisa.europa.eu y está disponible desde el 11 de septiembre de 2026. ENISA publica ahora una página de estado de la plataforma, que es donde comprobarlo antes de dar por hecho que una caída es tuya. Desde la página de inicio seleccionas el rol Assigned Representative e inicias sesión con EU Login. Los deberes de notificación de los fabricantes empezaron ese mismo día; los de los administradores de comunidad de programas informáticos de código abierto empiezan el 11 de diciembre de 2027. ENISA renovó su FAQ y su guía de registro el 10 de septiembre de 2026 y su guía de la interfaz y su guía de notificación el 9 de septiembre de 2026, su SRP Glossary está en la versión 1.3, su lista de coordinadores lleva fecha de 10 de septiembre de 2026 y el 9 de septiembre de 2026 publicó un AR User Manual de 55 páginas. ENISA marca todas sus orientaciones como conocimiento disponible actualmente y sujeto a cambios, así que verifica cualquier pantalla concreta contra la orientación vigente antes de confiar en ella.
¿Se registran los importadores y distribuidores en la Plataforma Única de Notificación?
No. Los importadores y distribuidores no asumen el deber de notificación del fabricante en la Plataforma Única de Notificación. Su deber CRA es informar al fabricante de la vulnerabilidad sin demora indebida. La notificación a través de la plataforma sigue siendo obligación del fabricante.
No soy fabricante. ¿Puedo comunicar una vulnerabilidad a través de la Plataforma Única de Notificación?
No. Esta versión de la plataforma solo admite notificaciones obligatorias del artículo 14 presentadas por fabricantes. Si eres investigador de seguridad, usuario, importador o distribuidor, contacta directamente con el CSIRT nacional correspondiente. ENISA indica que una presentación de cualquier otra persona puede quedar marcada como inválida en la plataforma. Comunicar una vulnerabilidad de la plataforma misma es otra cosa distinta y va a responsible-disclosure@enisa.europa.eu.
¿Puede registrarse directamente un fabricante no perteneciente a la UE?
Es posible, pero la cadena de reserva importa. Un mandato escrito de representante autorizado puede cubrir la notificación obligatoria porque las exclusiones aplicables al representante autorizado no incluyen la propia notificación. Para un fabricante sin establecimiento principal en la Unión, el enrutamiento sigue entonces la cadena disponible: representante autorizado, importador, distribuidor y, por último, concentración de usuarios.
¿Cómo sé si debo notificar una vulnerabilidad explotada activamente o un incidente grave?
Los dos flujos cubren superficies de ataque distintas. Una vulnerabilidad explotada activamente es un fallo en tu producto que un actor malicioso está usando contra tus usuarios. Un incidente grave es aquel que puede afectar a la disponibilidad, autenticidad, integridad o confidencialidad de los datos, o a la capacidad del producto para proteger datos o funciones sensibles o importantes, o que puede dar lugar a la introducción o ejecución de código malicioso en el producto o en los sistemas de información y redes de un usuario.
Una comunicación de bug bounty o un informe de divulgación coordinada de vulnerabilidades no activa ninguno de los dos flujos por sí sola. La notificación obligatoria aplica en cuanto existe una vulnerabilidad explotada activamente o un incidente grave que cumpla la definición.
El mismo ataque puede cruzar ambos límites a la vez. Si un atacante explota un fallo en tu producto y usa ese acceso para comprometer tu infraestructura de compilación, presentas dos notificaciones separadas, una por cada flujo, ambas con una alerta temprana de 24 horas desde el mismo momento en que tomaste conocimiento.
¿En qué momento exacto empieza a correr el reloj de 24 horas?
En el momento en que cualquier miembro de tu equipo de seguridad dispone de información creíble de que está ocurriendo un evento notificable. No cuando la dirección es informada. No cuando el equipo legal lo confirma. No cuando se identifica la causa raíz.
La alerta temprana de 24 horas solo necesita incluir una indicación de que hay explotación activa y los Estados miembros donde tu producto está disponible. El análisis técnico detallado va en la notificación de 72 horas. El Reglamento lo diseñó así: primero notificas, luego investigas en paralelo.
No existe ningún periodo de gracia para la evaluación. El reloj corre desde el primer conocimiento creíble.
¿Y si nuestra presentación a la Plataforma Única de Notificación falla?
Espera a la plataforma y presenta a través de ella. ENISA dice que, si la plataforma no está disponible temporalmente, presentas cuando vuelva a estarlo. Si la comunicación inmediata no puede esperar, puedes contactar mientras tanto con tu CSIRT coordinador directamente, pero la notificación tiene que pasar después por la plataforma. Eso no amplía el plazo. Conserva un registro con marca de tiempo de la caída, del intento de presentación y de cualquier contacto directo.
¿Es el punto único de contacto para los usuarios el mismo que el contacto de registro en la Plataforma Única de Notificación?
No. El contacto de usuario y el contacto de autoridad de la plataforma sirven a públicos distintos. El contacto orientado al usuario admite notificaciones de vulnerabilidades de usuarios y no puede limitarse a herramientas automatizadas. El contacto de la plataforma debe encaminar los mensajes de ENISA y del CSIRT coordinador al equipo de notificación, aunque ENISA precise más adelante los campos exactos del registro.
¿Cuántas cuentas necesitamos en la Plataforma Única de Notificación?
Un AR primario y hasta 20 AR secundarios. Las cuentas EU Login son personales y necesitan autenticación multifactor, y la plataforma no añade un inicio de sesión corporativo, así que una cuenta de la SRP es una persona concreta y no un buzón compartido. El AR primario registra al fabricante y tiene las funciones administrativas. Los AR secundarios se incorporan desde una invitación por correo que caduca a los 7 días. Dos personas es el mínimo práctico, porque el reloj de 24 horas no se detiene por unas vacaciones.
Nuestro CSIRT coordinador todavía no nos ha validado. ¿Podemos notificar igualmente?
Sí. La validación del vínculo entre un Assigned Representative y un fabricante se hace después del primer acceso y corre en paralelo con la notificación, así que no bloquea una presentación. Un AR sin validar puede presentar hasta 20 notificaciones para un fabricante antes de que la validación pase a ser obligatoria, una cifra en la que coinciden la FAQ, la guía de la interfaz y el AR User Manual. Trátalo como una válvula de seguridad frente a una cola de validación lenta, no como holgura planificada, y termina la validación. Sí bloquea una cosa: no puedes invitar a un AR secundario hasta que esa asociación figure como Verified.
¿En qué idioma está la plataforma?
Solo en inglés en la apertura. ENISA dice que irá traduciendo la ficha informativa y el material de apoyo a todas las lenguas de la UE, y que las versiones lingüísticas de la propia plataforma se revisarán en la siguiente fase del proyecto. Si tu equipo de respuesta a incidentes trabaja en otro idioma, prepara ahora tu guía rápida de campos contra las etiquetas en inglés del SRP Glossary, en lugar de traducir nombres de campo durante un incidente.
¿Tenemos que notificar una explotación que ya conocíamos?
Solo cuando el conocimiento surge el 11 de septiembre de 2026 o después. Siguiendo la orientación de la Comisión a la que remite ENISA, un fabricante no tiene que volver atrás para notificar una explotación activa que ya conocía antes de esa fecha. Si tomas conocimiento después, el deber se aplica, aunque la vulnerabilidad de fondo sea antigua o ya conocida. El deber va unido al conocimiento de la explotación, no a la antigüedad del fallo.
¿Podemos presentar notificaciones voluntarias por la plataforma?
En la apertura no. Las notificaciones voluntarias de vulnerabilidades, ciberamenazas, incidentes e incidentes evitados están previstas para una fase posterior de la plataforma. El primer día la plataforma solo acepta las notificaciones obligatorias de vulnerabilidades explotadas activamente e incidentes graves.