El reloj ya corre, también para lo que vendiste hace años

Desde el 11 de septiembre de 2026, un fabricante de productos con elementos digitales tiene 24 horas para dar la primera alerta cuando sabe que una vulnerabilidad de su producto se está explotando. No es una obligación de 2027. Es la única parte del Reglamento de Ciberresiliencia (CRA) que ya se aplica, y se aplica a todo lo que está en el mercado de la UE, incluidos los equipos que vendiste antes de que existiera la norma.

El resto del reglamento (requisitos esenciales, evaluación de conformidad, marcado CE por ciberseguridad) llega el 11 de diciembre de 2027. La notificación no espera.

Veinticuatro horas no dan para improvisar. Si el aviso te llega un viernes por la tarde, el plazo vence el sábado.

Qué hay que notificar y en qué plazos

Dos cosas: vulnerabilidades explotadas activamente y incidentes graves que afecten a la seguridad del producto. Los plazos son escalonados:

  • Alerta temprana: 24 horas desde que lo sabes, en los dos casos.
  • Notificación completa: 72 horas, en los dos casos.
  • Informe final de una vulnerabilidad: como tarde 14 días después de que haya una medida correctora o de mitigación.
  • Informe final de un incidente: un mes después de la notificación de 72 horas.

Se notifica una sola vez, a través de la plataforma única de notificación de la UE, y la notificación llega al CSIRT del Estado miembro donde el fabricante tiene su establecimiento principal. Desde ahí se comparte con los países donde se vende el producto.

Un matiz para pymes: las microempresas y pequeñas empresas fabricantes no pueden ser sancionadas por incumplir el plazo de 24 horas. El resto de la obligación sigue en pie, y las sanciones las fija cada Estado miembro.

Lo que necesitas tener antes del aviso

El problema de las 24 horas no es rellenar un formulario. Es poder responder en ese plazo a tres preguntas: ¿esto me afecta?, ¿a qué productos y versiones?, ¿se está explotando de verdad?

1. Saber qué llevas dentro de cada versión

Imagina que se publica una vulnerabilidad explotada en una librería TLS de código abierto. Si tu controlador lleva seis versiones de firmware en campo y no sabes cuáles incluyen esa librería, ni en qué versión, las 24 horas se te van buscando.

La respuesta es un SBOM por versión publicada, no uno por producto. Se genera en la compilación, en un formato estándar como CycloneDX o SPDX, y se guarda junto al binario. Con eso, la pregunta "¿qué firmware lleva esta librería?" se responde con una búsqueda, no con una reunión.

2. Una puerta de entrada para los avisos

Alguien tiene que poder decirte que tu producto tiene un fallo. Eso exige:

  • Un contacto de seguridad publicado y vigilado (un buzón dedicado y un security.txt en tu web).
  • Una política de divulgación coordinada que diga qué pasa cuando alguien te reporta algo.
  • Vigilancia de las fuentes públicas de vulnerabilidades explotadas, cruzada con tu inventario de componentes.
3. Una regla para decidir qué es "explotada activamente"

No toda vulnerabilidad dispara la notificación. Define por escrito qué evidencia cuenta (explotación confirmada en clientes, pruebas públicas de explotación en ataques reales, inclusión en catálogos de vulnerabilidades explotadas) y quién toma la decisión. Si esa persona no está localizable el fin de semana, el plazo vence igual.

4. Guardias y plantillas
  • Un responsable y un suplente con capacidad de decidir y notificar, también fuera de horario.
  • La plantilla de la alerta temprana preparada: producto, versiones afectadas, qué se sabe, qué se va a hacer.
  • Acceso a la plataforma de notificación probado antes de necesitarlo, no el día del aviso.
5. Un camino para el parche

El informe final de una vulnerabilidad va ligado a que exista una medida correctora o de mitigación. Si tus equipos se actualizan a mano, uno por uno, ese plazo depende de tu logística de campo. Ten pensado al menos una mitigación que el cliente pueda aplicar sin firmware nuevo: desactivar un servicio, cerrar un puerto, cambiar una configuración.

Si ya trabajas con IEC 62443-4-1, tienes medio camino hecho

La IEC 62443-4-1 pide justo lo que hace falta para cumplir los plazos:

  • Gestión de defectos de seguridad (DM): recibir, evaluar y dar seguimiento a los avisos de vulnerabilidades.
  • Gestión de actualizaciones de seguridad (SUM): cómo se prueban, se documentan y se entregan los parches.
  • Guías de seguridad (SG): la documentación que le dice al cliente cómo bastionar y mitigar.

Si tu proceso de desarrollo ya está auditado contra 4-1, la notificación del CRA es sobre todo una cuestión de plazos y de canal. Si no lo está, la notificación es un buen motivo para empezar por esas tres prácticas.

Qué hacer este trimestre

  1. Lista los productos con elementos digitales que tienes en el mercado de la UE, incluidos los descatalogados que siguen en campo.
  2. Genera o recupera el SBOM de cada versión de firmware desplegada.
  3. Publica un contacto de seguridad y una política de divulgación.
  4. Escribe la regla de "explotada activamente" y nombra a quién decide.
  5. Haz un simulacro: un aviso falso un viernes a las 18:00, y mide cuánto tardas en saber qué productos están afectados.

Si el simulacro tarda más de 24 horas, ya sabes dónde está el trabajo.

Fuentes