Event details
281 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.
---
I think it was Scott that said (in the Dec AMA) the 2011KEK key can no longer be used to sign updates post-expiration. If a device hasn't received any updates (CA or KEK) by expiration, is it true that device will *first* need to get the (PK-signed) 2023KEK installed and *second* install the (2023KEK-signed) CA into the DB list before bootmgr (or any boot loader for that matter) signed by 2023 CAs will boot? Is that the correct order of operations?
Both updates are independent and there is no required order.
The KEK update (needs to be signed by the OEM because they own the PK) is required before June 2026. Microsoft will stop shipping security updates signed with 'Microsoft Corporation KEK CA 2011' after June because that is when the certificate expires. So DB/DBX updates shipped afterwards will only be signed by 'Microsoft Corporation KEK 2K CA 2023'.
The DB update (signed by 'Microsoft Corporation KEK CA 2011' and probably also by 'Microsoft Corporation KEK 2K CA 2023') is required to be able to boot Windows on a boot manager signed by 'Windows UEFI CA 2023', and optionally some other specific components. There is technically no set date for updating the boot manager, but it helps fully mitigate BlackLotus and other past vulnerabilities. In addition, if the boot manager needs to be patched in the future, it will only be released as a 2023-signed version. Thus the DB update will be required to support the new secure version.The DB update is intentionally signed only by the old KEK, since machines that have the new KEK only will already have the new DB as well. And it prevents attackers from installing the 2023 third-party certificate on machines that only have the 2023 KEK and 2023 Windows certificate (no 2011 KEK) by a signed variable update.
Still, despite being said that Microsoft does not automatically apply 2023 third-party certificates to systems that do not have 2011 third-party certificates "for security reasons", nobody stops an attacker who has local administrative access from doing so (by applying the published DB updates signed by the 2011 KEK).
So those security reasons are pretty moot as long as the machine has the 2011 KEK.
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.
---
How will Windows Update behavior change post-expiration on devices that haven't trusted the 2023 keys? Will they continue to install LCUs normally *except* for boot-critical components? Or fail to take LCUs altogether? Will this be messaged to users/admins somehow (Defender perhaps)? Will this prevent milestone updates (i.e. prevent 25H2 -> 26H2)?
- Pearl-Angeles
Community Manager
Thanks for your participation in this AMA. Your question was answered at 57:36.
They will continue working but will not take Secure Boot/boot manager-specific security updates. This is documented at :
https://support.microsoft.com/en-us/topic/when-secure-boot-certificates-expire-on-windows-devices-c83b6afd-a2b6-43c6-938e-57046c80c1c2
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.
