So inevitably, what was supposed to happen happened. As the new Secure Boot certificates land on machines deemed compatible, the initial feedback confirms that the caution shown by Microsoft was not exaggerated.
As noted by Windows Latest, these discrepancies result in very variable behaviors depending on the manufacturers. At ASUS, applying updates to the DBX (the revocation list used by Secure Boot to block vulnerable or unreliable components at startup) may require temporarily deactivating Secure Boot.
At MSI, the firmware may silently ignore updates, mishandle the DBX, display Secure Boot modes that do not always match the labels on the interface, or unexpectedly return to factory settings.
On the ASRock side, reordering can sometimes be even more complicated. Some motherboards require clearing the Secure Boot keys stored in the UEFI, restoring factory keys, manually reinstalling the trusted keys provided by Microsoft, or even applying DBX updates yourself. In short, it’s a project.
Conversely, Dell, HP, or Lenovo PCs seem to better absorb the transition, even if deployments are spread out, BIOS or UEFI updates do not arrive at the same pace for all models, and several restarts may sometimes be necessary before the changes are fully taken into account.
Secure Boot ultimately is not the weakest link in the story. What’s causing trouble is everything surrounding it, starting with firmwares whose quality and support still vary too much from one manufacturer to another. As long as nothing disrupts the balance, these lapses in discipline go more or less unnoticed. But as soon as a somewhat sensitive change emerges, like this certificate renewal, all the accumulated disorder resurfaces. The ongoing transition will at least serve as a reminder that the PC ecosystem cannot indefinitely treat firmware as a secondary issue.
