If the device does not use Secure Boot, the deployment will do nothing.

If the device has Secure Boot, it has some kind of firmware where environment variables are stored (or else Windows could not boot as it could not store the location of Windows Boot Manager) - an attempt is made to update those variables with the latest certs.

This update can fail (both on hardware and virtual machines) due to implementation bugs in the firmware, causing a freeze or in the unlikely worst case a system that won't boot automatically again. That is the whole reason why Microsoft is adding so many switches and does not just apply the update everywhere. But this is unrelated whether the firmware is "a hardware BIOS" or "not a hardware BIOS", whatever that might refer to (e.g. a firmware that is not called BIOS but UEFI++, or a firmware that does not have a built-in setup menu, or the virtual firmware of a virtual machine).

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.

I updated the file : version 1.30   Have a look at the right part.

https://github.com/claude-boucher/CheckCA2023

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.