Not a driver development issue per se, but just a heads-up for changes we can expect to see in the not-too-distant future regarding the signing we do for drivers.
This latest Ballot CSC-13 is advancing that the HSM (hardware security module) requirement will now be for “all” code signing certificates, starting with new certificates issued after November 15, 2022, and no longer limited to just EV certificates.
Currently on the Microsoft Partner Portal we’re allowed to associate “normal code signing certificates” in addition to “EV code-signing certificates”. Several of us had leveraged this “normal code signing certificate” association capability in order to continue using them as part of our actual product build and signing automation. Due to there being less limitations in making the private key available to the signing automation, as compared to the EV certificate which required physical attachment or other secured access to the HSM-stored certificate keys.
So if you hadn’t already started designing your build or signing automation to depend on pulling the code signing certificate from an HSM, now might be the time to start.
Meaning, if you are already signing your submissions and/or product using your EV certificate, presumably “no further change needed.” Since EV certificates are already required to be on an HSM, and your signing process is already dealing with those limitations.
But if you had been continuing to leverage a non-EV-based signing process which used software-only private key storage, that approach likely isn’t going to continue working after your next certificate renewal. Because even non-EV code signing certificates will be required to issue and access through HSM-based devices.
Note this is not a statement of “you must begin using EV certificates for code signing.” This is just saying that one of the current practical differences between an EV code signing certificate and a non-EV code signing certificate will be going away, and both types will be “just as difficult to use” as part of your signing process. For reasons which are intended to protect your code-signing certificate from compromise, of course.