Event details
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?
- mihiMay 15, 2026Brass Contributor
- 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.
- DraganStMay 18, 2026Copper Contributor
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.
- trevorjonesMay 15, 2026Iron Contributor
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 } } }- DraganStMay 15, 2026Copper Contributor
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?
- trevorjonesMay 15, 2026Iron Contributor
I think the Microsoft answer would be to use UEFICA2023Status = Updated, but we've been tracking this and there are many devices with the new certs installed in the db and the boot manager updated that don't show UEFICA2023Status = Updated, so we use the updated boot manager as the preferred metric.