← Volver al blog

Secure Boot 2026: cómo actualizar los certificados de Microsoft

Los certificados de Secure Boot de 2011 caducan en 2026. Qué significa, cómo comprobar si tus equipos y máquinas virtuales están actualizados y cómo hacerlo.

Transición de los certificados de Secure Boot de 2011 a los de 2023, con la fecha de caducidad del certificado que firma el gestor de arranque de Windows

Secure Boot es la función del firmware UEFI que garantiza que, al encender un equipo, solo se carga software de arranque firmado y de confianza. Esa confianza se basa en certificados de Microsoft almacenados en el propio firmware, y los que usa la mayoría de equipos desde hace más de una década, emitidos en 2011, caducan a lo largo de 2026.

Microsoft los está sustituyendo por nuevos certificados de 2023. La mayoría de equipos con Windows recibirán el cambio de forma automática, pero en entornos corporativos conviene comprobarlo: hay equipos con firmware antiguo, servidores con actualizaciones controladas y máquinas virtuales que no se actualizan solas.

Qué certificados caducan

Según la información publicada por Microsoft:

Certificado que caduca Fecha Sustituto Para qué sirve
Microsoft Corporation KEK CA 2011 24 de junio de 2026 Microsoft Corporation KEK 2K CA 2023 Firma las actualizaciones de las bases de datos de Secure Boot (DB y DBX)
Microsoft UEFI CA 2011 27 de junio de 2026 Microsoft UEFI CA 2023 y Microsoft Option ROM UEFI CA 2023 Firma cargadores de arranque de terceros (por ejemplo, Linux) y firmware de tarjetas de expansión
Microsoft Windows Production PCA 2011 19 de octubre de 2026 Windows UEFI CA 2023 Firma el gestor de arranque de Windows

Qué pasa si un equipo no se actualiza

Es importante no caer en el alarmismo: un equipo que no se actualice seguirá arrancando y funcionando con normalidad, y seguirá recibiendo las actualizaciones habituales de Windows.

Lo que pierde es la capacidad de recibir nuevas protecciones para el arranque: actualizaciones del gestor de arranque de Windows, de las bases de datos de Secure Boot y de las listas de revocación que bloquean componentes vulnerables. Con el tiempo, el equipo queda más expuesto a amenazas que actúan antes de que arranque el sistema operativo, como los bootkits, y pueden aparecer problemas con funciones que dependen de esa cadena de confianza.

Dicho de otra forma: no es un apagón, es una degradación progresiva de la seguridad del arranque.

Cómo comprobar el estado de un equipo Windows

Desde PowerShell como administrador:

# ¿Está activo Secure Boot?
Confirm-SecureBootUEFI

# ¿Contiene la base de datos DB el nuevo certificado de Windows?
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI -Name db).Bytes) -match 'Windows UEFI CA 2023'

# ¿Contiene el KEK el nuevo certificado?
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI -Name KEK).Bytes) -match 'KEK 2K CA 2023'

# Estado del proceso de actualización
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing' -Name UEFICA2023Status -ErrorAction SilentlyContinue

Si las dos comprobaciones de certificados devuelven True y el estado es Updated, el equipo ya está actualizado.

También puedes revisar el Visor de eventos, en el registro Sistema con origen TPM-WMI:

  • Evento 1808: la actualización se completó. El equipo tiene los nuevos certificados en el firmware y el gestor de arranque firmado con el certificado de 2023.
  • Evento 1801: los certificados se prepararon, pero aún no se aplicaron al firmware.
  • Evento 1795: el firmware devolvió un error. Suele resolverse actualizando el BIOS/UEFI del fabricante.
  • Evento 1032: la actualización se bloqueó porque provocaría la recuperación de BitLocker.

Cómo forzar la actualización en equipos gestionados

En organizaciones que controlan las actualizaciones, la actualización puede lanzarse de forma explícita. El método documentado consiste en indicar a Windows, mediante una clave del registro, que despliegue los certificados y el nuevo gestor de arranque, y ejecutar después la tarea programada que lo procesa:

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot' -Name 'AvailableUpdates' -Value 0x5944 -Type DWord
Start-ScheduledTask -TaskPath '\Microsoft\Windows\PI\' -TaskName 'Secure-Boot-Update'

El proceso necesita al menos dos reinicios para completarse. Microsoft también ofrece este despliegue mediante directivas de grupo e Intune, más adecuado para hacerlo a escala.

Recomendaciones antes de desplegarlo en toda la organización:

  • Actualiza primero el firmware (BIOS/UEFI) con la última versión del fabricante. Muchos errores se deben a firmware antiguo.
  • Ten a mano las claves de recuperación de BitLocker. Los cambios en la cadena de arranque pueden provocar que BitLocker pida la clave de recuperación. Para minimizar el riesgo, se pueden suspender los protectores durante los reinicios necesarios.
  • Hazlo por fases: un grupo piloto con distintos modelos de hardware, revisión de los eventos y, después, el despliegue general.

Máquinas virtuales

Las máquinas virtuales con Secure Boot también tienen certificados en su firmware virtual, y no siempre se actualizan solas.

Proxmox VE

Las versiones recientes de Proxmox muestran un aviso cuando el disco EFI de una VM no incluye los certificados de 2023:

EFI disk without 'ms-cert=2023k' option

Para corregirlo, con la VM apagada:

qm enroll-efi-keys <VMID>

También puede hacerse desde la interfaz: VM → Hardware → EFI Disk → Disk Action → Enroll Updated Certificates.

Si la VM tiene Windows con BitLocker, antes de hacerlo suspende los protectores dentro de la VM, para evitar que pida la clave de recuperación en el siguiente arranque:

manage-bde -protectors -disable C:

Después, arranca la VM, comprueba que funciona correctamente y vuelve a activarlos con manage-bde -protectors -enable C:.

Otras plataformas

En Hyper-V, VMware, Azure y otras plataformas, el procedimiento depende del fabricante y de la versión: a veces basta con actualizar el sistema invitado y otras hace falta actualizar el host o la plantilla de la VM. Consulta la guía de tu plataforma antes de actuar.

Linux y otros sistemas

Las distribuciones de Linux con Secure Boot arrancan mediante un cargador (shim) firmado con el certificado Microsoft UEFI CA 2011. Las distribuciones están publicando versiones firmadas con el nuevo certificado de 2023. Mantén actualizados tanto la distribución como el firmware del equipo, y revisa también los servidores físicos que ejecutan hipervisores con Secure Boot activado.

Plan de acción recomendado

  1. Inventario: identifica qué equipos, servidores y máquinas virtuales tienen Secure Boot activado.
  2. Diagnóstico: comprueba el estado con PowerShell o con tu herramienta de gestión.
  3. Firmware: actualiza el BIOS/UEFI de los modelos que lo necesiten.
  4. BitLocker: asegúrate de tener las claves de recuperación de todos los equipos.
  5. Piloto: actualiza un grupo reducido y revisa los eventos.
  6. Despliegue: extiende la actualización por fases.
  7. Máquinas virtuales: actualiza el firmware virtual de cada VM según la plataforma.
  8. Seguimiento: revisa que los equipos registran el evento 1808 o el estado Updated.

Preguntas frecuentes

¿Mi equipo dejará de arrancar cuando caduquen los certificados? No. Seguirá arrancando con normalidad. Lo que deja de recibir son nuevas actualizaciones de seguridad del proceso de arranque.

¿Tengo que hacer algo en mi equipo personal? En la mayoría de equipos con Windows actualizado, Microsoft aplica el cambio automáticamente. Basta con mantener al día Windows y el firmware del fabricante.

¿Cómo sé si un equipo ya tiene los certificados de 2023? Con Get-SecureBootUEFI en PowerShell, comprobando si la base de datos DB contiene "Windows UEFI CA 2023", o buscando el evento 1808 en el Visor de eventos.

¿Puede saltar BitLocker al actualizar? Sí. Los cambios en la cadena de arranque pueden provocar que BitLocker pida la clave de recuperación. Tenla localizada antes de empezar y valora suspender los protectores durante la actualización.

Conclusión

La caducidad de los certificados de Secure Boot no apagará ningún equipo, pero sí puede dejar sin protección la parte más crítica del arranque si no se gestiona. Para la mayoría de equipos el cambio será automático; para el resto, especialmente servidores, equipos con firmware antiguo y máquinas virtuales, hace falta un plan: inventario, diagnóstico, claves de BitLocker a mano y despliegue por fases. Es un buen ejemplo de mantenimiento que no se ve, pero que marca la diferencia en la seguridad de una organización.