Event details
39 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.
---
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.
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?
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)?
So we have 2500 VMware VMs, where we have checked with this code:
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'
We also have a similar line of code that checks the KEK, they both are returning true.
But we have NOT flipped the registry key specified by Microsoft to 0x5944 and hence the status says NotStarted. In our case above, with the VMware VMs, do we need to actually flip that registry key, that iniates the process or are we good to go as it is?
/PatrickIMO your question (and it's a good one) is not unique to vSphere. There's no good way (that I'm aware of) via registry or TPM-WMI event IDs to tell whether a machine already installed the latest UEFI/SB keys successfully xor always had the 2023 keys and hence never needed to take any action.
To not risk getting shadowed for posting a link, you may want to look up Broadcom knowledge base article 421593.
We have taken exactly that approach (deleting the .nvram file and rebooting, which in Vcenters with version 8.0.2 or higher has provided us with the "true" results mentioned. The registry key and it's associated scheduled task is somewhat doubtful if it is needed at all in the case of our VMs.
