https://youtu.be/_AwzaZmRNsI?si=U_xxdMVhz9cFyySj

At work we triggered the update using the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\AvailableUpdates set to 0x5944 method; and it honestly went surprisingly well. That said; it's 100% thinkpads and enterprise-line Dells here; and I have the unpleasant suspicion that the 'consumer motherboard that maybe gets an update if AGESA needs to be bumped' segment has some...under-tested DBX update functionality.

We've also had a veritable torrent of WU-delivered UEFI capsule BIOS updates go out; so the OEMs seem to be doing things on their end as well.

Luckily, to the best I've been able to pin anyone down on the question, failure to update just means not being protected according to what secure boot is designed to do, rather than the system just not booting; so we shouldn't have too large an epidemic of random home wintendos just falling over and dying; and realistically home users don't exactly //

just had to check for these in powershell:

$([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbdefault).bytes) -match 'Windows UEFI CA 2023')
and
$([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023')$([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023')

depending on which DB we have it stored (let me know if you know any other place). //

This script works pretty well if you don't know how to do it for yourself, or in your corporate environment. https://github.com/anomixer/Update-SecureBootCert