Cyber Resilience Act: lo que los fabricantes de software deben haber hecho a finales de 2027

Calidad y seguridad

Desde el 11 de septiembre de 2026, los fabricantes deben notificar las vulnerabilidades activamente explotadas en sus productos, también en el caso de productos que se venden desde hace tiempo. A partir del 11 de diciembre de 2027, el Cyber Resilience Act se aplica en su totalidad. Quien distribuya en la UE software o equipos con software tiene, por tanto, algo más de un año para adaptar sus productos y procesos.

A quién afecta el CRA

El Cyber Resilience Act, el Reglamento (UE) 2024/2847, se aplica a los productos con elementos digitales que se comercializan en la UE. Esto incluye tanto equipos con software de control propio como software puro, por ejemplo programas de escritorio o add-ins de CAD. Es fabricante quien comercializa un producto de este tipo con su propio nombre o marca, ya sea a cambio de un pago o de forma gratuita. Algunos grupos de productos con normas propias, como los productos sanitarios, están excluidos.

Los plazos

Sus tareas hasta finales de 2027

1. Establecer el canal de notificación, de inmediato. Ante una vulnerabilidad activamente explotada, hay que enviar una alerta temprana en un plazo de 24 horas, una notificación en un plazo de 72 horas y un informe final como muy tarde 14 días después de que haya una corrección disponible. Para los incidentes graves de seguridad rigen los mismos plazos de alerta temprana y notificación. La notificación se realiza a través de la plataforma única de notificación de ENISA. Determine quién recibe los avisos, quién los evalúa y quién notifica, también durante las vacaciones.
2. Clasificar los productos. ¿Qué productos y versiones están afectados? ¿Se trata de un producto estándar, de un producto importante o de un producto crítico? De ello depende si puede evaluar la conformidad usted mismo o si necesita un organismo notificado.
3. Crear una lista de materiales de software (SBOM). El CRA exige una lista de materiales en un formato habitual legible por máquina que contenga, como mínimo, las dependencias de primer nivel. Lo mejor es que se genere automáticamente en cada compilación, por ejemplo en formato CycloneDX o SPDX.
4. Gestionar las vulnerabilidades. Compare periódicamente sus componentes con las bases de datos públicas de vulnerabilidades. Necesita una dirección de contacto para los avisos externos, un concepto de divulgación coordinada y pruebas de seguridad periódicas. Las vulnerabilidades corregidas se publican con una descripción para los usuarios.
5. Definir el proceso de actualización. Las actualizaciones de seguridad deben llegar a los clientes sin demora y, en principio, de forma gratuita, separadas de las actualizaciones de funciones en la medida en que sea técnicamente posible. El periodo de soporte es, por regla general, de al menos cinco años. Cada actualización de seguridad debe seguir disponible después durante al menos diez años o hasta el final del periodo de soporte, lo que sea más largo.
6. Proteger el producto. Se exige, entre otras cosas: ninguna vulnerabilidad explotable conocida en el momento de la entrega, una configuración predeterminada segura con posibilidad de restablecerla, protección contra el acceso no autorizado, cifrado, una superficie de ataque lo más reducida posible y el registro de los procesos relevantes para la seguridad.
7. Documentar. La documentación técnica incluye la descripción del producto, la arquitectura, la evaluación de los riesgos de ciberseguridad, el procedimiento de gestión de vulnerabilidades y la información para los usuarios. Es la base de la declaración UE de conformidad. Debe conservar ambas al menos diez años o durante el periodo de soporte, si este es más largo.

Por dónde empezar

Empiece por lo que ya se aplica hoy y lo que más adelante rinde en todas partes: el canal de notificación y la SBOM. Sin una lista de materiales, en caso de emergencia no sabrá si una vulnerabilidad recién conocida afecta a su producto, y el plazo de 24 horas corre de todos modos. Las pruebas automatizadas son otro componente. El CRA exige probar la seguridad del producto de forma periódica y eficaz. Las pruebas que se ejecutan en cada compilación aportan para ello pruebas documentales trazables.

Las infracciones de los requisitos esenciales o de las obligaciones de los artículos 13 y 14 pueden acarrear multas de hasta 15 millones de euros o de hasta el 2,5 % del volumen de negocios anual mundial, si este importe es superior.

Nota: Este artículo ofrece una visión general técnica y no constituye asesoramiento jurídico. Aclare la clasificación vinculante de su producto con su departamento jurídico o con sus abogados.

Errores típicos

• Esperar a 2027. Las obligaciones de notificación rigen desde el 11 de septiembre de 2026, para productos nuevos y existentes.
• «Nuestro producto es antiguo, esto no nos afecta». Hay que notificar igualmente. Y quien modifique de forma sustancial un producto existente después del 11 de diciembre de 2027 debe cumplir a partir de ese momento todos los requisitos.
• Crear la SBOM una sola vez a mano. Con la siguiente compilación ya está desfasada. Debe formar parte del proceso de compilación.
• Pasar por alto los componentes comprados y de código abierto. Las vulnerabilidades suelen estar en las bibliotecas, no en el código propio.
• Entregar las actualizaciones de seguridad solo junto con funciones nuevas. Los clientes deben poder cerrar una brecha sin implantar una versión nueva.
• No tener una dirección de contacto fija. Los avisos de vulnerabilidades acaban en el buzón general y se quedan allí.

Fuentes: Reglamento (UE) 2024/2847 (Cyber Resilience Act), en particular los art. 13, 14, 64, 69 y 71 y el anexo I, EUR-Lex; Cadida: Cyber Resilience Act. Situación: octubre de 2026.