Cyber Resilience Act
ENISA activa el tutorial de la plataforma única de reporte del Cyber Resilience Act
17 min lectura
Imagen generada por IAEl reloj regulatorio del Cyber Resilience Act ya no es una abstracción jurídica. Desde el 11 de septiembre de 2026, los fabricantes de productos con elementos digitales deben utilizar la Single Reporting Platform (SRP) de ENISA para comunicar determinadas vulnerabilidades explotadas e incidentes graves. La agencia europea acaba de publicar un tutorial en vídeo que explica, paso a paso, cómo registrarse y presentar esas notificaciones.
Puede parecer una ayuda de usabilidad. No lo es solamente. En un régimen donde el primer aviso debe llegar en un plazo de 24 horas desde que el fabricante tiene conocimiento de una vulnerabilidad explotada o de un incidente grave, saber dónde hacer clic forma parte del control regulatorio. La burocracia también tiene superficies de ataque.
La página de ENISA no presenta un nuevo requisito legal ni cambia los plazos del Reglamento (UE) 2024/2847. Su función es más concreta: familiarizar a los usuarios autorizados con el canal que centralizará las comunicaciones previstas en el CRA. La plataforma ha entrado en su capacidad operativa inicial el 11 de septiembre de 2026, la misma fecha en la que comienzan a aplicarse las obligaciones de reporte del artículo 14.
Para los fabricantes, el mensaje es incómodo pero sencillo: ya no basta con tener un procedimiento interno de gestión de vulnerabilidades. Hay que demostrar que la organización puede transformar una señal técnica en una notificación regulatoria completa, dentro del plazo y a través del canal correcto.
Qué ha puesto en marcha ENISA
ENISA describe la SRP como la herramienta en línea que permite a los fabricantes y, cuando resulte aplicable, a los responsables de software de código abierto cumplir sus obligaciones de notificación bajo el Cyber Resilience Act. La agencia ha publicado varios materiales de apoyo alrededor de la plataforma: preguntas frecuentes, guía de registro de usuarios autorizados, instrucciones para enviar y actualizar notificaciones, explicación de las funciones de la interfaz, orientación sobre circunstancias excepcionales y un manual de usuario.
El nuevo vídeo tutorial se suma a ese conjunto. No sustituye al Reglamento ni a las futuras orientaciones de las autoridades, pero cubre una parte que suele fallar en los primeros días de cualquier sistema regulatorio: la operación concreta. ¿Quién puede acceder? ¿Cómo se inicia un reporte? ¿Qué información puede modificarse? ¿Cómo se gestiona una notificación cuando todavía no se conocen todos los datos? En un incidente real, esas preguntas no se resuelven con una lectura genérica del CRA.
El lanzamiento de la plataforma fue anunciado por ENISA el 11 de septiembre de 2026. La agencia ha identificado además los CSIRT designados como coordinadores, una pieza esencial porque el reporte no queda aislado en un buzón europeo. La arquitectura conecta la notificación con los actores nacionales competentes y con ENISA, de acuerdo con el sistema previsto por el Reglamento.
La página de ENISA no ofrece en el material publicado una estadística sobre el número de fabricantes registrados, el volumen de avisos recibidos o el rendimiento de la plataforma. Conviene no inventar una historia de éxito con métricas que todavía no se han comunicado. Lo que sí puede afirmarse es que el canal ya existe y que la fecha de activación coincide con el inicio de una obligación jurídicamente exigible.
El artículo 14 cambia la gestión de vulnerabilidades
El centro de gravedad está en el artículo 14 del Reglamento (UE) 2024/2847. Este precepto obliga a los fabricantes a notificar a ENISA, a través de la plataforma única, las vulnerabilidades explotadas activamente que estén contenidas en productos con elementos digitales. También exige comunicar los incidentes graves que afecten a la seguridad de esos productos.
La palabra decisiva es “explotada”. El CRA no convierte cada vulnerabilidad descubierta en un aviso inmediato a ENISA. Una debilidad encontrada durante una auditoría interna, un test de penetración o una revisión de código puede activar obligaciones de corrección, documentación y comunicación con clientes, pero no necesariamente el reporte urgente del artículo 14. El umbral de notificación rápida se vincula a la explotación activa o a un incidente grave.
La distinción no elimina la dificultad. En las primeras horas de un incidente, el fabricante puede no saber si una vulnerabilidad ha sido realmente explotada, si el ataque ha afectado a un producto concreto o si el impacto alcanza el umbral de gravedad. Esperar a tener una autopsia perfecta puede ser incompatible con el plazo legal. El procedimiento debe permitir notificar con información inicial, actualizarla después y mantener una trazabilidad clara de lo que se sabía en cada momento.
El artículo 14 establece una secuencia de comunicaciones. Para una vulnerabilidad explotada activamente, el fabricante debe remitir una alerta temprana dentro de las 24 horas siguientes a tener conocimiento de ella. La notificación principal debe llegar dentro de las 72 horas. Después, el fabricante debe presentar un informe final dentro de los 14 días siguientes a la disponibilidad de una medida correctora, según la estructura temporal prevista por el Reglamento.
Para un incidente grave relacionado con la seguridad de un producto, el esquema también comienza con una alerta temprana en 24 horas y una notificación en 72 horas. El informe final se presenta dentro de un mes desde la notificación. Estas ventanas no son objetivos internos de un equipo de respuesta. Son plazos regulatorios y deben estar integrados en la gestión de incidentes desde el primer minuto.
Hay una consecuencia práctica que muchas organizaciones pasan por alto: el plazo no empieza cuando se reúne el comité de crisis ni cuando el departamento jurídico valida el comunicado. Empieza cuando el fabricante tiene conocimiento de la vulnerabilidad explotada o del incidente grave. Por eso es necesario definir qué evento constituye conocimiento organizativo y cómo se registra su hora exacta.
La plataforma no arregla un proceso de reporte mal diseñado
Una interfaz nueva no corrige una gobernanza vieja. Si el equipo de producto recibe las alertas, el SOC observa los indicadores de compromiso, el CISO coordina la respuesta y legal decide cuándo existe una obligación de comunicar, la organización necesita una regla inequívoca para poner en marcha el cronómetro.
El primer problema es la clasificación. Una empresa puede recibir un aviso de un investigador, detectar explotación en telemetría, conocer una campaña de ransomware que afecta a sus clientes o encontrar un fallo durante una revisión de código. No todos esos eventos tienen el mismo tratamiento bajo el artículo 14. El procedimiento debe separar, como mínimo, cuatro categorías: vulnerabilidad no explotada, vulnerabilidad explotada activamente, incidente de seguridad potencialmente grave e incidente que no alcanza ese umbral.
El segundo problema es la propiedad del reporte. El responsable técnico puede tener la información más rápida, pero no necesariamente la autoridad para representar al fabricante ante ENISA. El responsable regulatorio puede controlar el canal, pero no disponer de datos suficientes para describir el producto afectado. La respuesta eficaz necesita una pareja estable: un propietario del contenido técnico y un usuario autorizado para presentar, actualizar y cerrar la notificación.
El tercer problema es la evidencia temporal. Las organizaciones suelen conservar tickets, mensajes de Teams, alertas del SIEM y correos, pero rara vez los alinean para demostrar cuándo supieron qué. La SRP puede registrar la hora de envío, pero no reconstruirá por sí sola cuándo el fabricante tuvo conocimiento del hecho. Esa evidencia seguirá estando en los sistemas internos.
El tutorial de ENISA debe leerse, por tanto, como una prueba de preparación. Un equipo debería ser capaz de completar un ejercicio en el que una vulnerabilidad pasa de la detección técnica al envío de la alerta inicial sin improvisar usuarios, permisos, traducciones, clasificación de productos o aprobación ejecutiva.
Qué información tendrá que coordinar el fabricante
El Reglamento exige que las notificaciones sean útiles para las autoridades y para la coordinación europea. Eso obliga a reunir información que suele estar fragmentada entre ingeniería, seguridad, soporte y gestión de producto.
La organización tendrá que identificar con precisión el producto afectado, su versión, el componente vulnerable y la naturaleza del problema. También tendrá que describir, en la medida conocida, la explotación o el incidente, los posibles efectos sobre la confidencialidad, integridad o disponibilidad, las medidas de mitigación y el calendario de corrección. Un nombre comercial ambiguo no ayuda a un CSIRT que intenta determinar si otros productos o proveedores están expuestos.
La calidad del inventario de productos pasa a ser un control regulatorio. Si el fabricante no mantiene una correspondencia fiable entre nombres comerciales, identificadores internos, versiones, componentes de terceros y productos derivados, la notificación se convierte en una operación manual bajo presión. El dato que falta en el catálogo acaba faltando en el reporte.
La dependencia de componentes de código abierto añade otra capa. El CRA distribuye responsabilidades de forma distinta según el papel del actor y la naturaleza del producto. Un fabricante que integra una biblioteca de terceros no puede trasladar automáticamente su responsabilidad al mantenedor de esa biblioteca. La cadena de suministro puede aportar información, pero el fabricante del producto final debe saber qué utiliza, dónde lo utiliza y cómo corregirlo.
El mismo criterio se aplica a los proveedores de servicios de seguridad, plataformas cloud y herramientas de observabilidad. Que el incidente se detecte en un proveedor no significa que el fabricante deje de tener que evaluar el impacto sobre su producto. La SRP recibe el reporte; no decide por la empresa qué producto está afectado ni quién tiene el deber de comunicar.
La relación con NIS2, GDPR y otros canales de notificación
El reporte bajo el CRA no sustituye automáticamente otras obligaciones. Una misma intrusión puede activar varios regímenes, con distintos sujetos obligados, destinatarios y plazos. La peor respuesta sería crear un formulario por reglamento y esperar que alguien los rellene durante la crisis.
La Directiva NIS2, transpuesta mediante las normas nacionales correspondientes, establece para las entidades esenciales e importantes un sistema de alerta temprana en 24 horas y una notificación de incidente en 72 horas, con un informe final posterior. El parecido temporal con el artículo 14 del CRA no significa que ambos regímenes sean idénticos. NIS2 se centra en la entidad y en los incidentes que afectan a sus servicios; el CRA se centra en fabricantes, productos con elementos digitales, vulnerabilidades explotadas e incidentes graves relacionados con esos productos.
Una empresa puede ser simultáneamente fabricante sujeto al CRA y entidad esencial o importante bajo NIS2. En ese caso, debe mapear qué hechos se notifican, a qué autoridad, mediante qué plataforma y con qué información. Un único incidente puede requerir dos comunicaciones coordinadas, no una comunicación universal que mágicamente satisfaga todos los requisitos.
El Reglamento General de Protección de Datos añade otra posible vía. Si un incidente de seguridad provoca una violación de datos personales, el responsable del tratamiento debe valorar la notificación a la autoridad de control dentro de las 72 horas desde que tiene conocimiento de la violación, conforme al artículo 33 del GDPR. El plazo se parece al del CRA, pero el hecho desencadenante es diferente: en GDPR importa la violación de datos personales; en CRA, la vulnerabilidad explotada o el incidente grave relacionado con el producto.
Esta coincidencia de plazos puede generar una falsa sensación de simplicidad. Un equipo puede creer que enviar un aviso a ENISA resuelve el problema de privacidad o que comunicar a la autoridad de protección de datos cubre el CRA. No es así. La coordinación debe estar diseñada antes del incidente, con una matriz que relacione evento, producto, entidad afectada, datos personales, autoridad competente y fecha límite.
Para el sector financiero, DORA introduce otra posible obligación de notificación cuando una entidad financiera sufre un incidente relacionado con las tecnologías de la información y la comunicación. DORA opera sobre la entidad financiera y sus incidentes TIC; el CRA opera sobre los productos con elementos digitales y sus fabricantes. Un banco que utiliza un producto vulnerable puede tener deberes propios bajo DORA, mientras que el proveedor de ese producto puede tener los suyos bajo el CRA. El contrato no borra esa diferencia.
El reto que no aparece en el vídeo: quién puede reportar
Los materiales de ENISA incluyen una guía específica para el registro de usuarios autorizados. No es un detalle administrativo. La gestión de identidades será una parte crítica del control.
El fabricante debe decidir qué perfiles pueden acceder a la SRP, quién puede iniciar una notificación, quién puede modificarla y quién tiene capacidad para representar oficialmente a la organización. El principio de mínimo privilegio resulta tan aplicable aquí como en un sistema de producción: demasiados usuarios aumentan el riesgo de errores o accesos indebidos; demasiado pocos pueden bloquear la respuesta a las tres de la mañana.
La organización debería mantener al menos un titular y un sustituto para la función de reporte, con cobertura de vacaciones, rotaciones y cambios de empleo. También necesita un procedimiento para revocar accesos cuando un empleado abandona la empresa o cambia de función. Una cuenta de antiguo responsable de cumplimiento que conserva capacidad de notificar ante ENISA no es una rareza teórica; es un fallo básico de ciclo de vida de identidades.
La segregación de funciones merece una decisión expresa. Puede ser razonable que una misma persona prepare y envíe una alerta inicial cuando corren 24 horas, pero las notificaciones posteriores pueden requerir revisión técnica, jurídica o ejecutiva. Lo que no funciona es exigir cuatro aprobaciones para la primera alerta y descubrir después que el proceso incumple el plazo.
También conviene documentar la delegación cuando el fabricante forma parte de un grupo internacional. La filial que comercializa el producto, la matriz que desarrolla el código y el centro global de operaciones pueden tener responsabilidades distintas. La SRP no debería convertirse en el lugar donde se resuelve, por primera vez, una disputa sobre quién representa al fabricante.
Qué debería probar ahora un CISO o un responsable de compliance
La prueba más útil no es leer el tutorial de principio a fin. Es reproducir el proceso con un caso simulado y medir dónde se rompe.
Primero, hay que comprobar que el inventario de productos identifica las versiones desplegadas y los componentes críticos. El ejercicio debe usar un producto real o una familia de productos real, no un activo ficticio que nadie tendrá que localizar durante una crisis.
Después, el equipo debe simular la detección de una vulnerabilidad explotada. Hay que registrar la hora de la primera alerta, determinar quién toma la decisión de que existe conocimiento suficiente, asignar el usuario autorizado y preparar la información mínima para la alerta temprana. El objetivo no es escribir el informe final en 24 horas. Es demostrar que la organización puede iniciar correctamente el flujo y enriquecerlo después.
El tercer paso consiste en comprobar la actualización de una notificación. ENISA ofrece una guía específica sobre el envío y la actualización de reportes; el proceso interno debe indicar quién puede corregir datos, cómo se conserva el historial y qué cambios requieren una nueva revisión. Un reporte que no se actualiza cuando aparece información relevante puede ser tan problemático como uno enviado tarde.
El cuarto paso es ensayar una circunstancia excepcional. La documentación de ENISA incluye orientación sobre Particular Exceptional Circumstances, lo que indica que el sistema contempla situaciones en las que el reporte ordinario puede verse afectado por circunstancias concretas. La empresa no debería tratar esa vía como una extensión automática del plazo. Debe conocer qué hechos la justifican, qué evidencia se conserva y quién decide invocarla.
Por último, el ejercicio debe terminar con una revisión de evidencias: registros de acceso, hora de detección, decisión de clasificación, contenido enviado, aprobaciones, actualizaciones y medidas correctoras. La pregunta no es solo “¿enviamos el formulario?”. La pregunta seria es “¿podemos demostrar por qué lo enviamos así y cuándo supimos cada cosa?”.
La fecha de 2027 no es una excusa para esperar
El CRA tiene varias fechas de aplicación y esa fragmentación puede inducir a error. Las obligaciones de reporte del artículo 14 comienzan el 11 de septiembre de 2026. La aplicación general del Reglamento llega el 11 de diciembre de 2027, mientras que las obligaciones principales para los productos comercializados bajo el régimen también se sitúan en esa fecha, según el calendario del Reglamento.
Esperar a diciembre de 2027 para preparar los reportes sería confundir dos relojes distintos. La obligación operativa de notificación ya está activa. Además, los procesos que se necesitan para notificar —inventario, clasificación, gestión de vulnerabilidades, identidad, coordinación con CSIRT y trazabilidad— no se construyen con una circular interna enviada la víspera.
La entrada progresiva del CRA tiene una lógica: permite que el canal de reporte y la coordinación institucional empiecen antes de que todo el régimen de requisitos de producto alcance su aplicación general. Para los fabricantes, eso significa que 2026 es el año en el que deben probar la respuesta, no el año en el que pueden limitarse a leer sobre ella.
La plataforma inicial también debe entenderse como una capacidad en evolución. ENISA ha publicado el canal, el tutorial y materiales operativos; la experiencia de los primeros usuarios puede traducirse en preguntas frecuentes actualizadas, ajustes de interfaz o aclaraciones adicionales. Las organizaciones deberían conservar una copia controlada de sus procedimientos y revisar periódicamente las instrucciones oficiales, en lugar de tratar el vídeo como un documento inmutable.
El riesgo de convertir el reporte en un trámite
El error más probable no será que un fabricante ignore por completo la SRP. Será que la utilice como una ventanilla administrativa desconectada de la gestión técnica.
El objetivo del artículo 14 no es alimentar una base de datos europea con formularios. La información debe permitir coordinar la respuesta a vulnerabilidades explotadas e incidentes graves que pueden afectar a múltiples productos, fabricantes y usuarios. Un reporte incompleto, tardío o impreciso reduce el valor de esa coordinación.
Eso tiene consecuencias para los equipos de seguridad. La gestión de vulnerabilidades deberá incorporar una dimensión regulatoria: no bastará con puntuar una vulnerabilidad por CVSS, decidir una prioridad y abrir un ticket. Habrá que evaluar si existe explotación activa, si afecta a un producto sujeto al CRA y si la situación activa el plazo de 24 horas. CVSS puede ayudar a valorar severidad, pero no sustituye el análisis jurídico del evento desencadenante.
También cambia la relación entre seguridad y producto. Corregir una vulnerabilidad no termina con publicar un parche. El fabricante debe poder identificar cuándo la medida correctora está disponible, porque esa fecha puede activar el plazo del informe final de 14 días para una vulnerabilidad explotada activamente. El equipo que publica la actualización y el equipo que gestiona el reporte deben compartir una definición operativa de “medida correctora disponible”.
En los incidentes graves, el horizonte del informe final es de un mes desde la notificación. Ese plazo ofrece más margen que las primeras 24 o 72 horas, pero no permite archivar el caso y volver a la rutina. La empresa debe mantener una línea de investigación, documentar las medidas adoptadas y preparar una explicación que pueda sostenerse ante autoridades, clientes y socios de la cadena de suministro.
Qué significa realmente el tutorial para las empresas
El vídeo de ENISA no es una noticia espectacular y no pretende serlo. Es una pieza operativa publicada en el momento correcto: la SRP ya está desplegada y las obligaciones de reporte del CRA ya han empezado a aplicarse. Su valor está en convertir una plataforma desconocida en un proceso que puede ensayarse.
Los fabricantes deberían hacer tres cosas concretas. Primero, registrar a los usuarios autorizados y establecer sustituciones, aplicando controles de identidad y revocación. Segundo, vincular el flujo de respuesta a incidentes con los plazos del artículo 14: alerta en 24 horas, notificación en 72 horas y reporte final según el tipo de evento. Tercero, probar la actualización del reporte y la conservación de evidencias, no solo el primer envío.
La pregunta decisiva es sencilla: si mañana se detecta explotación activa de una vulnerabilidad en un producto comercializado, ¿puede la empresa enviar una alerta válida a ENISA sin detenerse a discutir quién tiene la cuenta, qué versión está afectada o cuándo empezó el plazo?
Si la respuesta es no, el tutorial ya ha cumplido una función. Ha señalado que el problema no está en aprender una interfaz, sino en descubrir que la organización todavía no tiene una cadena de decisión suficientemente rápida. El formulario es la parte visible. El control real está detrás.