El 11 de septiembre de 2026 llega la primera fecha dura del Reglamento de Ciberresiliencia. No es un requisito de diseño ni de documentación, y por eso pilla desprevenido a mucha gente: es un requisito operativo.
A partir de ese día, cualquier fabricante que ponga en el mercado europeo un producto con elementos digitales tiene que ser capaz de dar un aviso en 24 horas. No de arreglar el problema en 24 horas: de avisar. Y avisar exige tener montado algo que la mayoría de empresas pequeñas no tiene montado: alguien que conteste.
Esto no es un tema legal, es un tema de proceso de ingeniería. El texto del reglamento se lee en veinte minutos. Lo que cuesta es tener un canal, una persona de guardia y un inventario de qué firmware hay ahí fuera.
Tabla de contenidos
Qué arranca exactamente el 11 de septiembre
Las obligaciones de notificación del artículo 14 del Reglamento (UE) 2024/2847 pasan a ser exigibles. El resto del reglamento no se aplica plenamente hasta diciembre de 2027, pero esta pieza se adelanta.
Los dos supuestos que hay que notificar
- Vulnerabilidades explotadas activamente en tu producto. La clave está en «activamente»: no es cualquier fallo que descubras, es un fallo que alguien está aprovechando.
- Incidentes graves que afecten a la seguridad del producto.
Los plazos, con el matiz que casi todos cuentan mal
- Aviso temprano: 24 horas desde que tienes conocimiento. Es un aviso, no un análisis completo.
- Notificación: 72 horas. Ya con detalle técnico.
- Informe final: aquí es donde se confunde casi todo el mundo. Para una vulnerabilidad explotada, 14 días desde que hay una medida correctora disponible —no desde que te enteraste—. Para un incidente grave, el plazo es de un mes.
Fíjate en el reloj de las 24 horas. Empieza cuando tienes conocimiento, no cuando tu equipo se pone a mirarlo el lunes por la mañana. Si el aviso entra un viernes por la tarde en un buzón que nadie lee hasta el lunes, ya has consumido el plazo entero.
Te aplica aunque vendieras el producto hace años
Este es el punto que más sorprende. Las obligaciones de notificación no se limitan a los productos que pongas en el mercado a partir del 11 de septiembre: alcanzan también a los que ya están en el mercado.
Es decir, ese dispositivo conectado que vendiste en 2022, que sigue funcionando en casa de clientes y del que casi no te acuerdas, entra dentro. Si mañana aparece una vulnerabilidad explotada que le afecta, el reloj corre igual.
Lo cual lleva directamente a una pregunta incómoda: ¿sabes exactamente qué versiones de firmware tienes ahí fuera?
Se notifica una sola vez
Hay una confusión frecuente con esto. No hay que mandar un aviso a ENISA y otro al CSIRT nacional por separado.
La notificación se envía una sola vez a través de la plataforma única, y desde ahí se distribuye automáticamente: al CSIRT que actúa como coordinador —el del país donde tengas tu establecimiento principal—, a ENISA, y a los CSIRT de los demás territorios donde el producto esté disponible.
Qué tienes que tener montado antes de esa fecha
Cuatro cosas. Ninguna es cara; todas requieren decidirlas antes de necesitarlas.
1. Un canal donde te puedan avisar
Una dirección publicada y visible a la que un investigador, un cliente o un CERT pueda escribir. Si el único camino para avisarte de un fallo de seguridad es el formulario de contacto comercial, el aviso va a tardar días en llegar a quien tiene que leerlo.
Lo estándar es una dirección de seguridad dedicada y una política de divulgación publicada que diga qué esperas recibir y en cuánto respondes.
2. Alguien capaz de responder en 24 horas
No hace falta un equipo de guardia 24/7 con turnos. Hace falta que esté escrito quién es esa persona, que tenga suplente, y que el canal del punto anterior le llegue de verdad al móvil y no a un buzón compartido.
3. Un inventario de qué firmware hay en campo
Esta es la parte de ingeniería de verdad, y la que más trabajo da si no se hizo en su día. Necesitas poder responder rápido a: qué versiones están desplegadas, en cuántas unidades, con qué componentes de terceros dentro y cómo se actualizan.
Si tienes un esquema de versionado ordenado, esto ya está medio hecho. Es la misma disciplina que hace falta para saber si una actualización de firmware afecta al marcado CE.
4. Un criterio escrito de qué consideras «grave»
El día del incidente no es el momento de discutir si un fallo cumple el umbral. Conviene tener escrito de antemano, aunque sea en una página, qué combinaciones de impacto y explotabilidad disparan la notificación y cuáles no.
El error que va a cometer casi todo el mundo
Leer el reglamento, entenderlo, estar de acuerdo, y no designar a nadie.
El fallo típico no será de interpretación jurídica. Será que llega un correo un viernes, aterriza en un buzón genérico que se revisa los lunes, y para cuando alguien lo lee ya se ha agotado el plazo de aviso temprano. La obligación es de proceso, y los procesos que no tienen un nombre propio detrás no existen.
Prueba rápida: pregunta hoy en tu equipo quién contestaría si entrase un aviso de vulnerabilidad esta tarde. Si hay que pensarlo o la respuesta es «pues... alguien», ahí tienes el trabajo pendiente de estos días.
Cómo lo planteamos en RobotUNO
Que quede claro: no somos asesores jurídicos y no notificamos por ti. La obligación es del fabricante y no se delega.
Lo que hacemos es la parte técnica que hace posible cumplirla:
- Dejar montado el versionado y la trazabilidad del firmware para que el inventario de campo se pueda consultar, no reconstruir.
- Diseñar la actualización remota firmada y verificable, que es lo que convierte «hay que parchear» en algo que se puede hacer de verdad.
- Documentar los componentes de terceros que lleva el producto, para saber a qué te afecta cada aviso público.
- Ayudar a definir el criterio técnico de gravedad, que es una decisión de ingeniería antes que de abogados.
Es continuación natural del trabajo en cualquier dispositivo conectado y de lo que contamos en la guía de marcado CE y precertificación.
Y no, esto no sustituye al marcado CE. El marcado demuestra conformidad en el momento de poner el producto en el mercado. El CRA añade obligaciones que viven durante toda la vida del producto. Son capas distintas.
Preguntas frecuentes
¿Me aplica el CRA si solo vendo en España?
Sí. El CRA es un reglamento europeo de aplicación directa: no depende de en cuántos países vendas, sino de que pongas en el mercado de la UE un producto con elementos digitales. Vender solo en España es vender en el mercado de la UE.
¿Tengo que notificar cualquier vulnerabilidad que aparezca?
No. La obligación cubre dos supuestos concretos: vulnerabilidades que estén siendo explotadas activamente e incidentes graves que afecten a la seguridad del producto. Una vulnerabilidad que descubres tú y parcheas antes de que nadie la aproveche no dispara el reloj de las 24 horas.
¿Y si el fallo está en una librería de terceros que yo no escribí?
Sigues siendo tú quien notifica. La obligación recae en el fabricante, entendido como quien desarrolla el producto y lo vende bajo su nombre o marca. Que el código venga de un componente ajeno cambia cómo lo arreglas, no quién responde.
¿A quién se notifica exactamente?
Se envía una sola vez, a través de la plataforma única de notificación. Desde ahí llega al CSIRT que actúa como coordinador —el del país donde tienes tu establecimiento principal— y a ENISA a la vez. No hay que mandar avisos por separado.
¿Esto sustituye al marcado CE?
No, se suma. El marcado CE demuestra la conformidad del producto en el momento de ponerlo en el mercado. Las obligaciones de notificación del CRA son continuas y viven durante toda la vida del producto, incluso años después de venderlo.
¿Tienes producto conectado en el mercado?
Podemos revisar contigo el versionado, la actualización remota y la trazabilidad de componentes para que el 11 de septiembre no te pille reconstruyendo un inventario.
