Cyber Resilience Act: notificar una vulnerabilidad en 24 horas

El 11 de septiembre de 2026, ENISA, la agencia europea de ciberseguridad, puso en marcha la plataforma en la que los fabricantes de software y de objetos conectados deben declarar ahora sus vulnerabilidades explotadas. Ese día entró en aplicación la primera obligación del Cyber Resilience Act (CRA), el Reglamento (UE) 2024/2847, quince meses antes que el resto del texto.

Este análisis de nuestra sección Desarrollo de aplicaciones está actualizado a 20 de octubre de 2026. No es un asesoramiento jurídico: para saber si su producto está afectado y a qué título, su asesor tiene la última palabra.

En resumen

• Desde el 11 de septiembre de 2026, el fabricante de un software o de un objeto conectado vendido en la Unión notifica sus vulnerabilidades activamente explotadas y sus incidentes graves: alerta en 24 horas, notificación en 72 horas y después un informe final.
• La obligación vale también para los productos ya comercializados, y para los fabricantes establecidos fuera de la Unión.
• Una sola declaración, en la plataforma de ENISA, llega a la vez a la autoridad nacional competente y a ENISA.
• Los requisitos de seguridad de los propios productos se aplican a partir del 11 de diciembre de 2027.

¿Quién debe notificar sus vulnerabilidades desde el 11 de septiembre de 2026?

El CRA se dirige a los «productos con elementos digitales» comercializados en el mercado europeo y capaces de conectarse, directa o indirectamente, a un dispositivo o a una red. Según el análisis del bufete McCann FitzGerald, que se apoya en las directrices publicadas por la Comisión en julio de 2026, eso abarca el software autónomo, el hardware con su software integrado y las combinaciones de ambos. El reglamento se aplica a todo operador que vende en Europa, esté donde esté establecido.

Tres precisiones cuentan para una empresa mediana:

1. El fabricante no es necesariamente quien escribe el código. Una empresa que encarga el desarrollo de un producto y lo comercializa con su nombre es su fabricante; un importador o un distribuidor pasa a serlo si lo vende con su propia marca o lo modifica sustancialmente.
2. Los productos ya vendidos están afectados. La obligación de notificación se aplica desde el 11 de septiembre de 2026 a todos los productos cubiertos ya comercializados, recuerda el bufete Hogan Lovells citando el artículo 69 del reglamento. Esta lectura es la de un bufete, no una cita del Diario Oficial: antes de sacar una consecuencia para un producto concreto, relea el artículo 69 en el texto del Reglamento (UE) 2024/2847 en EUR-Lex.
3. Una aplicación puramente interna que no pone a disposición de nadie fuera de la empresa plantea otra cuestión, que debe resolver con su asesor.

¿Qué hay que declarar, y en cuánto tiempo?

Dos acontecimientos activan la obligación. El primero es una vulnerabilidad ya utilizada por un atacante:

El segundo es un incidente grave: un incidente que afecta, o puede afectar, a la capacidad del producto para proteger datos o funciones importantes, o que ha permitido introducir o ejecutar código malicioso en el producto o en la red del usuario. Para uno y otro, la página de la Comisión sobre las notificaciones fija la misma secuencia:

1. En 24 horas

   Una alerta temprana, contada desde el momento en que el fabricante tiene conocimiento de la vulnerabilidad o del incidente.

2. En 72 horas

   La notificación completa, con lo que el fabricante sabe de la vulnerabilidad y de las medidas adoptadas.

3. En 14 días tras la corrección

   El informe final de una vulnerabilidad explotada, una vez disponible una medida correctora o de mitigación.

4. En un mes tras la notificación

   El informe final de un incidente grave.

El fabricante debe además informar a los usuarios afectados, y si es necesario a todos sus usuarios; si no lo hace a tiempo, la autoridad nacional puede hacerlo en su lugar, según Hogan Lovells.

Una sola declaración, en la plataforma de ENISA

Para evitar que un fabricante declare la misma vulnerabilidad en cada país donde vende, el reglamento prevé una ventanilla única. La declaración llega al equipo nacional de respuesta a incidentes (CSIRT) del país donde el fabricante tiene su establecimiento principal, y al mismo tiempo a ENISA; ese CSIRT la transmite luego a los demás países donde se vende el producto.

www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp

ENISA anunció su lanzamiento ese mismo día, con preguntas frecuentes, guías y un servicio de asistencia. Los administradores de software libre implicados en el desarrollo de productos, llamados «administradores de software de código abierto», se incorporarán el 11 de diciembre de 2027.

¿Qué arriesga un fabricante que no notifica?

El incumplimiento de la obligación de notificación entra en el tramo más alto de las sanciones del reglamento:

Existen dos atenuantes: las microempresas y las pequeñas empresas no se exponen a una multa por el solo hecho de superar el plazo de 24 horas de la alerta temprana, y los administradores de software libre no están sujetos a multas administrativas. El plazo de 72 horas, en cambio, vale para todos. Estos importes y esta exención proceden del análisis del bufete Hogan Lovells, que remite a los artículos 64 y 71 del reglamento, y no de una lectura del Diario Oficial por nuestra parte: antes de comprometerse con un presupuesto o un contrato, verifíquelos en el Reglamento (UE) 2024/2847 publicado en el DO (los consultamos el 20 de octubre de 2026).

Lo que cambia para un equipo de 20 a 500 personas

El plazo de 24 horas empieza en el momento en que usted lo sabe. Premia, por tanto, a los equipos que se enteran rápido, y no a los que se enteran por un cliente. Es el verdadero beneficio de la obligación: obliga a implantar lo que de todos modos reduce el coste de una vulnerabilidad.

1. 01Saber lo que vende.

   La lista de sus aplicaciones y objetos conectados en circulación, con sus versiones y los componentes que integran: sin ella, es imposible decir en una hora si una vulnerabilidad publicada le afecta.

2. 02Recibir el aviso pronto.

   Una supervisión que alerte de un comportamiento anómalo, y una dirección donde un investigador o un cliente pueda notificar una vulnerabilidad, leída cada día.

3. 03Decidir quién declara.

   Una persona designada, y su suplente, con una cuenta ya creada en la plataforma de ENISA, en lugar de un registro en mitad de un incidente.

4. 04Poder corregir rápido.

   El informe final de una vulnerabilidad explotada se cuenta desde la corrección disponible: una cadena de entrega que publica una corrección en pocas horas acorta todo lo demás.

La cuestión de la publicación pesa aquí: una corrección en una aplicación de las tiendas espera la revisión de Apple o de Google, mientras que una aplicación web progresiva se actualiza en cuanto se pone en línea. Comparamos las dos vías en PWA o aplicación de las tiendas. El presupuesto de esta vigilancia forma parte del coste real de una aplicación, que detallamos en lo que hace variar el precio de una aplicación y en el presupuesto de mantenimiento de una aplicación. Para la alerta en sí, el método de supervisión de nuestras automatizaciones se aplica también a una aplicación.

Si usted compra software en lugar de fabricarlo, el CRA también le sirve: pregunte a sus proveedores quién recibe las notificaciones en su casa, cómo le avisarán de una vulnerabilidad explotada y a qué ritmo publican sus correcciones. Una respuesta clara dice mucho de su madurez.

Y después: los requisitos del 11 de diciembre de 2027

La notificación no es más que el primer peldaño. A partir del 11 de diciembre de 2027, los productos introducidos en el mercado deberán cumplir los requisitos esenciales de ciberseguridad del reglamento, recuerda ENISA. El CRA se suma a NIS2, que se dirige a las organizaciones más que a los productos y cuya transposición sigue pendiente en Francia, como explicamos en nuestro análisis de la ley francesa de Resiliencia. Todas estas fechas están reunidas en nuestro calendario de la regulación digital.

Si encarga el desarrollo de una aplicación y quiere que la supervisión, las actualizaciones y el procedimiento de notificación estén previstos desde el principio, ese es el perímetro de nuestra oferta de desarrollo de aplicaciones.

Preguntas frecuentes

Fuentes

1. El análisis del bufete McCann FitzGerald (nueva pestaña)mccannfitzgerald.com
2. El bufete Hogan Lovells (nueva pestaña)hlc.com
3. El texto del Reglamento (UE) 2024/2847 en EUR-Lex (nueva pestaña)eur-lex.europa.eu
4. La página de la Comisión sobre las notificaciones (nueva pestaña)digital-strategy.ec.europa.eu
5. Anunció su lanzamiento (nueva pestaña)enisa.europa.eu