๐ Secure Bits ๐ก
๐ฆ๐ฒ๐ฐ๐๐ฟ๐ฒ ๐ฏ๐ผ๐ผ๐๐ ๐ฐ๐ฒ๐ฟ๐๐ถ๐ณ๐ถ๐ฐ๐ฎ๐๐ฒ๐ ๐ฎ๐ฟ๐ฒ ๐ฒ๐
๐ฝ๐ถ๐ฟ๐ถ๐ป๐ด ๐ถ๐ป ๐๐๐ป๐ฒ ๐ฎ๐ฌ๐ฎ๐ฒย – ๐บ๐ฎ๐ป๐๐ฎ๐น ๐๐๐ฒ๐ฝ๐ ๐ฎ๐ฟ๐ฒ ๐ฟ๐ฒ๐พ๐๐ถ๐ฟ๐ฒ๐ฑ ๐ฑ๐ต. 1
Microsoft says many Windows client devices may update automatically, butย Windows Server requires manual action.
I assumed this type of operation would be ๐๐๐ฟ๐ฎ๐ถ๐ด๐ต๐๐ณ๐ผ๐ฟ๐๐ฎ๐ฟ๐ฑ.
โ It wasnโt.
๐๐ถ๐๐ฐ๐น๐ฎ๐ถ๐บ๐ฒ๐ฟ: This is just a record of how I proceeded step by step in my own environment and what I observed. Results may differ, and Iโm not finished with the full remediation yet.
โธป
๐ ๐๐ถ๐ฟ๐๐ ๐ข๐ฏ๐๐ฒ๐ฟ๐๐ฎ๐๐ถ๐ผ๐ป๐
As promised By Microsoft, my Windows desktops updated automatically. But you can still encounter errors and you might end up doing similar procedure to what is below.
Example below is from WS 2022 (VMware – VM version 19). And yesโฆ in a VM theย virtual firmwareย matters (VM hardware version / NVRAM state / hypervisor behavior). Microsoft warns firmware issues can block Secure Boot certificate updates.
โธป
๐ ๐ฆ๐๐ฒ๐ฝ ๐ญ โ ๐๐ต๐ฒ๐ฐ๐ธ ๐๐๐ฒ๐ป๐ ๐๐ผ๐ด๐
Look in System log for Secure Boot variable events:
โข 1808 – Certificates successfully applied
โข 1801 – Certificates not applied to firmware
โข 1796 – Unexpected error during update step
I saw 1801 โ meaning nothing had actually been applied yet.
โธป
๐ ๐ฆ๐๐ฒ๐ฝ ๐ฎ โ ๐๐ต๐ฒ๐ฐ๐ธ ๐จ๐ฝ๐ฑ๐ฎ๐๐ฒ ๐ฆ๐๐ฎ๐๐ฒ
I ran Microsoftโs detection script:
โข Secure Boot enabled
โข Nothing initiated
โข Scheduled task exists
The update mechanism runs via scheduled task:
\Microsoft\Windows\PI\Secure-Boot-Update
If your server hasnโt been patched recently, this task might not even exist.
My VM was patched until 01/2026.
โธป
๐ง ๐ฆ๐๐ฒ๐ฝ ๐ฏ โ ๐๐ป๐ฎ๐ฏ๐น๐ฒ ๐๐ฒ๐ฝ๐น๐ผ๐๐บ๐ฒ๐ป๐ ๐๐ถ๐ฎ ๐๐ฃ๐ข
I had to install updated Administrative Templates as I was missing the SecureBoot.admx. I then enabled:
โข Enable Secure Boot Certificate Deployment
After:
โข gpupdate
โข Registry changes appeared
โข Script confirmed deployment enabled
Then I manually triggered the task. It also runs after reboot and every 12 hours.
It requested a reboot.
โธป
โ ๐ฆ๐๐ฒ๐ฝ ๐ฐ โ ๐๐ฎ๐ถ๐น๐๐ฟ๐ฒ
After restart:
โข Event 1796
โข Step: KEK 2023
โข Error: Invalid access to memory location
If everything goes well, it ends up here for you with event ID 1808. But not for me, this is where things became more complicated.
โธป
โ ๏ธ Virtualization Dependency (in my case – VMware)
Broadcom published guidance that some Secure Boot update failures in VMware VMs require remediation at the VM firmware / UEFI Secure Boot variable level, not just inside Windows.
In some cases, their workaround involves:
โก Manually updating the Platform Key (PK) in the VM via UEFI setup.
Yes. You read that right. Enterprise-grade experience, right?
They mention theyโre working on a more automated solution, fingers crossed.
โธป
This is far more complex than it looks on paper and I feel like this is going to be an issue for many administrators.
To be continuedโฆ
