A partir del 24 de junio de 2026, han comenzado a expirar los certificados originales de Secure Boot de Microsoft. El Microsoft Corporation KEK CA 2011 venció primero, seguido por el Microsoft UEFI CA 2011 el 27 de junio, y el Microsoft Windows Production PCA 2011 expirará el 19 de octubre de 2026. Esta situación afecta a miles de millones de ordenadores, incluyendo aquellos que utilizan distribuciones de Linux.

El tiempo se ha agotado. A partir del 24 de junio de 2026, el primero de los certificados originales de Secure Boot de Microsoft, el Microsoft Corporation KEK CA 2011, ha caducado oficialmente, seguido por el Microsoft UEFI CA 2011 el 27 de junio de 2026.

Un tercero, el Microsoft Windows Production PCA 2011, caducará el 19 de octubre de 2026. Juntos, estos certificados han sustentado la confianza del arranque a nivel de firmware en cada PC compatible con UEFI desplegado desde la era de Windows 8, más de mil millones de dispositivos en todo el mundo, incluidos los sistemas que ejecutan distribuciones de Linux.

Esto no es un martes de parches rutinario. Es un cambio estructural y permanente en la cadena de confianza criptográfica que se ejecuta cada vez que enciendes un dispositivo.

Identificar los riesgos potenciales es el primer paso. Aquí tienes lo que los equipos de TI pueden hacer para asegurar la preparación antes de la fecha límite. Para entender por qué esto es importante, necesitas comprender la jerarquía de claves por capas de Secure Boot almacenada en el firmware UEFI:

• La Clave de Plataforma (PK) está en la cima, autorizando la Clave de Inscripción de Claves (KEK).
• La KEK firma las actualizaciones de dos bases de datos críticas: la Base de Datos de Firmas Permitidas (DB), que enumera las firmas de arranque confiables, y la Base de Datos de Firmas Prohibidas (DBX), que bloquea las que se sabe que son maliciosas.
• Al arrancar, el firmware verifica la firma criptográfica del cargador de arranque contra la DB. Si coincide y no ha sido revocada en la DBX, el sistema procede.

Cuatro certificados que anclan toda esta jerarquía están ahora al final de su vida útil o se acercan a ella:

Certificado que caduca	Fecha de caducidad	Reemplazo	Ubicación	Propósito
Microsoft Corporation KEK CA 2011	24 de junio de 2026	Microsoft Corporation KEK 2K CA 2023	KEK	Firma actualizaciones de DB y DBX
Microsoft Corporation UEFI CA 2011	27 de junio de 2026	Microsoft UEFI CA 2023	DB	Firma componentes de controladores de hardware y SO de terceros
Microsoft Corporation UEFI CA 2011	27 de junio de 2026	Microsoft Option ROM UEFI CA 2023	DB	Firma ROMs de opciones de terceros
Microsoft Windows Production PCA 2011	19 de octubre de 2026	Windows UEFI CA 2023	DB	Firma el cargador de arranque de Windows

Los certificados de reemplazo de 2023 son válidos hasta 2038, ofreciendo aproximadamente 15 años de cobertura continua.

El alcance es enorme. Cada computadora fabricada con una placa base basada en UEFI que abarque Windows 10, Windows 11, Windows Server 2012 hasta 2025, y cualquier hardware lanzado aproximadamente desde 2012, está potencialmente afectado.

La población de dispositivos impactados es de más de mil millones de PCs. Los dispositivos enviados en 2025 o posterior, incluidos los PCs Copilot+, normalmente llegan con los certificados de 2023 preinstalados y no requieren ninguna acción.

Las distribuciones de Linux están igualmente expuestas. Casi todas las distros de Linux principales, Ubuntu, Fedora, Debian, RHEL y otras, utilizan el UEFI CA 2011 de Microsoft para firmar el cargador de arranque de primera etapa shim que permite que esos sistemas arranquen con Secure Boot habilitado.

El Proyecto Fedora confirmó que una vez que la clave de 2011 caduque, cualquier nuevo binario de shim solo se firmará con la clave de 2023. Esto significa que los medios de instalación de Linux que dependan de un nuevo shim firmado con la clave de 2023 no podrán arrancar en máquinas cuyo firmware solo contenga los certificados antiguos de 2011, lo que impacta directamente en las instalaciones sobre metal (bare-metal), despliegues de servidores y plantillas de VM en entornos empresariales.

Los dispositivos que no logren migrar continuarán arrancando y ejecutando el software existente normalmente. Lo que perderán permanentemente, sin embargo, es mucho más grave:

• Sin futuras actualizaciones de la lista de revocación DBX: los nuevos bootkits y variantes maliciosas del cargador de arranque nunca serán puestos en la lista negra a nivel de firmware.
• Sin actualizaciones de seguridad del Administrador de Arranque de Windows: el cargador de arranque queda congelado en su última versión firmada en 2011.
• Sin nuevas actualizaciones de la DB de Secure Boot: los componentes de hardware de terceros y los controladores de SO firmados con nuevos certificados no serán confiables.
• Posible bloqueo de futuras actualizaciones de características de Windows, ya que las compilaciones más recientes pueden requerir una versión del Administrador de Arranque que necesite la cadena de certificados de 2023.

En la práctica, estos dispositivos acumulan una deuda de seguridad compuesta sin una vía de remediación limpia de regreso. Los actores de amenazas que explotan malware de clase bootkit operan precisamente en este nivel de firmware que el mecanismo de revocación DBX de Secure Boot está diseñado para bloquear.

La guía oficial de Microsoft y los avisos de los OEM dejan claro que la remediación requiere dos acciones secuenciales:

1. Primero, la actualización del Firmware OEM (BIOS/UEFI): los dispositivos fabricados antes de 2024 necesitan una actualización de firmware proporcionada por el proveedor para permitir que su UEFI acepte los certificados de 2023. Usa Dell Command | Update, Lenovo System Update o HP Image Assistant, según el proveedor del hardware.
2. Segundo, la actualización del Certificado de Windows: entregada a través de las actualizaciones acumulativas mensuales de Microsoft. Requiere Windows 10 22H2+ con inscripción en ESU, o cualquier compilación soportada de Windows 11. Una tarea programada se ejecuta aproximadamente cada 12 horas para preparar la actualización, y el reemplazo del Administrador de Arranque se pospone hasta el siguiente reinicio.

Para entornos empresariales, el Catálogo de Configuración de Microsoft Intune y Windows Autopatch incluyen una política dedicada de Actualización de Certificados de Secure Boot y un informe integrado del Estado de Secure Boot.

Los administradores de Directivas de Grupo deben habilitar "Habilitar despliegue de certificados de Secure Boot" en Configuración del equipo > Plantillas administrativas > Componentes de Windows > Secure Boot después de desplegar las plantillas ADMX más recientes de Windows 11.

Para los sistemas Linux, los administradores deben actualizar tanto el paquete shim (vía apt full-upgrade, dnf upgrade o equivalente) como aplicar la actualización de firmware del OEM que inscriba el certificado Microsoft UEFI CA 2023 en la DB del firmware. Se requiere la versión 2.0.10 o posterior de fwupd para que la entrega del Servicio de Firmware de Proveedores de Linux (LVFS) funcione correctamente.

En Windows, navega a Seguridad de Windows > Seguridad del dispositivo > Secure Boot; una insignia verde que confirme que "todos los certificados se han aplicado" es el indicador requerido, no simplemente una marca de verificación verde. Alternativamente, revisa la clave del registro HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\UEFICA2023Status para encontrar un valor "updated".

En Linux, ejecuta sudo mokutil --sb-state para confirmar el estado de Secure Boot y sudo mokutil --db para inspeccionar los certificados inscritos. Si la salida muestra solo el certificado Microsoft Corporation UEFI CA 2011, tu firmware necesita una actualización inmediata.

La caducidad del Windows Production PCA 2011 el 19 de octubre de 2026 proporciona una segunda fecha límite, pero las organizaciones que dependen de los certificados KEK y UEFI CA ya han pasado su ventana de oportunidad a día de hoy. Para obtener una guía autorizada, está disponible el portal dedicado de Microsoft.

El artículo (archivo .md) está listo para descargar arriba. Cubre el desglose completo de la cadena de confianza, las fechas exactas de caducidad de los cuatro certificados, el impacto en el shim de Linux, las consecuencias de la no remediación (congelación de DBX, exposición a bootkits, bloqueo de actualizaciones de características) y un manual de remediación de dos pasos para empresas/Linux, todo proveniente del blog oficial de Microsoft.

Fuentes:
https://cybersecuritynews.com/windows-secure-boot-certificate-expired/