El primer hito del Cyber Resilience Act (CRA) que afecta a los equipos de producto es el 11 de septiembre de 2026, fecha en que empiezan a aplicarse las obligaciones de notificación. Las obligaciones principales llegan el 11 de diciembre de 2027. La notificación depende de procesos y de personas, algo lento de construir, por lo que debe abordarse antes que cualquier otra cosa.
Qué se aplica y cuándo
El CRA es el Reglamento (UE) 2024/2847. Según la página de la Comisión Europea sobre el CRA, establece requisitos de ciberseguridad obligatorios para los fabricantes a lo largo de la planificación, el diseño, el desarrollo y el mantenimiento de los productos con elementos digitales. También exige a los fabricantes gestionar las vulnerabilidades durante todo el ciclo de vida del producto.
| Fecha | Qué ocurre |
|---|---|
| 10 de diciembre de 2024 | Entrada en vigor del CRA |
| 11 de septiembre de 2026 | Se aplican las obligaciones de notificación |
| 11 de diciembre de 2027 | Se aplican las obligaciones principales |
Los productos conformes llevarán el marcado CE, y las autoridades nacionales de vigilancia del mercado harán cumplir las normas. Algunos productos de especial relevancia para la ciberseguridad pueden requerir una evaluación por un tercero, a cargo de un organismo notificado, antes de su venta en el mercado de la UE. Conviene determinar cuanto antes a qué lado de esa línea se sitúa su producto, porque cambia su calendario.
La Comisión publicó además, el 27 de julio de 2026, una guía práctica para fabricantes. Léala antes de comprometerse con el diseño de cualquiera de los procesos que se describen a continuación.
Evidencias de desarrollo seguro
Los reguladores y los clientes preguntarán qué hizo usted, así que genere los registros como subproducto del trabajo habitual en lugar de reconstruirlos más adelante. Una estructura reconocida ayuda.
El NIST Secure Software Development Framework, SP 800-218, es un conjunto básico de prácticas de alto nivel que se añade al SDLC que ya tenga implantado. Sus objetivos declarados son reducir las vulnerabilidades del software publicado, limitar el impacto de las que persistan y corregir las causas raíz para que no se repitan. Además, le proporciona un vocabulario común para tratar con compradores y proveedores. Es un documento estadounidense y no una lista de verificación del CRA, así que conviene tomarlo como un andamiaje.
Evidencias que merece la pena conservar en cada versión:
- el modelo de amenazas o la revisión de diseño que cubrió el cambio
- los resultados de revisión de código y de pruebas, incluidas las pruebas de seguridad
- las listas de dependencias con sus versiones y lo que se decidió respecto a las vulnerabilidades conocidas en ellas
- la aprobación de la versión, con nombre y fecha
El material de Secure by Design de CISA aporta dos puntos prácticos. La responsabilidad debe recaer en el nivel directivo, y los valores por defecto importan: MFA, registro de eventos (logging) y SSO deberían estar disponibles de serie y sin coste adicional. Si su producto los vende como complementos de pago, es de esperar que se cuestione. CISA también publica guías sobre hojas de ruta hacia lenguajes con seguridad de memoria, útiles si su código está en C o C++.
Gestión y notificación de vulnerabilidades
A partir del 11 de septiembre de 2026, los fabricantes deberán notificar las vulnerabilidades explotadas activamente, junto con los demás supuestos indicados en la página de notificación de la Comisión. Consulte esa página para conocer el alcance exacto y el canal que debe utilizar. No se fíe de un resumen, y eso incluye este.
Lo que necesita internamente, sean cuales sean los detalles finales:
- Un único punto de recepción. Un contacto de seguridad monitorizado en el sitio web del producto y en la documentación, con un responsable designado y un suplente.
- Una rutina de triaje. Alguien decide, dentro de un plazo establecido, si un informe es válido, si la vulnerabilidad se está explotando y a qué productos y versiones afecta. Una puntuación de severidad coherente acelera el proceso; nuestra calculadora CVSS es útil para acordar puntuaciones dentro del equipo.
- Un circuito de decisión para la notificación. Deje por escrito quién decide que una vulnerabilidad explotada obliga a notificar y quién presenta la notificación. Ensáyelo una vez con un caso ficticio, fuera del horario laboral si es entonces cuando ocurriría de verdad.
- Un registro de cada decisión. Incluidos los informes que haya considerado fuera de alcance, con el motivo.
La notificación no puede funcionar si no sabe qué contiene su producto. Mantenga un inventario de componentes actualizado para cada versión distribuida, porque no es posible evaluar de memoria la exposición ante una nueva vulnerabilidad.
Procesos de actualización
La Comisión señala la falta de actualizaciones de seguridad oportunas como uno de los problemas que el CRA pretende resolver. Los productos deben diseñarse, actualizarse y mantenerse para proteger a los usuarios. En la práctica, esto significa probar su canal de actualización con la misma seriedad que sus funcionalidades.
Compruebe lo siguiente en cada línea de producto:
- Puede publicar una corrección de seguridad por separado de una versión con nuevas funcionalidades.
- Los clientes pueden saber que existe una actualización, e instalarla no exige llamar a soporte.
- Las versiones antiguas tienen una fecha de fin de soporte declarada que los clientes pueden ver antes de comprar.
- En el caso del hardware, ha probado a actualizar un dispositivo que ha estado un año sin conexión y a recuperar uno que falla a mitad del proceso.
La carencia más habitual no es tecnológica, sino de responsabilidad. Muchos equipos pueden generar un parche en un día y luego pasar tres semanas averiguando quién está autorizado a publicarlo.
Documentación técnica
Las fuentes que he utilizado no enumeran el contenido exigido del expediente técnico, por lo que debe consultarlo en el texto legal y en la guía de la Comisión. Lo importante en la práctica es que la documentación se vaya elaborando de forma continua a partir de las evidencias anteriores, y no se redacte en el último trimestre antes del plazo.
Asigne a cada producto una carpeta de documentación, o una sección del repositorio, con un responsable. Incluya en ella el diseño y la evaluación de riesgos, el inventario de componentes, los resultados de las pruebas, el procedimiento de gestión de vulnerabilidades y la política de actualizaciones. Versiónela junto con el producto. Cuando un auditor o una autoridad solicite un expediente, lo que usted quiere es poder exportarlo, no encargarlo.
Si además le es aplicable la Directiva NIS2, que según la Comisión el CRA complementa, reutilice los mismos procedimientos de incidentes y vulnerabilidades en lugar de mantener dos conjuntos.
Por dónde empezar
- Lea la guía de la Comisión del 27 de julio de 2026 y la página de notificación, y anote qué productos suyos están dentro del alcance y si alguno podría necesitar un organismo notificado.
- Designe a un responsable de la recepción de vulnerabilidades y de la notificación de las explotadas, publique un contacto de seguridad y realice un ensayo este trimestre.
- Genere un inventario de componentes para cada versión con soporte y haga que su generación forme parte de su build.
- Contraste su SDLC actual con las prácticas del SSDF, registre las brechas y empiece a conservar los registros de revisión, pruebas y aprobación de cada versión.
- Pruebe su canal de actualización de extremo a extremo y publique las fechas de fin de soporte de cada producto.
- Cree la carpeta de documentación por producto y complétela con lo que ya tiene. Si desea una opinión externa sobre las brechas, nuestro servicio de consultoría y nuestro servicio de desarrollo de software seguro cubren justamente esto.
