La obligación de notificación del Cyber Resilience Act de la UE ya está vigente. Desde el 11 de septiembre de 2026, los fabricantes de productos incluidos en su ámbito deben notificar vulnerabilidades explotadas activamente e incidentes graves de seguridad. La página de notificaciones de la Comisión Europea confirma la fecha y los plazos. Esperar a la aplicación general del reglamento ya no es un plan viable de respuesta a incidentes.
El desafío práctico es conectar la evidencia de un ataque con alguien que pueda presentar una notificación. Tu proceso de respuesta debe hacerlo mientras los ingenieros siguen investigando, antes de tener una explicación completa o un parche terminado.
Este artículo refleja la orientación oficial consultada el 16 de septiembre de 2026. La plataforma está operativa y su documentación ha cambiado respecto al periodo anterior al lanzamiento.
Los plazos tienen distintos puntos de partida
La Comisión establece una alerta temprana dentro de las 24 horas desde que se tiene conocimiento y una notificación más completa dentro de las 72 horas. Para una vulnerabilidad explotada, el informe final vence dentro de los 14 días posteriores a la disponibilidad de una medida correctora. Para un incidente grave, vence dentro del mes posterior a la notificación de 72 horas.
No son bloques consecutivos en una única cuenta atrás. Los primeros plazos comparten el momento de conocimiento como inicio; el plazo final depende del tipo de evento. Incluye cada desencadenante en el registro del incidente. De lo contrario, el equipo podría interpretar la notificación más completa como una prórroga que empieza al enviar la alerta temprana.
Prepara un registro breve que pueda ampliarse durante la investigación. Separa los hechos observados de las hipótesis. Registra cuándo llegó la evidencia, quién la evaluó, qué producto y versiones parecen afectados y qué falta saber. Una investigación incompleta necesita un responsable y una siguiente acción, no una hora de inicio que cambia sin dejar rastro.
Productos antiguos y evidencia recién conocida
Las preguntas frecuentes de implementación de la Comisión, actualizadas el 4 de septiembre, explican que el artículo 69(3) incluye productos anteriores en la obligación de notificar si están dentro del ámbito del reglamento. También distinguen una vulnerabilidad encontrada mediante pruebas legítimas de otra con evidencia fiable de explotación maliciosa. Un hallazgo de bug bounty sin esa evidencia no es, por sí solo, una vulnerabilidad explotada activamente.
Para tu equipo, esto implica conservar una forma de identificar versiones antiguas cuando un cliente avisa de un ataque. La rama actual de desarrollo no es un inventario completo de lo que ejecutan los clientes. Registra el nombre del producto, el identificador de versión y el contacto responsable donde soporte pueda encontrarlos sin saber quién escribió originalmente el código.
No supongas que un investigador haya encontrado el fallo significa que un atacante lo utilizó. Tampoco supongas que un fallo conocido sea inocuo porque ya tiene una tarea asignada. Pregunta qué evidencia cambió. Un aviso de explotación y un registro antiguo del defecto responden preguntas distintas.
Las preguntas frecuentes actuales de ENISA aclaran la transición: los fabricantes no notifican retrospectivamente una explotación que ya conocían antes del 11 de septiembre. Conocerla después puede activar la obligación incluso para una vulnerabilidad antigua. También confirman que las obligaciones correspondientes de los administradores de software de código abierto comienzan el 11 de diciembre de 2027. Hay que notificar sin demora indebida; las horas indicadas son límites máximos.
La plataforma ya está disponible
La página de la plataforma única de notificación de ENISA ya enlaza al portal operativo. Usa esa entrada oficial al preparar las instrucciones para incidentes. Elimina cualquier nota interna que diga que la dirección se facilitará en el lanzamiento.
La guía de registro, actualizada el 12 de septiembre, exige una cuenta personal de EU Login con autenticación multifactor. La verificación de la relación entre representante y fabricante ocurre en paralelo a la notificación; no es un requisito previo para el primer envío. ENISA recomienda iniciar el registro en la plataforma cuando haga falta notificar, aunque la cuenta de EU Login puede prepararse antes.
Esta diferencia importa al asignar la preparación. Confirma que la persona responsable puede acceder a su propia cuenta y método de autenticación. No conviertas una contraseña compartida en tu plan de respaldo. Documenta cómo reunirá el equipo los datos del fabricante y cómo identificará al equipo nacional de respuesta que debe actuar como coordinador.
La guía de funciones de la interfaz, también actualizada el 12 de septiembre, permite ahora hasta 20 notificaciones mientras la relación no esté verificada. El representante principal debe estar verificado para invitar a representantes secundarios. El principal puede acceder a las notificaciones del fabricante; los secundarios tienen acceso limitado a sus propios envíos y borradores.
Esos permisos deben formar parte del plan de relevo. Que un colega sepa que existe un informe no demuestra que pueda abrirlo o actualizarlo. Decide cómo conservarás la evidencia y la siguiente acción necesaria en el sistema interno de incidentes, con acceso restringido a quienes gestionan el caso.
Un borrador guardado no es una alerta presentada
La guía de envío de ENISA distingue entre guardar un borrador privado y enviar una alerta temprana. Describe la notificación más completa y el informe final como etapas posteriores de una notificación existente. Si faltan campos obligatorios, la validación devuelve errores.
Para el responsable del incidente, la pregunta operativa importante es si la plataforma aceptó el envío. Conserva el identificador, la confirmación y la hora de presentación junto al registro del incidente. Una captura de los campos completos o un mensaje interno que diga que el formulario está listo aporta menos evidencia que la confirmación de su envío.
Ensaya el relevo interno con un incidente ficticio, sin presentar una notificación de prueba en el servicio real. Pide a soporte que aporte la evidencia inicial, a ingeniería que identifique el producto afectado y al responsable de notificar que explique qué enviaría. Comprueba si otra persona puede continuar el trabajo cuando el responsable original no esté disponible.
Qué no cambia
El inicio de las notificaciones no significa que todos los requisitos del CRA comenzaran a la vez. El calendario de implementación de la Comisión distingue las disposiciones anteriores sobre organismos de evaluación de la conformidad, el inicio de las notificaciones y la aplicación general el 11 de diciembre de 2027.
Tampoco determina si cualquier servicio o proyecto de código abierto está dentro del ámbito. Importan la arquitectura del producto y el papel de la organización. Resuelve esa cuestión con la orientación aplicable antes de tratar este artículo como una decisión de clasificación de incidentes.
Notificar no sustituye la contención, una corrección ni la comunicación clara con los usuarios afectados. La respuesta útil de ingeniería consiste en hacer visibles la evidencia, la responsabilidad y el estado del envío mientras ese trabajo continúa. El plazo ya corre cuando se cumple el desencadenante; el equipo necesita saber quién está a cargo.
Escrito por Dandelion Labs