El Cyber Resilience Act empezó a exigir algo muy concreto esta misma semana: que cualquier empresa que desarrolle software con elementos digitales notifique en 24 horas una vulnerabilidad que esté siendo explotada. No es una norma pensada solo para fabricantes de hardware ni para multinacionales del software: alcanza a agencias que venden un SaaS propio, a quien distribuye un plugin de WordPress o una app, y deja fuera, con matices, el desarrollo a medida para un único cliente. Si tu equipo técnico o de marketing gestiona algún producto digital propio, esto es lo que cambia y lo que conviene revisar antes de que llegue el primer aviso de un fallo real.
El Cyber Resilience Act, en vigor desde el 11 de septiembre de 2026, obliga a fabricantes de software y hardware con elementos digitales a notificar a ENISA cualquier vulnerabilidad explotada activamente en un máximo de 24 horas, con informe completo a las 72 horas y cierre en 14 días. Las multas llegan a 15 millones de euros.
Qué cambia con el Cyber Resilience Act
El Cyber Resilience Act es el Reglamento (UE) 2024/2847, la primera norma europea que fija requisitos de ciberseguridad para todo producto con elementos digitales que se vende en la Unión Europea, desde una cámara conectada hasta un plugin de pago. Entró en vigor en diciembre de 2024, pero se aplica por fases: los requisitos técnicos completos, cifrado, actualizaciones de seguridad y gestión de vulnerabilidades, no son exigibles hasta el 11 de diciembre de 2027. Lo que sí es ya obligatorio, desde el 11 de septiembre de 2026, es el artículo 14: notificar cualquier vulnerabilidad explotada activamente o incidente grave. La Comisión Europea detalla el calendario en su página sobre obligaciones de notificación: primero llega este deber de aviso, después la certificación completa. Para un equipo de desarrollo, la fecha que importa hoy no es 2027, es la de esta semana.
Quién debe notificar vulnerabilidades ya
El reglamento llama «fabricante» a quien pone en el mercado un producto con elementos digitales: cubre tanto un dispositivo físico como un software distribuido a un número indeterminado de clientes. La frontera está en si ese software es un producto o un encargo puntual.
Software vendido como producto sí entra
Si desarrollas un SaaS propio que vendes a varios clientes, un plugin o tema de pago para WordPress, o una app distribuida en una tienda, eres fabricante a efectos del reglamento desde que ese software llega al mercado europeo con tu nombre detrás. No importa si lo aloja un tercero ni si el negocio es pequeño: la obligación de notificar corre igual para una empresa de dos personas en Barcelona que para un fabricante con miles de empleados. Solo cambia con el tamaño la sanción económica, nunca el deber de avisar.
El encargo a medida para un cliente
El desarrollo a medida que se factura para un único cliente, sin distribuirlo a nadie más, no encaja en la definición de «producto puesto en el mercado» y en principio queda fuera: es un servicio, no un producto. La frontera es fácil de cruzar sin darse cuenta. Una tienda online construida para un cliente concreto es un encargo; el mismo código vendido después a otros diez clientes como plantilla deja de serlo. Antes de cerrar un proyecto, conviene revisar si ese desarrollo se reutiliza o se distribuye más allá del cliente original.
Los plazos que impone la notificación
El artículo 14 del reglamento fija tres avisos sucesivos, no uno solo, y el reloj arranca en cuanto el equipo técnico tiene constancia del problema, no cuando ya está confirmado del todo:
- Aviso temprano, en 24 horas: qué producto y qué tipo de vulnerabilidad o incidente, sin necesidad de tener todavía la causa.
- Notificación completa, en 72 horas: gravedad, indicadores técnicos y, si existen, medidas correctoras que ya se estén aplicando.
- Informe final, en 14 días si la vulnerabilidad estaba siendo explotada, o en un mes si se trata de un incidente grave: qué pasó y cómo se ha corregido.
Todo se envía a través de la Single Reporting Platform que opera ENISA, que reenvía el aviso al mismo tiempo al CSIRT del país donde está establecido el fabricante; en España, INCIBE-CERT. El texto completo de la obligación está en el Reglamento (UE) 2024/2847, publicado en el Diario Oficial de la Unión Europea.
El reglamento considera incidente grave aquel que afecta de forma significativa a la disponibilidad, la confidencialidad o la integridad de los datos o servicios de un producto con elementos digitales, más allá de un fallo puntual sin impacto real para quien lo usa.
Cómo detectar un fallo explotado a tiempo
El plazo de 24 horas no da margen para averiguarlo sobre la marcha: hay que saber ya, antes de que ocurra, de dónde puede venir el aviso. La mayoría de vulnerabilidades explotadas no nacen en el código propio, sino en una dependencia de terceros: una librería de npm, un plugin de WordPress desactualizado, una API externa. Tener un inventario de qué componentes usa cada producto, y quién los vigila, es lo que permite detectar el problema en horas y no en semanas. Ya hemos visto cómo los paquetes npm maliciosos se cuelan en el árbol de dependencias sin que nadie los instale a propósito, y cómo buena parte de las vulnerabilidades en plugins de WordPress siguen sin parche meses después de publicarse. Un equipo que ya monitoriza eso no añade trabajo nuevo con el Cyber Resilience Act: solo cambia lo que hace con la información que ya tenía.
Multas del Cyber Resilience Act a las pymes
Las sanciones del reglamento llegan hasta 15 millones de euros o el 2,5% de la facturación global, la cifra que más pese, en los incumplimientos más graves de los requisitos de producto. El artículo 14 tiene un matiz que conviene conocer: las pymes y microempresas no pueden ser sancionadas económicamente solo por llegar tarde a notificar una vulnerabilidad, aunque la obligación de notificar sigue existiendo igual. En la práctica eso no es una puerta abierta a ignorarlo: el CSIRT nacional puede exigir igualmente que se corrija el fallo, y un cliente que descubre que su proveedor no avisó de una brecha activa no vuelve a confiarle el mantenimiento. Antes de la próxima auditoría, vale la pena revisar con quien lleva la seguridad informática del negocio qué productos propios existen y cuáles de ellos entran en el ámbito del reglamento.
Preguntas frecuentes sobre el Cyber Resilience Act
¿Qué cuenta como vulnerabilidad explotada activamente?
Una vulnerabilidad explotada activamente es aquella de la que hay indicios fiables de que alguien la está usando para atacar un sistema real, no solo la que se acaba de publicar o corregir. Un aviso de un investigador sin explotación confirmada no activa el plazo de 24 horas; un ataque real detectado en producción sí.
¿Un plugin gratuito de WordPress está sujeto al reglamento?
Si se distribuye en el curso de una actividad comercial, sí, aunque no se cobre por descargarlo: el reglamento habla de poner en el mercado, no de vender. El software libre de un proyecto sin ánimo de lucro tiene un régimen más ligero, pero un plugin gratuito que capta clientes para una agencia no entra en esa excepción.
¿Qué pasa si no notifico a tiempo?
Las grandes empresas se exponen a la sanción del artículo 64: hasta 15 millones de euros o el 2,5% de su facturación mundial. Las pymes y microempresas quedan fuera de esa multa concreta, pero el CSIRT puede seguir exigiendo la corrección del fallo, y el incidente sin notificar queda documentado igualmente.
¿Cómo se envía la notificación a ENISA?
A través de la Single Reporting Platform que opera ENISA, operativa desde el 11 de septiembre de 2026: un único formulario online que reenvía el aviso al mismo tiempo al CSIRT del país donde está establecido el fabricante, sin tener que repetir la notificación por duplicado en cada Estado miembro.
Fuente: Comisión Europea — Cyber Resilience Act, obligaciones de notificación