El Cyber Resilience Act de la UE

El CRA abarca hardware y software cuyo uso previsto incluya una conexión de datos directa o indirecta con un dispositivo o una red, incluidos los componentes introducidos en el mercado por separado. Las obligaciones recaen en primer lugar sobre los fabricantes en cuanto un producto se comercializa en el mercado de la UE; a los importadores y distribuidores se les aplican obligaciones graduadas de verificación y cooperación. Quedan excluidos los ámbitos de productos con normativas sectoriales propias —como los productos sanitarios, los vehículos de motor, la aviación y el transporte marítimo—, así como el software libre y de código abierto fuera de una actividad comercial.

El reglamento clasifica los productos según su riesgo: la gran mayoría se considera producto estándar y pasa por una autoevaluación del fabricante. Los productos importantes según el anexo III se dividen en clase I (19 categorías, entre ellas gestores de contraseñas, navegadores, productos VPN, sistemas operativos, routers y sistemas SIEM) y clase II (4 categorías: hipervisores y entornos de ejecución de contenedores, cortafuegos y sistemas de detección/prevención de intrusiones, así como microprocesadores y microcontroladores resistentes a manipulaciones). Para los productos críticos según el anexo IV —entre otros, pasarelas de contadores inteligentes, así como tarjetas inteligentes y elementos seguros— puede imponerse una certificación europea de ciberseguridad obligatoria. El Reglamento de Ejecución (UE) 2025/2392, de 28 de noviembre de 2025, precisa las descripciones técnicas de las categorías; para la clasificación es determinante la funcionalidad principal del producto.

El anexo I define los requisitos esenciales de ciberseguridad en dos partes. La parte I se refiere a las propiedades del producto: los productos deben desarrollarse sobre la base de una evaluación de riesgos, comercializarse sin vulnerabilidades explotables conocidas y entregarse con una configuración segura por defecto; las vulnerabilidades deben subsanarse mediante actualizaciones de seguridad, instalables automáticamente por defecto, con posibilidad de exclusión voluntaria (opt-out). La parte II exige procesos de gestión de vulnerabilidades: una lista de materiales de software (SBOM) en un formato habitual y legible por máquina que cubra al menos los niveles superiores de dependencias, una política de divulgación coordinada, un punto de contacto para notificaciones de vulnerabilidades, así como pruebas periódicas y la distribución inmediata y gratuita de las actualizaciones de seguridad. El CRA no exige la publicación de la SBOM; como ayuda práctica inicial, la directriz técnica BSI TR-03183 concreta, entre otros aspectos, los contenidos y formatos de la SBOM.

A partir del 11 de septiembre de 2026, los fabricantes deberán notificar las vulnerabilidades explotadas activamente y los incidentes graves con impacto en la seguridad del producto, simultáneamente al CSIRT designado como coordinador y a ENISA a través de la plataforma única de notificación prevista en el art. 16. Se aplica un procedimiento en tres fases: alerta temprana en un plazo de 24 horas desde el conocimiento, notificación detallada en un plazo de 72 horas y, como informe final, en el caso de las vulnerabilidades a más tardar 14 días después de que esté disponible una medida correctora o paliativa, y en el caso de los incidentes un mes después de la notificación del incidente. Estos plazos presuponen procesos de detección, evaluación y notificación preparados de antemano, en particular la capacidad de constatar de forma fiable una explotación activa.

Según la clase, la conformidad se acredita mediante el control interno (módulo A), el examen UE de tipo con posterior control de la producción (módulos B y C), un aseguramiento pleno de la calidad (módulo H) o un esquema europeo de certificación de la ciberseguridad (art. 32). Los productos importantes de la clase I solo pueden declararse conformes mediante autoevaluación si se aplican íntegramente las normas armonizadas o los esquemas pertinentes; para la clase II es obligatoria la intervención de un organismo notificado. A partir del 11 de diciembre de 2027, los productos con elementos digitales solo podrán introducirse en el mercado de la UE con el marcado CE (art. 29–30), que entonces acreditará también la conformidad con el CRA, demostrable mediante la declaración UE de conformidad y la documentación técnica. Las infracciones de los requisitos del anexo I o de las obligaciones de los art. 13 y 14 pueden acarrear multas de hasta 15 millones de euros o el 2,5 % del volumen de negocios anual mundial; los demás incumplimientos, de hasta 10 millones de euros o el 2 % (art. 64).

Los fabricantes deben determinar un período de asistencia durante el cual las vulnerabilidades se gestionen de forma eficaz; por regla general es de al menos cinco años (art. 13). Una vez puestas a disposición, las actualizaciones de seguridad deben permanecer disponibles durante al menos diez años tras su publicación o durante el resto del período de asistencia —el plazo que sea más largo— y ofrecerse gratuitamente durante el período de asistencia. Con ello, el CRA desplaza el foco de una verificación puntual de la conformidad hacia procesos operados de forma permanente: desarrollo seguro, gestión de vulnerabilidades y parches, y documentación continua. Además, desde el 11 de junio de 2026 se aplican las disposiciones sobre la notificación de los organismos de evaluación de la conformidad (capítulo IV), y la Comisión Europea publicó en julio de 2026 directrices prácticas para la aplicación.

Desde el 30 de julio de 2026, ENISA ofrece con el «Secure by Design and Default Playbook» (v1.0) una ayuda gratuita de implantación para justo las obligaciones de los fabricantes que el CRA exige en su anexo I: 22 principios –de las trust boundaries y el acceso inicial restrictivo a las actualizaciones automáticas– cada uno como playbook de una página con lista de verificación, evidencias mínimas y release gate para la pipeline CI/CD. El anexo C del documento asigna cada principio, de forma indicativa, a los requisitos esenciales del CRA; eso no crea una prueba de conformidad, pero sí un puente de ingeniería sólido del reglamento a la práctica de desarrollo, incluido un concepto de evidencias de seguridad procesables por máquina. Licencia CC BY 4.0, disponible como PDF y repositorio de GitHub.