El Cyber Resilience Act: el 11 de septiembre de 2026 es un plazo real
La mayoría de los reglamentos europeos te dan una fecha de cumplimiento y un periodo de gracia durante el cual todo el mundo se organiza en silencio. El Cyber Resilience Act hace otra cosa. Su primera obligación firme es un reloj de notificación de 24 horas, y arranca el 11 de septiembre de 2026.
Un reloj de 24 horas no se puede implantar por fases. O el proceso existe ese día, o incumples.
Qué es el CRA
El Reglamento (UE) 2024/2847 fija requisitos de ciberseguridad para productos con elementos digitales introducidos en el mercado de la UE. Esa expresión cubre mucho más de lo que la gente supone al principio: cualquier producto de software o hardware, y sus soluciones de tratamiento remoto de datos, cuyo uso previsto o razonablemente previsible incluya una conexión de datos directa o indirecta.
Los dispositivos conectados están dentro. También la mayoría del software comercial, los sistemas operativos, los navegadores, las aplicaciones móviles, el firmware y los componentes dentro de otros productos.
El Reglamento se publicó en noviembre de 2024 y se aplica por fases:
- 11 de junio de 2026: obligaciones para organismos de evaluación de la conformidad.
- 11 de septiembre de 2026: obligaciones de notificación de vulnerabilidades activamente explotadas e incidentes graves.
- 11 de diciembre de 2027: aplicación completa, incluidos los requisitos esenciales de ciberseguridad, el marcado CE, la documentación técnica y la lista de materiales de software.
La fecha intermedia es la que hay que planificar, porque llega primero y porque depende de capacidades que quizá no tengas.
Qué pasa el 11 de septiembre de 2026
Desde esa fecha, los fabricantes deben notificar:
Vulnerabilidades activamente explotadas en sus productos con elementos digitales, e
incidentes graves que afecten a la seguridad de esos productos.
La notificación va por la Plataforma Única de Notificación del CRA, operada por ENISA, hacia el CSIRT designado en el Estado miembro del establecimiento principal del fabricante, que después comparte con otros CSIRT afectados y con ENISA.
El calendario:
- En 24 horas desde el conocimiento: una alerta temprana.
- En 72 horas: una notificación completa, incluidas las medidas correctoras o de mitigación adoptadas.
- En 14 días desde que una medida correctora esté disponible: un informe final para una vulnerabilidad activamente explotada.
- En un mes: un informe final para un incidente grave.
Veinticuatro horas desde el conocimiento, no desde la confirmación, ni desde la corrección. Si una vulnerabilidad de un componente de tu producto se está explotando en el mundo real un sábado, el reloj corre el sábado.
Por qué es más difícil de lo que parece
La obligación de notificar en sí es un formulario. La dificultad está en todo lo que necesitas tener antes de poder rellenarlo.
Tienes que saber qué hay dentro de tu producto
Para notificar que una vulnerabilidad de tu producto se está explotando activamente, tienes que saber que el componente vulnerable está en tu producto. Para una aplicación moderna con cientos de dependencias transitivas, eso no es algo que un humano responda de memoria.
Por eso los equipos están construyendo ahora canalizaciones de lista de materiales de software, más de un año antes del requisito formal de SBOM de diciembre de 2027. La SBOM no es el objetivo. El objetivo es poder responder «¿nos afecta?» en horas, y la SBOM es lo que hace que la pregunta tenga respuesta.
Lo incómodo es que esto se aplica a productos que enviaste hace años. Si tienes dispositivos soportados en campo ejecutando firmware compilado en 2022 a partir de un árbol de dependencias que nadie registró, reconstruirlo es trabajo real.
Tienes que estar vigilando
El conocimiento arranca el reloj, y se espera que sea activo y no accidental. Eso significa vigilar fuentes de vulnerabilidades, suscribirse a los avisos de tus componentes, seguir los catálogos de vulnerabilidades explotadas conocidas, y tener un canal donde los investigadores de seguridad puedan contactarte y obtener respuesta.
Tienes que tener una vía de decisión
Alguien tiene que poder decidir, a cualquier hora, si un incidente alcanza el umbral y si el reloj ha arrancado. Sin un rol nombrado y una vía de escalado, las primeras horas se van en averiguar quién puede tomar la decisión.
Las dependencias al final de su vida se vuelven un pasivo
Si un componente de tu producto ya no recibe actualizaciones de seguridad, sigues cargando con la obligación de notificar cuando se explote, y no tienes ninguna corrección aguas arriba a la que apuntar. Auditar dependencias al final de su vida es de las cosas más útiles en la fase previa, porque la respuesta a veces obliga a una migración con su propio plazo.
Qué trae la aplicación completa en diciembre de 2027
Las obligaciones de diciembre de 2027 son el programa mayor, y hay que empezarlas mucho antes.
Seguridad desde el diseño y por defecto. Los productos deben diseñarse, desarrollarse y fabricarse para asegurar un nivel adecuado de ciberseguridad basado en el riesgo. Sin contraseñas por defecto. Configuración segura de fábrica. Minimización de la superficie de ataque. Protección de datos en tránsito y en reposo.
Gestión de vulnerabilidades. Un proceso documentado que cubra identificación, corrección, prueba, distribución y divulgación. Las actualizaciones de seguridad deben proporcionarse sin demora y gratuitamente, durante un periodo de soporte que refleje la vida útil esperada del producto, siendo cinco años una referencia común.
Lista de materiales de software. En formato legible por máquina, cubriendo como mínimo las dependencias de primer nivel, y mantenida al día.
Documentación técnica y evaluación de la conformidad. La mayoría de los productos se autoevalúan. Las categorías importantes y críticas, que incluyen cosas como gestores de contraseñas, VPN, sistemas operativos y sistemas de control industrial, requieren intervención de un tercero.
Marcado CE. El equivalente digital del marcado físico, declarando la conformidad.
Política de divulgación coordinada de vulnerabilidades. Publicada, con un punto de contacto que funcione.
Quién está realmente dentro del ámbito
Unos pocos casos límite salen constantemente.
El software libre y de código abierto desarrollado fuera de una actividad comercial queda en gran medida fuera. El Reglamento introduce la figura del administrador de software de código abierto con obligaciones más ligeras. Pero si comercializas código abierto, o lo incorporas en un producto que vendes, las obligaciones de producto son tuyas.
El software como servicio queda generalmente fuera del CRA y se sitúa en NIS2, aunque las soluciones de tratamiento remoto de datos que son parte integral de un producto con elementos digitales quedan arrastradas dentro. Si tu dispositivo depende de tu backend en la nube para funcionar, ese backend viaja con el producto.
Importadores y distribuidores también tienen obligaciones. Si introduces un producto de terceros en el mercado de la UE bajo tu propio nombre o marca, se te trata como fabricante.
Los productos ya regulados en otro lugar, como productos sanitarios, vehículos y equipos aeronáuticos, se tratan en sus propios marcos.
Las preguntas de ámbito no son triviales y es un punto donde una hora con tus abogados ahorra meses de ingeniería mal dirigida.
Qué haríamos con el tiempo que queda
Si estás dentro y empiezas ahora, este es el orden que funciona:
Primero, establecer el inventario de productos. ¿Qué tienes realmente en el mercado de la UE? Incluidas versiones antiguas todavía en campo, variantes de marca blanca y productos que distribuyes para otros. Esa lista suele ser más larga de lo que nadie espera.
Segundo, meter la generación de SBOM en CI. Generar una SBOM en cada compilación, en CycloneDX o SPDX, guardarla junto al artefacto de la versión y mantenerla consultable. La idea es poder preguntar «¿cuáles de nuestras versiones publicadas contienen esta biblioteca?» y obtener respuesta en minutos.
Tercero, conectar la vigilancia de vulnerabilidades. Alimentar con tus datos de SBOM un escáner que vigile avisos y catálogos de vulnerabilidades explotadas conocidas, y encaminar las alertas a un canal que alguien lea.
Cuarto, escribir el manual de incidentes. Quién declara, quién evalúa, quién notifica, quién comunica. Personas nombradas, suplentes y contactos fuera de horario. Luego ensayarlo una vez con un aviso ficticio. En el ensayo es donde descubres que quien tiene las credenciales de la plataforma de notificación está de vacaciones.
Quinto, publicar una política de divulgación de vulnerabilidades. Un fichero security.txt, una dirección atendida y un plazo de respuesta declarado. Es una tarde de trabajo y marca la diferencia entre enterarte de un problema por un investigador o por un periodista.
Sexto, empezar el trabajo de diciembre de 2027. Valores por defecto seguros, mecanismos de actualización, decisiones sobre el periodo de soporte y documentación son cuestiones de arquitectura, no papeleo. Los productos que diseñes en 2026 seguirán en el mercado en 2028.
El solapamiento que nadie aprovecha
Hay duplicación significativa entre el CRA y otros regímenes, y la mayoría de las empresas los tratan por separado, lo cual es desperdicio.
Una SBOM construida para el CRA responde a la mayoría de las preguntas de cadena de suministro de NIS2. El manual de incidentes se solapa con la alerta temprana de 24 horas de NIS2 y con la notificación de brechas de 72 horas del RGPD. Los procesos de gestión de vulnerabilidades alimentan directamente los cuestionarios de seguridad de clientes y las compras corporativas.
Construye esto una vez como capacidad de plataforma. La alternativa son tres equipos construyendo tres versiones del mismo inventario de activos.
Dónde conseguir ayuda
Construimos y mantenemos software para empresas que venden en la UE, lo que cada vez más significa construir la visibilidad de cadena de suministro y la infraestructura de actualización que el CRA da por supuestas. Si estás averiguando si estás dentro del ámbito, o tienes la fecha de septiembre en el calendario y ninguna vigilancia en marcha, escribe a office@c9group.dev.
Nuestro servicio de mantenimiento de sistemas heredados es a menudo el punto de partida, porque los productos con peor visibilidad de dependencias suelen ser los más antiguos. El panorama regulatorio más amplio está en nuestra guía de cumplimiento digital de la UE 2026.
Somos ingenieros más que abogados. Las decisiones de ámbito y clasificación corresponden a tus abogados, y construimos según la respuesta que den.