Hi Tackey-8993,
From what you describe, the issue seems to be tied to how the KEKUpdateCombined.bin file is currently packaged. The absence of the KEK payload signed by the Windows OEM Devices PK has been noted by others in the community, and it does appear to be a limitation in the way the update bundle was built rather than a problem with your devices.
When transition mode or alternate signing keys are used, reauthentication and updates typically succeed, but strict reliance on the Windows OEM Devices PK can expose this gap. The fact that you are seeing the KEK payload missing suggests that the combined update file may not yet include all expected signatures.
The best course of action is to monitor the official Secure Boot objects repository and Windows release notes, as updates to the KEK package are periodically published. In the meantime, you can validate whether your devices are applying the latest cumulative updates, since improvements to Secure Boot handling are often rolled out through those channels. Capturing logs during the update attempt and submitting them via the Feedback Hub can also help escalate the issue to the product team.
While this does look like a Windows-side packaging issue, it’s not uncommon for Secure Boot updates to lag slightly in including all OEM-related payloads. Keeping your test environment aligned with the latest builds will give you the best chance of seeing the corrected KEK included.
I hope this helps clarify the situation and gives you a practical path forward. If you find this advice useful, please consider clicking Accept Answer so I know your concern has been addressed.
Jason.