SBOM requirements for applicable driver submissions beginning with Windows release in 2027

Summary​

Microsoft is continuing to raise the security bar for the Windows driver ecosystem. Beginning with applicable driver submissions for the Windows client / server release in 2027 and later, partners will be expected to provide a valid Software Bill of Materials (SBOM) as part of the signing submission. This requirement is intended to improve supply-chain transparency, support vulnerability response, and help partners prepare for evolving ecosystem and regulatory expectations. Microsoft is introducing this WHCP requirement as part of a broader security-hardening effort for applicable driver submissions.

What is changing​

• All driver submissions for the Windows client / server release in 2027 and later will require a valid SBOM in the Software Package Data Exchange (SPDX) 3.0.1 format.
• Enforcement is planned to begin with the RTM date for the Windows client / server release in 2027.
• Older OS certifications are not retroactively brought into scope. A later submission for an older target, such as Windows 25H2, Windows 24H2, or Windows 10, will not automatically inherit the new requirement solely because it was submitted after enforcement begins.
• HLK will support a user experience at packaging time to be able to add SBOMs into a separate folder for a driver package. HLK will also validate the presence of an SPDX SBOM and block packaging if not present.
• HDC will verify that the required SBOM is present and conforms to the supported SPDX 3.0.1 schema and required fields.
• Any driver submission without a valid SPDX 3.0.1 formatted SBOM will not be signed by HDC

Who this affects​

This requirement applies to partners who develop, sign, or submit applicable driver packages through HDC for the Windows client / server release in 2027 and later. The scope is tied to that release and later OS releases rather than every historical WHCP or attestation submission. Additional guidance will clarify how the requirement applies across HLK-certified and attestation-signed driver submissions before enforcement begins.

Partners should review their upcoming driver submission plans now and identify which packages are expected to target the Windows client / server release in 2027 or later. Those packages should have a repeatable process for generating, validating, signing, and retaining the required SBOM artifact.

Tooling and submission expectations​

Partners may use any tool of their choice to generate the SBOMs, provided the resulting artifact meets Microsoft’s documented SPDX 3.0.1 requirements. Microsoft plans to make tooling and documentation available separately from the enforcement requirement. The documentation will describe the supported schema, required fields, validation behavior, and HDC submission experience. The Microsoft tool will be made available as a part of WDK in early 2027. Partners should therefore focus on producing a valid, and current SBOM that can be associated with the driver package being submitted.

What partners should do now​

• Familiarize engineering, security, release, and compliance teams with SBOM concepts and SPDX 3.0.1 terminology.
• Inventory first-party, third-party, and open-source components used in driver binaries and the associated build process.
• Evaluate SBOM generation options and decide whether to use Microsoft tooling or another compliant generator.
• Plan how each applicable driver package will produce an SBOM when submitted, updated, or resubmitted.
• Monitor future WHCP and HDC documentation for the final enforcement date, required fields, validation behavior, and submission experience.

SBOM placement and naming​

• Place the required SBOM file in the SBOM location identified by the HLKx or HDC submission experience.
• Provide the required SBOM for each applicable driver package. A driver package refers to a driver INF file and the corresponding set of binaries for that package.
• Do not use a single SBOM to cover an entire submission that contains multiple driver packages.
• Do not place SBOM files in the supplemental documents folder unless future HDC documentation explicitly instructs partners to do so.
• Name the SBOM file to match the INF name: <inf_name>.spdx.json.
• SBOMs will not be distributed to end users as part of a driver package.

Format and technical requirements​

• Required SBOMs must use the supported SPDX 3.0.1 format and include the required fields documented by Microsoft.
• SBOMs should identify first-party and third-party components, including tools, libraries, frameworks, and dependencies needed to understand the driver package supply chain.
• Components should include accurate versions and package identifiers where available to support vulnerability tracking and response.
• Microsoft will retain SBOMs for internal use only. It will not be externally distributed.

Required fields for an SBOM​

Next steps​

Microsoft will continue to share updates as the policy, tooling, and submission experience are finalized. Partners with questions should contact Partner Center support and reference this requirement announcement.