La notificación del CRA empieza el 11 de septiembre de 2026

Un viernes por la tarde llega un aviso sobre una vulnerabilidad en un componente integrado en varios productos. La persona que informa asegura que ya se está explotando. Ingeniería quiere reproducir el fallo. Legal pregunta si el Reglamento de Ciberresiliencia (CRA, por sus siglas en inglés) se aplica. Respuesta a incidentes necesita versiones afectadas y telemetría. Dirección prefiere esperar hasta tener hechos concluyentes.

A partir del 11 de septiembre de 2026, esa espera puede consumir casi todo el primer plazo del CRA.

Las obligaciones de notificación del artículo 14 empiezan antes que la mayoría de requisitos del Reglamento. Los fabricantes de productos con elementos digitales incluidos en su ámbito deben notificar vulnerabilidades explotadas activamente e incidentes graves que afecten a la seguridad del producto. El proceso es progresivo: alerta temprana en 24 horas, notificación más completa en 72 horas e informe final con un plazo distinto para vulnerabilidades e incidentes.

Eso no significa enviar cada bug a ENISA. Significa decidir de antemano quién determina que existe conocimiento suficiente, quién identifica al fabricante legal, cómo se conservan las pruebas y quién presenta una notificación defendible mientras la investigación sigue abierta.

Qué cambia el 11 de septiembre de 2026

El CRA entró en vigor el 10 de diciembre de 2024. La mayor parte de sus obligaciones se aplicará desde el 11 de diciembre de 2027, pero el artículo 14 será aplicable desde el 11 de septiembre de 2026. Este adelanto puede sorprender a empresas que han tratado la preparación para el CRA como un proyecto de conformidad con fecha de 2027.

La obligación alcanza a todos los productos con elementos digitales dentro del ámbito del CRA, incluidos los productos pertinentes introducidos en el mercado antes del 11 de diciembre de 2027. Las directrices de la Comisión añaden que la notificación sigue siendo exigible después de terminar el periodo de soporte, aunque las obligaciones generales de gestión de vulnerabilidades no se apliquen de igual modo a un producto antiguo o sin soporte.

Por tanto, el historial del producto importa. Un dispositivo conectado descatalogado, una rama antigua de software o un appliance heredado no desaparecen del inventario de notificación porque ingeniería ya no los compile. La organización necesita información suficiente para reconocer el producto, localizar la entidad fabricante responsable y evaluar el aviso.

El artículo 14 establece dos desencadenantes obligatorios para los fabricantes:

• una vulnerabilidad explotada activamente contenida en el producto de la que el fabricante tenga conocimiento; y
• un incidente grave que repercuta en la seguridad del producto y del que el fabricante tenga conocimiento.

Una vulnerabilidad recién descubierta no es automáticamente una vulnerabilidad explotada activamente. El Reglamento exige pruebas fiables de que un actor malicioso la ha explotado sin permiso del propietario del sistema. Un hallazgo de laboratorio, una investigación de buena fe o un aviso de un programa de recompensas sin pruebas de explotación maliciosa no activa por sí solo la notificación obligatoria, aunque cabe una notificación voluntaria.

Tampoco conviene irse al extremo opuesto. Una vulnerabilidad en un componente externo no se puede despachar como «problema del proveedor». Si existe explotación activa en el producto del fabricante, este tiene su propia obligación de notificar. Si el código vulnerable no es alcanzable en ese producto o no ha sido explotado en él, las directrices indican que no hay notificación obligatoria para ese fabricante, sin perjuicio de las tareas de gestión de vulnerabilidades y coordinación con el proveedor.

El reloj del CRA: 24 horas, 72 horas e informe final

Los plazos corren desde que se tiene conocimiento, no desde que termina el análisis técnico. Las directrices de julio de 2026 sitúan ese momento cuando una evaluación inicial permite al fabricante alcanzar un grado razonable de certeza de que existe explotación activa, o de que se ha producido un incidente grave que ha comprometido la seguridad del producto. La Comisión también pide evaluar sin demora los sucesos sospechosos.

El proceso admite una investigación todavía incompleta:

1. Alerta temprana: sin demora indebida y, en todo caso, en las 24 horas siguientes a tener conocimiento.
2. Notificación: sin demora indebida y, en todo caso, en las 72 horas siguientes. Añade la información disponible a medida que avanza la investigación.
3. Informe final de una vulnerabilidad explotada activamente: como máximo 14 días después de que esté disponible una medida correctora o de mitigación.
4. Informe final de un incidente grave: dentro del mes siguiente a la notificación de 72 horas.

La alerta de 24 horas no pretende ser un informe forense terminado. El error consiste en tratar la incertidumbre como permiso para detener el reloj. Hay que documentar los hechos conocidos, las hipótesis pendientes, el fundamento de la decisión y la persona que autorizó el envío. Después se actualiza el expediente.

Las notificaciones se tramitan mediante la plataforma única de notificación del CRA (SRP), que ENISA debe tener operativa el 11 de septiembre de 2026. La Comisión la describe como un único envío dirigido al CSIRT del Estado miembro donde el fabricante tenga su establecimiento principal. Salvo circunstancias especialmente excepcionales, la información queda disponible simultáneamente para ENISA y se comparte con otros CSIRT afectados. ENISA ya ha publicado instrucciones de registro y presentación, pero advierte de que pueden cambiar. Conviene consultar la guía vigente y no depender de una captura guardada meses antes.

Quién notifica y por qué no todos son fabricantes

El artículo 14 dirige la obligación al fabricante. En el CRA, no siempre es la fábrica ni quien escribió el código original. La calificación depende, entre otros hechos, de quién desarrolla o encarga el producto y lo comercializa con su nombre o marca.

Importadores y distribuidores tienen obligaciones propias. No deben presentarse como sujetos automáticos del proceso de 24 y 72 horas reservado al fabricante. Sin embargo, un importador o distribuidor puede pasar a considerarse fabricante si introduce el producto en el mercado con su nombre o marca, o si realiza una modificación sustancial. Otros actores también pueden adquirir obligaciones de fabricante tras modificar sustancialmente un producto.

Un revendedor, proveedor de marca blanca, integrador o empresa que distribuya un producto modificado necesita un análisis por producto. La etiqueta utilizada en el contrato no resuelve por sí sola el papel jurídico.

El software libre y de código abierto exige la misma precisión. El software desarrollado o suministrado fuera de una actividad comercial recibe un tratamiento distinto y no se debe convertir a cada colaborador individual en fabricante. El CRA crea la figura del administrador de software de código abierto para una persona jurídica que no sea fabricante, preste apoyo sistemático y sostenido al desarrollo de FOSS destinado a actividades comerciales y garantice su viabilidad.

Los administradores tienen una obligación más limitada en el artículo 24. Las directrices confirman que deben notificar vulnerabilidades explotadas activamente conforme al artículo 24(3), en la medida en que participen en el desarrollo del producto pertinente. Una empresa puede ser administradora de una edición comunitaria gratuita y fabricante de una versión monetizada. La misma entidad puede asumir papeles distintos según la edición.

Determinar el ámbito y el operador económico es una cuestión jurídica. Ingeniería aporta los hechos, pero no debería resolverla en solitario durante un incidente.

Organizar el proceso alrededor de pruebas, no de reuniones

La preparación empieza antes del aviso. No hace falta una política de cien páginas, sino un recorrido corto desde la señal hasta la decisión, con pruebas suficientes en cada relevo.

1. Relacionar productos, entidades y responsables

El inventario debe conectar cada familia de producto, incluidas las versiones antiguas, con:

• la entidad que lo introduce en el mercado de la UE;
• nombres comerciales y acuerdos de marca blanca;
• componentes y soluciones de tratamiento remoto de datos;
• responsables de producto, seguridad y legal;
• estado de soporte y disponibilidad del entorno de compilación o análisis;
• jurisdicción del CSIRT asociada al establecimiento principal del fabricante.

Un incidente real es el peor momento para descubrir que el nombre utilizado por los clientes no aparece en los registros internos.

2. Definir la decisión de conocimiento

El inicio del plazo debe poder auditarse. Conviene registrar la primera señal, su procedencia y hora, los pasos de evaluación inicial, las pruebas de explotación o compromiso, el razonamiento sobre el producto afectado y el momento en que se alcanza una certeza razonable. También deben conservarse las pruebas en contra.

Un punto único de entrada debe aceptar avisos de clientes, investigadores, SOC, inteligencia de amenazas y proveedores. A partir de ahí, un grupo pequeño toma la decisión con suplentes designados. Una videollamada con veinte personas no sustituye a un procedimiento de escalado.

3. Preparar los datos mínimos de 24 horas

La plantilla tiene que funcionar con información parcial. Debe recoger producto y fabricante, tipo de suceso, hora de conocimiento, versiones afectadas o incertidumbre, indicios observados, territorios conocidos, contención inmediata, impacto probable y un contacto operativo.

Hay que separar hechos de hipótesis y conservar marcas de tiempo, registros, hashes, tickets y copias de informes externos con una política clara. Un programa de gestión de vulnerabilidades ayuda a mantener el rastro del componente y la corrección, pero la decisión de notificar necesita además un propietario jurídico.

4. Convertir la actualización de 72 horas en un entregable técnico

En 72 horas la empresa debería explicar mejor la exposición del producto, las versiones afectadas, la vía de explotación o mecánica del incidente, el impacto, los indicadores, el estado de la mitigación y los siguientes pasos. Producto, ingeniería, seguridad y respuesta a incidentes deben trabajar sobre un único expediente.

Conviene nombrar a una persona responsable de las pruebas para evitar tres cronologías incompatibles. Si el mismo suceso activa NIS2, RGPD, normativa sectorial o avisos contractuales, es mejor mantener una matriz de plazos y destinatarios que asumir que un envío cubre todos los regímenes.

5. Conectar la corrección con el informe final

Para una vulnerabilidad, el plazo final depende de cuándo queda disponible la medida correctora o de mitigación. Por eso hay que registrar horas y versiones del parche, la configuración mitigadora y la comunicación a clientes. Para un incidente grave, se debe reservar tiempo de revisión antes de cumplir el mes; no conviene dejar la narrativa final al responsable del incidente en el día 29.

El artículo 14 también obliga a informar a los usuarios afectados y, cuando proceda, al conjunto de usuarios. Las directrices señalan que la comunicación debe ser proporcionada y basada en el riesgo. No exige publicar sin criterio detalles técnicos sensibles mientras continúe la posibilidad de explotación.

Un plan de preparación de 30 días

Durante la primera semana, se clasifican familias de productos y entidades responsables. Deben incluirse los productos antiguos y separarse ediciones comunitarias, comerciales y de marca blanca. Las dudas de clasificación se remiten a asesoramiento jurídico cualificado.

La segunda semana se dedica a un ejercicio de simulación. Un buen escenario es un aviso incompleto sobre un componente. La métrica importante es cuándo se alcanza una certeza razonable, no cuándo aparece el parche ficticio. El equipo debe tomar una decisión sobre la alerta de 24 horas.

En la tercera semana se comprueban el acceso a la SRP y los representantes asignados según las instrucciones vigentes de ENISA. Se preparan plantillas, suplentes, contactos fuera de horario y almacenamiento de pruebas. Las credenciales no deben figurar en el procedimiento.

En la cuarta semana se repite el ejercicio con legal, ingeniería, seguridad de producto, comunicación y respuesta a incidentes. Esta vez se añade otra obligación regulatoria y una disputa con el proveedor. Cada carencia termina con responsable y fecha.

Un servicio de CISO virtual puede coordinar gobierno y simulacros cuando no existe un responsable interno. Si faltan inventario o pruebas, conviene resolver eso antes de comprar otra fuente de alertas. Cuando la organización esté preparada para revisar el proceso, puede contactar con Enclave Guard para plantear un ejercicio específico de preparación para la notificación del CRA.

El plazo es procesal; el fallo será organizativo

El CRA no exige tener la respuesta completa en 24 horas. Exige que el fabricante reconozca una situación notificable, envíe la alerta y amplíe el expediente mientras avanza la investigación. Las empresas con más riesgo de incumplir no son siempre las que detectan peor. Son las que no identifican a tiempo su papel jurídico, la exposición del producto, la persona que decide o la fuente de las pruebas.

El 11 de septiembre de 2026 debe tratarse como una fecha de preparación operativa. Hay que clasificar productos, ensayar la decisión de conocimiento, habilitar el acceso a la SRP y hacer que la cadena funcione fuera de horario. El formulario es la parte sencilla.

Este artículo ofrece información general y no constituye asesoramiento jurídico. El ámbito del CRA, la condición de operador económico y las obligaciones de notificación dependen de las circunstancias de cada producto y organización. Solicita asesoramiento jurídico cualificado para tu caso.