CRA obligación de reporte de vulnerabilidades para fabricantes de electrónica

En la legislación tradicional de armonización de productos de la UE, como RED, LVD o la Directiva EMC, existen obligaciones post-comercialización (cooperación con las autoridades de vigilancia del mercado, gestión de reclamaciones, acciones correctivas cuando se identifican no conformidades), pero son esencialmente reactivas. Se responde cuando algo se solicita o cuando un problema se hace evidente.

El reporte bajo el CRA cambia esto. El Artículo 14 exige una notificación activa y sujeta a plazos a las autoridades de la UE cuando se detectan determinados eventos de seguridad, no después de que una autoridad de vigilancia del mercado lo solicite, sino de forma proactiva, en un plazo de 24 horas. Para los fabricantes del sector electrónico, esto es estructuralmente diferente a cualquier requisito del marco regulatorio existente.

Hay otra distinción importante. La obligación de reporte también se aplica a productos que ya están en el mercado de la UE, incluidos productos comercializados antes de que el CRA sea plenamente aplicable. Un producto conectado que lleva años en servicio está cubierto por la obligación de reporte desde el 11 de septiembre de 2026, siempre que entre dentro del ámbito de aplicación del reglamento. Las implicaciones para fabricantes con un portfolio de productos activo son significativas, y se tratan en detalle más adelante en este artículo.

El CRA define una vulnerabilidad activamente explotada como una vulnerabilidad respecto a la cual existe evidencia fiable de que un actor malicioso la ha explotado en un sistema sin permiso del propietario (Artículo 3(42)). La clave es evidencia fiable de explotación maliciosa. La mera existencia de una vulnerabilidad no activa la obligación.

Qué sí la activa: un cliente informa de que un atacante ha obtenido acceso no autorizado a través de una debilidad conocida en el firmware de tu producto. Un investigador de seguridad publica evidencia de que una vulnerabilidad en la pila de comunicaciones de tu producto está siendo explotada en campo. Una agencia gubernamental de ciberseguridad te notifica que una vulnerabilidad en un componente que tu producto utiliza ha sido explotada en ataques contra unidades desplegadas.

Igualmente importante es lo que no activa la obligación. Las vulnerabilidades descubiertas a través de actividades autorizadas como pruebas de penetración, programas de bug bounty o evaluaciones de seguridad encargadas por el fabricante no son vulnerabilidades activamente explotadas, siempre que no haya evidencia de explotación maliciosa previa. Una vulnerabilidad descubierta por un hacker ético, sin evidencia de explotación por un actor malicioso, no está sujeta a reporte obligatorio. No obstante, el fabricante puede reportarla voluntariamente conforme al Artículo 15 del CRA.

La segunda categoría cubre incidentes con un impacto grave en la seguridad del producto con elementos digitales. El Artículo 14(5) define el umbral de gravedad: se califica como un incidente si afecta negativamente, o es susceptible de afectar negativamente, la capacidad del producto para proteger la disponibilidad, autenticidad, integridad o confidencialidad de datos o funciones sensibles o importantes. También se califica de esta forma si ha conducido, o es susceptible de conducir, a la introducción o ejecución de código malicioso en el producto o en los sistemas de red e información de un usuario.

Para fabricantes de electrónica, esto podría incluir escenarios como la evidencia de que un mecanismo de actualización OTA comprometido ha distribuido firmware no autorizado a unidades desplegadas, la detección de exfiltración de datos a través de una vulnerabilidad del producto, o la confirmación de que se ha inyectado código malicioso en productos a través de un compromiso en la cadena de suministro que afecta a un componente de firmware.

Los plazos de reporte comienzan cuando el fabricante tiene conocimiento de que una vulnerabilidad está siendo activamente explotada o de que se ha producido un incidente grave. El CRA no prescribe cómo debe obtener el fabricante ese conocimiento. Lo que importa es el momento en que el fabricante dispone de evidencia suficiente para determinar que el evento es notificable.

La guía de la Comisión sobre el CRA reconoce que esta determinación puede no ser inmediata en todos los casos. En algunos, será evidente desde el principio. En otros, puede llevar tiempo establecer si una vulnerabilidad está siendo activamente explotada o si un incidente alcanza el umbral de gravedad. Sin embargo, el énfasis está en actuar con prontitud para llevar a cabo la evaluación inicial, especialmente cuando la vulnerabilidad puede suponer un riesgo significativo.

La implicación práctica es que los fabricantes necesitan un proceso interno capaz de recibir, clasificar y escalar eventos de seguridad con la rapidez suficiente para cumplir el plazo de 24 horas del early warning. Esto no es algo que pueda improvisarse cuando ocurre un evento.

Ambas categorías de eventos notificables siguen una estructura de notificación en tres fases. El fabricante presenta información progresivamente más detallada a medida que avanza la investigación interna. Todas las notificaciones se envían a través de la Single Reporting Platform de ENISA (tratada en una sección separada más adelante).

Aquí es donde el reporte bajo el CRA se vuelve especialmente relevante para los fabricantes de hardware, y donde los retos prácticos difieren más de los que enfrentan las empresas de software puro.

La mayoría de productos electrónicos conectados contienen firmware y componentes de software de múltiples orígenes. El módulo inalámbrico viene con la pila de protocolo del fabricante del chipset. El sistema operativo embebido puede ser un RTOS comercial o una distribución Linux mantenida por un tercero. Librerías de comunicaciones, implementaciones criptográficas, bootloaders, aplicaciones complementarias. La cadena de suministro de software en un producto hardware conectado típico involucra componentes que el fabricante no ha desarrollado y que a menudo no tiene capacidad de modificar directamente.

Bajo el CRA, el fabricante que comercializa el producto en el mercado de la UE es responsable de reportar las vulnerabilidades activamente explotadas contenidas en el producto, independientemente de dónde se originen esas vulnerabilidades. Si una vulnerabilidad en el firmware de un módulo Wi-Fi de terceros está siendo activamente explotada en tu producto, estás obligado a reportarla.

La guía de la Comisión sobre el CRA establece un límite claro en este punto. La obligación se aplica a vulnerabilidades activamente explotadas contenidas en tu producto. Si un componente de terceros tiene una vulnerabilidad conocida, pero esa vulnerabilidad no puede ser explotada en tu producto (porque el código vulnerable no es alcanzable en tu implementación) o no ha sido explotada en tu producto, no se cualifica como vulnerabilidad activamente explotada en tu producto. En ese caso, el reporte obligatorio bajo el Artículo 14 no se activa. Puedes reportarla voluntariamente conforme al Artículo 15, y estás obligado bajo el Artículo 13 a informar al fabricante del componente sobre la vulnerabilidad.

El reto práctico es evidente: para determinar si una vulnerabilidad en un componente de terceros es alcanzable y explotable en tu producto, necesitas visibilidad sobre lo que contiene tu producto. Necesitas saber qué versión de firmware ejecuta tu módulo inalámbrico, qué librerías incluye tu RTOS, qué componentes de código abierto están embebidos en tu bootloader. Este es el vínculo directo entre la obligación de reporte y el requisito de SBOM que formalmente se aplica a partir de diciembre de 2027. Los fabricantes que construyan su bill of materials de software ahora estarán mejor posicionados para clasificar las divulgaciones de vulnerabilidades de terceros frente al plazo de 24 horas cuando lo necesiten.

Existe también una obligación separada que opera en la dirección contraria. Bajo el Artículo 13, cuando un fabricante identifica una vulnerabilidad en un componente integrado en su producto, incluyendo componentes de código abierto, debe reportar esa vulnerabilidad a la persona o entidad que fabrica o mantiene el componente. Esta obligación de reporte aguas arriba existe independientemente de la notificación del Artículo 14 a las autoridades.

El Artículo 69 del CRA hace que las obligaciones de reporte sean aplicables desde el 11 de septiembre de 2026 a todos los productos con elementos digitales dentro del ámbito de aplicación que hayan sido comercializados en el mercado de la UE a partir de esa fecha. Esto significa que la obligación de reporte no se limita a productos nuevos diseñados y fabricados bajo el marco del CRA. Se extiende al portfolio de productos existente del fabricante disponible en el mercado de la UE.

No hay retroactividad en el reporte. Si tenías conocimiento tanto de una vulnerabilidad como de su explotación activa antes del 11 de septiembre de 2026, ese evento específico no requiere notificación. Sin embargo, si conocías una vulnerabilidad antes de esa fecha pero la explotación activa se produce después del 11 de septiembre de 2026, la obligación de reporte se aplica.

Una disposición merece especial atención: la obligación de reporte continúa incluso después de que el periodo de soporte del producto haya finalizado. Las obligaciones de gestión de vulnerabilidades bajo el Anexo I Parte II del CRA (que requieren monitorización continua de vulnerabilidades, remediación y actualizaciones de seguridad) solo se aplican durante el periodo de soporte del producto. Pero la obligación de reportar una vulnerabilidad activamente explotada o un incidente grave persiste más allá de ese periodo. Un fabricante que ha finalizado oficialmente el soporte de un producto sigue obligado a notificar a las autoridades si una vulnerabilidad activamente explotada en ese producto llega a su conocimiento.

Todas las notificaciones bajo el Artículo 14 se envían a través de la Single Reporting Platform (SRP), un sistema electrónico establecido y operado por ENISA conforme al Artículo 16 del CRA. La plataforma consolida lo que de otro modo requeriría notificaciones separadas a múltiples autoridades nacionales en un único envío.

El proceso funciona así: el fabricante inicia sesión, selecciona el CSIRT (Computer Security Incident Response Team) designado al que se dirige la notificación, completa la información requerida y envía. La plataforma enruta automáticamente la notificación al CSIRT designado como coordinador, a los CSIRTs de otros Estados miembros de la UE donde el producto afectado ha sido comercializado, y a ENISA.

El CSIRT coordinador se determina principalmente por el lugar de establecimiento principal del fabricante. Para fabricantes establecidos fuera de la UE, el CSIRT se determina por el establecimiento de su representante autorizado.
Los CSIRTs nacionales también comparten determinada información con sus respectivas autoridades de vigilancia del mercado para apoyar la aplicación de la normativa. El fabricante puede indicar la sensibilidad de la información notificada, y en circunstancias excepcionales, la difusión puede retrasarse conforme al Artículo 16 y al Reglamento Delegado de la Comisión (UE) 2026/881.

La recomendación práctica es registrarse en la plataforma antes de que ocurra un evento notificable. El registro utiliza una cuenta EU Login, que puede crearse con antelación. Esperar a que una vulnerabilidad esté siendo activamente explotada para descubrir cómo funciona la plataforma no es una posición en la que ningún fabricante quiera encontrarse.

La obligación de reporte a las autoridades a través del SRP no es el único requisito de notificación. El Artículo 14 del CRA exige a los fabricantes, tras tener conocimiento de una vulnerabilidad activamente explotada o un incidente grave, informar a los usuarios afectados y, cuando proceda, a todos los usuarios del producto.

La guía de la Comisión sobre el CRA aclara que se trata de una obligación basada en el riesgo y proporcionada. No exige divulgación pública. Para productos utilizados en entornos sensibles o esenciales, divulgar detalles técnicos públicamente podría aumentar los riesgos de ciberseguridad o facilitar una mayor explotación. Los fabricantes pueden limitar la información detallada a los usuarios o clientes relevantes afectados.

Una vez que la vulnerabilidad ha sido adecuadamente tratada o mitigada, una divulgación más amplia puede ser apropiada, especialmente cuando ayuda a los usuarios a verificar que han aplicado la actualización de seguridad o medida correctiva necesaria.

Si un fabricante no informa a los usuarios de manera oportuna, los CSIRTs que recibieron la notificación pueden proporcionar la información a los usuarios directamente, cuando se considere proporcionado y necesario.

El Artículo 64 del CRA clasifica el incumplimiento del Artículo 14 en el nivel sancionador más alto: multas administrativas de hasta 15 millones de euros o el 2,5% de la facturación anual mundial, lo que sea mayor. Este es el mismo nivel que se aplica al incumplimiento de los requisitos esenciales de ciberseguridad.

Hay una excepción importante para las empresas más pequeñas. Las microempresas y pequeñas empresas están explícitamente exentas de multas administrativas por no cumplir el plazo de 24 horas del early warning. Esta exención cubre solo la primera fase de notificación, no la notificación de 72 horas, el informe final ni ninguna otra obligación de reporte. La justificación reconoce que los fabricantes muy pequeños pueden no tener la capacidad interna para enviar en 24 horas, pero la expectativa es que reporten dentro de los plazos posteriores.

También conviene señalar que el CRA no sanciona el sobre-reporte razonable. Si un fabricante tiene dudas sobre si una vulnerabilidad está siendo activamente explotada, presentar el early warning es la opción más segura. La notificación puede reclasificarse o cerrarse posteriormente a medida que avanza la investigación.

Más allá de las multas administrativas, hay una consideración secundaria. La Directiva de Responsabilidad por Productos Defectuosos (Directiva (UE) 2024/2853) establece que los fabricantes pueden ser responsables por los daños causados por productos defectuosos, incluidos los productos con elementos digitales. Una vulnerabilidad que el fabricante conocía pero que no reportó ni trató podría ser relevante en un contexto de responsabilidad por producto si un usuario sufre daños como consecuencia. Ambas regulaciones operan de forma independiente, pero la interacción práctica refuerza la conveniencia de un reporte y remediación oportunos.

La obligación de reporte es el primer plazo concreto dentro de un calendario CRA más amplio. Para los fabricantes que planifican su estrategia de cumplimiento, la imagen completa es la siguiente:

Ya en vigor (desde el 11 de septiembre de 2026): reporte de vulnerabilidades e incidentes a través de la Single Reporting Platform. Se aplica a todos los productos dentro del ámbito de aplicación que ya están en el mercado de la UE.

Desde el 11 de diciembre de 2027: el CRA completo pasa a ser aplicable. Ciberseguridad por diseño, procesos de gestión de vulnerabilidades durante todo el periodo de soporte, SBOM en formato legible por máquina, evaluación de riesgos de ciberseguridad, documentación técnica, evaluación de conformidad, Declaración de Conformidad UE y marcado CE para ciberseguridad.

Para los fabricantes que ya trabajan en el cumplimiento de los requisitos de ciberseguridad de la RED bajo el Artículo 3.3, existe un solapamiento sustancial. La serie de normas EN 18031, desarrollada originalmente para los actos delegados de la RED sobre los Artículos 3.3(d), (e) y (f), constituye el punto de partida para las normas horizontales del CRA que desarrollan CEN-CENELEC y ETSI. Los fabricantes que ya han invertido en el cumplimiento de RED 3.3 encontrarán que gran parte de ese trabajo se traslada a la evaluación de conformidad del CRA.

La obligación de reporte debe verse como el punto de entrada, no como una tarea aislada. Construir ahora los procesos internos de detección, clasificación y reporte establece la base para las obligaciones más amplias de gestión de vulnerabilidades que se aplican a partir de diciembre de 2027.