Product documentation
Citrix Provisioning
Current Release 2511 2507.1 LTSR 2503-1 2411 2407 2402 LTSR 2311 2203 LTSR
View PDF

Windows Secure Boot certificate expiration and CA updates

April 28, 2026
Contributed by: 
C

As documented by Microsoft at Windows Secure Boot certificate expiration and CA updates - Microsoft Support, the current certificates used for validating binaries when using Secure Boot are expiring in 2026 and have been replaced by new CA certificates which are used in the future to validate that binaries are properly signed. When booting a Citrix Provisioning target VDA, there are two different certificates that are used:

  • The CA certificate which is used to validate the Citrix Provisioning network boot program as it is loaded. This has to be present in the UEFI firmware storage in order to boot a Citrix Provisioning VDA.

    • The existing certificate that is expiring is the Microsoft UEFI CA 2011. For the moment, this is the certificate used to sign the Citrix Provisioning network boot program and this continues to work after the CA certificate expires unless it is revoked.
    • The new certificate is the Microsoft UEFI CA 2023. At some point in 2026, Citrix Provisioning releases will contain Network Boot Programs signed by this certificate at which point they will only load if the hypervisor has been updated to include it.

  • The CA certificate which is used to validate the Windows boot loader. When using Citrix Provisioning, the Windows boot loader is validated by the Citrix Provisioning Network Boot Program which has the CA certificate embedded. Currently, shipping versions of Citrix Provisioning only include the old CA certificate but there will be releases that include the new one as well - Citrix Provisioning will try both old and new certificate when loading the Windows Boot Loader.

    • The existing certificate that is expiring is Microsoft Windows Production PCA 2011.
    • The new certificate is the Windows UEFI CA 2023.

Important:

Even after your hypervisor is upgraded to a release that includes the new certificates, any existing VMs are not automatically updated to include this - the certificate information is stored in the UEFI NVRAM which is part of the VM.

Upgrading your environment

The process of upgrading the environment has three or four steps depending on the boot method used for Citrix Provisioning targets:

  1. Upgrade the hypervisor being used to a version that includes the new certificates.
  2. Update any existing VMs so that they have the updated certificates present in their NVRAM.
  3. Upgrade Citrix Provisioning to a version that includes both certificates used to sign the Windows Boot Loader.
  4. If using BDM or ISO boot, then update all the BDMdisk and ISO images.

Important:

  • Do steps 1 and 2 now to prepare your environment for the shift.
  • Windows has published documentation on how to mitigate CVE-2023-24932 by revoking the old Secure Boot certificates. This MUST NOT be done until you have completely updated your Citrix Provisioning setup as documented herein, including upgrading to a Citrix Provisioning version where the firmware is signed with the new certificate (this will be announced in the “What’s new” section of the release where this is done - at that point, Citrix Provisioning will only work if the hypervisor and VMs have been updated). See How to manage the Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932.
  • When the old certificates are to be revoked, it is necessary to update the hypervisor hosts with that change and then update all existing VMs again to pick up the fact that the old certificates have been revoked. This implies that you must do steps 1 and 2 again.

The following table shows the results when the steps are done:

Installed Hypervisor Installed Citrix Provisioning Results
Old

Old (existing LTSR CUs, 2507 and earlier). NBP signed with old CA cert and has old Windows cert embedded. Secure Boot will continue to work until a Windows update that is signed by the new Windows CA is applied to the vDisk. At that point Secure Boot will stop working.
New, 2411, 2603, updated LTSR CUs. NBP still signed with old CA cert, with old and new Windows cert embedded. Currently, we are shipping Citrix Provisioning NBP signed by the old key which will continue to work. Secure Boot fully supported.
New, 2607 onwards, all LTSR CUs released after June 2026. NBP signed with new CA cert with old and new Windows cert embedded. Secure Boot will stop working after updating to these releases.
New (includes old and new CA certs)

Old. NBP signed with old CA cert and has old Windows cert embedded. Secure Boot will continue to work until a Windows update that is signed by the new Windows CA is applied to the vDisk. At that point Secure Boot will stop working.
New, 2411, 2603, existing LTSR CUs. NBP still signed with old CA cert, with old and new Windows cert embedded. Currently, we are shipping PVS NBP signed by the old key which will continue to work. Secure Boot fully supported.
New, 2607 onwards (worst case), All LTSR CUs released after June 2026. NBP signed with new CA cert with old and new Windows cert embedded. Secure Boot fully supported.

Upgrading the hypervisor

You should upgrade your hypervisor to a version that is at least what is outlined in the following table (note that earlier releases are not supported once the Secure Boot certificates are being used by Microsoft to sign binaries):

Hypervisor Minimum version
VMWare/ESXi vSphere 8.0 update 3h
XenServer 8.4, November 2025 update
Hyper-V Host should be running Server 2019 and newer with latest windows updates. Note that the process to enable the new certificates requires manual steps but Server 2022 and 2025 are automatically done as part of the windows update procedure. See Updating Server 2019 to enable the new CA certificates for details of enabling the new certificates in Server 2019 Hyper-V hosts.
Azure The new certificates were available as of late 2024. Any VMs created before this time will have to be reprovisioned.
Nutanix AVH 20230302.101026, associated with AOS 6.5.1
OpenShift Version 4.17 or later
GCP Google do not document when the new certificates were included. You should check any existing VMs using the script included later to see if the VMs already have the newer certificates present.

Upgrading existing VMs

Any VMs using Secure Boot that existed before the hypervisor was upgraded must be updated. The simplest and safest approach is to reprovision these VMs but most environments provide tools to help update existing VMs as documented in the following table:

Note:

If the VM also has a virtual TPM enabled, then it is not possible to update existing VMs and they must be reprovisioned.

Hypervisor Procedure
VMware vSphere 8 Not possible - you must reprovision all Citrix Provisioning target VMs.
VMware vSphere 9 You can reset a virtual machine’s Secure Boot keys to the factory defaults (restoring the original trusted CA certificates, such as Microsoft UEFI CA and Microsoft Windows Production CA) using either the vSphere Client UI or the vicfg-uefi CLI tool.
XenServer 8.4 Not possible. You must reprovision all Citrix Provisioning target VMs.
Hyper-V The Secure Boot certificates can be reset to the current set by toggling the Secure Boot Template to another value and then back to the MicrosoftUEFI Secure Boot template.
Other Hypervisors Citrix Provisioning targets using Secure Boot must be reprovisioned.

If you are unsure how many Citrix Provisioning targets are using Secure Boot, see Determine if a VM uses secure boot and has the new certificates for instructions on checking this.

Determine if a VM uses Secure Boot and has the new certificates

You can determine if a VM is using Secure Boot by running msinfo32 inside the VM but this won’t tell you if the VM has the new certificates available or not.

See Appendix 1 for a script that be run from a Windows VM to determine if it is using Secure Boot and whether or not it has the new certificates.

See Appendix 2 for detailed information on updating existing VMs if you decide not to simply reprovision.

Upgrade the Citrix Provisioning target boot process

There are three boot methods for Citrix Provisioning targets, each of which require different work to enable the new certificates to be used:

  • Network/PXE Boot: when the Citrix Provisioning farm is completely upgraded, targets that use PXE Boot automatically gets the updated Citrix Provisioning boot program the next time they boot.
  • BDM Disk Boot: once the farm is completely upgraded, update all of the BDM disks for targets that use Secure Boot. The BDM update process that is available in the Citrix Provisioning console can be used for this. In addition, use the PowerShell cmdlet Start-PvsDeviceUpdateBdm to update individual devices or all devices in a collection
  • ISO Boot: once the farm is completely updated, use the BDM.exe program to create new ISO images as required, upload to the hypervisor and change all VM definitions to boot from the updated ISO.

Appendix 1

The following script can be run in a Windows VM to determine if it uses Secure Boot and whether or not it already has the new certificates available.

Script: Extract-db.ps1

# dumpdb-fixed.ps1
$ErrorActionPreference = "Stop"

Write-Host "SecureBoot enabled:" (Confirm-SecureBootUEFI)

$db = Get-SecureBootUEFI -Name db
$bytes = $db.Bytes

$outDir = Join-Path $env:TEMP ("uefi-db-certs-" + (Get-Date -Format "yyyyMMdd-HHmmss"))
New-Item -ItemType Directory -Path $outDir | Out-Null

$dbPath = Join-Path $outDir "db.bin"
[IO.File]::WriteAllBytes($dbPath, $bytes)
Write-Host "Wrote raw UEFI db to: $dbPath"
Write-Host "Parsing for X.509 certs..."

function Read-GuidFromBytes {
  param(
    [byte[]]$b,
    [int]$offset
  )
  if ($offset -lt 0 -or ($offset + 16) -gt $b.Length) {
    throw "GUID read out of range at offset $offset (len=$($b.Length))"
  }

  $gBytes = New-Object byte[] 16
  [Array]::Copy($b, $offset, $gBytes, 0, 16)

  # IMPORTANT: force the Guid(byte[]) ctor
  return [Guid]::new($gBytes)
}

$EFI_CERT_X509_GUID = [Guid]"a5c059a1-94e4-4aa7-87b5-ab155c2bf072"

$pos = 0
$certIndex = 0
$records = @()

while ($pos -lt $bytes.Length) {
  if ($pos + 28 -gt $bytes.Length) { break }

  $sigType  = Read-GuidFromBytes -b $bytes -offset $pos
  $listSize = [BitConverter]::ToUInt32($bytes, $pos + 16)
  $hdrSize  = [BitConverter]::ToUInt32($bytes, $pos + 20)
  $sigSize  = [BitConverter]::ToUInt32($bytes, $pos + 24)

  # sanity checks
  if ($listSize -lt 28) { break }
  if ($sigSize -lt 16)  { break }
  if (($pos + $listSize) -gt $bytes.Length) { break }

  $sigDataStart = $pos + 28 + $hdrSize
  $sigDataEnd   = $pos + $listSize
  if ($sigDataStart -gt $sigDataEnd) { break }

  $entryCount = [Math]::Floor( ($sigDataEnd - $sigDataStart) / $sigSize )

  for ($i = 0; $i -lt $entryCount; $i++) {
    $entryOffset = $sigDataStart + ($i * $sigSize)

    if ($entryOffset + $sigSize -gt $bytes.Length) { continue }

    $owner = Read-GuidFromBytes -b $bytes -offset $entryOffset
    $dataOffset = $entryOffset + 16
    $dataLen    = $sigSize - 16

    if ($sigType -eq $EFI_CERT_X509_GUID) {
      $certBytes = New-Object byte[] $dataLen
      [Array]::Copy($bytes, $dataOffset, $certBytes, 0, $dataLen)

      try {
        $cert = [System.Security.Cryptography.X509Certificates.X509Certificate2]::new($certBytes)

        $certIndex++
        $cerPath = Join-Path $outDir ("db-cert-{0:D3}.cer" -f $certIndex)
        [IO.File]::WriteAllBytes($cerPath, $certBytes)

        $records += [PSCustomObject]@{
          Index      = $certIndex
          OwnerGuid  = $owner.ToString()
          Subject    = $cert.Subject
          Issuer     = $cert.Issuer
          Thumbprint = $cert.Thumbprint
          NotBefore  = $cert.NotBefore
          NotAfter   = $cert.NotAfter
          Path       = $cerPath
        }
      } catch {
        # ignore non-parseable entries
      }
    }
  }

  $pos += $listSize
}

$csvPath = Join-Path $outDir "db-certs.csv"
$records | Export-Csv -NoTypeInformation -Path $csvPath

Write-Host ""
Write-Host "Extracted $($records.Count) X.509 cert(s) from UEFI db."
Write-Host "Output directory: $outDir"
Write-Host "CSV summary:      $csvPath"
$records | Select-Object Index, Thumbprint, NotAfter, Subject | Format-Table -AutoSize
<!--NeedCopy-->

Sample output for a VM that does not have the new certificates.

PS C:\Users\simong\Downloads> .\Extract-db.ps1
SecureBoot enabled: True
Wrote raw UEFI db to: C:\Users\simong\AppData\Local\Temp\uefi-db-certs-20260305-131219\db.bin
Parsing for X.509 certs...

Extracted 2 X.509 cert(s) from UEFI db.
Output directory: C:\Users\simong\AppData\Local\Temp\uefi-db-certs-20260305-131219
CSV summary:      C:\Users\simong\AppData\Local\Temp\uefi-db-certs-20260305-131219\db-certs.csv

Index Thumbprint                               NotAfter              Subject
----- ----------                               --------              -------
    1 580A6F4CC4E4B669B9EBDC1B2B3E087B80D0678D 10/19/2026 2:51:42 PM CN=Microsoft Windows Production PCA 2011, O=Mic...
    2 46DEF63B5CE61CF8BA0DE2E6639C1019D0ED14F3 6/27/2026 5:32:45 PM  CN=Microsoft Corporation UEFI CA 2011, O=Micros...
<!--NeedCopy-->

VMware

  1. Install or import PowerCLI.

    Install-Module -Name VMware.PowerCLI -Scope CurrentUser
Import-Module VMware.PowerCLI
<!--NeedCopy-->

  2. Connect to your vCenter or ESXi host.

    Connect-VIServer -Server <your-vcenter-or-esxi-host>
<!--NeedCopy-->

  3. Check Secure Boot for:

    • All VMs:

      Get-VM | Select Name, @{N='SecureBoot';E={ ($_ | Get-VMFirmware).EnableSecureBoot }}
<!--NeedCopy-->

    • A specific VM:

      $vm = Get-VM -Name 'YourVMName'
$firmware = $vm | Get-VMFirmware
$firmware.EnableSecureBoot   # Returns True or False
<!--NeedCopy-->

    Output:

    • True: Secure Boot is enabled.
    • False: Secure Boot is disabled.

Query via PowerCLI Script 

# List all VMs and their Secure Boot state
Get-VM | Select-Object Name, @{N='SecureBootEnabled'; E={$_.ExtensionData.Config.BootOptions.EfiSecureBootEnabled}}
<!--NeedCopy-->

Using the vSphere API (Python example)

With pyVmomi, you can programmatically access the same value:

from pyVim.connect import SmartConnect, Disconnect
from pyVmomi import vim
# (login and setup code here...)
vm = # get your VM object
if vm.config.firmware == "efi":
    print(f"Secure Boot enabled: {vm.config.bootOptions.efiSecureBootEnabled}")
else:
    print("VM does not use EFI firmware.")
<!--NeedCopy-->

Summary table

Method Script/Command Output
PowerCLI Get-VMFirmware and EnableSecureBoot True/False per VM
pyVmomi (Python) vm.config.bootOptions.efiSecureBootEnabled True/False

XenServer

To test whether a VM uses Secure Boot in XenServer 8.4, you need to check the VM’s configuration for the secure_boot parameter in the VM’s platform settings. Perform the following steps in the built-in xe CLI, which is the most straightforward and scriptable method.

  1. List Your VMs.

    xe vm-list is-control-domain=false
<!--NeedCopy-->

    Find your VM’s uuid.

  2. Inspect platform parameters for Secure Boot.

    xe vm-param-get uuid=<VM-UUID> param-name=platform
<!--NeedCopy-->

    Sample output:

    Not secureboot: true in the following:

    [root@ra-xen-04 ~]# xe vm-param-get uuid=740a8d85-c096-c9cd-b83e-2c106513415f param-name=platform
timeoffset: -18002; device-model: qemu-upstream-uefi; cores-per-socket: 2; 
device_id: 0002; viridian: true; viridian_time_ref_count: true; 
viridian_reference_tsc: true; viridian_apic_assist: true; viridian_crash_ctl: true;
viridian_stimer: true; secureboot: true; vga: std; videoram: 8; nx: true; 
acpi: 1; apic: true; pae: true; hpet: true; acpi_laptop_slate: 1; vtpm: true
<!--NeedCopy-->

    Interpretation:

    • If you see secure_boot: true, then the VM is using Secure Boot.
    • If you see secure_boot: false or the key is missing, Secure Boot is not enabled.

  3. Script to Check all VMs. The following is a bash snippet to list all VMs and their Secure Boot status.

    for UUID in $(xe vm-list is-control-domain=false --minimal | tr ',' '\n'); do
NAME=$(xe vm-param-get uuid=$UUID param-name=name-label)
PLATFORM=$(xe vm-param-get uuid=$UUID param-name=platform)
SECURE_BOOT=$(echo "$PLATFORM" | grep -oE 'secureboot: [^;]+' | awk '{print $2}')
echo "$NAME: Secure Boot = ${SECURE_BOOT:-not set}"
done
<!--NeedCopy-->

    You can also print the names of all VMs that are using secure Boot:

    xe vm-list platform:secureboot=true params=name-label --minimal|tr ',' '\n'
ra-w11-cvad002
ra-w11-cvad027
ra2-w11-cvad029
ra-w11-cvad029
ra2-w11-cvad020
ra-w11-cvad014
ra-w11-cvad020
ra-w11-cvad016
ra-w11-cvad003
...
<!--NeedCopy-->

Summary table

Platform Parameter Secure Boot State
secureboot: true Secure Boot is ON
secureboot: false Secure Boot is OFF
No secureboot key Secure Boot is not set/not supported

Checking templates

Any templates other than the built-in ones must be updated or recreated to ensure the updated certificates are present. The built-in template objects have is-default-template=true set so use the following command:

xe template-list params=name-label,is-default-template
<!--NeedCopy-->

Hyper-V

To check whether a Hyper-V VM has Secure Boot enabled, you can use PowerShell, which is scriptable and works locally or remotely.

Note:

The following commands must be run on the hyper-v host and not the machine with SCVMM installed.

  1. List Secure Boot Status for all VMs.

    Get-VM | Get-VMFirmware -ErrorAction SilentlyContinue | Select-Object VMName, SecureBoot
<!--NeedCopy-->

    Sample output:

    PS C:\Users\administrator.CELESTIALS> Get-VM | Get-VMFirmware -ErrorAction SilentlyContinue | Select-Object VMName, SecureBoot

VMName     SecureBoot
------     ----------
2016               On
2025              Off
025-1            Off
simgr-2025         On
<!--NeedCopy-->

  2. Check Secure Boot for one VM.

    Get-VM -Name "YourVMName" | Get-VMFirmware | Select-Object SecureBoot
<!--NeedCopy-->

    The property SecureBootEnabled is:

    • On if Secure Boot is enabled.
    • Off if Secure Boot is disabled.

Important:

Generation 2 VMs only: Secure Boot is only supported for Generation 2 VMs, which use UEFI firmware. Generation 1 (BIOS) VMs does not have this property.

Appendix 2

As previously stated, the safest approach is to reprovision all VMs that use Secure Boot but if this is not possible then this section describes how existing target VMs can be updated for those hypervisors that support updating.

VMware vSphere 9

In VMware vSphere 9, you can reset a virtual machine’s Secure Boot keys to the factory defaults (restoring the original trusted CA certificates, such as Microsoft UEFI CA and Microsoft Windows Production CA) using the vicfg-uefi CLI tool.

CLI/PowerCLI method

Prerequisites:

  • vSphere 9
  • The VM must be powered off.

Commands

The basic requirement is to set the following advanced parameters for each VM to TRUE. These causes the VM to reload the certificates on next boot.

"uefi.secureBoot.PK.resetOnce"
"uefi.secureBoot.KEK.resetOnce"
"uefi.secureBoot.db.resetOnce"
"uefi.secureBoot.dbx.resetOnce"
<!--NeedCopy-->

The following script (VMWare-ResetCertificates.ps1) is an example of doing this for a specific VM (including connecting to the vCenter and setting parameters) to allow self-signed certificates to be used by the vCenter.

param (
    [Parameter(Mandatory=$true)]
    [string]$vCenter,

    [Parameter(Mandatory=$true)]
    [PSCredential]$Credential,

    [Parameter(Mandatory=$true)]
    [string]$VMName
)

# 1. Suppress CEIP warning and ignore invalid certificates for this session only
Set-PowerCLIConfiguration -ParticipateInCEIP $false -InvalidCertificateAction Ignore -Confirm:$false -Scope Session | Out-Null

# 2. Connect to vCenter
Write-Host "Connecting to vCenter: $vCenter..." -ForegroundColor Cyan
try {
    Connect-VIServer -Server $vCenter -Credential $Credential -ErrorAction Stop
}
catch {
    Write-Error "Failed to connect to vCenter: $_"
    return
}

# 3. Get VM Object
$vm = Get-VM -Name $VMName -ErrorAction SilentlyContinue
if (-not $vm) {
    Write-Error "VM '$VMName' not found."
    Disconnect-VIServer -Server $vCenter -Confirm:$false
    return
}

# 4. Fail if the VM is not powered off
if ($vm.PowerState -ne "PoweredOff") {
    Write-Error "VM '$VMName' must be Powered Off to reset Secure Boot. Current state: $($vm.PowerState)"
    Disconnect-VIServer -Server $vCenter -Confirm:$false
    return 
}

# 5. Build and Apply Reset Spec
$spec = New-Object VMware.Vim.VirtualMachineConfigSpec
$resetKeys = @(
    "uefi.secureBoot.PK.resetOnce",
    "uefi.secureBoot.KEK.resetOnce",
    "uefi.secureBoot.db.resetOnce",
    "uefi.secureBoot.dbx.resetOnce"
)

foreach ($key in $resetKeys) {
    $option = New-Object VMware.Vim.OptionValue
    $option.Key = $key
    $option.Value = "TRUE"
    $spec.ExtraConfig += $option
}

Write-Host "Applying Secure Boot reset flags to $VMName..." -ForegroundColor Cyan
try {
    $vm.ExtensionData.ReconfigVM($spec)
    Write-Host "Success! Certificates will reset on the next power-on." -ForegroundColor Green
}
catch {
    Write-Error "Failed to update configuration: $_"
}

# 6. Disconnect
Disconnect-VIServer -Server $vCenter -Confirm:$false
<!--NeedCopy-->

Hyper-V

In Hyper-V Gen 2 VMs, you can use PowerShell to change the Secure Boot template, which in practice resets the Secure Boot keys to the chosen “factory” set (either the Microsoft Windows Production CA or Microsoft UEFI CA).

This is the closest PowerShell-equivalent to a “reset to factory” for Secure Boot keys in Hyper-V.

How Secure Boot template works in Hyper-V

  • Secure Boot Template = firmware’s “preset” CA certificate selection.
  • There are two built-in templates:
    • MicrosoftWindows: Only trusts the Microsoft Windows Production CA (good for all Windows OS).
    • MicrosoftUEFICertificateAuthority: Trusts the Microsoft UEFI CA (needed for most modern Linux distros with shim). This template MUST be selected for Citrix Provisioning streamed VMs.

Changing the template replaces the UEFI Secure Boot PK/KEK/db with the default set for that template. This effectively resets any custom or previously-enrolled keys back to the chosen set.

PowerShell instructions

Note:

This cannot be done if the VM has a vTPM.

  1. List available Secure Boot templates.

    (Get-VMHost).SecureBootTemplates

Id                                   Name                              Description
--                                   ----                              -----------
1734c6e8-3154-4dda-ba5f-a874cc483422 MicrosoftWindows                  Microsoft Windows
272e7447-90a4-4563-a4b9-8e4ab00526ce MicrosoftUEFICertificateAuthority Microsoft UEFI Certificate Authority
4292ae2b-ee2c-42b5-a969-dd8f8689f6f3 OpenSourceShieldedVM              Open Source Shielded VM
<!--NeedCopy-->

  2. Look up VMs using the UEFI Secure Boot template. Use the following script.

    Get-VM | Where-Object Generation -eq 2 | ForEach-Object {
$firmware = Get-VMFirmware -VM $_
    
if ($firmware.SecureBootTemplate -eq "MicrosoftUEFICertificateAuthority") {
    [PSCustomObject]@{
        VMName     = $_.Name
        TPMEnabled = (Get-VMSecurity -VM $_).TPMEnabled
    }
}
} | Format-Table -AutoSize
<!--NeedCopy-->

    Output:

    PS C:\Users\administrator.CELESTIALS\Downloads> .\Get-PVSTargetVMs.ps1

VMName         TPMEnabled
------         ----------
mo-PVS13804-02       True
pvs-hv2022-1         True
pvs-hv2022-2         True
<!--NeedCopy-->

    Note:

    Remember that you cannot update VMs using a TPM. These have to be reprovisioned.

  3. Change Citrix Provisioning targets using the UEFI template to Windows and then back to UEFI to reload the certificates.

    # Set template to Windows CA only
Set-VMFirmware -VMName "YourVMName" -SecureBootTemplate MicrosoftWindows
# Set template to Windows and UEFI CA
Set-VMFirmware -VMName "YourVMName" -SecureBootTemplate MicrosoftUEFICertificateAuthority
<!--NeedCopy-->
    • The new template overwrites any user-enrolled keys and bring the firmware back to the template’s factory keys.
    • VM must be powered off to change the template.

    The following script (Update-PVS-VMs.ps1) changes all Citrix Provisioning VMs that are powered off that are not using a TPM.

    # Get all VMs using the Microsoft UEFI CA template
$vms = Get-VM | Get-VMFirmware -ErrorAction SilentlyContinue| Where-Object { $_.SecureBootTemplate -eq "MicrosoftUEFICertificateAuthority" }

foreach ($vmFirmware in $vms) {
$vmName = $vmFirmware.VMName
$vm = Get-VM -Name $vmName
    
# Check for TPM status
$tpmStatus = (Get-VMSecurity -VMName $vmName).TpmEnabled

if ($tpmStatus -eq $true) {
    Write-Host "Ignoring VM: $vmName which has TPM enabled." -ForegroundColor Red
    continue # Skip to the next VM in the loop
}

# Ensure VM is Off
if ($vm.State -ne 'Off') {
    Write-Host "Ignoring VM: $vmName which is on." -ForegroundColor Red
    continue
}

# Perform the toggle
Set-VMFirmware -VMName $vmName -SecureBootTemplate "MicrosoftWindows"
Set-VMFirmware -VMName $vmName -SecureBootTemplate "MicrosoftUEFICertificateAuthority"

Write-Host "Processed VM: $vmName." -ForegroundColor Green
}
<!--NeedCopy-->

    PS C:\Users\administrator.CELESTIALS\Downloads> .\Update-PVS-VMs.ps1
Ignoring VM: mo-PVS13804-02 which has TPM enabled.
Processed VM: simgr-sb.
<!--NeedCopy-->

Summary

Toggling the Secure Boot template in Hyper-V Gen 2 VMs through PowerShell is a supported way to reset the Secure Boot keys to the factory defaults for that template. This replaces the UEFI key store with the template’s pre-set trusted certificates, removing any previous customizations.

Updating Server 2019 to enable the new CA certificates

Windows Server 2019 is fully supported for the new 2023 Secure Boot certificates, but because it is an older OS, the update behavior is more conservative compared to Windows 11. While the certificates are included in the monthly Cumulative Updates for Server 2019 (specifically those released from May 2024 onwards), they are often not applied automatically to avoid potential boot issues on older hardware or virtual environments.

  • The “Support Status” for Server 2019 Physical servers running 2019 can receive the update, provided the server’s BIOS/firmware is modern enough to handle the 2023 CA.

    However, note that unlike Windows 11, which might “auto-update” once Microsoft gains “high confidence” in the hardware, Server 2019 typically requires an administrator-initiated trigger through the registry.

Trigger the update on Server 2019

If you have confirmed your Server 2019 VM is fully patched but the certificates are still the 2011 versions, you can manually trigger the deployment using the following steps:

  1. Set the Trigger Key: Open an elevated Command Prompt or PowerShell and run:

    reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x5944 /f
<!--NeedCopy-->

    The value 0x5944 tells Windows to deploy all new 2023 CAs and the new signed Boot Manager.

  2. Run the Scheduled Task: Windows uses a specific background task to process these certificate changes. You can start it immediately:

    Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
<!--NeedCopy-->
  3. Reboot: A restart is usually required for the Windows Boot Manager to switch to the version signed by the “Windows UEFI CA 2023.”

  4. Verification: After the reboot, run this PowerShell command to see if the 2023 CA is now in the allowed database (db):

    [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'
<!--NeedCopy-->
    • Returns True: You are protected and ready for the 2026 deadline.
    • Returns False: The update failed. This is common in Hyper-V if the VM’s “Secure Boot Template” is set incorrectly.
Windows Secure Boot certificate expiration and CA updates
April 28, 2026
Contributed by: 
C
April 28, 2026
Contributed by: 
C

In this article

Site feedback | Your privacy choices footer linkYour Privacy Choices | Privacy and legal terms | Cookie preferences | Consent settings | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.