La plataforma de ENISA centraliza desde el 11 de septiembre el reporte de vulnerabilidades bajo explotación activa para todo fabricante que venda productos digitales en la UE
El 11 de septiembre de 2026 la Agencia de Ciberseguridad de la Unión Europea puso en marcha la Plataforma Única de Reporte del Cyber Resilience Act, el mismo día en que entraron en vigor las obligaciones de notificación para fabricantes bajo esa normativa. Cualquier empresa que coloque un producto con elementos digitales en el mercado europeo queda desde esa fecha obligada a reportar vulnerabilidades activamente explotadas y incidentes graves a través de ese portal centralizado. ENISA construyó la herramienta y gestiona su operación diaria, según lo establece el Artículo 16(1) del CRA.
El fin del reporte fragmentado en 27 jurisdicciones
Hasta ahora, un fabricante con presencia en múltiples Estados miembros de la UE enfrentaba un mosaico de canales de notificación nacionales, cada uno con sus propios formularios, plazos y criterios de severidad. La Plataforma Única de Reporte elimina esa fragmentación: un solo punto de entrada para cumplir con la obligación legal en los 27 países del bloque. ENISA diseñó el sistema para que el reporte llegue simultáneamente a las autoridades nacionales competentes y a la propia agencia, que coordina la respuesta a nivel comunitario.
El CRA define como reportables las vulnerabilidades que están siendo explotadas en la práctica — no las teóricas ni las que solo tienen prueba de concepto — y los incidentes que cumplen el umbral de gravedad establecido en el reglamento. La plataforma no reemplaza los canales de coordinación de vulnerabilidades existentes como CERT-EU o los CSIRT nacionales, pero sí se convierte en el canal legal obligatorio para cumplir con el CRA. Un fabricante que detecte explotación activa de una falla en su producto tiene ahora un plazo definido desde el momento en que toma conocimiento del hecho, y el reloj arranca con la activación de esta plataforma.
Por qué importa para fabricantes fuera de Europa
El alcance territorial del CRA no se limita a empresas con sede en la UE. Cualquier fabricante — esté radicado en San Pablo, Buenos Aires, Ciudad de México o Palo Alto — que venda o distribuya productos con componentes digitales en el mercado europeo queda sujeto a la obligación de reporte. Esto incluye desde dispositivos IoT y routers hasta software embebido en electrodomésticos o sistemas de control industrial. La norma sigue la lógica extraterritorial del GDPR: si tu producto llega al consumidor o la empresa europea, cumplís con la ley europea.
Para fabricantes latinoamericanos con exportaciones a Europa, esto representa un cambio operativo concreto. Una empresa argentina que vende terminales de punto de venta con software propio, o una brasileña que exporta cámaras de seguridad IP, necesita ahora procesos internos para detectar explotación activa de vulnerabilidades en sus productos y reportarlas a ENISA dentro del plazo legal. No hacerlo expone a sanciones que el CRA establece como porcentaje del volumen de negocios global — el mismo modelo de multas que hizo del GDPR una norma con dientes reales.
El patrón que ya vimos con NIS2 y que ahora se repite
La activación de la plataforma sigue el mismo esquema de implementación escalonada que la UE aplicó con la Directiva NIS2: primero se publica la norma, luego se da un período de transición para que los Estados miembros adapten legislación nacional y las agencias construyan infraestructura, y finalmente se activa la obligación con fecha fija y herramienta operativa. ENISA ya había probado este modelo con el registro de nombres de dominio de alto riesgo bajo NIS2; la Plataforma Única de Reporte es la versión del CRA de ese mismo enfoque.
La diferencia clave está en el alcance: mientras NIS2 apunta a operadores de servicios esenciales e importantes, el CRA cubre productos — un universo mucho más amplio. Cada fabricante de hardware con firmware actualizable, cada desarrollador de software que se distribuya en la UE, cada integrador que arme soluciones con componentes de terceros, entra en el radar. La plataforma de ENISA se convierte así en el punto de agregación de inteligencia sobre vulnerabilidades explotadas en productos digitales a escala continental, un dataset que ninguna agencia nacional podría construir sola.
Qué queda sin resolver en la primera versión operativa
La activación del 11 de septiembre marca el inicio de la obligación legal, pero varios aspectos del flujo de reporte todavía están en proceso de definición. ENISA no publicó aún guías detalladas sobre cómo determinar si una vulnerabilidad cruza el umbral de «activamente explotada» — si basta con evidencia de escaneo masivo, si se requiere confirmación de compromiso exitoso, o si el reporte de un solo incidente en producción ya dispara la obligación. Tampoco está claro cómo se coordinará el reporte cuando una vulnerabilidad afecta a múltiples fabricantes que usan el mismo componente de terceros: ¿reporta cada uno por separado, o hay un mecanismo de reporte coordinado para fallas en dependencias compartidas?
Para fabricantes latinoamericanos, la incertidumbre más concreta es cómo se integra este reporte con las obligaciones locales. Si una empresa mexicana detecta explotación de una falla en un producto que vende tanto en Europa como en México, ¿debe reportar dos veces, una a ENISA y otra a la autoridad mexicana? ¿O el reporte a ENISA cuenta como cumplimiento si México adopta un esquema de reconocimiento mutuo? Esas preguntas no tienen respuesta todavía, porque la mayoría de los países de la región no tienen marcos legales equivalentes al CRA — y los que están desarrollando normativa de ciberseguridad para productos (como Brasil con su proyecto de ley de IoT seguro) no han definido aún cómo se articularán con el régimen europeo.
Nuestro análisis
La Plataforma Única de Reporte convierte al CRA en la primera normativa que obliga a fabricantes globales a notificar vulnerabilidades bajo explotación con un estándar común y un canal centralizado. Esto cambia la dinámica de divulgación: hasta ahora, un fabricante podía elegir si reportaba públicamente una falla explotada o la gestionaba en silencio mientras desarrollaba un parche. Con el CRA, esa discreción desaparece para cualquier producto que toque el mercado europeo — la explotación activa dispara una obligación legal de reporte, independientemente de si el fabricante ya tiene solución lista o no.
El modelo tiene precedente en sectores regulados como aviación o farmacéutica, donde los eventos adversos se reportan a autoridades centrales aunque el fabricante no tenga todavía la causa raíz identificada. La novedad es aplicarlo a productos digitales con ciclos de actualización semanales y cadenas de suministro de software con cientos de dependencias transitivas. ENISA va a recibir un volumen de reportes que ninguna agencia de ciberseguridad procesó antes a esa escala, y la calidad de la inteligencia resultante dependerá de qué tan bien los fabricantes distingan entre ruido (escaneo automatizado, investigación de seguridad) y señal real (explotación con impacto en usuarios). Los primeros seis meses de operación de la plataforma van a mostrar si el umbral de «activamente explotada» está calibrado para capturar amenazas reales o si termina inundado de reportes defensivos de fabricantes que notifican cualquier actividad sospechosa para cubrirse legalmente.
¿Qué pasa cuando el primer fabricante latinoamericano enfrente una multa por no reportar a tiempo una vulnerabilidad explotada en Europa, y descubra que su proceso interno de gestión de incidentes no estaba diseñado para cumplir con plazos legales europeos?