Event details
275 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-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.
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 KEK trust installation task is cyclical (this isn't the last time we'll do this), yet it seems Microsoft hasn't taken this fact into consideration with the names of the various registry keys and log messages. How are we going to differentiate at the next rotation cycle between the updates we're doing now and the ones we'll be doing then? Seems to me the current methods are not sustainable or flexible enough for the future.
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 KEK trust installation task is cyclical (this isn't the last time we'll do this), especially in virtualized environments. What is industry doing to make these updates (particularly the KEK) more frequent and easier?
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 Dec AMA it was mentioned (I think by Scott) that the KEK-signed DB/DBX update binaries are time-stamped and continue to work. How does timestamping work with KEK updates? Similar to how we do it in x509/code signing? Or did I misunderstand? It also sounds like the KEK can't be used after it expires to make DB/DBX changes, so I find this all irreconcilable.
Technically, if your new DB/DBX update has a timestamp larger than the last one that is in the DB/DBX already, it can still be applied. The DB/DBX update timestamp needs to be within time range of the certificate signing it.
Technically, nothing stops Microsoft from issuing a KEK update with a timestamp 1 week before expiration although the signature has actually been created 3 years after expiration (Just like nothing stops a TLS CA to issue a certificate signed for a domain they do not control). Only that it would violate the policy of their CA, and maybe people would get mad at them and stop trusting them...
Secure Boot requires update binaries to be timestamped but it doesn't enforce strong verification of those timestamps. The only check is that you can only replace or delete a variable with a timestamp strictly greater than the last used timestamp for that variable. You can still append to the variable with a old timestamp (what Microsoft is doing with these updates since it only appends certificates). Thus the update binaries will always stay valid in the future, as per the current UEFI specifications.
Also, Secure Boot never checks if the certificate signing the binary is expired. So you can generate outdated PKCS#7 signatures with an expired certificate to keep using it for Secure Boot updates. It seems Microsoft won't do that though (or that their PKI won't allow them to), otherwise they wouldn't insist so much on replacing the KEK.Thanks for the replies.
"Secure Boot requires update binaries to be timestamped but it doesn't enforce strong verification of those timestamps. The only check is that you can only replace or delete a variable with a timestamp strictly greater than the last used timestamp for that variable. "
After staring at your comment for long enough, I think I understand what you're saying, but it's not really my question. I'm talking about "normal" code timestamping where the signature doesn't rely on the subject certificate still being time-valid (RFC 3161). What you're referring seems to be more about ensuring the proper lineage of updates (forward-only updates).
However...
"Thus the update binaries will always stay valid in the future, as per the current UEFI specifications."
...you lose me with this comment. Either the KEK binaries are valid past expiration xor they're not. If update binaries are valid forever and UEFI/SB processes are **trusting** an unauthenticated timestamp, then the whole expiration of the certificate would seem pointless. Or you didn't mean to say what I'm interpreting.
"Also, Secure Boot never checks if the certificate signing the binary is expired."
You're losing me even further with this one. What do you mean by binary? Do you mean the EFI bootloader/oprom/application? Or the update binary (the DB/DBX 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-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.
---
All MS is doing (for now) is adding new certificates and not revoking any of the 2011-era certs. To clarify, are the main reasons Microsoft is being so cautious with the rollout (A) tripping bitlocker recovery and (B) triggering code defects in device firmware (and how severe are we talking)? Are there other (bigger) reasons? Root CA programs update their CA anchors all the time and never is it this big of a deal. Why/how is secure boot unique?
The main reason why 2011 certs are not "blanket" revoked, in my opinion, is that there are lots of recovery media out there (e.g. created by third-party full-disk backup software) that would fail to boot once the 2011 cert has been revoked. And Microsoft does not intentionally make it hard for users to restore their data.
If your company is aware, they can flip the bit so that the 2011 certs are revoked as well. It is just not happening through CFR or LCU (yet...).
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.
---
Is there any general practice among OEMs as to how many PKs they maintain? It would seem reasonable for OEMs to not use the exact same PK/keypair across their entire brand because the blast radius of a key compromise/leak will be immense (not if, but when). i.e. one PK per generation, one PK per model, one PK per product line, etc? How does this impact Microsoft's complexity in updating the KEKs?
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 trust anchor for secure boot is the PK. Do PKs expire? Has a PK's private key ever been leaked (do we have precedence for such a horrifying possibility)? How do vendors update their PKs (if that's possible)? Can you have multiple PKs (to service replacements with minimal disruption)?
