Microsoft actualizó su guía sobre la expiración de certificados de Windows Secure Boot y las actualizaciones de CA. El punto clave no es que “el PC dejará de arrancar cuando expire el certificado”. El problema real es que un grupo de certificados Secure Boot emitidos en 2011 empezará a expirar a partir de junio de 2026, y los dispositivos Windows necesitan migrar a los nuevos certificados de 2023 para seguir recibiendo futuras actualizaciones de protección en la fase temprana de arranque.

Artículo original: Microsoft Support: Windows Secure Boot certificate expiration and CA updates.

De qué trata esta actualización

Secure Boot es una función de seguridad del firmware UEFI. Antes de que arranque el sistema operativo, verifica las firmas de cargadores de arranque, controladores UEFI, Option ROM y otros componentes, ayudando a bloquear bootkits, rootkits y otro malware de fase temprana.

Esta validación depende de varias bases de datos y claves almacenadas en el firmware:

• KEK: clave de inscripción, usada para autorizar actualizaciones de las bases de datos de Secure Boot.
• DB: base de datos de firmas permitidas, que decide qué componentes de arranque pueden ser confiables.
• DBX: base de datos de firmas revocadas, usada para bloquear componentes conocidos como no confiables o riesgosos.

Microsoft indica que un grupo de certificados de 2011 usado durante años por dispositivos Windows se acerca a su expiración, y que los certificados correspondientes ya existen en versiones de 2023. Esto incluye el certificado KEK usado para firmar actualizaciones de DB / DBX, la Windows UEFI CA usada para firmar el cargador de arranque de Windows, y la UEFI CA usada para cargadores de arranque de terceros, aplicaciones EFI y Option ROM.

¿Afectará al arranque?

La pregunta que más preocupa a la mayoría de usuarios es: después de que expiren los certificados en 2026, ¿el PC dejará de arrancar de repente?

La respuesta de Microsoft es bastante clara: los dispositivos que no hayan recibido los nuevos certificados de 2023 podrán seguir arrancando y funcionando normalmente, y las actualizaciones estándar de Windows seguirán instalándose. El problema es que esos dispositivos ya no podrán recibir nuevas protecciones relacionadas con la fase temprana de arranque, como actualizaciones de Windows Boot Manager, actualizaciones de la base de datos de Secure Boot, actualizaciones de listas de revocación y mitigaciones para vulnerabilidades de arranque descubiertas más adelante.

Así que se parece más a una cadena de protección de seguridad que envejece que a un problema simple de “el sistema queda obsoleto de inmediato”. A corto plazo, la máquina puede seguir funcionando. A largo plazo, bajará su capacidad de defensa frente a nuevos bootkits, vulnerabilidades de la cadena de arranque y componentes revocados.

Qué deben hacer los usuarios normales

Los usuarios normales no necesitan editar manualmente las claves de Secure Boot, y no deberían borrar, restablecer o importar certificados en BIOS / UEFI sin una instrucción clara.

El enfoque más seguro es:

1. Mantener Windows Update activado e instalar actualizaciones acumulativas.
2. Instalar actualizaciones de firmware, BIOS, UEFI y controladores proporcionadas por el fabricante del PC.
3. No mantener Secure Boot desactivado a largo plazo solo por problemas temporales de compatibilidad.
4. Si BitLocker está activado, confirmar que la clave de recuperación está disponible antes de cambios relacionados con firmware o Secure Boot.
5. Usar msinfo32 para revisar “Secure Boot State” y confirmar que Secure Boot está activado.

En PCs domésticos, el riesgo principal normalmente no es “no saber operar”, sino dejar el firmware sin actualizar durante demasiado tiempo. Muchos cambios relacionados con Secure Boot en portátiles y equipos de marca dependen al final del soporte de firmware del OEM.

Qué deben vigilar los administradores de empresa

En entornos empresariales, el problema no está en una sola máquina. Está en la mezcla de modelos de dispositivos, versiones de firmware, políticas de cifrado, herramientas de despliegue y componentes de arranque de terceros.

Conviene empezar por cuatro cosas:

1. Inventariar modelos de dispositivos, versiones de Windows, estado de Secure Boot, versiones de firmware y estado de BitLocker.
2. Probar primero en modelos representativos y ampliar el despliegue gradualmente.
3. Poner actualizaciones de Windows, firmware OEM, copia de claves de recuperación y flujos PXE / MDT / ConfigMgr / Intune dentro de un mismo plan de cambio.
4. Validar si los medios de recuperación, herramientas de imagen, software de seguridad de terceros y cargadores de arranque de doble sistema siguen arrancando normalmente.

La documentación de Microsoft también ofrece rutas para dispositivos gestionados por IT mediante registro, directivas de grupo, WinCS API, Intune y ejemplos de monitorización. Para empresas, esta actualización de certificados no debería tratarse como un parche común. Debe probarse, desplegarse por fases y acompañarse de un plan de reversión como cambio de nivel firmware.

Doble arranque y herramientas de arranque de terceros requieren más cuidado

Si un dispositivo usa doble arranque con Linux, un cargador de arranque de terceros, aplicaciones EFI con firma personalizada, medios de recuperación antiguos o herramientas de despliegue offline, esta actualización merece validación anticipada.

La razón es que Microsoft ha separado con más detalle partes del modelo de confianza original. Por ejemplo, la confianza para cargadores de arranque de terceros y Option ROM ya no está completamente agrupada. Esto ayuda a reducir el alcance de confianza, pero también significa que componentes de arranque antiguos, versiones sin actualizar de shim / GRUB, medios de recuperación viejos o herramientas de arranque personalizadas podrían encontrar más problemas de confianza de firma en el futuro.

La regla es simple: no esperes a que expiren los certificados para descubrir que tu USB de recuperación tampoco arranca. Las máquinas importantes deberían probar al menos una vez el flujo real de recuperación antes de tiempo.

Qué no conviene hacer

Este tipo de problema parece una “expiración de certificado”, así que es tentador entrar en BIOS y cambiar claves manualmente. Salvo que el fabricante o la documentación de Microsoft lo pidan claramente, no es recomendable.

No dejes Secure Boot desactivado a largo plazo. No borres directamente Secure Boot keys en dispositivos de producción. No copies la configuración de firmware de un dispositivo a otro lote de modelos distintos. Y no actualices solo Windows, ignores el firmware OEM y asumas que todo está resuelto.

Una forma más razonable de verlo es: las actualizaciones de Windows resuelven el lado del sistema operativo, las actualizaciones de firmware OEM resuelven el lado de la plataforma, y la política de despliegue empresarial resuelve la consistencia a escala. Si falta una de las tres, después puede convertirse en un problema de arranque difícil de diagnosticar.

Resumen

El impacto real de la expiración de certificados de Windows Secure Boot no es que todos los PCs dejen de arrancar el mismo día de 2026. El problema real es que los dispositivos con certificados antiguos perderán gradualmente la capacidad de recibir futuras actualizaciones de seguridad de Secure Boot.

Los usuarios individuales deben mantener Windows y firmware actualizados, y evitar desactivar Secure Boot sin necesidad. Los administradores de empresa deberían empezar cuanto antes con inventario, pruebas y despliegue por fases. Cuanto más cerca esté junio de 2026, menos tiempo quedará para compatibilidad de firmware, validación de recuperación y planes de reversión masiva.