Windows Hardware Certification blog

HCK QFE 07 for Windows 8.1 now available

Certification team — Wed, 12 Mar 2014 17:44:20 GMT

For information about QFE updates, see Windows Hardware Certification Kit QFE Updates.

To get the latest QFEs for the Windows HCK, run HCKSetup.exe. The Windows HCK download includes all previous QFE updates.

Learn what's in the QFE

Download and install HCK to get the QFE

Download the QFE now

Note: Before applying the QFE, close all active HCK Studio sessions. Applying this QFE might affect in-progress submissions, so please complete any submissions before applying the QFE. After installing this QFE, you'll need to regenerate any affected submission that was generated before the QFE was installed.

Waiver to the Windows Logo License Agreement for Hardware Version 2014 (“LLA”) for use of the Windows Symbol on devices

Certification team — Thu, 27 Feb 2014 10:57:00 GMT

To address OEM feedback about the use of the Windows Symbol on devices, Microsoft is providing new size options and flexibility about the clear space and placement requirements for that logo.

These are the new requirements:

The Windows Symbol is now available in sizes ranging from 3 mm to 9 mm wide.
The required minimum clear space around the logo is being reduced to 0.5 mm from 1 mm. This is true also for the Windows 8 Hotkey Glyphs, Near Field Proximity Logo, and Application Icon.
Button placement requirements for the Windows Symbol are now found in the Windows Hardware Certification Requirements details. More flexible placement guidelines are provided.
The additional size and placement options for the Windows Symbol are available to all device types, regardless of screen dimensions.

If you have any questions regarding this communication or the LLA, please contact Microsoft in writing as provided in the notices section of the LLA.

Except as indicated above, the obligations under the LLA remain in full force and are neither waived nor modified.

The LLA and all communications related to it are covered under the existing non-disclosure obligations between the OEM and Microsoft Corporation.

Dashboard system submissions process simplified

Certification team — Wed, 26 Feb 2014 09:41:00 GMT

The Windows Dev Center hardware dashboard site has been updated so that partners are no longer required to enter the system certification BIOS or processor information when submitting system packages. Before the update, partners had to provide this data manually, which could slow down the process and introduce errors. This information is now pulled directly from the Hardware Certification Kit (HCK) client machine gatherer.

Here are the main reasons we’ve made this change:

To reduce human errors in providing this information.
To help create an accurate set of information in the product catalogs.
To help streamline the submission process.
To reduce the need to update the Dashboard site processor list on a regular basis.

The Windows Server Catalog and Certified Products List still contains the information needed by support organizations and end users to determine whether a system is certified and supportable.

MUTT software package update available

Certification team — Wed, 19 Feb 2014 11:35:00 GMT

Late last year a new version of the MUTT software package was released. For more information about this package, please see the documentation here.

Download the MUTT software package now

Changes to “System - Sleep and PNP (disable and enable) with IO Before and After (Certification)” test in February HCK QFE

Certification team — Tue, 11 Feb 2014 11:06:00 GMT

In the February 2014 HCK for Windows 8.1 QFE, these changes are made to the System – Sleep and PNP (disable and enable) with IO Before and After test:

You no longer need to configure all devices on the system before the test can run.

- We also released filter 4706 to remove the need to plug in a MUTT device.

The test run time is reduced by a factor of four.

These changes address the feedback we received about the test after we shipped Windows 8.1 HCK.

Existing filters & contingencies

As a result of reducing the test difficulty, all existing blanket errata filters and contingencies granted for this test will expire on March 31, 2014. Specifically, these filters (along with any blanket contingencies that were given) will expire on March 31, 2014:

4663 System - Sleep and PNP (disable and enable) with IO Before and After (Certification) to be waived while investigation is underway.
4664 System - Sleep and PNP (disable and enable) with IO Before and After (Certification) to be waived while investigation is underway - waiver for when logs are not generated.

Summary of changes

Driver verifier settings changes

Because of the driver verifier settings changes that we’ve made, you’ll notice a reduction in stress on the system when the test runs. This has been the case since the release of QFE 003.

Device configuration requirement change

We encourage you to plug in an optional MUTT/SuperMUTT device when running the test. We have released filter 4706 to filter out errors that occur because there is no MUTT device plugged in.

Recommendations

We recommend that you run the test with QFE 006 changes and report any test or operating system bugs to us.
The 0xC4 bug ensures that the test reports are legitimate WLAN driver bugs that must be fixed. Follow up with your IHV on any 0xC4 bug checks found. This can be done before or after certification. The IHV will need a copy of the .dmp file generated. If you need help with the investigation of these bug checks, you can contact driverqualitytools@microsoft.com.
Running the test with the MUTT/SuperMUTT device helps you find bugs in the USB controller and/or other devices enumerated on the USB bus (like webcams). So we strongly recommend that you run the test with the MUTT device connected. Simply connect the MUTT before starting the test and follow up on any issues that you find.

HCK QFE 06 for Windows 8.1 now available

Certification team — Tue, 11 Feb 2014 11:05:00 GMT

For information about QFE updates, see Windows Hardware Certification Kit QFE Updates.

To get the latest QFEs for the Windows HCK, run HCKSetup.exe. The Windows HCK download includes all previous QFE updates.

Learn what's in the QFE

Download and install HCK to get the QFE

Download the QFE now

HCK for Windows 8.1 and WLK 1.6 usage scenarios

Certification team — Mon, 10 Feb 2014 16:53:00 GMT

HCK for Windows 8.1 usage scenarios

The new HCK for Windows 8.1 supports certification for these operating systems:

Windows 7

Windows 8

Windows 8.1

Windows Server 2008 R2

Windows Server 2012

Windows Server 2012 R2

WLK 1.6 usage scenarios

WLK 1.6 supports certification for these operating systems:

Windows Server 2003

Windows Server 2008

Windows Server 2008 R2

Digital signatures for legacy operating systems

When you successfully complete testing for a client certification of Windows 7, Windows 8, or Windows 8.1, use the Windows Dev Center hardware dashboard to create a submission package for uploading - the same process that you’ve used in the past. And, if you’re using a unified driver that’s properly decorated to include Windows Vista and Windows XP, the dashboard has check boxes for digital signatures.

When you successfully complete testing for a server certification of Windows Server 2008 R2, Windows Server 2012, or Windows Server 2012 R2, you can also use the dashboard to create a submission package for uploading. Again, this is the same process that you’ve used in the past. And similarly, if you’re using a unified driver that’s properly decorated to include Windows Server 2003 and Windows Server 2008, the dashboard has check boxes for digital signatures. You can select the check boxes only if the driver being submitted was previously fully tested for certification. If you select these check boxes for Windows Server 2008 or Windows Server 2003, you must add to the supplemental folder a Readme file that includes the previous submission IDs for the Windows Server 2008 and Windows Server 2003 certification testing. All submissions for which you select these check boxes will go into the manual review queue so that the previous certification for Windows Server 2008 and Windows Server 2003 can be confirmed. If no Readme file is provided for the certification testing for Windows Server 2008 and Windows Server 2003, the submission will be canceled.

Self-test submission model for touch device and precision touchpad certification

Certification team — Thu, 23 Jan 2014 10:10:00 GMT

On January 1, 2014, the touch device and precision touchpad (PTP) certification program enabled a self-test submission model. Partners can now submit touch devices and precision touchpads for certification without sending hardware to WTTL/WPTL for full-test validation. We believe the self-test submission model will provide predictable submission turnaround time as well as standardized submission review criteria that are based on the provided submission test logs (HCKX logs). A certified THQA Blob will be granted when the submitted logs are validated.

The WTTL/WPTL full-test service will still be available as a certification path. We strongly recommend that you continue use the WTTL/WPTL service as part of development validation to ensure consistency in testing touch and PTP quality. WTTL/WPTL services will remain free of charge.

For more information about the process changes, see these documents:

· Windows Touch Device Certification Processes and Windows Touch Test Lab (WTTL) Service

· Windows Precision Touchpad Certification Process

Touch and PTP certification FAQs

What are the permissible ways to integrate a PTP?

A PTP module can be integrated into any system (clamshell or convertible) or dock accessory that also has an integrated keyboard. Standalone external PTP modules can’t currently be submitted.

I’m an OEM, and I’m building a dock accessory with an integrated PTP module. The dock is compatible with multiple systems, and the IHV submitted the dock with one of the supported systems. Do the other systems need to be submitted for certification?

No, the other systems don’t need to be submitted for device certification because each system is using the same module. We strongly recommended that the system certification tests be performed on all systems that can interface with the dock accessory.

I’m an IHV, and I’ve received device certification for a touch stack up module or a PTP module. I have multiple customers for the module, and each customer’s system requires different firmware. Do I need a separate device submission for each system into which the touch stack up or PTP module will be integrated?

Yes, if your architecture requires unique firmware for each integration project, the module must be certified with each firmware version. The module’s VID/PID will remain the same, but its revision ID is different for each project.

Upon resubmission of the updated firmware, you can continue to use the previously issued certified BLOB once the resubmission is approved. WTTL/WPTL will not be issuing new THQA BLOBs for resubmissions in this scenario.

I’m an IHV, and I’ve received device certification for a touch stack up module or a PTP module. I have multiple customers for the modules. If one customer wants a slightly smaller touch stack up or PTP, do I need a separate device submission for each customer?

Yes, a change in sensor size represents a new module and requires a new device submission, even if the controller and associated firmware remains constant. WTTL/WPTL will issue new THQA BLOB once the submission is approved.

When I have recertified the touch stack up or PTP module at the device level, do I need to recertify at the system level as well?

Yes, the system level tests must be run with the recertified module to ensure that the integration of the recertified module is successful. The passing system HCK results must be submitted.

What are the rules for third-party drivers and operating system build?

Touch/PTPs must function without any third-party drivers, except for I2C devices that might require GPIO and I2C controller drivers to function. These drivers are permissible and, if needed for device certification, should be submitted together with the system because the operating system will be clean-installed upon receipt.

Windows Hardware Certification requirement changes effective January 1, 2014

Certification team — Fri, 13 Dec 2013 15:19:00 GMT

This post provides an update to the September 17, 2013, Windows requirements publication on MSDN. The below requirement changes are intended to relax the Windows 8.1 system and device requirements and give our partners greater flexibility in designing and differentiating their tablet and PC products in 2014.

It’s important to understand that the changes remove or modify the specific requirements listed under the summary of changes only. (See tables below.) All other requirements will remain as before to support device interoperability, compatibility with Windows, and app platform consistency. The tests associated with these removed or modified requirements will remain in the Windows Hardware Certification Kit (HCK) to aid in the testing and measurement of your system’s quality. We’ll provide a set of HCK filters by January 1, 2014, to help you achieve the passing result needed for certification.

We’ve made these requirement changes to give you greater flexibility in bringing to market systems that customers demand. We encourage our partners to do the due diligence to understand the implications of these changes, especially the ones related to user experience. Additionally, these changes have no effect on any of the existing system designs that our partners have built for Windows 8 and Windows 8.1 platforms.

Device requirements - summary of changes

Requirement	Change type
Device.Audio.Base.Fidelity	Removed
Device.Audio.Base.InAirFidelity	Removed
Device.Digitizer.Touch.Bezel	Removed
Device.Network.LAN.SRIOV.SRIOV	Modified
Device.Network.WLAN.Base.MeetPerformanceReq	Modified
Device.Storage.Enclosure.DriveIdentification	Modified
Device.Storage.Hd.Sas.ComplyWithIndustrySpec	Modified

System requirements - summary of changes

Requirement	Change type
System.Client.BluetoothController.Base.BluetoothRequiredIfWiFiPresent	Removed
System.Client.Buttons.WindowsButtons	Modified
System.Client.Digitizer.Touch.Bezel	Removed
System.Client.NearFieldProximity.NFCPlacement	Removed
System.Client.NearFieldProximity.TouchMark	Modified
System.Client.Sensor.Integrated	Modified
System.Client.Sensor.MBBRequiresGPS	Removed
System.Client.SystemConfiguration.Windows8RequiredComponents	Modified
System.Client.Tablet.BezelWidth	Removed
System.Client.Tablet.RequiredHardwareButtons	Modified
System.Client.Tablet.TabletPCRequiredComponents	Removed
System.Client.Webcam.Specification.CameraRequirements	Modified
System.Client.Webcam.Specification.WNCameraRequirements	Removed
System.Fundamentals.DebugPort.SystemExposesDebugInterface	Modified
System.Fundamentals.Firmware.UEFIPostTime	Removed
System.Fundamentals.Graphics.Display.MinimumResolutionandColorDepth	Modified
System.Fundamentals.PowerManagement.CS.ConnectedStandbyDuration	Removed
System.Fundamentals.PowerManagement.CS.ResumeFromConnectedStandby	Removed
System.Fundamentals.SystemAduio.RequiredHeadphoneJack	Removed
System.Fundamentals.SystemUSB.SystemExposesUSBPort	Modified
System.Fundamentals.SystemUSB.USBControllerTransferSpeed	Removed

The current requirement documents (pdf and web versions) can be found here: Windows Hardware Certification Requirements.

Hardware certification submission fees update

Certification team — Fri, 13 Dec 2013 15:18:00 GMT

To help our hardware partners achieve certification qualification, the Windows Certification Program team is pleased to announce that all hardware certification fees will be dropped starting on 1/1/2014. Any hardware certification submissions that arrive on 1/1/2014 or later will not be invoiced for submission fees.

This is a great opportunity to lower your development costs by downloading the latest Windows Hardware Certification Kit (HCK) and testing your system or device for submission at this time.

The Windows Hardware Certification Policy document will be updated shortly to indicate that no hardware certification fees will be charged after 1/1/2014.

Errata expiration guidelines

Certification team — Tue, 10 Dec 2013 16:10:00 GMT

We've updated all active errata filters for the Windows Hardware Certification Kit (HCK). All active errata that weren't fixed in the test kit are now extended until 12/31/2014. We'll reevaluate all active errata again about 3 months before the new expiration dates. We'll either retire errata or extend the expiration date again, depending on whether fixes are in place for the test issues.

A few errata are set to expire between now and 12/31/2013 by design for delayed enforcement reasons or because fixes were implemented into the next HCK release. Those errata won't be extended again.

You can check the status of all errata any time on the Windows Dev Center hardware dashboard. To narrow down the list, use the filters to view only active, expired, or expiring within 30 days. You can also search by ID and title.

HCK QFE 05 for Windows 8.1 now available

Certification team — Tue, 10 Dec 2013 11:18:00 GMT

For information about QFE updates, see Windows Hardware Certification Kit QFE Updates.

To get the latest QFEs for the Windows HCK, run HCKSetup.exe. The Windows HCK download includes all previous QFE updates.

Learn what's in the QFE

Download and install HCK to get the QFE

Download the QFE now

Fast-track Windows 8.1 certification

Certification team — Thu, 05 Dec 2013 09:30:00 GMT

You can fast-track the Windows 8 certified devices listed in the table below for Windows 8.1 certification if:

The device was previously certified for Windows 8.
The device's binaries haven't changed since the submission for Windows 8, and only the INF is updated to reflect the new Windows version.

If the device meets these criteria, here's how you can create a submission:

Use the new Windows HCK for Windows 8.1, create a Windows 8.1 project, and run the Device.DevFund INF test.
Use the Windows Dev Center hardware dashboard to package the results for submission upload.
Include the previous Windows 8 submission ID in the README folder.
Reference errata ID 2657, "Windows 8 to Windows 8.1 driver certification update special," in the README folder.

Submissions are reviewed for these items:

The earlier Windows certification referenced in the README file.
The DevFund INF test passes.
No driver binary changes occurred. (We test this by using WinDiff.)

If the review is successful, the submission is free.

Certified Windows 8 devices and drivers that can be resubmitted for Windows 8.1 using the plan above

Digital Video Camera

Digital Media Renderer

Digital Still Camera

Distribution Scan Management Enabled Device

Enterprise WSD Multifunction Printer

Game Controller

Generic Controller

Graphics Tablet

Hard Drive - HDD, SSD

LAN

LCD

Monitor

Multifunction Printer

Optical Drive

Other

Pen Digitizer

Printer

Removable Storage

Router

Scanner

SDIO Controller

Signature Tablet

Smart Card

Smart Card Reader

Storage Array

Storage Controller (Client)

Storage Spaces Adapter (Client)

Storage Spaces Drive

Storage Spaces Enclosure

Touch

Touch Monitor

USB Hub

WSD Multifunction

WSD Printer

WSD Scanner

New or changed drivers require testing for Windows 8.1

If you're submitting a new device or driver not listed in the table above (or if you're submitting an updated driver that was previously certified), you need to test for Windows 8. However, you can request a Windows 8 signature without completely retesting with Windows 8. You'll need to prove that the INF is well formed for Windows 8 by following these steps:

Using the new Windows HCK for Windows 8.1, create a Windows 8.1 project, and run the full certification suite of tests.
Using the new Windows HCK for Windows 8.1, create a Windows 8 project and run only the Device.DevFund INF test.
Package the results of the projects for submission uploading by using the Windows Dev Center hardware dashboard packaging tools.
Reference errata ID 2656 "Windows 8.1 to Windows 8 driver certification downgrade special" in the README folder.

A submission is reviewed for these items:

The Windows 8.1 test results.
The DevFund INF test passes for Windows 8.
The same binary is used in both projects.

Pre-submission testing for UEFI submissions

Certification team — Tue, 03 Dec 2013 14:43:00 GMT

1 Introduction

This post provides guidance on how to test sign and verify UEFI modules before submitting them for signature by Microsoft UEFI CA. Before using the Windows Dev Center hardware dashboard to sign a UEFI driver or app, you should test sign your UEFI driver or app and verify it, following the guidelines provided here. Doing this helps you determine up front if your UEFI driver or app is signable and whether it works after being signed.

Doing QA on your product before having it signed by Microsoft UEFI CA reduces the likelihood of repeated submissions and so helps the Windows Dev Center hardware dashboard provide good turnaround time for signing, as each submission requires significant review resources from the dashboard.

Note: Don’t submit test signed UEFI modules to the dashboard. Submitted modules that are signed will fail.

2 Test sign and verify UEFI modules

Follow these steps to use and test your UEFI product before getting it signed by Microsoft UEFI CA:

1. Sign your product with your certificate (or a test certificate).
2. Add this certificate to the SecureBoot database.

3 Using Windows HCK to test sign and verify UEFI modules

You can use Windows HCK on a device running Windows by following these steps:

1. Prepare the test system.

2. Test sign the UEFI modules.

3. Install the “Lost” test certificate into the secure boot allow database.

4. Verify that test signed UEFI modules load and run successfully.

3.1 Prepare the test system

To install test certificates, including the “Lost CA,” onto a UEFI secure boot system to prepare it to test UEFI modules that are test signed, follow these steps:

1. Procure a UEFI secure boot–capable system for testing. The firmware should comply with UEFI 2.3.1 Errata C or higher.

2. In the BIOS configuration, enable secure boot custom mode and clear all secure boot keys and certificates. Note that some firmware ignores authentication of certain image paths, such as option ROMs. This should be re-enabled if you’re testing these image paths.

3. Install the Windows Hardware Certification Kit for the appropriate version of Windows on a computer running Windows Server, and uncompress C:\Program Files (x86)\Windows Kits \8.0\Hardware Certification Kit\Tests\amd64\secureboot\UefiSecureBootManualTests.zip to a USB drive.

4. On the test system, boot to Windows, start Powershell as administrator, and execute Set-ExecutionPolicy Bypass –force.

5. Execute ManualTests\tests\00-EnableSecureBoot\EnableSecureBoot.ps1 and reboot the system. This enables secure boot with a test KEK that will be used later to install the “Lost” test key into database.

3.2 Test sign the UEFI modules

Follow the example at ManualTests\generate\TestCerts\Lost\signApps.bat to learn how to sign UEFI modules using the Lost certificate chain:

· You’ll need to set your system clock back to 1/1/2012 to sign using the Lost certificate C:\WINDOWS\system32>date 1-1-12.

· You might need to import the Lost*.cer into your certificate store. To do this, in File Explorer, go to ManualTests\generate\TestCerts\Lost\, right-click each .cer file, and click Install.

· Run signtool.exe sign /fd sha256 /a /f “ManualTests\generate\TestCerts\Lost\Lost.pfx” <your_module.efi>.

We recommend that you use a computer running Windows 8 or Windows 8.1 for signing. If the system used is running Windows Vista or a previous Windows operating system, you’ll need to run signtool.exe from the SDK directory where it is installed. On these versions of the operating system, signtool.exe depends on manifests and DLLs in that SDK directory for the /fd option to function properly.

Verify that secure boot is enabled: After you complete the steps in “Prepare the Test System” above, secure boot should be enabled, but the lost key isn’t yet installed into the database. If you try to load the test-signed UEFI driver or app, it should be blocked from execution. Some BIOS systems display a warning message, others fail silently. If execution is blocked, secure boot is correctly enabled for your module load path. If the test-signed UEFI module runs, secure boot is not correctly enabled.

3.3 Install the lost test certificate into the secure boot allow database

Open PowerShell as Administrator and run the following command:

ManualTests\tests\01-AllowNewCertificate\append_LostCA_db.ps1

This adds the “Lost” test certificate chain to the allow database. You can verify that the system is properly configured by trying to run the UEFI test modules in the HCK (for example, ManualTests\apps\<ARCH>\pressanykey1.efi) via a UEFI shell. It should display the test name and prompt you to press any key on the keyboard.

3.4 Verify that test-signed UEFI modules load & execute successfully

After the secure boot system is configured to trust the test certificates and the UEFI modules to be tested are signed by the test certificates, you are ready to begin testing. Install the UEFI modules, reboot, and determine if the modules load and execute successfully. You can test UEFI drivers for hardware either by installing them into your option ROM or via the DRIVER#### UEFI variables.

4 Using other tools

Here are a few links that might be helpful:

Sourceforge - SecurityPkg

Signing UEFI Applications and Drivers for UEFI Secure Boot

However, you have to clear secure boot in the BIOS, and then you have to either boot to Linux to run Linux tools, or you have to use SHIM with MokManager UI (which allows you to set the databases if the system is in SetupMode).

Microsoft UEFI CA Signing policy updates

Michael Alberts - MSFT — Tue, 03 Dec 2013 09:36:00 GMT

This post describes UEFI Signing policy changes. These changes are important to help secure boot meet its security goals and also to maintain a reasonable turnaround time for signing UEFI submissions. This post also reiterates a few important parts of the existing UEFI signing policy licensing terms.

UEFI signing is a service provided by the Windows Dev Center hardware dashboard that lets you submit UEFI firmware binaries targeted to x86 or x64 computers for signing by Microsoft, so they can be more easily installed on computers running Windows that use secure boot and execute code signed with the UEFI CA.

While Microsoft reserves the right to sign or not sign submissions at its discretion, this list of requirements should be adhered to. Doing this will help you achieve faster turnaround times for getting your submission signed, and will also help avoid revocation. Microsoft might conduct follow-up reviews, including but not limited to questionnaires, package testing, and other security testing of these requirements before signing.

1. Starting March 15, 2014, UEFI submissions will require an EV certificate.

a. Starting March 15, 2014, SysDev will begin accepting EV certificates issued by either DigiCert or VeriSign for new submissions and renewals.

b. Existing submitters have until August 15, 2014, to move from existing non–EV code signing certificates to EV code signing certificates. This extension is provided to facilitate frictionless migration.

2. Only production quality code (for example, “release to manufacturing” code, rather than test or debug modules) that will be released to customers (no internal-only code or tools) are eligible for UEFI signing. For internal-use code, we suggest that you either turn off secure boot or add your own key to the SecureBoot database during development and testing.

3. Code submitted for UEFI signing must not be subject to GPLv3 or any license that purports to give someone the right to demand authorization keys to be able to install modified forms of the code on a device. Code that is subject to such a license that has already been signed might have that signature revoked. For example, GRUB 2 is licensed under GPLv3 and won’t be signed.

4. If there’s a known malware vector related to code that uses certain techniques, that code won’t be signed and is subject to revocation. For example, the use of versions of GRUB that aren’t SecureBoot enlightened won’t be signed.

5. All code modules must be authenticated before execution. If this is not the case, submissions won’t be signed, and, if already signed, are subject to revocation.

a. If your submission loads a GRUB or other loaders, it must be SecureBoot enlightened.

For example, the latest GRUB 2 with SecureBoot patches.

b. Developers might assume that secure boot security requirements have been satisfied when their initial boot is complete. However, if a secure boot system permits launch of another operating system instance after execution of unauthenticated code, the security guarantee of secure boot is compromised. If this vulnerability is exploited, the submission might be revoked.

6. If your submission is a shim (handing off execution to another bootloader):

a. Certificates embedded in the shim must all be EV Certificates, and the Organization attribute in all these embedded certificates must be same as the Organization attribute in the EV Certificate on file for the SysDev account.

b. If you lose keys or abuse the use of a key, or if a key is leaked, any submission relying on that key will be revoked.

c. Some shims are known to present weaknesses into the SecureBoot system. For a faster signing turnaround, we recommend that you use source code of 0.7 or higher from shim - GitHub branch.

7. You must test your product, following the Pre-Submission testing document (for UEFI Submissions), before submitting for signing.

Welcome to the Windows Hardware Certification blog

Michael Alberts - MSFT — Tue, 26 Nov 2013 16:24:02 GMT

This is the new Windows Hardware Certification blog, where you can get Windows Certification Program news and info. All the updates and info you’re used to seeing in the Windows Certification Newsletter will be available here, and you’ll be able to post comments and join in conversations with the Certification team and other community members. You can also expect to see updates on a more timely and flexible schedule.

After a short transition period, the email newsletter will be retired.

To subscribe to this blog, see the Feeds options on this page.