CRA y Vulnerability Disclosure: qué exige el Cyber Resilience Act a las empresas

Por Kike Gandia · Co-Fundador y CEO, OSCP · Última actualización: octubre de 2026

El Cyber Resilience Act (CRA) obliga a los fabricantes de productos con elementos digitales a gestionar sus vulnerabilidades durante todo el periodo de soporte y a notificar a las autoridades las que se están explotando. Esa segunda parte ya no es un plan de futuro: es exigible desde el 11 de septiembre de 2026. Esta guía separa lo que hay que notificar de lo que hay que gestionar, con los plazos exactos del artículo 14 y lo que necesitas tener montado para cumplirlos.

El CRA en contexto: por qué obliga a gestionar y comunicar vulnerabilidades

El Cyber Resilience Act, Reglamento (UE) 2024/2847, fija requisitos de ciberseguridad para los productos con elementos digitales que se comercializan en la UE, del dispositivo IoT al software instalable. La parte que más trabajo da en el día a día no es el diseño del producto, sino lo que pasa después de venderlo: el fabricante tiene que gestionar las vulnerabilidades mientras dure el periodo de soporte y avisar a las autoridades y a sus usuarios cuando alguna se explota.

Qué productos quedan sujetos a estas obligaciones de disclosure

Software y hardware con elementos digitales cuya finalidad o uso razonablemente previsible incluya una conexión de datos, directa o indirecta, con un dispositivo o una red, junto con sus soluciones de tratamiento de datos a distancia. Quedan fuera los productos ya regulados por normas sectoriales propias —productos sanitarios y de diagnóstico in vitro, vehículos de motor, aviación civil y equipos marinos—, los desarrollados exclusivamente para la seguridad nacional o la defensa y el software como servicio puro, que no es un producto en el sentido del reglamento.

Desde cuándo son exigibles: las obligaciones de notificación ya están en vigor

El reglamento entró en vigor el 10 de diciembre de 2024. Las obligaciones de notificación del artículo 14 son exigibles desde el 11 de septiembre de 2026 y, según el artículo 69.3, alcanzan también a los productos que ya estaban en el mercado antes de esa fecha: no hay excepción por antigüedad. El resto del reglamento, incluidos los requisitos esenciales y el marcado CE, se aplica desde el 11 de diciembre de 2027.

Qué hay que notificar y en qué plazos

La obligación cubre dos supuestos: las vulnerabilidades activamente explotadas del producto y los incidentes graves que afecten a su seguridad. Cada uno tiene su propio calendario:

Supuesto	Plazo	Entrega
Vulnerabilidad activamente explotada	24 horas desde que el fabricante la conoce	Alerta temprana, indicando si es el caso los Estados miembros donde se comercializa el producto
Vulnerabilidad activamente explotada	72 horas desde que el fabricante la conoce	Notificación con información general del producto, naturaleza del exploit y de la vulnerabilidad, y medidas correctoras o de mitigación
Vulnerabilidad activamente explotada	14 días desde que hay una corrección o mitigación disponible	Informe final: descripción, gravedad e impacto, información sobre el actor malicioso si se conoce y detalle de la actualización
Incidente grave	24 horas	Alerta temprana
Incidente grave	72 horas	Notificación del incidente
Incidente grave	Un mes desde la notificación	Informe final

Todo se envía por la plataforma única de notificación que gestiona ENISA, y llega a la vez al CSIRT designado como coordinador del Estado miembro donde el fabricante tiene su establecimiento principal y a la propia ENISA. Además, el fabricante tiene que informar a los usuarios afectados de la vulnerabilidad o el incidente y de las medidas que pueden tomar.

Lo que no es obligatorio notificar, pero sí gestionar

Una vulnerabilidad que nadie está explotando no se notifica por obligación: el artículo 15 permite comunicarla de forma voluntaria, una vía que la plataforma de ENISA aún no habilitó en su primera fase. Lo que sí es obligatorio para todas es gestionarlas conforme a la parte II del anexo I del reglamento:

Identificar y documentar los componentes del producto, con una lista de materiales de software (SBOM).
Corregir sin demora, con actualizaciones de seguridad gratuitas y distribuidas por un mecanismo seguro.
Probar y revisar la seguridad del producto de forma periódica.
Aplicar una política de divulgación coordinada de vulnerabilidades (CVD) y ofrecer una dirección de contacto para que terceros reporten.
Publicar información sobre las vulnerabilidades corregidas una vez exista la actualización.

En la práctica, la notificación de 24 horas solo se cumple si esta gestión ya funciona: no se puede declarar a tiempo una vulnerabilidad explotada en un componente que no sabías que llevabas.

Cómo preparar tu proceso de gestión de vulnerabilidades para el CRA

Cumplir con el CRA requiere más que una política escrita. Lo mínimo operativo es esto:

Un canal público para recibir reportes (security.txt, buzón security@ o un VDP formal) y un punto único de contacto declarado.
Un criterio escrito para decidir cuándo una vulnerabilidad está activamente explotada, porque es lo que pone en marcha el reloj de 24 horas.
Un triage capaz de validar técnicamente un reporte y determinar su estado de explotación en horas, también fuera de horario.
El alta del fabricante en la plataforma única de ENISA hecha antes de necesitarla, con plantillas preparadas para las tres entregas.
Un procedimiento para avisar a los usuarios afectados con medidas concretas.

CRA vs NIS2: diferencias en obligaciones de disclosure

NIS2 y CRA se solapan en algunos aspectos pero tienen ámbitos distintos. NIS2 regula a las entidades esenciales e importantes por los servicios que prestan y les obliga a notificar sus incidentes significativos. El CRA regula los productos y obliga a su fabricante a notificar las vulnerabilidades explotadas y los incidentes graves que les afecten. Un fabricante de software que además opere un servicio regulado puede estar sujeto a las dos normas a la vez.

Qué ocurre si no notificas: régimen sancionador del disclosure

Incumplir los requisitos esenciales o las obligaciones de los artículos 13 y 14, que incluyen las de notificación, puede costar hasta 15 millones de euros o el 2,5% del volumen de negocios mundial anual, la cifra que sea mayor. Además, las autoridades de vigilancia del mercado pueden exigir medidas correctoras, restringir la comercialización del producto o retirarlo del mercado.

FAQ

¿El CRA me obliga a crear un programa de bug bounty?

No directamente, pero sí te obliga a tener un canal de reporte de vulnerabilidades y un proceso de CVD. Un programa de bug bounty es una forma de cumplir con esta obligación y además atraer investigadores que te ayuden a descubrir vulnerabilidades antes de que sean explotadas.

¿Cuándo tengo que empezar a cumplir con las obligaciones de disclosure del CRA?

Ya. Las obligaciones de notificación del artículo 14 son exigibles desde el 11 de septiembre de 2026 para todos los productos en el mercado, también los anteriores a esa fecha. El resto del reglamento se aplica desde el 11 de diciembre de 2027.

¿Tengo que notificar una vulnerabilidad que no se está explotando?

No es obligatorio: el artículo 15 permite notificarla de forma voluntaria. Lo que sí tienes que hacer es corregirla sin demora, distribuir la actualización de forma gratuita y publicar información sobre ella una vez corregida, conforme a la parte II del anexo I.

¿Qué pasa si recibo un reporte de vulnerabilidad explotada fuera de horario laboral?

El plazo de 24 horas del CRA no distingue entre horario laboral y no laboral. Necesitas un proceso de guardia o un equipo externo que pueda recibir, evaluar y notificar el reporte en cualquier momento. Este es uno de los argumentos más sólidos para externalizar el triage.