Event details
220 Comments
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
Microsoft
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.
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 is leading the rollout of these new certificates but even Hyper-V (at time of writing) won't support the KEK updates until March at the earliest. Why does Microsoft seem unprepared for these updates at the first-party level? Doesn't this compromise the "secure by default" mission? If Microsoft isn't keeping their own platform up to date, why would we expect all other OEMs will be ready in time for the expiration dates?
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.
---
Please expand on the role of "default" vs "active" secure boot variables, what the general practice of firmware vendors is, and what this means for IT pros.
---
Edit: MS covered this question well in the February AMA at timestamp 15:44, YouTube ID EscGJTKHPdw.
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.
---
The promise of UEFI was to make things more standardized and easy. Why then does this seem like such a complicated update with so many moving parts? Does it boil down to things like OEMs being ... frugal ... on how much NVRAM they install on systems or taking too many liberties with the specs?
It boils down into OEMs being frugal, yes. But not about hardware, but about developer time. I've seen this since the very first Secure Boot capable devices, that people implement parts of the spec, and they just test if Windows boots with it. If yes, problem solved. Nobody tested certificate updates at that time. Or actually testing compliance to the spec.
Same for UEFI in general - there are some (now old) devices who only boot a boot manager from the UEFI partition if it is called "Windows Boot Manager", therefore there are still Linux distros today who have an option to install the Linux (GRUB) boot manager under this name.
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.
---
In the web PKI, the "leaf" certificates can be easily chained back to the root CA/trust anchor. If UEFI were sensible, the same thing would be done with secure boot and we could avoid needing to deploy separate KEK and DB/CA certificates and simply include a signed chain (up to the KEK) with every bootmgr. Why don't we? Does it all come down to revocation checks being impractical (but isn't that the case anyway and why we have a DBX)? What's the engineering challenge that makes what we're doing now the "least worst" option?
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.
---
This question/comment comes with 20/20 hindsight.
In the web PKI, general practice is to replace CAs LONG before they expire to allow plenty of time to transition. Why did industry take so long to start replacing these certs? Would have been better to start replacing these certs back in 2018 or 2019 at their half-life.
In case you didn't notice, hardware has become expensive and (for some customers) it's harder and harder to ask for budget just because devices are long in the tooth. Rolling out these keys/certs back in 2018/2019 would have made this far less of an issue when it comes to hardware lifecycles.
