Cyber Resilience Act: tutorial para reportar vulnerabilidades en 24 y 72 horas
Una vulnerabilidad explotada en un producto ya no se gestiona solo con un parche y un comunicado. Si ese producto digital se comercializa en la Unión Europea y entra en el ámbito del Cyber Resilience Act (CRA), el fabricante puede tener que activar una ruta formal de notificación. Desde el 11 de septiembre de 2026 se aplican las obligaciones de reporte para vulnerabilidades activamente explotadas e incidentes graves que afectan la seguridad del producto. La Comisión Europea explica los plazos y el alcance.
El dato reciente es operativo: ENISA actualizó el 4 de noviembre su Single Reporting Platform a la versión 1.3 y advierte que parte de la documentación está en revisión. Para una dirección de tecnología, la pregunta útil no es solo «¿tenemos un formulario?», sino «¿podemos detectar, decidir y reunir evidencia antes de que corra el reloj?».
Primero: comprueba si el caso pertenece al CRA
El CRA se refiere a productos de hardware y software con elementos digitales puestos a disposición en el mercado de la UE. No convierte cualquier incidente de TI de cualquier empresa en una notificación CRA. Antes de abrir un reporte, identifica el producto, su fabricante, el mercado donde se ofrece y si lo ocurrido es una vulnerabilidad activamente explotada o un incidente grave con impacto en la seguridad del producto. La síntesis oficial del reglamento aclara que las obligaciones de reporte también alcanzan a productos ya comercializados antes de la aplicación general prevista para diciembre de 2027.
«Crítico» no equivale automáticamente a «explotado». Una puntuación alta de CVSS puede justificar respuesta urgente, pero el supuesto de notificación de vulnerabilidad habla de explotación activa. Conserva la evidencia que sustenta la clasificación y pide revisión jurídica cuando el alcance o la categoría del evento no estén claros.
El cronómetro: 24 horas, 72 horas y cierre
Según la Comisión Europea, el fabricante debe presentar una alerta temprana dentro de las 24 horas desde que tiene conocimiento del evento y una notificación completa dentro de las 72 horas. El informe final tiene plazos distintos: para una vulnerabilidad explotada, a más tardar 14 días después de que esté disponible una medida correctiva; para un incidente grave, dentro del mes siguiente a la notificación de 72 horas.
La notificación se presenta a través de la plataforma única de ENISA. Su guía de envío describe tres pasos consecutivos: alerta temprana, notificación de 72 horas e informe final. Un borrador guardado no equivale a un envío; el equipo debe comprobar el estado de la notificación y conservar la confirmación.
Tutorial: arma un expediente mínimo antes del incidente
- Inventario de producto. Registra nombre, versiones, componentes, mercados donde se ofrece y propietario interno. Relaciona cada versión con su equipo de soporte.
- Señal y tiempo. Define quién recibe avisos de explotación, reportes de clientes y alertas de seguridad. Guarda cuándo se recibió la señal y cuándo se conoció el hecho relevante; no reconstruyas la cronología días después.
- Clasificación. Documenta la evidencia de explotación o del incidente grave, su impacto en la seguridad del producto y las dudas pendientes. Separa hechos confirmados de hipótesis.
- Responsable de envío. Designa una persona titular y una suplente con acceso probado a la plataforma de ENISA. Valida el registro con antelación y comprueba la guía vigente tras la actualización.
- Acción y seguimiento. Reúne mitigaciones, versiones afectadas, plan de corrección, comunicación con clientes y fechas para la actualización de 72 horas y el informe final.
Este expediente es una herramienta de coordinación interna; los campos obligatorios son los que solicite la plataforma vigente. Conviene mantener una bitácora única de decisiones: qué se sabía, quién decidió, qué se notificó y cuándo. Seguridad, ingeniería de producto, soporte, comunicación y asesoría jurídica deben poder trabajar sobre la misma cronología.
Un simulacro de 30 minutos que revela fallas reales
Plantea un caso ficticio: un cliente informa explotación activa de una versión todavía en uso. Inicia un cronómetro y pide al equipo que localice el dueño del producto, determine los países donde se ofrece, encuentre al representante autorizado de la plataforma y redacte una alerta temprana basada solo en hechos conocidos. Detén el ejercicio antes de enviar nada real.
Al finalizar, mide cuatro tiempos: detección, clasificación, acceso a la plataforma y revisión del primer mensaje. Si cualquiera depende de una sola persona, de una hoja desactualizada o de un proveedor al que nadie puede contactar, ese es el trabajo prioritario. Mi criterio: la gobernanza se prueba cuando el equipo puede tomar una decisión trazable bajo presión, incluso con información incompleta.
Fuentes: Comisión Europea, obligaciones de reporte; síntesis oficial del CRA; ENISA, plataforma y actualización; ENISA, guía de envío.
