Event details
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
