Arquitectura de cumplimiento de la CRA para la firma segura de código

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.

Cumplimiento de la firma de código, definido como: operar una arquitectura de firma que satisfaga simultáneamente dos regímenes separados que rigen la misma operación de firma, las obligaciones de integridad y divulgación a nivel de producto de la Ley de Resiliencia Cibernética de la UE y las reglas del ciclo de vida de los certificados del Foro CA/Browser para validez, revocación, protección de claves y sellado de tiempo, ambos aplicados a través de claves respaldadas por HSM, flujos de trabajo de aprobación documentados y registros auditables.

Puntos Clave

• Dos regímenes de cumplimiento distintos se aplican a la misma operación de firma: la CRA (legislación de la UE, centrada en el producto) y los Requisitos Básicos del Foro de Autoridades de Certificación/Navegadores (normas del sector, centradas en los certificados). Una arquitectura compatible satisface ambos requisitos, no solo uno.
• Fechas de la CRA: entrada en vigor el 10 de diciembre de 2024; notificación de vulnerabilidades/incidentes a partir del 11 de septiembre de 2026; cumplimiento total y marcado CE antes del 11 de diciembre de 2027.
• Fechas del CA/Browser Forum: claves privadas en hardware FIPS 140-2 Nivel 2+/Criterios Comunes EAL4+ desde junio de 2023; los desencadenantes de revocación se ampliaron para cubrir el Código Sospechoso según la votación CSC-22 (abril de 2024); las claves de Autoridad de Marca de Tiempo son obligatorias en los módulos criptográficos de hardware fuera de línea desde abril de 2025; validez máxima de los certificados de 460 días según la votación CSC-31 para los certificados emitidos a partir del 1 de marzo de 2026.
• Según los Requisitos Básicos de Firma de Código, la confirmación de una vulneración de claves debe revocarse en un plazo de 24 horas; la revocación solicitada por el suscriptor debe atenderse en el plazo de un día hábil.
• Para conocer el historial completo del cambio de validez del certificado, consulte Comprender el nuevo cambio en la validez de los certificados de firma de código.Este artículo se centra en la arquitectura de cumplimiento que requieren ambos regímenes, no en el historial de votaciones de forma aislada.

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.

La otra mitad del cumplimiento de la firma de código: Requisitos del Foro CA/Browser

La CRA rige el producto; no dice nada sobre el certificado bajo el cual se emite la clave de firma. Esos son los Requisitos Básicos del Foro CA/Browser para la Emisión y Gestión de Certificados de Firma de Código de Confianza Pública, y cualquier organización que firme con un certificado de confianza pública debe cumplir con ambos regímenes a la vez, en la misma operación de firma.

Estas no son recomendaciones; cada una tiene una fecha de entrada en vigor específica y una referencia en la papeleta de votación:

Fecha de vigencia	Boleta / Cambio	Requisito
1 de junio de 2023	Actualización de protección de claves del foro CA/B	Las claves privadas para la firma de código DEBEN generarse y almacenarse en un módulo criptográfico de hardware que cumpla con el nivel 2 de FIPS 140-2 o con los Criterios Comunes EAL4+; la generación de claves basada en software ya no está permitida.
Abril 2024	Boleta CSC-22	Los criterios de revocación se ampliaron más allá de la confirmación de la vulneración de la clave para abarcar también el código sospechoso y la actividad de firma maliciosa o no autorizada.
de junio 2024	Requisitos del servicio de firma del foro CA/B	Los servicios de firma de terceros que gestionan claves en nombre de un suscriptor DEBEN someterse a auditorías formales de evaluación de la conformidad (por ejemplo, WebTrust para autoridades de certificación, ETSI EN 319 401).
Abril 2025	Actualización del sistema de marcas de tiempo del foro CA/B	Las claves privadas de la Autoridad de Marca de Tiempo DEBEN estar protegidas en módulos criptográficos de hardware fuera de línea.
Marzo 1, 2026	Boleta CSC-31	La validez máxima de los certificados de firma de código se reduce a 460 días para los certificados emitidos a partir de esta fecha, en lugar de los 39 meses anteriores.

Revocación

Según los Requisitos Básicos §4.9.1.1, una CA debe revocar un certificado de firma de código dentro de las 24 horas posteriores a la confirmación de que la clave privada se vio comprometida. Una revocación solicitada por el suscriptor, o un informe de que la solicitud original no estaba autorizada, debe atenderse dentro de un día hábil según el §4.9.1.2. Desde la votación CSC-22, ese mismo plazo de 24 horas también se aplica una vez que se identifica Código Sospechoso, y no solo una confirmación de compromiso de clave, como vinculado al certificado. Operativamente, esto significa que una organización necesita saber, en cuestión de horas, qué certificado firmó qué artefacto, para poder solicitar la revocación antes de que los propios mecanismos de detección de la CA lo hagan por ella en un momento menos conveniente.

Marcando la hora

Una marca de tiempo confiable, aplicada según la RFC 3161, es lo que mantiene una firma verificable después de que expire el certificado de firma; sin ella, un artefacto firmado con un certificado de 460 días ya vencido parecería inválido el día en que caduque dicho certificado. Desde abril de 2025, el Foro CA/B exige que las Autoridades de Marcas de Tiempo protejan sus propias claves de firma en módulos criptográficos de hardware fuera de línea, lo que eleva el estándar para que los proveedores de marcas de tiempo sean aceptables para un flujo de firma compatible. Confirme directamente que su autoridad de marcas de tiempo cumple con este requisito; no es algo que una plataforma de firma de código pueda compensar por sí sola.

Renovaciones

La reducción de 39 meses a 460 días prácticamente triplica la frecuencia con la que se debe renovar un certificado de firma de código. Un proceso de renovación manual que era simplemente un inconveniente con el ciclo anterior se convierte en un riesgo operativo real con el nuevo; un certificado caducado a mitad del ciclo de lanzamiento bloquea por completo la firma. La gestión del ciclo de vida de los certificados debe tratarlos como una clase de activos con seguimiento y renovación automática, y no como una adquisición única que el equipo recuerda revisar cada pocos años.

Consecuencias de la protección de claves

La normativa HSM de junio de 2023 eliminó la opción que existía para los certificados de menor nivel de seguridad: la generación de claves mediante software. Ahora, toda clave de firma de código de confianza pública debe generarse internamente, y nunca exportarse desde, un módulo de hardware FIPS 140-2 Nivel 2 (o superior) o Common Criteria EAL4+. Este es el mismo requisito arquitectónico que impulsa de forma independiente la expectativa de raíz de confianza de hardware del Artículo 13(1)(c) de la CRA, y es precisamente ahí donde ambos regímenes de cumplimiento se refuerzan mutuamente en lugar de generar tareas separadas.

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.

Lista de verificación de acciones de cumplimiento

Utilice esto como una secuencia de preparación para auditorías, que abarque ambos regímenes, en lugar de una tarea de configuración única:

1. Confirme que cada clave privada de firma de código, independientemente de la línea de producto, se genere internamente y nunca se exporte desde un HSM FIPS 140-2 Nivel 2+ (o Criterios Comunes EAL4+), según el requisito del Foro CA/B de junio de 2023.
2. Pasar de una clave de firma compartida a un aislamiento de clave por producto, con la clave de cada línea de productos en su propia partición HSM y su propia lista de control de acceso.
3. Exija la aprobación de múltiples partes (M-of-N) para la firma de producción, de modo que ninguna persona pueda firmar y enviar unilateralmente, y confirme que esto se aplica mediante el motor de políticas de la plataforma de firma, y ​​no solo mediante el proceso.
4. Inscriba cada certificado de firma de código en un proceso de gestión del ciclo de vida de los certificados diseñado para ciclos de renovación de 460 días, y no para el antiguo ciclo de 39 meses.
5. Confirme que su autoridad de sellado de tiempo protege sus propias claves en un módulo criptográfico de hardware fuera de línea, según el requisito de abril de 2025, y que cada firma tiene un sello de tiempo en el momento de la firma.
6. Desarrolle (o confirme que posee) la capacidad de identificar, en cuestión de horas, cada artefacto firmado por un certificado o clave específicos, de modo que un plazo de revocación de 24 horas o un plazo de notificación a ENISA sea alcanzable en lugar de una mera aspiración.
7. Conserve los registros de eventos de firma, los hashes de los artefactos, las identidades de los aprobadores y el linaje de los certificados durante al menos el período mínimo de soporte de cinco años de la CRA, o más tiempo si la vida útil prevista de su producto supera ese período.
8. Si utiliza un servicio de firma de terceros, confirme que ha completado la auditoría de evaluación de conformidad (WebTrust o ETSI EN 319 401) requerida desde junio de 2024, en lugar de darlo por sentado.

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.

Preguntas frecuentes

¿Son lo mismo los requisitos básicos de la CRA y los del CA/Browser Forum?

No. La CRA es una ley de la UE que regula la ciberseguridad de los productos con elementos digitales. Los requisitos básicos del CA/Browser Forum son normas del sector que rigen la emisión y gestión de certificados de confianza pública, incluidos los certificados de firma de código. Una organización que firma con un certificado de confianza pública para un producto sujeto a la CRA debe cumplir ambos requisitos simultáneamente.

¿Cuánto tiempo tengo para revocar un certificado de firma de código después de que se haya comprometido una clave?

Según los Requisitos Básicos de Firma de Código §4.9.1.1, una CA debe revocar un certificado dentro de las 24 horas posteriores a la confirmación de una vulneración de la clave. Desde la votación CSC-22 (abril de 2024), ese mismo plazo de 24 horas también se aplica a los certificados vinculados a código sospechoso o actividad de firma no autorizada, no solo a aquellos cuya vulneración se haya confirmado.

¿Por qué se redujo la validez del certificado de firma de código a 460 días?

La propuesta CSC-31 redujo la validez máxima de los certificados de firma de código emitidos a partir del 1 de marzo de 2026, de 39 meses a 460 días, siguiendo la tendencia general del sector, impulsada por el CA/Browser Forum, de acortar la vida útil de los certificados para limitar el período de exposición de cualquier certificado individual.

¿Sigue siendo importante el sellado de tiempo si ahora los certificados caducan más rápido?

Es más importante. Una marca de tiempo RFC 3161 de confianza es lo que mantiene la validez de una firma después de que expire su certificado; con una validez de 460 días en lugar de 39 meses, es mucho más probable que los artefactos se verifiquen después de que su certificado de firma original haya caducado.

¿Cuál es el período mínimo que debo conservar los registros de auditoría de firmas?

Al menos el período mínimo de respaldo de cinco años de la CRA según el Artículo 13(8), o más si la vida útil prevista de su producto supera los cinco años. Los registros deben vincular cada evento de firma con la clave, el aprobador, el hash del artefacto y el certificado específicos utilizados.