🚀 NEW

Generate Embedded SBOM for C/C++

⚡ Windows Hardware Compatibility Program

`Windows Driver SBOM Requirements for WHCP Submissions`

Q: When does the WHCP SBOM requirement take effect?

Microsoft plans to enforce it from the RTM date of the 2027 Windows release. The final date hasn't been published yet.

Q: What SBOM format does Microsoft require for drivers?

SPDX 3 (currently version 3.0.1), as a JSON file named after the driver's INF file. CycloneDX isn't accepted for this requirement.

Q: Can one SBOM cover a submission with several drivers?

No. Each driver package, meaning one INF and its binaries, needs its own SBOM.

Q: Do I still need to submit a VEX statement?

Not as part of the submission. Since the October 2026 update, Microsoft wants vulnerability data kept out of the SBOM and shared separately, for example as CSAF or VEX.

Q: Do I have to use Microsoft's WDK tool?

No. Any generator that produces a compliant SPDX 3 SBOM is allowed. Microsoft's tool is expected in the WDK in early 2027.

Q: Does the requirement apply to drivers for Windows 11 24H2 or Windows 10?

No. Older targets aren't pulled in just because a driver is submitted after enforcement starts.

Q: How does the WHCP SBOM relate to the EU Cyber Resilience Act?

Microsoft's required fields follow BSI TR-03183-2, the German guideline many manufacturers use for the CRA. So a driver SBOM that meets Microsoft's rules can also go into your CRA technical documentation.

From the 2027 Windows release, Microsoft won’t sign a driver without an SPDX 3 SBOM for each driver package. lynkctl generates it straight from your MSBuild and WDK build.

Trusted by regulated product teams preparing for

WHCP

Trusted by regulated product teams preparing for

WHCP

Trusted by regulated product teams preparing for

WHCP

IN SHORT

Starting with the 2027 Windows client and server release, Microsoft won't sign a driver through the Hardware Dev Center (HDC) unless every driver package ships with a valid SPDX 3 SBOM.

Each package gets its own SBOM, named after its INF file, listing every component with its SHA-512 hash, license and dependencies. Without it, HLK won't package the submission. If it's missing or fails validation, HDC won't sign.

Microsoft is adding its own SBOM tool to the WDK in early 2027. You don't have to wait for it. Any generator that produces a compliant SPDX 3 file is accepted.

Starting with the 2027 Windows client and server release, Microsoft won't sign a driver through the Hardware Dev Center (HDC) unless every driver package ships with a valid SPDX 3 SBOM.

Microsoft is adding its own SBOM tool to the WDK in early 2027. You don't have to wait for it. Any generator that produces a compliant SPDX 3 file is accepted.

OVERVIEW

What is the WHCP driver SBOM requirement?

The Windows Hardware Compatibility Program (WHCP) is what hardware partners go through to get their drivers signed by Microsoft. For the 2027 Windows client and server release and later, each applicable driver submission must include a Software Bill of Materials: a list of what's in the driver package, with file hashes and licenses. Microsoft's field list comes from Germany's BSI TR-03183-2 guideline, which many manufacturers already use for the EU Cyber Resilience Act.

SPDX 3

The only accepted SBOM format

1 per package

One SBOM for each INF and its binaries

SHA-512

Hash required for every component

2027

First Windows release it applies to

TIMELINE

WHCP SBOM Timeline and Key Dates

Date

Milestone

What it means

September 2026

First announcement

Microsoft says WHCP driver submissions will need an SBOM and a VEX statement. Replaced by the October post.

21 October 2026

Requirements revised

Microsoft pins the format to SPDX 3.0.1 and ties the scope to the 2027 Windows release. VEX is no longer part of the submission.

Early 2027

Microsoft SBOM tool in the WDK

Microsoft's generator ships in the Windows Driver Kit. Other tools are still allowed.

2027 Windows release (RTM)

Enforcement begins

HLK and HDC start checking applicable submissions. Microsoft will publish the final date.

SCOPE

Who Does the WHCP SBOM Requirement Affect?

It covers applicable driver packages submitted through HDC for the 2027 Windows client or server release or later. In practice that means IHVs, OEMs, ODMs and anyone else shipping a signed driver for their hardware.

Microsoft's announcement names three roles.

Developers

Teams that build the driver package and its binaries, including code from silicon vendors and other suppliers.

Signers

Partners who get the driver signed through WHCP, whether through HLK certification or attestation.

Submitters

Anyone who uploads driver packages to the Hardware Dev Center on a company's behalf.

Note: Older targets stay out of scope. A driver for Windows 25H2, 24H2 or Windows 10 doesn't need an SBOM, even if you submit it after enforcement begins.

REQUIRED FIELDS

Required SBOM fields

About the SBOM

Creator email or URL, and a creation timestamp.

Every component

Creator, name, version, filename, license as an SPDX identifier, SHA-512 hash, and whether it's an executable, archive or structured file.

Relationships and depth

Direct dependencies or contained components, plus a completeness status. Each path is resolved at least as far as the first component you don't deliver yourself.

When available

SBOM URI, source URI, PURL or CPE, and original licenses. A new SBOM for every version.

THE HARD PART

Why Are Driver SBOMs Hard to Generate?

Most SBOM generators start by reading a package manifest. A Windows driver usually doesn't have one. It's C or C++ built with MSBuild and the WDK, often with source copied in from a silicon vendor's SDK and static libraries linked at build time.

☑️ No package manager, so dependencies have to come from the build itself

☑️ Vendored and modified source with no version metadata

☑️ Static libraries that leave no trace in the final binary's imports

☑️ A SHA-512 hash for every file actually shipped

☑️ Licenses stated as SPDX identifiers, not free text

☑️ A separate SBOM for each INF in a multi-driver submission

{
  "@context": "https://spdx.org/rdf/3.0.1/spdx-context.jsonld",
  "@graph": [
    {
      "type": "software_File",
      "spdxId": "urn:contoso:file:contoso.sys",
      "creationInfo": "_:creationinfo",
      "name": "contoso.sys",
      "software_primaryPurpose": "executable",
      "verifiedUsing": [{
        "type": "Hash",
        "algorithm": "sha512",
        "hashValue": "9f2c4e…"
      }]
    },
    …
  ]
}

Package scanners built for npm or PyPI projects miss most of this. To pass HDC validation, a driver SBOM needs to be generated from the build itself.

SUBMISSION CHECKS

What Will HLK and HDC Check?

Your SBOM gets checked twice. The Hardware Lab Kit (HLK) looks for it when you package a submission. Then the Hardware Dev Center (HDC) validates it against Microsoft's schema and required fields before signing.

1 per INF

One SBOM for each driver package, never one for the whole submission

.spdx.json

Named after the INF file: <inf_name>.spdx.json

Named after the INF file

HLK

Blocks packaging if the SBOM is missing

HDC

Rejects signing if it's missing or invalid

TARGET

IN SCOPE

WHY

Windows client or server release in 2027 and later

Yes

In scope: Yes

The requirement is written for these releases

Windows 11 25H2, 24H2 and Windows 10

In scope: No

Older targets aren't pulled in, even if submitted after enforcement starts

Multi-driver submission

Yes, per package

In scope: Yes, per package

Each driver package needs its own SBOM

WORTH KNOWING

Put the SBOM where HLK or HDC tells you to, not in the supplemental documents folder.
Vulnerability and exploitability data stays out of the SBOM. Microsoft asks for it to be shared separately, for example as CSAF or VEX.
Signing the SBOM is recommended but not required.
Microsoft keeps the SBOM for internal use. It isn't shipped to end users.
Any compliant generator is allowed. You don't have to wait for the WDK tool.

Put the SBOM where HLK or HDC tells you to, not in the supplemental documents folder.
Vulnerability and exploitability data stays out of the SBOM. Microsoft asks for it to be shared separately, for example as CSAF or VEX.
Signing the SBOM is recommended but not required.
Microsoft keeps the SBOM for internal use. It isn't shipped to end users.
Any compliant generator is allowed. You don't have to wait for the WDK tool.

BEYOND THE MINIMUM

Is Passing HDC Validation Enough?

PASSES HDC

HOLDS UP

Depth

Through the first component outside your delivery

Passes HDC: Through the first component outside your delivery

✓ Full transitive dependency tree

Cadence

Generated for each submission

Passes HDC: Generated for each submission

✓ Regenerated on every build

Vulnerability data

Kept outside the SBOM

Passes HDC: Kept outside the SBOM

✓ Monitored for new CVEs, with VEX

Reuse

WHCP only

Passes HDC: WHCP only

✓ The same SBOM serves CRA technical documentation

PLATFORM

How Interlynk Helps

lynkctl builds the SBOM from your MSBuild and WDK projects. The Interlynk platform stores it and keeps tracking its components after the driver is out.

SPDX 3 from the build

lynkctl reads your MSBuild and WDK projects directly, so vendored code and static libraries end up in the SBOM.

SBOM per package

lynkctl splits output per INF and names it <inf_name>.spdx.json to comply with WHCP requirements.

Air-Gapped

lynkctl runs fully offline, so build machines never need outside access to produce the SBOM.

Separate VEX

The platform watches each component for new CVEs and keeps VEX separate from the SBOM, as Microsoft requires.

FAQ

FAQs

Do Windows drivers need an SBOM?

Yes, if the driver targets the 2027 Windows client or server release or later. Every applicable package you submit through HDC for WHCP signing needs a valid SPDX 3 SBOM.

When does the WHCP SBOM requirement take effect?

What SBOM format does Microsoft require for drivers?

Can one SBOM cover a submission with several drivers?

Do I still need to submit a VEX statement?

Do I have to use Microsoft's WDK tool?

Does the requirement apply to drivers for Windows 11 24H2 or Windows 10?

How does the WHCP SBOM relate to the EU Cyber Resilience Act?

Trusted by 100+ Organizations

Get Your Drivers Ready for WHCP

Produce an SPDX 3 SBOM for every driver package from the MSBuild and WDK setup you already have, well before HDC starts checking.

Windows Driver SBOM Requirements for WHCP Submissions

What is the WHCP driver SBOM requirement?

What is the WHCP driver SBOM requirement?

SPDX 3

1 per package

SHA-512

2027

WHCP SBOM Timeline and Key Dates

WHCP SBOM Timeline and Key Dates

Who Does the WHCP SBOM Requirement Affect?

Who Does the WHCP SBOM Requirement Affect?

Developers

Signers

Submitters

Required SBOM fields

Required SBOM fields

About the SBOM

About the SBOM

Every component

Every component

Relationships and depth

Relationships and depth

When available

When available

Why Are Driver SBOMs Hard to Generate?

Why Are Driver SBOMs Hard to Generate?

What Will HLK and HDC Check?

What Will HLK and HDC Check?

1 per INF

.spdx.json

HLK

HDC

Is Passing HDC Validation Enough?

Is Passing HDC Validation Enough?

How Interlynk Helps

How Interlynk Helps

SPDX 3 from the build

SBOM per package

Air-Gapped

Separate VEX

FAQs

FAQs

Do Windows drivers need an SBOM?

When does the WHCP SBOM requirement take effect?

What SBOM format does Microsoft require for drivers?

Can one SBOM cover a submission with several drivers?

Do I still need to submit a VEX statement?

Do I have to use Microsoft's WDK tool?

Does the requirement apply to drivers for Windows 11 24H2 or Windows 10?

How does the WHCP SBOM relate to the EU Cyber Resilience Act?

Get Your Drivers Ready for WHCP

Get Your Drivers Ready for WHCP

Features

SBOM Automation

Open Source Management

Supplier Monitoring

Post Quantum Readiness

LynkMCP

Solutions

FDA 524B Compliance

CRA Compliance

Embedded C/C++ SBOM

Windows Driver SBOM

Resources

Guides

Blog

News

Docs

Open Source Tools

Comparisons

References

Company

About Us

Contact

Privacy Policy

Features

SBOM Automation

Open Source Management

Supplier Monitoring

Post Quantum Readiness

`Windows Driver SBOM Requirements for WHCP Submissions`