La vigencia de los certificados de firma de código es cada vez menor.

Los certificados de firma de código autentican el software antes de que llegue a los usuarios finales. Confirman que un binario, instalador o actualización proviene de un editor verificado y no ha sido alterado durante su transmisión. Durante años, el modelo operativo de estos certificados fue sencillo: obtener uno con un período de validez de varios años, almacenarlo en un entorno de compilación y renovarlo al recibir el aviso de vencimiento. Este modelo generó un riesgo silencioso pero real, ya que un certificado válido por 39 meses implica que una clave privada comprometida permanece en confianza durante todo ese período, a menos que alguien lo detecte y lo revoque a tiempo.

Según la propuesta CSC-31 del Foro CA/Browser , aprobada el 17 de noviembre de 2025 e incorporada a la versión 3.10.0 de los Requisitos Básicos de Firma de Código, el período máximo de validez de los certificados de firma de código de confianza pública se redujo de 39 meses a 460 días, aproximadamente 15 meses. Cualquier certificado de firma de código emitido a partir del 1 de marzo de 2026 debe cumplir con este límite. Los certificados emitidos antes de esa fecha siguen siendo válidos hasta su vencimiento natural, pero al momento de la renovación, se aplica el nuevo plazo.

Este no es un caso aislado. Sigue la misma trayectoria que los certificados TLS , cuya vigencia se redujo de 398 a 200 días a partir del 15 de marzo de 2026, y que se prevé que disminuya aún más a 100 días el 15 de marzo de 2027 y a 47 días el 15 de marzo de 2029, según la propuesta SC-081v3 del Foro CA/B, aprobada en abril de 2025. La firma de código y TLS convergen en el mismo principio: los certificados no deben superar las condiciones de confianza bajo las cuales fueron emitidos. El sector apuesta por la automatización para que esto sea factible.

Este blog analiza qué ha cambiado, dónde reside el riesgo y qué deben abordar las organizaciones antes del próximo ciclo de renovación.

¿Por qué se están reduciendo los períodos de validez de los certificados?

La tendencia a reducir la duración de los certificados no es arbitraria. Aborda dos problemas que existen desde hace tiempo en la infraestructura de clave pública (PKI): el lapso entre el momento en que un certificado se ve comprometido y el momento en que deja de ser confiable, y la lentitud con la que las organizaciones adoptan estándares criptográficos más robustos cuando sus certificados actuales aún funcionan correctamente.

Cuando se expone una clave de firma privada, el certificado asociado a ella permanece válido hasta que caduca o se revoca. La revocación presenta problemas de fiabilidad bien conocidos. Las listas de revocación de certificados (CRL) y el protocolo OCSP (Online Certificate Status Protocol) no se comprueban de forma sistemática en todas las plataformas, y cuando una comprobación de revocación falla o se agota el tiempo de espera, la mayoría de los sistemas la interpretan como un resultado positivo en lugar de un bloqueo.

El resultado es que un certificado comprometido puede seguir siendo una herramienta de ataque viable mientras siga siendo de confianza. Con el modelo anterior de validez de 39 meses, una sola vulneración de clave podía exponer a una organización a más de tres años de riesgo. Con el nuevo límite de 460 días, el período máximo de exposición se reduce significativamente.

El segundo problema es que las organizaciones tienden a no reemplazar los certificados en funcionamiento antes de lo previsto, incluso cuando existen mejores opciones de algoritmos. El sector aprendió esto durante la descontinuación de SHA-1 y el abandono de las claves RSA de 1024 bits. Ambas transiciones se prolongaron mucho más de lo necesario porque los certificados de larga duración no imponían a las organizaciones un plazo natural para actuar.

Los periodos de validez más cortos cambian esta situación. Cada renovación representa una oportunidad para adoptar los estándares actuales. Esto cobra especial relevancia ahora, dado que el NIST finalizó sus primeros estándares de criptografía post-cuántica , FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) y FIPS 205 (SLH-DSA), en agosto de 2024. Las organizaciones que renuevan sus certificados periódicamente estarán en una posición mucho mejor para adoptar algoritmos resistentes a la computación cuántica a medida que se desarrollen las plataformas y el soporte de las autoridades de certificación.

La menor duración de los certificados reduce el daño derivado de una posible vulneración de claves, disminuye la dependencia de mecanismos de revocación que no siempre funcionan y mantiene actualizados los estándares criptográficos en todo el ecosistema. Aplicar esto a los certificados de firma de código representa un paso directo hacia una mayor seguridad en la cadena de suministro de software . La propuesta CSC-31 formalizó este paso con un límite máximo de validez específico y una fecha de entrada en vigor definitiva para todos los certificados de firma de código de confianza pública.

¿Qué cambió realmente la papeleta de votación CSC-31?

La propuesta CSC-31 del Foro CA/B fue presentada por Microsoft. El plazo para votar finalizó el 13 de octubre de 2025 y la propuesta fue aprobada formalmente el 17 de noviembre de 2025, tras el período de revisión de propiedad intelectual. Siete de los nueve miembros emisores de certificados votaron a favor, dos se abstuvieron y ninguno se opuso. El único voto de un consumidor de certificados, emitido por Microsoft, también fue a favor. El período de revisión de propiedad intelectual finalizó el 17 de noviembre de 2025, sin que se presentaran avisos de exclusión.

La versión 3.10.0 de los Requisitos Básicos de Firma de Código actualizados se publicó el 17 de noviembre de 2025, y el nuevo límite de validez entró en vigor el 1 de marzo de 2026. Este requisito se aplica a todos los certificados de firma de código de confianza pública, es decir, los certificados emitidos por autoridades de certificación cuyas raíces están integradas en los almacenes de confianza del sistema operativo y del navegador. La infraestructura de clave pública privada utilizada para los flujos de trabajo de firma internos no se rige por las normas del Foro CA/B, aunque alinear las prácticas internas con el mismo estándar es un enfoque razonable.

Un detalle práctico importante: el límite de 460 días se calcula a partir de la fecha de emisión, no de la fecha en que se realizó el pedido. Un certificado solicitado antes del 1 de marzo de 2026, pero emitido en o después de esa fecha, está sujeto al nuevo límite. La mayoría de las Autoridades de Certificación (AC) dejaron de emitir certificados de firma de código de 2 y 3 años a finales de febrero de 2026 para garantizar el cumplimiento estricto del plazo. Cualquier certificado de firma de código de confianza pública emitido a partir del 1 de marzo de 2026 tiene una validez máxima de 460 días.

Cumplir con el límite de 460 días sobre el papel es sencillo. La cuestión más difícil es si la infraestructura de firmas existente fue diseñada para funcionar con esa frecuencia.

Por qué la infraestructura de firma no fue construida para esto

El cambio de un certificado de 39 meses a uno de 460 días parece una simple modificación del calendario de renovación. En la práctica, pone de manifiesto problemas estructurales en la forma en que la mayoría de las organizaciones han configurado sus flujos de trabajo de firma.

El primer aspecto es el almacenamiento de claves. Los Requisitos Básicos de Firma de Código ya exigen que las claves privadas de todos los certificados de firma de código de confianza pública, tanto los de Validación de Organización (OV) estándar como los de Validación Extendida (EV), se almacenen en un módulo criptográfico de hardware que cumpla al menos con el Nivel 2 de las Normas Federales de Procesamiento de Información (FIPS) 140-2 o con el Nivel 4+ de los Criterios Comunes. Dado que las validaciones FIPS 140-2 pasarán a la lista histórica el 21 de septiembre de 2026, las organizaciones que adquieran nuevo hardware deberían priorizar los módulos con validación FIPS 140-3 activa para garantizar el cumplimiento continuo más allá de esa fecha.

Para los certificados OV estándar, los tokens de hardware, como los dispositivos USB, son una opción común, pero generan un problema de gestión física. Los tokens se pueden perder, están vinculados a usuarios específicos y su renovación implica volver a configurar el hardware. Con un ciclo de 460 días, este proceso se repite anualmente en lugar de cada tres años, lo que genera mucho más trabajo y aumenta la probabilidad de que surjan problemas si no se gestiona adecuadamente.

El segundo problema es la integración de la canalización. Muchos sistemas de compilación firman artefactos utilizando un certificado y una clave que se colocaron manualmente en una ruta del sistema de archivos, una variable de entorno o una entrada del administrador de secretos. Cuando se reemplaza el certificado, algo en esa cadena se rompe. Con un ciclo de 460 días, esa ruptura ocurre con mayor frecuencia. Los equipos que no cuentan con automatización integral para el aprovisionamiento de certificados, la generación de solicitudes de firma de certificados (CSR), la interacción con la CA y la implementación tendrán dificultades para gestionar este cronograma de manera confiable.

El tercer problema es el inventario. Una sola organización puede tener docenas de certificados de firma de código distribuidos entre líneas de productos, entornos de compilación y sistemas gestionados por contratistas. Es posible que los equipos que poseían esos certificados hace tres años ya no trabajen allí. Sin un registro centralizado de lo que existe, quién lo posee y cuándo vence, un ciclo de renovación de 460 días se vuelve inmanejable.

Las deficiencias estructurales en la infraestructura de firma no solo generan fricciones en la renovación, sino que se convierten en riesgos críticos en el momento en que un certificado se ve comprometido.

¿Qué sucede cuando se ve comprometido un certificado de firma de código?

Un certificado de firma de código comprometido no es solo un incidente de seguridad. Es una emergencia operativa con un plazo límite estricto. Según la versión 3.10.0 de los Requisitos Básicos de Firma de Código, una Autoridad de Certificación (CA) debe revocar un certificado de firma de código dentro de las 24 horas posteriores a la notificación de que el certificado se utilizó para firmar malware o que la clave privada fue robada o expuesta. Este plazo de 24 horas deja muy poco margen para una respuesta lenta o desorganizada.

El problema inmediato radica en la identificación. Antes de que una CA pueda actuar, el certificado en cuestión debe identificarse con precisión: su número de serie, la CA emisora ​​y su estado de revocación actual. Para las organizaciones que no cuentan con un inventario centralizado de certificados, este paso por sí solo puede llevar horas. Si los certificados de firma están distribuidos entre equipos, entornos de compilación y sistemas de contratistas sin un único responsable registrado, encontrar el certificado correcto bajo presión no es tarea fácil.

Una vez revocado, el certificado no puede utilizarse para firmar nada nuevo, y la CA publicará la revocación a través de su CRL y su infraestructura OCSP. Sin embargo, la comprobación de revocación no se aplica de forma consistente en todas las plataformas. Esto significa que un certificado revocado puede seguir siendo aceptado en algunos entornos durante un tiempo después de su revocación, que es precisamente el comportamiento que se pretende limitar con el tiempo al reducir la duración de los certificados.

El certificado de reemplazo debe emitirse e implementarse en todos los flujos de trabajo que dependían del certificado comprometido. Sin una integración documentada de los flujos de trabajo y una implementación automatizada, esto implica un esfuerzo manual adicional bajo presión de tiempo. Las organizaciones con almacenamiento de claves respaldado por un Módulo de Seguridad de Hardware (HSM) están mejor posicionadas en este caso, ya que la vulneración generalmente se limita al certificado y no al hardware subyacente, y la generación de nuevas claves puede realizarse dentro del HSM sin necesidad de reaprovisionar tokens físicos en todos los equipos.

La lección práctica es clara: las mismas deficiencias que dificultan la gestión de un ciclo de renovación de 460 días, como inventarios de certificados incompletos, procesos de firma manual y claves privadas almacenadas en software, también ralentizan la respuesta ante incidentes y aumentan la probabilidad de errores. Abordar estas debilidades antes de que se produzca una brecha de seguridad es mucho menos costoso que intentar solucionarlas durante un incidente en curso.

La respuesta a incidentes no termina con la revocación y el reemplazo del certificado. Las organizaciones también deben comprender cómo el sellado de tiempo afecta la confianza y la usabilidad del software previamente firmado.

La cuestión del sellado de tiempo que la mayoría de los equipos pasan por alto

Un aspecto de la firma de código que cobra mayor importancia cuando los certificados tienen una vigencia más corta es el sellado de tiempo según la RFC 3161. Cuando una firma incluye un sello de tiempo de confianza emitido por una Autoridad de Sellado de Tiempo (TSA, por sus siglas en inglés) , la validez de dicha firma se extiende más allá de la fecha de vencimiento del certificado.

La marca de tiempo proporciona una prueba criptográfica de cuándo se firmó el software, lo que permite que la firma siga siendo válida incluso después de que expire el certificado de firma de código, siempre que la cadena de certificados de la TSA siga siendo válida y confiable en el momento de la verificación. En consecuencia, el software que se firmó y distribuyó antes de la expiración del certificado no pierde automáticamente la confianza bajo el nuevo límite de validez de 460 días. 

Lo que cambia es la propia credencial de firma. Se requiere un certificado válido y vigente para firmar nuevas versiones, nuevas compilaciones y paquetes actualizados. Una vez que un certificado de firma de código caduca, no se puede usar para firmar nada nuevo, incluso si las firmas anteriores de ese certificado siguen siendo válidas. El impacto es directo: cualquier interrupción en la disponibilidad del certificado detiene la entrega de software. En un ciclo de 460 días, una renovación no realizada no permite tres años de margen. Detiene el proceso el día 461.

Estas realidades operativas dejan una cosa clara: las organizaciones necesitan flujos de trabajo de firma diseñados para la renovación continua de certificados, en lugar de la sustitución ocasional de los mismos.

¿Qué cambios son necesarios en los flujos de trabajo de firma digital?

Cumplir con el límite de 460 días es solo el punto de partida. Crear un flujo de trabajo que se mantenga durante la próxima reducción, que es probable dado que los certificados TLS ya están programados para reducirse cada varios años, requiere cambios estructurales.

Comience por el descubrimiento. Administrar certificados de firma de código con un ciclo de renovación de 460 días requiere saber cuántos existen, dónde están implementados, qué flujos de trabajo dependen de ellos y quién es el propietario de cada uno. Para las organizaciones que han estado operando con el antiguo modelo de 39 meses, este inventario a menudo no existe en un formato utilizable. Crearlo es el primer paso antes de que cualquier otra cosa pueda automatizarse o administrarse de manera confiable.

Trasladar las claves de firma al hardware. Las claves privadas almacenadas en sistemas de archivos, máquinas de desarrollo o servidores de compilación deben trasladarse a un HSM. El almacenamiento basado en HSM cumple con el mínimo de nivel 2 de FIPS 140-2 que especifican actualmente los requisitos básicos de firma de código del CA/B Forum, elimina el problema de reaprovisionamiento físico que generan los tokens USB en los ciclos de renovación anuales y reduce el riesgo de que una clave comprometida se utilice para firmar y distribuir software malicioso. Dado que todas las validaciones FIPS 140-2 pasarán a la lista histórica el 21 de septiembre de 2026, las nuevas adquisiciones de hardware deben dirigirse a módulos con validación FIPS 140-3 activa.

Automatice el proceso de renovación. Si bien los requisitos básicos de firma de código del Foro CA/B no exigen la automatización, un ciclo de 460 días hace que la renovación manual sea poco fiable a gran escala. La generación de la solicitud de firma de certificado (CSR), el envío a la CA, la emisión y la implementación deben realizarse mediante un flujo de trabajo repetible y auditable, en lugar de un proceso manual que se inicie unos días antes del vencimiento. El protocolo ACME ( Automatic Certificate Management Environment ), cuando la CA ofrece soporte, elimina por completo los pasos manuales del proceso de renovación.

Prepárense para la próxima reducción. Los certificados de firma de código siguen la misma senda de reducción que TLS. Las organizaciones que implementen hoy una infraestructura de firma automatizada podrán absorber futuras reducciones de validez sin tener que empezar de cero. Las organizaciones que consideren 460 días como un límite permanente podrían enfrentarse a la misma situación cuando se apruebe la próxima votación.

Para muchas organizaciones, alcanzar este nivel de madurez operativa requiere experiencia especializada, herramientas adecuadas y una estrategia de implementación por fases. Ahí es donde Encryption Consulting puede ayudar.

Cómo puede ayudar la consultoría de cifrado

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 necesitan las industrias.

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 nShield, 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 que nunca se exporta.

Quórum de firmas de la M de N y RBAC

El modelo de control de acceso basado en roles (RBAC) de la plataforma aplica requisitos de aprobación multiusuario (M-of-N) para la firma del firmware de producción. Ningún individuo puede iniciar ni aprobar una operación de firma. Todas las solicitudes, aprobaciones y rechazos de firma quedan registrados. La configuración del RBAC es auditable y está controlada por versiones, lo que proporciona la política de firma documentada que exigen las evaluaciones de conformidad de la 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 la 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, satisfaciendo el requisito de la CRA de controles consistentes en todas las líneas de productos sin reconstruir la infraestructura de firma para cada plataforma.

Soporte para criptografía postcuá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 es hoy la arquitectura que protege contra la amenaza HNDL antes de la llegada de una computadora cuántica criptográficamente relevante (CRQC).

Integración de canalización de CI/CD

CodeSign Secure se integra con Azure DevOps , Jenkins , GitLab CI y otras plataformas de canalización importantes mediante interfaces API y de línea de comandos. La firma del firmware es una etapa controlada y regulada dentro del proceso de compilación, no un paso manual.

Las organizaciones que estén atravesando el período de transición de 460 días, ya sea evaluando su inventario actual de certificados, migrando claves a hardware o creando flujos de trabajo de renovación automatizados, pueden contactar a Encryption Consulting para una consulta personalizada. El equipo trabaja directamente con las organizaciones para identificar deficiencias en su infraestructura de firma y diseñar una estrategia práctica antes de que el próximo ciclo de renovación genere presión.

Conclusión

La votación CSC-31 del Foro CA/B marca un cambio significativo en la gestión de los certificados de firma de código de confianza pública. El período de validez de 39 meses, en el que se basaban la mayoría de los equipos, ya no está disponible. Las organizaciones que aún no se hayan adaptado pronto se enfrentarán a su primera renovación de 460 días, y las decisiones de infraestructura que se tomen en ese momento determinarán si las futuras reducciones provocan interrupciones o se gestionan sin problemas.

Las organizaciones que gestionan bien esta situación no son las que añaden un recordatorio al calendario y siguen como si nada. Son las que interpretan el límite de 460 días como la señal que realmente es: el sector avanza hacia una menor duración de los certificados en general, los certificados TLS ya cuentan con un programa de reducción plurianual confirmado, y la firma de código sigue ahora el mismo camino. Crear una infraestructura de firma automatizada y auditable ahora significa no tener que reconstruirla con la próxima reducción.

El Foro CA/B ha mantenido una postura coherente. La vigencia de los certificados seguirá reduciéndose y los procesos manuales de renovación serán cada vez más difíciles de mantener. Las organizaciones que invierten hoy en descubrimiento, almacenamiento de claves basado en hardware y gestión automatizada del ciclo de vida de los certificados de firma de código no solo cumplen con un requisito actual, sino que sientan las bases para afrontar cualquier futura reducción en la validez de los certificados.