Secure Boot 2026: Why It Hits Provisioning Environments Harder

Anyone who uses Citrix Provisioning is familiar with the division of labor: The tool creates the vDisk—but the It is the customer's responsibility to ensure that the surrounding area is clean. And that's exactly where some pitfalls are lurking that not every administrator is aware of. The latest one is called Secure Boot, and it has an expiration date.

The 2011 Secure Boot certificates are expiring

Microsoft will replace the entire Secure Boot certificate chain in 2026. Two of the three certificates issued in 2011 have already expired: the KEK CA on June 24 and the UEFI CA on June 27, 2026. The third, the Windows Production PCA 2011, will follow on October 19, 2026. It will be replaced by the 2023 generation, which must be installed in the UEFI firmware of each individual machine via Windows Update.

For traditional PCs, this is a rollout just like any other. For provisioning environments, however, it’s a trap waiting to happen—so much so that Citrix has published two separate known-issue articles on the topic (CTX696455 for VMware and XenServer, CTX696473 for Hyper-V). The crux of both: PVS targets with Secure Boot will no longer boot after Windows updates have been applied to the vDisk.

Why Provisioning Is Particularly Affected

The mechanism behind this is easy to explain—and typical of PVS. The Windows Update places a boot manager signed with the 2023-CA certificate into the master image, and thus into the vDisk. This vDisk is streamed to dozens or hundreds of target VMs. Each of these VMs verifies the boot manager against the Certificates in its own UEFI firmware—which is based on a template from ages ago. If it doesn't recognize the 2023 CA, it won't boot. The farm is down.

A single PC can repair itself via Windows Update. A provisioned farm cannot—because the image is frozen, and the firmware for each VM is managed by the hypervisor. It is precisely this discrepancy between „one image“ and „a hundred firmware states“ that makes this issue so dangerous for PVS environments.

To be honest: This isn't a PVS Forge issue

And here we are back to the division of labor. An imaging tool creates a clean vDisk from the master target—this works flawlessly even with Secure Boot. The firmware of the target VMs, the hypervisor version, the VM templates: All of that is up to the customer and their hypervisor vendor. No imaging tool in the world can influence that.

But: Who, if not the tool that runs on the master before every imaging process anyway, should warn the administrator in a timely manner?

Check, warn, fix

That is exactly PVS Forge's approach—every time imaging is started, for every master target, without any configuration.

To check means: Does the master even run with Secure Boot enabled? Are the 2023 certificates already in its firmware database and in the KEK? Systems without UEFI or Secure Boot are silently skipped—no false alarms.

To warn means: If the certificates are missing, a clear message appears with an explanation, the Citrix part numbers, and a template for manual resolution.

And to differentiate means: Distinguish what the real issue is. If the 2023-CA is missing from the database, a boot failure is likely—serious warning. If only the KEK is missing, future certificate updates will be blocked—note. And if the firmware simply refuses the update, PVS Forge makes it clear: This is a hypervisor issue; the only solution is a hypervisor update, not guest software.

The Single Checkbox Fix

If you prefer a more convenient approach, just enable a single option: „Fix Secure Boot Certificates (2023 Rollout)„. Then, before imaging, PVS Forge sets the official Microsoft opt-in on the master, triggers Windows’ own update task, and restarts the master target. Windows then applies the certificates wherever the platform allows it—and because the trigger is included in the vDisk, the streamed devices can also adopt the certificates into their own firmware during boot, provided the hypervisor supports this.

Important to note: The fix uses only the documented Microsoft mechanism, is repeatable, and only takes effect if something is actually missing. Even if the hypervisor firmware doesn't cooperate, it's harmless—nothing bad will happen, and the message will specify the cause.

Boundaries — and Why We Should Name Them

PVS Forge can do a lot, but not everything, and it’s more honest to say so. The hypervisor must support the 2023 chain (such as VMware vSphere 8.0 U3h or newer, XenServer 8.4, or the latest Hyper-V on Windows Server 2019 or newer). Older versions refuse to update the firmware—no guest software can bypass this. Updating the VM firmware on existing targets is a hypervisor task. And Citrix Provisioning itself also requires a current version to support the new chain.

A good tool provides timely warnings, fixes whatever can be fixed within the guest, and points to the right spot when the problem lies elsewhere. An imaging tool cannot—and should not—promise more than that.

By the way: the same principle applies to DNS and DHCP

Secure Boot is just the most recent example of this philosophy. Every PVS administrator is familiar with a second example, often without knowing the cause: Streamed devices carry the DNS and DHCP identity of the master target in their image—and may delete the master’s DNS entry or request its old DHCP lease during boot. The proper way to handle this is to clean up this registration state immediately before sealing: DNS cleanup is safe by default because Windows rebuilds the state anyway; DHCP cleanup is a deliberate option to prevent address conflicts after the rollout.

Conclusion

The 2026 Secure Boot transition is not just a theory. Two certificates have expired, the third will expire in October, and Citrix has the Boat breakdowns have already been documented. Provisioned environments are at a structural disadvantage because an image encounters many different firmware states.

PVS Forge does exactly what it’s supposed to do: It checks at every opportunity, provides clear warnings, resolves issues that can be fixed with a checkbox—and is honest about the rest. The Secure Boot check isn’t a special case here, but just one of many examples. It’s all the little built-in features—from cleaning up DNS/DHCP to certificate warnings—that make the administrator’s life easier right out of the box.


PVS Forge checks the Secure Boot certificate chain during every imaging process out-of-the-box, issues a warning via a pop-up message, and resolves the Microsoft opt-in via a checkbox where the platform allows it—and clearly indicates when the issue lies with the hypervisor. Practical expertise, built right into the product.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top