Event details
39 Comments
Hi guys 👋, thank you for hosting another AMA, and for fixing the Intune Secure Boot report 🙏.
It was advised the 65000 error on the Intune report would be fixed by now, but it's still showing on every device we apply the policy to:
When will this issue be resolved please?
Thank you 🙂Could you confirm that the Secure-Boot-Update scheduled task expects Microsoft's Owner GUID on Microsoft's signatures in Secure Boot? We customize the Secure Boot content and it seems that a different GUID causes the task to break the behavior of GetFirmwareEnvironmentVariableA() (used by BitLocker in other things).
Could you also confirm that updating the firmware SVN (4th step of the revocations) only consists in adding SVNs to the DBX? And that for testing purposes, resetting the DBX is enough to cancel the rollback prevention?
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.
---
When do the 2023 keys expire? See you again in ten years? Or will all you brainiacs be retired by then? :)
You can download the certificates and check their expiration dates. For Microsoft Corporation KEK 2K CA 2023 it's valid until 2038-03-02, after that date Microsoft won't be able to sign Secure Boot updates to the DB and DBX with this certificate
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.Thanks for the replies.
"The KEK update (needs to be signed by the OEM because they own the PK) is required before June 2026."
It's very possible I'm lost in the sauce, but I remember Scott in the December AMA saying that the various (existing) key/cert updates continued to work past 2026. This ties into the timestamping question you also responded to which I need to re-read.
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)?
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,
