What should we actually be checking for the UEFI certificate changes?

First, separate certificate expiration from an immediate boot failure. An expiration date does not by itself mean every machine stops starting on that day. The practical concern is whether devices can receive and apply the newer Secure Boot trust data and boot components, including through future servicing.

Inventory the Secure Boot state and relevant certificate updates across physical machines and virtual machines. Test the intended update path on representative hardware, and confirm the updated trust data is actually present rather than assuming a routine OS or device-management update handled it.

Don’t make this a BIOS-only project, but don’t assume Windows updates cover every case either. Some systems may need firmware support or a vendor-specific procedure, while others can receive changes through the operating system. The right answer depends on the model, firmware, and deployment path.

Check vendor guidance for the hardware you own, then pilot the update and recovery steps before scaling up. Keep a record of devices that are out of support or missing a workable update route, so those are visible as lifecycle risks instead of surprises.

Start with a calm inventory. Find out which Windows devices actually have Secure Boot enabled, which certificate state they report, and whether they have pending updates. A managed-device dashboard showing that updates are current may not prove the Secure Boot certificates have changed, so verify the result directly.

Also include virtual machines. Their Secure Boot configuration and update process can differ from physical endpoints, and a fleet with a lot of VMs is easy to overlook if the work is assigned only to desktop support.

Test for the failure mode, not just whether an update installed. A firmware or certificate update that leaves the boot chain in an unexpected state can make recovery stressful. Use a small pilot, document how to restore boot access, and avoid pushing a broad change until the pilot has restarted successfully.

If a machine does fail to boot, changing Secure Boot settings may be part of a recovery path, but treat that as a controlled troubleshooting step rather than a fleet-wide workaround.

The dates are worth tracking, but they are not a reason to declare older computers unusable today. Some older systems may still receive relevant firmware updates, while others may not. Check support for each model and make a plan for machines that cannot be updated.

For unsupported devices, document the exposure and decide whether they can be replaced, isolated, or kept in service with an accepted risk. Don’t assume the same answer applies to every vendor or model.