mihi,

I don't know why this isn't working. I'm seeing others that are saying they were successful. One person said it took a little while before they worked.

I forgot to say: one other detail is that you need to apply the March updates on the guests as well. This will give the guests a Hyper-V PK signed KEK to apply. That is not why you got the 1795 event but wanted to make sure you (and everyone else) were aware of this.

Let me know if you can't get it solved.

Arden

[1] If the device is not sending diagnostic data, there is still an alternate path for Secure Boot certificates to be applied. Devices can be included in the High Confidence database that is delivered with cumulative updates. When a device is identified as High Confidence, the Secure Boot certificates are applied automatically.

For client devices, there is a relatively high likelihood of being classified as High Confidence. This is much less likely for server and IoT devices.

[2] Yes. Automatic application occurs for devices that are determined to be High Confidence based on data from other similar devices.

[2.1] The default Secure Boot behavior will automatically apply certificates for High Confidence devices. Leaving Automatic Certificate Deployment via Updates set to Not Configured or Disabled allows this path to function. Unless there is a strong reason to avoid relying on this mechanism, it is generally recommended.

As you noted, Certificate Deployment via Controlled Feature Rollout must be Enabled, and Required diagnostic data must be sent for this option to work. This can be more difficult for some IT organizations, either due to data‑sharing policies or challenges ensuring diagnostic data reaches Microsoft.

[3] Yes. Enabling Enable Secure Boot Certificate Deployment bypasses the need to send diagnostic data. This explicitly instructs the device to apply the Secure Boot certificates and the 2023‑signed boot manager. This option is appropriate when you have confidence that the device firmware can successfully process the update.

[4] Yes, that is correct.

Additional note on firmware updates
Firmware updates are not required in most cases. They are primarily needed when there is a firmware defect that prevents Secure Boot certificates from being updated, or when you want the new certificates present in the firmware default variables. The default variables are used to initialize the active Secure Boot variables.

I hope I've answered your questions.

Assuming they are on current patchlevel, I would assume they have been delivered with the new 2023 certificates from the factory and therefore the job would have never needed to update anything.

Hi Joaki1810,

Hotpatch updates are security‑only updates. The OS support required for Secure Boot certificate updates was delivered in prior monthly cumulative updates, including those released before the January hotpatch baseline.

As a result, hotpatch‑enabled Windows 11 24H2 and 25H2 devices can still receive Secure Boot certificate updates. In most cases, these certificate updates can be applied without a reboot. Some Secure Boot changes do require a restart, such as applying a newly signed Windows Boot Manager, and those changes are applied during the baseline month when a reboot occurs.

For devices relying on hotpatch, High Confidence targeting data is only updated during baseline months. When that High Confidence data is refreshed, hotpatch‑enabled devices that meet the criteria will have their Secure Boot certificates updated at that time.

This is why Secure Boot improvements may be called out in the standard February cumulative update but not explicitly listed in the February hotpatch update.

Arden

I use the following code to check certificate on the boot file in the EFI partition. You could simplify by using mountvol if you prefer. This is just for the active boot file - not the copy in the Windows file system (C:\Windows\Boot\Efi)

$SystemDisk = Get-Disk | Where-Object IsSystem
if ($SystemDisk)
{
    $SystemPartition = Get-Partition -DiskNumber $SystemDisk.DiskNumber -ErrorAction SilentlyContinue | Where-Object IsSystem
    if ($SystemPartition)
    {
        $params = @{
            DiskNumber = $($SystemPartition.DiskNumber)
            PartitionNumber = $($SystemPartition.PartitionNumber)
            AccessPath = 'S:'
        }
        Add-PartitionAccessPath @params -ErrorAction SilentlyContinue
        $SystemPartition = Get-Partition -DiskNumber $SystemDisk.DiskNumber -ErrorAction SilentlyContinue | Where-Object IsSystem
        if ($SystemPartition.AccessPaths -contains 'S:\') 
        {
            $bootmgrPath = Join-Path 'S:\' 'EFI\Microsoft\Boot\bootmgfw.efi'
            if (Test-Path $bootmgrPath)
            {
                try 
                {
                    $cert = [System.Security.Cryptography.X509Certificates.X509Certificate2]::CreateFromSignedFile($bootmgrPath)  
                }
                catch { }
                if ($null -ne $cert) 
                {
                    $issuerName = $cert.Issuer
                    $commonName = $issuerName.Split(',')[0].TrimStart('CN=')
                    $dateString = $cert.GetExpirationDateString()
                    $notAfter = $dateString | Get-Date -Format "yyyy-MM-dd HH:mm:ss"
                    $expiresInDays = ((Get-Date $dateString) - (Get-Date)).Days
                }
            }
            Remove-PartitionAccessPath @params -ErrorAction SilentlyContinue
        }
    }
}

I have to say that I like your UI.

Would you mind adding some more metrics/information?

• Which certificate \EFI\Microsoft\Boot\bootmgfw.efi on EFI system partition is signed with
  • Reason: In Multiboot scenarios (e.g. Win10+Win11, or multiple systems using Boot2VHD) the "global truth" does not always match the "local truth" reflected in the system registry
• In case EFI system partition contains \EFI\boot\bootx64.efi, whether it is a Microsoft boot loader and if yes which certificate it is signed with
  • Reason: When working with multiple OS (Win+Win, or Win+Other), sometimes there appears such a fallback bootloader, which may be used by the firmware for booting despite a "correct" bootloader is present in the EFI variables. Getting to know whether that one is still outdated
• The thumbprint of the Platform Key in a form that can be copied.
• Whether 

  "C:\Windows\System32\SecureBootUpdates\KEKUpdateCombined.bin" of the currently booted Windows instance contains a KEK update for that platform key

• Whether https://github.com/microsoft/secureboot_objects/blob/main/PostSignedObjects/KEK/kek_update_map.json contains a KEK update for that platform key
  • Reason: Getting a better feeling whether there is a chance that the KEK gets updated when flicking the switch now, and whether there is a chance for it to work in the future

Thank you.

Don't be afraid of the "minimum BIOS version required" or "compatible hardware" lists you can read on LENOVO, DELL, HP, ... Web Site. (in rare case you need to upgrade your Bios before using MS CA 2023 Process)

BIOS updates from your OEM will provide certificates stored in a dedicated area of the firmware — but the certificates needed to start the Secure Boot chain are actually provided by Microsoft through the process they described. And of course there is absolutely no cost involved.

If you only have a few devices, the simplest path is just to let Windows Update handle it — it will deliver the necessary certificates and boot loader updates automatically.

see my other message ;)

Hi Stuard_Smiles,

For home users, Secure Boot certificate updates are delivered automatically through Windows Update at no cost. OEM BIOS lists are provided for reference when firmware updates are required, but most Windows 11 devices do not need manual action unless the system reports a compatibility issue.

Arden

Hi SCCM_Terror,

we recently discovered an issue with Windows 11 23H2 Enterprise-Pro where you would still get this error. A fix for this is planned for the April updates. It should be working with Windows 11 24H2 and 25H2.

Sorry for the inconvenience.

Arden