Obligaciones de notificación de la Ley de Ciberresiliencia (CRA)

09/03/2026

    El artículo 14 del CRA responde a una pregunta práctica que se hacen los fabricantes de productos con elementos digitales: si descubres que un problema está siendo explotado activamente o se produce un incidente de seguridad grave, ¿a quién debes notificar, con qué rapidez y qué información debe contener el informe?

    En este artículo, analizamos las distintas vías de notificación disponibles para los fabricantes al informar a CSIRT-ENISA, en función de la naturaleza y la gravedad del incidente o de la vulnerabilidad. Si quieres más información sobre el CRA, puedes consultar nuestra Guía esencial sobre la Ley de Ciberresiliencia o visitar nuestro CRA Hub, donde encontrarás información detallada sobre la normativa y podrás conocer mejor los servicios que ofrecemos para ayudar a los fabricantes a prepararse para el cumplimiento del CRA.

    Artículo 14 del CRA: Obligaciones de notificación de los fabricantes en virtud del CRA

    El artículo 14 establece que los fabricantes deben notificar ciertos eventos de seguridad a través de dos vías paralelas. 

     

    Vía 1: Vulnerabilidades explotadas activamente

    Las vulnerabilidades explotadas activamente se refieren a situaciones en las que un actor malicioso ya está aprovechando un fallo en el producto para causar daños. Esta vía se aplica cuando existe una explotación confirmada y en curso que afecta a usuarios u otras personas, como una elusión de autenticación que permite accesos no autorizados o una escalada de privilegios que conduce al robo de datos en un componente orientado al usuario. Cuando los fabricantes detectan este uso indebido activo, deben evaluar rápidamente la naturaleza y el impacto de la explotación e iniciar medidas correctivas o de mitigación inmediatas para proteger a los usuarios y limitar daños adicionales.

    Cronograma de notificación de vulnerabilidades (Artículo 14(2))

     

    0h – Conocimiento
    Se tiene conocimiento de una vulnerabilidad explotada activamente.
    24h – Notificación de alerta temprana (≤ 24 horas)
    • Enviar rápidamente, aunque esté incompleta
    • Incluir el estado de explotación activa
    • Incluir (cuando proceda)
    • Estados miembros donde el producto está disponible
    72h – Notificación de vulnerabilidad (≤ 72 horas)
    • Más detalle (salvo que ya se haya proporcionado)
    • Incluir información general del producto (según disponibilidad)
    • Incluir la naturaleza general del exploit y de la vulnerabilidad
    • Incluir medidas correctivas/de mitigación adoptadas
    • Incluir medidas que los usuarios pueden tomar de inmediato
    • Incluir (cuando proceda) la sensibilidad de la información notificada
    14d – Informe final (≤ 14 días tras disponer de la solución/mitigación)
    • Incluir la descripción de la vulnerabilidad
    • Incluir la gravedad y el impacto
    • Incluir (cuando esté disponible) información sobre el actor malicioso
    • Incluir detalles de la actualización de seguridad/medidas correctivas

     

    Vía 2: Incidentes graves que afectan a la seguridad del producto

    Los incidentes graves se refieren a eventos de ciberseguridad que afectan, o podrían afectar, a la seguridad del producto o a los procesos de desarrollo, producción o mantenimiento del fabricante. Estos incidentes pueden no implicar una explotación activa, pero se consideran graves cuando suponen un riesgo significativo de ciberseguridad para los usuarios u otras personas. Algunos ejemplos incluyen la inyección de código malicioso en actualizaciones, la compromisión de claves de firma de código o de servicios de firma, o brechas en el repositorio de código fuente o en el sistema de compilación que afecten a los artefactos distribuidos.
    Un incidente se clasifica como grave cuando cumple alguna de las siguientes condiciones:

    • Perjudica la capacidad del producto para proteger la disponibilidad, autenticidad, integridad o confidencialidad de datos o funciones importantes o sensibles, o
    • Da lugar (o podría dar lugar) a la introducción o ejecución de código malicioso en el producto o en los sistemas de un usuario.

     

    Cronograma de notificación de incidentes graves (Artículo 14(4))

     

    0h – Conocimiento
    El fabricante tiene conocimiento de un incidente grave.
    ≤ 24 horas – Alerta temprana
    Presentar una alerta temprana que incluya:
    • Si se sospechan actos ilícitos o maliciosos
    • Una evaluación inicial
    • Estados miembros donde el producto está disponible (si procede)
    • Medidas de mitigación o correctivas ya adoptadas
    ≤ 72 horas – Notificación del incidente
    Presentar una notificación del incidente que incluya (cuando esté disponible):
    • Naturaleza del incidente
    • Gravedad e impacto
    • Descripción detallada
    • Tipo de amenaza probable o causa raíz
    • Medidas que los usuarios pueden adoptar
    • Sensibilidad de la información notificada (si procede)
    ≤ 1 mes – Informe final
    Presentar un informe final que incluya:
    • Medidas de mitigación aplicadas y en curso
    • Información consolidada de la investigación completada

     

    Cómo y dónde notificar: Plataforma Única de Notificación

    Para ambas vías, los fabricantes notifican a través de la Plataforma Única de Notificación. La notificación pasa a ser accesible simultáneamente para el CSIRT coordinador nacional y para ENISA.

    Plazos, aplicabilidad y productos heredados

    Obligaciones de notificación en virtud del artículo 14 se aplican a partir del 11 de septiembre de 2026. Los fabricantes deben notificar las vulnerabilidades explotadas activamente y los incidentes graves para todos los productos con elementos digitales que estén dentro del ámbito de aplicación del CRA, incluidos los productos comercializados antes del 11 de diciembre de 2027 (véase el artículo 69(3)).

    Notificación a los usuarios afectados

    Tras tener conocimiento de una vulnerabilidad explotada activamente o de un incidente grave, los fabricantes deben informar a los usuarios afectados.

    Notificación de vulnerabilidades en componentes de terceros

    Cuando un producto contiene una vulnerabilidad explotada activamente procedente de un componente integrado, el fabricante del producto debe notificarla. El fabricante del componente también debe notificarla si el componente ha sido comercializado.

    Actos delegados y coordinación de CSIRT

    Un acto delegado complementa el CRA definiendo los términos y condiciones en los que el primer CSIRT (coordinador) que recibe una notificación puede retrasar su compartición con los CSIRT de otros Estados miembros. Véase el texto oficial aquí: Acto delegado.

    Orientación práctica para fabricantes

    • Primeros pasos: crear concienciación y definir roles mediante formación sobre el CRA y leer la Guía Esencial del CRA.
    • Proceso establecido: realizar un análisis de brechas con la evaluación de preparación para el CRA.
    • Alta madurez: prepararse para esquemas de aseguramiento como la Marca de Ciberresiliencia o la certificación EUCC.
    • Soporte integral: seguir el itinerario de madurez en nuestra página de servicios de cumplimiento del CRA.

    Preguntas frecuentes sobre la notificación en el CRA

    1) ¿Qué deben notificar los fabricantes según el artículo 14 del CRA?
    Vulnerabilidades explotadas activamente e incidentes graves de seguridad, enviados a través de la Plataforma Única de Notificación.

    2) ¿Con qué rapidez deben notificar los fabricantes?
    El plazo comienza cuando el fabricante tiene conocimiento de la vulnerabilidad o del incidente. Se deben seguir los plazos específicos definidos por la plataforma y la orientación correspondiente cuando estén disponibles.

    3) ¿Deben notificarse los productos heredados?
    Sí, si están dentro del ámbito del CRA, incluidos los productos comercializados antes del 11 de diciembre de 2027.

    4) ¿Qué ocurre si la vulnerabilidad procede de un componente de terceros?
    Tanto el fabricante del producto como el del componente (si el componente se comercializa) tienen obligaciones de notificación.

    5) ¿Deben los fabricantes notificar a los usuarios además de a las autoridades?
    Sí. Los usuarios afectados deben ser informados una vez que el fabricante tenga conocimiento del problema.

    Lectura adicional

    Applus+ utiliza cookies propias y de terceros para fines analíticos y para mostrarte publicidad personalizada en base a un perfil elaborado a partir de tus hábitos de navegación (por ejemplo, páginas visitadas). Puedes aceptar todas las cookies pulsando el botón “Aceptar” o configurarlas o rechazar su uso. Para más información, consulta nuestra Política de Cookies. ​

    Panel de configuración de cookies