Problema

En entornos con cientos o miles de endpoints gestionados mediante Intune o Configuration Manager, es frecuente encontrarse con equipos que solicitan la clave de recuperación de BitLocker en cada reinicio. El síntoma típico son entradas de evento como “Signature contained in EFI_SIGNATURE_DATA could not be found in trust chain” o “Recovery Information backup to Entra Recovery Information for given protector is already present”. El bloqueo ocurre aunque el disco ya esté cifrado y el TPM esté activo.

El patrón se repite en varios modelos (HP, Dell, Lenovo) y suele coincidir con actualizaciones de firmware o con la expiración de los certificados de arranque seguro (Secure Boot). Cuando el firmware no reconoce la cadena de confianza, BitLocker suspende la protección y obliga a la recuperación.

Causa

  1. Certificados de Secure Boot caducados o no cargados
    Los módulos de arranque (bootloaders) firmados con certificados que han expirado pierden la validez en la cadena de confianza del firmware. El TPM detecta la inconsistencia y revierte a modo de recuperación.

  2. Configuración de BIOS/UEFI desalineada
    Opciones como “Secure Boot” desactivadas, “Platform Key (PK)”, “Key Exchange Key (KEK)” o “db/dbx” sin cargar, provocan que el firmware no pueda validar la firma del cargador de Windows.

  3. Actualizaciones automáticas de firmware (Autopatch, HP SoftPaq, Dell Command Update)
    Cada parche que reemplaza el firmware puede sobrescribir la base de datos de certificados sin restaurar los valores esperados, generando un ciclo de suspensión‑recuperación.

  4. Política de BitLocker que fuerza la suspensión al detectar cambios en la plataforma
    Cuando la política incluye “Require TPM validation before unlocking” y el firmware reporta un cambio de certificado, BitLocker se suspende automáticamente.

  5. Desincronización entre Intune y el estado del TPM
    Si Intune no actualiza la propiedad “TPMOwnerAuth” después de una actualización de firmware, el agente interpreta que el TPM está en estado no confiable.

Solución

1. Verificar la validez de los certificados de Secure Boot

powershell -Command "Confirm-SecureBootUEFI"

Si el comando devuelve False o muestra errores, el firmware no está validando la cadena. En ese caso, restaure los certificados desde el menú de firmware o mediante la herramienta del fabricante (HP BIOS Configuration Utility, Dell Command | Configure, etc.).

2. Re‑establecer la base de datos de claves de Secure Boot

Ejecute el siguiente script de PowerShell en modo administrador. El script:

  • Borra la base de datos actual (db, KEK, PK).
  • Importa los certificados de fábrica provistos por el OEM.
  • Fuerza la re‑inscripción de la clave de arranque en el TPM.
#!/usr/bin/env pwsh
# Reset Secure Boot keys and re‑enroll TPM binding
$ErrorActionPreference = 'Stop'

# 1. Borrar bases de datos (requiere soporte del OEM)
Write-Host "Borrando bases de datos de Secure Boot..."
bcdedit /set {default} bootstatuspolicy ignoreallfailures
# Si el OEM provee una utilidad, reemplazar la línea anterior por su comando

# 2. Importar certificados de fábrica (ejemplo HP)
$certPath = "C:\OEM\SecureBoot\Certificates"
Get-ChildItem $certPath -Filter *.cer | ForEach-Object {
    Write-Host "Importando $($_.Name)..."
    # El comando real depende del OEM; aquí se usa una llamada genérica
    certutil -addstore "TrustedPublisher" $_.FullName
}

# 3. Forzar re‑enrollment del TPM
Write-Host "Re‑enrolling TPM..."
tpmvscmgr delete /instance ROOT\SMARTCARDREADER\0000
tpmvscmgr create /instance ROOT\SMARTCARDREADER\0000

# 4. Reiniciar para aplicar cambios
Write-Host "Reiniciando..."
shutdown /r /t 0

Nota: Ajuste la ruta y los comandos según el fabricante. En entornos HP, la utilidad HPBIOSUPDREC permite cargar los certificados desde un archivo .bin.

3. Asegurar la política de BitLocker

En Intune o Configuration Manager, configure la política:

  • Require TPM: Enabled
  • Allow BitLocker without TPM: Disabled
  • Suspend BitLocker on detected changes: Disabled

Esto evita que BitLocker se suspenda automáticamente cuando el firmware informa un cambio de certificado.

4. Aplicar una corrección de registro para “AvailableUpdate”

Aunque no soluciona el problema por sí sola, la clave ayuda a que Windows reconozca actualizaciones de Secure Boot:

reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\SecureBoot" /v AvailableUpdate /t REG_DWORD /d 1 /f

5. Automatizar la verificación post‑parche

Cree una tarea programada que, después de cualquier actualización de firmware, ejecute:

powershell -ExecutionPolicy Bypass -File C:\Scripts\CheckSecureBoot.ps1

El script debe:

  1. Verificar Confirm-SecureBootUEFI.
  2. Si falla, lanzar el proceso de restauración de certificados (paso 2).
  3. Registrar el resultado en el Event Log bajo una fuente personalizada (BitLockerUEFIHelper).

Cuándo aplicar esta solución

  • Síntomas: BitLocker solicita recuperación en cada arranque, eventos de EFI_SIGNATURE_DATA en el log, o mensajes de “TPM binding census” repetidos.
  • Entorno: Equipos con Secure Boot habilitado, gestión vía Intune/ConfigMgr, y firmware que recibe actualizaciones automáticas.
  • No aplica: Si la clave de recuperación se solicita solo tras cambios de hardware (disco nuevo, RAM) o cuando el TPM está deshabilitado en BIOS. En esos casos, la causa no está relacionada con certificados UEFI.

Código

#!/usr/bin/env pwsh
# Check and restore Secure Boot certificates
$sbStatus = (Confirm-SecureBootUEFI)
if (-not $sbStatus) {
    Write-Host "Secure Boot no está validado. Restaurando certificados..."
    # Ruta de los certificados OEM
    $certDir = "C:\OEM\SecureBoot\Certificates"
    Get-ChildItem $certDir -Filter *.cer | ForEach-Object {
        certutil -addstore "TrustedPublisher" $_.FullName
    }
    Write-Host "Reiniciando para aplicar cambios..."
    shutdown /r /t 0
} else {
    Write-Host "Secure Boot está operativo."
}

Verificación

  1. Revisar el Event Viewer
    • Microsoft-Windows-BitLocker-API/Operational: no debe aparecer “Signature contained in EFI_SIGNATURE_DATA could not be found in trust chain” después del reinicio.
  2. Comprobar el estado de BitLocker 
    manage-bde -status C:
    La salida debe indicar Protection Status: On y Key Protectors: TPM sin Recovery activo.
  3. Validar Secure Boot 
    powershell -Command "Confirm-SecureBootUEFI"
    Debe devolver True.
  4. Ejecutar un ciclo de arranque
    Reinicie el equipo y confirme que no se solicita la clave de recuperación.

Notas adicionales

  • Algunos modelos HP almacenan los certificados en una partición oculta. Si la partición está corrupta, la restauración mediante la utilidad HP BIOS Configuration Utility es la única vía.
  • Cuando se usa Autopatch, configure una excepción para los paquetes de firmware que modifican Secure Boot; de lo contrario, el proceso de restauración se ejecutará en cada ciclo de actualización.
  • Mantenga una copia de los certificados OEM en un repositorio interno y documente la versión de firmware asociada; esto acelera la respuesta ante incidentes.
  • Si la política de BitLocker está gestionada por Intune, use la acción “Refresh device policy” después de aplicar los cambios de BIOS para que el agente vuelva a registrar el protector TPM.

Con estos pasos, la mayoría de los entornos que experimentan bloqueos recurrentes de BitLocker por problemas de certificados UEFI pueden estabilizarse sin necesidad de intervención manual en cada máquina.