El 10 de diciembre de 2024, la Ley de Resiliencia Cibernética de la Unión Europea ( CRA , por sus siglas en inglés) entró en vigor como Reglamento (UE) 2024/2847. Por primera vez en la historia, los requisitos de ciberseguridad para productos con elementos digitales se convirtieron en legalmente vinculantes en todo el mercado único de la UE, no como un marco voluntario, sino como un requisito de acceso al mercado respaldado por multas de hasta 15 millones de euros o el 2.5 % de la facturación anual mundial , lo que sea mayor.
A partir del 11 de septiembre de 2026 , los fabricantes, importadores y distribuidores deberán informar activamente sobre las vulnerabilidades explotadas y los incidentes de seguridad graves a ENISA y a los CSIRT nacionales. Para las organizaciones que diseñan, fabrican o distribuyen dispositivos conectados, la CRA redefine el concepto de envío de un producto.
Este blog desglosa lo que la CRA exige específicamente de una arquitectura de firma de código , relaciona esos requisitos con los controles técnicos necesarios para satisfacerlos y explica por qué las organizaciones que aún no han abordado su infraestructura de firma se están quedando sin tiempo para hacerlo antes de que venza cada plazo de cumplimiento.
Lo que realmente exige la Ley de Resiliencia Cibernética
La CRA se aplica a cualquier «producto con elementos digitales» comercializado en el mercado de la UE, una categoría lo suficientemente amplia como para abarcar prácticamente cualquier dispositivo de hardware conectado y el software que ejecuta. Los routers, los dispositivos domésticos inteligentes, los equipos médicos, los controladores industriales, los ordenadores portátiles, los servidores, los sensores de IoT y el firmware que ejecutan todos ellos están incluidos en su ámbito de aplicación.
La normativa se basa en un principio fundamental: la seguridad desde el diseño. Los productos deben diseñarse, desarrollarse y mantenerse de forma que se garantice su ciberseguridad durante toda su vida útil prevista. No se trata de una certificación puntual, sino de una obligación continua que se mantiene durante un período mínimo de soporte de cinco años, según lo estipulado en el artículo 13(8), o durante la vida útil prevista del producto si esta fuera menor.
En lo que respecta específicamente a la firma de código, la CRA establece varias obligaciones que se derivan directamente de sus requisitos fundamentales:
La integridad del software y el firmware debe protegerse a lo largo de toda la cadena de suministro y la vida útil del producto. Cada imagen de firmware que se incluye con un producto y cada actualización que se le entrega deben ser verificables como auténticas y no haber sido modificadas. Esto requiere una infraestructura de firma criptográfica con controles demostrables sobre quién puede firmar, qué se puede firmar y qué registro de auditoría existe.
Se requieren explícitamente mecanismos de actualización seguros y, según el artículo 13, los fabricantes deben garantizar que las actualizaciones de seguridad se apliquen automáticamente e incluir mecanismos para verificar su autenticidad. Un sistema de actualización sin verificación de firma criptográfica no cumple con este requisito.
La divulgación coordinada de vulnerabilidades en virtud del artículo 14 implica que los fabricantes deben contar con la infraestructura operativa necesaria para identificar qué líneas de productos se ven afectadas por una vulnerabilidad determinada, notificar a ENISA en un plazo de 24 horas desde que tengan conocimiento de una vulnerabilidad que se está explotando activamente y entregar un informe de evaluación completo en un plazo de 72 horas.
Se requiere una lista de materiales (SBOM) legible por máquina que documente todos los componentes de software incluidos en el producto. Para fines de firma, esto significa que la procedencia de cada componente de firmware debe ser rastreable y documentable.
Mapeo del Anexo I de la CRA a los controles técnicos de firma
El Anexo I de la CRA establece los requisitos de seguridad específicos que deben cumplir los productos con elementos digitales. En el caso del firmware y el software integrado, estos requisitos se traducen directamente en controles técnicos concretos.
| Requisito del Anexo I de la CRA | Referencia del artículo | Control técnico requerido |
|---|---|---|
| Seguridad desde el diseño: abordar los riesgos de forma apropiada para el uso previsto. | Art. 1 | Cadena de arranque segura: anclas BootROM/OTP inmutables con claves únicas para cada dispositivo; cada etapa de arranque se verifica criptográficamente antes de su ejecución. |
| Integridad de datos y código: protege la integridad de los datos almacenados, los datos transmitidos y los programas ejecutables. | Artículo 2(f) | Firma del firmware: Las claves vinculadas al HSM firman cada artefacto de firmware; los manifiestos SUIT/FIT/UEFI proporcionan prueba de origen y evidencia de manipulación. |
| Control de acceso: protección contra accesos no autorizados | Artículo 2(d) | Quórum de firma M-of-N: ninguna persona firma el firmware de producción por sí sola; se aplica mediante el control de acceso basado en roles (RBAC) de la plataforma de firma. |
| Mitigación de incidentes: reducir el impacto de los incidentes de seguridad. | Art. 2(k) | Aislamiento de clave por producto: una brecha afecta a un solo producto, no a toda la cartera. |
| Sin vulnerabilidades conocidas: los productos deben enviarse sin vulnerabilidades explotables conocidas. | Artículo 2(a) | Análisis de vulnerabilidades previo a la firma: los artefactos del firmware se analizan contra bases de datos CVE conocidas antes de la aprobación de la firma. |
| Superficie de ataque minimizada: limitar todas las interfaces externas. | Artículo 2(j) | Certificación del dispositivo: DICE/TPM/PSA/TEE proporcionan una prueba en tiempo de ejecución de que solo se está ejecutando código verificado y sin modificar. |
Arquitectura de aislamiento clave
El cambio arquitectónico más significativo desde el punto de vista operativo que exige la CRA a la mayoría de las organizaciones es la transición de una infraestructura de claves de firma compartidas a un sistema de claves aisladas por producto.
El modelo de clave compartida es el predeterminado para las organizaciones que adoptaron la firma de código sin una gobernanza formal. Se utiliza una única clave de firma, posiblemente almacenada en un token USB o en un servidor de compilación, para firmar el firmware de cada producto. Es sencillo de gestionar y funciona técnicamente. Sin embargo, según la Ley de Revisión del Código (CRA), constituye un incumplimiento estructural.
He aquí por qué esta distinción es importante:
Arquitectura de clave compartida
Todas las líneas de productos comparten una única clave de firma. Si esa clave se ve comprometida:
- Todos los productos firmados con él se ven afectados simultáneamente.
- El radio de explosión abarca toda la cartera.
- La notificación ENISA de 24 horas prevista en el artículo 14 debe abarcar todos los productos afectados a la vez, sin posibilidad de determinar el alcance del impacto.
- Respuesta sobre el cumplimiento normativo: imposible en 24 horas sin registros por producto.
Arquitectura de clave por producto
Cada línea de productos tiene su propia clave dedicada, generada internamente y almacenada en una partición HSM separada . Si una clave se ve comprometida:
- Solo el producto asociado a esa clave se ve afectado.
- El radio de la explosión se limita a una sola línea de productos.
- La notificación del artículo 14 abarca un ámbito definido que puede responderse de forma precisa y rápida.
- Respuesta sobre cumplimiento: el registro de auditoría identifica inmediatamente los productos afectados, los eventos de firma y las versiones del firmware.
Para un fabricante con cuatro líneas de productos, el modelo de clave compartida implica un posible procedimiento de retirada del mercado y obligaciones de subsanación para todos los productos a la vez. El aislamiento por producto significa que, si bien un producto se ve afectado, los otros tres siguen funcionando con normalidad y la notificación se presenta con precisión en lugar de con pánico.
La transición al aislamiento de claves por producto también cumple con los requisitos de responsabilidad de la cadena de suministro de la CRA según el artículo 13 §5. La documentación de evaluación de la conformidad para el marcado CE deberá demostrar que la clave de firma de cada producto tiene su propia gobernanza, controles de acceso y registro de auditoría.
Firma neutral del proveedor
Uno de los desafíos prácticos para los fabricantes que buscan cumplir con la normativa CRA es la diversidad de arquitecturas de silicio en sus carteras de productos. Una empresa que fabrica un enrutador para el consumidor (ARM TrustZone), un electrodoméstico inteligente (MCU/IoT), un controlador industrial (RISC-V) y un producto de servidor (x86/UEFI) se enfrenta a cuatro ecosistemas de plataforma distintos, cada uno con diferentes cadenas de herramientas de firma, diferentes formatos de firmware (SUIT, FIT, manifiestos UEFI) y diferentes mecanismos de raíz de confianza de hardware (DICE, TPM, PSA, TEE).
A la CRA no le preocupa esta complejidad y exige controles consistentes y auditables en todos los productos incluidos en su ámbito de aplicación. Una arquitectura de firma independiente del proveedor resuelve este problema al separar la cadena de herramientas de firma específica de la plataforma del motor de políticas que la gestiona. En lugar de crear cuatro flujos de trabajo de firma independientes con cuatro prácticas de gestión de claves y cuatro registros de auditoría distintos, un motor de políticas centralizado aplica una gobernanza consistente a todos los tipos de plataforma, mientras que las integraciones específicas de cada plataforma gestionan el formato y los detalles del protocolo.
Las capas de la arquitectura funcionan de la siguiente manera:
Capa raíz de confianza de hardware: los módulos de seguridad de hardware (HSM) con certificación FIPS 140-2 proporcionan el almacenamiento de claves y las operaciones de firma para todas las plataformas. La compatibilidad con ML-DSA y SLH-DSA garantiza que la firma resistente a la computación cuántica esté disponible desde la misma infraestructura utilizada para los algoritmos clásicos.
Motor de políticas centralizado: La gobernanza de firmas respaldada por HSM aplica un control de acceso basado en roles (RBAC) coherente, requisitos de quórum M-of-N y flujos de trabajo de aprobación uniformes en todas las líneas de productos y plataformas. Un cambio en la política de firmas surte efecto simultáneamente en todas partes.
Capa de CI/CD y auditoría: La firma, la certificación y la generación de registros inmutables en tiempo de compilación se producen en la etapa de la canalización, generando el hash del artefacto, el ID de clave, la identidad del aprobador, la etapa de la canalización y la marca de tiempo que exigen los requisitos de auditoría de la CRA.
Resultados conformes: Cada plataforma recibe el firmware firmado en su formato nativo con el tipo de manifiesto apropiado: SUIT para IoT/MCU, FIT para ARM/Linux embebido, manifiesto UEFI para plataformas de servidor x86 y certificación específica para RISC-V. El flujo de trabajo de informes de ENISA recibe una salida estructurada y compatible con SRP que cumple directamente con el requisito de notificación en 24 horas.
Esta arquitectura satisface el requisito de la CRA de contar con controles consistentes en todas las líneas de productos sin necesidad de un programa de cumplimiento independiente para cada plataforma de silicio.
Cómo ayuda CodeSign Secure de Encryption Consulting
CodeSign Secure es la plataforma de gestión de firmas de código de clase empresarial de Encryption Consulting, diseñada para proporcionar los controles de infraestructura que exige el cumplimiento de la CRA en todas las dimensiones que se tratan en este blog.
Gestión de claves respaldada por HSM: CodeSign Secure almacena todas las claves de firma privadas en módulos de seguridad de hardware (HSM) con certificación FIPS 140-2 Nivel 3, integrándose con Thales Luna, Entrust nCipher, Utimaco, Securosys y HSM en la nube de AWS y Azure. El aislamiento de claves por producto se aplica a nivel de partición del HSM: cada línea de productos recibe su propia clave dedicada, generada internamente en el hardware y nunca exportada. Esto cumple directamente con el requisito de raíz de confianza de hardware de la CRA según el Artículo 13(1)(c) y el requisito de aislamiento por producto según el Artículo 13 §5.
Quórum de firma M-of-N y RBAC: El modelo de control de acceso basado en roles de la plataforma aplica requisitos de aprobación M-of-N para la firma del firmware de producción. Ningún individuo puede iniciar y aprobar una operación de firma. Todas las solicitudes, aprobaciones y rechazos de firma quedan registrados. La configuración de RBAC es auditable y está controlada por versiones, lo que proporciona la política de firma documentada que exigen las evaluaciones de conformidad de CRA.
Registro de auditoría inmutable: Cada evento de firma en CodeSign Secure genera una entrada de registro inmutable que captura el hash del artefacto, el identificador de clave, el certificado utilizado, la identidad del aprobador y la marca de tiempo RFC 3161. Los registros se centralizan y se almacenan por separado de la infraestructura de firma.
Compatibilidad con formatos de firmware multiplataforma: CodeSign Secure admite la firma de artefactos de firmware en toda la gama de formatos que requiere una cartera de productos diversa: .bin, .img, .hex, .fw, .dfu y .efi, lo que satisface el requisito de la CRA de controles consistentes en todas las líneas de productos sin reconstruir la infraestructura de firma para cada plataforma.
Compatibilidad con criptografía post-cuántica: CodeSign Secure v3.02 admite ML-DSA de nivel de producción (FIPS 204, con niveles de seguridad ML-DSA-44, ML-DSA-65 y ML-DSA-87) y SLH-DSA (FIPS 205) como firmas separables junto con algoritmos clásicos. Para los fabricantes que desarrollan productos con obligaciones de soporte CRA de más de cinco años, la firma PQC actual es la arquitectura que protege contra la amenaza HNDL antes de que llegue CRQC.
Integración con la canalización CI/CD: CodeSign Secure se integra con Azure DevOps, Jenkins, GitLab CI y otras plataformas importantes de canalización mediante API e interfaces de línea de comandos. La firma del firmware es una etapa controlada y regulada dentro de la canalización de compilación, no un paso manual.
Conclusión
La Ley de Resiliencia Cibernética ha transformado la firma de firmware, pasando de ser una buena práctica de seguridad a una obligación legal con consecuencias graves. El primer hito en su aplicación, los requisitos de notificación de incidentes y vulnerabilidades del Artículo 14, entraron en vigor el 11 de septiembre de 2026. El cumplimiento total, incluido el marcado CE, es obligatorio antes del 11 de diciembre de 2027. La infraestructura necesaria para cumplir con ambos plazos (aislamiento de claves por producto, firma respaldada por HSM, quórums M-of-N, registros de auditoría de 10 años y flujos de trabajo de firma con control de vulnerabilidades) requiere entre 12 y 18 meses para su diseño e implementación adecuados.
Las organizaciones mejor posicionadas para cumplir con la Ley de Reinversión Comunitaria (CRA) no son las que comenzarán a construir su infraestructura de firmas cuando llegue diciembre de 2027, sino las que la están construyendo ahora, antes de que las obligaciones de presentación de informes de septiembre de 2026 pongan al descubierto las deficiencias de su infraestructura actual.
En Encryption Consulting, CodeSign Secure proporciona la infraestructura de firma que exige el cumplimiento de la CRA, desde el aislamiento de claves respaldado por HSM hasta registros de auditoría inmutables y firma post-cuántica que aborda la amenaza HNDL dentro del plazo de soporte de la CRA.
