# Getting a kernel driver through Microsoft certification as a bootstrapped startup

* * *

## There is no shortcut. We checked.

When people hear "signed kernel driver," they usually think of attestation signing: you sign your driver with an EV certificate, submit it to Microsoft's portal, attest that it works, and get a Microsoft signature back in hours. No lab, no test suite. That's how plenty of Windows drivers ship.

Here's the thing we confirmed early, directly against Microsoft's documentation and then empirically: **attestation-signed drivers do not load on Windows Server.** For Server 2016 and later, the kernel itself refuses anything that hasn't been through full certification — the Hardware Lab Kit (HLK) test suite, run against the exact target OS build, submitted to Microsoft, reviewed, and signed. This isn't a policy you can toggle or a warning you can click through. It's enforced at driver load, in the kernel, on the operating system our enterprise customers actually run.

So the choice was binary: do the full certification, or don't have a Windows product. For a bootstrapped startup where the founder is also the entire platform team, that's a sobering fork. We took the certification path, and I want to describe what's actually behind that word, because almost nobody in the cloud-native world talks about it — most vendors never come this way.

## What the gauntlet actually looks like

HLK certification is not a form you fill in. It's a physical test lab you must build, even if "physical" means cloud VMs.

Ours was two machines in Azure: an HLK *controller* running the test orchestration, and a *client* running the exact target build — Windows Server 2022 — with your driver installed, taking the beating. You install test agents, join the machines into a test pool, create a project, and point a few hundred tests at your driver: correctness tests, API-usage validation, stress tests, fuzzing, Driver Verifier runs, security checks. Then Microsoft's *playlist* — the official list of which tests your device class must pass — decides what counts.

The tests themselves are where the humility sets in. Some failures are your driver. Many are the lab: a test that hangs because it's waiting for an interactive prompt in a session that, by design, has no interactive user. A networking suite that fails until you discover — in a decade-old OSR forum thread, the true institutional memory of Windows driver development — that it misbehaves when the primary adapter has a particular binding enabled, and the fix is one PowerShell line nobody will ever tell you officially. You learn to read test logs the way archaeologists read strata.

And then there's the INF file — the driver's installation manifest, a format whose conventions date back decades. Our first attempt at packaging technically worked, but the generated package cheerfully advertised support for Windows 2000, XP, and Vista, because we'd omitted a section whose absence means "all Windows, forever." Fixing it properly meant learning INF architecture decades of Windows history deep: OS-decorated sections targeting the exact build, modern isolation requirements, the blessed directory for driver binaries. None of this is hard the way distributed systems are hard. It's hard the way *old* things are hard: the knowledge is scattered, the error messages are oblique, and the people who know are mostly on forums, generously answering questions asked fifteen years ago.

Where a test failure is genuine but explainable — a validation rule that flags uncommon-but-legitimate API usage, a known test-suite bug with a documented history — Microsoft's process has a mechanism: *errata*, a written justification for each item, submitted with your results. Writing good errata turns out to be its own discipline. You're making a technical argument to a reviewer you'll never meet, and the argument has to demonstrate that you understand the platform better than the failing test does. We treated ours like a legal brief: references, quantified scope, and honest attestations that matched what the driver actually does rather than what would pass most smoothly.

## The final boss nobody warned us about

After days and weeks of test runs, reruns, and errata drafting, you export your results as a submission package — an `.hlkx` file — and there's one last requirement before Microsoft's portal will take it: **the package itself must be signed with your EV certificate.**

Should be trivial. Our EV certificate lives where a code-signing certificate for a kernel driver *should* live: in an Azure Key Vault Premium HSM, non-exportable, so the private key physically cannot leave the hardware module. Best practice, exactly what you'd want to tell an enterprise customer.

Except: an `.hlkx` is not a normal binary. It's an OPC package — the same container format as `.docx` and `.nupkg` — and it isn't Authenticode-signed at all. `signtool` rejects it outright. So does the standard Azure signing tooling. Microsoft signs these packages with XML digital signatures embedded *inside* the package, and the documented path for that assumes your certificate is available in ways an HSM-backed, non-exportable key simply isn't. The .NET packaging API that should handle it internally tries to export the private key — which is the one thing an HSM exists to never allow. Even Microsoft's own modern signing tool got us tantalisingly close before failing on a format detail specific to HLK packages.

So there we were: driver tested, results clean, errata written — and unable to put the last signature on the box, because doing key custody *properly* had made us incompatible with the submission tooling. It's a small, perfect example of the gap this whole certification story lives in: the intersection of "modern cloud security practice" and "Windows hardware certification" is a place very few people have stood, and the paths are not paved.

We did what you do. We read how the signature format actually works, studied the open-source implementations that came closest, and wrote a small tool: it builds the OPC XML signature by hand, computes the hashes locally, and sends *only the hash* to Key Vault for signing — the private key never leaves the HSM, which is the entire point. It signed the package. The portal accepted it.

Some days later — Microsoft's human review is measured in business days, and there's nothing to do but refresh — the submission came back approved. A Microsoft-signed kernel driver, certified for Windows Server 2022 — earned by a bootstrapped startup, on nights and weekends, on the far side of every wall described above.

![Microsoft Hardware Certification Report — Approved](https://cdn.hashnode.com/uploads/covers/69d65cc5707c1ce7683c466b/289ad207-399c-412d-ba11-03ca3a95e6d8.png align="center")

*The certification report: approved for the Windows Hardware Compatibility Program, Server family 21H2 x64, as a Universal API, Declarative INF driver.*

And because this is the kind of claim that should never require trusting a vendor's screenshot: the certification is independently verifiable on Microsoft's public [Windows Server Catalog](https://www.windowsservercatalog.com/product/c2a6cbe3-35f7-0a23-3616-7e640120246a), and Microsoft provides the [full certification report](https://partner.microsoft.com/en-us/dashboard/hardware/Driver/DownloadCertificationReport/94295680/14315147326148313/1152921505701103304) as a shareable download for exactly this purpose.

## The tool is yours now

The signing wall was the most needless of them — not deep, just undocumented — and the next person who stores their EV cert in an HSM (as they should) will hit it exactly as we did. So we've open-sourced the tool: [**HLKSigner**](https://github.com/tracenyx/hlksigner), a small .NET utility that signs HLK submission packages against an HSM-backed Azure Key Vault certificate. README covers the auth setup, the verification steps, and why the obvious tools fail. If it saves one driver developer the days it cost us, it's done its job.

## Why we'd do it again

It would be easy to read this as a complaint about Microsoft's process. It isn't. The gauntlet is the point: production Server kernels refuse uncertified code *because kernel code can do anything*, and an enforcement driver — software whose whole job is dropping packets with kernel authority inside regulated enterprises — is exactly the code that should have to earn its signature. The process is demanding because the bar should be.

That's also why we tell prospective customers, without hedging: if a vendor claims kernel-level enforcement on Windows Server, the Microsoft certification is the receipt to ask for. Not because it's a badge — because the kernel literally will not load the driver without it. It's the rare marketing claim that's mechanically enforced by the operating system.

The certification now sits at the bottom of Nyx's Windows story the way foundations sit under buildings: invisible in the product screenshots, load-bearing for everything above. And the lab is still there in our Azure tenancy, quietly waiting — because every future Windows Server version, and every significant driver change, means going through the gauntlet again. We knew that going in. The moat is a moat precisely because you have to keep swimming it.

* * *

*The Nyx Windows dataplane this driver powers — and the eBPF Linux dataplane beside it — are live now, with a free tier at* [*tracenyx.ai*](https://tracenyx.ai)*. Friday's post,* [*Why eBPF stops at the Windows node boundary*](https://blog.tracenyx.ai/why-ebpf-stops-at-the-windows-node-boundary)*, covers the architecture. HLKSigner is on* [*GitHub*](https://github.com/tracenyx/hlksigner)*.*