Cyber Resilience Act
ENISA activa la plataforma única de notificación del CRA: el reloj de las 24 horas ya corre
18 min lectura
Imagen generada por IALos fabricantes de productos con elementos digitales ya tienen un canal europeo único para informar de vulnerabilidades explotadas activamente e incidentes graves: ENISA ha puesto en funcionamiento inicial la Single Reporting Platform (SRP) del Cyber Resilience Act (CRA). La obligación de notificar comenzó el 11 de septiembre de 2026. El resto de las exigencias principales de ciberseguridad del reglamento llegará el 11 de diciembre de 2027.
La diferencia entre ambas fechas no es un detalle de calendario. Durante más de un año, una empresa puede estar obligada a informar de determinados problemas de seguridad antes de tener que cumplir plenamente con los requisitos de diseño seguro, evaluación de conformidad y mantenimiento del producto. El CRA ha separado el deber de avisar del resto del paquete regulatorio. La plataforma de ENISA convierte esa separación en una realidad operativa.
El mecanismo pretende resolver un problema conocido: un fabricante que vende el mismo producto en varios Estados miembros no debería tener que reconstruir el mismo expediente para cada autoridad nacional. La notificación se presenta una vez ante la plataforma; el CSIRT coordinador que la recibe la distribuye a los CSIRT relevantes de los países donde el producto está disponible y ENISA obtiene acceso simultáneo a la información.
Suena sencillo. La parte difícil empieza cuando el equipo de seguridad descubre la vulnerabilidad un viernes por la tarde, el producto está desplegado en doce mercados y el departamento jurídico todavía intenta decidir si el incidente entra también en NIS2, DORA o el RGPD.
La novedad real no es el portal, sino el inicio del cómputo
La noticia de ENISA, publicada el 11 de septiembre de 2026, confirma que la SRP tiene una capacidad operativa inicial. No es todavía una declaración de que el CRA esté plenamente desplegado ni sustituye a las autoridades nacionales. Es el canal común que permite ejecutar una obligación que ya resulta aplicable a los fabricantes.
El artículo 14 del CRA establece las obligaciones de notificación de los fabricantes respecto de vulnerabilidades explotadas activamente e incidentes graves que afecten a la seguridad de productos con elementos digitales. La obligación no depende de que el fabricante haya terminado su evaluación de conformidad ni de que el producto pertenezca a una categoría crítica. El detonante es el conocimiento del hecho relevante y su conexión con un producto comercializado o puesto a disposición en el mercado de la Unión.
Para una vulnerabilidad explotada activamente, el esquema temporal previsto por el artículo 14 funciona, en términos prácticos, en tres pasos:
- En 24 horas: el fabricante debe presentar una alerta temprana desde que tiene conocimiento de la vulnerabilidad explotada.
- En 72 horas: debe remitir una notificación de vulnerabilidad con información más completa, incluyendo, cuando esté disponible, la descripción del problema y las medidas correctoras o mitigadoras.
- En 14 días: debe presentar el informe final una vez que la medida correctora esté disponible, con la información requerida sobre la vulnerabilidad y su tratamiento.
En el caso de un incidente grave que afecte a la seguridad del producto, el artículo 14 establece igualmente una alerta temprana en 24 horas y una notificación en 72 horas. El informe final debe presentarse en el plazo de un mes desde la notificación del incidente. Estos plazos no son objetivos internos recomendables: son ventanas regulatorias que obligan a tener un proceso de decisión preparado antes de que ocurra el incidente.
Aquí está el quid. El reloj no empieza cuando el comité de crisis consigue una imagen completa. Empieza cuando el fabricante tiene conocimiento de la vulnerabilidad explotada o del incidente grave. Esperar a conocer todos los indicadores técnicos puede ser una buena práctica forense, pero no justifica automáticamente dejar pasar la primera ventana de 24 horas.
Qué cambia para fabricantes y desarrolladores
El CRA aplica a productos con elementos digitales, una categoría deliberadamente amplia que incluye tanto hardware conectado como software y componentes destinados a conectarse directa o indirectamente a un dispositivo o red. La pregunta operativa no es solo si una empresa fabrica un router, un sistema operativo o un dispositivo IoT. También hay que determinar si desarrolla o comercializa una librería, un agente, un componente integrado o un servicio que forma parte de un producto sujeto al reglamento.
El fabricante no puede tratar la SRP como una tarea exclusiva del equipo de vulnerabilidades. Una notificación requiere decisiones sobre alcance de producto, mercados afectados, versiones, explotación conocida, impacto en la seguridad y medidas de respuesta. Es una intersección entre seguridad de producto, ingeniería, gestión de incidentes, asuntos regulatorios, comunicación y, en algunos casos, protección de datos.
El artículo 14 pone el foco en dos tipos de hechos que conviene separar desde el principio:
Vulnerabilidad explotada activamente
Una vulnerabilidad no se convierte en notificable solo porque tenga una puntuación CVSS elevada o aparezca en una base de datos pública. El criterio relevante es que esté siendo explotada activamente. Eso exige una valoración de inteligencia de amenazas y evidencias técnicas: telemetría, indicadores de compromiso, informes de investigadores, actividad observada en clientes o avisos de un CSIRT.
La ausencia de un CVE tampoco elimina necesariamente el problema. El fabricante puede descubrir una explotación antes de que exista una identificación pública o una entrada en la base de datos correspondiente. El proceso debe poder registrar la vulnerabilidad con un identificador interno, describir el producto y actualizar la notificación posteriormente. Esperar a que todo tenga nombre oficial sería una forma bastante eficaz de incumplir el plazo de 24 horas.
Incidente grave
El segundo supuesto es el incidente grave que afecta a la seguridad del producto. La evaluación no debería confundirse con la mera indisponibilidad de un servicio corporativo. La empresa necesita analizar si el incidente compromete propiedades como la confidencialidad, integridad o disponibilidad del producto, si puede afectar a usuarios y si tiene una dimensión relevante para la seguridad.
La clasificación debe estar documentada. No porque el CRA exija una novela forense en las primeras 24 horas, sino porque una decisión de no notificar tendrá que poder explicarse después. El expediente debería conservar la fecha y hora de detección, la fuente de conocimiento, los productos y versiones afectados, la evidencia de explotación o impacto, el análisis de severidad, los responsables que aprobaron la clasificación y la justificación de cualquier decisión de no presentar una notificación.
Una plataforma, varias autoridades y menos excusas administrativas
La SRP introduce un modelo de distribución coordinada. El fabricante presenta la información una vez y el CSIRT designado como coordinador la comparte con otros CSIRT de los Estados miembros donde el producto afectado está disponible. ENISA recibe la notificación al mismo tiempo y puede utilizar la información para mejorar la visión europea sobre vulnerabilidades e incidentes.
El beneficio inmediato es evidente: se elimina la obligación práctica de duplicar envíos nacionales con formatos diferentes. Pero la plataforma no elimina la responsabilidad de saber qué producto se vende dónde. Para que la distribución funcione, el fabricante debe aportar datos fiables sobre presencia geográfica, versiones, clientes o canales de comercialización afectados. Un inventario comercial incompleto puede producir dos errores opuestos: dejar fuera a una autoridad que debería recibir la información o generar notificaciones innecesarias en países donde el producto nunca estuvo disponible.
Tampoco significa que ENISA se convierta en la única autoridad supervisora de todos los fabricantes. La Agencia opera y mantiene el sistema; los CSIRT nacionales reciben, coordinan y actúan sobre las notificaciones dentro de sus competencias. La SRP es una infraestructura de comunicación, no un salvoconducto frente a la supervisión nacional.
El lanzamiento también plantea una cuestión de confidencialidad. Los informes de vulnerabilidades explotadas contienen información que, si se divulga antes de que exista un parche, puede ayudar a los atacantes. ENISA afirma que la plataforma incorpora medidas para proteger la confidencialidad de la información enviada. Eso no libera al fabricante de aplicar su propio control de acceso, clasificación de la información y disciplina de divulgación coordinada.
El error más probable: confundir el CRA con NIS2, DORA o el RGPD
Una misma intrusión puede activar varias obligaciones. El hecho de que la empresa presente una notificación en la SRP no significa que haya cumplido automáticamente con todos los demás regímenes aplicables.
Una empresa tecnológica que presta servicios a bancos puede quedar afectada por el CRA como fabricante y, a la vez, formar parte de la cadena de terceros TIC de entidades financieras sujetas a DORA. El artículo 28 de DORA exige a las entidades financieras gestionar el riesgo asociado a terceros TIC y mantener un registro de información sobre sus acuerdos contractuales. Si el proveedor sufre un incidente que afecta a un producto desplegado por un banco, la notificación al SRP no sustituye necesariamente a la comunicación contractual o regulatoria que deba hacer el cliente financiero.
En el caso de una entidad incluida en NIS2, el artículo 21 exige medidas de gestión del riesgo de ciberseguridad, mientras que el artículo 23 regula la notificación de incidentes significativos. La autoridad o el CSIRT competente puede necesitar información distinta y aplicar plazos diferentes. El mismo hecho técnico puede tener un expediente CRA centrado en el producto, otro bajo NIS2 centrado en la entidad esencial o importante y un tercero contractual bajo DORA.
El RGPD añade una capa distinta. Si el incidente implica datos personales, el artículo 33 exige notificar a la autoridad de protección de datos, cuando proceda, sin dilación indebida y, como máximo, en 72 horas desde que el responsable tenga constancia de la violación de seguridad. El artículo 34 puede exigir comunicación a las personas afectadas cuando exista un alto riesgo para sus derechos y libertades. Una notificación a ENISA no reemplaza ninguna de esas obligaciones.
El problema no se resuelve creando cuatro equipos que trabajen en paralelo sin hablarse. Hace falta un árbol de clasificación común que identifique: qué ocurrió, qué producto está afectado, qué entidad sufrió el impacto, qué datos están comprometidos, qué países están implicados y qué reloj regulatorio se ha activado. La SRP reduce la duplicación del canal; no reduce la complejidad jurídica del incidente.
La separación temporal del CRA obliga a trabajar en dos velocidades
Desde el 11 de septiembre de 2026, los fabricantes deben cumplir las obligaciones de notificación. Las obligaciones principales de ciberseguridad del CRA serán aplicables desde el 11 de diciembre de 2027. Esta entrada escalonada permite a las empresas organizar dos líneas de trabajo distintas.
La primera es inmediata y reactiva: detectar, clasificar y notificar. La segunda es estructural: construir productos que cumplan los requisitos de ciberseguridad durante todo su ciclo de vida. El reglamento no pretende limitarse a la gestión de incidentes después de la venta. Su lógica alcanza el diseño, desarrollo, producción, mantenimiento y soporte del producto, con obligaciones que afectan a la evaluación de riesgos y a la gestión de vulnerabilidades.
Una organización puede tener un excelente programa de respuesta y, aun así, no estar preparada para el CRA si no sabe qué versiones siguen soportadas, quién aprueba un parche, qué componentes de código abierto se incorporaron al producto o cuánto tarda en publicar una actualización. La obligación de notificar es el primer examen público de ese sistema interno.
El 11 de diciembre de 2027 será la fecha general de aplicación de los requisitos principales del CRA, pero no conviene leerla como una licencia para posponer todo hasta el último trimestre de 2027. Los productos que entren en determinadas categorías pueden estar sujetos a requisitos adicionales de evaluación de conformidad y a la intervención de organismos notificados. Además, los contratos con distribuidores, integradores y clientes institucionales suelen exigir evidencias de seguridad antes de que exista una obligación regulatoria plenamente aplicable.
Hay una peculiaridad que merece vigilancia: ENISA indica que las obligaciones de notificación también alcanzarán a los responsables de software de código abierto en la medida prevista por el artículo 24, apartado 3, del CRA, y que para ellos esa disposición será aplicable el 11 de diciembre de 2027. No todo proyecto abierto es automáticamente un fabricante ni todo mantenedor comunitario es un steward sujeto al mismo régimen. La clasificación dependerá de su papel, de la naturaleza de la actividad y de si el software se desarrolla o mantiene con finalidad comercial o dentro de una actividad profesional relevante.
Para las empresas que integran componentes open source en productos comerciales, la conclusión práctica es menos ambigua: no pueden externalizar por completo la gestión de vulnerabilidades al repositorio del que descargaron el componente. Deben conocer dependencias, versiones, responsables de mantenimiento y rutas para escalar una vulnerabilidad. Un SBOM ayuda, pero una lista de componentes sin un proceso de respuesta es solo un inventario con buena prensa.
Qué debe estar resuelto antes de la primera notificación
El primer control no es técnico. Es un mapa de responsabilidades. La empresa debe designar quién puede declarar que existe una vulnerabilidad explotada, quién decide que un incidente es grave, quién rellena la notificación y quién valida el contenido. Si todas esas decisiones requieren convocar a un comité que solo se reúne durante horario laboral, el proceso no está preparado para una obligación de 24 horas.
El segundo control es un inventario de productos y versiones. Debe relacionar cada producto con su fabricante legal, propietario técnico, repositorios de código, componentes de terceros, mercados de comercialización, ciclo de soporte y canal de actualización. La SRP no puede corregir un inventario corporativo que ya era incorrecto.
El tercero es la integración entre detección y cumplimiento. El sistema de gestión de vulnerabilidades debería capturar como mínimo la fecha de conocimiento, la fuente de la alerta, la evidencia de explotación, el producto afectado, el nivel de confianza, el estado del parche y la fecha límite de cada notificación. Conviene que esos datos puedan exportarse para preparar tanto el expediente del CRA como las comunicaciones bajo NIS2, DORA, RGPD o los contratos de cliente.
El cuarto control es un procedimiento de notificación incremental. La primera comunicación no necesita contener la investigación completa, pero sí debe ser útil. El procedimiento tiene que permitir enviar la alerta temprana con la información disponible, actualizarla en 72 horas y completar el informe final cuando la medida correctora esté lista. Un formulario interno que exige cerrar todos los campos antes de enviarse empuja a la organización hacia el incumplimiento.
El quinto es una prueba. La empresa debería simular una vulnerabilidad explotada con un producto comercializado en varios Estados miembros y medir cuánto tarda en responder a cinco preguntas: cuándo se enteró, quién lo supo primero, qué productos están afectados, qué autoridad recibe la información y qué comunicación debe salir por otros canales. Si el ejercicio termina con una discusión semántica sobre quién es el fabricante legal, el problema no está en ENISA.
La información que conviene preparar para la SRP
ENISA ha publicado materiales de apoyo que incluyen preguntas frecuentes, manuales de usuario, vídeos tutoriales, un glosario y una ficha informativa en varias lenguas de la Unión. También mantiene un servicio de ayuda para cuestiones que no queden cubiertas en las guías. La existencia de recursos no convierte el proceso en automático: cada fabricante debe transformar esa documentación en datos disponibles dentro de su propio sistema.
Antes de necesitar la plataforma, conviene tener preparados al menos estos bloques de información:
- Identificación del fabricante: entidad jurídica, datos de contacto y responsable operativo para la notificación.
- Identificación del producto: nombre comercial, versiones, identificadores técnicos, componentes afectados y mercados donde está disponible.
- Descripción del problema: vulnerabilidad o incidente, condiciones de explotación, productos afectados y nivel de confianza de la evidencia.
- Impacto: propiedades de seguridad comprometidas, usuarios potencialmente afectados y consecuencias conocidas.
- Respuesta: medidas de mitigación, parche previsto, instrucciones para clientes y calendario de actualizaciones.
- Coordinación: interlocutores internos, CSIRT nacionales ya contactados y referencias de otras notificaciones relacionadas.
La lista no sustituye al formulario oficial ni debe confundirse con una reproducción exhaustiva de sus campos. Su valor está en revelar una realidad incómoda: los datos regulatorios viven en sistemas diferentes. La identificación legal puede estar en compras, la geografía en ventas, las versiones en ingeniería y la evidencia de explotación en el SOC. El tiempo se pierde al ensamblar esa información, no al escribir tres párrafos en un portal web.
La confidencialidad no debe convertirse en silencio
Los fabricantes suelen temer que notificar demasiado pronto exponga información sensible, provoque alarma entre clientes o afecte a una investigación. Ese riesgo es legítimo. Pero el CRA no parece diseñado para esperar a que el fabricante tenga una comunicación pública perfecta. El modelo de alerta temprana y actualización posterior asume que la primera información será incompleta.
La respuesta correcta es separar canales y niveles de detalle. La notificación a la autoridad debe contener información suficiente para que los CSIRT puedan coordinarse y valorar el riesgo. La comunicación a clientes puede centrarse inicialmente en mitigaciones verificadas. La divulgación pública puede seguir una estrategia de publicación coordinada con investigadores, proveedores afectados y autoridades.
También hay que controlar el acceso interno. Una notificación puede incluir detalles de explotación, indicadores de compromiso, arquitectura de producto o información de clientes. La empresa debería limitar quién puede ver el expediente, registrar accesos y definir qué documentos pueden circular por correo electrónico. El artículo 32 del RGPD, cuando resulte aplicable por tratarse de datos personales, exige medidas técnicas y organizativas apropiadas; pero incluso fuera del RGPD, la protección de la información de vulnerabilidades es una condición básica para no convertir el mecanismo de reporte en una nueva superficie de riesgo.
La prueba para los fabricantes pequeños
Las grandes empresas pueden asignar equipos de producto, SOC, asuntos regulatorios y respuesta a incidentes. Las pymes no siempre disponen de esa estructura. El CRA no desaparece porque la organización tenga veinte empleados, aunque la evaluación de sus obligaciones y la forma de demostrar el cumplimiento deban ser proporcionales al producto y a sus riesgos.
Para una empresa pequeña, la prioridad no es comprar una plataforma gigantesca. Es establecer cuatro activos sencillos: un inventario de productos y versiones, un contacto de emergencia, un procedimiento de clasificación y un registro de decisiones. El fabricante debe saber quién recibe una alerta fuera del horario habitual y qué proveedor externo puede ayudar a validar la explotación o preparar un parche.
El reto más serio puede estar en la dependencia de proveedores. Un fabricante que incorpora una biblioteca de terceros necesita una vía contractual o técnica para enterarse rápidamente de una vulnerabilidad. Las cláusulas de seguridad que solo exigen “cumplir la normativa aplicable” no garantizan una alerta en horas. Los contratos deben concretar canales de notificación, tiempos de respuesta, disponibilidad de información sobre componentes y cooperación durante la investigación.
ENISA señala que seguirá mejorando las funcionalidades de la SRP a partir de la experiencia operativa y de las necesidades de los usuarios. Eso significa que el sistema evolucionará. Las empresas deberían probarlo pronto, consultar las guías y registrar las dificultades encontradas, en lugar de esperar a que una crisis real sea su primer test de usabilidad.
Qué observar durante los próximos meses
El lanzamiento de la capacidad operativa inicial abre varias cuestiones que todavía tendrán que resolverse en la práctica. La primera es cómo interpretarán los CSIRT nacionales los umbrales de explotación activa y gravedad. La segunda es cómo se coordinarán las notificaciones cuando un producto se distribuya a través de fabricantes originales, integradores y marcas blancas. La tercera es cómo se gestionarán las actualizaciones sucesivas de una notificación sin generar versiones contradictorias entre autoridades.
También será relevante observar la relación entre la SRP y los canales que ya utilizan los fabricantes para informar de vulnerabilidades, como los equipos de respuesta de proveedores, los programas de divulgación coordinada y los CSIRT sectoriales. La existencia de un canal europeo único no impide que siga siendo necesario colaborar con la organización que mantiene un componente vulnerable o con el proveedor de infraestructura afectado.
La Comisión Europea ha publicado orientación específica sobre las obligaciones de notificación del CRA, incluida la sección 9.1 de su guía de implementación y la sección 5 de sus preguntas frecuentes. Esas fuentes deberían leerse junto con el texto del Reglamento (UE) 2024/2847 y con las instrucciones operativas de ENISA. La guía ayuda a interpretar; no reemplaza el análisis del producto concreto ni convierte todos los casos límite en casos fáciles.
El veredicto: una mejora necesaria, no una amnistía regulatoria
La SRP es una mejora práctica porque reduce la fragmentación del reporte y permite que la información llegue de forma coordinada a los CSIRT relevantes y a ENISA. Su valor crecerá si las notificaciones son suficientemente tempranas, precisas y accionables. Un portal único puede eliminar cinco formularios duplicados; no puede detectar una vulnerabilidad, decidir su gravedad ni inventar un inventario de productos que la empresa nunca mantuvo.
Desde el 11 de septiembre de 2026, los fabricantes tienen que tratar la notificación como una capacidad operativa permanente. El primer objetivo no debería ser redactar el informe perfecto, sino llegar a tiempo con información fiable y actualizarla de forma disciplinada. El segundo es evitar que el proceso del CRA quede aislado de NIS2, DORA y el RGPD cuando el mismo incidente active obligaciones simultáneas.
La fecha del 11 de diciembre de 2027 sigue siendo crucial, pero no es la fecha de inicio de la preparación. Para entonces, los fabricantes deberán demostrar que el ciclo completo —diseño, desarrollo, mantenimiento, gestión de vulnerabilidades y respuesta— funciona como un sistema. La plataforma de ENISA acaba de poner el primer cronómetro encima de la mesa. A partir de ahora, la pregunta incómoda para cada fabricante es muy concreta: si mañana aparece explotación activa en uno de sus productos, ¿puede notificar en 24 horas sin empezar por averiguar qué vende y quién tiene autoridad para hablar?