A practical case-by-case guide (PCs, servers and virtual machines)
In June 2026, “legacy” Secure Boot certificates will expire. In business environments this does not usually translate into an immediate outage, but it can leave devices in a degraded security state and complicate compatibility with future signed components if the trust chain is not updated.
This guide provides a clear, actionable approach, broken down by scenarios (PCs, physical servers and VMs), with an inventory, pilot, rollout and verification plan. It also includes an operational workaround for lab/pilot use and a FAQ section at the end.
If you want help running a controlled plan without surprises, you can rely on our IT maintenance for businesses service and on cybersecurity for SMEs as a foundation to govern firmware changes, hardening and operational continuity.
5-step summary
If you need a quick read to turn this into an internal plan, here is the recommended flow. It is designed to minimise operational risk and avoid acting “blind” in production.
- Inventory: classify by PC / server / VM and by BIOS/Legacy vs UEFI + Secure Boot.
- Pilot: test with a representative group (PCs, 1 server per hardware family and 1–2 VMs per type).
- Pre-check fixes: up-to-date firmware/BIOS/UEFI, BitLocker management, and hypervisor compatibility for VMs.
- Phased rollout: from lower to higher criticality, with maintenance windows where applicable.
- Validation: events, a clean reboot and service verification (especially on critical servers and VMs).
What changes in 2026 and why it matters for businesses
Secure Boot is part of the UEFI boot process and validates that what runs at startup (the bootloader and related components) is signed by trusted authorities. The 2026 certificate expiration requires organisations to align devices and platforms with the most recent certificates to preserve boot integrity going forward.
In businesses, the typical risk is not “it stopped booting”, but a degraded security state and a higher likelihood of incidents when future updates, hardening, platform changes or large-scale rollouts are applied.
Recommended official source: Windows Secure Boot certificate expiration and CA updates (Microsoft)
Case 0: Not applicable (BIOS/Legacy)
This case helps you rule things out quickly and avoid spending time where it is not needed. If a device does not use UEFI, Secure Boot is not active and this change does not apply directly.
Applies to
- PCs, servers or VMs that boot in BIOS/Legacy mode (not UEFI).
- Environments where Secure Boot does not exist or cannot be enabled due to the platform.
Recommended action
- Record these as “BIOS/Legacy” in your inventory.
- Consider migrating to UEFI when appropriate (for standardisation and hardening), with testing.
Case 1: PCs
For workstations, the most efficient approach is to treat this as a controlled update project: pilot, validation and phased rollout. Usually the estate stabilises with Windows Update and up-to-date firmware, but it is worth anticipating BitLocker and older firmware.
Typical risks on PCs
- Out-of-date BIOS/UEFI or limited/full NVRAM.
- BitLocker and security policies that interfere with boot changes.
- Older devices with no firmware maintenance from the manufacturer.
Workaround for a pilot (PC)
This workaround is intended for lab or pilot use. The goal is to force the flow and confirm whether the device can apply the update without errors before scaling to phased rollouts.
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x5944 /fStart-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"Then reboot and validate. In some environments, more than one reboot may be required to complete the changes.
Validation (PC)
The quickest validation is to review events. If you see persistent NVRAM write errors, it usually points to firmware or device limitations.
- Path: Event Viewer > Applications and Services Logs > Microsoft > Windows > Hardware-Events > Admin
- Event ID 1: attempt to update a Secure Boot variable
- Event ID 2: error writing a new key to NVRAM (firmware/NVRAM/compatibility)
Case 2: Physical servers (on-prem)
On servers, the procedure is similar to PCs, but execution must be more disciplined: maintenance windows, rollback, role validation and, above all, dependency on the manufacturer’s firmware.
What changes compared to PCs
- Planned reboots and coordination with the business.
- High dependency on BIOS/UEFI and platform firmware.
- Post-reboot validation: roles (AD/SQL/RDS), storage, network and cluster if present.
Recommended plan for servers
- Inventory by model and BIOS/UEFI version.
- Update manufacturer firmware when required (before the change).
- Pilot: 1 server per hardware family.
- Phased rollout: secondary > critical.
- Validation: clean boot + services/roles/cluster OK.
If you need to align this kind of change with operational continuity, it often fits a IT systems management service to keep firmware, reboots, evidence and maintenance windows under control.
Case 3: Virtual machines (VMs)
VMs are the most “tricky” case. Even if the operating system is Windows and looks like a PC, the firmware is virtual and so is the NVRAM. If the platform does not allow Secure Boot variables to be written, the guest can fail even when fully up to date.
Why it can fail on VMs
- Restricted virtual NVRAM or write limitations.
- Virtual hardware / UEFI / Secure Boot compatibility not aligned.
- Hypervisor not patched or vendor guidance not applied.
Correct order of actions on VMs
- Review the hypervisor (patches and vendor recommendations).
- Review VM compatibility: virtual hardware, UEFI and Secure Boot.
- Pilot with 1–2 representative VMs per type.
- Apply on the guest (updates and, if needed, workaround).
- Validate events. If Event ID 2 persists, prioritise reviewing the hypervisor/virtual firmware.
Minimum recommended inventory
With this inventory you can segment quickly, plan phased rollouts and document evidence. It’s the minimum needed to avoid improvising in production and to audit what was changed, when, and with what outcome.
| Field | Example / values | Why it matters |
|---|---|---|
| Asset type | PC / Physical server / VM | Defines the plan and operational risk |
| Boot mode | BIOS/Legacy or UEFI | Determines whether Secure Boot applies |
| Secure Boot | Enabled / Disabled | Direct impact of the change |
| Vendor/model | Dell/HP/Lenovo… | Firmware dependency |
| BIOS/UEFI version | Exact version | Compatibility and NVRAM writes |
| Operating system | Windows 10/11, Server 2019/2022… | Update flow and support |
| BitLocker / encryption | Yes/No + policy | May affect boot |
| Hypervisor (VMs only) | ESXi/Proxmox/Hyper-V + version | Virtual firmware and NVRAM |
| Criticality | High/Medium/Low | Rollout order |
| Pilot result | OK / Warning / Error | Scale decision |
| Evidence | Event ID 1/2 + notes | Traceability and audit |
Checklist by asset type
This block is designed for support or systems teams to use as an execution guide. If you follow it, you reduce the likelihood of incidents and avoid making changes without evidence.
PC checklist
- Confirm UEFI + Secure Boot.
- Windows Update up to date.
- BIOS/UEFI on the vendor-recommended version.
- If BitLocker is enabled: plan suspension/control before the change.
- Pilot with workaround if needed.
- Validate events and reboot.
Physical server checklist
- Platform firmware up to date (BIOS/UEFI + controller where applicable).
- Maintenance window approved.
- Rollback defined (backup, rollback plan).
- Pilot by model/family.
- Validate roles/services/cluster after reboot.
VM checklist
- Hypervisor patched and aligned with vendor recommendations.
- VM compatibility reviewed (virtual hardware, UEFI and Secure Boot).
- Pilot by VM type.
- If Event ID 2 persists, review hypervisor/virtual firmware before pushing further on the guest.
Frequently asked questions (FAQ)
These questions are written so business users understand impact, priorities and how to approach it without unnecessary jargon. They also lend themselves to FAQ schema markup.
Will my devices stop booting on 1 June 2026?
It is not usually an immediate “blackout”. The typical risk is ending up in a degraded security state or running into future compatibility issues if the Secure Boot trust chain is not updated. That is why an inventory, pilot and controlled rollout are recommended.
Which devices are most exposed to incidents?
Those combining older firmware, limited NVRAM, sensitive encryption configurations (such as BitLocker), or virtualised environments where firmware/NVRAM depend on the hypervisor.
If a device is on BIOS/Legacy, do I need to do anything?
For this specific topic, Secure Boot does not apply. Still, BIOS/Legacy is often technical debt for standardisation and hardening, and it is worth planning a move to UEFI when feasible.
Why is it more sensitive on servers than on PCs?
Because reboots and validation directly affect service continuity. In addition, server vendor firmware is often decisive, and you must validate roles, storage, networking and any cluster after applying changes.
Why can VMs fail even if the operating system is up to date?
Because firmware and NVRAM can be limited or controlled by the hypervisor. If the guest cannot write Secure Boot variables, you will see errors (for example, Event ID 2). In that case, the fix is usually “below”: hypervisor patches, compatibility and virtual firmware.
Should I apply the workaround to every device?
Not as a first option. The sensible approach is to use it in a pilot to validate behaviour and apply it only where needed. In most environments, the priority is keeping the operating system and firmware up to date and rolling out in phases.
What evidence should we keep for internal control?
UEFI/Secure Boot status per device, the application date (pilot/rollout wave), BIOS/UEFI or hypervisor version, and exported/screenshotted relevant events (especially if there were errors and remediation).
Next steps
If you want to tackle this change without improvising, the ideal approach is to run an inventory, a pilot and a phased rollout with evidence. This reduces operational risk and prevents incidents caused by firmware, encryption or virtualisation compatibility.
We can help you define the plan and execute it across PCs, servers and VMs with maintenance windows and change control through our IT systems management service.
