Event details
It's time for our second Ask Microsoft Anything (AMA) about updating Secure Boot certificates on your Windows devices before they expire in June of 2026. If you've already bookmarked Secure Boot play...
Heather_Poulsen
Updated Feb 12, 2026
mihi
Jan 28, 2026Copper Contributor
Three questions related to Secure Boot:
- When updating Secure Boot variables (like this db update but also on some older dbx updates), some older firmware has problems due to maximum variable size or size of variable store. UEFI exposes this information via RT:QueryVariableInfo, and when booting Linux, you can see by querying free space of efivarfs. Is there a way from Windows userspace (e.g. Powershell or a NTDLL exported function) to get this information? Max variable length, max variable store, remaining variable store.
- When applying the hardening measures for Black Lotus and adding SVN values to dbx, some older versions of bootmgfw.efi deny booting due to SVN mismatch. This is by design. BUT: When you boot from some recovery media that comes with its own loader that sets its own security protocol file authentication callback (like shim does), to use a fixed set of hashes, and bypasses DBX that way, and chainload this (whitelisted) bootmgfw.efi, the SVN values are still checked in DBX and deny booting. Is this by design? If yes, what is the preferred way to set up such media? Try to remove the signature from bootmgfw and patch the check out? Or use an old version of bootmgfw that does not check SVN yet (like one from 2017 I found on an old Win10 install disk)? Always having the latest bootmgfw on these media is not an option for us, and we'd like to apply the SVN hardenings for "normal" boots (not via this recovery media) if possible.
- The current certificate update will install the replacements for the Third Party EFI CA to DB only if the old Third Party EFI CA is included in DB. However, as Microsoft published signed variable updates for adding them to DB on every system that has the old KEK, nothing prevents an adversary from doing so. Is this taken into account when evaluating security implications of adding anything to DBX which is signed by these keys (nothing revoked yet, but in the future?). E.g. by applying these DBX updates when old KEK is in DB, even when new Third party EFI CA replacements are not there? Or by adding those replacements to DBX at a later stage if not present in DB?
I am aware you probably cannot answer them by heart, therefore I'll give you a week advance notice :)
mihi
Feb 05, 2026Copper Contributor
I now tried to answer as many of other people's questions as possible, in the hope that someone answers mine too in return...