The distinction matters. Microsoft’s announced enforcement point is the WHCP submission process for enrolled partners using Hardware Dev Center. A submission in scope that lacks the required documentation, or whose documentation fails validation, will not receive a WHCP signature. That can block a vendor’s intended certification and distribution path, but the material announced does not establish a new runtime rule that invalidates drivers already signed or prevents every other possible route by which a driver might be distributed.
What changes in March 2027
Microsoft announced on September 2, 2026 that WHCP-signing submissions for specified newer Windows releases will require a Software Bill of Materials (SBOM) in SPDX 3.0 format and Vulnerability Exploitability eXchange (VEX) information. The announced scope starts with submissions for Windows 11 25H2 and 26H1, plus Windows Server 2025 and later builds.
The requirement applies to two important submission paths:
- Drivers certified through the Hardware Lab Kit (HLK).
- Drivers submitted through the attestation-signing route.
In practical terms, a partner that relies on a WHCP signature for an in-scope driver package will have another deliverable to prepare, validate, and maintain. Microsoft has stated that a submission without the necessary SBOM and a VEX statement when applicable—or one whose supplied artifacts fail validation—will not receive a WHCP signature.
That wording leaves an important open question. Microsoft has not yet publicly defined the situations in which a VEX statement is considered “applicable.” Developers should not assume that every package will necessarily use VEX in precisely the same way, nor should they assume the qualifier creates a broad exemption. Until the detailed guidance arrives, the prudent reading is that teams need to design a process capable of producing both forms of information when the submission rules call for them.
Microsoft has provided only the month, March 2027, rather than an exact effective day or a published transition process for submissions already in progress. That makes release planning more important for vendors with certification work scheduled around that period.
SBOM and VEX: why Microsoft wants both
An SBOM is an inventory of software components in a product. In the driver context, it is intended to give a structured account of the components and dependencies associated with a driver package. The announced format is SPDX 3.0, a standardized way to represent this type of software supply-chain data.
Microsoft’s outlined requirements go beyond a basic list of visible files. The announced submission guidance calls for first-party and third-party components, transitive dependencies, package identifiers, and versions. It also calls for COSE integrity signatures. Those details are central: a manually maintained dependency list that omits indirect components or does not meet the required artifact structure may not satisfy submission validation.
VEX information serves a related but different purpose. Vulnerability data can identify that a component has a known issue, but that alone does not answer whether the issue is exploitable in a particular driver package or configuration. VEX is intended to communicate vulnerability status and exploitability context. The combination gives software suppliers a more useful basis for responding when a vulnerability affects a dependency in a released or planned driver.
For driver suppliers, this moves vulnerability tracking closer to a formal release requirement. Engineering, security, build, legal, and release-management teams may all need input into the eventual submission workflow. A component inventory has to reflect what the build actually contains; vulnerability assertions need a defensible process; and both must arrive in the right package structure before a signing submission can succeed.
The unit of compliance is each driver, not a bundle
One of the most operationally important aspects of the announcement is its definition of a driver. Microsoft describes a driver as one INF file and its associated set of binaries. Each such driver needs its own SBOM and VEX artifact.
That means a multi-driver submission cannot rely on one high-level SBOM or one combined VEX document for the whole bundle. A vendor shipping several INF-based drivers—perhaps for different hardware functions, architectures, or device components—will need to treat the documentation as a per-driver deliverable.
Microsoft’s proposed packaging approach puts these artifacts in a subfolder within the driver package, rather than in Supplemental Documents. The suggested naming convention is based on the INF name, using filenames in the form:
<inf_name>.spdx.json<inf_name>.vex.json
This may sound like a small packaging detail, but it affects automation. Build systems will need a reliable way to associate the right inventory and vulnerability information with the correct INF and binaries. Teams that package drivers by hand, or that share component inventories across several driver packages, are likely to face more process change than organizations with mature automated build and dependency-management systems.
The requirement also creates a version-control challenge. A change to a binary, included component, or transitive dependency can make existing documentation stale. A robust workflow will need to regenerate or revalidate artifacts as part of release preparation rather than treating the SBOM as static paperwork created once per product.
Tools are promised, but implementation details are not final
Microsoft says Windows Driver Kit tooling and detailed documentation are expected by December 2026. The planned tooling is intended to generate compliant SBOMs, validate SBOMs, and generate VEX statements. Microsoft has also said that third-party and open-source tooling may be used, provided the final artifacts are valid SPDX 3.0.
That flexibility is useful for vendors that already have software-composition-analysis or SBOM-generation systems. They may be able to integrate an existing pipeline rather than replace it wholesale. Yet compatibility at the artifact level does not guarantee that every existing tool chain will meet Microsoft’s eventual submission validation expectations without adjustment. The announced policy, tooling, and submission experience are still being finalized.
The gap between the expected tooling date and the March 2027 enforcement date is also relatively short for organizations that need to alter build systems, procure new security tools, validate suppliers’ component records, and retrain release teams. The safest early preparation is organizational rather than speculative: identify every driver package, map each INF to its binaries, determine how dependencies are currently tracked, and establish ownership for vulnerability-status decisions.
Developers should avoid treating preliminary file names or currently described validation requirements as the last word. Once Microsoft publishes its detailed documentation and WDK implementation, teams will need to test their real packages against the actual tooling and revise their submission automation accordingly.
What is outside the stated scope
The announcement draws meaningful boundaries around the initial policy. Driver packages submitted before March 2027 are outside this documentation requirement. So are certification submissions for builds that predate Windows 11 25H2 and 26H1 and Windows Server 2025.
Those exclusions should not be stretched beyond their wording. Microsoft says packages submitted before March 2027 are excluded; it has not said that a package merely prepared, started, or expected to complete before then receives the same treatment. Nor has it specified an exact day in March or a grace period for in-flight submissions.
There is another ambiguity in the release list. Microsoft explicitly names Windows 11 25H2 and 26H1, along with Windows Server 2025 and later builds. The reviewed material does not spell out how a later client release such as a hypothetical Windows 11 26H2 would be handled. It is reasonable to expect further clarification as the policy is finalized, but that expectation is not a published scope statement.
Most importantly for ordinary PC owners, there is no announced instruction to remove drivers, reinstall existing drivers, or manually create SBOM files. The documentation is not intended for inclusion as an end-user-facing item in a normal driver package. The direct burden falls on WHCP-enrolled hardware partners and their supply chains.
The Cyber Resilience Act context—and its limits
Microsoft describes the new policy as driven by Cyber Resilience Act (CRA) compliance obligations. The European Union regulation includes SBOM-related information in the technical documentation expected for vulnerability-handling processes. That creates a clear policy rationale for bringing structured component and vulnerability information into a driver certification workflow.
Still, Microsoft’s WHCP deadline should not be confused with the CRA’s general application date. The CRA is scheduled to become fully applicable on December 11, 2027, while its reporting obligations begin earlier, on September 11, 2026. Microsoft’s March 2027 signing requirement is therefore an earlier program deadline set by Microsoft, not simply the date on which the CRA broadly takes effect.
The distinction is relevant when assessing VEX. The reviewed CRA material refers to the software bill of materials but does not expressly name VEX. Microsoft’s decision to request VEX information is part of its announced WHCP approach; it should not be described as a verbatim statutory requirement based on the material available here.
What Windows users and IT teams should expect
For consumers, the near-term practical consequence is indirect. If vendors adapt successfully, the change may be largely invisible: drivers will continue to arrive through normal vendor and Windows distribution channels. The intended benefit is stronger traceability when software components are later associated with security vulnerabilities.
The immediate risk is concentrated on driver suppliers. A failed documentation check can delay WHCP signing for an affected package, and a signing delay can in turn disrupt a vendor’s planned driver release. However, no reviewed evidence establishes that these rules will cause widespread delays, higher device prices, or compatibility problems. Those outcomes are possible concerns, not established results.
Enterprise IT teams do not need to alter deployed driver packages based solely on this announcement. They should, however, ask strategic hardware vendors how they are preparing for SBOM and VEX submissions, especially where upcoming Windows 11 25H2, 26H1, or Windows Server deployments depend on newly certified drivers. Procurement and security teams may also find that vendor conversations about component transparency become more concrete as the deadline approaches.
For developers, the message is more immediate: treat the policy as a forthcoming release-engineering requirement, not as an administrative attachment to add at the end. Per-INF component tracking, dependency provenance, vulnerability review, artifact integrity, and package validation will need to work together. Microsoft’s final tooling and documentation will determine the exact implementation, but waiting until March 2027 to build that process would leave little margin if a submission needs correction before it can receive a WHCP signature.
The bottom line is narrower than claims that “Windows will reject drivers,” but it is still material. Microsoft is putting supply-chain evidence into the WHCP signing gate for newer Windows and Windows Server targets. For the companies building and certifying drivers, that changes what a shippable package must prove—not just what it must do.