Hardware Dev Center articles

Introducing Control Over Driver Update Acceptance (DUA) Creation on Shared Driver Submissions

Cymoki — Mon, 20 Apr 2026 23:14:33 GMT

As part of Microsoft’s commitment to improving Windows quality through more predictable and reliable update delivery, we are introducing a new capability that will give submission owners control over Driver Update Acceptance (DUA) creation on shared submissions. This opt-in, per-sharing-shipping-label control will allow submission owners to explicitly block receivers from creating DUA submissions on shared content — providing greater flexibility and control over driver distribution. Receivers who use automation to create DUA submissions on shared products should update their code to handle the new error responses. Default behavior will remain unchanged — DUA creation will be allowed unless the owner explicitly enables the block.

Note: This blog is intended for Microsoft partners who share or receive shared driver submissions through the Partner Center portal or API.

What's Changing

A new per-sharing-shipping-label control will allow submission owners to block DUA creation by receivers of shared submissions. When selected on a sharing shipping label, receivers will not be able to:

Download the DUA shell
Create new DUA (derived) submissions

The only allowed action on a DUA-blocked shared submission is publishing the driver to Windows Update as-is.

Timeline

This new feature and the API will be available Starting May 18th.
Documentation and resources will be published before general availability

For Submission Owners

In the Partner Center Portal

When creating or editing a sharing shipping label, you will see a new option under the Properties section to block DUA creation by the receiver.

The option is off by default — existing behavior is preserved unless you opt in.
You can enable or disable this setting at any time, even on existing shipping labels.
The setting applies per sharing shipping label. Different shipping labels for the same submission can have different DUA policies.
If you share to multiple partners in a single request, the same setting applies to each resulting shipping label.

In the API

A new boolean field blockDuaCreation will be added to the existing recipientSpecifications object on sharing shipping labels, alongside the existing enforceChidTargeting property. It will be available in POST (create), GET (read), and PATCH (update) shipping label calls.

Creating a shipping label (POST):

{
    "recipientSpecifications": {
        "receiverPublisherId": "2600000",
        "enforceChidTargeting": false,
        "blockDuaCreation": true
    }
}

Reading a shipping label (GET): The blockDuaCreation field will be returned in the response so you can confirm the current setting.

Updating a shipping label (PATCH): You can now include recipientSpecifications (with blockDuaCreation and enforceChidTargeting) in the PATCH payload.

{
    "recipientSpecifications": {
        "blockDuaCreation": true,
        "enforceChidTargeting": true
    },
    "targeting": {
        .
        .
    }
}

For Submission Receivers

In the Partner Center Portal

When a submission owner has blocked DUA creation on a shared submission:

The "Upload new" and "Download DUA shell" buttons will be disabled (greyed out).
A message will be displayed: "Driver Update Acceptance (DUA) creation has been restricted by the submission owner. The DUA shell is not available for download."

You can still create publishing shipping labels and publish the shared driver to Windows Update.

In the API

GET Submission: When DUA creation is blocked, the derivedPackage download link will be excluded from the response, and a restriction message will be included:

{
    "downloads": {
        "items": [
            { "type": "initialPackage", "url": "..." },
            { "type": "signedPackage", "url": "..." },
            { "type": "driverMetadata", "url": "..." }
        ],
        "messages": [
            {
                "message": "Driver Update Acceptance(DUA) creation has been restricted by the submission owner. The DUA shell is not available for download."
            }
        ]
    }
}

POST Create Derived Submission: Attempting to create a DUA submission when blocked will return HTTP 412 Precondition Failed:

{
    "error": {
        "code": "DUACreationNotAllowed",
        "message": "Driver Update Acceptance(DUA) creation has been restricted by the submission owner for this shared submission."
    }
}

Action Required for API Consumers

If your automation creates DUA submissions on shared products, you must update your code to handle:

The new DUACreationNotAllowed error code (HTTP 412) when attempting to create a derived submission.
The potential absence of derivedPackage in the downloads.items list when calling GET Submission.
The new messages array in the downloads response, which will contain a restriction message when DUA creation is blocked.

Failing to handle these responses may cause your automation to break when an owner enables the DUA block on a submission shared with you.

Next Steps

Review your current sharing and DUA workflows to understand where this control might benefit your scenarios.
Engage with your partner counterparts to discuss how this feature might affect your existing agreements.
Update your API automation to handle the new DUACreationNotAllowed error code (HTTP 412) and the absence of derivedPackage and the new messages array in the downloads response in GET Submission responses if you create DUA submissions on shared products.
Contact support if you have questions or concerns about this capability through the Partner Center support channel.

⚠️ Important: Avoid strict JSON parsing

The Hardware Dev Center API may add new properties to responses at any time as part of non-breaking, additive changes. Your client must not use strict JSON deserialization that rejects unknown properties.

- - System.Text.Json — Do not set JsonSerializerOptions.UnmappedMemberHandling = JsonUnmappedMemberHandling.Disallow. The default behavior (ignoring unknown properties) is correct.
  - Newtonsoft.Json — Do not set MissingMemberHandling = MissingMemberHandling.Error. The default behavior is correct.
  - General — If you use schema validation or strict contracts, ensure they allow additional properties.

This applies to all Hardware Dev Center API responses, not just this change.

FAQs

Q: Will my existing DUA submissions be affected when the owner enables the block?
A: No. Existing DUA submissions are not retroactively affected. The block only prevents future DUA creation on the shared submission.

Q: Can the owner change the setting after the shipping label is already shared?
A: Yes. The owner can enable or disable the block at any time via the Partner Center portal or the PATCH API. The change takes effect immediately.

Q: Does this require a new API version?
A: No. The blockDuaCreation field is an additive, non-breaking change. Existing API clients that do not send or read this field will continue to work as before.

Q: What happens if the owner blocks DUA on one shipping label but not another for the same submission?
A: Each shipping label has its own DUA policy. A receiver will be blocked from creating DUAs only on the specific shared submission associated with a shipping label where the block is enabled.

Q: I receive shared submissions from multiple partners. Do I need to change anything right now?
A: If your automation creates DUA submissions on shared products, you should update your code to handle the new error responses. If you only publish shared drivers to Windows Update without creating DUAs, no changes are needed.

Q: What if I need DUA for a specific shared submission where the owner has blocked it?
A: Work directly with the submission owner. They can disable the block on the relevant shipping label at any time via the portal or the PATCH API, and the change takes effect immediately.

Q: Can I block DUA for specific Hardware IDs on a shipping label?
A: No. The setting applies to the entire sharing shipping label. Use separate shipping labels if you need different DUA policies per Hardware ID.

Additional Information

DUA documentation: Hardware submission update (DUA)
Hardware API documentation: Hardware API

Upcoming changes to driver metadata and publishing validations in Hardware Dev Center

Cymoki — Thu, 16 Apr 2026 04:03:29 GMT

We're making improvements to how the Windows Hardware Dev Center (HDC) handles driver OS compatibility. These changes will help reduce driver installation failures caused by drivers being offered to Windows versions outside their supported range.

This post explains what's changing, what you need to know, and what — if any — action you may need to take.

What's changing

New field in HardwareDriverMetadata: CeilingOsCode

We are adding a new nullable string property, CeilingOsCode, to the per-PnP entries in the HardwareDriverMetadata asset (documented at Driver package metadata ). This field represents the maximum OS version that a given hardware ID (PnP) supports, as determined by the INF file's OS version decorators.

Note: The CeilingOsCode field will only be populated for packages submitted after the feature rollout date. Packages submitted before this date will not have this field in their metadata — it will not be backfilled for existing submissions.

If you use the Hardware Dev Center API to retrieve driver metadata — via Get a submission  (the driverMetadata link) or Create Publisher Metadata  — the OSPnPInfoMap entries in the response will now include this additional property.

Example — before:

Response excerpt:

"OSPnPInfoMap": {

"WINDOWS_v100_RS3_FULL": {

"pci\\ven_test&dev_abcd": {

"Manufacturer": "RAID",

"DeviceDescription": "Virtual Raid Adapter",

"FeatureScore": null

}

Example — after:

Response excerpt:

"OSPnPInfoMap": {

"WINDOWS_v100_RS3_FULL": {

"pci\\ven_test&dev_abcd": {

"Manufacturer": "RAID",

"DeviceDescription": "Virtual Raid Adapter",

"FeatureScore": null,

"CeilingOsCode": "WINDOWS_v100_X64_20H1_FULL"

}

Do I need to take action?

In most cases, no. This is an additive change. The new property is nullable — it will be null when no OS ceiling is detected for a hardware ID. Standard JSON parsers (including Newtonsoft.Json and System.Text.Json) handle new, unknown properties gracefully by ignoring them.

If your tooling uses strict JSON validation that rejects unknown properties, you may need to update your deserialization logic to allow the new CeilingOsCode field.

⚠️ Important: Avoid strict JSON parsing

- System.Text.Json — Do not set JsonSerializerOptions.UnmappedMemberHandling = JsonUnmappedMemberHandling.Disallow. The default behavior (ignoring unknown properties) is correct.
- Newtonsoft.Json — Do not set MissingMemberHandling = MissingMemberHandling.Error. The default behavior is correct.
- General — If you use schema validation or strict contracts, ensure they allow additional properties.

This applies to all Hardware Dev Center API responses, not just this change.

What CeilingOsCode means

When your INF file contains multiple OS-decorated [Manufacturer] sections, each hardware ID is only applicable within a specific OS range. The CeilingOsCode reflects the last OS version wher the hardware ID is still listed in the INF - the inclusive upper bound of that range.

CeilingOsCode value	Meaning
"WINDOWS_v100_X64_20H1_FULL"	This hardware ID is supported up to and including Windows 10 20H1 (build 19041) for x64. It is not supported on the next OS version or above.
null	No upper bound detected — the hardware ID is supported on all OS versions from its floor onward.
(field absent)	The package was submitted before the feature rollout and metadata has not been regenerated.

Example

Consider an INF with two OS-decorated manufacturer sections:

[Manufacturer]

%MfgName% = Models, NTamd64.10.0...17763, NTamd64.10.0...25952

[Models.NTamd64.10.0...17763]

%DevDesc% = Install, PCI\VEN_8086&DEV_1234 ; present from build 17763

[Models.NTamd64.10.0...25952]

; PCI\VEN_8086&DEV_1234 is NOT listed here ; absent from build 25952 onward

In this case, PCI\VEN_8086&DEV_1234 is only applicable for OS builds in the range [17763, 25952). The CeilingOsCode for this hardware ID would reflect the upper bound of that range.

Rollout plan

Starting May 8, 2026, the HardwareDriverMetadata response will include the new CeilingOsCode field on each PnP entry in OSPnPInfoMap for packages submitted on or after that date. This field will not be backfilled — metadata for packages submitted before this date will remain unchanged and will not include CeilingOsCode.

Note: We plan to use this ceiling data to improve driver targeting accuracy on Windows Update. We will communicate those changes separately as they approach rollout.

What you should do now

Review your JSON parsing logic. If you consume HardwareDriverMetadata via the Hardware Dev Center API (as described in Driver package metadata ) and use strict schema validation, update your parser to accept the new CeilingOsCode property in OSPnPInfoMap entries.
No changes are required to your driver packages, INF files, or shipping labels at this time.
No resubmission is required, but if you want your existing packages to take advantage of the improved OS ceiling targeting, you should resubmit them after the rollout date. The CeilingOsCode field will only be populated for packages submitted on or after that date — metadata for previously submitted packages will not change unless resubmitted.

Questions or feedback?

If you have questions about these changes or encounter issues, please reach out through the support channel Support for Partner Center Dashboard - Windows drivers | Microsoft Learn.

Attention: HDC is changing the policy on signing unreferenced files in driver packages

Cymoki — Wed, 29 Apr 2026 18:53:02 GMT

Today, HDC signs all files contained in a submitted driver package (.cab/HLKx), regardless of whether they are referenced by the INF.
With the upcoming change, any files in a submitted package that are not referenced by the INF will be returned unsigned.

Impact on Windows Update Publication

Driver packages published to Windows Update will include only INF‑referenced files.
This means customers receiving driver updates will install packages that contain only the files required by the INF.

To help minimize disruption:

Starting February 23, HDC will enable this policy in “On with Logging Only” mode.
- Submissions will be processed normally.
- Partners will be able to see whether this change affects their packages through either HDC submissions or the HLK:
  - HDC - The signing logs provided in HDC submissions are available in both the UI and API. Note: if the submission does not contain any unreferenced files, the logs will not be present.
  - HLK - February 2026 HLK refresh release will present a warning when the driver package is added to the submission package if the driver package contains files that are not referenced in an INF.
- Microsoft will collect partner feedback through bug reports and direct engagement. This will allow us to identify any scenarios that require special handling or further consideration.
After feedback is reviewed, Microsoft will announce the date when the policy changes to “On and Enforced” mode where any files in a submitted package that are not referenced by the INF will be returned unsigned.

Why this change matters

This change improves package integrity and aligns WU deliveries with the set of files your INF declares, reducing the risk of unsigned and unreferenced artifacts in distributed driver bundles.

Who is impacted

OEMs, IHVs, and driver developers who submit packages to HDC for signing.
Partners who include helper tools, debug utilities, or extra artifacts in packages without INF references.

What you need to do (checklist)

Audit your packages for unreferenced files (files not listed in INF sections such as SourceDisksFiles, CatalogFile, or other driver package manifest references. More information can be found here: INF SourceDisksFiles Section - Windows drivers | Microsoft Learn and to validate whether there are unreferenced files please pick up the latest HLK here: Windows Hardware Lab Kit | Microsoft Learn
Ensure the driver package only contains the files needed for the functioning of the driver package
Validate your package with the latest HLK validation tools before submitting to HDC.
Note: The February 2026 refresh of the HLK will showcase a warning at package creation time if unreferenced files are found in the driver. See What's new in the Hardware Lab Kit | Microsoft Learn for more information.
Update automation if you have it to create submissions or process signed packages to avoid adding unreferenced files.
If using the HDC API for submissions, update your automation to account for a new asset that will be returned ("type": "unreferencedFilesReport",
"url": "<SAS URL from Hardware API>"). See Get product data - Windows drivers | Microsoft Learn for more information.

Note: Starting April 27th, 2026, the ability to get the Unreferenced File Report through the API will be enabled. This is to ensure there is ample time for users of the API to adjust their code to account for the new download type being returned.

Important operational detail: When enforcement starts, HDC will continue to accept packages that contain unreferenced files; those unreferenced files will simply be returned unsigned. This initial implementation does not reject submissions for unreferenced files; stricter enforcement may be considered later.

Timeline

Start enforcement of “On with Logging Only” mode: February 23rd.
Update of enforcement of “On and Enforced” mode: To be announced – when any files in a submitted package that are not referenced by an INF will be returned unsigned.

How this works in practice

Output you receive from HDC: The returned package may contain unsigned unreferenced files alongside signed INF referenced files. Signed driver bundles published to WU will no longer contain files unreferenced in an inf.

Links & resources

Get a submission - Windows drivers | Microsoft Learn
What's new in the Hardware Lab Kit | Microsoft Learn
Partner Center doc & support: Support for Partner Center Dashboard - Windows drivers | Microsoft Learn

Frequently asked Questions

Q1: What is an “unreferenced file”?
A: An unreferenced file is any file in your submitted package that is not listed in an INF. More information can be found here: INF SourceDisksFiles Section - Windows drivers | Microsoft Learn. Such files will not receive embedded signatures in this phase. Note: If adding files to an INF ensure that they are referenced correctly, if they are not then they will be treated as an unreferenced file. INF Verif in the WDK can assist in ensuring the files are referenced correctly.

Q2: What happens if I submit a package with unreferenced files?
A: During the “On with Logging Only” mode, submissions will be processed normally, and partners can see whether this change will affect them. During the “On and Enforced” mode, HDC will return the driver package; only the INF referenced files will be signed. The unreferenced files will be returned unsigned. Driver packages published to Windows Update will include only INF‑referenced files.

Q3: Will my package be rejected?
A: Not in the initial phase. We may move to stricter enforcement later (e.g., rejecting packages that contain unreferenced files). We’ll publish dates and guidance well in advance.

Q4: What will be published to Windows Update?
A: Only INF referenced files will be included in the signed driver bundles that are published to Windows Update.

Q5: Do nested CAB files get embedded signing?
A: No. HDC does not perform embedded signing on nested CAB files; those components are protected by catalog signing and are out of scope for this change.

Q6: I have runtime dependencies that aren’t in the INF (e.g., firmware blobs, config files, user mode DLLs). What should I do?
A: If such a file is needed at runtime, it must be referenced in the INF to be signed and delivered via WU. Otherwise, it will be returned unsigned and will not be included in WU bundles. Plan to add appropriate INF references or maintain your own distribution for those artifacts.

Q7: How can I check for unreferenced files?
A: Partners will be able to see whether this change affects their packages through either HDC submissions or using the HLK:

HDC - The signing logs provided in HDC submissions are available in both the UI and API. Note: if the submission does not contain any unreferenced files, the logs will not be present. Examples:
- HDC On and Logging message:
  - Warning: This submission contains one or more files that are not referenced by any INF in the submitted driver package. These files have been signed and published; however, in a future update, files not referenced by an INF will no longer be eligible for signing or publishing. For additional information on unreferenced files, see the documentation
- HDC On and Enforced message:
  - Attention: This submission contains one or more files that are not referenced by any INF in the submitted driver package. Files not referenced by an INF are not eligible for signing or publishing. For additional information on unreferenced files, see the documentation.

Note: The messaging above will be seen at the submission level, though it is possible that the initial submission package does not contain unreferenced files, but the derived package contains additional files which are unreferenced. In this case, the partner verbiage would be displayed at the derived submission level, and not at the top-level submission.

HLK - February 2026 HLK refresh release will present a warning when the driver package is added to the submission package if there are unreferenced files included in the driver package.

Q8: How are symbol files handled since they are not referenced by an INF?

A: Symbol files today are not included in the signed driver package that is returned. This behavior is not changing, and symbol files do not need to be referenced in an INF. Including symbols with your driver package is highly recommended.

Q9: Will HDC fail submissions that contain unreferenced files?
A: Not in this phase. Submissions will still be accepted; unreferenced files will be returned unsigned. Stricter enforcement may be considered later after partners have time to adapt.

Q10: How can I tell what files are signed by Microsoft?

A: How to validate the Microsoft signature - Windows drivers | Microsoft Learn

Q11: Where can I get help?
A: If you need direct assistance, open a Partner Center support case and reference this policy change. Support for Partner Center Dashboard - Windows drivers | Microsoft Learn

Driver Isolation Ruleset Changes for WHCP and Attestation Submissions

Cymoki — Wed, 03 Dec 2025 21:30:25 GMT

In November, Hardware Dev Center enforced stricter driver isolation requirements using the existing InfVerif /h validation. While InfVerif /h is already in use across WHCP and Attestation workflows, this update raises the bar for what qualifies as a compliant submission. These changes will impact both WHCP and Attestation driver packages submissions and are designed to help increase the security and quality of the Windows driver ecosystem.

Action for Partners

To help ensure that your driver submission passes HDC validation checks, run InfVerif /h on your driver package before submission. InfVerif /h testing is automatically executed as part of the Windows 11 version 25H2 HLK. Additionally, you can get the latest version of InfVerif by downloading the most recent Windows Driver Kit (WDK). The tool is located in the \tools folder of your WDK installation (e.g., C:\Program Files (x86)\Windows Kits\10\tools). To apply the 25H2 ruleset, use the command:
InfVerif /h /rulever 25h2

For additional information on the errors and how to address them:

Running InfVerif from the Command Line - Windows drivers | Microsoft Learn

INF Validation Errors and Warnings - Windows drivers | Microsoft Learn

Additional information about InfVerif /h:

InfVerif /h - Windows drivers | Microsoft Learn

Information about viewing your certification level in Partner Center:

Update a hardware submission - Windows drivers | Microsoft Learn

Questions?

If you have any questions or issues, please reach out to our support team. For details on how to contact support, see Get support for Partner Center dashboard issues - Windows drivers | Microsoft Learn.

Action Required: Account Verification for Windows Hardware Program Begins October 16, 2025

NatachaC — Thu, 30 Apr 2026 21:25:23 GMT

4/13/26 Update for partners experiencing challenges regaining access to the Hardware Dev Center

We've heard your feedback. We know that some partners whose accounts were suspended following Account Verification are experiencing challenges regaining access to the Hardware Dev Center (HDC). Protecting the security of the Windows ecosystem remains our highest priority, and we are adding a temporary process to accelerate the reinstatement experience for partners who are able to resolve outstanding compliance requirements.

Opening a support case is the fastest path towards reinstatement. Partners may request reinstatement through Hardware Program support. If reinstated, all compliance issues must be resolved prior to regaining access to HDC.

Encountering issues with the support experience? Make sure you are signed in using the email address associated with your Hardware Program account in Partner Center. Case creation is now live on Microsoft EngageCenter where you should see the following options for Product: Windows Developer Center.

Still unable to submit a ticket? The only official channel to get support is by opening a ticket as described above. However, we know some partners have been having challenges with that workflow, which we’re planning to address in a future update. Until then, you can reach out for support at aka.ms/HDC-Account-Verification-Support and someone from our team will reach out to assist.

Before submitting a reinstatement request, please review the information below and the Account Verification guidance in Partner Center to ensure all required verification steps are completed.

Original Post

Effective October 16, 2025, Microsoft will initiate mandatory account verification for all partners in the Windows Hardware Program who have not completed account verification since April 2024.

Required Actions for Partners:

Review and update your Legal Info in Partner Center to ensure it is current and accurate.

Prepare to complete the account verification process when notified.

Monitor your verification status on the Legal Info page in Partner Center to ensure all requirements are met and your account remains in good standing.

To successfully complete Account Verification:

The primary contact email address must be a monitored work account that can send and receive email. Generic or group email addresses are not permitted; use an individual address in the format you@yourcompany.com.

The name on the government-issued ID must match the Partner Center Primary Contact. Acceptable forms of ID include a valid passport, driver’s license, or other national identification.

Identity verification must be completed within 30 days of receiving the request. Failure to do so will result in rejection and suspension from the hardware program.

Blockers that will prevent successful verification include:

Failure to complete identity verification within 30 days.

Primary contact email address is not a monitored work account or is a group/generic address.

Mismatch between the name on the government ID and the Partner Center Primary Contact.

Incomplete or outdated information in the Legal Info page on Partner Center.

Partners who fail to complete Account Verification by the deadline, or who do not meet the requirements, will have their status set to Rejected and will be suspended from the program.

For more information on what is required to successfully complete verification or how to check status of your account, please review Verify Your Account Information - Partner Center | Microsoft Learn. If you have questions or need assistance, please contact our support team as described on Get support for Partner Center dashboard or HLK issues - Windows drivers | Microsoft Learn.

Update: Account Verification Completed

Account verification for the Windows Hardware Program has now concluded. Accounts that did not successfully complete account verification and received a Rejected verification status have been suspended from the Windows Hardware Program, and submissions from these accounts are no longer permitted.

Partners whose accounts were suspended may request reinstatement by submitting an appeal through Hardware Program support. Appeals must include either:

Supporting evidence that the suspension was issued in error, or
A clear business justification explaining why access to the Windows Hardware Program is required

Appeal requests that do not include supporting evidence or a business justification are not reviewed.

Signing with the new 2023 Microsoft UEFI certificates: what submitters need to know

Pratishtha — Wed, 24 Sep 2025 05:53:28 GMT

Note: This blog is intended for Microsoft partners who submit UEFI binaries for signing—such as OEMs, IHVs, ISVs, and other device builders. If you are a Windows IT administrator or enterprise customer, please refer to Act now: Secure Boot certificates expire in June 2026.

Certificate expirations and continuity

Microsoft Corporation UEFI CA 2011 (Expiration: June 2026) → replaced by:

Microsoft UEFI CA 2023 for UEFI application submissions
Microsoft Option ROM UEFI CA 2023 introduced for Option ROM submissions

Important: Expiration does not invalidate binaries already signed with the 2011 cert. Those remain trusted on devices that still have the 2011 CA in their DB.

Why the rollout is careful

Microsoft began introducing the new Secure Boot certificates in 2023, and while many newer devices already include them, a significant number of existing systems still need to be updated. To ensure a smooth and safe transition, Microsoft is taking a phased and measured approach to deploying these updates. Past internal testing revealed that some devices had firmware compatibility issues, which have since been resolved in collaboration with OEMs. This experience informed our decision to proceed cautiously, validating updates across diverse hardware configurations before broader deployment.

For organizations managing Windows updates, Microsoft offers different paths to receive these certificate updates—either by allowing Microsoft to manage the rollout automatically or by handling the update process independently. These options, along with detailed guidance for IT-managed environments, are outlined in the blog post Act now: Secure Boot certificates expire in June 2026.

Transition timeline: October 2025 → June 2026

From October 20, 2025, each approved submission will return two signed files instead of the usual one:

One binary signed with the existing 2011 UEFI CA
One binary signed with a 2023 UEFI CA:
- UEFI application submissions: Microsoft UEFI CA 2023
- Option ROM submissions: Microsoft Option ROM UEFI CA 2023

This will happen through June 2026, when the existing 2011 CA expires and signing ceases with the 2011 CA.

Install-time detection logic

Your installer must check the Secure Boot DB for the 2023 certs:

If present → install/use the 2023-signed binary
If absent → install/use the 2011-signed binary

✅ Windows helper script (PowerShell)

# Requires: UEFIv2 PowerShell module # Install-Module -Name UEFIv2 -Force Import-Module UEFIv2 $db = Get-UEFISecureBootCerts db function Test-CertPresent([string]$thumbprint) { $db | Where-Object { $_.SignatureThumbprint -eq $thumbprint } | ForEach-Object { return $true } return $false } $UEFI2023Thumb = "B5EEB4A6706048073F0ED296E7F580A790B59EAA" $OptionROM2023Thumb = "3FB39E2B8BD183BF9E4594E72183CA60AFCD4277" $hasUEFI2023 = Test-CertPresent $UEFI2023Thumb $hasOptionROM2023 = Test-CertPresent $OptionROM2023Thumb if ($hasUEFI2023 -and $hasOptionROM2023) { Write-Host "Install 2023-signed binaries" exit 0 } else { Write-Host "Install 2011-signed binaries" exit 1 }

✅ Linux helper script (Bash)

#!/bin/bash UEFI2023 = "B5EEB4A6706048073F0ED296E7F580A790B59EAA" OPTIONROM2023 = "3FB39E2B8BD183BF9E4594E72183CA60AFCD4277" db=$(mokutil --list-db 2>/dev/null) if echo "$db" | grep -q "$UEFI2023" && echo "$db" | grep -q "$OPTIONROM2023"; then echo "Install 2023-signed binaries" exit 0 else echo "Install 2011-signed binaries" exit 1 fi

(Replace mokutil with efi-readvar if preferred.)

✅ Windows C APIs

The Windows win32 API, GetFirmwareEnvironmentVariableExw, can be used to retrieve the values of the Secure Boot DB database to determine which signed binary to use.

Some devices may not trust all 3P CAs

Some devices manufactured for specific use case configurations (e.g., Secured-Core PCs) may not trust the Option ROM CA or the other third-party CAs by default. Test your target platforms and coordinate with OEMs if your product depends on these certs. Most OEMs’ firmware has a UEFI menu option to switch Secure Boot configurations.

Quick reference: certificate names and SHA-1 thumbprints

Certificate	Subject String	SHA-1 Thumbprint
UEFI CA (2011)	Microsoft Corporation UEFI CA 2011	46DEF63B5CE61CF8BA0DE2E6639C1019D0ED14F3
UEFI CA (2023)	Microsoft UEFI CA 2023	B5EEB4A6706048073F0ED296E7F580A790B59EAA
Option ROM CA 2023	Microsoft Option ROM UEFI CA 2023	3FB39E2B8BD183BF9E4594E72183CA60AFCD4277

Coming soon: changes to signing requirements

Beginning in October 2025, Microsoft partners submitting binaries for signing with the third-party UEFI CA must undergo an annual security audit conducted by a Microsoft-approved independent partner specializing in security code reviews. For SHIM submissions, the SHIM Review Board process is sufficiently rigorous and meets this requirement. However, when the Review Board flags risks they can't cover, such as proprietary, non-SHIM code that is included with the submission, then you must also complete the independent security code audit.

Stay tuned for further announcements on this blog, including how to identify a qualifying partner to conduct the audit.

Submitter checklist

Prepare your submission process to handle two returned files (2011 and 2023 signed).
Update your installers to detect the 2023 certs and select the correct binary.
Keep shipping the 2011-signed binary along with the 2023-signed binary until most devices have updated their UEFI trust anchors – Microsoft will provide an update when this happens.
If you try dual-signing, test comprehensively across your target fleet.
Engineer for crypto agility (avoid hard-coded assumptions about key sizes or algorithms).

FAQs

Q: Will my existing 2011-signed binary stop working when the cert expires?
A: No. Existing signatures remain valid on devices that still trust the CA in DB.

Q: What about Post-Quantum Cryptography (PQC)?
A:Microsoft and the UEFI Forum are working together to ensure the ecosystem is ready. Guidance will be published in stages—focus now on crypto agility and update mechanisms. Microsoft’s PQC roadmap is published here: Microsoft Quantum | Quantum Roadmap

Additional information

Secure Boot CA update website: Windows Secure Boot certificate expiration and CA updates - Microsoft Support
Article for OEMs and ODMs: Windows Secure Boot Key Creation and Management Guidance - Microsoft Support
Blog post announcement: Act now: Secure Boot certificates expire in June 2026 - Windows IT Pro Blog

HLK July Refresh Release for Windows 11 Version 24H2 and Windows Server 2025

Cymoki — Tue, 08 Jul 2025 20:54:50 GMT

Microsoft is pleased to announce that a refreshed HLK for Windows 11, version 24H2 and Windows Server 2025 is available starting July 8, 2025.

This release of the HLK contains only infrastructure changes. See below for detailed information on what’s new with this HLK refreshed version. The refreshed version of the HLK will replace the RTM version that is available on the HLK download site. The VHLK version will be available in a week. Partners can submit to WHCP using either the RTM version of the HLK for Windows 11, version 24H2 and Windows Server 2025 or the refreshed HLK so long as passing results can be obtained (waivers acceptable).

What's new with this refresh?

Upcoming HLKX Packager changes

This HLK refresh will increment the HLKX packager version to a newer version, the data format will not be readable by previous versions of the HLK Studio. Opening an HLKX saved from this version will fail with the message text "Failed to open package. Could not open package: (hlkx filename)" when opened from previous releases of the HLK Studio and will require installation of this version or newer to read it. HLK Studio in this refresh will continue to be backwards compatible and will be able to read, merge, and add drivers to submission packages that were saved from current and previous releases of the HLK.

Note that the HLK Installer supports installation of the HLK Studio components only to read and write HLKXes if HLK Controller functionality is not needed.

The submission portal will continue to accept HLKXes from older versions of the HLK, but any HLKX submitted after the switchover will return Driver Update Acceptable (DUA) HLKX shells in the new format when requested, while HLKXes submitted prior to the switchover will continue to be in the previous format. Without the refreshed HLK, the update will not be able to read and process DUA HLKX shells in the new format.

Action Required:

Note that HLKX files created in this release of the HLK will be generated in an updated format version. The user should be aware of scenarios which will and will not require an update to this version of the HLK or HLK Studio.

HLKXes generated from this release will be readable by this and future versions of the HLK Studio.
HLK Studio from previous releases of the HLK will not be able to read the data format of the upcoming version.
This release of the HLK is backwards compatible and will also be able to read HLKXes and HCKXes from current and past versions of the HLK.

Troubleshooting and Known Issues:

Issue: "Failed to open package. Could not open package: (hlkx filename)" when opening HLKX generated from this release on separate system.

Submission packages from this release are generated in a new schema and a newer version of the HLK Studio is required to open it.

Solution: Install/Update to a newer of HLK or HLK Studio

Existing HLK Controller installations may be kept as is and do not need to be reinstalled as it is not supported to update just the HLK Studio on an existing HLK Controller instance. An HLK Studio only instance from the latest HLK may be installed on a separate system to open these HLKXes.

Issue: "Failed to open package. Could not open package: (hlkx filename)" when opening DUA shell downloaded from submission portal.

After the portal switches over to processing submissions in the new format, DUA shells for submission packages submitted to the portal after the switchover will return them in the new format. These DUA shells will not be readable without an HLK Studio installation that does not have the updated changes and will return the error "Failed to open package. Could not open package: (hlkx filename)"

Solution: HLK/HLK Studio instance should be updated to newer version.

Issue: Reinstall of HLK Controller fails with “Install did not complete successfully: An error occurred installing ‘Windows Hardware Lab Kit Infrastructure’”

This issue is caused by a missing check in the HLK installer to detect whether a newly supported version of SQL is already installed. When this occurs, the HLK SQL installer fails due to an existing instance with the same instance name.

Workaround:

After uninstalling the Hardware Lab Kit on the HLK Controller system:

Right-click on the “Start” button on the Windows taskbar and select the “Settings” menu option to launch the Windows Settings app.
From the Windows Settings app, select the “Apps” option, then select “Installed Apps”
Look for the item “Microsoft SQL Server 2022 (64-bit)” and uninstall it.
Attempt to install the Hardware Lab Kit again and confirm that it completes without errors.

This issue will be fixed on a future refresh of the 24H2 Hardware Lab Kit.

Issue: HLK Studio may throw InvalidOperationException when selecting targets

Enabling the Distributed Target Selection feature in HLK Studio may cause HLK Studio to crash with the error: “System.InvalidOperationException: A TwoWay or OneWayToSource binding cannot work on the read-only property 'RedistributeTests.'”

Workaround:

If this issue occurs in HLK Studio, disable the Distributed Target Selection feature.

From HLK Studio, select the “Configuration” menu option.
Select the “Options” item on the left side of the user interface
Under the “Distributed Testing” group box, look for the “Show Distributed Target Selection dialog when multiple matching targets are found” checkbox and uncheck it.
Confirm that the InvalidOperationException is no longer thrown when selecting targets in HLK Studio.

This issue will be fixed on a future refresh of the 24H2 Hardware Lab Kit.

Issue: Wifi tests regressed due to removal of TestNetv2.0 dependencies

The TestNetv2.0 was removed from the HLK test infrastructure, causing some Wifi tests to regress due to not being able to invoke “testnetv2.0/ccrun.exe”. The list of affected tests is:

- Wi-Fi Direct Basic Discovery Tests – Functional

- Wi-Fi Direct Basic Pairing Tests – Functional

- Wi-Fi Direct Basic Reconnect Tests – Functional

- Wi-Fi Direct Legacy Pairing Tests – Functional

- Wi-Fi Direct Service Discovery Tests – Functional

- Wi-Fi Direct Service Pairing and Reconnect Tests – Functional

This issue will be fixed on a future refresh of the 24H2 Hardware Lab Kit

Frequently Asked Questions

What HLK version is being refreshed?

The May refresh HLK is being refreshed, this HLK helps support certifying drivers for Windows 11, version 24H2 and Windows Server 2025. For the following FAQ’s, the May 2024 release will be referenced to as RTM HLK and the upcoming release in July 2025 will be referenced as refresh HLK.

How can I tell what version of the HLK I have?

The distinction between RTM HLK and refreshed HLK will be in the last digits of the HLK studio version, 10.1.26100.X

The RTM HLK Studio version is 10.1.26100.1
The refresh HLK Studio version is 10.1.26100.X

The HLK Studio version information can be located by clicking ‘About’ in the upper right corner of studio

How do I install the refreshed version of the HLK?

Visit the HLK download page: Windows Hardware Lab Kit | Microsoft Learn
Download the refreshed HLK
Run HLKSetup.exe

Notes

Ensure your current HLK projects are finished before attempting to use the same system for the HLK refresh.
The refreshed HLK cannot be installed on a system that already has the RTM HLK, this goes for both Controller and Client. It is highly recommended to start with a clean install of the OS for both.

How can I tell if the errata I use was fixed in the refreshed HLK?

The list of errata fixed is available below

What do I do if the errata I use doesn’t appear to be fixed in the refreshed HLK?

If the errata is not on the fixed list the waiver can be used on both the RTM HLK as well as the refreshed HLK

What do I do if the errata I use is listed as fixed, but failures are still being seen in the test?

Triage the failure first. There have been cases where a test issue is fixed, and the failure is still present, but it is due to a driver issue that has the same failure message
Next Open a CSS case: Get support for Partner Center dashboard and HLK issues - Windows drivers | Microsoft Learn

How should I address a test that was passing on the RTM HLK but now failing on the refreshed HLK?

Triage the failure first. There have been cases where a test issue is fixed, and the failure is still present, but it is due to a driver issue that has the same failure message
Next Open a CSS case: Get support for Partner Center dashboard and HLK issues - Windows drivers | Microsoft Learn

Going forward, will Microsoft be updating the HLK regularly?

Yes, Microsoft is transitioning into this servicing model for the HLK, which maintains overall test quality and reduces dependency on errata.

How often are these refresh releases expected?

Current plan is to evaluate releasing a refreshed HLK each quarter.

Does this update apply to client and server?

Can results from an RTM test run and a Refreshed test run be merged and used for submission?

No, submission should be completed with either the RTM or refreshed HLK.

Will the refreshed HLK continue to support merged packages for multiple-OS submissions?

Is the VHLK also going to be updated?

Action Required: HLK Submission Packager Changes Coming in July

Cymoki — Tue, 24 Jun 2025 23:01:41 GMT

The Hardware Lab Kit (HLK) packaging component is important for reading, writing, and packaging test results, as well as submitting drivers to the Hardware Dev Center (HDC) portal for certification and signing.

What’s Changing?

In July, an upcoming HLK refresh will update the submission packager version and format. Submission packages generated using this HLK refresh will be saved in a new data format and will not be readable by previous versions of HLK Studio.
The updated packaging components can read both current and previous data formats but will always write HLKX files in the new format. Older versions of the HLK Studio will not be able to read submission packages written in the new format.
The above applies to DUA HLKX packages as well.
The HDC portal will synchronize deployment of the new submission package format with the upcoming HLK refresh. .

Actions Required

To enable compatibility with the new format:

Watch for a notification and an upcoming HLK release announcement regarding the switch to the new submission package version and format on this blog and on the HDC portal.
Installations of older HLK Controller versions do not require updates for this scenario as submission packages from older versions of the HLK will continue to be accepted by the portal. An HLK Studio only instance can be installed on a separate system for opening and processing a DUA shell package returned after the update,
If the error "Failed to open package. Could not open package: (hlkx filename)" is encountered when opening a submission package in HLK Studio, it is recommended to install a newer version of HLK/HLK Studio. This error message may be indicating that the updated version of HLK Studio is necessary to read the latest submission package format.
Automation and tools utilizing the HLK Object Model may require additional dependencies to be deployed due to updates in these dependencies. These changes will be detailed in the HLK Documentation upon the release of the update.

Removal of unwanted drivers from Windows Update

Cymoki — Tue, 24 Feb 2026 23:48:23 GMT

This blog post is intended to notify all Windows Hardware program partners that Microsoft has taken a strategic initiative to clean up legacy drivers published on Windows Update to reduce security and compatibility risks. The rationale behind this initiative is to ensure that we have the optimal set of drivers on Windows Update that cater to a variety of hardware devices across the windows ecosystem, while making sure that Microsoft Windows security posture is not compromised. This initiative involves periodic cleanup of drivers from Windows Update, thereby resulting in some drivers not being offered to any systems in the ecosystem.

2/24/2025 update:

Microsoft has completed the expiration of the first batch of drivers as of 02/23/2026. A thorough vetting was completed by Microsoft to ensure that the expiration of these drivers would not cause any feature disruption for current devices in the ecosystem. We are actively monitoring the ecosystem for any impact caused by the expiration and have a sound mitigation plan in place should it be the case. Please note that this was the first iteration of the WU cleanup and subsequent iterations will occur at a set cadence. Similar updates to the blogpost will not be made after every iteration similar to the one today.

Further details of the effort are as follows:

What category of drivers are targeted in the first cut of the cleanup?

The first phase targets legacy drivers that have newer replacements already on Windows Update.

What does “cleanup” mean in this context?

Cleanup here refers to the process of expiring drivers so that they are no longer associated with an audience in Windows update, resulting in them not being offered to any system. Technically, expiring a driver means removing all its audience assignments in Hardware Development Center, which stops Windows Update from offering that driver to devices.

Can partners republish a driver that was expired by Microsoft?

Yes, partners will be able to republish the drivers that were expired. Microsoft may require business justification as to why there was a need for republishing.

What happens to the cleaned-up drivers?

After the expiry, Microsoft will publish a blog post mentioning the end of the first cut of driver expiry. After that, there will be a 6-month window for partners to get back with concerns (if any). If no action is taken, the drivers will be permanently removed from windows update.

Will this be a one-time exercise or will similar instances occur in the future?

This is meant to be a regular exercise to optimize what windows update has to offer. We are beginning with the above-mentioned category of drivers but will expand to cover more categories of drivers that Microsoft deems fit to be expired from windows update. Each time such a cleanup occurs, Microsoft will communicate broadly so that partners know what to expect.

In summary, Microsoft removing legacy drivers from Windows Update is a proactive measure to safeguard security and improve driver quality for Windows users. As a partner, you should review your drivers in the Hardware Program, be aware of what your current drivers in the ecosystem are, and make sure that any unwanted/legacy driver is proactively expired from windows update. Moving forward, expect this cleanup to be a routine practice, and prepare for the introduction of new publishing guidelines that will help all windows users keep their systems in a secure and reliable state. We appreciate your cooperation in this initiative, as it helps ensure that Windows devices run on the most secure and compatible drivers available.

Changes to Pre-Production Driver Signing

Pratishtha — Wed, 02 Jul 2025 07:39:34 GMT

Preproduction driver signing

The Windows Hardware Program supports partners signing drivers for use in pre-production environments. The CA that is used to sign the binaries for use in pre-production environments on the Windows Hardware Program is set to expire in July 2025, following which a new CA will be used to sign the preproduction content starting June 9, 2025. There are some important points that partners must take notice of, following this change:

Going forward, the expiry of the signed content will not be tied to the expiry of the underlying CA. This means that any pre-production driver signed after June 9, 2025, will not come with an expiry date. This is unlike today, where preproduction content expires along with the expiration of the certificate that signed it.
Drivers signed before June 9, 2025, will expire on July 4, 2025, as is the current model.
June 10, 2025 - Windows servicing releases (6B) ship to in-market platforms (down to Windows 10 RTM) to remap existing CAs to their new CAs in WDAC/Application Control for Business policies. Partners must make sure to install this Latest Cumulative update (LCU) to add trust for the new preproduction signer (Microsoft Windows Component Preproduction CA 2024) to the kernel.

Product	Release	Release Date	Update Release	Update Date
Windows 11 24H2	2025.06 B	10 June 2025	2025.07 D	22 July 2025
Windows 11 22H2/23H2	2025.06 B	10 June 2025	2025.07 D	22 July 2025
Windows 10 2004	2025.06 B	10 June 2025	2025.07 D	22 July 2025
Server OS 23H2 (Zn)	2025.06 B	10 June 2025	2025.08 B	12 August 2025
Windows Server 2022	2025.06 B	10 June 2025	2025.08 B	12 August 2025
Windows 10 1809	2025.06 B	10 June 2025	2025.08 B	12 August 2025
Windows Server 2016 RTM (1607)	2025.06 B	10 June 2025	2025.08 B	12 August 2025
Windows 10 RTM	2025.06 B	10 June 2025	2025.08 B	12 August 2025

Timeline and key milestones

June 10, 2025 - Windows servicing releases (6B) ship to in-market platforms (down to Windows Server 2008) to remap existing CAs to their new CAs in WDAC/Application Control for Business policies. Partners must make sure to install this Latest Cumulative update (LCU) to add trust for the new preproduction signer (Microsoft Windows Component Preproduction CA 2024) to the kernel.

June 9, 2025 – New content signed after this date will be signed with the new certificates, so the content will not come with an expiration date.
July 4, 2025 – Any content signed before June 9, 2025, will expire as the Microsoft Code Signing PCA 2010 and the Windows PCA 2010 expire on this day.
July 22, 2025 - Windows servicing releases (7D) ship to in-market platforms (Windows 11 24H2, Windows 11 22H2/23H2, Windows 10 2004). Partners must make sure to install this Latest Cumulative update (LCU) to add trust for the new preproduction signer (Microsoft Windows Component Preproduction CA 2024) to the kernel by default.
August 12, 2025 - Windows servicing releases (8B) ship to in-market platforms (Server OS 23H2 (Zn), Windows Server 2022, Windows 10 1809, Windows Server 2016 RTM (1607), Windows 10 RTM). Partners must make sure to install this Latest Cumulative update (LCU) to add trust for the new preproduction signer (Microsoft Windows Component Preproduction CA 2024) to the kernel by default.

Note: Any driver signed between June 9th and their respective update date (see table above for the "update date" of your Windows version) should go through one of the following manual steps to go through:

1. Manually overriding the trust check by selecting "Install". Selecting the "Always trust..." checkbox will prevent subsequent prompts from PNP

2. Adding the leaf certificate to the Local Computer\Trusted Publishers\Certificates cert store which can be manual or automated.

End of Servicing and Retirement Plan for Device Metadata on Windows

Cymoki — Mon, 05 May 2025 21:22:57 GMT

Device metadata and the Windows Metadata and Internet Services (WMIS) are being retired as of May 2025, and no new packages will be delivered to Windows clients via WMIS. In Partner Center, device metadata experiences cannot be created, modified, or promoted. New device metadata submissions will fail. Existing device metadata packages on Windows clients will remain on the client.

Between now and December 2025, partners can continue to use Partner Center to view and download previously signed device metadata packages.

Driver Package-based Replacement Solution

To continue customizing user-facing information about your physical device, the following guidance includes instructions on how to include this in your driver INF and/or extension INF.

Driver Package Container Metadata - Windows drivers | Microsoft Learn

o Driver package container metadata functionality for Windows 11 24H2 clients is available beginning in March 2025.

If you have not already updated your device companion app (DCA) to a modern hardware support app (HSA) or print support app (PSA), see below for additional guidance.

FAQ

I am a partner; how do I view and download previously signed device metadata packages?

Log into your Partner Center account and navigate to the device metadata section. Select the previously signed device metadata experience. Expand the details by clicking the down arrow located next to the device metadata package and click on the download signed file link.

What happens to the device metadata packages on my machine?

Existing device metadata packages will remain on your machine.

What happens to the device metadata packages if I update my machine to a new Windows OS?

Existing device metadata packages will be preserved across upgrades when upgrading to Windows 11, version 24H2 or newer.

Additional Questions?

If you have any questions, please reach out to our support team. For details on how to contact support, see Get support for Partner Center dashboard issues - Windows drivers | Microsoft Learn.

New Firmware and Camera Measures

Asotocama1 — Mon, 10 Feb 2025 23:49:35 GMT

New Measures

The following measures are currently in evaluation for feedback through 2/28/25 and will be operationalized into Driver Shiproom publishing decisions in March of 2025.

Evaluation	Class	New Measure ID
Pre-Attestation Health Check	Firmware	51378333
Camera DShow Bridge Failure Rate	Camera	50182120
Legacy Camera Dshow Failure Rate	Camera	50182242
Camera: User-Mode Crashes: Distinct Device Hits (Cabs) over Population (DHoP)	Camera	49005400

Measure Details

Upcoming Changes to INF Validation in HDC

Cymoki — Tue, 04 Feb 2025 17:46:10 GMT

Hardware Dev Center relies on the InfVerif tool for all driver submissions. Starting in April 2025, HDC will switch to using an updated version of InfVerif that contains new validation checks for submissions and for the evaluation of certification levels. These changes may result in the rejection of driver submissions made to Partner Center for the Windows Hardware Certification Program (WHCP).

Background

As of Windows 11 version 24H2, a new mode (InfVerif /h) was introduced for InfVerif. InfVerif /h validates INF files using a set of requirements that change with each release to align with the WHCP program to obtain a signature from Hardware Dev Center. The WHCP requirements associated with InfVerif /h include additional checks and encompass all the requirements of InfVerif /k (Declarative check). After these changes take effect, all attestation submissions must pass InfVerif /h. These requirements validate that driver packages meet high standards of quality, security, and reliability.

Action for Partners

To ensure that your driver submission passes HDC validation checks, run InfVerif /h on your driver package before submission. To acquire a version of InfVerif with this functionality, download the latest version of the Windows Drivers Kit (WDK). The InfVerif Tool is part of the WDK installation and can be found in the \tools subdirectory of your WDK installation (e.g. c:\Program Files(x86)\Windows Kits\10\tools\). Additionally, InfVerif/h testing is automatically executed as part of the Windows 11 version 24H2 HLK.

For additional information on the errors and how to address them:

Running InfVerif from the Command Line - Windows drivers | Microsoft Learn

INF Validation Errors and Warnings - Windows drivers | Microsoft Learn

Additional information about InfVerif /h:

InfVerif /h - Windows drivers | Microsoft Learn

Information about viewing your certification level in Partner Center:

Update a hardware submission - Windows drivers | Microsoft Learn

Questions?

2025 Driver Release Calendar and Block Out Dates

Asotocama1 — Tue, 12 Nov 2024 18:26:19 GMT

Exciting news – our 2025 Driver Release Calendar is here!

The Driver Shiproom Release Calendar provides a clear view of our release windows for delivering drivers through Windows Update. For a detailed overview of the process, please check visit our complete overview.

ACTION REQUIRED: HDC API users may need to update code for accessing submission blobs by Aug 28th

Cymoki — Fri, 26 Jul 2024 13:38:16 GMT

On August 28th, 2024, Hardware Dev Center APIs will change the type of blob urls that are returned in various API calls from service sas urls to user delegated sas urls. Partners using HDC Hardware dashboard API to automate driver submission process may be affected. The specific area affected is the upload and downloads through the download links in the submission response. All other aspects of the submission process that can be accessed through the API are not affected. Partners are recommended to update to latest version of the libraries they use to upload and download from Azure Blobs during the driver submission process.

Partners using C# are encouraged to move to Azure.Storage.Blobs or Azure.Storage.Blobs.Specialized library to ensure that driver submissions are not interrupted. Any partner already managing blob interactions through these libraries is not affected by this change. The following is an example of the BlockBlobClient:

If you experience any issues, please open a support ticket with HDC support. For details about how to contact the support team, visit https://aka.ms/GetHardwareSupport .

ACTION REQUIRED: New Agreement governing access to Hardware Dev Center

NatachaC — Wed, 29 May 2024 00:04:51 GMT

We have updated the agreements on Partner Center for the Windows Hardware Program. We made these updates to clarify our terms and ensure that they are transparent, as well as to address usage of new logos.

All participants in the Hardware Program are required to have their authorized personnel review, acknowledge, and accept the agreements. New submissions will be blocked after August 14, 2024 until the agreements are accepted.

Partners who have accepted prior versions of the agreement via other means will still need to accept the agreement on Partner Center. For partners who have already been a part of the program, you will see the previous agreement, the Windows Logo License Agreement from 2021, has been renamed and is now listed in the Agreements section of Partner Center as "Microsoft Marks License Agreement (formerly Windows Logo License Agreement)" with the value in the Agreement column of Version 2021.

As a result, partners who previously accepted the Windows Logo License Agreement will see two entries in the Agreements section:

The new Microsoft Marks License Agreement, with Version 2024.
The previous Windows Logo License Agreement, now renamed to "Microsoft Marks License Agreement (formerly Windows Logo License Agreement)" with the value in the Agreement column of Version 2021.

Going forward, the four agreements listed below will govern your access to the Hardware Program. Legacy agreements will be deprecated.

· Code Signing Agreement

· Windows Hardware Compatibility Agreement

· Microsoft Marks License Agreement 2024 (New)

· Windows Analytics Agreement v2.0

Please note: Authorized personnel must review and accept the updated agreement on Partner Center. To access the new agreement, sign in to Microsoft Partner Center and select "Agreements" under "Account Settings".

If you encounter issues accessing the new agreements, please reach out to our support team. For details on how to contact support, see Get support for Partner Center dashboard issues - Windows drivers | Microsoft Learn.

InfVerif Error Code 1199

AndyW — Thu, 09 May 2024 19:07:14 GMT

HDC incorporates new capability to verify the usage of unsupported syntax for a particular DDInstall section with InfVerif error code 1199.

This error reports the usage of unsupported syntax for a particular DDInstall section to help prevent the driver from installing on product versions where it will not function properly.

Compliance with InfVerif error code 1199 is now a requirement for a driver to be certified as Declarative.

Details
The impacted DDInstall section will install on product versions that do not support the specified syntax. A build number should be added to the Models section to limit applicability of the DDInstall to only supported product versions.

To aid with this error, a new infverif output mode has been introduced to the command line infverif.exe available in the WDK. This new mode will help to report syntax used in the INF and what the minimum applicable OS for that syntax is. It can be invoked with: infverif.exe /syntax <filename>.inf

Infverif Error Message:
The syntax '<value>' was introduced in OS version <MajorVersion>.<MinorVersion>.<BuildNumber> but DDInstall sections utilizing the syntax will install on earlier OS versions. Those DDInstall sections should be restricted to only install on <MajorVersion>.<MinorVersion>.<BuildNumber> or higher using a TargetOSVersion decoration.

For additional information, see the following pages:

Get Verifiable Credentials

NatachaC — Fri, 15 Mar 2024 20:00:00 GMT

A new Account Verification will be required to access Partner Center programs. All participants in the Windows Hardware Program on Partner Center will be required to complete Verifiable Credentials or they will be blocked from accessing the Hardware Program. Verifiable Credentials (VCs) is an open standard for digital credentials.

The Primary Contact for your account will be the initial individual required to obtain Verifiable Credentials. We ask that you take action now to confirm the Primary Contact information on your account in Partner Center is accurate and current.

Please note the information you provide to obtain Verifiable Credential will be verified by Au10tix Ltd, an industry leader engaged to support this effort. You will not need to disclose the information with Microsoft.

To complete your Verifiable Credential, you will need to install the Microsoft Authenticator app on your mobile device and follow the instructions. Microsoft Authenticator will store your Verifiable Credential. You will need a current and valid government ID in the physical form. The name on the government ID must match the Partner Center Primary Contact. For security purposes there are fixed time limits in the steps to obtain Verifiable Credentials. You may need thirty (30) minutes to complete the steps.

When you receive the Verifiable Credentials request from Partner Center, we urge you to complete the steps as soon as possible to avoid losing access to the Hardware Program. If you have any questions or issues, please reach out to our support team. For details on how to contact support, see Get support for Partner Center dashboard issues - Windows drivers | Microsoft Learn.

Thank you for your cooperation.

RESOLVED: HDC Web Dashboard Outage

kevintremblay — Fri, 29 Dec 2023 23:33:37 GMT

Updated 12/29/2023

Thank you for your patience. The issue has been resolved and service restored.

***

We are aware of an issue with the hardware dashboard and are working to remediate. As this issue occurred during our scheduled US Winter Holiday timeframe release moratorium, we are targeting restoration of service early in January. In the meantime, the API interface should still be available to you.

Please check the Hardware Dev Center Community Hub for updates.

2024 Driver Release Calendar and Block Out Dates

Garrettd — Fri, 08 Dec 2023 20:30:48 GMT

Here is our Driver Release Calendar for 2024!

The Driver Shiproom Release Calendar serves as a predictable way to understand our release windows when delivering drivers through Windows Update. For a full breakdown on the process, please visit our complete overview.