Problema

En entornos de virtualización que combinan UEFI, Secure Boot y un TPM virtual (vTPM), es frecuente encontrarse con que, después de restaurar una máquina virtual (VM) desde una copia de seguridad, el arranque falla con un mensaje Access Denied. El error suele aparecer antes de que el sistema operativo cargue y obliga al administrador a desactivar Secure Boot o a “resetear” las claves de arranque. El patrón es reproducible: cualquier VM que incluya un vTPM y que haya sido restaurada muestra el bloqueo, mientras que VMs sin vTPM o recién creadas no presentan el problema.

Este comportamiento no es exclusivo de una solución de backup concreta; se manifiesta en cualquier plataforma que gestione el estado del vTPM como parte del proceso de restauración. El síntoma típico es:

Secure Boot Violation – Access Denied

y la única salida inmediata es desactivar Secure Boot o resetear las claves desde el firmware virtual.

Causa

1. Inconsistencia del estado del vTPM

El vTPM almacena las claves de Secure Boot y los valores de PCR (Platform Configuration Registers). Cuando una VM se respalda, el motor de backup suele capturar el disco y la configuración de la VM, pero no siempre exporta el estado interno del vTPM. Al restaurar, el hipervisor crea un nuevo vTPM vacío o reutiliza uno con un estado diferente al original. Secure Boot, al validar la firma de los binarios contra las claves almacenadas, detecta la discrepancia y bloquea el arranque.

2. Cambio de GUID del firmware

Al recrear la VM, el hipervisor asigna un nuevo GUID de firmware UEFI. Las claves de Secure Boot están vinculadas a ese GUID; si el vTPM conserva el antiguo GUID, la validación falla. Algunas plataformas (por ejemplo, Scale Computing) generan un GUID distinto al restaurar, lo que produce la colisión.

3. Políticas de arranque firmadas por la entidad de gestión

En entornos gestionados (por ejemplo, Acronis Cyber Protect Cloud), los paquetes de arranque pueden estar firmados con una clave de la organización. Si la restauración no incluye la política de arranque o la clave del TPM, el firmware no reconoce la firma y devuelve Access Denied.

4. Configuración de Secure Boot en modo “Standard” vs “Custom”

Cuando el vTPM se restaura en modo Custom, las claves de arranque deben ser re‑importadas manualmente. Si la VM se restaura con Secure Boot en modo Standard pero el vTPM está vacío, el firmware no tiene una lista de claves válidas y aborta el arranque.

Solución

La estrategia consiste en alinear el estado del vTPM con la configuración de Secure Boot antes de que el firmware intente validar el arranque. Se pueden seguir tres vías principales:

A. Resetear y volver a provisionar el vTPM

  1. Apagar la VM y eliminar el dispositivo vTPM existente desde la consola del hipervisor.
  2. Crear un nuevo vTPM y asociarlo a la VM.
  3. Re‑inicializar Secure Boot:
    • Ingresar al firmware UEFI (presionando la tecla indicada en el arranque, normalmente Esc o F2).
    • Seleccionar Secure Boot → Reset to Setup Mode.
    • Cambiar a Standard Mode para que el firmware genere automáticamente las claves de Microsoft.
  4. Guardar y reiniciar. El VM debería arrancar sin error porque el vTPM y las claves están sincronizados.

B. Exportar e importar el estado del vTPM con la herramienta del hipervisor

Algunos hipervisores (Hyper‑V, VMware) permiten exportar el blob del vTPM antes de la copia de seguridad y volver a importarlo después de la restauración:

# Hyper‑V PowerShell example
Export-VMKeyProtector -VMName "MyVM" -Path "C:\Backup\MyVM_TPM.bin"
# Después de la restauración
Import-VMKeyProtector -VMName "MyVM_Restore" -Path "C:\Backup\MyVM_TPM.bin"

Una vez importado, el vTPM conserva sus PCR y claves originales, evitando la discrepancia.

C. Desactivar temporalmente Secure Boot y volver a habilitarlo

Si la plataforma no permite exportar el vTPM, se puede usar el siguiente proceso:

  1. Desactivar Secure Boot en el firmware UEFI.
  2. Arrancar la VM y, dentro de Windows, ejecutar tpm.msc para borrar el TPM (Clear TPM).
  3. Reiniciar y volver a activar Secure Boot. El firmware generará un nuevo conjunto de claves y el vTPM vacío será aceptado.

Este método es menos elegante porque borra cualquier clave almacenada, pero es rápido y funciona en la mayoría de los entornos de prueba.

Cuándo aplicar esta solución

  • Síntomas: error “Access Denied” en Secure Boot justo después de una restauración de VM que incluye vTPM; la VM arranca solo con Secure Boot desactivado.
  • Entornos: Hyper‑V, Scale Computing, VMware ESXi, o cualquier hipervisor que ofrezca vTPM y UEFI.
  • Aplicable cuando la copia de seguridad incluye discos y configuración, pero no el estado interno del vTPM (caso típico de soluciones de backup genéricas).
  • No aplicar si la VM no usa vTPM, o si la política de arranque está gestionada por un MDM que impone claves específicas que deben mantenerse; en ese caso, la solución es exportar/importar el vTPM o sincronizar la política de arranque con la herramienta de gestión.

Código

# PowerShell – Reset vTPM y volver a habilitar Secure Boot en Hyper‑V
Stop-VM -Name "MyVM" -Force
Remove-VMKeyProtector -VMName "MyVM"
Add-VMKeyProtector -VMName "MyVM"
Set-VMFirmware -VMName "MyVM" -EnableSecureBoot On -SecureBootTemplate MicrosoftUEFICertificateAuthority
Start-VM -Name "MyVM"

Verificación

  1. Revisar el log de firmware: en la pantalla de UEFI, buscar “Secure Boot State: Enabled” y que no aparezca “Access Denied”.
  2. Dentro de Windows, abrir tpm.msc y confirmar que el TPM está en estado Ready.
  3. Ejecutar bcdedit /enum y verificar que la entrada secureboot está marcada como Yes.
  4. Realizar una prueba de restauración en una VM de prueba y confirmar que arranca sin necesidad de desactivar Secure Boot.

Notas adicionales

  • Siempre que sea posible, incluya el estado del vTPM en la política de backup. Algunas herramientas (por ejemplo, Veeam) ofrecen una opción “Include TPM state” que elimina la necesidad de resetear.
  • Si su infraestructura usa Key Management Service (KMS) o Active Directory‑based TPM provisioning, asegúrese de que los controladores de dominio estén accesibles durante el arranque; de lo contrario, la validación de claves puede fallar.
  • En clústeres Scale Computing, el GUID del nodo puede cambiar tras una migración; verifique que el GUID de la VM coincida con el almacenado en el vTPM antes de la restauración.
  • Mantenga una lista de VMs críticas sin vTPM o con Secure Boot desactivado temporalmente, para poder recuperarlas rápidamente en caso de fallo masivo del backup.