Event details
327 Comments
Microsoft please could you share your list of what computer make/model/firmware qualify as high-confidence devices and which ones do not? e.g. "all Surface Laptop 5s on XXX firmware version are high-confidence" etc.? Please 🙏
We've been told that devices that aren't updated by either June or October will fail to receive updates to the Secure Boot trust stores and Windows Boot Manager respectively during the installation of a cumulative update that contains these changes. What's the experience when the Cumulative Update runs on these devices? Will the CU still install "successfully", but just leave the machines without those changes? Or will the CU fail to install and rollback the entire CU as a result?
So you have delivered reporting in Intune. https://learn.microsoft.com/en-us/windows/deployment/windows-autopatch/monitor/secure-boot-status-report
Should we expect something similar for Microsoft Configuration Manager that could cover server resources managed by that product?its much needed the reports in SCCM as well.
OHHH NICE - thanks for pointing this out! Feature is present in our tenants, but showing nothing. Yet?
We're getting reports as expected for quality update status (all good), but not for secure boot.Will that populate over the next few days?
Hi community, Chris_Cramp ErnieCosta Dom_Cote
I have updated my earlier posting of questions with available answers / or solutions.-
What is the best way to update WinPE and SCCM OSD Boot medias(Standalone Media and Bootable Media USB and ISO with new cert 2023?
Unable to perform update on Hyper-V VM in test environment
Log Name: System
Source: Microsoft-Windows-TPM-WMI
Date: 2/2/2026 12:34:04 AM
Event ID: 1795
Task Category: None
Level: Error
Keywords:
User: SYSTEM
Computer: ABCDWin11.gpmn.test.com
Description:
The system firmware returned an error The media is write protected. when attempting to update a Secure Boot variable KEK 2023. This device signature information is included here.
DeviceAttributes: FirmwareManufacturer:Microsoft Corporation;FirmwareVersion:Hyper-V UEFI Release v4.1;OEMModelNumber:Virtual Machine;OEMManufacturerName:Microsoft Corporation;OSArchitecture:amd64;
BucketId: 4e22d051e8c143d2875b9d16ef2241c7ec548985a21e5073126d3c1f9bf53bb2
BucketConfidenceLevel: .
This Event ID (1795) is preventing a Hyper-V VM Generation 2 CV 10.0 running the Windows 11 version 25H2 O/S on a Hyper-V Host Server (Dell PowerEdge T140) System, that has successfully updated the BIOS Firmware, and Microsoft 2023 Secure Boot Certificates, and has UEFI and "Secure Boot" turned on within the server configuration settings.
This is a known issue (read the other comments here). Will probably be fixed with cumulative update in March, to be applied to the Hyper-V host. Workaround (if you care) is to suspend bitlocker (if used), and then move the virtual hard disk to a freshly created Gen 2 VM (after updating the host to have the cumulative January patches, if not already done). The freshly created VM will receive the new KEK in the Secure Boot template and the rest of the process can continue.
We have Windows Server VMs running on ESXi that are stuck in progressl available updates registry value is 4004.
VMs are fully patched, we've run through the Broadcom documented process to update the Platform Key which allows the KEK db to be updated, and the Dell host server has had the latest BIOS applied, which specifically references the secure boot certificate firmware update.
The VM event logs state Updated Secure Boot certificates are available on this device but have not yet been applied to the firmware; we've confirmed the hosts are running the latest BIOS/firmware version.
2023 certificates are showing in the active DB but not in the default DB. How do we get this process to complete?
The default DB will not change at all by actions done by the Secure Boot updates. If there is a firmware update, it may include them (or provide an option to enable them). If not, live with the fact you will need to run securebootrecovery whenever you reset your firmware variables.
With "Broadcom documented process" you refer to article 423919 in their knowledge base, specifically to use UEFI setup to manually change PK to the one with Thumbprint 3d86...48b5? There should be a signed update available for that one (according to secureboot_objects), but when you went that far and took precautions like about TPM before, why not just repeat the process and enroll KEK available in the same way?
https://github.com/microsoft/secureboot_objects/blob/main/PreSignedObjects/KEK/Certificates/microsoft%20corporation%20kek%202k%20ca%202023.der
Yes, although the Broadcom documentation indicate KEK update as an optional step, but it is recommended to enroll KEK also. At least two VM encountered similar secure boot update failure when KEK update is not enrolled. And the registry key may need to reset to the original 0x5944 to restart the entire progress if it still stucks at 0x4004 after the KEK update.
Q1. Is there a known bug for the GPO setting "Enable Secure Boot certificate deployment" on Windows Server 2025 servers? The registry key AvailableUpdatesPolicy is applied, but the value is never transferred to the AvailableUpdates key. No problem on Windows Server 2022, and servers are updated with the January 2026 cumulative update.
Q2. According to this link: https://github.com/microsoft/secureboot_objects/issues/318#issuecomment-3662004435 applying March 2026 cumulative updates would fix so that the "Microsoft Corporation KEK 2K CA 2023" certificate would be able to apply on HyperV. Is that fix for the Host or the Virtualized VMs with the issue?
Q3. Would the same update in Q2, also help on the Azure VMs, that also have issues with applying the "Microsoft Corporation KEK 2K CA 2023" certificate. Random VMs in Azure has problem with the KEK certificate.For Q2, you'd need to apply it to the host. (By the way, that they target March update will not necessarily mean that it will make it). Apart from that, the known workarounds work without any host updates (if the host is on recent patchlevel):
- Create a new VM and attach the virtual disks to it. That new VM will have the new KEK by default. Be careful with suspending Bitlocker etc. if you use a TPM
- Change the Secure Boot Template in the VM settings twice (back to original) while the VM is powered off. This will not work (raise an error message) if you ever had a TPM attached to the VM
Im testing the Intune policy to enable Enable Secureboot Certificate Updates and Configure Microsoft Update Managed Opt In, but I can see an error on both:
The test device is a Windows 11 24h2 Enterprise.
Interesting. This is a known issue on PRO devices: Microsoft Intune method of Secure Boot for Windows devices with IT-managed updates - Microsoft Support
Did your device do a step-up from Pro via subscription activation? Or is it an Enterprise base image?
Because it also impacts Windows 11 Business - which is also a subscription activation step-up from Pro for M365 Buiness Premium.The device was upgraded from Pro to Enterprise via subscription activation.
