Event details
114 Comments
What's the current situation with VMware and secure boot. Broadcom has been "working on an automated solution with Microsoft" for quite some time, and I have the feeling they will not have one before the deadline. There's an automated script that uses the delete NVRAM method which Broadcom has since disavowed as a valid solution and warns it can cause problems with the VM.
I was on a call with a third party last week and they announced that most PCs will recieve the new certificates as part of this month's Cumulative Update. Can you confirm that and is there a definitive list of make and model devices that are receiving them this month?
Thank you everyone at Microsoft I'm a member of a company that deploys approximately 100,000 Windows PCs. I would like to ask you two questions regarding the expiry of the secure boot certificate. It has been announced that the certificate will expire in June 2026, but it is written in the knowledge that the PC can still be started. Please tell me the reason why I can start up even though the certificate has expired. Also, there is a statement in the knowledge below that a new notice will be given 6 months before the PC will no longer be able to start, but is my understanding correct? Announcement date – implementation phase The enforcement phase will not begin until January 2026, and this article provides at least six months of advance warning before this phase begins. When enforcement phase updates are released, they will include: I'm looking forward to today
- Heather_Poulsen
Community Manager
Today's Secure Boot AMA will get underway in 75 minutes. Keep those questions coming in. Our panel will ready to help.
I have only delved into this briefly, but from what i have read it seems that for devices using BIOS boot updates will not be pushed. What about devices using UEFI without Secure Boot? Also, in the case of BIOS boot, could it be that a patch for boot components is released in the future and it would require new certificates/signature to be able to install and a system would be marked vulnerable without such patch? My guess, that it probably would not be vulnerable as Secure Boot is not being used, but often scanning tools do not look into nuances of whether it is actually applicable and just use signature/registry/file version check and mark everything as vulnerable. Trying to anticipate all possible scenarios.
If Secure Boot is disabled as well as in legacy Boot environments:
- Microsoft will install the new boot manager regardless of installed certificates. So you will automatically get the latest updates for the Boot manager regardless of certificate status (if applicable)
- There is no way to prevent vulnerable boot managers from booting. So, you won't get the protections regardless of certificate status (if applicable).
To sum it up, there is no difference in security impact on such machines whether new certificates have been applied (if applicable) or not.
We're following a guide by MindCore (search for Mindcore Secure Boot) to detect and automatically remediate machines into getting updates certs, which provides a lot of detail on what stage of the process is happening.
We've noticed that on a small number of machines (approx 25 out of 900) are waiting on Windows Update to finalise the secure boot activation sequence so the certs are marked as ACTIVE.
It's apparent these computers whilst updated on the latest cumulative update do not have the file System32 \WinCsFlags.exe which is apparently used to aid with communicating back to Microsoft.
Can WinCSFlags.exe become available as its own update or specific standalone application so this can be installed as/when needed.
These computers are also missing the key UEFICA2023Status - it doesn't exist on these computers. Could this be connected to the above issue where WinCsFlags is not in place on the computer?
To potentially answer my own question, it would appear there is some corruption within Windows on my affected devices and this issue resolved itself once a Windows reinstallation via the latest Windows 11 Pro ISO from Microsoft was done on top of an existing installation (ie: no lost data, settings, etc).
The computers were fully patched, including the latest cumulative update for their build version (24H2, etc)
All the usual DISM commands for checking / restoring health were run and completed successfully, but with no change on the reporting.
A reinstall of Win11 on top of the existing installation appears to be the fix in this situation.- Arden_White
Microsoft
Hi Ben_Draper I'm glad you were able to resolve the issue. It's not clear why the devices were in this state.
The WinCSFlags.exe only operates locally on the machine and is one method of triggering the Secure Boot updates. WinCS had a staggard release (Oct 2025 - Apr 2026). That may explain why WinCSFlags.exe were not on some the devices. See Windows Configuration System (WinCS) APIs for Secure Boot for details on the release date of each. This should not prevent the certificates from expiring since there are other methods of deploying (Intune, GPO, registry key, ...).
I think the more interesting detail is that UEFICA2023Status did not exist on these devices. We have seen this when the Secure‑Boot‑Update scheduled task is not running. It's not clear why it would not be running. There are troubleshooting details here on determining if this is the issue: Secure Boot troubleshooting guide - Microsoft Support - see the first scenario called "Secure Boot updates not applying (no progress)"
Arden White
The main issues my customer are facing are :
* SecureBoot in Setup Mode
* KEK CA 2023 not provided by MS (need a script to manually install it)
(A CA2023 KEK) is proposed to the Hardware by MS SecureBoot Task,
but it seems it is not the good one and an error 1795 occurs !)
Is anyone get the same kind of issues ?Dear MS team,
Could you please give us the schedule for the nexts steps ... after 0x5944.
ThxNext step would be a restart sometimes can take 2 reboots
See:
https://support.microsoft.com/en-us/topic/how-to-manage-the-windows-boot-manager-revocations-for-secure-boot-changes-associated-with-cve-2023-24932-41a975df-beb2-40c1-99a3-b3ff139f832d
I wasn't aware of this KB, and it seriously concerns me. It says that sooner or later (during 2026) the "Windows Production PCA 2011" certificate will be added to the dbx, which, if I'm not mistaken, is the one used to sign the current bootloaders for various versions of Windows.
Up until now, I was comfortable and thought I could delay any action, especially in VMware environments where we have the null PK problem. Instead, both the KEK and DB, as well as the bootloader, need to be updated soon. Or am I wrong?
Our team has completed the Secure Boot certificate update procedure across a mixed environment covering Windows 11 workstations, physical servers running Server 2019 and 2022, and virtual machines on VMware vSphere running Server 2019, 2022 and 2025. While we are generally seeing success indicated by UEFICA2023Status = Updated, we are finding it difficult to confirm with confidence that the process is fully complete with no further action needed.
Our specific observations are:
WindowsUEFICA2023Capable varies across machines showing values of 0, 1 or 2, and it is unclear which value represents a fully completed state and whether a value of 1 is acceptable or indicates a pending step.
Get-SecureBootSVN consistently returns FirmwareSVN = 0.0 and ComplianceStatus = Not compliant across all machines including those that have received the May 2025 cumulative update, which was reported to address known issues with that cmdlet. It is unclear whether this reflects a genuine compliance gap or is still a known reporting defect.
Querying the Authenticode signature of both bootmgfw.efi in the Windows directory and on the mounted EFI System Partition using Get-AuthenticodeSignature returns CN=Microsoft Windows Production PCA 2011 as the issuer on all machines, including those showing WindowsUEFICA2023Capable = 2. This is contradictory because a value of 2 is documented as meaning the system is booting from the 2023-signed boot manager, yet the signature query returns the old issuer.
KEK and DB certificate presence has been confirmed via Get-SecureBootUEFI and both Microsoft Corporation KEK 2K CA 2023 and Windows UEFI CA 2023 return true across the tested machines.
My question is: What is the definitive, reliable way to confirm that the Secure Boot certificate update is fully complete and no further action is required? Specifically, is UEFICA2023Status = Updated alone sufficient, or must WindowsUEFICA2023Capable reach a specific value? If WindowsUEFICA2023Capable = 2 is required, why does Get-AuthenticodeSignature on the ESP bootmgfw.efi still show PCA 2011 as the issuer on machines reporting that value? And should Get-SecureBootSVN be trusted at all given persistent FirmwareSVN = 0.0 results even post-May update, or has Microsoft confirmed this cmdlet remains broken?
- Do not use WindowsUEFICA2023Capable for determining anything
- UEFICA2023Status will track boot manager as well as DB and KEK contents. It will not track SVN and 2011 certificate revocation in DBX, nor does it track SBAT status. Those are triggered by AvailableUpdate flags 0x200, 0x80 and 0x400, and they are not included in the suggested AvailableUpdates flags, as they are not required to keep all components of Secure Boot servicable by Microsoft. They are recommended to harden against certain targeted attacks, but if you go that route be aware that you may need to recreate all boot media created before July 2025 as well as all that still contain the 2011 signed bootloader or they won't boot without disabling Secure Boot
- There are two bootmgfw.efi in Windows directory, one in C:\Windows\Boot\EFI and one in C:\Windows\Boot\EFI_EX. They are expected to be 2011-signed and 2023-signed, respectively, and are no indication which one got installed to your ESP
- I am not aware of a broken Get-SecureBootSVN cmdlet. To check the SVN manually (for bootmgfw.efi) you can run this:
Get-SecureBootUEFI dbx -decoded | Where-Object {$_.Hash.StartsWith("01612B139DD5598843AB1C185C3CB2EB92") }The resulting hash will, after the shown prefix, have a bunch of zeros, then the SVN as a hex digit, then another bunch of zeros. If no hash is shown, no SVN is recorded and the SVN is therefore 0.
Thank you mihi for clarifying that SVN (Secure Version Number), along with SBAT (Secure Boot Advanced Targeting) and the revocation of the 2011 certificate via DBX, are optional hardening measures that improve security posture but are not required or part of the current Secure Boot certificate update process. As you explained, applying these is currently a manual process that requires careful planning and testing and should not be rushed. An SVN value of 0 is therefore expected on machines that have only completed the mandatory certificate update steps, and I can confirm this is what we observe both via the Get-SecureBootSVN cmdlet and the manual PowerShell command you gave me.
Regarding my original question, I conclude that having UEFICA2023Status = Updated is a reliable way to confirm that the certificate update process completed successfully, meaning all required certificates are in place and the boot manager has been updated to one signed by the new CA, so once the 2011 certificates expire, Secure Boot will continue to function without issues.
Furthermore, as trevorjones pointed out, even if UEFICA2023Status does not yet show Updated, the process may still be complete, but this requires manual verification of the individual components: Windows UEFI CA 2023 and KEK 2023 present in the UEFI variables, and the boot manager on the EFI System Partition signed by the new certificate.
For the "WindowsUEFICA2023Capable" key, the documentation says "For reference only - do not use this key when getting status on Secure Boot updates. Use the UEFICA2023Status key instead"
For the signed boot manager, I wouldn't use Get-AuthenticodeSignature as you'll get mixed results - it may not choose the correct certificate. To more accurately check for the signing cert, I use the following PS code. You can simplify this by using mountvol if you prefer.
In my environment, using this along with the db cert checks this has returned a more accurate picture of the update status than any current reporting mechanism from MS including the UEFICA2023Status key and the Intune report.
# Check whether the boot manager has been updated with the new cert $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 } } }trevorjones thank you for your quick response, it proved very helpful.
I used it in the following way:
Mounted the EFI system partition:
mountvol s: /SPerformed the check using:
[System.Security.Cryptography.X509Certificates.X509Certificate2]::CreateFromSignedFile("S:\EFI\Microsoft\Boot\bootmgfw.efi").IssuerFor successfully updated machines I get:
CN=Windows UEFI CA 2023, O=Microsoft Corporation, C=USFor machines that are not yet updated I get:
CN=Microsoft Windows Production PCA 2011, O=Microsoft Corporation, L=Redmond, S=Washington, C=USFinally, I unmount the EFI system partition using:
mountvol s: /DTo add, my previous confusion came from using the following command to verify the certificate:
(Get-AuthenticodeSignature "S:\EFI\Microsoft\Boot\bootmgfw.efi").SignerCertificate.Issuerwhich always returned:
CN=Microsoft Windows Production PCA 2011, O=Microsoft Corporation, L=Redmond, S=Washington, C=USWould it be correct to conclude that verifying UEFICA2023Status = Updated is sufficient to confirm that the process is fully completed, or is the boot manager certificate check the final validation step?
lalanc01 Very good questions.
Would you mind following up with some more details:
- Those machines are managed / part of a domain, I assume? And neither AvailableUpdates nor ManagedDevicesOptIn has ever been touched by you?
- Can you definitely say that they have been updated by Microsoft (as opposed to them coming with the new certs from the factory, or having them updated by updating the firmware and applying setup defaults)?
- Do you find any of the relevant Event log entries in their event logs (apart from the one stating that there is nothing to update)?
- Would you mind share a sample Bucket Hash?
For devices that are not managed or have opted into ManagedDevicesOptin, they may have been updated via CFR despite the Bucket hash not yet being High Confidence. After all that is what CFR is about (rolling changes only to a subset of devices). Update via the High Confidence list included in the LCR should (as I understand it) not update devices that were in "Under observation" state, and I assume that hashes that once were High Confidence would not move back to Under Observation, but rather to one of the known blocker categories in case there were any issues.
About your last question, my impression is that they will not succeed to getting all the buckets to High Confidence by June, just by looking at the pace buckets have moved in the last months. But I'd be happy to be proven wrong.
Stats so you can draw your own conclusion:
Name May April March High Confidence 2005634 1878953 1617397 Under Observation - More Data Needed 395777 466652 597235 Temporarily Paused 52420 53611 0 Not Supported - Known Limitation 32736 33831 0 High Confidence (Percent) 80,7 % 77,2 % 73,0 % Under Observation (Percent) 15,9 % 19,2 % 27,0 % My apologies Mihi, I see you weren't replying to me. Edited for removal.
