Comprender el nuevo cambio en la validez de los certificados de firma de código.

Firma de código Es el mecanismo de confianza que permite a un sistema operativo confirmar quién publicó un software y si este ha sido modificado desde su firma. En la criptografía de clave pública, un certificado contiene la clave pública, mientras que el editor mantiene en secreto la clave privada correspondiente. Un certificado de firma de código vincula la identidad del editor con una clave pública, y la clave privada correspondiente genera la firma que Windows SmartScreen, los cargadores del sistema operativo y los instaladores verifican antes de confiar en un ejecutable, controlador o instalador.

El cambio de validez, introducido por Foro CA/Browser, Boleta CSC-31: Reducción de validez máximaEsta medida entró en vigor el 1 de marzo de 2026. Este artículo se centra en dicho cambio de validez: cuál es el nuevo límite, el razonamiento criptográfico que lo sustenta, cómo interactúa con el sellado de tiempo y la revocación, a quién afecta y los pasos concretos necesarios para adaptarse.

Lo que dice el nuevo cambio de validez

La Foro CA/Browser (Foro CA/B) es el organismo de autoridades de certificación y consumidores de certificados, como proveedores de navegadores y sistemas operativos, que definen los requisitos básicos para los certificados de confianza pública. El 13 de octubre de 2025, concluyó la votación sobre la propuesta CSC-31, que modifica los Requisitos Básicos de Firma de Código para establecer la validez máxima de un certificado de firma de código en 460 días, en lugar del límite anterior de 39 meses. El cambio fue propuesto por Microsoft y respaldado por Sectigo y eMudhra, y fue adoptado el 17 de noviembre de 2025, como Requisitos básicos de firma de código, versión 3.10.0.

El límite se aplica tanto a los certificados de firma de código de Validación de Organización (OV) como a los de Validación Extendida (EV). Rige el campo de validez establecido en el momento de la emisión, por lo que se aplica a cualquier certificado emitido o renovado a partir del 1 de marzo de 2026. Certificados Los documentos emitidos antes de esa fecha con una validez mayor seguirán siendo fiables hasta su fecha de caducidad indicada.

Los números

Atributo	Requisito previo	Bajo CSC-31
Validez máxima	39 meses	460 días
Fecha efectiva	No es aplicable	Marzo 1, 2026
Versión de requisitos básicos	v3.9	v3.10.0
Tipos de certificados afectados	OV y EV	OV y EV

Aunque la votación fija el plazo máximo en 460 días, en la práctica algunas autoridades de certificación emiten certificados a 459 días para tener margen de seguridad ante posibles desfases temporales y latencia en la emisión. DigiCert, por ejemplo, describe su lanzamiento con una validez de 459 días, y SSL.com emite certificados a 458 días por la misma razón. Varias autoridades de certificación dejaron de vender certificados de dos y tres años a finales de 2025, antes del cambio, y ahora los certificados de un año (366 días) son la opción predeterminada.

El razonamiento detrás de un período de validez más corto

La reducción de validez es una aplicación de un método bien establecido. gestión de claves Se trata de un principio fundamental, más que de una reacción a un incidente puntual. Un certificado de firma de código vincula una clave privada de larga duración a una identidad. Cuanto más tiempo sea válida esta vinculación, más tiempo podrá una clave robada o utilizada indebidamente generar firmas de confianza, y mayor será el volumen de documentos firmados que un atacante podrá crear antes de que alguien intervenga.

Criptoperíodos en la guía de gestión de claves del NIST

Esto se corresponde directamente con el concepto de criptoperíodo definido en Publicación especial 800-57 del NIST, Parte 1, Revisión 5, Recomendación para la gestión de clavesUn criptoperíodo es el lapso de tiempo durante el cual una clave está autorizada para su uso. NIST Se recomienda limitar su alcance para evitar que el riesgo se acumule indefinidamente, y la publicación modela cada clave pasando por los estados de preactivación, activo, desactivado, comprometido y destruido. Limitar la validez del certificado a 460 días impone un límite al período activo de la clave de firma asociada, lo que garantiza que las vinculaciones de identidad se revaliden al menos cada quince meses; la rotación de la clave de firma requiere generar un nuevo par de claves al renovarla, que es la práctica recomendada.

Recomendaciones específicas para la firma de código

El NIST también publicó una guía dedicada a este caso de uso. Libro Blanco de Ciberseguridad del NIST: Consideraciones de seguridad para la firma de código.Explica cómo la firma de código garantiza la integridad y la autenticación de la fuente, y recomienda aislar las claves de firma, almacenarlas en un módulo de seguridad de hardware restringido a las funciones de firma, separar los sistemas de firma de desarrollo y producción, y exigir la aprobación de varios participantes antes de una operación de firma. Un período de validez obligatorio más corto refuerza estos controles al forzar la reemisión periódica, lo que revalida la identidad del editor y rota la vinculación de la clave según un calendario fijo.

Cómo interactúa la validez con la firma, el sellado de tiempo y la revocación.

Para evaluar el impacto operativo de un período de validez más corto, la relación entre el certificado, la marca de tiempo y la revocación debe ser precisa. El certificado define el período durante el cual se confía en una clave de firma, la marca de tiempo registra cuándo se generó una firma y la revocación retira la confianza antes de que el certificado caduque.

La operación de firma

1. El editor calcula un resumen criptográfico del artefacto utilizando una función hash aprobada, como SHA-256.
2. El resumen se firma con la clave privada, lo que produce la firma, que se incrusta en el artefacto junto con el certificado del editor y su cadena hasta una raíz de confianza.
3. En el momento de la verificación, el cargador recalcula el resumen criptográfico, verifica la firma con la clave pública del certificado y valida la cadena y el estado de validez del certificado.

Por qué un período de validez más corto no invalida el software ya firmado.

Una preocupación frecuente es que los certificados con menor vigencia provoquen que el software previamente lanzado deje de validarse. Esto no sucederá, siempre y cuando la firma tenga una marca de tiempo. Una marca de tiempo de una Autoridad de Marcas de Tiempo de confianza registra el instante de la firma. Si el certificado era válido en ese instante, la firma se mantiene válida durante la vigencia de la marca de tiempo, que suele ser mucho mayor que la del certificado. Por eso, un controlador firmado hace años aún se instala aunque su certificado de firma haya caducado mucho antes.

Esa misma propiedad es el núcleo del problema de seguridad que aborda el cambio de validez. Debido a que una firma con marca de tiempo sobrevive al certificado, un certificado comprometido continúa generando firmas confiables mucho después del momento del compromiso. Acortar la validez reduce esa ventana de exposición y la revocación la cierra. El estado de revocación se publica a través de Listas de revocación de certificados (CRL) y conectar Protocolo de estado del certificado en línea (OCSP)Una autoridad de certificación (CA) puede revocar un certificado comprometido para que los verificadores rechacen las firmas que se basen en él. Dado que una firma con marca de tiempo realizada antes de la fecha de revocación generalmente sigue siendo válida, la CA debe restablecer la fecha de revocación al momento en que se sospecha que se produjo el compromiso para invalidar las firmas generadas con anterioridad.

Incidentes recientes que ilustran el riesgo

La vulnerabilidad que generan las credenciales de firma de larga duración y con una gestión deficiente no es hipotética. Varias campañas recientes demuestran por qué el ecosistema está reduciendo la vigencia de los certificados y reforzando los controles relacionados.

Violación de seguridad en la producción de AnyDesk (2024)

A principios de 2024, el proveedor de acceso remoto AnyDesk confirmó que los atacantes llegaron a sus sistemas de producción y que se robaron el código fuente y las claves privadas de firma de código, según informes de BleepingComputerLa empresa respondió revocando los certificados afectados y renovando su material de firma. Incidentes como este demuestran la importancia de limitar la vigencia de los certificados, ya que esto reduce el tiempo durante el cual un certificado robado puede ser explotado.

Hijack Loader y GHOSTPULSE firmaron campañas (finales de 2024)

En octubre de 2024, los investigadores documentaron muestras de Hijack Loader (también conocido como GHOSTPULSE e IDAT Loader) firmadas con credenciales legítimas. certificados de firma de códigoEste ataque se produjo mediante la técnica de ingeniería social ClickFix, que engaña a los usuarios para que ejecuten PowerShell. Los investigadores descubrieron varios certificados maliciosos vinculados a la misma infraestructura de comando y control, y las autoridades emisoras los cancelaron en cuestión de horas o un día tras ser notificadas. Este episodio demuestra tanto la importancia que los atacantes otorgan a las firmas válidas como el papel fundamental que desempeña la revocación rápida para contener el abuso.

Abuso de los certificados de corta duración de Microsoft Trusted Signing (2025)

En marzo de 2025, se observó que los atacantes firmaban malware a través de El servicio de firma de confianza de Microsoft utiliza certificados de tres días.Este caso ilustra dos dinámicas distintas. Demuestra que los actores decididos seguirán buscando firmas válidas, pero también evidencia el valor defensivo de los certificados de corta duración emitidos centralmente: las credenciales nunca se entregan al desarrollador, por lo que no pueden ser robadas de un punto final, y caducan y pueden ser revocadas casi de inmediato. Este modelo es precisamente la dirección que fomenta la reducción de la validez.

Abuso de conductores a escala industrial (2020 a 2025)

Una investigación de 2025 realizada por Grupo-IB Se rastreó una operación de larga duración que acumuló más de 80 certificados y más de 60 cuentas del Programa de Compatibilidad de Hardware de Windows, y firmó más de 620 controladores de kernel de Windows maliciosos entre 2020 y el primer trimestre de 2025, a menudo utilizando certificados robados o certificados obtenidos a través de empresas fantasma de reciente creación. Los controladores de kernel se ejecutan en el nivel más privilegiado del sistema operativo, por lo que una firma válida en un controlador malicioso es extremadamente poderosa. Una validez más corta no impide la emisión fraudulenta por sí sola, pero combinada con el almacenamiento de claves de hardware y la revocación rápida, reduce la vida útil de cada credencial utilizada indebidamente.

¿Quiénes se ven afectados y en qué medida?

Cualquier organización que firme software con un certificado de confianza pública está sujeta al límite de 460 días. La magnitud del cambio operativo depende principalmente de cómo se almacenan las claves de firma y cómo se gestiona la renovación.

Mayor impacto: flujos de trabajo con tokens de hardware físico

Desde el 1 de junio de 2023, el Foro CA/B exige que las claves privadas de firma de código se generen y se almacenen en hardware. FIPS 140-2 Nivel 2 o Criterios Comunes EAL 4+, normalmente un token USB o un HSM. Los equipos que dependen de tokens USB físicos enviados por la CA son los que más notan este cambio, ya que cada renovación implica el aprovisionamiento y el envío de un nuevo token. Con una periodicidad de quince meses en lugar de tres años, este trabajo logístico se realiza con mucha más frecuencia.

Menor impacto: firma basada en la nube y HSM

Organizaciones que firman a través de un servicio de firma en la nube o una red HSMEn los sistemas donde las claves se aprovisionan y rotan mediante una API, se absorbe el cambio con mínima fricción. Para ellos, la renovación es principalmente un proceso de software que puede automatizarse de principio a fin. Esta asimetría es intencional, ya que la política general favorece la firma automatizada y gestionada centralmente frente a la gestión manual de tokens.

Impacto operativo

Frecuencia de renovación

Ampliar el plazo de 39 meses a 460 días implica que los certificados deben reemplazarse al menos cada quince meses. En un periodo fijo, esto supone más del doble de renovaciones. Para un editor que utiliza varios certificados de firma en diferentes productos y sistemas de compilación, cada renovación debe programarse y ejecutarse sin interrumpir los procesos de lanzamiento.

Requisito de automatización

El seguimiento manual mediante hojas de cálculo y recordatorios de calendario resulta poco práctico a medida que las renovaciones se vuelven más frecuentes. Una renovación omitida puede bloquear un lanzamiento o enviar archivos binarios que activen las advertencias de SmartScreen. Gestión del ciclo de vida de los certificados Las herramientas que detectan los certificados de firma, supervisan su caducidad y gestionan su renovación mediante las API de las autoridades de certificación constituyen el control práctico. Esta misma presión por la automatización impulsa la reducción paralela de la duración de los certificados TLS a 47 días para 2029, según la propuesta SC-081v3 del Foro de Autoridades de Certificación/Navegadores.

Continuidad mediante marcas de tiempo

Dado que las firmas con marca de tiempo conservan su validez incluso después de que expire el certificado de firma, cada operación de firma debe incluir una marca de tiempo de una Autoridad de Marcas de Tiempo confiable. Esto permite separar la longevidad del software publicado de la vida útil más corta del certificado y evita que el cambio de validez afecte al código que ya está en funcionamiento.

Cumplimiento ahora que el requisito está en vigor.

Con el límite de 460 días ya en vigor, todos los certificados nuevos y renovados deben cumplir con la normativa. Los siguientes pasos permiten que una organización cumpla con la normativa y transite de una gestión manual y reactiva a un ciclo de vida controlado.

1. Realizar un inventario de todos los certificados de firma de código en todos los equipos, servidores de compilación y productos, registrando el propietario y dónde se almacena cada clave privada.
2. Clasifique el almacenamiento de claves por tipo, separando los flujos de trabajo de tokens USB físicos de las claves basadas en la nube o en HSM, y priorice las basadas en tokens para su modernización.
3. Adopte la automatización de la gestión del ciclo de vida de los certificados para supervisar su caducidad, alertar a los propietarios antes de las fechas límite y renovarlos a través de las API de las autoridades de certificación, cuando estén disponibles.
4. Aplique el sellado de tiempo a cada operación de firma para que el software publicado siga siendo válido después de que expire el certificado.
5. Refuerce la seguridad del entorno de firma según las directrices del NIST: claves almacenadas en el HSM, separación de la firma de desarrollo y producción, aprobación por múltiples partes y sistemas de firma aislados.
6. Lleve a cabo un ciclo de renovación completo con el nuevo calendario para que cada renovación bajo la regla de los 460 días sea rutinaria en lugar de causar interrupciones.
7. Mantenga la capacidad de revocación, con un proceso definido para revocar y volver a firmar rápidamente si se sospecha que una clave ha sido comprometida, ya que la mera expiración no es protección suficiente.

Cumpliendo con el nuevo requisito gracias a CodeSign Secure de Encryption Consulting

Un período de validez más corto convierte la firma de código en un problema recurrente del ciclo de vida, en lugar de una tarea que se realiza una vez cada pocos años, que es precisamente donde una plataforma de firma centralizada demuestra su valía. CodeSign seguro Es una plataforma de firma de código centralizada, segura y escalable, diseñada para ayudar a las organizaciones a firmar código con confianza sin sacrificar la seguridad ni la velocidad. Está diseñada para entornos DevOps modernos, integrándose con pipelines de CI/CD como Azure DevOps, Jenkins y GitLab, a la vez que aplica estrictos controles de acceso y flujos de trabajo de aprobación que mantienen el proceso de firma limpio y conforme a las normativas, incluso con renovaciones más frecuentes.

Capacidades alineadas con el cambio de validez

Varias funcionalidades de CodeSign Secure se corresponden directamente con los controles que el nuevo límite de 460 días impulsa a las organizaciones a adoptar:

• Seguridad de claves respaldada por HSM. Las claves privadas se almacenan en módulos de seguridad de hardware (HSM) con certificación FIPS 140-2 de nivel 3, superando el requisito de almacenamiento de hardware del CA/Browser Forum, con soporte para Entrust nCipher, Thales Luna, Utimaco y Securosys en HSM locales y en la nube.
• Control de acceso basado en políticas. La integración con Active Directory y Keycloak, el control de acceso granular basado en roles y los flujos de trabajo de aprobación en varios pasos garantizan la separación de funciones, de modo que ningún artefacto se firma a menos que cumpla con el tipo de certificado, la etapa de firma y las aprobaciones requeridas. Esto implementa directamente la aprobación entre múltiples partes y el aislamiento de claves que NIST recomienda para la firma de código.
• Integración CI/CD perfecta. Las comprobaciones de seguridad y la validación de la integridad de las versiones impiden que los artefactos sin firmar lleguen a producción, gracias al seguimiento centralizado y las alertas instantáneas sobre intentos de firma no autorizados, lo que garantiza que los flujos de trabajo de alta velocidad cumplan con las normativas a través de ciclos de renovación más frecuentes.
• Amplia compatibilidad con diversos formatos y plataformas. La firma digital abarca archivos .exe, .dll, .jar, .apk, .dmg, contenedores Docker y binarios de firmware en Windows, Linux y macOS, y se integra con un envoltorio PKCS11 personalizado y herramientas como Signtool, Jarsigner y JSign.
• Hashing del lado del cliente y sellado de tiempo seguro. Los hashes se generan en el cliente mediante un proveedor de almacenamiento de claves personalizado para el marco CNG de Microsoft, y las marcas de tiempo seguras preservan la validez de la firma después de la expiración del certificado, lo cual es esencial en períodos de validez más cortos.
• Pistas de auditoría completas. Los registros detallados de eventos documentan cada aprobación, denegación y firma para el cumplimiento normativo y la investigación de incidentes, con integración SIEM para Grafana, Loki y Splunk a través de OpenTelemetry.
• Modelos de despliegue flexibles. Las organizaciones pueden ejecutar un servicio totalmente gestionado alojado en la nube con seguridad HSM integrada y acceso completo a la API, o bien implementarlo en sus propias instalaciones gestionando las claves en HSM en la nube, HSM locales o ambos.
• Compatibilidad con criptografía postcuántica. CodeSign Secure admite los esquemas de firma resistentes a la computación cuántica ML-DSA y LMS reconocidos por NIST directamente en el HSM, junto con la firma dual que combina un RSA clásico o ECDSA firma con una firma post-cuántica para una transición gradual.

Tanto si gestionas docenas de identidades de firma en equipos distribuidos, como si ejecutas pipelines de CI/CD de alta velocidad u operas bajo estrictos mandatos de cumplimiento en sectores como el automotriz, el sanitario o el de tecnología financiera, CodeSign Secure absorbe la sobrecarga adicional de renovación que introduce el límite de 460 días y convierte la firma de código en un ciclo de vida automatizado y controlado.

Conclusión

Reducir la validez de los certificados de firma de código a 460 días impone un período criptográfico más corto para las claves de firma, reduce el tiempo durante el cual se puede abusar de un certificado comprometido y alinea la firma de código con el modelo automatizado que ya está transformando TLS. Incidentes recientes relacionados con AnyDesk, Hijack Loader, Microsoft Trusted Signing y el abuso a gran escala de controladores firmados apuntan a la misma conclusión: las credenciales de firma de larga duración y poco controladas representan un riesgo, y limitar su vigencia es una medida de mitigación sensata.

Para las organizaciones que aún gestionan los certificados manualmente y dependen de tokens físicos, la principal consecuencia es una mayor frecuencia de renovación. Para aquellas que consideran la firma de código como un ciclo de vida automatizado con detección, monitorización, sellado de tiempo y claves respaldadas por hardware, el cambio supone un ajuste menor. Ahora que ha pasado la fecha de entrada en vigor del 1 de marzo de 2026, completar esta transición ya no es opcional, sino un requisito operativo.