Firma segura de código: Validez del certificado reducida a 460 días.

Si gestionas la firma de código en tu organización, debes saber que la industria acaba de cambiar las reglas y el plazo ya ha vencido. El 1 de marzo de 2026 entró en vigor la propuesta CSC-31, adoptada formalmente por el Foro CA/Browser el 17 de noviembre de 2025. Esta propuesta reduce el período máximo de validez de todos los certificados de firma de código de confianza pública de 39 meses (aproximadamente 3 años) a 460 días (aproximadamente 15 meses). Cualquier certificado de firma de código emitido a partir del 1 de marzo de 2026 deberá cumplir con este nuevo límite.

Para los equipos de desarrollo que han estado operando con un ciclo de renovación automático, renovando cada dos o tres años, este cambio altera radicalmente la forma en que la firma de código se integra en el proceso de lanzamiento de software. Lo que antes era una tarea administrativa que se realizaba cada tres años, ahora es una obligación recurrente y de gran importancia operativa que debe gestionarse de forma deliberada y, en la mayoría de los casos, automatizarse.

En este blog, explicaremos con detalle qué ha cambiado, por qué el Foro CA/Browser tomó esta decisión, quiénes son los más afectados y, lo que es más importante, qué debería hacer su equipo ahora mismo para cumplir con la normativa y mantener las operaciones de firma en marcha sin interrupciones.

Validez de 460 días para los certificados de firma de código, definida como la vida útil máxima que el CA/Browser Forum permite para un certificado de firma de código de confianza pública emitido a partir del 1 de marzo de 2026, en comparación con los 39 meses establecidos en la propuesta CSC-31 (aprobada el 17 de noviembre de 2025), lo que prácticamente triplica la frecuencia con la que se debe realizar un seguimiento, renovar y, si el almacenamiento de claves aún depende de tokens físicos, reemplazar físicamente cada certificado de firma que utiliza una organización.

Puntos Clave

• La propuesta CSC-31 fue votada y aprobada el 14 de octubre de 2025, completó la revisión IPR y fue adoptada formalmente el 17 de noviembre de 2025 (publicando los Requisitos Básicos de Firma de Código v3.10.0), y entró en vigor el 1 de marzo de 2026. Los certificados emitidos antes de esa fecha conservan su validez original; los emitidos a partir de esa fecha tienen una validez máxima de 460 días, sin período de gracia.
• Esta es la página canónica y más detallada sobre esta votación específica y sus consecuencias operativas. Para saber cómo encaja esto con las obligaciones separadas de la Ley de Resiliencia Cibernética de la UE que cubren la misma infraestructura de firma, consulte Arquitectura de cumplimiento de la CRA para la firma segura de código, que abarca ambos regímenes en conjunto en lugar de duplicar aquí los detalles de la votación.
• Una menor validez no reduce la necesidad de estar preparado para la revocación, sino que cambia las cifras: una clave comprometida ahora tiene como máximo 460 días de exposición potencial en lugar de 39 meses, pero una vulneración confirmada sigue requiriendo la revocación en un plazo de 24 horas según los Requisitos Básicos, no cuando el certificado caduca.
• Los tokens de hardware USB, tolerables en un ciclo de 3 años, se convierten en un coste operativo recurrente en uno de 15 meses; esta es la razón más común por la que las organizaciones migran a la firma respaldada por HSM después de este cambio, no antes.

Qué cambió y cuándo

El Grupo de Trabajo sobre Certificados de Firma de Código del Foro CA/Browser presentó la propuesta CSC-31 para actualizar los Requisitos Básicos para la Emisión y Gestión de Certificados de Firma de Código de Confianza Pública , versión 3.9.

Aquí está la cronología:

Milestone	Fecha
Propuesta de papeleta CSC-31	Septiembre 2025
La papeleta fue votada y aprobada por el Foro CA/B.	14 de octubre de 2025
Finalizado el período de revisión de IPR, se aprobó formalmente la votación.	17 de noviembre.
Se han publicado los nuevos requisitos básicos de firma de código v3.10.0.	17 de noviembre.
Entra en vigor una nueva validez máxima de 460 días.	Marzo 1, 2026

Los certificados emitidos antes del 1 de marzo de 2026 bajo las normas anteriores conservan su validez hasta su fecha de vencimiento original. Sin embargo, cualquier certificado emitido o renovado a partir del 1 de marzo de 2026 está sujeto al nuevo límite de 460 días. No existe un período de gracia para los certificados de nueva emisión.

Por qué el Foro CA/Navegador realizó este cambio.

La tendencia a reducir la duración de los certificados no es arbitraria ni novedosa. El Foro CA/Browser lleva años reduciendo sistemáticamente la validez de los certificados de todos los tipos. El razonamiento es coherente y se basa en sólidos principios de seguridad.

1. Limitar el radio de explosión de las principales concesiones: La clave privada de un certificado de firma de código puede verse comprometida mediante una filtración de datos, un ataque de ransomware, una amenaza interna o malas prácticas de almacenamiento de claves. Con el antiguo período de validez de 39 meses, una clave comprometida seguía siendo útil para un atacante hasta por tres años, incluso si el certificado era revocado (ya que la verificación de la revocación de certificados no se aplica de forma consistente en todas las plataformas).
   Una vida útil más corta limita directamente el período de exposición. Si una clave se ve comprometida el primer día de un certificado de 460 días, el atacante tiene aproximadamente 15 meses de posible abuso en lugar de tres años.
2. Gestión clave más sólida: Cuando un equipo no necesita preocuparse por su certificado de firma durante tres años, las prácticas de almacenamiento de claves, los controles de acceso y los registros de auditoría tienden a deteriorarse. Las renovaciones anuales o casi anuales obligan a las organizaciones a revisar periódicamente su infraestructura de firma, auditando quién tiene acceso, dónde se almacenan las claves, si los métodos de almacenamiento siguen cumpliendo con los estándares actuales y si los flujos de trabajo de firma siguen siendo adecuados.
3. Fomentar la automatización: Todas las organizaciones que firman código con un certificado de firma de código de confianza pública se ven afectadas. Los períodos de validez más cortos hacen que la gestión manual sea cada vez menos práctica, lo que acelera la adopción de herramientas automatizadas.

El problema del token USB

Merece la pena dedicar un momento específicamente al problema del token de hardware USB, ya que representa el mayor desafío operativo que supone el cambio de 460 días para muchos equipos de desarrollo.

Los requisitos básicos del CA/Browser Forum exigen desde hace varios años que las claves privadas de los certificados de firma de código de confianza pública se almacenen en hardware que cumpla con los estándares FIPS 140-2 Nivel 2 o Common Criteria EAL 4+. Para muchas organizaciones, este requisito se cumplía emitiendo certificados de firma de código en tokens de hardware USB enviados directamente por la Autoridad de Certificación, un modelo que satisfacía el requisito de almacenamiento de claves de hardware sin que la organización tuviera que gestionar su propia infraestructura HSM.

La firma basada en tokens USB introdujo sus propios problemas incluso bajo el antiguo período de validez de 39 meses:

• Los tokens podían perderse, dañarse o ser robados, y su reemplazo requería la reemisión del certificado.
• La firma requería acceso físico al token, lo que generaba cuellos de botella para los equipos remotos y las canalizaciones automatizadas de CI/CD.
• No era fácil realizar copias de seguridad de los tokens, lo que creaba un único punto de fallo en la operación de firma.

Con un período de validez de 460 días, todos estos problemas se repiten con mayor frecuencia. La logística de los tokens, que era manejable en un ciclo de tres años, se convierte en una carga operativa recurrente en un ciclo de 15 meses.

La solución práctica, y la dirección clara que está tomando la industria, es la migración de tokens USB a una infraestructura HSM basada en la nube o local, a la que se accede mediante una plataforma de firma centralizada. Este enfoque almacena la clave privada en hardware compatible con FIPS, permite realizar operaciones de firma mediante API desde cualquier sistema de compilación autorizado, elimina por completo la logística de los tokens físicos y se integra de forma natural con una plataforma de firma de código centralizada.

Por qué el sellado de tiempo se vuelve aún más crucial ahora

Una de las consideraciones técnicas más importantes para reducir la duración de los certificados es el sellado de tiempo. Cuando un certificado de firma de código caduca, el software firmado con dicho certificado no deja de ser confiable automáticamente. Si la operación de firma incluyó un sellado de tiempo válido según la RFC 3161, emitido por una Autoridad de Sellado de Tiempo (TSA) de confianza, la firma permanece verificable indefinidamente, incluso después de que el certificado caduque. El sellado de tiempo proporciona una prueba criptográfica de que la operación de firma se realizó mientras el certificado era válido, y dicha prueba se mantiene vigente más allá del período de validez del certificado.

Sin una marca de tiempo, la confiabilidad del artefacto firmado está directamente ligada al período de validez del certificado. Una vez que el certificado caduca, los sistemas de verificación que comprueban su validez rechazarán la firma. Para cualquier software con una vida útil superior a 15 meses, lo que incluye prácticamente todas las aplicaciones empresariales, controladores, imágenes de firmware o ejecutables de larga duración, la ausencia o la aplicación incorrecta de una marca de tiempo implica que dicho software acabará perdiendo su estatus de confianza.

Cuando los certificados se renuevan anualmente, cualquier documento firmado que carezca de una marca de tiempo RFC 3161 adecuada se convierte en un problema potencial dentro de los 15 meses posteriores a la firma. Los pasos prácticos a seguir son:

• Verifique que su conjunto de herramientas de firma aplique las marcas de tiempo RFC 3161 de forma predeterminada en cada operación de firma.
• Configure sus procesos de firma para que traten la ausencia de una marca de tiempo como un fallo de firma y no como una advertencia.
• Asegúrese de que las marcas de tiempo se apliquen utilizando el algoritmo de hash SHA-256 (no SHA-1, que está en desuso).
• Para los componentes con una larga vida útil (firmware, controladores, software empresarial), verifique que la configuración de la marca de tiempo se haya aplicado correctamente también a todos los componentes históricos.

Revocación bajo el nuevo período de validez

A veces se describe la menor validez como una reducción de la necesidad de revocación. Esto no es del todo correcto: reduce la exposición máxima que puede causar una vulneración, pero no cambia la obligación de revocación en sí. 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 la vulneración de la clave privada, tanto para un certificado de 460 días como para uno de 39 meses. Lo que cambia el plazo más corto es el límite máximo: si una clave se ve comprometida al día siguiente de su emisión y pasa desapercibida, el plazo máximo que un atacante podría explotar teóricamente se reduce de aproximadamente tres años a unos 15 meses.

La implicación práctica para su lista de verificación de auditoría es la siguiente: confirme que su organización puede identificar, en el plazo de una hora tras sospechar una intrusión, cada elemento firmado por un certificado específico. Esperar a que un certificado caduque no constituye un plan de revocación, y la mayor frecuencia de renovación que introduce este cambio no sustituye una respuesta probada ante una intrusión.

Requisitos antiguos frente a requisitos nuevos, uno al lado del otro

Requisito	Antes del 1 de marzo de 2026	A partir del 1 de marzo de 2026
Validez máxima del certificado	39 meses	460 días
Frecuencia de renovación (típica)	Aproximadamente cada 3 años	Aproximadamente cada 15 meses
Cronograma de revocación para la vulneración de claves confirmada	24 horas (sin cambios)	24 horas (sin cambios)
Almacenamiento de claves privadas	Hardware compatible con FIPS 140-2 Nivel 2+ o Criterios Comunes EAL4+ (desde junio de 2023)	Mismo requisito, sin cambios
Máxima exposición teórica derivada de una vulnerabilidad clave no detectada.	Hasta ~39 meses	Hasta ~460 días

Lista de verificación de auditoría: Qué debe hacer ahora mismo

Si su organización aún no ha evaluado el impacto del cambio de 460 días, aquí tiene un punto de partida práctico:

Paso 1: Audite su inventario de certificados de firma de código. Identifique todos los certificados de firma de código de confianza pública que utiliza su organización. Para cada uno, registre la fecha de vencimiento, el método de almacenamiento (token USB, HSM, HSM en la nube, repositorio de software), los flujos de trabajo o canalizaciones de firma que dependen de él y quién es responsable de su renovación. Si no dispone de esta información documentada de forma centralizada, la creación de dicho inventario es la prioridad principal.

Paso 2: Identifique los certificados que ya están sujetos a las nuevas normas. Cualquier certificado emitido a partir del 1 de marzo de 2026 tiene una vigencia limitada a 460 días. Identifique cuáles de sus certificados se encuentran en esta categoría y programe las renovaciones con la antelación adecuada: planifique la renovación con al menos 30 a 60 días de anticipación para permitir la adquisición, el aprovisionamiento y las actualizaciones de la infraestructura.

Paso 3: Evalúe su infraestructura de almacenamiento de claves. Si su organización utiliza tokens de hardware USB, evalúe si es conveniente migrar a un HSM en la nube o a un HSM local con acceso a través de una plataforma de firma centralizada. Dada la logística recurrente de la renovación de tokens USB cada 15 meses, es probable que esta migración resulte rentable durante el primer ciclo de renovación.

Paso 4: Verifique la configuración de la marca de tiempo. Audite sus procesos de firma para confirmar que las marcas de tiempo RFC 3161 se aplican en cada operación de firma, utilizando SHA-256, y trate la falta de una marca de tiempo como un error que bloquea su proceso.

Paso 5: Actualizar las configuraciones de la canalización para referencias de certificados dinámicos. Revisar todas las configuraciones de la canalización de CI/CD , los scripts de compilación y las configuraciones de las herramientas de firma que hacen referencia a certificados de firma. Reemplazar los identificadores estáticos por referencias dinámicas que no requieran actualización manual en cada renovación.

Paso 6: Evalúe la automatización de la gestión del ciclo de vida de los certificados. Si su organización gestiona una cantidad significativa de certificados en varios equipos o productos, evalúe una plataforma de firma centralizada dedicada que pueda automatizar la detección, las alertas de renovación y la implementación integrada en el flujo de trabajo.

Cómo ayuda CodeSign Secure de Encryption Consulting

CodeSign Secure es la plataforma centralizada de firma de código con políticas de Encryption Consulting. Fue diseñada precisamente para el entorno que el cambio de 460 días está acelerando: un entorno donde la operación de firma debe automatizarse, las claves deben administrarse centralmente en una infraestructura respaldada por HSM, y los eventos del ciclo de vida de los certificados deben rastrearse y procesarse sin depender del conocimiento individual de los desarrolladores.

Gestión centralizada de claves con soporte 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, eliminando por completo el modelo de token USB. La plataforma se integra con Thales Luna, Entrust nCipher, Utimaco, Securosys y los principales HSM en la nube de AWS y Azure. Las claves privadas se generan dentro del HSM, nunca se exportan y solo se puede acceder a ellas a través de la API de firma de la plataforma.

Alertas sobre el ciclo de vida y la renovación de los certificados

CodeSign Secure mantiene un inventario centralizado de todos los certificados gestionados, con visibilidad de las fechas de caducidad y alertas de renovación configurables. Los equipos de seguridad y operaciones reciben notificaciones anticipadas antes de que caduquen los certificados, lo que elimina el riesgo de descubrir un certificado caducado.

Integración de canalización de CI/CD

La plataforma se integra de forma nativa con Azure DevOps, Jenkins, GitLab CI y otros sistemas de canalización importantes mediante interfaces API y de línea de comandos. Las operaciones de firma se realizan con la canalización haciendo referencia al certificado válido actual de forma dinámica a través de la plataforma, en lugar de mediante una referencia de certificado estática. Cuando se renueva un certificado, las operaciones de firma de la canalización continúan sin interrupción y sin necesidad de actualizar la configuración de la canalización.

Preparación para la era post-cuántica

A medida que el sector de los certificados avanza hacia ciclos de vida más cortos, también se prepara para la migración a la criptografía postcuántica que el NIST ya ha estandarizado. CodeSign Secure v3.02 admite ML-DSA (FIPS 204) para la firma, proporcionando firmas separables, lo que permite a las organizaciones comenzar la transición de su infraestructura de firma de código a algoritmos resistentes a la computación cuántica, manteniendo la compatibilidad con las plataformas existentes.

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 período de validez y fecha de vencimiento originales. El límite de 460 días se aplica únicamente a los certificados emitidos o renovados a partir de esa fecha, sin período de gracia.

¿Una menor vigencia significa que puedo preocuparme menos por la revocación?

No. Si se confirma una vulneración de clave, la revocación sigue requiriendo un plazo de 24 horas según los Requisitos Básicos de Firma de Código, tanto para un certificado de 460 días como para el antiguo de 39 meses. Una menor validez solo reduce el período máximo de exposición si la vulneración pasa desapercibida; no elimina la necesidad de un proceso de revocación probado.

¿Aún debo preocuparme por la caducidad del certificado si utilizo el sellado de tiempo de confianza?

Para el software ya firmado y distribuido, no: una marca de tiempo válida según la RFC 3161 mantiene la firma verificable incluso después de que expire el certificado. Aun así, es necesario renovar el certificado antes de su vencimiento para seguir firmando nuevas versiones.

¿Es obligatorio dejar de usar tokens USB con este cambio?

No es obligatorio, pero resulta muy recomendable desde el punto de vista económico. El mismo requisito de hardware FIPS 140-2 Nivel 2+ se aplica tanto si se utiliza un token como un HSM; un ciclo de renovación de 460 días simplemente hace que la logística recurrente de reemplazo físico de tokens, la pérdida y los cuellos de botella de CI/CD sean mucho más frecuentes que con un ciclo de 3 años.

¿En qué se diferencia esto de los requisitos de cumplimiento de la CRA para la firma de códigos?

Son regímenes distintos. Esta votación es una norma del sector CA/Browser Forum sobre el ciclo de vida de los certificados; la Ley de Resiliencia Cibernética de la UE es una obligación legal independiente sobre la integridad del firmware a nivel de producto y la divulgación de vulnerabilidades. Una organización que firma productos sujetos a la CRA debe cumplir con ambas normativas; consulte la Arquitectura de Cumplimiento de la CRA para la Firma Segura de Código para comprender su interrelación.

Conclusión

El cambio en el certificado de firma de código de 460 días, que entró en vigor el 1 de marzo de 2026, no es el final de esta historia; es un paso más en la dirección que el Foro CA/Browser ha estado impulsando de forma constante durante años. Las organizaciones que gestionarán estos cambios con la menor interrupción serán aquellas que traten la gestión del ciclo de vida de los certificados como una función disciplinada, automatizada y a nivel de infraestructura, y no como una tarea manual periódica.

Para los equipos de desarrollo que aún dependen de tokens USB y recordatorios de renovación manual, el cambio a 460 días es el momento oportuno para evaluar si este enfoque es sostenible. La logística del reemplazo anual de tokens, las actualizaciones de la configuración del flujo de trabajo y el seguimiento manual de la renovación en múltiples certificados se complicarán rápidamente a medida que los períodos de validez se acorten.

En Encryption Consulting, nuestra plataforma CodeSign Secure está diseñada para que esa transición sea práctica, proporcionando a su equipo seguridad de claves respaldada por HSM, gestión automatizada de certificados y firma integrada en el flujo de trabajo que gestiona las renovaciones sin intervención manual.