Problema

Después de aplicar un Cumulative Update (CU) de Windows 11, una parte significativa de los equipos gestionados con Intune dejan de desbloquearse automáticamente. Los usuarios reciben mensajes de error al iniciar, el sistema solicita la clave de recuperación de BitLocker y, en algunos casos, el arranque se detiene porque el firmware no reconoce el certificado de Secure Boot que Intune había distribuido. El patrón típico es:

  • Un lote de 30‑+ dispositivos que antes funcionaban sin incidentes.
  • El CU se instala automáticamente (a través de Windows Update o WSUS).
  • Al reiniciar, el TPM no entrega la clave de desbloqueo y el proceso de arranque se bloquea.
  • La consola de Intune muestra que el certificado de Secure Boot está “applied”, pero el firmware lo ignora.

Este comportamiento rompe la política de “Zero‑Touch” y obliga a los administradores a recuperar manualmente claves, suspender BitLocker o incluso reinstalar el sistema.

Causa

Los fallos no provienen de un único componente; suelen combinarse varios factores que aparecen con la misma actualización:

  1. Cambio en la validación de firmas de Secure Boot
    Algunas versiones de los CU modifican la lista de algoritmos aceptados o añaden una comprobación de fecha de expiración del certificado. Si el certificado distribuido por Intune está firmado con SHA‑1 o tiene una fecha fuera del rango aceptado, el firmware lo rechaza.

  2. Re‑registro del TPM después del CU
    El proceso de actualización puede reinicializar el TPM y borrar temporalmente los protectores de BitLocker. Cuando el controlador de BitLocker intenta leer la clave, el TPM responde “no autorizado”, lo que dispara la solicitud de recuperación.

  3. Desincronización entre Intune y el firmware
    Intune marca el certificado como “installed”, pero el firmware no lo ha cargado porque la actualización del BIOS/UEFI no se ha ejecutado aún. En laptops con Secure Boot habilitado, el firmware solo carga certificados firmados por la autoridad que está en la lista de arranque segura; cualquier cambio en la lista requiere una re‑aplicación explícita.

  4. Política de “Require device encryption” activada sin suspensión previa
    Si la política de BitLocker está configurada para “Require encryption” y la actualización se ejecuta mientras el disco está activo, el agente de Windows intenta re‑encriptar el volumen durante el reinicio, lo que colisiona con el proceso de arranque seguro.

Solución

Una estrategia robusta combina preparación previa, manejo automático del TPM y una rutina de post‑actualización que verifica el estado de Secure Boot y BitLocker. El flujo recomendado es:

1. Preparar el certificado de Secure Boot

  • Usa un certificado firmado con SHA‑256 y una validez mínima de 2 años.
  • En Intune, crea un Device Configuration > Endpoint security > Secure Boot y sube el certificado.
  • Habilita la opción Force re‑enrollment after firmware update para que el dispositivo vuelva a cargar el certificado cuando detecte un cambio de firmware.

2. Suspender BitLocker antes del CU

Ejecuta un script que:

  • Suspende BitLocker (sin desactivar la protección).
  • Fuerza la instalación del CU mediante wuauclt /detectnow o Install-Module -Name PSWindowsUpdate.
  • Registra el estado del TPM antes de la actualización.

3. Aplicar el CU y validar el firmware

  • Configura la política de Windows Update para que el CU se instale fuera del horario crítico.
  • Después del reinicio, verifica que la variable de firmware SecureBoot sea Enabled y que el certificado aparezca en la lista de SecureBoot del UEFI (bcdedit /enum {current}).

4. Reactivar BitLocker y validar la clave

  • Si el TPM devolvió el protector, reanuda BitLocker.
  • Si no, usa la clave de recuperación almacenada en Azure AD para volver a crear el protector (manage-bde -protectors -add C: -tpm).
  • Registra el nuevo protector en Azure AD para evitar futuros bloqueos.

5. Automatizar con Intune

  • Crea una PowerShell script asignada a los dispositivos que combine los pasos 2‑4.
  • Usa la condición “Device OS version = Windows 11 22H2” para limitar la ejecución a los equipos que recibieron el CU problemático.
  • Configura un Compliance policy que marque como no conforme a los dispositivos que todavía tengan BitLockerStatus = Suspended después de 2 horas.

Cuándo aplicar esta solución

Aplicable cuando:

  • Los dispositivos ejecutan Windows 11 y están inscritos en Intune.
  • Se detecta que, tras un CU, el arranque solicita la clave de recuperación de BitLocker o muestra “Secure Boot violation”.
  • El certificado de Secure Boot está gestionado por Intune y tiene una firma SHA‑256.

No aplicable si:

  • El entorno usa BitLocker sin TPM (solo contraseña), porque el problema radica en la interacción TPM‑Secure Boot.
  • Los equipos no están bajo gestión de Intune (no hay forma de distribuir el certificado automáticamente).
  • La falla se origina en un BIOS/UEFI corrupto que requiere actualización manual del firmware.

Código

# PowerShell script para suspender, actualizar y reactivar BitLocker
# Ejecutar con privilegios de administrador

# 1. Suspender BitLocker (sin desactivar)
$volumes = Get-BitLockerVolume | Where-Object {$_.VolumeStatus -eq 'FullyEncrypted'}
foreach ($v in $volumes) {
    Suspend-BitLocker -MountPoint $v.MountPoint -RebootCount 1
}

# 2. Forzar detección e instalación del CU
Install-Module -Name PSWindowsUpdate -Force -Scope CurrentUser
Import-Module PSWindowsUpdate
Get-WUInstall -AcceptAll -AutoReboot

# 3. Esperar a que el equipo reinicie y vuelva a ejecutar el script
Start-Sleep -Seconds 300

# 4. Verificar estado de Secure Boot
$sb = (Get-WmiObject -Namespace root\Microsoft\Windows\HardwareManagement -Class MSAcpi_ThermalZoneTemperature).CurrentTemperature
if ((Confirm-SecureBootUEFI) -eq $false) {
    Write-Error "Secure Boot no está habilitado"
    exit 1
}

# 5. Reactivar BitLocker
foreach ($v in $volumes) {
    Resume-BitLocker -MountPoint $v.MountPoint
}

Verificación

  1. Comprobar Secure Boot
    Ejecuta Confirm-SecureBootUEFI en PowerShell; debe devolver $true.
  2. Validar protector TPM
    manage-bde -status C: debe mostrar Key Protectors: TPM.
  3. Revisar cumplimiento en Intune
    En el portal, filtra por la política de cumplimiento creada; todos los dispositivos deben aparecer como “Compliant”.
  4. Probar arranque limpio
    Reinicia una máquina de prueba sin conectar medios externos; el sistema debe iniciar sin solicitar la clave de recuperación.

Notas adicionales

  • En entornos con hardware mixto (OEM con firmware propio), verifica que la versión del BIOS/UEFI sea la recomendada por el fabricante antes de aplicar el CU.
  • Si el certificado de Secure Boot se revoca accidentalmente, vuelve a subirlo a Intune y fuerza una sincronización (DeviceSync desde la consola).
  • Mantén una copia de seguridad de las claves de recuperación en Azure AD; sin ella, la re‑creación del protector TPM puede quedar bloqueada.
  • Cuando uses Suspend-BitLocker -RebootCount 1, el estado vuelve a activarse automáticamente tras el siguiente reinicio, evitando que el disco quede indefinidamente sin protección.