Microsoft ha empezado a activar de forma más visible la transición de certificados de Secure Boot en Windows, un cambio técnico que muchos usuarios verán como una simple actualización, pero que afecta a una de las capas más sensibles del sistema operativo: todo lo que ocurre antes de que Windows arranque.
La compañía ya había avisado de que varios certificados de Secure Boot emitidos en 2011 caducan durante 2026. Ahora esa renovación ha pasado de ser una advertencia para fabricantes y administradores a aparecer en Windows Update y en la app Seguridad de Windows. En la mayoría de equipos modernos, el proceso será automático. Pero no es una actualización menor: mantiene viva la cadena de confianza que permite validar cargadores de arranque, bases de firmas, listas de revocación y mitigaciones frente a malware que intenta ejecutarse antes del sistema operativo.
Secure Boot no es una tecnología exclusiva de Windows, aunque Microsoft tiene un papel central en el ecosistema PC. Es una función de UEFI que comprueba firmas digitales durante el arranque para evitar que se ejecute código no confiable antes del sistema operativo. Windows lo incorporó con Windows 8 para reforzar la protección frente a bootkits y rootkits, amenazas que buscan cargar antes que el propio sistema y esconderse de las defensas tradicionales.
Del BIOS clásico al arranque verificado
Para entender por qué este cambio importa, conviene mirar atrás. Durante décadas, el PC arrancaba con BIOS tradicional. El firmware inicializaba hardware, buscaba un dispositivo de arranque y entregaba el control al cargador del sistema operativo. Ese modelo era sencillo, pero ofrecía poca protección criptográfica frente a manipulaciones tempranas.
UEFI cambió ese escenario. Además de modernizar el firmware, introdujo Secure Boot como mecanismo para que cada pieza cargada antes del sistema operativo pudiera validarse mediante firmas. El firmware comprueba bootloaders, aplicaciones EFI y Option ROMs antes de ceder el control. Si las firmas encajan con la base de confianza almacenada en el propio firmware, el proceso continúa. Si no, el arranque puede bloquearse.
Windows añade después sus propias capas. Secure Boot crea la ruta de confianza desde UEFI hasta el cargador de Windows, y Trusted Boot continúa esa protección dentro de Windows, verificando componentes del arranque del sistema y ayudando a que antimalware y otras defensas arranquen en un estado fiable.
La transición actual afecta a esa primera parte de la cadena. Microsoft está renovando certificados que se almacenan en bases como KEK y DB. KEK permite firmar actualizaciones de las bases Secure Boot y DB contiene certificados que autorizan código durante el arranque. También existe DBX, la base de firmas revocadas, que permite bloquear cargadores o componentes vulnerables.
| Certificado antiguo | Caducidad | Certificado nuevo | Uso |
|---|---|---|---|
| Microsoft Corporation KEK CA 2011 | 24/06/2026 | Microsoft Corporation KEK 2K CA 2023 | Firmar actualizaciones de DB y DBX |
| Microsoft UEFI CA 2011 | 27/06/2026 | Microsoft UEFI CA 2023 | Firmar cargadores de terceros y apps EFI |
| Microsoft UEFI CA 2011 | 27/06/2026 | Microsoft Option ROM UEFI CA 2023 | Firmar Option ROMs |
| Microsoft Windows Production PCA 2011 | 19/10/2026 | Windows UEFI CA 2023 | Firmar el cargador de Windows |
Microsoft explica que los equipos que no reciban los nuevos certificados seguirán arrancando y recibiendo actualizaciones normales de Windows. El problema es que, con el tiempo, dejarán de recibir nuevas protecciones para el arranque temprano, incluidas actualizaciones de Windows Boot Manager, bases de Secure Boot, revocaciones o mitigaciones ante vulnerabilidades de bajo nivel.
Qué cambia para el usuario de Windows
Para el usuario doméstico, la recomendación es poco espectacular: mantener Windows Update activo, instalar las actualizaciones pendientes y reiniciar cuando toque. Microsoft está entregando los certificados de 2023 de forma automática a dispositivos de consumo y a parte de equipos empresariales gestionados por sus propios canales. La app Seguridad de Windows muestra desde abril de 2026 más información sobre el estado de estas actualizaciones en Seguridad del dispositivo > Arranque seguro.
Si aparece un check verde y el mensaje indica que Secure Boot está activado y que las actualizaciones de certificado están aplicadas, no hay que hacer nada más. Si aparece una insignia amarilla, puede indicar que el equipo todavía usa certificados antiguos, que necesita más datos para clasificarse, que el despliegue está pausado por compatibilidad o que hace falta una actualización adicional. Si aparece un aviso rojo, la situación merece más atención: Microsoft lo asocia a casos donde existe una actualización de seguridad para la experiencia de arranque que no puede entregarse con la configuración actual del dispositivo.
La parte más importante para muchos usuarios es no tocar la BIOS o UEFI sin necesidad. Restablecer claves, cambiar el modo de arranque, activar o desactivar CSM, modificar TPM o tocar Secure Boot manualmente puede generar problemas si el equipo tiene una instalación antigua, arranque dual o BitLocker activo.
Antes de aplicar una actualización de firmware o cambiar valores de arranque conviene tener localizada la clave de recuperación de BitLocker. No porque esta transición vaya a romper equipos de forma general, sino porque algunos cambios de firmware, TPM o arranque pueden hacer que Windows solicite esa clave al iniciar. En un PC personal suele estar asociada a la cuenta Microsoft; en empresas, puede estar gestionada por Intune, Active Directory, Entra ID u otras herramientas.
Empresas: no es un parche más, es una rotación de confianza
En entornos corporativos, el cambio debe tratarse como una operación de plataforma. Microsoft ofrece guías específicas para profesionales de TI y organizaciones, además de claves de registro para gestionar el despliegue en dispositivos con actualizaciones controladas por el departamento de sistemas. En despliegues empresariales, Microsoft menciona el uso de un bitmask de registro para habilitar acciones como añadir los certificados de 2023, actualizar KEK e instalar el nuevo boot manager.
La diferencia respecto a un parche mensual es que aquí intervienen variables persistentes del firmware. Un equipo puede tener Windows actualizado, pero seguir dependiendo de firmware OEM para determinados valores por defecto o escenarios de reinicialización de Secure Boot. Por eso las organizaciones deben probar por fabricante, modelo, versión de firmware y configuración de arranque antes de extender el cambio a toda la flota.
También hay que mirar máquinas virtuales. En entornos virtualizados, Secure Boot depende del firmware virtual que proporciona el hipervisor, y la actualización puede venir por el proveedor de virtualización, por la imagen base o por el propio Windows si la VM permite actualizar variables activas. Para administradores de sistemas, esta transición obligará a revisar plantillas, imágenes golden, políticas de BitLocker, arranque dual, Linux corporativo y dispositivos fuera de soporte.
Linux: el papel incómodo de shim y las claves de Microsoft
La comparación con Linux es necesaria porque muchos equipos x86 con Linux también dependen, de forma indirecta, de la infraestructura de confianza de Microsoft. En distribuciones como Ubuntu, el firmware valida primero shim, un pre-bootloader firmado por Microsoft. Después shim contiene una base de confianza propia, con certificados de Canonical, para validar GRUB y el kernel firmados por la distribución.
Red Hat sigue un esquema parecido: shim contiene la clave pública de Red Hat para autenticar GRUB y el kernel, y el kernel incluye claves para autenticar drivers y módulos. Además, en determinados escenarios se puede usar Machine Owner Key, o MOK, para añadir claves propias, por ejemplo al trabajar con módulos o versiones no firmadas por el fabricante de la distribución.
Esto demuestra una diferencia importante entre Windows y Linux en PCs estándar. Windows controla de forma más directa su cadena de arranque dentro del ecosistema Microsoft-OEM. Linux, para mantener compatibilidad con el parque de PC que viene preparado para Windows, ha tenido que apoyarse muchas veces en shim firmado por Microsoft. Esa dependencia ha funcionado razonablemente bien, pero hace que la caducidad y rotación de certificados también sea relevante para usuarios de arranque dual, administradores de servidores x86 y distribuciones que quieran mantener Secure Boot activo.
En Linux avanzado existe más libertad para gestionar claves propias, pero también más complejidad. Un usuario puede desactivar Secure Boot, usar MOK, firmar módulos o controlar su propia cadena. Eso ofrece flexibilidad, aunque aumenta la carga operativa frente al modelo más guiado de Windows.
macOS, Android y ChromeOS: cadenas más cerradas
Apple sigue una filosofía distinta. En los Mac con Apple silicon, el arranque seguro parte de una cadena de confianza controlada por Apple desde Boot ROM y verifica no solo el código del sistema operativo, sino también políticas de seguridad y extensiones configuradas por usuarios autorizados. En los Mac Intel con chip T2, el chip realiza un arranque seguro desde Boot ROM, verifica iBoot y continúa la cadena antes de pasar por UEFI.
La ventaja de Apple es el control vertical. Hardware, firmware, sistema operativo y políticas están mucho más integrados. La desventaja es que hay menos margen para modelos abiertos o configuraciones heterogéneas como las del PC. Para usuarios y empresas, eso significa menos piezas que coordinar, pero también menos flexibilidad.
Android también usa una filosofía de arranque verificado, aunque adaptada al móvil. Android Verified Boot establece una cadena de confianza desde una raíz protegida por hardware hasta el bootloader, la partición de arranque y otras particiones verificadas como system o vendor. Además, incorpora protección frente a rollback para impedir que un atacante instale una versión antigua vulnerable del sistema.
ChromeOS va en la misma línea de control fuerte. Cada vez que un dispositivo arranca, realiza una comprobación llamada Verified Boot; si detecta código desconocido, el sistema puede repararse volviendo a una versión anterior. El sistema operativo de Google combina esta idea con un modelo de sistema de solo lectura y recuperación más integrada.
| Sistema | Enfoque de arranque seguro | Ventaja | Coste |
|---|---|---|---|
| Windows en PC UEFI | Secure Boot con certificados Microsoft/OEM y actualización por Windows Update | Compatibilidad amplia y despliegue automático | Dependencia de firmware OEM y estado de claves |
| Linux en PC UEFI | shim firmado por Microsoft, claves de distribución y MOK | Flexibilidad y control del usuario | Más complejidad y dependencia parcial de claves Microsoft |
| macOS Apple silicon | Cadena integrada desde Boot ROM y políticas de Apple | Control vertical y menos fragmentación | Menos apertura para configuraciones no estándar |
| Android | Verified Boot con raíz hardware y rollback protection | Protección fuerte en dispositivos móviles | Depende del fabricante y del soporte del dispositivo |
| ChromeOS | Verified Boot con reparación automática | Recuperación sencilla y modelo cerrado | Menor libertad que un PC generalista |
La lección: el arranque ya no es un trámite
La renovación de Secure Boot en Windows no debería verse como un susto, pero tampoco como una actualización menor. Es una rotación de confianza en una capa que normalmente el usuario no ve y que solo llama la atención cuando algo falla. La seguridad moderna no empieza cuando aparece el escritorio; empieza cuando el firmware decide qué código puede ejecutarse.
La comparación con otros sistemas deja una idea clara. Windows intenta compatibilizar seguridad, parque instalado enorme y diversidad de fabricantes. Linux mantiene más libertad, pero paga el precio de gestionar shim, MOK y distintas políticas de firma. Apple, Android y ChromeOS protegen más mediante cadenas cerradas e integradas, a cambio de reducir el margen de intervención del usuario.
Para un usuario de Windows, la respuesta práctica sigue siendo simple: actualizar, reiniciar, comprobar Seguridad de Windows y no tocar UEFI sin motivo. Para administradores, la respuesta es más seria: inventario, pruebas por modelo, firmware al día, control de BitLocker, revisión de VMs y monitorización de estado.
Secure Boot no hace invulnerable a un sistema. Pero sin una cadena de arranque confiable, todo lo que viene después se construye sobre una base más débil. Por eso Microsoft está renovando certificados antes de que caduquen y por eso esta transición merece atención en cualquier medio de sistemas operativos.
Preguntas frecuentes
¿Qué está cambiando Microsoft en Secure Boot?
Está renovando certificados de 2011 que caducan en 2026 y sustituyéndolos por certificados de 2023 para mantener la cadena de confianza del arranque seguro.
¿Windows dejará de arrancar si no se actualiza Secure Boot?
No de forma inmediata. Microsoft indica que los equipos seguirán arrancando y recibiendo actualizaciones normales, pero perderán capacidad para recibir nuevas protecciones de arranque temprano.
¿Qué diferencia hay entre Secure Boot y Trusted Boot?
Secure Boot valida componentes antes de que arranque Windows, desde UEFI. Trusted Boot continúa la verificación dentro del proceso de arranque de Windows.
¿Por qué afecta también a Linux?
Muchas distribuciones Linux usan shim, un pre-bootloader firmado por Microsoft, para poder arrancar con Secure Boot activado en PCs diseñados originalmente para Windows.
¿macOS funciona igual que Windows?
No. En Apple silicon y en Mac con T2, Apple controla más partes de la cadena de arranque desde hardware y firmware propios, con una integración más cerrada que en el PC.
