Event details
274 Comments
I must have a thousand questions. I'm making one comment per question as that seems reasonable. Posted in no particular order. As of 2026-02-26 I have 22 questions.
I typed up all these questions not knowing there was a February AMA. I'll have to watch that later to see if any of my questions are answered there.
---
Should admins be considering anything with regard to secure boot as it pertains to backup and recovery or system archival procedures (how do we restore and boot a backup in 5 years time if the 2011 keys cease to be trusted)? Will we need to accept a lower security posture in such cases? Will Microsoft backport or provide newly signed bootmgr updates to unsupported versions of Windows so that the Windows secure boot process can be maintained long-term? Is Microsoft working with partners (Veeam, Cohesity, Rubrik, et al) to consider recovery implications? Or will IT pros have to embrace managing our own secure boot keys in such use cases?
I must have a thousand questions. I'm making one comment per question as that seems reasonable. Posted in no particular order. As of 2026-02-26 I have 22 questions.
I typed up all these questions not knowing there was a February AMA. I'll have to watch that later to see if any of my questions are answered there.
---
(Anecdote) My system required bitlocker recovery on the reboot following the first TPM-WMI 1808 message being logged. Is Microsoft tracking Bitlocker and TPM events related to bitlocker recovery (e.g. IDs 24652, 24658, 24638) as part of telemetry and using that to inform how fast they rollout the key updates?
I must have a thousand questions. I'm making one comment per question as that seems reasonable. Posted in no particular order. As of 2026-02-26 I have 22 questions.
I typed up all these questions not knowing there was a February AMA. I'll have to watch that later to see if any of my questions are answered there.
---
If I understand the nature of the KEK correctly, it's the key that is far more difficult to update than the CAs installed in the DB/DBX (which are signed by the KEK). Why doesn't Microsoft rotate out these "lowest" bootmgr signing certs more frequently? It would seem that as long as machines are getting KEK-signed DB/DBX updates frequently enough that Microsoft could replace these CAs way faster than once every 10 years.
The DBX is updated when necessary to revoke known bootkit hashes. The DB doesn't need to be updated as long as the certificates are still valid (to allow signing boot managers). In addition, the latest boot loaders implement a version check to prevent loading former versions. The SVN update appends a fake hash in the DBX that identifies a specific minimum version of a specific component (such as bootmgfw.efi).
Thanks for the reply.
"The DB doesn't need to be updated as long as the certificates are still valid (to allow signing boot managers)."
I think you've missed the point I was trying to make. I'm trying to point out that if MS commissions keypairs more regularly and gets those deployed out sooner than in this case, we can be more prepared for expirations like this rather than still having all these conversations 4 months before expiry.
It's great that MS commissioned new keys at 80% of the lifecycle of the original 2011 keys but they seemed to wait until mid-2025 to start thinking about deploying the new keys to all pre-2023 devices. Seems to lack planning.
I must have a thousand questions. I'm making one comment per question as that seems reasonable. Posted in no particular order. As of 2026-02-26 I have 22 questions.
I typed up all these questions not knowing there was a February AMA. I'll have to watch that later to see if any of my questions are answered there.
---
Can Microsoft please create a publicly (and regularly updated) database where admins can look up the bucketIDs and confidence levels to compare what should be happening on our systems compared to what is happening? Or publish instructions on how admins can query the database "on disk" (from LCU)? If a breakdown on CA-update success vs KEK-update success could be given too that'd be great. I assume the former has more reliable success than the latter.
---
Edit: I noticed someone (I think a MS FTE) started open sourcing some data on github.
I would like answer to two questions:
- Clear impact on what happens if we only apply the Windows updates for certificates and not the OEM updates. From my understanding, the SB certificates will be updated but if OEM firmware isn't updated, then the only impact is that in case of BIOS/SB Keys reset, the old keys will return. But this alone doesn't mandate BIOS updates to hundreds and hundreds of devices.
- When will the Intune 65000 error will be fixed in the respective policy? It is mentioned to be fixed by Feb 27 but we are still seeing this.
Thanks,
Prabhakar_MSFTMicrosoft
On #1, you have called out correctly on what happens if BIOS is reset to factory defaults. If device moves back to old certs, it will result in device not-trust new boot manager due to absence of 2023 certificate. Device in this situation can be recovered using SecureBootRecovery.efi app . Steps to recover from this condition is published at
#2 - We are aware of another issue which will be addressed in April update. Can you share Windows version (Snapshot of WinVer) where you are observing the issue?
I'd like clarity on who (MS or OEM) has responsibility for what in this update. From what I gather both have to be involved to get it done, but even then the user may have to do some manual work. It seems way to complicated and unreliable for something Windows is trying to enforce on everyone.
"I'd like clarity on who (MS or OEM) has responsibility for what in this update"
The best TL;DR I can give is this:
- UEFI is a specification, not a standard. UEFI allows some of these updates to be done, but the implementations of those specifications is going to differ from vendor to vendor. Not to mention, bugs exist.
- The KEK updates MUST be signed by each vendor's PK. MS doesn't have the PK, each OEM is sovereign over their PK.
- Look up the secureboot_objects github repo for more.
- Therefore, KEK updates take two to tango - OEM and Microsoft.
- KEK updates rely on the firmware implementing the specs reliably.
- As with all software, MS strongly recommends updating firmware to the latest version to ensure any bugs in the KEK updates are avoided.
- The DB and DBX updates (installing/removing the signing CAs) are signed by Microsoft's KEK.
- Microsoft is the only dancer, but again, bugs can exist which might prevent reliable DB and DBX updates on each device.
- DB/DBX updates rely on the firmware implementing the specs reliably.
- As with all software, MS strongly recommends updating firmware to the latest version to ensure any bugs in the DB/DBX updates are avoided.
- The bootloaders are signed by Microsoft's CAs.
- Microsoft is the only dancer.
Because bugs exist, MS gives admins a decent amount of control to roll things out at their own pace (except by default high confidence devices/buckets).
If you're running devices (including VM hardware) beyond it's reasonable/supported lifespan/lifecycle, then there's not much anyone is going to do for you. Upgrade.
I must have a thousand questions. I'm making one comment per question as that seems reasonable. Posted in no particular order. As of 2026-02-25 I have 22 questions.
I typed up all these questions not knowing there was a February AMA. I'll have to watch that later to see if any of my questions are answered there.
---
Microsoft has said in many places that they're rolling out the updates to Home and Pro systems but this doesn't explain how Windows Server systems will get these updates rolled out. Due to hardware differences between (most) uses of Windows client and (most) uses of Windows server, Windows client SKU CA/KEK update telemetry won't help inform Windows server SKU CA/KEK updates. What's the phasing plan for WS?
---
Edit: MS kinda covered this question in the February AMA at timestamp 27:22, YouTube ID EscGJTKHPdw.
- Arden_White
Windows Server uses a different rollout model than Windows client because the telemetry signals that enable safe, phased deployment on Home and Pro SKUs do not meaningfully exist or apply in server environments. Windows Server systems commonly have limited or disabled telemetry, and client‑SKU telemetry cannot be used as a proxy to assess risk or readiness for server platforms. As a result, Secure Boot CA and KEK updates for Windows Server are not rolled out through Controlled Feature Rollout or confidence‑based phasing. Instead, Microsoft delivers the required update components through cumulative updates, and administrators explicitly initiate certificate updates on servers that need them, aligned with their own validation and maintenance processes.
Thanks for the response.
Arden_White towards the end of today's AMA you mentioned that MSFT is hoping to release in the near future a bootable utility to update systems. I have two questions:
- Will this work on server platforms for updating the KEK/DB/DBX?
- How will customers be able to subscribe to new releases/updates of this utility (as presumably the update binaries get updated over time)?
I must have a thousand questions. I'm making one comment per question as that seems reasonable. Posted in no particular order. As of 2026-02-25 I have 22 questions.
I typed up all these questions not knowing there was a February AMA. I'll have to watch that later to see if any of my questions are answered there.
---
Microsoft has said in many places that they're rolling out the updates to Home and Pro systems before Enterprise versions of Windows. But MS hasn't been clear on how fast or slow they're releasing the updates to these device populations. Is it a dice roll on each individual device? Are any "randomized updates" increasing with each LCU or with time-bomb logic? Is it a single gate for an entire bucket all at once? Something else? All of the above?
How are buckets transitioning to high confidence? Microsoft says they need to see enough devices take the update before they mark a device/bucket high confidence, so is this a lottery? Can't have the latter without the former.
---
Edit: I found this PDF which explains the transition in a bit more detail. Page/slide 10. I assume "WIP" means Windows Insider Program.
I must have a thousand questions. I'm making one comment per question as that seems reasonable. Posted in no particular order. As of 2026-02-25 I have 22 questions.
I typed up all these questions not knowing there was a February AMA. I'll have to watch that later to see if any of my questions are answered there.
---
A lot of the discussion has been around how Windows is helping roll out these updates but please expand on how Microsoft is helping our open-source (Linux et al) friends in ensuring these updates are happening ecosystem-wide.
I must have a thousand questions. I'm making one comment per question as that seems reasonable. Posted in no particular order. As of 2026-02-25 I have 22 questions.
I typed up all these questions not knowing there was a February AMA. I'll have to watch that later to see if any of my questions are answered there.
---
Why did the Intune secure boot readiness report only release in 2026? Should've been deployed years ago.
