Ley de Ciberresiliencia de la UE: qué notificaciones exige desde septiembre de 2026

La Ley de Ciberresiliencia de la UE (CRA, por sus siglas en inglés) no empezó a aplicarse en bloque el 11 de septiembre de 2026. Esa fecha marca el inicio de sus obligaciones de notificación: desde entonces, los fabricantes afectados deben informar de ciertas vulnerabilidades explotadas activamente y de incidentes graves que repercutan en la seguridad de sus productos con elementos digitales. La aplicación general del reglamento está prevista para el 11 de diciembre de 2027. Son dos hitos distintos, y confundirlos puede llevar a pensar erróneamente que todas las obligaciones de la ley ya rigen o, a la inversa, que ninguna está vigente todavía.

La norma es el Reglamento (UE) 2024/2847. Su ámbito abarca productos de hardware y software con elementos digitales que se comercializan en la Unión, incluidos determinados componentes comercializados por separado. No equivale a una obligación universal para cualquier persona que detecte un fallo: las obligaciones principales de notificación del artículo 14 recaen en los fabricantes cuando se cumplen los criterios que fija el reglamento. La Comisión describe la CRA como un marco horizontal de requisitos de ciberseguridad para estos productos; para resolver casos concretos, sin embargo, hay que acudir al texto legal y determinar si el producto y la entidad entran en su ámbito. Comisión Europea: resumen de la CRA y texto del reglamento.

La obligación de notificar no se activa por cualquier vulnerabilidad potencial ni por cualquier incidente informático de la empresa. Según la guía de la Comisión, se refiere a vulnerabilidades explotadas activamente y a incidentes graves que tengan un impacto en la seguridad del producto con elementos digitales. La evaluación requiere, por tanto, distinguir un problema conocido o teórico de uno que esté siendo explotado, y valorar si un incidente afecta a la seguridad del producto. La guía resume el régimen; no reemplaza las definiciones, condiciones y excepciones del reglamento. Comisión Europea: obligaciones de notificación.

El sujeto obligado principal es el fabricante, no automáticamente cada usuario, investigador o distribuidor que comunique un fallo. La ley también contempla obligaciones para los open-source software stewards, pero bajo una disposición y un calendario diferentes: la Comisión sitúa su aplicación desde el 11 de diciembre de 2027, conforme al artículo 24(3) y al artículo 71(2). Esto no significa que todo proyecto de código abierto tenga ya, por ese solo hecho, las mismas obligaciones del fabricante. La calificación de una entidad y su papel concreto en el ciclo del producto importan; cuando exista duda, no conviene resolverla únicamente por la etiqueta comercial o por el hecho de que el código sea abierto.

Los plazos empiezan cuando el fabricante toma conocimiento del suceso pertinente. La guía de la Comisión establece un aviso inicial en un máximo de 24 horas y una notificación más completa en un máximo de 72 horas. Para una vulnerabilidad explotada activamente, el informe final debe presentarse, como máximo, 14 días después de que esté disponible una medida correctiva. En el caso de un incidente grave, el informe final vence dentro del mes siguiente a la notificación de 72 horas. Son relojes distintos y no deben resumirse como un único plazo de respuesta.

La tabla resume los plazos publicados por la Comisión, pero no sustituye el artículo 14 ni recoge todos los detalles de cada procedimiento. En particular, las empresas deben distinguir qué categoría de suceso están notificando y documentar cuándo adquirieron conocimiento y cuándo estuvo disponible la medida correctiva. La guía oficial detalla los plazos como parte del régimen de notificación de la CRA. Fuente.

La Comisión indica que los fabricantes realizan una sola notificación mediante la Single Reporting Platform (SRP), una plataforma común para el régimen de la CRA. La notificación se dirige al equipo de respuesta a incidentes de seguridad informática (CSIRT) correspondiente al lugar donde el fabricante tiene su establecimiento principal. La Comisión también explica que, salvo circunstancias excepcionalmente particulares, la información se comparte con otras autoridades pertinentes. Por tanto, “una sola vez” describe el canal de presentación indicado, no una garantía de que no haya otras interacciones posteriores con autoridades.

ENISA publica la página de la SRP y materiales de apoyo, incluidas preguntas frecuentes y guías de uso. Estos recursos ayudan a entender el canal y sus funciones; no cambian por sí solos quién debe notificar, qué hechos activan la obligación ni cuáles son los plazos legales. Para las organizaciones afectadas, una comprobación práctica es identificar de antemano el responsable interno, el proceso para escalar sucesos y la información necesaria para presentar y actualizar un aviso. La plataforma sirve como parte del proceso de reporte, pero no sustituye la gestión técnica de la vulnerabilidad ni la obligación de adoptar medidas correctivas. ENISA: Single Reporting Platform.

Para fabricantes, la fecha de septiembre de 2026 justifica revisar si sus productos están dentro del ámbito de la CRA y si su proceso permite reaccionar dentro de los plazos. Esa preparación puede incluir un procedimiento para registrar la hora de conocimiento, clasificar el suceso, coordinar equipos técnicos y legales y preparar las comunicaciones sucesivas. También conviene revisar productos ya comercializados: la guía de la Comisión establece la fecha y las categorías de reporte, mientras que el texto legal debe consultarse para las disposiciones de alcance y transición que sean aplicables al caso.

Para quienes compran o utilizan dispositivos y programas, la fecha no implica que deban presentar estos informes ni que todos los productos hayan recibido de repente una certificación nueva. La CRA también introduce requisitos para fabricantes sobre el diseño, desarrollo y mantenimiento seguro, pero el régimen general de aplicación llega en diciembre de 2027. En la práctica, los usuarios pueden pedir al proveedor información sobre actualizaciones, soporte y gestión de vulnerabilidades, sin asumir que la entrada en vigor de la obligación de informar garantiza por sí sola que un producto esté libre de fallos. Notificar un problema y eliminarlo son tareas relacionadas, pero distintas.

La conclusión verificable es acotada: a 3 de octubre de 2026, las obligaciones de reporte de la CRA se aplican desde el 11 de septiembre a fabricantes y a los sucesos descritos por la Comisión; la aplicación general del reglamento tiene otro calendario, y la obligación específica para open-source software stewards comienza en diciembre de 2027. La Comisión identifica la SRP como el canal de notificación y publica los plazos principales. Estos datos bastan para corregir la idea de que el cambio todavía es solo una previsión, pero no para resolver la situación de cada empresa o producto.

Hay límites que conviene conservar. Esta explicación se apoya en el reglamento y en la guía pública de la Comisión, además de los recursos operativos de ENISA; no incluye entrevistas ni asesoramiento jurídico individual, y no pretende determinar si un producto concreto está cubierto o si un incidente satisface los umbrales legales. Esas respuestas dependen de los hechos y de la lectura del texto completo, incluidas sus definiciones y excepciones. Ante una situación real, las organizaciones deberían comprobar el Reglamento (UE) 2024/2847 y la documentación vigente de la SRP, y consultar asesoramiento especializado cuando la clasificación del suceso o del actor no sea clara.