El Cyber Resilience Act ya está en marcha: Europa impone la regla de las 24 horas para vulnerabilidades e incidentes de productos digitales
Europa acaba de activar una de las piezas más importantes de su nueva arquitectura de ciberseguridad. Desde el 11 de septiembre de 2026, los fabricantes de productos con elementos digitales comercializados en la Unión Europea tienen que comunicar determinadas vulnerabilidades explotadas activamente y los incidentes graves que afecten a la seguridad de sus productos. Es el primer gran bloque de obligaciones del Cyber Resilience Act (CRA) que entra en aplicación y supone un cambio importante para fabricantes de hardware y software: descubrir que un producto está siendo atacado ya no desencadena únicamente una respuesta técnica interna, sino también un reloj regulatorio que puede empezar a correr inmediatamente.
El Cyber Resilience Act es el Reglamento europeo que introduce requisitos horizontales de ciberseguridad para los denominados “products with digital elements”. Su alcance es muy amplio: puede comprender desde software, aplicaciones y determinados programas informáticos hasta dispositivos IoT, routers, cámaras, smartwatches, sistemas domésticos conectados, componentes digitales y numerosos productos industriales. El principio que introduce Europa es sencillo pero profundo: un producto digital no debería considerarse terminado cuando sale al mercado. Su fabricante tiene que gestionar la ciberseguridad durante su ciclo de vida, identificar vulnerabilidades, proporcionar actualizaciones de seguridad y mantener mecanismos que permitan responder cuando aparece una amenaza.
El reloj empieza a correr: 24 horas
La gran novedad que ya está operativa es el artículo 14 del CRA. Cuando un fabricante tenga conocimiento de una vulnerabilidad contenida en uno de sus productos que esté siendo explotada activamente, debe realizar una primera comunicación en un plazo máximo de 24 horas. Lo mismo ocurre cuando detecta un incidente grave que afecta a la seguridad del producto. Esa primera comunicación funciona como una alerta temprana y no exige necesariamente disponer ya de toda la investigación terminada. Precisamente por eso existe una segunda etapa: dentro de las 72 horas debe presentarse una notificación más completa con la información disponible sobre el evento, su naturaleza y las medidas adoptadas o previstas.
El proceso continúa posteriormente. Cuando se trata de una vulnerabilidad explotada activamente, el informe final debe presentarse como máximo 14 días después de que esté disponible una medida correctora o mitigadora. En el caso de un incidente grave, el informe final debe presentarse dentro del mes siguiente a la notificación inicial, según el calendario establecido por el Reglamento y explicado por la Comisión.
Esto introduce una consecuencia empresarial muy concreta: 72 horas ya no son el primer plazo; el primer plazo son 24. Una compañía que tarde dos días en conseguir que Ingeniería comunique un problema a Legal o Compliance puede haber consumido ya el plazo regulatorio antes de haber decidido siquiera si debe notificar.
ENISA estrena una plataforma única europea
Para gestionar estas comunicaciones, ENISA —la Agencia de la Unión Europea para la Ciberseguridad— acaba de poner en funcionamiento la CRA Single Reporting Platform (SRP). La plataforma permite que el fabricante realice una única notificación en lugar de tener que informar individualmente a múltiples autoridades nacionales. El fabricante selecciona el CSIRT coordinador correspondiente, normalmente determinado por su principal establecimiento, y la información queda simultáneamente disponible para ENISA; posteriormente puede distribuirse a los demás CSIRT y autoridades relevantes cuando el producto se comercializa en otros Estados miembros.
Esto también significa que Europa empieza a construir una visión centralizada de las vulnerabilidades que están siendo explotadas contra productos digitales presentes en el mercado europeo. Ya no se trata únicamente de recibir denuncias. La información agregada permitirá a ENISA y a las autoridades nacionales detectar patrones, productos afectados, amenazas emergentes y ataques que puedan extenderse simultáneamente por varios países.
La plataforma está disponible oficialmente desde el 11 de septiembre y ENISA ha publicado manuales, tutoriales, glosario y documentación para las personas designadas por las empresas como responsables de realizar las comunicaciones. En esta primera fase, la plataforma se utiliza para las notificaciones obligatorias de vulnerabilidades explotadas activamente e incidentes graves. ENISA señala además que inicialmente no existe una API para automatizar directamente las comunicaciones, aunque las empresas sí pueden automatizar sus procesos internos de detección y preparación de la información.
La obligación afecta también a productos que ya estaban en el mercado
Este es uno de los aspectos que las empresas deberían revisar con mayor cuidado. Las obligaciones de reporting no se limitan exclusivamente a nuevos productos lanzados después del 11 de septiembre. La Comisión y ENISA aclaran que alcanzan también a productos con elementos digitales que ya estaban comercializados anteriormente, siempre que estén dentro del ámbito del CRA.
Existe, no obstante, una precisión importante. El fabricante no tiene que comunicar retroactivamente una explotación activa que ya conocía antes del 11 de septiembre de 2026. Pero si después de esa fecha descubre que una vulnerabilidad está siendo explotada activamente, la obligación puede activarse aunque la vulnerabilidad o el propio producto sean anteriores.
Esto obliga a muchas organizaciones a mirar hacia atrás. El inventario relevante no debería contener únicamente los productos que se están desarrollando actualmente, sino también el parque instalado y las versiones de software que siguen presentes en el mercado europeo.
Una vulnerabilidad de un proveedor también puede convertirse en tu problema
La cuestión se vuelve todavía más interesante cuando pensamos en cómo se construye actualmente el software. Pocas compañías desarrollan todos sus componentes internamente. Aplicaciones y dispositivos incorporan librerías, frameworks, componentes open source, SDK, firmware y software suministrado por terceros. Una vulnerabilidad puede aparecer en cualquiera de esas capas.
Por eso el CRA obliga a evolucionar desde una visión del producto como elemento aislado hacia una visión de cadena de suministro digital. El fabricante necesita saber qué componentes contiene su producto, qué versiones utiliza, qué proveedores intervienen y cómo puede determinar rápidamente qué productos están afectados cuando aparece una nueva vulnerabilidad.
Para muchas organizaciones esto convertirá prácticas como Software Bill of Materials (SBOM), gestión de dependencias, vulnerability management y trazabilidad de componentes en elementos centrales de Compliance, no únicamente de Ingeniería.
El verdadero problema empresarial: 24 horas exigen una organización preparada antes del incidente
La principal dificultad del CRA probablemente no será rellenar el formulario de ENISA. Será conseguir que una compañía sea capaz de detectar, clasificar, escalar y decidir dentro del plazo.
Imaginemos que un sábado por la noche el SOC detecta actividad anómala sobre una vulnerabilidad de un producto. Seguridad inicia una investigación. Ingeniería necesita comprobar qué versiones están afectadas. Producto debe identificar cuántos clientes utilizan esas versiones. Legal tiene que determinar si el evento entra en el ámbito del CRA. Dirección necesita conocer el riesgo reputacional. Comunicación debe preparar potencialmente información para usuarios. Mientras todo esto ocurre, el reloj de 24 horas puede estar corriendo.
El CRA convierte por tanto la gestión de vulnerabilidades en un proceso transversal que debería involucrar como mínimo Cybersecurity, Engineering, Product, Legal, Compliance, Customer Support y Dirección.
Las empresas deberían definir previamente quién tiene autoridad para clasificar un evento como potencialmente notificable, quién controla el reloj regulatorio, quién está autorizado para utilizar la plataforma de ENISA, quién aprueba la comunicación y quién coordina posteriormente las medidas correctoras.
La IA amplía todavía más el alcance empresarial del CRA
Para compañías que desarrollan productos con inteligencia artificial, el CRA adquiere una importancia adicional. Un sistema puede estar simultáneamente sujeto a requisitos derivados del AI Act y a obligaciones de ciberseguridad del Cyber Resilience Act, dependiendo de su naturaleza, función y comercialización.
Pensemos en robots, dispositivos médicos inteligentes, sistemas IoT, vehículos conectados, maquinaria industrial, wearables o productos físicos que incorporan modelos de IA. El AI Act puede regular determinados aspectos relacionados con el riesgo y utilización de la inteligencia artificial, mientras el CRA se ocupa de la resiliencia cibernética del producto digital.
Esto hace cada vez menos razonable mantener AI Governance y Cybersecurity Governance completamente separadas. Un ataque puede modificar el comportamiento de un sistema de IA; una vulnerabilidad puede comprometer datos o modelos; un agente puede disponer de permisos que permitan actuar sobre otros sistemas. Seguridad, gobernanza de IA y Compliance empiezan a converger.
El 11 de diciembre de 2027 llegará la segunda gran fase
Es importante diferenciar lo que acaba de entrar en aplicación de lo que todavía está por llegar. El CRA no está aplicándose todavía en su totalidad. Las obligaciones de notificación comenzaron el 11 de septiembre de 2026, mientras que los principales requisitos del Reglamento serán aplicables desde el 11 de diciembre de 2027.
Entonces el impacto será mucho mayor. Los fabricantes deberán cumplir requisitos de ciberseguridad durante el diseño, desarrollo, producción y mantenimiento de los productos; realizar evaluaciones de riesgo; gestionar vulnerabilidades; proporcionar actualizaciones de seguridad y mantener documentación que permita demostrar conformidad. El marcado CE servirá también para identificar productos que cumplen los requisitos correspondientes del CRA.
Por tanto, septiembre de 2026 no debería interpretarse como el final de la adaptación, sino como el comienzo operativo. Las compañías tienen aproximadamente quince meses para transformar las obligaciones de producto restantes en procesos industriales estables.
Qué debería hacer ahora una empresa
La primera prioridad debería ser determinar qué productos de la compañía entran dentro del ámbito del CRA. Después, identificar quién figura jurídicamente como fabricante y qué importadores, distribuidores, proveedores tecnológicos y componentes intervienen. A continuación debería existir un inventario técnico suficientemente detallado para determinar rápidamente qué versiones y clientes están afectados por una vulnerabilidad.
La segunda prioridad es construir un CRA Incident Reporting Playbook. Desde el momento en que aparece una posible explotación activa debe existir un procedimiento que responda automáticamente a cinco preguntas: quién evalúa, quién escala, quién decide, quién comunica y quién corrige. El proceso tiene que diseñarse alrededor del plazo de 24 horas, no alrededor de las reuniones internas habituales de la organización.
La tercera prioridad es probarlo. Una empresa no debería descubrir durante un incidente real que nadie tiene acceso a la plataforma de ENISA, que no está claro cuál es el CSIRT correspondiente o que Ingeniería y Legal utilizan criterios distintos para determinar cuándo empieza el reloj. Un tabletop exercise simulando una vulnerabilidad explotada activamente puede revelar en unas horas problemas organizativos que de otro modo aparecerían durante una crisis real.
Europa empieza a regular el producto digital durante todo su ciclo de vida
La trascendencia del Cyber Resilience Act va más allá de una nueva obligación de reporting. Europa está introduciendo un principio que puede cambiar la forma de desarrollar tecnología: la ciberseguridad deja de ser una característica adicional y pasa a convertirse en una obligación inherente al producto.
Hasta ahora una compañía podía considerar terminada gran parte de su responsabilidad cuando comercializaba determinado software o dispositivo. El CRA extiende esa responsabilidad durante su ciclo de vida. Vulnerabilidades, actualizaciones, soporte y respuesta ante incidentes pasan a formar parte de la relación regulatoria entre fabricante, producto y mercado.
Y desde el 11 de septiembre de 2026, esa transformación ya no pertenece únicamente al futuro. El primer reloj ha empezado a correr.
24 horas para alertar. 72 horas para ampliar la información. Después, corregir, documentar y demostrar qué se ha hecho.
Para los consejos de administración, el mensaje debería ser sencillo: el Cyber Resilience Act ya no es una regulación para preparar en 2027. Una parte de sus obligaciones ya está en vigor.
Descubre más desde THE INTELLIGENCE
Suscríbete y recibe las últimas entradas en tu correo electrónico.
