Conflicto grave con Arranque seguro (Secure Boot)

[FTC]

Tras la actualización del Martes, imagino, porque no he tocado nada, quedó bloqueado el Arranque seguro en mi PC con Windows 10 IoT Enterprise 2021 x64, que afecta, también, a todos los demás sistemas operativos de los distintos discos duros independientes.
Nada más arrancar, aparece (en inglés): "El sistema ha encontrado cambios no autorizados en el firmware, sistema operativo o drivers UEFI".
Y no existe modo de continuar mientras Arranque seguro esté activado. Cuestión que no me había pasado nunca.

Saludos.

[jmtella]

ChatGPT (Pro) dice esto (y suele ser fiable).

Sí: por los síntomas, encaja muchísimo con una actualización de Secure Boot / certificados UEFI, no con que se haya estropeado un Windows concreto.

La pista clave es esta: te afecta a todos los sistemas operativos de discos distintos. Eso apunta a la NVRAM/firmware UEFI de la placa, concretamente a las bases de firmas de Secure Boot: DB, DBX, KEK, no al contenido de un solo disco.

Microsoft está justo en plena transición de certificados Secure Boot antiguos de 2011 a certificados de 2023, porque los de 2011 empiezan a expirar en junio de 2026. Además, la actualización de Windows 10 del martes 9 de junio de 2026, KB5094127, menciona explícitamente el tema de expiración/estado de certificados Secure Boot; y Microsoft documenta que algunos firmwares pueden fallar al actualizar DB/DBX/KEK o incluso dejar el arranque bloqueado hasta que se actualice/restaure el estado correcto del firmware. (Microsoft Support) Qué creo que te ha pasado


Probablemente una de estas dos cosas:

1. La actualización ha cambiado la política de confianza de Secure Boot —DB/DBX/certificados— y ahora tu UEFI rechaza algún cargador: Windows Boot Manager antiguo, GRUB/shim de Linux, loader de otra instalación, herramienta de arranque, driver UEFI de controladora, etc.
2. El firmware de la placa ha gestionado mal la actualización de certificados, por ejemplo sobrescribiendo la DB en vez de añadir certificados nuevos. Microsoft describe exactamente este escenario: tras una actualización de certificados Secure Boot, el dispositivo puede fallar antes de cargar Windows, mostrar error de firmware/Secure Boot, y arrancar solo si se desactiva Secure Boot. (Microsoft Support)

El mensaje que ves —“The system found unauthorized changes…”— es el clásico Secure Boot Violation: la UEFI considera que algo de la cadena de arranque ya no está firmado con una clave que acepte. Qué haría yo, en orden seguro

1. No reinstales nada


No parece un problema de instalación de Windows ni de disco. Reinstalar puede hacerte perder tiempo y no tocaría la causa real. 2. Desactiva Secure Boot temporalmente para entrar


En BIOS/UEFI:

• Secure Boot: Disabled
• Mantén el modo UEFI, no cambies a CSM/Legacy salvo emergencia.
• No borres claves todavía.
• No hagas “Clear Secure Boot keys” como primer paso.

Si tienes BitLocker en algún Windows, ten a mano la clave de recuperación. Microsoft advierte que cambios de Secure Boot pueden provocar pantalla de recuperación BitLocker. (Microsoft Support) 3. Una vez dentro de Windows, mira qué se instaló


En PowerShell como administrador:
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 15 HotFixID, InstalledOn, Description


Y comprueba si está la de junio:
Get-HotFix -Id KB5094127


También:
winver


Para Windows 10 IoT Enterprise LTSC 2021, la rama 19044.x es la esperable. 4. Comprueba el estado del mecanismo Secure Boot Update


Microsoft indica que Windows usa una tarea programada llamada Secure-Boot-Update para aplicar certificados Secure Boot y que debe existir, estar habilitada y ejecutarse como SYSTEM. (Microsoft Support)

Ejecuta:
schtasks.exe /Query /TN "\Microsoft\Windows\PI\Secure-Boot-Update" /FO LIST /V


Y mira también:
reg query HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot


Si ves valores como AvailableUpdates, UEFICA2023Status, UEFICA2023Error o UEFICA2023ErrorEvent, pueden dar la pista de en qué fase se quedó. 5. Mira eventos Secure Boot


En PowerShell administrador:
Get-WinEvent -FilterHashtable @{
LogName='System'
Id=1032,1043,1795,1796,1797,1799,1802,1803
} -MaxEvents 50 | Format-List TimeCreated,Id,ProviderName,Message


Según Microsoft, eventos como 1795 suelen indicar fallo de firmware al actualizar variables Secure Boot, y 1803 indica problema con KEK firmada por OEM/plataforma. (Microsoft Support) 6. Actualiza BIOS/UEFI de la placa


Este paso es importante. Si el firmware ha manejado mal DB/DBX/KEK, Windows no puede “arreglarlo” del todo desde el sistema operativo. Microsoft dice que estas actualizaciones dependen del comportamiento correcto del firmware UEFI, y que si el firmware no soporta bien la operación pueden aparecer bloqueos o fallos hasta instalar una actualización del fabricante. (Microsoft Support)

Busca BIOS/UEFI nueva para la placa exacta. Si es ASUS, Gigabyte, MSI, ASRock, HP, Dell, etc., mejor desde la web del fabricante. 7. Después, reactivar Secure Boot con cuidado


Primero prueba con solo el disco de Windows 10 IoT en el orden de arranque.

En BIOS/UEFI:

• OS Type: Windows UEFI Mode
• Secure Boot Mode: Standard
• Secure Boot: Enabled

Si existe una opción tipo:

• “Install default Secure Boot keys”
• “Restore factory keys”
• “Reset Secure Boot to setup/default”

úsala con cuidado solo después de actualizar BIOS, porque Microsoft advierte que restaurar valores por defecto antiguos puede quitar certificados 2023 si el firmware no los trae actualizados. (Microsoft Support) Si con Secure Boot ON sigue bloqueando


Entonces el problema casi seguro es uno de estos:

• cargador EFI antiguo en algún disco;
• GRUB/shim viejo de Linux;
• Windows Boot Manager no actualizado;
• medio USB/recovery antiguo;
• opción ROM/firmware de una controladora PCIe/NVMe/GPU;
• firmware UEFI defectuoso.

Para reparar el cargador de Windows, arrancando con Secure Boot desactivado y desde el Windows afectado:
mountvol S: /S
bcdboot C:\Windows /s S: /f UEFI


Luego reinicia, entra en BIOS, activa Secure Boot y prueba.

Si el problema es Linux u otro sistema, habrá que actualizar shim, grub-efi, kernels y firmwares desde ese sistema antes de volver a activar Secure Boot. Mi recomendación práctica


Para recuperar operativa ya: Secure Boot desactivado temporalmente.

Para dejarlo bien:

1. Arrancar Windows con Secure Boot OFF.
2. Guardar claves BitLocker si existen.
3. Actualizar BIOS/UEFI.
4. Aplicar todas las actualizaciones Windows pendientes.
5. Revisar eventos 1795/1803/1032/1799.
6. Rehabilitar Secure Boot con solo el disco Windows primero.
7. Luego añadir el resto de discos/sistemas uno a uno.

No lo trataría como intrusión de primeras. Por fecha, mensaje y efecto global en todos los discos, huele mucho más a rotura/cambio de confianza Secure Boot tras actualización de certificados/revocaciones.

[FTC]

Gracias JM. Voy a ir actuando según indicas.

Debo advertir que mi placa base es antigua, ASUS Z87-PRO (V EDITION), con la última BIOS disponible (2103) y existe la posibilidad de que las funciones necesarias para una actualización correcta de las claves, certificados y demás puntos básicos no se contemplen en ella. No obstante, hasta ahora se iban desarollando los procesos con normalidad y el ordenador aceptaba todas las actualizaciones de WU de manera satisfactoria.

Saludos.

[FTC]

JM, te cuento:

En principio traté de seguir al pie de la letra cada uno de los puntos señalados en tu mensaje. Sin embargo, siempre me topaba con un muro al final de los respectivos intentos. No había manera de activar el Arranque seguro sin que apareciera el consabido mensaje "El sistema ha encontrado cambios no autorizados en el firmware, sistema operativo o drivers UEFI". Eso en todos los discos duros independientes con sistema operativo.
Entonces, tomando el toro por los cuernos, decidí que tendría que ir a mayores. Ante la ineficacia de lo actuado, en primer lugar restablecí las claves de todos los epígrafes del Arranque seguro a su estado inicial predeterminado por el fabricante de la placa base. Luego lo activé, dando preferencia al modo UEFI. A continuación, desde USB inicié la instalación del Windows 10 IoT Enterprise LTSC 2021 x64, en un HD nuevo, sin formatear, pero esta vez desde la versión en inglés. Y funcionó.
Al terminar, disponía de un flamante sistema nuevo, con el dichoso Arranque seguro en acción, incluso me atreví a hacer lo propio con el CSM. Y desde él escribo.
No tiene desperdicio la mención que se refleja en la configuración: "El Arranque seguro se ha activado y se han aplicado todas las actualizaciones de certificado necesarias".
Ante todo muchas gracias por las orientaciones que has facilitado. Por supuesto, el origen del conflicto estaba en La actualización ha cambiado la política de confianza de Secure Boot y El firmware de la placa ha gestionado mal la actualización de certificados. De eso no hay duda.

Saludos.

[jmtella]

El CSM ni de coña ..debe estar en UEFI puro. El tenerlo en CSM da problemas serios al instalar certificados y si lo tenias así eso ha sido el causante

[FTC]

El CSM nunca lo tengo activado, desde hace mucho tiempo. Lo de ahora solo ha sido para probar.

Repito las gracias.

[FTC]

Por cierto, la puesta a punto ha reanudado el normal funcionamiento de los sistemas operativos relativos a los distintos discos duros independientes.
Y reitero que la prueba del CSM únicamente la efectué para verificar los dispositivos NO UEFI del PC. Después, como siempre, lo desactivé.

Saludos.