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?
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?
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.
Be aware that the boot manager may be updated before the new KEK is in place (in case there is no new KEK update signed by your firmware vendor's platform key), so by checking the boot manager, you may see "Updated" devices that still lack the KEK update. If going that route, I'd check for the KEK certificate separately.
