Problema

En varios portátiles y desktops con Windows 11, después de instalar una actualización que incluye un firmware BIOS/UEFI, el arranque se detiene con el mensaje “Boot Manager Blocked by Current Security Policy”. La causa típica es que Secure Boot está habilitado y la base de datos de claves (DB/KEK) del firmware ha sido modificada por la actualización, mientras que el cargador de arranque de Windows sigue firmado con una clave que ya no coincide. El síntoma es idéntico en distintas marcas: el sistema no pasa del splash de Secure Boot y sólo arranca cuando se desactiva temporalmente Secure Boot en la BIOS.

Este comportamiento no es exclusivo de un modelo concreto; cualquier equipo que reciba una actualización de certificados de Secure Boot (por ejemplo, la migración de los certificados de 2011 a los “Windows UEFI CA 2023”) puede quedar atrapado en este estado.

Causa

  1. Actualización de la base de datos de Secure Boot
    Windows Update puede instalar un paquete que actualiza los certificados de la base de datos de firmware (DB/KEK). Cuando la firma del bootmgfw.efi ya no coincide con la nueva base de datos, el firmware la rechaza.

  2. Desfase entre firmware y cargador
    El firmware mantiene una copia de respaldo (\EFI\Boot\bootx64.efi) que, en sistemas afectados, contiene una versión antigua del Boot Manager. Al fallar la validación del Windows Boot Manager, el firmware intenta el fallback, pero al encontrar el mismo binario bloqueado, el proceso se detiene.

  3. Restablecimiento de claves insuficiente
    Ejecutar “Clear Keys” y “Restore Factory Keys” en la BIOS no soluciona el problema porque la base de datos de Windows sigue apuntando a los certificados expirados; el firmware necesita una reparación que restaure la relación entre la base de datos y el cargador firmado por Microsoft.

Solución

La forma más fiable es utilizar la herramienta de recuperación interna que Windows incluye en el ESP: SecureBootRecovery.efi. El proceso consiste en reemplazar temporalmente el archivo de fallback (bootx64.efi) por esta herramienta, forzando al firmware a ejecutar la reparación automática de la base de datos de Secure Boot. Los pasos son los siguientes y pueden repetirse en cualquier equipo que presente el mismo síntoma.

Preparación

  1. Inicia Windows con Secure Boot desactivado (puedes hacerlo desde la BIOS o usando el menú de arranque rápido).
  2. Abre PowerShell con privilegios de administrador.
  3. Identifica la partición ESP (tipo GUID c12a7328-f81f-11d2-ba4b-00a0c93ec93b). En la mayoría de los equipos será la primera partición del disco 0 y tendrá alrededor de 260 MiB sin letra asignada.

Reemplazo del fallback

# 1. Montar la ESP como Z:
Get-Partition | Where-Object { $_.GptType -eq '{c12a7328-f81f-11d2-ba4b-00a0c93ec93b}' } |
  ForEach-Object { Add-PartitionAccessPath -DiskNumber $_.DiskNumber -PartitionNumber $_.PartitionNumber -AccessPath 'Z:' }

# 2. Respaldar el fallback actual
Copy-Item 'Z:\EFI\Boot\bootx64.efi' 'Z:\EFI\Boot\bootx64.efi.bak' -Force

# 3. Copiar la herramienta de recuperación al fallback
Copy-Item 'Z:\EFI\Microsoft\Boot\SecureBootRecovery.efi' 'Z:\EFI\Boot\bootx64.efi' -Force

# 4. Desmontar la ESP
Remove-PartitionAccessPath -DiskNumber 0 -PartitionNumber 1 -AccessPath 'Z:'

Reinicio y reparación automática

  1. Vuelve a la BIOS y habilita Secure Boot.
  2. Guarda los cambios y reinicia.
  3. El firmware intentará cargar Windows Boot Manager, fallará la validación y caerá en el fallback. Ahora ejecutará SecureBootRecovery.efi, que muestra una pantalla azul de Microsoft y repara la base de datos de claves.
  4. Tras la reparación, el firmware reinicia automáticamente y Windows arranca normalmente.

Restauración del fallback original (opcional)

Una vez confirmada la reparación, es recomendable volver a colocar el archivo de fallback original para evitar que el sistema siempre arranque la herramienta de recuperación.

# Montar la ESP nuevamente
Add-PartitionAccessPath -DiskNumber 0 -PartitionNumber 1 -AccessPath 'Z:'

# Restaurar el backup
Copy-Item 'Z:\EFI\Boot\bootx64.efi.bak' 'Z:\EFI\Boot\bootx64.efi' -Force

# Limpiar el backup
Remove-Item 'Z:\EFI\Boot\bootx64.efi.bak' -Force

# Desmontar
Remove-PartitionAccessPath -DiskNumber 0 -PartitionNumber 1 -AccessPath 'Z:'

Cuándo aplicar esta solución

  • Síntomas: error “Boot Manager Blocked by Current Security Policy”, arranque detenido al habilitar Secure Boot, pero el sistema arranca sin problemas con Secure Boot desactivado.
  • Entorno: equipos con Windows 10/11 que recibieron una actualización de firmware o de certificados Secure Boot (especialmente en 2024‑2026, cuando los certificados de 2011 expiran).
  • No aplicable: si el fallo se debe a un daño físico del disco, a una configuración de BitLocker que impide el arranque, o a un BIOS que no contiene SecureBootRecovery.efi. En esos casos se requieren pasos diferentes (reparación de BCD, desactivación de BitLocker, etc.).

Verificación

  1. Ejecuta Confirm-SecureBootUEFI en PowerShell; debe devolver True.
  2. Revisa la entrada del gestor de arranque: bcdedit /enum firmware. El device debe apuntar a \EFI\Microsoft\Boot\bootmgfw.efi.
  3. Reinicia varias veces con Secure Boot habilitado para confirmar que el error no reaparece.

Notas adicionales

  • La herramienta de recuperación solo está disponible en sistemas con firmware UEFI que incluya la carpeta \EFI\Microsoft\Boot. Si falta, la actualización de Windows que introdujo la herramienta no se aplicó correctamente.
  • En algunos portátiles Lenovo, la partición ESP puede estar en el disco 1; ajusta -DiskNumber en los comandos según corresponda.
  • Mantener el BIOS actualizado reduce la probabilidad de que la base de datos de Secure Boot quede desincronizada, pero siempre verifica la versión de firmware antes de aplicar la solución.
  • Si el fallback original se corrompe, puedes recrearlo copiando cualquier archivo EFI válido (por ejemplo, bootmgfw.efi) a bootx64.efi, aunque la solución preferida es restaurar el backup.