After updating with the MCS Machine Catalogs with a golden image that has it's bootloader signed by the Windows UEFI CA 2023, VDAs can fail to boot with “No Boot Media”.

Applies to:

• Any hypervisor where VMs were originally created with only the Windows UEFI CA 2011 certificate in the Secure Boot database
• Citrix Virtual Apps and Desktops (CVAD) — all versions, on-premises and Citrix Cloud

Follow your hypervisor below for resolution steps.

XenServer

For XenServer, MCS catalog updates replace the OS disk but do not update the VM's NVRAM, which contains the Secure Boot certificate store. When a catalog update applies a 2023-signed bootloader, existing VMs with only the 2011 certificate in their NVRAM fail to boot. This issue also affects Image Preparation VMs — the Image Prep VM is created using the same stored NVRAM from the original catalog creation, so catalog updates with a 2023-signed master image will also fail during image preparation.

XenServer provides two mechanisms to address this:

• Auto-update pool parameter (Part A): Automatically injects the 2023 certificate into VMs at creation time and on each boot. This covers Image Prep VMs, new VDAs, and existing VDAs.

  • For persistent VDAs, the certificate persists across reboots. The expected secureboot_certificates_state is ok.

  • For non-persistent VDAs, NVRAM is reset to the VM's creation-time state on every power cycle, undoing the injection. The expected secureboot_certificates_state is update_on_boot — Windows Secure Boot servicing re-injects the certificate on every boot. This does not affect functionality (see Step 6 for details).

• Certificate Remediation API (Part B): Allows marking existing VMs for certificate update on next reboot. This is required for persistent VDAs and the master image that were created before the auto-update feature was enabled.

XenServer Version Reference

If VMs Have Already Failed to Boot:

These are immediate fixes available before upgrading XenServer.

• Fix Option 1: Roll Back the Master Image (Non-persistent VDAs)

  • Revert the MCS catalog to the previous master image snapshot that uses a 2011-signed bootloader.

• Fix Option 2: Disable Secure Boot (Persistent VDAs)

  • Disable Secure Boot on affected VMs so the bootloader signature is not checked.

  • To automate this, refer to the example script (Fix Boot Failure - Disable Secure Boot)

• Fix Option 3: Create a New Catalog with a New Master Image (Only for XenServer 9 or XenServer 8.4 (November 2025 update or later))

  • Create a new master image on a new VM (do not reuse the existing master image VM).

  • The NVRAM of new VDA VMs and the Image Prep VM will automatically include the 2023 certificate from the XenServer firmware template.

  • Take a snapshot and create a new machine catalog

Recommendation to Prevent the Issue:

Step 1: Upgrade XenServer and Enable Auto-Update (Part A)

Upgrade to XenServer 8.4 or 9 with the Secure Boot 2023 certificate hotfix. After upgrading and enabling the feature, VMs created through MCS operations (Image Prep VMs, new VDAs) will automatically receive the 2023 certificate. The auto-update feature also injects the certificate on each boot for existing VMs.

Note for non-persistent catalogs:

• A non-persistent VDA's NVRAM is fixed at VM creation time. Power cycling only replaces the disk — it does not recreate the VM. The auto-update feature injects the 2023 certificate on each boot, but the NVRAM reset undoes it on every power cycle. This means Windows Secure Boot servicing will run on every boot. To eliminate this, apply MachineProfile (see Step 6). This is not blocking — VDAs boot and function normally, Secure Boot is enforced correctly, and the observed boot-time impact is within normal variance. It is cosmetic churn plus minor per-boot servicing overhead, not a failure.

Verify the feature is enabled:

To enable:

To identify the pool UUID:

Step 2: Remediate Existing VDAs and the Master Image (Part B)

Existing VDAs and the Master Image, which were created before enabling the auto-update feature, still have only the 2011 certificate in their NVRAM.

These VMs must be remediated using the Certificate Remediation API. Run the following PowerShell cmdlets below.

Step 2-1: Connect to the XenServer.

Step 2-2: Get XenServer VM object.

Step 2-3: Mark VM for certificate update on next reboot.

• To automate the Step 2-1 through Step 2-3 for VDAs, refer the example script (Prevent Boot Failure - Deploy Certificate)

• The step 2 for the master image VM needs to be run manually on the master image.

Step 2-4: (Recommended Verification Step) Restart the VM to apply the certificate and Confirm the certificate status.

Wihout Machine Profile, new VDAs added to a pre-2023 catalog will also start at update_on_boot with repeated (non-blocking) per-boot servicing.

This has the following values:

For persistent VDAs and the master image : Proceed to the next step after confirming secureboot_certificates_state is ok. VM may require multiple reboots — Windows servicing completes over several boot cycles. The certificate state ok confirms completion.

For existing and new non-persistent VDAs: update_on_boot is the expected terminal state — the certificate state will not reach ok. (See Step 1 Note).

Restarting the VM multiple times from inside the guest OS does not resolve this. To eliminate repeated servicing, see Step 6.

Step 3: Complete Windows Updates by running the PowerShell cmdlets below.

• For non-persistent VDAs, run on the master image only.

• For persistent VDAs, run on each VDA (or automate via GPO).

Step 4: (Non-persistent VDAs): Take a snapshot of the master image and update the MCS catalog.

Step 5: (Recommended Verification Step) Verify the deployment by running the following cmdlet in PowerShell on a provisioned VDA.

Returns True if the Windows UEFI CA 2023 certificate has been deployed to the Secure Boot DB.

For non-persistent VDAs, run the cmdlet on the master image.

For persistent VDAs, run the cmdlet on each VDA.

Step 6: (Optional) Eliminate Repeated Per-Boot Servicing on Existing Non-Persistent Catalogs via MachineProfile.

Applies to: existing non-persistent catalogs only. New catalogs created from a master image that already carries the 2023 certificate are not affected and do not need this step.

Requirement: Cloud DDC or CVAD 2603 to support adding MachineProfile to an existing XenServer catalog.

As described in Step 1 Note, non-persistent VDAs on catalogs with a 2011-only NVRAM baseline remain at update_on_boot — Windows Secure Boot servicing re-injects the certificate on every boot. This does not affect functionality but adds minor per-boot overhead. MachineProfile can eliminate this by providing a 2023-inclusive NVRAM baseline to newly created VDAs.

To bring existing VDAs to ok status, remove and re-add them to recreate with the updated MachineProfile.

Set a MachineProfile pointing to a VM with secureboot_certificates_state = ok (e.g., the master image after completing Step 2). The fix depends on the machine profile itself containing the 2023 certificate. A machine profile created from an old (2011-only) source will not help.

New VDAs created after this inherit the 2023 certificate NVRAM and start with ok status.

Verification: Power on a new VDA and check:

Expected: ok

References

• Manage UEFI Secure Boot certificate remediation - XenServer 8.4

• Manage UEFI Secure Boot certificate remediation - XenServer 9

• Early Access channel updates - XenServer 8.4

• Early Access channel updates - XenServer 9

• Windows Secure Boot certificate expiration and CA updates

• XenServer Secure Boot 2023 Certificate Scripts (Github)

VMware

Recommendation:

On VMware versions earlier than ESXi 8.0 U3j (P09) Build #25429389, Windows updates that deploy Secure Boot 2023 certificates may fail. This occurs because ESXi versions prior to 8.0 U3j create VMs with a null Platform Key (PK). Without a valid PK, the KEK 2023 deployment cannot be authorized, which in turn prevents subsequent DB updates.

If VMs Have Already Failed to Boot:

Follow one of the fix options below, then follow the recommendation to prevent the issue.

• Fix Option 1: Roll Back the Master Image (Non-persistent VDAs)

  • Revert the MCS catalog to the previous master image snapshot that uses a 2011-signed bootloader.

• Fix Option 2: Disable Secure Boot (Persistent VDAs)

  • Disable Secure Boot on affected VMs so the bootloader signature is not checked.

  • To automate this, refer to the example script (Fix Boot Failure - Disable Secure Boot)

• Fix Option 3: Resetting the NVRAM (VMware does not recommend)

  • Remove the NVRAM file on each VM to regenerate it on next boot. This resets all Secure Boot keys and may cause BitLocker recovery prompts on VMs with vTPM.

  • To automate this, refer to the example script (Fix Boot Failure - Reset NVRAM)

• Fix Option 4: Reprovision VMs (Non-persistent VDAs)

  • Reprovision the MCS catalog. New VMs are created with updated Secure Boot certificates.

  • Reprovisioning persistent VDAs will destroy user data.

Recommendation to Prevent the Issue:

For VMware, administrators can follow the steps below to address the Windows UEFI CA 2023 issue.

Step 1: Upgrade the hypervisor.

For ESXi 9.x: Upgrade to ESXi 9.0 or later.

For ESXi 8.0: Upgrade to ESXi 8.0 U3j (P09) Build #25429389.

For both persistent and non-persistent VDAs without vTPM,

Step 2: Deploy the 2023 certificate to the Secure Boot DB.

For ESXi 9.x,

• Perform Steps 2a-1 through 2a-4 from the machine with VMware PowerCLI installed.

Step 2a-1 (ESXi 9.x): Connect to vCenter.

Step 2a-2 (ESXi 9.x): Stop the VM.

Step 2a-3 (ESXi 9.x): Reset the Secure Boot DB by running the PowerShell cmdlets below. On next boot, ESXi regenerates the NVRAM with the 2023 certificate included.

Step 2a-4 (ESXi 9.x): Start the VM. No Windows Update or scheduled task is required.

For non-persistent VDAs, this can be scripted across all provisioned VMs before the next boot.

For details, refer to Secure Boot Custom Certificates (KB 377306).

For ESXi 8.0 U3j (P09),

For non-persistent VDAs, perform Steps 2b-2 through 2b-4 on the master image.

For persistent VDAs, perform Steps 2b-2 through 2b-4 on each VDA.

Step 2b-1 (ESXi 8.0 U3j): Restart VMs (SilentPK). The PK is automatically updated via SilentPK during reboot.

• For details, refer to "SilentPK update for vTPM disabled Virtual Machines" in Secure Boot Certificate Expirations and Update Failures in VMware Virtual Machines.

Step 2b-2 (ESXi 8.0 U3j): Complete Windows updates by running the PowerShell cmdlets below. Windows Updates can be automated via Group Policy (GPO).

Step 2b-3 (ESXi 8.0 U3j): Deploy the UEFI CA 2023 to the VMs by running the PowerShell cmdlet below.

Step 2b-4 (ESXi 8.0 U3j): Restart the VM twice from inside the guest OS, not from Citrix Web Studio. The first restart applies the certificate, and the second finalizes the deployment.

Step 2b-5 (ESXi 8.0 U3j): Non-persistent VDAs only. Take a snapshot of the master image and update the MCS catalog.

To automate Steps 2b-2 through 2b-4, refer to the example script (Prevent Boot Failure - Deploy Certificate)

Step 3: Verify the deployment by running the following cmdlet in PowerShell on a provisioned VDA.

Returns True if the Windows UEFI CA 2023 certificate has been deployed to the Secure Boot DB.

For non-persistent VDAs, run the cmdlet on the master image.

For persistent VDAs, run the cmdlet on each VDA.

For both persistent and non-persistent VDAs with vTPM,

• VMware recommends waiting for an automated Capsule Update solution in a future release.

References

• Secure Boot Certificate Expirations and Update Failures in VMware Virtual Machines

• VMware ESXi 8.0 Update 3j Release Notes

• Secure Boot Custom Certificates (KB 377306)

SCVMM / Hyper-V

For SCVMM (Hyper-V), Hyper‑V Generation 2 VMs use Microsoft-managed Secure Boot keys and trust stores, allowing Secure Boot certificate updates to be delivered through Windows Update without requiring hypervisor-level updates.

If VMs Have Already Failed to Boot:

Follow one of the fix options below, then follow the recommendation to prevent the issue.

• Fix Option 1: Roll Back the Master Image (Non-persistent VDAs)

  • Revert the MCS catalog to the previous master image snapshot that uses a 2011-signed bootloader.

• Fix Option 2: Disable Secure Boot (Persistent VDAs)

  • Disable Secure Boot on affected VMs so the bootloader signature is not checked.

  • To automate this, refer to the example script (Fix Boot Failure - Disable Secure Boot)

• Fix Option 3: Reprovision VMs (Non-persistent VDAs)

  • Reprovision the MCS catalog. New VMs are created with updated Secure Boot certificates.

  • Reprovisioning persistent VDAs will destroy user data.

Recommendation to Prevent the Issue:

Step 1: Deploy the Windows UEFI CA 2023 certificate to the Secure Boot DB.

For non-persistent VDAs, perform Steps 1-1 through 1-3 on the master image.

For persistent VDAs, perform Steps 1-1 through 1-3 on each VDA.

Step 1-1: Complete Windows updates by running the PowerShell cmdlets below. Windows Updates can be automated via Group Policy (GPO).

Step 1-2: Deploy the UEFI CA 2023 to the VMs by running the PowerShell cmdlet below.

Step 1-3: Restart the VM twice from inside the guest OS, not from Citrix Web Studio. The first restart applies the certificate, and the second finalizes the deployment

Step 1-4 (Non-persistent VDAs): Take a snapshot of the master image and update the MCS catalog.

• To automate Steps 1-1 through 1-3, refer to the example script (Prevent Boot Failure - Deploy Certificate)

Step 2: Verify the deployment by running the following cmdlet in PowerShell on a provisioned VDA.

Returns True if the Windows UEFI CA 2023 certificate has been deployed to the Secure Boot DB.

For non-persistent VDAs, run the cmdlet on the master image.

For persistent VDAs, run the cmdlet on each VDA.

References

• Windows Secure Boot certificate expiration and CA updates

OpenShift

OpenShift will not have the Windows UEFI CA 2023 certificate issue. This is because the OpenShift versions 4.18+ that Citrix supports already include 2023 certificate.

Nutanix AHV

For Nutanix AHV, VMs created on AHV 10.3.1.9 (or 11.0.1.2) or later include the new 2023 Secure Boot certificates by default. However, VMs created on earlier AHV versions do not, and upgrading AHV alone does not automatically apply the new certificates to existing VMs.

If VMs Have Already Failed to Boot:

Follow one of the fix options below, then follow the recommendation to prevent the issue.

• Fix Option 1: Roll Back the Master Image (Non-persistent VDAs)

  • Revert the MCS catalog to the previous master image snapshot that uses a 2011-signed bootloader.

• Fix Option 2: Disable Secure Boot (Persistent VDAs)

  • Disable Secure Boot on affected VMs so the bootloader signature is not checked.

  • To automate this, refer to the example script (Fix Boot Failure - Disable Secure Boot)

• Fix Option 3: Reprovision VMs (Non-persistent VDAs)

  • Reprovision the MCS catalog. New VMs are created with updated Secure Boot certificates.

  • Reprovisioning persistent VDAs will destroy user data.

Recommendation to Prevent the Issue:

Step 1: Upgrade AHV to version 10.3.1.9 (or 11.0.1.2) or later. VMs created on these versions include the 2023 Secure Boot certificates by default.

Step 2: Deploy the Windows UEFI CA 2023 certificate to the Secure Boot DB on existing VMs. For non-persistent VDAs, perform Steps 2-1 through 2-3 on the master image. For persistent VDAs, perform Steps 2-1 through 2-3 on each VDA.

Step 2-1: Complete Windows updates by running the PowerShell cmdlets below. Windows Updates can be automated via Group Policy (GPO).

Step 2-2: Deploy the UEFI CA 2023 to the VMs by running the PowerShell cmdlet below.

Step 2-3: Restart the VM twice from inside the guest OS, not from Citrix Web Studio. The first restart applies the certificate, and the second finalizes the deployment

Step 2-4 (Non-persistent VDAs): Take a snapshot of the master image and update the MCS catalog.

• To automate Steps 2-1 through 2-3, refer to the example script (Prevent Boot Failure - Deploy Certificate)

Step 3: Verify the deployment by running the following cmdlet in PowerShell on a provisioned VDA.

Returns True if the Windows UEFI CA 2023 certificate has been deployed to the Secure Boot DB.

For non-persistent VDAs, run the cmdlet on the master image.

For persistent VDAs, run the cmdlet on each VDA.

References

• Windows Secure Boot certificate expiration and CA updates

• Nutanix Support. How to update Secure Boot certificates for AHV virtual machines.

Azure

For Azure, VMs created after March 2024 include the 2023 Secure Boot certificates by default. VMs created prior to March 2024 do not, and require manual certificate deployment.

For Azure Local, version 2603 or later is required.

If VMs Have Already Failed to Boot:

Follow one of the fix options below, then follow the recommendation to prevent the issue.

• Fix Option 1: Roll Back the Master Image (Non-persistent VDAs)

  • Revert the MCS catalog to the previous master image snapshot that uses a 2011-signed bootloader.

• Fix Option 2: Disable Secure Boot (Persistent VDAs)

  • Disable Secure Boot on affected VMs so the bootloader signature is not checked.

  • To automate this, refer to the example script (Fix Boot Failure - Disable Secure Boot)

• Fix Option 3: Reprovision VMs (Non-persistent VDAs)

  • Reprovision the MCS catalog. New VMs are created with updated Secure Boot certificates.

  • Reprovisioning persistent VDAs will destroy user data.

Recommendation to Prevent the Issue:

Step 1 (Azure Local only): Upgrade Azure Local to version 2603 or later.

Step 2: Deploy the Windows UEFI CA 2023 certificate to the Secure Boot DB.

For non-persistent VDAs, perform Steps 2-1 through 2-3 on the master image.

For persistent VDAs, perform Steps 2-1 through 2-3 on each VDA.

Step 2-1: Complete Windows updates by running the PowerShell cmdlets below. Windows Updates can be automated via Group Policy (GPO).

Step 2-2: Deploy the UEFI CA 2023 to the VMs by running the PowerShell cmdlet below.

Step 2-3: Restart the VM twice from inside the guest OS, not from Citrix Web Studio. The first restart applies the certificate, and the second finalizes the deployment.

Step 2-4 (Non-persistent VDAs): Take a snapshot of the master image and update the MCS catalog.

• To automate Steps 2-1 through 2-3, refer to the example script (Prevent Boot Failure - Deploy Certificate)

Step 3: Verify the deployment by running the following cmdlet in PowerShell on a provisioned VDA.

Returns True if the Windows UEFI CA 2023 certificate has been deployed to the Secure Boot DB.

For non-persistent VDAs, run the cmdlet on the master image.

For persistent VDAs, run the cmdlet on each VDA.

References

• Windows Secure Boot certificate expiration and CA updates

• Azure Local. Manage Secure Boot updates.

GCP

For GCP, administrators can follow the steps below to address the Windows UEFI CA 2023 issue.

If VMs Have Already Failed to Boot:

Follow one of the fix options below, then follow the recommendation to prevent the issue.

• Fix Option 1: Roll Back the Master Image (Non-persistent VDAs)

  • Revert the MCS catalog to the previous master image snapshot that uses a 2011-signed bootloader.

• Fix Option 2: Disable Secure Boot (Persistent VDAs)

  • Disable Secure Boot on affected VMs so the bootloader signature is not checked.

  • To automate this, refer to the example script (Fix Boot Failure - Disable Secure Boot)

• Fix Option 3: Reprovision VMs (Non-persistent VDAs)

  • Reprovision the MCS catalog. New VMs are created with updated Secure Boot certificates.

  • Reprovisioning persistent VDAs will destroy user data.

Recommendation to Prevent the Issue:

Step 1: Deploy the Windows UEFI CA 2023 certificate to the Secure Boot DB.

For non-persistent VDAs, perform Steps 1-1 through 1-3 on the master image.

For persistent VDAs, perform Steps 1-1 through 1-3 on each VDA.

Step 1-1: Complete Windows updates by running the PowerShell cmdlets below. Windows Updates can be automated via Group Policy (GPO).

Step 1-2: Deploy the UEFI CA 2023 to the VMs by running the PowerShell cmdlet below.

Step 1-3: Restart the VM twice from inside the guest OS, not from Citrix Web Studio. The first restart applies the certificate, and the second finalizes the deployment.

Step 1-4 (Non-persistent VDAs): Take a snapshot of the master image and update the MCS catalog.

To automate Steps 1-1 through 1-3, refer to the example script (Prevent Boot Failure - Deploy Certificate)

Step 2: Verify the deployment by running the following cmdlet in PowerShell on a provisioned VDA.

Returns True if the Windows UEFI CA 2023 certificate has been deployed to the Secure Boot DB.

For non-persistent VDAs, run the cmdlet on the master image.

For persistent VDAs, run the cmdlet on each VDA.

AWS

For AWS, administrators can follow the steps below to address the Windows UEFI CA 2023 issue.

If VMs Have Already Failed to Boot:

Follow one of the fix options below, then follow the recommendation to prevent the issue.

• Fix Option 1: Roll Back the Master Image (Non-persistent VDAs)

  • Revert the MCS catalog to the previous master image snapshot that uses a 2011-signed bootloader.

• Fix Option 2: Disable Secure Boot (Persistent VDAs)

  • Disable Secure Boot on affected VMs so the bootloader signature is not checked.

  • To automate this, refer to the example script (Fix Boot Failure - Disable Secure Boot)

• Fix Option 3: Reprovision VMs (Non-persistent VDAs)

  • Reprovision the MCS catalog. New VMs are created with updated Secure Boot certificates.

  • Reprovisioning persistent VDAs will destroy user data.

Recommendation to Prevent the Issue:

Step 1: Deploy the Windows UEFI CA 2023 certificate to the Secure Boot DB.

For non-persistent VDAs, perform Steps 1-1 through 1-3 on the master image.

For persistent VDAs, perform Steps 1-1 through 1-3 on each VDA.

Step 1-1: Complete Windows updates by running the PowerShell cmdlets below. Windows Updates can be automated via Group Policy (GPO).

Step 1-2: Deploy the UEFI CA 2023 to the VMs by running the PowerShell cmdlet below.

Step 1-3: Restart the VM twice from inside the guest OS, not from Citrix Web Studio. The first restart applies the certificate, and the second finalizes the deployment.

Step 1-4 (Non-persistent VDAs): Take a snapshot of the master image and update the MCS catalog.

To automate Steps 1-1 through 1-3, refer to the example script (Prevent Boot Failure - Deploy Certificate)

Step 2: Verify the deployment by running the following cmdlet in PowerShell on a provisioned VDA.

Returns True if the Windows UEFI CA 2023 certificate has been deployed to the Secure Boot DB.

For non-persistent VDAs, run the cmdlet on the master image.

For persistent VDAs, run the cmdlet on each VDA.

References

• Windows Secure Boot certificate expiration and CA updates

AWS Workspace Core

For AWS Workspace Core, administrators can follow the steps below to address the Windows UEFI CA 2023 issue.

If VMs Have Already Failed to Boot:

Follow one of the fix options below, then follow the recommendation to prevent the issue.

• Fix Option 1: Roll Back the Master Image (Non-persistent VDAs)

  • Revert the MCS catalog to the previous master image snapshot that uses a 2011-signed bootloader.

• Fix Option 2: Disable Secure Boot (Persistent VDAs)

  • Disable Secure Boot on affected VMs so the bootloader signature is not checked.

  • To automate this, refer to the example script (Fix Boot Failure - Disable Secure Boot)

• Fix Option 3: Reprovision VMs (Non-persistent VDAs)

  • Reprovision the MCS catalog. New VMs are created with updated Secure Boot certificates.

  • Reprovisioning persistent VDAs will destroy user data.

Recommendation to Prevent the Issue:

Step 1: Deploy the Windows UEFI CA 2023 certificate to the Secure Boot DB.

For non-persistent VDAs, perform Steps 1-1 through 1-3 on the master image.

For persistent VDAs, perform Steps 1-1 through 1-3 on each VDA.

Step 1-1: Complete Windows updates by running the PowerShell cmdlets below. Windows Updates can be automated via Group Policy (GPO).

Step 1-2: Deploy the UEFI CA 2023 to the VMs by running the PowerShell cmdlet below.

Step 1-3: Restart the VM twice from inside the guest OS, not from Citrix Web Studio. The first restart applies the certificate, and the second finalizes the deployment.

Step 1-4 (Non-persistent VDAs): Take a snapshot of the master image and update the MCS catalog.

To automate Steps 1-1 through 1-3, refer to the example script (Prevent Boot Failure - Deploy Certificate)

Step 2: Verify the deployment by running the following cmdlet in PowerShell on a provisioned VDA.

Returns True if the Windows UEFI CA 2023 certificate has been deployed to the Secure Boot DB.

For non-persistent VDAs, run the cmdlet on the master image.

For persistent VDAs, run the cmdlet on each VDA.

Microsoft is transitioning from the Windows UEFI CA 2011 certificate to the Windows UEFI CA 2023 certificate for signing Windows bootloaders. The 2011 certificate expires in June 2026. This does not mean existing VMs will stop booting — Secure Boot does not check certificate expiration. However, recent Windows Updates can install bootloaders signed with the 2023 certificate. If the VM's Secure Boot DB only contains the 2011 certificate, the VM will fail to boot after receiving a 2023-signed bootloader.

• [Microsoft] Windows Secure Boot certificate expiration and CA updates
• [Microsoft] How to manage the Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932
• [Microsoft] Sample Secure Boot Inventory Data Collection script
• [Azure Local] Manage Secure Boot updates on Azure Local
• [GCP] feedbackMicrosoft Secure Boot certificates expiration guide
• Github Citrix MCS SDK Samples. Please check the SampleAdminScenarios in each hypervisor folder