It was back in 2015 that I wrote my first set of blog posts on Windows driver signing. Then I wrote some more in 2016. And then in 2017 I wrote what I thought was the ultimate, definitive, and incredibly simple blog post entitled Attestation Signing — It’s NOT a Mystery.
Still, all these years later, two weeks don’t go by without a post on NTDEV by some poor soul who’s utterly flummoxed by the Windows driver signing procedure… or without our getting an email from a client or potential client the says something like the following:
Our customers (or our internal test team, or our OEM) are telling us (or begging us, or yelling at us angrily) that we need to have our drivers for Windows 10 signed.
We don’t know what this means. We don’t know anything about driver signing. The documentation on the Interwebs is about as clear as mud and appears to a novice to be inconsistent.
Please help us. We have money. We will pay you. Please.
This is frustrating beyond description — For them and for us here at OSR. How can a company that can build something as amazing as Azure Active Directory fail so utterly and consistently at describing what is, really, an inherently simple process?
Let me repeat what I tell these poor folks:
- Go read my 2017 blog post on this topic here.
- Ignore anything you read, anywhere, regardless of who wrote it and when, that suggests or implies or even definitively states that driver signing for Windows Server is any different than driver signing for Windows Client. It’s not. There was a brief time in history when there was going to be a difference. That time never came. Now they are entirely the same: A driver that’s Attestation Signed for Windows Client will work on Windows Server.
- If you want to get fancy and have a single executable driver image (only one .sys file) that can be successfully installed on Windows 7, Windows 8.1 and Windows 10, then things can get tricky. This is not supported by attestation signing, and the only way you can do this is by passing the appropriate battery of Hardware Lab Kit / Hardware Compatibility Kit tests. But, lacking this, nothing says you can’t create a single installer package that selects the appropriate .sys file — 32-bit or 64-bit, signed appropriately for Win 7, Win 8.1 or Win 10 — and let your customers use that.
Back in 2017 I ended my blog post by writing “It really is this simple.” And guess what? It still is. You just needed somebody to make it clear.
And if you’re still flummoxed? Head over to our our community site’s driver developer’s forum and ask us (and a smart and helpful group of community-minded colleagues) any questions you might have.