La UE activa el 11 de septiembre nuevas obligaciones de ciberseguridad: a quién afectan y qué hay que comunicar
Desde el 11 de septiembre de 2026, los fabricantes de productos digitales afectados por el Reglamento de Ciberresiliencia deberán comunicar las vulnerabilidades explotadas activamente y los incidentes graves que comprometan la seguridad de sus productos. La primera alerta tendrá que enviarse sin demora indebida y, como máximo, en 24 horas desde que tengan conocimiento.
La medida también afecta a empresas españolas que comercializan dispositivos o software bajo su marca. Su objetivo es que las autoridades reciban información temprana para coordinar la respuesta cuando un problema pueda extenderse entre productos, usuarios y países.
Qué empieza ahora y qué queda para 2027
El Reglamento de Ciberresiliencia, conocido como CRA por sus siglas en inglés, establece requisitos de seguridad para productos con elementos digitales comercializados en la Unión Europea. Abarca tanto hardware como software y determinados componentes vendidos por separado.
Su aplicación sigue un calendario escalonado. Como explica el resumen de la Comisión Europea sobre el CRA, el reglamento entró en vigor el 10 de diciembre de 2024, pero sus disposiciones generales serán aplicables desde el 11 de diciembre de 2027. Las obligaciones de notificación del artículo 14 se adelantan al 11 de septiembre de 2026.
El comienzo de las notificaciones no significa que todos los requisitos de diseño, documentación y evaluación de conformidad sean exigibles desde mañana.
Para una empresa, la prioridad inmediata es disponer de un procedimiento que permita identificar un suceso notificable, reunir la información disponible y comunicarlo dentro de plazo, mientras continúa preparando el resto de su adaptación.
A qué empresas y productos afecta
El concepto de fabricante incluye a quien desarrolla un producto o encarga su desarrollo y lo comercializa bajo su nombre o marca. Por tanto, puede abarcar a una empresa española que vende software propio o dispositivos conectados, aunque haya subcontratado parte del trabajo.
El ámbito comprende productos cuyo uso previsto o razonablemente previsible incorpora una conexión de datos, directa o indirecta, con otro dispositivo o una red. Routers, cámaras conectadas y aplicaciones comerciales son ejemplos ilustrativos, aunque existen exclusiones y debe revisarse cada caso.
Una empresa que simplemente utiliza esos productos no se convierte por ello en fabricante obligado a notificar conforme al artículo 14.
Además, el calendario alcanza productos anteriores: las preguntas frecuentes de ENISA, actualizadas el 8 de septiembre, aclaran que las notificaciones también afectan a productos ya introducidos en el mercado. Esperar al lanzamiento de una nueva versión no evita esta obligación.
Qué problemas deben notificarse
Hay dos supuestos principales. El primero es una vulnerabilidad explotada activamente: existe evidencia fiable de que un actor malicioso ha aprovechado el fallo sin autorización. Encontrar un error durante una auditoría o asignarle una puntuación elevada de gravedad no demuestra, por sí solo, que esté siendo explotado.
El segundo es un incidente grave que repercuta en la seguridad del producto. Puede afectar a la protección de datos o funciones sensibles, o permitir introducir o ejecutar código malicioso, según los criterios del artículo 14 del Reglamento de Ciberresiliencia.
Imaginemos que un fabricante recibe pruebas de que atacantes están aprovechando un fallo de autenticación de sus cámaras. Ese conocimiento exige evaluar inmediatamente la notificación, aunque todavía se esté investigando cuántos clientes están afectados.
La consecuencia práctica es que desarrollo, soporte y seguridad necesitan compartir las señales relevantes. Un aviso recibido por atención al cliente puede contener la primera evidencia de una explotación real.
Los plazos: 24 horas, 72 horas e informe final
El proceso se divide en etapas para comunicar pronto y ampliar después la información. La Comisión Europea detalla las obligaciones de notificación, cuyos plazos iniciales se cuentan desde que el fabricante tiene conocimiento:
- En un máximo de 24 horas: alerta temprana sobre la vulnerabilidad explotada o el incidente grave.
- En un máximo de 72 horas: notificación con la información disponible, una descripción del problema y las medidas correctoras o de mitigación.
- Informe final: para vulnerabilidades explotadas, como máximo 14 días después de disponer de una medida correctora o paliativa. Para incidentes graves, dentro del mes siguiente a la notificación de las 72 horas.
Las 72 horas no empiezan después de agotar las primeras 24: ambos plazos iniciales parten del conocimiento del suceso.
Tampoco constituyen un plazo general para terminar el parche. La comunicación temprana y la resolución técnica avanzan en paralelo; esperar a cerrar toda la investigación puede impedir cumplir la primera obligación.
Cómo se comunica desde España
La vía prevista es la plataforma única de notificación del CRA, gestionada por ENISA. Centraliza el envío al equipo de respuesta a incidentes —CSIRT— designado como coordinador y a ENISA, con las excepciones de difusión previstas para información especialmente sensible.
La selección del coordinador sigue las reglas sobre el establecimiento principal del fabricante. No basta con elegir el país donde apareció el primer cliente afectado.
Según las últimas aclaraciones de ENISA, la plataforma estará disponible desde el 11 de septiembre, inicialmente en inglés, y el acceso utilizará EU Login. En su lanzamiento admitirá las notificaciones obligatorias de fabricantes; la función de comunicación voluntaria llegará posteriormente.
Notificar a las autoridades tampoco equivale a publicar inmediatamente todos los detalles técnicos. La gestión de información sobre un fallo todavía explotable exige coordinar la respuesta sin facilitar nuevos ataques.
Qué conviene preparar desde hoy
Para un fabricante, una preparación útil empieza por asignar responsables y sustitutos, establecer un canal de recepción de avisos y mantener localizable la información de productos y versiones. También conviene acordar quién puede enviar una alerta cuando la investigación todavía está abierta.
Un simulacro sencillo permite comprobarlo: llega un aviso fiable un viernes por la tarde, el responsable habitual está ausente y aún no existe parche. ¿Quién recoge la evidencia, decide el siguiente paso y registra cuándo se conoció el problema?
La eficacia del cambio dependerá de convertir esas primeras horas en información útil y medidas de protección. ¿Están preparadas las pequeñas empresas de software para responder con estos plazos? ¿Qué dificultad ves mayor: detectar, coordinar o comunicar?
