Event details
396 Comments
We have an air gapped environment with Windows 2019 servers and on them some Hyper-V VMs.
Cause of air gapped we can only install patches once a year and we are on patch KB5062557 and try now with registry keys and starting of the scheduled task to refresh the certs on our boxes. Works fine on physical ones, but we have problems on VMs. Sometimes current KEK is updated, sometimes not (Microsoft Corporation KEK 2K CA 2023) , same for Current UEFI DB (here we do not get the 2023 certificates, sometimes).
Is there a proven and let's say stable way for refreshing the certificates on the VMs and what has to be done to "avoid" the error "1795 - The system firmware returned an error The media is write protected"? We tested the switching of the SecureBootTemplate, but as I wrote it seems to work only sometimes.
Intune Secure Boot Status Report
The Secure Boot Status Report states:
“The affected devices have Secure Boot enabled but are using Microsoft Secure Boot certificates that expire in 2026.”
Given this scope, we would appreciate clarification on the following:
Why does the report include a Secure Boot enabled filter and values such as Unknown or Not applicable if the report is intended to cover devices with Secure Boot enabled?
Can Microsoft confirm the exact meaning of the following states:
Up to date
Not up to date
Not applicable
Secure Boot enabled = Unknown
Under which conditions can a firmware-ready device remain in Not applicable for an extended period (e.g., telemetry delays, firmware validation, recent BIOS changes)?
Our intent is to correctly interpret the report and align remediation actions with Microsoft’s expected behavior ahead of the Secure Boot enforcement milestones.
Does the Intune setting Configure Microsoft Update Managed Opt‑In only opt a device into receiving Secure Boot certificate updates, or does enabling it also activate any additional or hidden Microsoft Update features?
Could you talk about the device's local Secure Boot enforcement mode (Strict, Standard, Audit etc.) please? Someone in our team mentioned it today - that if devices are in Strict mode they won't boot without the new certificate? I've not seen this mentioned in the MS docs I've read. Thank you 🙂
- Pearl-Angeles
Community Manager
Thanks for your participation in the AMA! Panelists covered this topic at around 9:10.
Posting the link from the footnote (windowsforum) would have been more useful than a screenshot of Copilot, as it would allow to see the original discussion and what actually was talked there. And do not forget that copilot can be wrong and often is when you use terms that are not official (like Secure Boot Strict Mode - There is Setup Mode and User Mode, but no Strict Mode in Secure Boot specification. Some UEFI also have "Custom mode" vs. "Vendor mode" which refers whether to use platform keys from the UEFI vendor or your own ones. But no Strict Mode).
The new "Secure Boot" Intune report (Reports > Windows Quality Updates > Secure Boot) only shows 100 devices onscreen out of all the devices in our estate - even when exported. The summary numbers at the top of the report I suspect are correct, but unable to confirm as the report itself is limited to 100 devices. Also keep seeing the below error when scrolling through the 100 it does show. Please can this be fixed 🙏
Hello, I would like to get some clairty on the following questions.
- Is there a prerequisite of updating the system to the latest BIOS / UEFI version from the vendor to before updating the certificates ?
- Is there a list of High Confidence devices that Microsoft is able to provide ?
- Outside of InTune deployment which method does Microsoft suggest using for the most reliable way to update the certificates ?
- The most recent one via WinCS (Option 3) ? or the (Option 2) via Registry keys?
- In the troubleshooting section Microsoft recommends you have the Bitlocker recovery key available.
- Does the updating the certificates via any of the methods suggest suspend bitlocker for them to apply and how do we monitor this via telemetry, events etc?
- If Secure boot is not on and we let the certificate expire and we enable secure boot at a later date, what is the impact ?
Q1: In the common case (no firmware bugs) it does not matter whether the firmware update is installed before or after updating the certificates. The firmware update will provide new certificates in case the UEFI variables are reset, and the certificate update will provide new certificates for the currently running system. If there is a firmware bug that lets the certificate update run into an error, obviously you need to install the firmware updates.
Q5: You will have to update the certificates at a later date, either from the system or via securebootrecovery.efi, or the system will stop booting in case it got a newer bootloader signed with the new certificates. As UEFI generally cannot securely validate timestamps, the update will either (most likely) just work or will require to switch back the system time before applying securebootrecovery.efi, and fix the system time again afterwards. So, as a worst case, a few more manual steps required.
Hi, I would like to have some clarification to know if we enable this
What is the Controlled Feature Rollout for secureboot?
Does that mean that MS will be in charge of updating the certs like for high confidence devices?
So it's kinda like us deciding which devices we know can have the cert renewed by MS?
Or it's something else?
thks for clarifying.That's how we have interpreted it - by configuring those RKs on devices, you're giving MS the greenlight to deploy the certs automatically to them.
Is there a supported method to manually determine a successful deployment outside of a registry key value being switched to "Updated"? So far, I have yet to run into issues testing in our lab environment, but I don't have high confidence only relying on the registry key and event ID 1808...
Hi renzobaronti I have posted a script in the comments. This allows you to identify the situation at scale.
Ask Microsoft Anything: Secure Boot - February 5, 2026 - Windows Tech Community
We are using the AvailableUpdates=x5944 method to make these changes in our environment. Two out of our ~ten active, Win11-supported models of Lenovo desktops/laptops will not take the KEK cert update (the DB certs and bootloader update fine on them, but the KEK piece fails with Event ID 1795). In the last month, Lenovo has released BIOS updates for those models that add the 2023 certs to the default Secure Boot key stores, but not the active store, and the KEK update from within the OS still fails. Lenovo's recommended process is to update the BIOS and then use the "Restore Factory Keys" get the new certs into the active store. We have started doing this and it works but it is obviously a hands-on process (in particular, the "reset to factory keys" part cannot be automated and requires physical presence, as far as I know).
Is there any hope that Microsoft (maybe in partnership with these OEMs) will add "support" for more hardware models to take the KEK cert via AvailableUpdates before June, or, if it doesn't do it now, is that not going to change?
Event ID 1795 should include an error code that might be useful to diagnose this (Not all 1795 are equal).
For the KEK update to work, the OEM needs to submit a signed variable update with the new KEK that is signed with the Platform Key. and upload to Microsoft's secureboot_objects repo on GitHub. A list of all platform keys they have received (even those that did not make it into the January CU) with their thumbprint is available at
https://github.com/microsoft/secureboot_objects/blob/main/PostSignedObjects/KEK/kek_update_map.json
You can check the Subject and Thumbprint of the used platform key on affected machines that did not reload the factory keys, by installing and importing UEFIv2 Powershell module and running:
(Get-UEFISecureBootCerts pk).Signature | Format-List Subject,Thumbprint
If the thumbprint has already been submitted to Microsoft, it will probably be part in one of the subsequent updates and therefore the KEK update may work. If the KEK update causes a firmware error, the OEM might push a firmware update to fix this. So time can fix this.
The most likely case for a vendor like Lenovo to release a firmware update but not submit a signed KEK to Microsoft would be that they simply lost the private key to the PK used in those firmware versions. You can check on a machine that already uses the new factory keys (or by looking at pkdefault instead of pk if the firmware exposes that variable) if it uses a PK with different thumbprint. If yes, that is a telltale sign.
In that case, automated fixing is not possible (if the machine has an active TPM, which it probably has if it is Win11-supported). If Lenovo pushed a firmware update that either updated PK or KEK, it would invalidate PCR7 of the TPM and in case Bitlocker uses that PCR to seal their keys you would end up in Bitlocker recovery (which is a tedious manual step as well). And as long as they cannot sign a new KEK update with the PK as they lost it, Microsoft cannot do anything either.
That's exactly what Secure Boot tries to prevent.
mihi - thanks for clarifying why the BIOS update can't realistically update the active keys.
The two models we have that won't take the KEK update via the OS (as of the January B-Week CU, anyway) are PK thumbprints F2E851A4D6C74F0671DC0DCF392C96F94AE30816 and EF95E29CCE285D87734012EF940FB14EE0A7118B, respectively. Both of these have been on the JSON file you referenced since it was first published last May. The PK thumbprint is still the same after updating the BIOS to the version that adds the new certs to the factory defaults and performing a reset to factory keys.
It sounds like Microsoft still might add support, then? That said, with taking so long to do so, our hand is basically being forced to undertake an extremely intensive manual process, since we can't afford to wait until a month or two before June with no guarantee that Microsoft will actually get around to it and then not have enough time to complete the updates manually ourselves.
Can you give any insight into how much of a "backlog" MS has in adding support for PKs already submitted by vendors? Any specifics into when the two thumbprints I provided might be added?
Given that :
- All Windows devices are one of the following manufacturers, Dell, Lenovo and HP
- All Windows devices are updated via WUfB (Intune update rings, Windows drivers = Allow, i.e. all BIOS are updated via WUfB)
- Full https://learn.microsoft.com/sv-se/windows/client-management/mdm/policy-csp-System?WT.mc_id=Portal-fx#allowtelemetry is configured (Allow Telemetry = Full) for all Windows devices
- Assuming that WUfB and AllowTelemetry are working as intended
Can we just sit back and wait for WUfB to update all Windows devices secure boot certificates?
