Manage UEFI Secure Boot certificate remediation
Microsoft’s original 2011 UEFI Secure Boot certificates begin to expire in June 2026, in favor of replacement certificates issued in 2023. XenServer® provides a managed remediation workflow that helps administrators identify virtual machines (VMs) whose UEFI NVRAM only contains the legacy 2011 Microsoft certificate chain and safely update those VMs to include the 2023 certificates during a controlled reboot.
An update was released for XenServer 8.4 in November 2025 which ensured newly provisioned virtual machines include the newer 2023 Microsoft certificates. This remediation workflow applies only to VMs originally provisioned prior to this update, where they may only have the legacy 2011 certificates.
The following VM-class objects are in scope for this remediation workflow:
- UEFI Windows and Linux VMs that contain only the Microsoft 2011 UEFI certificate chain, including VMs where Secure Boot is currently disabled.
- Snapshots and templates that carry the legacy certificate state (exposed for reporting, not directly updatable).
The following are out of scope:
- VMs that already contain the 2023 Microsoft certificates.
- BIOS boot VMs.
- VMs using custom UEFI certificates.
Note that where virtual machines are being provisioned by Citrix Virtual Apps and Desktops™ (CVAD), additional steps may be required to ensure future virtual machines contain the 2023 certificates. Please refer to CVAD guidance in CTX696696 for specific actions required.
Note:
The functionality described below was released as an update to the XenServer 8.4 Early Access channel on Jun 11, 2026. It is expected to reach the Normal channel before the end of June.
Certificate states
XenServer exposes a read-only certificate state for each VM, snapshot, and template object. The possible values are described in the following table:
| State | Meaning |
|---|---|
ok |
The object does not require remediation. This includes BIOS boot VMs and VMs already carrying the 2023 Microsoft certificate chain. |
update_available |
The VM is eligible for remediation and can be marked for update on the next boot. |
update_on_boot |
The VM has been marked and XenServer will update the certificates automatically at the next boot of that VM. |
Note:
Snapshots and templates display their certificate state for visibility only. Remediation applies only after a snapshot or template is converted to a VM and that VM is booted.
Prerequisites
Warning:
Updating the UEFI certificates changes TPM PCR measurements (notably PCR7), which can trigger BitLocker recovery mode on Windows guests that seal their Volume Master Key against PCR7. Plan and stage rollouts carefully to avoid unplanned user disruption.
Before you mark any VM for remediation, do the following:
- Ensure the BitLocker recovery keys are accessible as a precaution.
- Suspend BitLocker protection on affected Windows VMs prior to updating the certificates.
- Schedule the first post-remediation reboot in a monitored maintenance window.
Manage certificate remediation by using the CLI
Review certificate state
Run the following command to list the certificate state for all VM-class objects, including snapshots and templates:
xe vm-list params=name-label,uuid,is-a-template,is-snapshot,secureboot-certificates-state
<!--NeedCopy-->
Mark a VM for remediation
Run the following command to mark a VM so that XenServer updates the certificates at the next boot of that VM:
xe vm-update-secureboot-certificates-on-boot uuid=<vm-uuid> mark=true
<!--NeedCopy-->
Cancel pending updates
Run the following command to cancel a pending certificate update before the VM reboots:
xe vm-update-secureboot-certificates-on-boot uuid=<vm-uuid> mark=false
<!--NeedCopy-->
Note:
You can cancel a pending update only before the VM reboots and the scheduled remediation runs. After the VM has rebooted and the update has applied, the state returns to
okautomatically.
XenAPI reference
The certificate remediation workflow introduces the following XenAPI field and method, which are first available in SDK version 26.14.0.
Field: VM.secureboot_certificates_state
Read-only. Applies to VM, snapshot, and template objects. Possible values: ok, update_available, update_on_boot.
Method: VM.update_secureboot_certificates_on_boot(session, vm, mark)
Pass mark=true to schedule the certificate update on the next boot. Pass mark=false to cancel a pending update.
PowerShell reference
With a VM object $vm, the new field can be accessed as follows:
$vm.secureboot_certificates_state
<!--NeedCopy-->
The new method is invoked as follows:
Invoke-XenVM -XenAction UpdateSecurebootCertificatesOnBoot -VM $vm -Mark $true
<!--NeedCopy-->
Planning
- Schedule updates in reasonably sized batches to limit the scope of any impacts from issues such as BitLocker recovery.
- Test updates on representative VMs first and validate guest boot behavior before broad rollout.
- Do not bulk-reboot a large number of VMs simultaneously; stagger reboots to allow time to respond to unexpected BitLocker or boot issues.
Troubleshooting
BitLocker recovery prompt after reboot
If BitLocker is configured and not suspended on a Windows VM, it is likely to prompt for a BitLocker recovery key after the first reboot following certificate remediation.
Enter the BitLocker recovery key to unlock the drive. After the VM boots successfully, BitLocker resumes protecting the volume automatically. To avoid this behaviour, suspend BitLocker protection on the VM before the scheduled remediation reboot, and resume it after the reboot has completed.
VM remains in update_available state after reboot
If a VM still shows update_available after a reboot, the update may not have been applied. Verify that the VM was marked before it rebooted by checking the state with the xe CLI. If the state is update_available rather than ok, mark the VM again and reboot.
Snapshot or template shows update_available
Snapshots and templates cannot be directly remediated. To update the certificate state of a snapshot or template, convert it to a VM and then reboot that VM after marking it for update.