EU Cyber Resilience Act: qué significa para la seguridad hardware

El Cyber Resilience Act, Reglamento (UE) 2024/2847 [1], es la primera legislación horizontal de la UE que impone requisitos obligatorios de ciberseguridad para los productos con elementos digitales a lo largo de todo su ciclo de vida. Se aplica a fabricantes, importadores y distribuidores que introducen dichos productos en el mercado de la Unión, con independencia de su establecimiento. El ámbito es deliberadamente amplio: cualquier producto dotado de software, firmware o componentes de red, desde los controladores industriales a los wearables de consumo, queda dentro del alcance salvo exclusión explícita [2].

La arquitectura jurídica sigue el esquema familiar a la Radio Equipment Directive y al Reglamento de Máquinas: requisitos esenciales en el Anexo I, procedimientos de evaluación de conformidad, marcado CE y un régimen de vigilancia del mercado respaldado por sanciones de hasta 15 millones de euros o el 2,5% de la facturación anual global, según cuál sea mayor [3]. La novedad estructural es la adición de un régimen obligatorio de gestión y disclosure de vulnerabilidades que se extiende durante todo el periodo de soporte.

El Anexo I, Parte I enumera los requisitos de ciberseguridad que cada producto en el alcance debe satisfacer en el momento de su introducción en el mercado. Las obligaciones clave incluyen: configuración secure-by-default, protección frente al acceso no autorizado mediante autenticación y control de accesos adecuados, protección de la confidencialidad e integridad de los datos almacenados y transmitidos, minimización de la superficie de ataque, mitigación del impacto de los incidentes mediante diseño resiliente y provisión de mecanismos de actualización de seguridad [1].

El Anexo I, Parte II regula el proceso de gestión de vulnerabilidades a lo largo del periodo de soporte. Los fabricantes deben identificar y documentar los componentes y las vulnerabilidades de sus productos mediante una software bill of materials, abordar las vulnerabilidades sin demora mediante actualizaciones de seguridad gratuitas, divulgar públicamente información sobre las vulnerabilidades resueltas una vez disponible el parche y mantener una política de coordinated vulnerability disclosure. Se trata de obligaciones continuadas, no de verificaciones puntuales [1].

Para los proveedores de hardware, la implicación práctica es que la infraestructura de firmware update, el toolchain de SBOM y la política de CVD son ahora activos regulados, no higiene de ingeniería opcional. Un producto no puede introducirse en el mercado sin ellos y la evaluación de conformidad los examinará.

El Anexo III clasifica un subconjunto de productos como importantes (Clase I y Clase II) y el Anexo IV identifica los productos críticos. La clasificación determina la vía de evaluación de conformidad. Los productos predeterminados pueden autoevaluarse. Los productos importantes de Clase I requieren la aplicación de una norma armonizada o una evaluación por tercero. Los productos importantes de Clase II requieren una evaluación por tercero realizada por un organismo notificado. Los productos críticos requieren una certificación europea de ciberseguridad bajo el marco instituido por el Reglamento (UE) 2019/881 [1][7].

Para el dominio de la seguridad hardware, las entradas relevantes de Clase II incluyen dispositivos hardware con security box, lectores de smart card con funciones de seguridad, microprocesadores con funciones security-related destinados a entidades esenciales conforme a NIS2 [4] y microcontroladores hardware con funciones security-related. Un dispositivo como una llave hardware post-cuántica o un endpoint soberano de comunicación segura cae plenamente en este régimen. El estatus de producto crítico, cuando lo designe un acto delegado de la Comisión para los root of trust hardware de mayor riesgo, impone certificación UE de ciberseguridad obligatoria al nivel de assurance fijado en el acto delegado.

El Artículo 14 introduce obligaciones de reporting de incidentes y vulnerabilidades más estrictas que la mayoría de los regímenes existentes. Las vulnerabilidades activamente explotadas deben notificarse a ENISA [5] y al CSIRT competente dentro de las 24 horas siguientes al conocimiento con un early warning, seguido de una notificación más completa dentro de las 72 horas y un informe final dentro de los 14 días. Los incidentes graves que impacten la seguridad del producto deben reportarse en la misma cadencia temporal [1].

Operativamente, esto significa que el fabricante debe disponer de una pipeline interna de triage y notificación capaz de producir un informe estructurado para un regulador dentro de pocas horas tras un evento de seguridad. Para un proveedor pequeño o de tamaño medio, se trata de un requisito organizativo significativo, no de un problema de tooling. El CRA contempla explícitamente que la conformidad con este artículo requiera una función de security operations con roles y caminos de escalado definidos, del tipo de madurez típicamente formalizada bajo ISO/IEC 27001 [8].

El Reglamento entró en vigor a finales de 2024 [3]. Las obligaciones de reporting del Artículo 14 se aplican desde el 11 de septiembre de 2026. El conjunto completo de obligaciones, incluyendo la evaluación de conformidad y el marcado CE, se aplica desde el 11 de diciembre de 2027. No existe ningún periodo de gracia para los productos introducidos en el mercado después de esa fecha [1].

Para un proveedor de hardware con un ciclo de desarrollo de 12-24 meses, el horizonte práctico es ahora. Un producto que entra en serie de desarrollo en 2026 debe llegar al mercado con una postura de seguridad CRA-compliant, expediente de evaluación de conformidad e infraestructura de gestión de vulnerabilidades. El retrofit no es realista para los requisitos estructurales como secure update, cobertura de SBOM y los elementos arquitectónicos que soportan la operación resiliente [6].

Para los proveedores de productos de seguridad hardware que venden en la UE, el CRA no es un ejercicio documental. Es un régimen de assurance regulado con participación de organismo notificado para cualquier función de seguridad no trivial, obligaciones continuadas durante el periodo de soporte y sanciones calibradas para garantizar que la conformidad sea menos costosa que la no conformidad. Trátelo como trataría el Reglamento sobre Productos Sanitarios o la Radio Equipment Directive: un input estructural de diseño, no una auditoría de última milla.

Concretamente: identificar hoy la clasificación del Anexo III de su producto; involucrar a un organismo notificado para los productos de Clase II al menos 12 meses antes de la entrada planificada al mercado; integrar la infraestructura de SBOM y CVD en su proceso de ingeniería en lugar de añadirla después; alinear el mecanismo de actualización de firmware, el threat model y los runbooks de incident response con el Anexo I antes del tape-out, no después.

Para los compradores de productos de seguridad hardware, el CRA es una potente palanca de procurement. Desde diciembre de 2027, el marcado CE sobre un producto en el alcance es una declaración vinculante de conformidad con los requisitos esenciales de ciberseguridad. El expediente de evaluación de conformidad, la SBOM y la política de CVD son documentos que usted tiene derecho a exigir. La presencia de una postura regulatoria sólida es ahora un factor discriminante entre proveedores serios y el resto [1][2][3].