Los certificados de firma de código se reducen a 460 días.

La validez de un certificado de firma de código es el número máximo de días que un certificado de firma de código de confianza pública puede permanecer válido antes de que deba renovarse. Desde el 1 de marzo de 2026, este plazo se ha reducido a 460 días, frente a los 39 meses que los equipos habían utilizado durante años. Esta norma proviene de la propuesta CSC-31 del Foro CA/Browser (aprobada el 17 de noviembre de 2025, que publica los Requisitos Básicos de Firma de Código v3.10.0), establecida por el grupo de autoridades de certificación y proveedores de navegadores que define las reglas que debe seguir cada certificado público. Este blog explica los cambios, el funcionamiento de la firma y el sellado de tiempo, la ubicación de las claves privadas y cómo prepararse sin prisas de última hora.

El cumplimiento de la firma de código según la regla de los 460 días se define de la siguiente manera: mantener cada certificado de firma de código de confianza pública emitido a partir del 1 de marzo de 2026 dentro de su período máximo de validez de 460 días, con un proceso de revocación probado, sellado de tiempo obligatorio según la RFC 3161 y almacenamiento de claves respaldado por HSM, todo ello inventariado de forma centralizada para que un ciclo de renovación de 15 meses no supere el seguimiento manual.

Puntos Clave

• La propuesta CSC-31 fue aprobada el 17 de noviembre de 2025 (Requisitos básicos de firma de código v3.10.0); el límite de 460 días entró en vigor el 1 de marzo de 2026 para los certificados emitidos a partir de esa fecha.
• Este sitio cubre esta votación con mayor profundidad en Firma segura de código: Validez del certificado reducida a 460 días. y La vigencia de los certificados de firma de código es cada vez menor.y como parte de una arquitectura de cumplimiento de régimen dual en Arquitectura de cumplimiento de la CRA para la firma segura de códigoPara obtener información detallada sobre la gobernanza de la votación y la lista de verificación de auditoría, comience por ahí; esta página se centra en el proceso de compilación y los mecanismos de sellado de tiempo.
• La confirmación de una vulneración de la clave sigue requiriendo la revocación de la CA en un plazo de 24 horas, independientemente de la validez del certificado; una menor validez reduce el período máximo de exposición, pero no modifica dicho plazo.
• Una marca de tiempo válida según la RFC 3161 permite verificar el software ya distribuido una vez que caduca el certificado de firma; lo que lo impide es la posibilidad de firmar cualquier software nuevo.

¿Qué cambió el 1 de marzo de 2026?

La regla es sencilla. Ningún certificado de firma de código emitido a partir del 1 de marzo de 2026 podrá tener un periodo de validez superior a 460 días, o aproximadamente 15 meses. Los certificados emitidos antes de esa fecha seguirán funcionando según su calendario original hasta que caduquen de forma natural, por lo que durante un tiempo coexistirán certificados de larga y corta duración. Esta regla se aplica por igual a los certificados de Validación de Organización (OV) y Validación Extendida (EV), sin excepción alguna, y refleja un patrón que el sector ya ha implementado con los certificados TLS. La firma de código simplemente se está adaptando ahora.

Desde el punto de vista del riesgo, el razonamiento es sencillo. Un certificado de firma de código representa confianza, y esa confianza se mantiene mientras el certificado siga siendo válido. Si la clave privada asociada se roba o se utiliza indebidamente, el daño dura exactamente lo mismo que el certificado. Un certificado de tres años le da a un atacante un plazo de tres años para seguir utilizando una clave robada. Un certificado de 460 días reduce ese plazo a menos de la mitad y obliga a las organizaciones a rotar las claves periódicamente en lugar de dejarlas sin usar durante años.

La menor duración de los certificados impulsa a los equipos hacia la automatización casi por obligación, ya que la gestión manual de los mismos se vuelve inviable rápidamente cuando la renovación se realiza cada 15 meses en lugar de cada tres años. Ese cambio, de una tarea ocasional a un proceso operativo rutinario, es realmente el objetivo de la norma, más que el número específico de días elegido.

Cómo funcionan realmente la firma de código y el sellado de tiempo en conjunto

Cuando un editor firma un software, se crea un hash, una huella digital única del código que cambia por completo si se modifica incluso un solo byte. Este hash se firma con la clave privada del editor, generando una firma digital que se adjunta al software junto con el certificado público del editor. Cuando un usuario descarga el archivo, su sistema operativo recalcula el hash y lo compara con la firma mediante la clave pública. Si coinciden y el certificado se vincula a una autoridad de certificación raíz de confianza, el software se muestra como verificado; si algo ha cambiado desde la firma, la firma falla. Por eso la clave privada es tan importante y por eso las normas sobre su ubicación son cada vez más estrictas.

Esto plantea una pregunta obvia: ¿qué sucede con el software que firmaste hace años una vez que caduca el certificado que lo respalda? La respuesta es el sellado de tiempo, el detalle más importante en esta transición. Al firmar código, tus herramientas también pueden enviar la firma a una Autoridad de Sellado de Tiempo (TSA), un tercero de confianza que registra la prueba criptográfica de cuándo se creó la firma, siguiendo el Protocolo de Sellado de Tiempo IETF RF C 3161 , un estándar que la mayoría de las herramientas de firma ya admiten.

Una vez que se adjunta una marca de tiempo, el sistema operativo puede confirmar que la firma se creó mientras el certificado aún era válido, incluso después de que este caduque. La confianza se establece en el momento de la firma, no cuando alguien abre el archivo, lo que permite que la rotación frecuente funcione.

El problema es que el sellado de tiempo no es automático en todas partes. Algunos scripts de compilación antiguos lo omiten, y algunas herramientas heredadas no lo verifican correctamente. Dado que los certificados ahora caducan aproximadamente cada 15 meses, conviene auditar el proceso de firma para confirmar que cada compilación tenga el sellado de tiempo correcto. Sin embargo, lograr un sellado de tiempo correcto es solo la mitad del trabajo; la otra mitad consiste en asegurarse de que el flujo de trabajo pueda adaptarse a los certificados que ahora se renuevan cada 15 meses en lugar de cada pocos años.

Preparación de su canalización de compilación

Para la mayoría de los equipos, el impacto operativo se reduce a unos pocos cambios concretos. Los sistemas de compilación ya no pueden codificar una ruta de certificado y asumir que funcionará durante años; las canalizaciones deben obtener el certificado válido actual de forma dinámica en lugar de apuntar a un archivo estático que eventualmente quedará obsoleto a mitad de la versión. Los entornos de firma aislados, comunes en el control industrial, la atención médica y el software gubernamental, necesitan un cronograma predecible para importar nuevos certificados, ya que a menudo no pueden obtener una renovación automáticamente.

La compra de certificados plurianuales debe dar paso a una presupuestación y un tiempo de aprobación de renovaciones más frecuentes, y cualquier persona que gestione certificados EV u OV necesita un calendario de renovaciones que tenga en cuenta el tiempo de validación de la CA, que puede tardar unos días y nunca debe dejarse para el último momento.

Nada de esto es difícil en sí mismo. El verdadero desafío radica en que, históricamente, la firma digital se ha tratado como una tarea de configuración que se realiza cada pocos años, no como un proceso continuo. Abordarlo como una secuencia corta facilita la transición. Comience con un inventario completo: enumere todos los certificados de firma de código en servidores de compilación, canalizaciones de CI/CD, estaciones de trabajo de firma y entornos aislados, registrando la CA emisora, la fecha de emisión, la fecha de vencimiento y la ubicación de cada clave privada. Esto suele revelar más certificados de los que los equipos esperan.

A continuación, asegúrese de que el sellado de tiempo sea obligatorio auditando sus scripts de firma para confirmar que cada compilación esté sellada con una TSA de confianza. Luego, automatice la renovación y la rotación de claves donde aún queden pasos manuales, ya que la renovación manual no es escalable una vez que los certificados caducan cada 15 meses. Finalmente, establezca una política clara sobre la robustez de las claves, los algoritmos aprobados, el nivel de certificación HSM requerido y la propiedad de los certificados, y mantenga un registro de auditoría de cada operación de firma para que las revisiones de cumplimiento sean sencillas.

Algunos errores se repiten con frecuencia. Aquí tienes algunos consejos para solucionarlos:

• No dé por sentado que todos sus certificados caducan en la misma fecha; tendrá una combinación de certificados con validez larga y corta coexistiendo durante un tiempo.
• No olvide que los procesos basados ​​en un archivo de certificado estático dejarán de funcionar en el momento en que dicho certificado caduque, a menudo a mitad del ciclo de lanzamiento.
• No considere la marca de tiempo como algo opcional, ya que es el factor más importante para que el software antiguo firmado siga siendo confiable.
• No deje las claves privadas sin modificar entre renovaciones, ya que eso anula gran parte del beneficio de seguridad que se supone que proporciona una validez más corta.

La revocación no se vuelve más fácil solo porque la validez sea más corta.

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 privada, independientemente de si dicho certificado tiene una vigencia de 460 días o la anterior de 39 meses. Una menor validez solo limita la exposición máxima en caso de que una vulneración pase desapercibida; no sustituye la capacidad de identificar, en el plazo de una hora, cada elemento firmado por un certificado determinado. Desarrolle esta capacidad antes de necesitarla, no durante un incidente.

De esta forma, la reducción de la duración de los certificados deja de ser un problema y se convierte en una práctica habitual en la distribución de software. Además, los hábitos que se adquieren ahora son precisamente los que exigirá el próximo gran cambio criptográfico, por lo que el esfuerzo nunca será en vano.

Cómo se relaciona esto con la criptoagilidad y la preparación post-cuántica

Las mismas habilidades que desarrolla para gestionar certificados de firma de código de 460 días (descubrimiento, automatización y rotación rápida) son precisamente las que su organización necesitará para la transición hacia la criptografía postcuántica (PQC). El NIST finalizó sus primeros estándares postcuánticos en agosto de 2024: FIPS 203 (ML-KEM) para la encapsulación de claves, y FIPS 204 (ML-DSA) y FIPS 205 (SLH-DSA) para firmas digitales. Estos son estándares definitivos, no borradores, y se espera que las organizaciones comiencen a planificar en función de ellos desde ahora.

La firma de código tiene su propia fecha límite que conviene conocer. El conjunto de algoritmos de seguridad nacional comercial 2.0 (CNSA 2.0) de la NSA exige que la firma de software y firmware admita y dé preferencia a los algoritmos post-cuánticos, específicamente a los esquemas basados ​​en hash con estado LMS y XMSS (NIST SP 800-208), una fase que comenzó en 2025 y cuyo uso exclusivo es obligatorio para 2030. Desarrollar ahora buenos hábitos de inventario y rotación criptográfica, mientras se trabaja en la transición de 460 días, permitirá que su equipo se anticipe a este cambio en lugar de tener que empezar de cero más adelante.

La criptoagilidad es la capacidad de reemplazar algoritmos, claves y certificados criptográficos con una mínima interrupción de los sistemas existentes, lo que permite a las organizaciones responder rápidamente a la obsolescencia de algoritmos, la evolución de los requisitos normativos o las amenazas emergentes sin rediseñar su infraestructura de firma. En la práctica, esto significa que la migración a nuevos estándares, como los exigidos por CNSA 2.0 o las futuras directrices post-cuánticas, se convierte en un cambio operativo en la política criptográfica en lugar de un costoso esfuerzo de ingeniería.

También proporciona resiliencia operativa. Si un algoritmo de firma queda obsoleto, se descubre una vulnerabilidad o cambian las aprobaciones regulatorias, las organizaciones pueden migrar a un algoritmo alternativo sin interrumpir los procesos de lanzamiento de software. Durante el período de migración post-cuántica, la estrategia recomendada es la firma de código híbrida, donde cada artefacto se firma utilizando tanto un algoritmo clásico (como ECDSA o RSA) como un algoritmo post-cuántico (como ML-DSA o LMS). Esto permite a las partes que confían en la información validar las firmas utilizando cualquiera de los dos esquemas, preservando la interoperabilidad con los sistemas existentes y proporcionando continuidad criptográfica a medida que se generaliza el soporte post-cuántico.

Las organizaciones que ya han modernizado su infraestructura de firma de código con gestión automatizada del ciclo de vida de los certificados, rotación periódica de certificados, almacenamiento seguro de claves en entornos con soporte de hardware y sellado de tiempo conforme a la RFC 3161 están en una posición mucho mejor para adoptar nuevos algoritmos a medida que evolucionan los estándares. En la práctica, alcanzar este nivel de criptoagilidad es mucho más fácil con herramientas diseñadas específicamente para ello y la experiencia adecuada.

Cómo puede ayudar la consultoría de cifrado

Adaptarse a una menor validez de la firma de código es mucho más sencillo cuando las prácticas de gestión de certificados y claves ya están organizadas, en lugar de dispersas entre equipos y herramientas. Encryption Consulting colabora con equipos de seguridad, PKI y DevSecOps para estructurar precisamente este tipo de transición, comenzando con una visión clara de dónde se encuentran actualmente todos los certificados y claves.

Nuestro equipo ayuda a las organizaciones a construir y modernizar su infraestructura de clave pública, y nuestra plataforma CodeSign Secure está diseñada específicamente para poner en práctica las estrategias descritas en este blog: almacenamiento de claves privadas con HSM, flujos de trabajo de aprobación basados ​​en políticas, sellado de tiempo automático en cada operación de firma y registros de auditoría detallados. CodeSign Secure también incluye soporte nativo para algoritmos de firma post-cuánticos como ML-DSA y LMS, por lo que los equipos que la adopten ahora no tendrán que iniciar un segundo proyecto de migración cuando lleguen los plazos de CNSA 2.0.

Además de la firma de código, ayudamos con la gestión integral del ciclo de vida de los certificados, la gestión de claves y el mapeo de cumplimiento con estándares como NIST y PCI DSS, para que su proceso de firma resista tanto las auditorías como los ataques.

Conclusión

El cambio a certificados de firma de código de 460 días representa una transformación significativa, pero manejable si se empieza ahora. Cree un inventario claro de sus certificados, estandarice el sellado de tiempo, rote las claves privadas con cada renovación y automatice los pasos manuales que aún persistan. Los equipos que lo consideren un mantenimiento rutinario apenas notarán la transición. Quienes esperen la notarán en su calendario de lanzamientos, probablemente más de una vez, ya que esta es la primera de varias reducciones en la vida útil de los certificados que están por venir. Si necesita ayuda para preparar la firma de código y la gestión del ciclo de vida de los certificados para este cambio, o para lo que venga después, Encryption Consulting es un buen punto de partida para hablar de ello.

Preguntas frecuentes

¿El límite de 460 días se aplica a los certificados que ya tengo?

No. Los certificados emitidos antes del 1 de marzo de 2026 conservan su validez y fecha de vencimiento originales. El límite máximo se aplica únicamente a los certificados emitidos o renovados a partir de esa fecha.

¿Aún debo preocuparme por la caducidad del certificado si le asigno una marca de tiempo a todo?

Para el software que ya ha distribuido, no, una marca de tiempo RFC 3161 válida lo mantiene verificable. Aún necesita un certificado válido y vigente para firmar cualquier nueva versión, por lo que la renovación debe realizarse según lo programado.

¿Una menor validez reduce la urgencia de planificar la revocación?

No. Si se confirma que una clave se ha comprometido, aún así se requiere su revocación en un plazo de 24 horas según los Requisitos Básicos de Firma de Código, independientemente de la duración del período de validez del certificado.