1. Regardless which way you are choosing (Intune, Group Policy, manual), each way will ultimately result in setting the same registry key. So there should not be any "Best way" for triggering the job. Probably the "Best way" is to actually monitor the reasons why adoption rate is not going up (e.g. errors in event log, if any) to determine whether the devices do not get compliant due to  hardware incompatibilities or due to a missing restart)
2. The May Patch Tuesday will obviously provide one more chance for a restart, but I doubt it will guarantee resolution of anything. In case the devices have a known hardware issue (also present in the latest firmware version) preventing the update running automatically, this will not "magically" make the updates work. But there should be a sufficient amount of error information in the event log to diagnose this and to decide whether any actions other than waiting are needed.

Can we expect an answer to that question?

As a very general summary, this is roughly correct.

• This does not only refer to the KEK update, but updates of all the Secure Boot keys. For KEK, there also needs to be a signature by the vendor of your firmware (its Platform Key) submitted to Microsoft so that the KEK can be updated.
• Whether a device is considered managed or not depends not only on whether WSUS is used, but also whether the device is domain-joined and whether telemetry is enabled and actually usable, and maybe other factors
• All the mentioned registry options (both for opting in via Available updates and for opting out) are available on all devices, managed or not
• The main difference between managed and unmanaged devices is that unmanaged devices can also receive their update via Controlled Feature Rollout (if they are lucky/unlucky and telemetry suggests that it should be tried), resulting in potentially being updated before the LCU that sets them to high confidence reaches them. However, there is no way to enforce or trigger whether you will be Chosen a Guinea Pig for Microsoft or not (if you are an unmanaged device)
• In case Microsoft considers your device managed, but you have telemetry enabled and explicitly want your device to be used as a Guinea Pig, you can set MicrosoftUpdateManagedOptIn registry key. This only has an effect if your device is considered managed.

Your question boils down to whether a VM snapshot will include a copy of the UEFI variables and/or UEFI NVRAM. I cannot answer this question for all available virtualization solutions, but for those I have been using (Hyper-V, Virt-ualBox, and QEMU/KVM based ones like Proxmox) I can confirm that at least in their latest version, the VM snapshot includes all of this, so it is sufficient to create a VM snapshot to protect against incorrect Secure Boot configuration changes.

That being said, I don't know of any likely scenario where a Secure Boot certificate update can screw your VM so badly that you need to revert to a previous snapshot. In case you use BitLocker in the VM, make sure to have your Recovery Key handy just in case.

(There used to be an older version of Vir-tualBox where not all UEFI variables - like dual-boot configurations - were part of the snapshot, which could cause confusion when restoring snapshots after an OS install - not only related to Secure Boot settings. But I believe this was before Vir-tualBox supported Secure Boot for VMs).

[Ouch, naming of competitor products is not allowed in this community?]

I assume all those machines have Secure Boot enabled? If not, there is no option nor need to update the secure boot certs.

If Secure Boot is enabled, not updating them (on both) will have the same effect as on any other (physical or virtual) machine: The bootloader will remain stuck on the June 2026 version and Secure boot blacklist will not get updated. So an attacker who gets admin access on either the host or the guests could install a bootkit on the (host or guest) machine they had access to once there is any public exploit for that bootloader or any other blacklisted bootloader. In any case the system will continue working and will still receive security updates for all other Windows components.

Let me guess, the device came with all the 2023 certificates from the factory already (Or it has been updated before the OS got reinstalled)? In that case it can happen that the key has not been created at all. I cannot tell what exactly causes the key not being created, but everything is fine if the certificates are there.

There is a section about that in the Secure Boot Troubleshooting document:

https://support.microsoft.com/en-us/topic/secure-boot-troubleshooting-guide-5d1bf6b4-7972-455a-a421-0184f1e1ed7d#ID0ELBP-button

For Scenario 1 (bug in firmware implementation), you cannot reliably detect it. If you have identified affected firmware vendors/versions, you can mitigate it by disabling or suspending Bitlocker before applying the Secure Boot updates, restart another time when they have been successfully applied, and re-enable Bitlocker. (Note that Microsoft does not endorse increasing your attack surface by disabling or suspending Bitlocker, you will have to do your own risk assessment on that).

For Scenario 2 (There is a PXE server early in the boot sequence which will most of the time do nothing more than trigger BOOTNEXT, and uses a bootloader signed by the 2011 certificates), you can mitigate it by moving Windows Boot Manager to spot 1 in your boot sequence or temporarily blacklist the MAC addresses of your devices from the PXE server's DHCP configuration so that PXE boot is not attempted or uses a bootloader signed by the 2023 certificate.

But in general, there is no reliable way to predict whether Measure Boot TPM resealing is working on your current firmware or not, otherwise Microsoft would probably add a safeguard lock for that :-)

Have you seen today's admin center notice "Users might be prompted into BitLocker recovery screen on device restart" that mentions "Connected Standby" devices, supposedly fixed in this month's (April 2026) LCU? Small possibility it could be related...

It does not matter whether the certs have already expired, it only matters if you already got the 2023 bootloader. If the new bootloader is already installed (which started happening for some machines with February 2026 LCU) and you reset to system default, your system will not boot but show a secure boot error. You will then need to boot from a USB key with securebootrecovery.efi which will update the one certificate needed to get the system booting again (Windows 2023 certificate in DB), the rest will be fixed from the booted system.

See "Device fails to boot after resetting Secure Boot" in the Troubleshooting Guide: 

https://support.microsoft.com/en-us/topic/secure-boot-troubleshooting-guide-5d1bf6b4-7972-455a-a421-0184f1e1ed7d#bkmk_common_failure_scenarios_and_resolutions

I'm curious about an updated ADK as well as official guidance on how to address PXE w/ WDS:

"A new checkbox, Use Windows Boot Loader signed with Windows UEFI CA 2023, is available in the Data Source tab of boot image properties. When enabled, it updates the boot image to use the boot loader signed with Windows UEFI CA 2023. The checkbox automates the mitigation steps described in KB5025885.

The new functionality only works on WDS-Less PXE-enabled Distribution Points."

Importantly, related to this: is there specifically a way to ensure that newly-imaged and re-imaged computers get deployed with the new 2023 cert in their UEFI DB and applied to their boot manager as part of a CM Task Sequence, particularly if they do not already have the 2023 cert in their UEFI DB?

I might expect to continue using the older 2011 cert on the PXE boot image for some time to accommodate the transition, but want to avoid deploying new endpoints with outdated certs, or needing a supplemental update post-deployment with added restarts to address it.