So, inevitably, what had to happen happened. As the new Secure Boot certificates land on machines deemed compatible, the first feedback confirms that Microsoft’s caution was not exaggerated.
As highlighted by Windows Latest, these disparities translate into 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 temporary deactivation of Secure Boot.
At MSI, the firmware may silently ignore updates, mishandle the DBX, display Secure Boot modes that do not always match the labels of the interface, or unexpectedly revert to factory defaults.
On ASRock’s side, the reordering process can sometimes be even more laborious. Some motherboards require clearing the Secure Boot keys already registered in the UEFI, restoring factory keys, manually reinstalling the trust keys provided by Microsoft, or even applying DBX updates themselves. In short, it’s a mess.
On the other hand, Dell, HP, or Lenovo PCs seem to better absorb the transition, even if deployments are spread out, BIOS or UEFI updates don’t arrive at the same pace depending on the models, and several restarts may sometimes be necessary before the changes are fully taken into account.
Secure Boot ultimately isn’t the weakest link in the chain. What’s causing issues is everything around it, starting with firmware whose quality and support still vary too much from one manufacturer to another. As long as nothing disrupts the balance, these discipline flaws go more or less unnoticed. But as soon as a somewhat sensitive evolution emerges, like this renewal of certificates, all the accumulated disorder resurfaces. The ongoing transition will at least have the merit of reminding that the PC ecosystem cannot indefinitely treat firmware as a secondary subject.
