You’re not missing a hidden “Azure-only” button. Microsoft’s guidance for virtualized environments is basically:

• The virtualization provider (Azure/AWS/Hyper-V/VMware) can ship an update that bakes the new certificates into the virtual firmware (helpful mainly for new VMs).
• For long-lived existing VMs, the update can be applied from inside Windows, like any other device, if the virtualized firmware supports Secure Boot variable updates. (see https://support.microsoft.com/en-us/topic/frequently-asked-questions-about-the-secure-boot-update-process-b34bf675-b03a-4d34-b689-98ec117c7818)

That’s why the playbook doesn’t present a special “mass update for Azure VMs” section: the mass rollout mechanism is your fleet management layer, not Azure itself.

However, on Trusted Launch/Gen2 VMs, Secure Boot is implemented in platform firmware. Azure controls that firmware and already includes Microsoft-owned trusted certificates in the UEFI firmware for Windows VMs. So Azure can update firmware defaults for new VMs as part of platform evolution, matching the “provider update” path above.

Finally, Microsoft is delivering the Secure Boot certificate servicing through Windows monthly updates, and IT is still responsible for ensuring the fleet is updated (even when Microsoft “assists”).
For IT-managed devices, Microsoft documents multiple deployment methods (registry keys, GPO, Intune, WinCS). Do you use any of these?

If you tell me which Azure VM type you’re talking about (AVD session hosts? Windows Server workloads? VMSS?), I can suggest the cleanest rollout pattern and how to monitor success states (including the “reboot required” phase) without babysitting thousands of machines.