24 horas para avisar, también de lo que vendiste hace años
Desde el 11 de septiembre de 2026, el fabricante que vende en la Unión Europea un producto con elementos digitales (una máquina con autómata, un router, una cámara IP, un programa comercial) tiene 24 horas para dar la primera alerta cuando sabe que alguien está aprovechando una vulnerabilidad de ese producto, o cuando sufre un incidente grave que afecta a su seguridad. Lo exige el artículo 14 del Cyber Resilience Act, el Reglamento (UE) 2024/2847, y el aviso se presenta en la plataforma única que ENISA abrió ese mismo día. Casi todo lo demás no se aplica hasta el 11 de diciembre de 2027. Esta obligación ya corre, y alcanza a los productos que ya están en el mercado.
Las obligaciones de notificación del artículo 14 “se aplicarán a todos los productos con elementos digitales que entren en el ámbito de aplicación del presente Reglamento y hayan sido introducidos en el mercado antes del 11 de diciembre de 2027”. El resto de exigencias del reglamento, como el diseño seguro o el periodo mínimo de soporte, sólo alcanza a esos productos antiguos si sufren una modificación sustancial. El deber de avisar, en cambio, les llega desde ya.
Si fabricas maquinaria, cuadros de control o equipos para instalaciones, lo normal es que al oír “ciberseguridad” pienses en los ordenadores de la oficina y en el correo con la factura falsa. Esta norma va del producto que sale por tu puerta. Muchas pymes industriales no se ven como empresas tecnológicas y, sin embargo, sus máquinas llevan firmware, se conectan a la red del cliente para el mantenimiento remoto o se configuran desde una aplicación, y eso puede bastar para quedar dentro.
El aviso de 24 horas es además sólo el principio. Después llegan el parche, la comunicación a los clientes, a veces la retirada, y la pregunta que de verdad cuesta dinero: quién paga si el fallo llega a causar daños. Esa parte es la nuestra, y la dejamos para el final.
- Qué productos entran en el Cyber Resilience Act
- Qué hay que notificar, a quién y en qué plazos
- Multas, y lo que España aún no ha aprobado
- Cuando una vulnerabilidad convierte el producto en defectuoso
- Qué seguro responde de cada consecuencia
- Qué dejar preparado antes del primer aviso
- Preguntas frecuentes
Qué productos entran en el Cyber Resilience Act
El reglamento define producto con elementos digitales como el “producto consistente en programas informáticos o equipos informáticos y sus soluciones de procesamiento de datos remoto”, incluidos los componentes que se venden por separado (artículo 3.1). Y lo aplica a todos aquellos cuyo uso previsto o razonablemente previsible incluya “una conexión de datos directa o indirecta, lógica o física, a un dispositivo o red” (artículo 2.1). Esa última frase es la que hace grande el perímetro. No hace falta que el producto navegue por internet: basta con que se conecte a algo, aunque sea por cable a un ordenador de taller.
En la práctica entran una máquina herramienta con control numérico y acceso remoto del servicio técnico, un cuadro eléctrico con autómata programable, sensores y pasarelas de IoT industrial, routers y switches, cámaras y grabadores de videovigilancia, lectores de control de accesos, termostatos, persianas y electrodomésticos conectados, equipos de pesaje o de etiquetado que hablan con el ERP del cliente, y el software que se vende como producto, por licencia o descarga.
Si en tu línea de producto hay algo de esto, conviene leer también lo que contamos en seguros para industria y fabricación, porque la exposición no se queda en el reglamento.
Quedan fuera los productos que ya tienen su propia norma europea de seguridad: los sanitarios y los de diagnóstico in vitro (Reglamentos 2017/745 y 2017/746), los vehículos homologados (Reglamento 2019/2144), los certificados para aviación civil, los equipos marinos, las piezas de recambio idénticas y lo que se fabrica sólo para defensa o seguridad nacional (artículo 2).
El aviso de septiembre obliga sólo al fabricante. Quien importa o distribuye tendrá deberes propios a partir del 11 de diciembre de 2027, cuando se apliquen los artículos 19 y 20: si conoce una vulnerabilidad, informar al fabricante “sin demora indebida” y, si hay un riesgo de ciberseguridad significativo, avisar “inmediatamente” a las autoridades de vigilancia del mercado; y si el fabricante cierra, informar él a las autoridades y a los usuarios. Una empresa española que trae de fuera un equipo con controlador y lo vende con su catálogo tiene, por tanto, fecha marcada en el calendario, y le conviene saber ya cómo se enteraría de un fallo de su proveedor.
Qué hay que notificar, a quién y en qué plazos
Hay dos supuestos, y ninguno es “cualquier fallo”. El primero es la vulnerabilidad aprovechada activamente, aquella “respecto de la cual existen pruebas fiables de que un agente malintencionado la ha aprovechado en un sistema sin autorización del propietario del sistema” (artículo 3.42). Un error que tu equipo encuentra en pruebas y que nadie ha usado no activa este aviso.
El segundo es el incidente grave: el que afecta o puede afectar a la capacidad del producto para proteger la disponibilidad, la autenticidad, la integridad o la confidencialidad de datos o funciones sensibles o importantes, o el que lleva o puede llevar a introducir o ejecutar código malicioso en el producto o en la red y los sistemas del usuario (artículo 14.5). Un servidor de actualizaciones comprometido que distribuye un firmware manipulado es el ejemplo de manual.
| Plazo | Vulnerabilidad aprovechada activamente | Incidente grave |
|---|---|---|
| Alerta temprana: 24 horas | Desde que el fabricante tiene conocimiento. Indica, si se sabe, en qué Estados miembros se ha comercializado el producto (art. 14.2.a) | Debe decir como mínimo si se sospecha que el incidente se debe a actos ilegales o malintencionados (art. 14.4.a) |
| Notificación: 72 horas | Producto afectado, naturaleza de la vulnerabilidad y cómo se aprovecha, medidas adoptadas y medidas que pueden tomar los usuarios (art. 14.2.b) | Naturaleza del incidente, evaluación inicial y medidas correctoras o paliativas, propias y de los usuarios (art. 14.4.b) |
| Informe final | A más tardar 14 días después de que exista una medida correctora o paliativa (art. 14.2.c) | En el plazo de un mes desde la notificación de las 72 horas, no desde el incidente (art. 14.4.c) |
Todo se presenta en la plataforma única de notificación de ENISA, que reparte el aviso a la vez al CSIRT coordinador del país donde el fabricante tiene su establecimiento principal y a la propia ENISA (artículos 14.1 y 14.7). Para España, la lista oficial de ENISA remite a INCIBE-CERT. La plataforma arrancó el 11 de septiembre con lo que ENISA llama capacidad operativa inicial, y la agencia ha anunciado que irá ampliando funciones en los próximos meses.
Luego viene lo que casi nadie lee. El artículo 14.8 obliga al fabricante a informar a los usuarios afectados, y cuando proceda a todos, de la vulnerabilidad o del incidente y de lo que pueden hacer para protegerse. Si no lo hace a tiempo, puede hacerlo el CSIRT por su cuenta. Para eso hay que saber a quién se vendió cada unidad, y en muchas empresas esa lista sólo la tiene el distribuidor.
Multas, y lo que España aún no ha aprobado
Incumplir el artículo 14 está en el tramo más alto de sanciones: hasta 15 millones de euros o, si es mayor, hasta el 2,5 % del volumen de negocio mundial del ejercicio anterior (artículo 64.2).
Hay una excepción que conviene conocer bien porque es más estrecha de lo que parece. Una corrección de errores publicada en el Diario Oficial de la UE el 2 de julio de 2025 dejó el artículo 64.10 así: a las microempresas y pequeñas empresas no se les impone multa por no cumplir el plazo de la alerta temprana de 24 horas. Sólo ese. La notificación de las 72 horas y el informe final les obligan igual que a una multinacional.
Los importes concretos y el procedimiento los tiene que fijar cada Estado (artículo 64.1). En España, el Proyecto de Real Decreto que designa las autoridades del reglamento está en tramitación. Según el informe que emitió la CNMC el 13 de mayo de 2026, prevé que la Secretaría de Estado de Telecomunicaciones e Infraestructuras Digitales sea la autoridad de vigilancia del mercado, el Centro Criptológico Nacional la autoridad notificante e INCIBE el laboratorio técnico de apoyo. A finales de septiembre no se ha publicado en el BOE, y el régimen sancionador español tampoco. Pero la obligación no espera a nada de esto, porque un reglamento europeo se aplica directamente desde su fecha.
Cuando una vulnerabilidad convierte el producto en defectuoso
El cambio que más va a pesar en las pólizas llega por otra norma aprobada el mismo año: la Directiva (UE) 2024/2853 sobre responsabilidad por productos defectuosos. Sustituye a la de 1985 y dice por primera vez, en su artículo 4.1, que los programas informáticos son un producto.
Para juzgar si un producto es defectuoso habrá que tener en cuenta “los requisitos de ciberseguridad pertinentes para la seguridad” (artículo 7.2.f). Y el fabricante no podrá escudarse en que el defecto apareció después de vender si se debe a la “falta de actualizaciones o mejoras de los programas informáticos necesarias para mantener la seguridad”, siempre que esas actualizaciones estuvieran bajo su control (artículo 11.2.c).
Leídas juntas, las dos normas cierran el círculo. El reglamento te obliga a avisar y a corregir. La directiva no hace responsable automáticamente a quien no parcheó: el perjudicado tiene que acreditar el defecto, el daño y la relación entre ambos, aunque no la culpa; la directiva le permite presumir el defecto o la relación causal en ciertos casos, y el fabricante puede rebatirlo. Pero si el defecto viene de no haber dado las actualizaciones de seguridad que tenía en su mano, pierde la defensa de que el fallo apareció después de vender. Si el cliente no instala la actualización que le diste, tu responsabilidad puede reducirse o desaparecer según el caso, y ahí está otra razón para documentar cada parche y cada aviso.
Un matiz importa mucho a quien vende a otras empresas: la directiva indemniza muertes y lesiones, daños a bienes y la destrucción o corrupción de datos, pero deja fuera los bienes usados exclusivamente con fines profesionales y los datos que se utilicen con fines profesionales (artículo 6.1). Si tu máquina estropea la línea de producción de un cliente, esa reclamación quedará fuera de la directiva y se planteará por las vías del derecho nacional, contractuales o extracontractuales, y ahí es donde tu RC de explotación y de producto tienen que estar bien atadas.
La directiva se aplica a los productos introducidos en el mercado después del 8 de diciembre de 2026, fecha que fijó otra corrección de errores de mayo de 2026. Los vendidos antes siguen con la norma antigua. El plazo para trasponerla vence el 9 de diciembre de 2026, y la iniciativa no figura en el Plan Anual Normativo 2026 del Gobierno. En cuanto a los plazos del perjudicado, tiene tres años desde que conoce el daño, el defecto y al responsable (artículo 16), y su derecho se extingue a los diez años de poner el producto en el mercado, que pasan a veinticinco cuando una lesión corporal tarda tanto en manifestarse que no pudo reclamar antes (artículo 17).
El aviso a ENISA no cuesta nada. Lo caro viene después: corregir, retirar, sustituir y defender el producto.
Qué seguro responde de cada consecuencia
Notificar una vulnerabilidad es cumplir una obligación legal, y su coste (horas del equipo técnico, asesoría para redactar la notificación) corre a cargo de la empresa como cualquier otro gasto de cumplimiento. Lo que viene después sí puede estar asegurado, pero repartido entre varias pólizas que no se escribieron pensando las unas en las otras. Ése es el hueco que buscamos cuando revisamos el programa de seguros de un fabricante:
| Consecuencia | Póliza que hay que mirar | Qué comprobar en ella |
|---|---|---|
| El fallo causa lesiones o daños a bienes de terceros | RC de producto | Exclusiones de software, de datos o de hechos derivados de ciberataques; si cubre perjuicios económicos que no vengan de un daño material |
| Hay que retirar, sustituir o reprogramar unidades vendidas | Retirada de productos | Si admite una retirada por riesgo de ciberseguridad o sólo por defecto físico; si exige orden de la autoridad; si paga la actualización en campo o sólo la recogida |
| Análisis forense, abogados y comunicación a clientes | Ciberriesgos | Si su definición de sistema informático incluye el producto vendido o sólo tus propios equipos |
| El cliente reclama por un error de programación o de integración | RC profesional o tecnológica | Si cubre la actividad de desarrollo o sólo la de consultoría; la fecha de retroactividad |
| Se reclama a los administradores por no haber actuado a tiempo | D&O | Gastos de defensa en procedimientos administrativos; exclusión de incumplimientos normativos |
| Multa por no notificar | Ninguna, en la práctica | No cuentes con que ninguna póliza pague la multa. Algunas de D&O cubren la defensa en el procedimiento sancionador, no la sanción |
La diferencia entre las dos primeras filas es la que más se confunde, y la explicamos con calma en RC de producto y retirada del mercado: la RC paga lo que tu producto le hace a otros; la retirada paga lo que te cuesta a ti sacarlo o arreglarlo. Una actualización de firmware distribuida a varios miles de equipos instalados puede no dañar a nadie y costar mucho, y ese coste no lo paga la RC.
Sobre la tercera fila, la mayoría de los seguros de ciberriesgos para empresas se redactan pensando en un ataque a tus propios sistemas, así que merece la pena leer la definición antes de contar con ella. Si lo tuyo es desarrollar software o integrar sistemas para terceros, el enfoque cambia, y lo tratamos en seguros para empresas tecnológicas.
Hay además un asunto de fechas. La Ley de Contrato de Seguro da siete días desde que se conoce el siniestro para comunicarlo al asegurador, salvo que la póliza dé más (artículo 16), y detectar una vulnerabilidad no siempre es ya un siniestro. En las pólizas de responsabilidad civil con cláusula claim made la fecha que suele contar es la de la reclamación. Si tu condicionado permite declarar circunstancias, una vulnerabilidad detectada poco antes del vencimiento conviene comunicarla como tal antes de que la póliza termine; si no lo prevé, hay que saberlo antes de renovar.
La notificación de las 72 horas describe el fallo y lo que se ha hecho, y el asegurador puede acabar leyéndola, de modo que conviene redactarla sabiéndolo y avisar a tu corredor ese mismo día. Lo que no hacemos es decirte si tu producto entra o no en el reglamento: eso lo resuelven tu asesor jurídico y tu responsable técnico. Nos toca que, cuando entre, entre en tus pólizas sin huecos.
Qué dejar preparado antes del primer aviso
Veinticuatro horas no dan para improvisar. Lo que sigue es lo mínimo para que un aviso no pille a la empresa buscando papeles:
- La lista de productos con conexión que sigue en uso, con su versión de firmware o de software y a quién se vendió cada lote, distribuidores incluidos. Sin ella no se puede cumplir el artículo 14.8.
- Un responsable con suplente que pueda decidir fuera de horario, porque el plazo corre desde que la empresa tiene conocimiento, sea viernes por la tarde o no.
- Una alerta temprana ya redactada en plantilla. La de incidentes tiene que decir, como mínimo, si se sospecha un acto malintencionado.
- Un compromiso escrito de tus proveedores de componentes y de software para avisarte de sus vulnerabilidades. Si el fallo está en un módulo de otro, necesitas saberlo antes que tus clientes.
- La revisión de tus pólizas contra la tabla de arriba, antes del primer incidente y no después.
¿Tus seguros cubren el ciclo entero de un fallo de seguridad?
Revisamos gratis y sin compromiso cómo encajan tu RC de producto, la retirada, el ciberseguro, la RC profesional y el D&O frente a una vulnerabilidad de lo que fabricas o distribuyes, y te decimos dónde están los huecos.
Preguntas frecuentes
¿Qué es el Cyber Resilience Act?
Es el Reglamento (UE) 2024/2847, que fija requisitos de ciberseguridad para los productos con elementos digitales que se venden en la Unión Europea: hardware, software y sus componentes, siempre que se conecten a un dispositivo o a una red. Se aplica en general desde el 11 de diciembre de 2027, salvo la obligación de notificar, vigente desde el 11 de septiembre de 2026.
¿Qué obligación empieza el 11 de septiembre de 2026?
La del artículo 14: el fabricante debe notificar las vulnerabilidades aprovechadas activamente y los incidentes graves que afecten a la seguridad de su producto, con una alerta temprana en 24 horas, una notificación en 72 horas y un informe final, a través de la plataforma única de ENISA. También debe informar a los usuarios afectados.
¿Afecta a los productos vendidos antes de 2026?
Sí. El artículo 69.3 aplica la obligación de notificar a todos los productos del ámbito del reglamento introducidos en el mercado antes del 11 de diciembre de 2027. Una máquina conectada vendida hace años y todavía en uso entra en el deber de aviso.
¿El Cyber Resilience Act afecta a las pymes?
Sí, sin exención general por tamaño. La única excepción es que las microempresas y pequeñas empresas no pueden ser multadas por incumplir el plazo de la alerta temprana de 24 horas (artículo 64.10). Las 72 horas y el informe final les obligan igual.
¿A quién se notifica en España?
A través de la plataforma única de ENISA, que hace llegar el aviso al CSIRT coordinador del país del establecimiento principal del fabricante y a ENISA a la vez. Para España, la lista de ENISA remite a INCIBE-CERT.
¿La RC de producto cubre una vulnerabilidad de software?
Cubre los daños que el fallo cause a terceros si la póliza no excluye el software, los datos o los ciberataques, y hay que comprobarlo en cada condicionado. No cubre el coste de retirar o actualizar las unidades vendidas, que es materia del seguro de retirada, ni las multas administrativas.
Descubre más desde Sure Service: Correduría de seguros
Suscríbete y recibe las últimas entradas en tu correo electrónico.