Windows Certification Program
Hardware Certification Policies and Processes
January 7, 2014
Abstract
This paper provides information about the Windows Hardware Certification Program.
It contains high-level guidelines on certification testing and product submission
policies, and useful business process requirements. This document has been updated
to reflect new processes and policies for the launch of Windows 8.1
Document History
Date
January 7, 2014
November 22, 2013
Change
Submission fees removed. Updated Touch Device
Resubmission instructions. Addition of Graphic Adapter Test
Optimization Procedure.
Added links to certification newsletter and certification blog.
July 3, 2013
Updated for Windows 8.1, Server 2012 R2, and the revised
HCK for Windows 8.1. Added contingency policy and
simplified Windows 8 testing. New fees for submissions are
documented.
November 13, 2012
Added Windows RT connected devices, specialized PC,
updated details for multifunction device testing and docking
stations.
October 26, 2012
Updated testing fees for Windows 8 and Windows
Server 2012.
Added information on the policy for using previously certified
motherboards in client systems.
May 10, 2012
Added information on Signature-only policies, UEFI
requirements, and server testing requirements.
Additional edits for style and clarity.
February 28, 2012
First publication
Windows Certification Program - 2
Disclaimer: This document is provided "as-is". Information and views expressed in this document, including
URL and other Internet website references, may change without notice. Some information relates to prereleased product, which may be substantially modified being commercially released. Microsoft makes no
warranties, express or implied, with respect to the information provided here. You bear the risk of using it.
This document does not provide you with any legal rights to any intellectual property in any Microsoft
product. You may copy and use this document for your internal, reference purposes.
© 2014 Microsoft. All rights reserved.
DirectX, Microsoft, MSDN, Windows, Windows Server, and Windows Vista are trademarks of the Microsoft
group of companies. All other trademarks are property of their respective owners.
January 7, 2014
© 2014 Microsoft. All rights reserved.
Windows Certification Program - 3
Contents
Introduction ................................................................................................................... 5
Overview of Windows Hardware Certification .............................................................. 5
General certification concepts, policies, and processes ................................................ 6
How requirements are defined and tested ............................................................... 6
Turning a positive test result into certification.......................................................... 7
Product Types ............................................................................................................ 7
Testing optional features and functionality............................................................... 8
How do I know what requirements my product needs to meet? ............................. 8
What if my product type is not automatically discovered? ....................................... 8
“Other” products and conditional certification ......................................................... 8
General certification testing policies ............................................................................. 9
General testing guidance ........................................................................................... 9
Testing all features and functionality ...................................................................... 10
Seeking Windows HCK support................................................................................ 10
Correcting false test failures with errata ................................................................. 10
Contingencies........................................................................................................... 11
Merging test results into a single submission or project ......................................... 12
Submission requirements ............................................................................................ 13
Legal agreements ..................................................................................................... 13
Essential agreements........................................................................................... 13
Optional agreements ........................................................................................... 13
Symbol files .............................................................................................................. 14
Listing products ........................................................................................................ 14
Product naming........................................................................................................ 15
Naming restrictions ............................................................................................. 15
Product name details........................................................................................... 15
Post-certification requirements ................................................................................... 16
Certification and support obligation lifetime .......................................................... 16
Audits ....................................................................................................................... 17
Audit selection and product procurement .......................................................... 17
Response to observed audit failures ................................................................... 17
Submissions types that don't require complete testing .............................................. 18
Reseller submissions ................................................................................................ 18
Driver update acceptable......................................................................................... 18
Conditions where a DUA is acceptable................................................................ 19
Conditions for a DUA ........................................................................................... 19
Submissions for device driver maintenance ............................................................ 19
Acceptable device changes without resubmitting................................................... 19
Simplified submissions for Windows 8 .................................................................... 20
Testing policies for devices .......................................................................................... 21
Device family testing ................................................................................................ 21
Definition of family .............................................................................................. 21
Determining when to consider a group of devices as a separate family ............ 21
Portable device families ...................................................................................... 24
Network media device families ........................................................................... 25
Multifunction devices .............................................................................................. 26
Special cases for multifunction devices ............................................................... 27
January 7, 2014
© 2014 Microsoft. All rights reserved.
Windows Certification Program - 4
Testing devices with multiple connectivity.............................................................. 28
Switched-mode devices ........................................................................................... 28
Windows RT connected device certification and testing......................................... 28
Testing exception for network media devices and routers ................................. 29
Para-virtualization drivers........................................................................................ 29
Touch device testing ................................................................................................ 31
Touch Device Resubmission and Multi-source Subcomponents ............................. 31
Graphic Adapters Test Optimization Procedure .......................................................... 32
Testing policies for client systems................................................................................ 33
Certified components .............................................................................................. 33
Digital signature policy for systems ......................................................................... 33
Systems and the use of Signature-only components .............................................. 34
System form-factor definitions ................................................................................ 34
Using previously certified motherboards in client systems..................................... 35
Specialized PCs ......................................................................................................... 36
Testing a docking station designed for the system ................................................. 37
System family testing and updates that require a new submission ........................ 37
Testing GPUs across different GPU families ........................................................ 38
Using Distributed Testing for System Family Testing .......................................... 38
Touch device ........................................................................................................ 39
Sensors ................................................................................................................ 39
UEFI requirements for systems and devices ................................................................ 39
UEFI configuration for system certification ............................................................. 39
UEFI client system required for device testing ........................................................ 40
UEFI and Server systems .......................................................................................... 40
Testing policies for server system ................................................................................ 41
Up-level and down-level certification policies for Windows Server 2012 and
Windows Server 2012 R2 ......................................................................................... 41
Run Server tests on physical hardware.................................................................... 41
Rules that control server system testing and retesting ........................................... 41
Closing comments ........................................................................................................ 42
January 7, 2014
© 2014 Microsoft. All rights reserved.
Windows Certification Program - 5
Introduction
Welcome to the Windows Certification Program for Windows 8.1. This document
updates earlier versions to reflect the changes in the program brought about by
Windows 8.1, Windows Server 2012 R2 and the Windows Hardware Certification Kit
for Windows 8.1.
This document contains the business policies to prepare products for Windows 8.1
and Windows Server 2012 R2 for use with x86/x64-based systems and successfully
certify those products. The policies for certifying devices for Windows RT are
included. The policies and processes for testing and submitting Windows RT systems
are covered in a separate document.
For clarification, contact [email protected] with any questions.
Overview of Windows Hardware Certification
The Windows Certification Program is the primary channel that we use to
communicate to the partner community the core expectations that Windows places
on devices, kernel-affecting software, and systems so that those products can
successfully and seamlessly integrate into Windows. This communication starts with
the core tenets and user scenarios that drove Windows design. Those design
principles translate into a set of features that cover fundamentals, connectivity, and
device-specific features. These design features are codified as discrete requirements
which define what Windows expects from the various components and connected
devices. A device designed to meet the requirements will be reliable, stable, efficient
in power and performance, and provide a great Windows experience.
The program is unique in the industry in terms of the detail and engineering tools
that can freely provide to build, test, secure, and maintain products for success in the
Windows environment. No other program provides access to in the field telemetry to
facilitate end-user support and quality assurance, nor as powerful a method to
deliver software, driver and certain firmware updates to end-users to correct
identified problems or allow new features to be embraced.
Partners can self-assess how their products comply with certification requirements by
using the tests in the Windows Hardware Certification Kit (HCK). The current version
of the Windows HCK is named the Windows HCK for Windows 8.1. The Windows HCK
for Windows 8.1 supports testing all actively certified versions of Windows and
contains significant enhancements to encourage efficient testing practices, such as
early and focused testing, distributed testing and merged multifunction device
fundamental testing. Not all requirements are testable in an automated fashion, and
automated testing can't fully assure absolute compliance with the requirements, so
we continue to analyze the end-user experience and improve the tools over time.
Certification is a public statement of confidence from us that the tested device, filter
driver, or system works well with Windows. Certification benefits include:

Signing the device drivers.
January 7, 2014
© 2014 Microsoft. All rights reserved.
Windows Certification Program - 6

Publishing the product as certified in various catalogs and the compatibility
center.

Collecting and pre-analyzing telemetry on your product in the field to
improve your quality assurance efforts.

Providing a free and extremely effective distribution channel for driver
updates.

Providing eligibility for various marketing incentives and a logo license.
The following processes and policies describe how the program moves from a
collection of requirements and tests to certification of a product. These policies can
have an impact on a product's eligibility for certification and the efficiency of your
efforts. Use them in planning for testing cycles and resources.
The Windows Certification Program continuously re-evaluates the requirements and
the test environment, with major revisions timed to Windows releases. This policy
and process guide reflects the latest requirements and testing philosophy. We
reserve the right to revise these policies as needed to improve the program. Revisions
in the policies described here will be announced in the certification newsletter or in
the certification blog, and changes will be listed in the Document History section of
this document.
The Policy FAQ on MSDN may address questions regarding these policies. For any
additional questions that are not covered in the FAQ, contact [email protected].
Questions on policy are also taken in the forum located at
http://social.msdn.microsoft.com/Forums/en-US/whck.
General certification concepts, policies, and processes
How requirements are defined and tested
Some key terms describe how we test the Windows scenarios that certification is
validating.
A feature is a Windows capability that is exposed or enhanced by a device or a kernelmode driver. Features fit into these classifications:

Fundamental features that are common to any device or driver in the
environment.

Connectivity features that are necessary for a particular bus and protocol to
work successfully.

Critical features that are necessary for a particular product to interoperate
with Windows.

Optional features that enhance the experience that the device provides.
Features use a descriptive CamelCase name, like Device.Graphics.WDDM13,
System.Client.BluetoothController.Base, or Filter.Driver.Network.LWF.
A requirement is the written document that specifies what a device must do to
qualify for Windows hardware certification. See Windows 8 Hardware Certification
January 7, 2014
© 2014 Microsoft. All rights reserved.
Windows Certification Program - 7
Requirements in the Windows Dev Center. Within the namespace, requirements are
descendants of features. For example, Device.Imaging.Scanner.Base.RawFileFormat is
a requirement for the feature Device.Imaging.Scanner.Base.
The Windows Certification Program uses the Windows HCK to assess compliance with
the requirements. The Windows HCK uses a unique method to determine which tests
are necessary to run. The Windows HCK identifies the features of the product that is
being tested and generates a set of tests for the test harness to schedule. For specific
guidance on how to use the Windows HCK, see Windows Hardware Certification Stepby-Step Guide. This document includes policies for testing practices. The current
version of the Windows HCK is HCK for Windows 8.1.
A product type is a collection of features that are associated with a particular device,
filter, or system in common use with Windows. Product types are important for
identifying a category of product for catalogs, compatibility lists, and the dev nodes
and inner workings of Windows. Most partners who are engaged in the certification
program are actively seeking to certify a particular product that matches a product
type.
Turning a positive test result into certification
Anyone can download and use the requirements and the Windows HCK. We
encourage you to design your product to meet the certification requirements and
then test compliance with the requirements throughout the product cycle. However,
to fully participate in the certification program and have the product certified, you
must register with the Windows Certification Program through the membership
process that is described at the Hardware and Desktop dashboard in the Windows
Dev Center.
After you register with the program and the product has completed testing, create a
submission package and submit it for certification at Hardware and Desktop
dashboard.
Product Types
The process for hardware certification has changed. In the earlier kit, Windows Logo
Kit 1.6, you selected a category to test and assumed that that category contained the
right set of tests that exercised all of the device features that interoperate with
Windows. The Windows HCK implements feature-based testing. The test harness
detects all of the features of the device that interoperate with Windows and
schedules testing for all implemented features. The certification process evaluates all
of the exposed features of the device, rather than only a subset of features.
This new approach has a definite advantage when the device being tested does not fit
neatly into a defined category or exposes multiple functions. For example, a device
may connect in many different ways. Each method represents a testable feature.
These connectivity features don't contribute to the definition of product types, but
are expected to be tested as an exposed feature.
Tests are grouped into product types rather than categories, which provide certified
product with a label that is appropriate for cataloging.
January 7, 2014
© 2014 Microsoft. All rights reserved.
Windows Certification Program - 8
When a device is tested, the kit identifies any product types that the device is eligible
to claim in the catalog. If more than one product type matches the features that a
device exposes, you may choose what product type best describes the device.
Testing optional features and functionality
Definitions of product types contain only the minimum feature set that is necessary
to describe those product types. Windows is designed to support beyond the basics
in many scenarios, and many defined features are optional. The Windows HCK tests
any known features that your product exposes to Windows. For a product to be
certified, it must pass all the Windows HCK tests. The tests validate the required and
optional features of the product.
How do I know what requirements my product needs to meet?
All Products will expose a suite of features that can be categorized into 5 basic
groupings. These features map to requirements and tests. The five groups are:
1. Basic features expected of any device, filter or system (the fundamental
features)
2. The connectivity features exposed for the type of connectivity the device
uses.
3. The features that define the basics of a Product Type
4. The optional features that are associated with a feature area. If your device
or system exposes an optional feature the device must successfully comply
with all of the associated requirements.
5. Additional features that are related to secondary functions added to the
product. For example, removable storage is commonly found on mobile
broadband USB-connected units.
For your convenience, a product type matrix is located at
http://download.microsoft.com/download/2/3/6/23662F33-71E8-43C1-85475DE49B0374AB/windows-hck-product-type-matrix.zip. This file can help identify all
of the features, requirements and tests your submission will need to comply with for
certification.
What if my product type is not automatically discovered?
Occasionally the gatherer will not detect all of the features your device supports and
therefore the product type options exposed in the kit for certification does not
include the certification product type you are after. In this case, from the selection
tab in the HCK, right click to see the list of all features and manually add the missing
features. This process will improve over time as the detection becomes more
sophisticated.
“Other” products and conditional certification
Some devices introduce features for which Windows has no specific design scenario.
In previous programs, a product that does not map to a product type was called
January 7, 2014
© 2014 Microsoft. All rights reserved.
Windows Certification Program - 9
Unclassified and was tested with a limited set of tests which assured the driver
installed correctly but little else. As a platform, we embrace innovation, but we
retain the reliability and performance of Windows by testing whatever features these
innovative devices expose to the operating system. These unclassified devices that do
not match a Product Type are now designated “Device-Other” or in some cases a
more specific classification like “Storage Device-Other” to reflect certain additional
features in key areas were exposed. The Other classification allows for signing of the
drivers and distribution on Windows Update, but the device does not receive the
complete benefits of a certified product.
If your device does not match any product type definition no product types will
appear in the Windows HCK. On submission, however, the option “Device –Other”
will be visible.
The limitations of “Other” products are:

They aren't certified for Windows because they don't match recognized
product types that are designed for Windows scenarios.

They aren't mentioned in certified product listings or catalogs.

They can't use the Windows logo artwork.

To avoid confusion with certified products, “Other” products can't use the
same product names as certified products.

A certified system can't replace expected functionality normally provided by a
component of a defined product type with an “Other” product.
Despite these limitations, “Other” devices do receive important benefits:

The product's driver receives a Microsoft digital signature and is distributable
on Windows Update.

The product can take advantage of metadata services.

Microsoft telemetry services identify a “Other” product in data sets, and that
data becomes available to the submitter.
General certification testing policies
General testing guidance
All testing for certification uses the Windows HCK. The harness and tests receive
updates at major releases of operating systems and service packs. Generally
certification begins at the Release Preview of the forthcoming new Windows and use
the Windows HCK released at that time will be used. Typically when the RTM version
of the operating system is released the Windows HCK will also be updated. Each time
the harness is updated, a transition window of 90 days or more is provided for the
orderly migration of testing from the previous kit.
Each device submission must include test logs and the corresponding device drivers.
Devices that use in-box drivers (drivers that are included with Windows) must be
tested for certification, but no in-box drivers are included in the submission package.
January 7, 2014
© 2014 Microsoft. All rights reserved.
Windows Certification Program - 10
Each system submissions must include test logs. The certification specifically applies
to the hardware firmware and/or BIOS that was tested. To maintain the certification,
the product must retest if the hardware, firmware, or BIOS changes, with certain
minor text-only exceptions.
Testing all features and functionality
Any product that is tested and submitted for certification must:

Meet all applicable requirements for device fundamentals, including any
Windows Driver Foundation (WDF) requirements.

Meet all device connectivity requirements for the connectivity type or types
that the device uses. Devices that use more than one type of connectivity bus
must test successfully for all the applicable connectivity buses.

Pass any tests that apply to any features that are attributed to the device
while under test. The Windows HCK detects any feature that Windows is
designed to handle in a special manner. This testing assures that the device
behaves as Windows expects from any device that exhibits these features.
This helps assure reliability, stability, and compatibility.
This includes products whose exposed features don't match the definition of any
product type. For a feature that is detected on a product, the feature must pass
testing, if the product will be submitted.
Seeking Windows HCK support
To obtain help with the Windows HCK, open a support case with CSS. They will
provide technical support.
Customers who have a Premier support contract can use their Partner Technical
Manager (PTM) to open support incidents for high-priority handling.
For customers who don't have a Premier support contract, professional support
options, including telephone numbers and pricing information, are available at
Microsoft Support.
For more information, see Windows Hardware Certification on MSDN.
Correcting false test failures with errata
Occasionally, test bugs cause failures that are encountered during certification, rather
than product failures. The Windows HCK can filter out false failures by using errata
filters. These filters find false failures in the test logs and scrub them to a passing
state. The errata filters receive regular maintenance. Download errata filters regularly
to your test environment to detect any current issues with the Windows HCK. The
details on how to download and apply filters is found at
http://msdn.microsoft.com/en-US/windows/hardware/hh852367.If a potential false
failure is detected and isn't filtered by the current errata, open a service request with
Microsoft Customer Service and Support (CSS). If the root cause of the issue is a test
error, an errata filter allows bypassing the problem until a later update of the
Windows HCK.
January 7, 2014
© 2014 Microsoft. All rights reserved.
Windows Certification Program - 11
Errata can't filter some test failures and may appear as a failure on automated
review. Where possible, an informational filter known as an auto-triage filter
identifies these issues. Informational filters don't reverse detected failures but
instruct the tester to correct the test environment, or to contact CSS for further help
to determine whether the failure is legitimate or an ambiguous test result. If you
encounter such an issue, confirm the status with CSS and submit even though the
logs still contain an apparent error. Such failures are manually reversed. For details
about how to properly document the failure for a manual review, contact CSS or
[email protected].
Contingencies
In certain cases, a product cannot meet the published requirements or pass certain
certification tests. Mitigating circumstances may surround the product’s failure
where the partner may appeal to Microsoft to review the Product’s failure with the
objective that the product may still receive certification. In the case of devices with
drivers perhaps the device remains uncertified but we would allow signing of the
driver. These exception requests are called Contingencies and their outcome is
determined by a review board. Contingency requests are considered in the context
of the customer promise provided by certification and the failure’s impact on the
end-user experience.
A contingency request is made using a standardized form which documents the
specific failures, customer impact, business impact, and proposed mitigations. If
approved by Microsoft, an online legal agreement documents the terms and
conditions surrounding the approval of the contingency as agreed to by Microsoft
and the partner.
Contingencies are rare compared to overall submissions, but an important process for
providing flexibility to the interpretation of the requirements. Incoming contingency
requests are reviewed first by the certification team and feature owners to
understand the merits of the request and assign a severity rating to the request (or
rejected outright). For failures that are assessed to have minimal end user impact, a
decision may be concluded quickly. However, if the request represents a significant
departure from the requirements the discussion is broadened to many groups and
the discussion takes considerably longer for a decision to be reached. A complex
contingency review could take 4 to 6 weeks with considerable communication for
additional details, out of band testing and research. Approval should not be assumed
even when similar contingencies have been granted to your company in the past
since the readiness of the eco system and end user expectations evolve over time.
Where possible the request should include the actual test logs to document the issue.
This greatly facilitates review and internal discussion and the ability to actually create
a filter to remove the failure on submission, should the request be approved.
However, it is a good practice to inquire about a decision early if the design is known
to conflict with the requirements even if the device cannot yet be tested, so you do
not invest time and effort into designs or build products that prove to be
unacceptable by the standards.
January 7, 2014
© 2014 Microsoft. All rights reserved.
Windows Certification Program - 12
The contingency program has considerable flexibility in disposing of a case. Virtually
all will require a timeline to bring the product into compliance. In more significant
cases, contingencies may require additional steps such as consumer disclosure of the
product’s limitations, audit of shipping product, heightened telemetry review of the
product’s performance, a defined SLA for response to detected issues, or other
mitigation measures.
Approved Contingencies are not covered under Non-Disclosure Agreement (NDA) as a
practical matter since the filters used for passing a contingent submission are the
same as the filters used for errata and are downloadable by all partners. Microsoft
reserves the right to publish information regarding the affected hardware products. If
the device would be used as a component in a system, Microsoft expects the
contingency will be disclosed to OEMs.
To request a contingency send email to the [email protected] alias or other
contacts you are provided to request the appropriate forms and instructions. Failure
to follow those instructions fully and completely will delay in the evaluation of the
request as the triage team will be coming back to you to gather the information
before further processing.
Merging test results into a single submission or project
The Windows HCK for Windows 8.1 brings some important new efficiencies which
allow testing in a project to be distributed over a group of identical systems.
However there are some situations where testing will need to occur in different
projects. Some partners may want to split testing across projects, controllers, or even
physically separated labs. The Windows HCK allows for merging test results from
separate projects under certain conditions.
A typical situation is one lab that focuses on testing earlier versions of Windows while
another tests Windows 8.1, yet the partner wants to make a single submission for all
of the operating systems and architectures. The Windows HCK environment allows
for completed projects that tested different platforms and operating systems for the
same system, filter, or device to be merged into a single submission package.
To combine the projects for a submission, create a submission package under the
“Package” tab and select the “merge package” option. You will be allowed to include
a previously completed Project file (.hckx) as part of this package. Note that
whatever is added cannot be changed. For instance the tests cannot be rerun or any
missing tests completed.
In addition to combining completed .hckx files per operating system and the
architecture, it's possible to test portions of a single-product submission across
different projects (even from different controllers) and merge the test results into a
single submission package. Such "deep merged projects" allow testing of components
that require expensive setups to run in a special lab. They also allow teams that are
responsible for different subcomponents of a single product to be responsible for
their testing of their feature.
The rules for deep-merged project testing are:
January 7, 2014
© 2014 Microsoft. All rights reserved.
Windows Certification Program - 13

The products under test must be identifiable as the same product—same PnP
IDs, container IDs, driver binaries, and firmware.

The deep-merged features must be for the same operating system and
architecture.

The entire set of features identified under a dev node must be run together
in the same project. Features associated with the same dev node can't be
tested in different projects and then merged.

All tests for any feature must be run in the same project on the same
controller.
Because system testing doesn't target a specific dev node, it's not possible to break a
system submission across multiple projects and deep merge the results.
Submission requirements
Legal agreements
Participation in the Windows Certification Program requires a company to have
signed an effective Logo License Agreement and Windows Certification Program
Testing Agreement. All certification submission activity requires these agreements on
file. All legal agreements that are related to the Windows Certification Program are
signed at the Hardware and Desktop dashboard in the Windows Dev Center.
Essential agreements
Windows Certification Program Testing Agreement. This agreement includes
language that is related to testing procedures, testing policies, intellectual property
rights, support requirements, audit policies, payment policies, indemnification,
warranty, liabilities, confidentiality, term and termination, metadata, and digital
rights management (DRM) clauses. Signing this agreement is required for
participation in the program.
Windows Logo License Agreement. This agreement includes specifications for logo
artwork usage, license grants and restrictions, indemnification clauses, disclaimer of
warranty, and limitation of liability statements. This agreement is required to submit
any product for Windows Certification or driver signing.
New versions of the Windows Certification Program Testing Agreement and Windows
Logo License Agreement will be posted for signature before Windows 8 submissions
begin.
Optional agreements
These agreements control access to additional services that are available to
participants in the certification programs or if the company is submitting in areas that
have additional legal restrictions placed on them.
Windows Error Reporting Agreement. This agreement provides access to the
telemetry data that is available on the Hardware and Desktop dashboard in the
January 7, 2014
© 2014 Microsoft. All rights reserved.
Windows Certification Program - 14
Windows Dev Center. The agreement defines the restrictions on acceptable use of
the data.
Test Sign Driver Agreement. This agreement allows a company to sign drivers that
are under development by using a special Microsoft certificate. The agreement
defines the restrictions on acceptable use.
Digital Rights Management Agreement. With this agreement, Microsoft can sign
with the Protected Environment (PE) attribute drivers that are involved in the
transfer and display of digitally protected media.
To accept the legal agreements, establish a Windows Certification account and
designate a representative from the company to accept legal agreements on the
company's behalf. Users who have the "Sign Master Legal Agreements" permission
role can sign legal agreements for an organization.
If you have any questions about the legal agreements, contact
[email protected].
Symbol files
We strongly recommend that partners submit the symbol files for their drivers,
including those that don't match a defined product type. The symbol files help in the
crash analysis and improve telemetry and feedback. Symbols are particularly helpful
for Signature-only drivers, where we are unclear what the function of the device may
be. The absence of symbol files can result in incomplete or wrong analysis, causing
the wrong driver to be accused for a crash. It's acceptable to submit public symbols
that don't detail the driver's functioning but still allow bucketing of crash failures
bucketing and meaningful telemetry for partner analysis. The more detailed the
provided symbols are, the better the analysis can be and the more accurate
information the telemetry services may provide to you.
Listing products
A benefit of certifying products is that they're searchable in a variety of listing
catalogs. This is useful for consumers and for enterprise verification of certification
status. All certification-qualified submissions that match a defined product type are
provided to the catalogs on the announcement date that the submitting company has
entered.
If the submitter provides no announcement date, the product appears in the catalog
two weeks after submission. Providing a date far into the future is an effective way to
avoid a catalog listing but still keep the products on the certified list used for legal
reference.
After the product is in the market and the partner-selected announcement date has
passed, a listed product remains listed. Products that don't qualify for product types
as defined by the Windows Certification Program are not eligible to receive a product
listing.
Certification-qualified products are currently listed in the following catalogs:
•
Windows Compatibility Center
January 7, 2014
© 2014 Microsoft. All rights reserved.
Windows Certification Program - 15
•
Windows Server Catalog
•
Hardware Compatibility List
Product naming
Product naming is extremely important for tracking what products are certified.
Naming is key for consumer education, use of the certification logos on products and
in advertising, and legal tracking.
Naming restrictions
The primary product name of a device or system that is given at submission must
uniquely identify one specific device or system. If your company produces several
distinctly different products under a marketing name, use the most distinct product
name for the purposes of identifying a submitted product. After a submission has
passed testing, you can use a product management tool to add marketing names. Any
marketing names become published to the catalogs. They may be subject to audit by
us. Marketing names appear in responses to inquiries of appropriate use of
certification, such as from customs agencies and bib verification since certification is
frequently a basic bid criteria with enterprise purchasers. For these reasons among
others, we require that the product names that are listed in our product catalogs be
detailed and accurate.
Product name details

A company may submit products only for itself and may not submit products
on behalf of a third party.
For example, an independent testing lab that was contracted to test products for
an original equipment manufacturer (OEM) may not submit such products on
behalf of the OEM. The product submission package is submitted using an
account under the OEM's administration, and the OEM must accept any or all
agreements that apply to that product.

A single product name is assigned during the initiation of the submission.

After submission approval, additional marketing names may be added
through the Product Listing Wizard, if all names meet the allowable change
requirements that are posted for the product type.

The product name of a device or system must uniquely identify one specific
device or system and must not be a generic name.
For example, "Laser Printer" can't be used as the product name of a laser printer.
However, "Laser printer model 5003", "Laserprint 2893", and "QuickLine 2" are
acceptable names.

If a series name is included in the product name, the product name must also
include a model name or number to uniquely identify that individual device
or system. This requirement prevents confusion with other products in the
Windows catalogs.
For example, "Laserprint series" can't be used as the product name of a laser
printer. However, "Laserprint series model 5003" and "Laserprint 2893" are
acceptable names.
January 7, 2014
© 2014 Microsoft. All rights reserved.
Windows Certification Program - 16

The product name can include only the marketed product name, model
number, and/or version number.
For example, a keyboard that is submitted with the product name "Quick-key" is
acceptable. However, a submission that includes multiple product names such as
"Quick-key/Quick-key mobile, Quick-key 5000" isn't allowed. The additional
names must be entered through the Product Listing Wizard after the submission
for the product name has been approved.

The product name can't include any marketing slogans or tag lines.

The product name can't include any Microsoft trademarks.
Post-certification requirements
Certification and support obligation lifetime
With certification comes a commitment to the end user of product support for the
reasonable lifetime of the product. The Windows Certification Program provides
services to make this commitment possible through access to field telemetry and the
ability to certify driver fixes and deliver them to end users. This policy clarifies the
expected lifetime and support levels for certified products.
The Windows Certification Program aligns with the Windows release and support
schedules. Our commitment to supporting products ties to the milestones for end of
sales, end of mainstream support, and end of extended support of the operating
system. This information is available on the Windows lifecycle fact sheet.
This overall product schedule defines three phases for the certification program.
Phase
Release to
Manufacturing to
end of retail sales of
operating system
To end of
Mainstream Support
Program supports
Systems and devices that
are certifiable for the
operating system
Time frame
System certification retires when
the operating system is no longer
sold preinstalled.
Devices that are
certifiable for the
operating system
Device certification retires at least
5 years from general availability,
or 2 years into the life of the next
operating system.
To end of Extended
Devices that are signable, At least 5 years from general
Support
distributable
availability, or 2 years into the life
of the second successor version.
System certification ends after the operating system is no longer available for OEM
pre-installation, but device certification continues into the expected usable lifetime of
that operating system.
An important part of the Windows experience is the assurance that an investment in
a product has a meaningful lifetime. End users expect that their purchases will
continue to work if they upgrade to a new operating system. Each release of the
operating system works with devices that are designed to the standards of the
previous release of the operating system, at least in a deprecated fashion. Products
that are submitted to the Windows Certification Program are expected to support the
January 7, 2014
© 2014 Microsoft. All rights reserved.
Windows Certification Program - 17
next operating system. The device may not meet increased standards and
functionality of the new operating system, but at a minimum, the device must work
in the new operating system with functionality that is equivalent to the functionality
that was demonstrated in the previous operating system.
You may test previously certified drivers in the new operating system and make those
drivers available on Windows Update. In some cases, we may ask partners to update
drivers that were previously certified for a previous operating system.
Extended support is typically a commitment that companies make to enterprise
buyers. We don't commit to continuing a full testing program to cover devices under
extended support, but it does provide a signing process and a fundamental program
so that the best possible drivers remain distributed on Windows Update.
Audits
We periodically audit certified systems and devices to ensure that the requirements
and tests are having the intended impact on quality of the Windows experience and
to plan for future improvements in requirements and testing. These audits are not
intended to be punitive. The nature and focus of the audits vary over time as we
explore areas of the certification program that can be improved.
Audit selection and product procurement
Any device (any hardware ID) that is included in a device or system submission,
reseller submission, or marketing name submission can be selected for an audit. In
some circumstances, we purchase an audited product at retail. For other audits, we
may ask the partner to provide the product, at the partner's expense, including all
shipping charges.
We reserve the right to specify the exact product name or hardware ID of the product
that is submitted for audit. We return partner-provided audited hardware, if the
company requests it. We assume no liability for returned hardware that was
reconfigured or damaged during testing or shipping.
If we request a particular product, you must provide the product configured in retail
packaging within 30 days, following the direction provided by the Windows
Certification Program. Any special instructions required to configure the device or
system for certification should also be included with the audit hardware.
Response to observed audit failures
Occasionally, we may find in audit a significant issue that places a product out of
compliance with the goals of the certification program. If the observed issue is
significantly outside expected performance (for example, reliability, security, missing
critical experience), we notify partners about the audit results, describe the required
fixes to bring the product back into compliance, and set the required timeline for
implementing the required updates. If we and the partner can't agree to terms on the
requested changes, we reserve the right to remove the certified status of the
product. The noncompliant product then drops from our catalogs. The Windows logo
must be removed from the product and all packaging and promotional materials
associated with that product.
January 7, 2014
© 2014 Microsoft. All rights reserved.
Windows Certification Program - 18
Submissions types that don't require complete testing
In some cases, complete testing isn't necessary.
Reseller submissions
The Reseller Submission Policy allows companies that purchase a certified product
from a manufacturer to resell as their own and receive a listing in the Microsoft
catalogs and Hardware Compatibility List. Resellers repackage and relabel the
purchased device or system with the right to display the logo. Resellers must have
sign a Logo License Agreement in order to claim certification rights to the resold
product.
Reseller submissions don't require retesting. A reseller submission retains a
dependency on the parent submission. If the parent submission fails an audit, the
reseller submission also fails.
Products that are submitted as a reseller submission have the following restrictions:

The reselling company can't change the hardware or software when
relabeling or repackaging the product, except for branding or splash-screen
changes to identify the product under the new company name.

The distribution rights for the original driver remain with the original
submitter.

If a reseller wants to control distribution for its product, take the following
steps:
1. Revise the PnP ID of the product to include the subvendor ID.
2. Submit a Driver Update Submission that revises the information (.inf) file
to reflect the new PnP ID.

If a reseller wants to change the driver binary for a device, a new initial
device submission must be made (with full testing).

All reseller submissions are subject to audit.

For a peripheral device (connected device) whose primary function is outside
the interaction with the PC and whose functionality is evaluated by the
Windows HCK, changes that don't affect the interaction between the device
and the PC or affect the applicable requirements are not considered grounds
for a resubmission.
For more information:

See Manage Hardware Logo Submission in Dashboard Help.

Refer to Driver Update Acceptable (DUA) and audit policies as they relate to
this policy.

Refer to Device Family Testing policies as they relate to this policy.
Driver update acceptable
Occasionally, a certified device requires that its driver be modified in ways that don't
change the binaries and interoperability of the device with a system. In these cases,
you may submit a DUA package.
January 7, 2014
© 2014 Microsoft. All rights reserved.
Windows Certification Program - 19
Conditions where a DUA is acceptable
For an already approved driver submission, changes to driver packages that add,
remove, or modify files that don't interoperate with or otherwise affect driver
functionality or reliability are allowed via a DUA submission. A DUA submission may
include only changes in file types: .txt, .htm, .rtf, .chm, .hlp, .inf, .icm, .jpg, .bmp, .cpl,
.pdf, .mht, or txtsetup.oem. No changes are allowed for the driver binaries (such as
.sys and .dll. You may add new hardware IDs in the INF file as part of these updates,
provided that they meet the family policies.
Conditions for a DUA
Retesting isn't required for a DUA submission. The Hardware Dashboard performs a
WinDiff file comparison with the original to ensure that no binaries have changed.
Submissions for device driver maintenance
Microsoft recognizes the need to maintain devices and improve driver quality for
devices already certified and in the marketplace. Maintenance submissions are
allowed so drivers may be tested and submitted for recertification after new logo
requirements are implemented for specific features and required for certifying for
certain product types. The device is resubmitted including the failures resulting from
new tests in the certification since originally submitted.
In a maintenance submission, the original certification submission ID must be
referenced in the submission readme file. Any test assertions that fail under the new
kit will be reviewed to assess whether the original bar was met. It is the responsibility
of the company submitting to identify the new failures in the individual tests that are
new and were not there previously. Our expectation is that partners will ensure that
there have been no regressions after updating the product. This should be
documented using the standard readme.doc file that is included with the submission.
Maintenance submissions are not a method to recertify for a new major Windows
release (client or server), such as Windows 8 to Windows 8.1. A product must meet
the certification requirements for the new operating system in order to obtain a
certification and use the Windows logo artwork. Note: a similar maintenance
recertification is available for system submissions.
Maintenance submissions must comply with the following restrictions:

No new PnP IDs can be added to the INF file.

The driver can't be used with new products.

Don't add new product names to the catalog.
Acceptable device changes without resubmitting
The Windows Certification Program takes into consideration that not all
device/firmware changes affect the interoperability of the device with Windows.
There are guidelines for when a retest and resubmission are necessary.
Silicon chipset size reductions (die shrinks) are allowed, provided that the device ID or
subsystem device IDs are unchanged, no functionality is added or modified, and the
January 7, 2014
© 2014 Microsoft. All rights reserved.
Windows Certification Program - 20
drivers are unchanged. If the die shrink affects other certification requirements, such
as S3 resume time, the device requires a full retest and resubmission.
Changes that require resubmission include:

Changes in device components, firmware, or BIOS, with exceptions as noted
in "System Family Testing and Updates Requiring a New Submission" later in
this paper.

Changes to touch device components.

Changes in supported operating systems or I/O interfaces (also known as
buses) not found in the original submission.

Changes to multifunction devices.
Simplified submissions for Windows 8
In many device areas for Windows 8.1, the device requirements are identical to
Windows 8 or possibly a superset where if a device can pass for Windows 8.1 the
device would pass for Windows 8. To simplify your testing efforts we are allowing a
simplified testing regimen for the following Product Types. This is primarily designed
to allow drivers to be signed for Windows 8 without full retesting.
Product Types where a Certified Windows 8.1 devices/drivers can be
resubmitted for 8.0 (details below)
Distribution Scan Management Enabled Devices
Enterprise WSD Multi-Function Printer
Graphics Tablet
LAN CS
LAN
Multi-Function Printer
Pen Digitizer
Precision Touchpad
Printer
Scanner
SDIO Controller
Signature Tablet
Smart Cards
Smartcard Reader
Storage Array
Storage Controller (Client)
Storage Spaces Adapter (Client)
Storage Spaces Drive
Storage Spaces Enclosure
Touch
Touch Monitor
USB Hub
WSD Multi-Function
WSD Printer
WSD Scanner
In any of the Product type areas listed, a certified Windows 8.1 driver may receive a
Windows 8 signature without complete retesting by proving the INF is well formed
for Windows 8 .
January 7, 2014
© 2014 Microsoft. All rights reserved.
Windows Certification Program - 21
A. Using the HCK for Windows 8.1, create a Windows 8.1 project, and run the
full certification suite of tests.
B. Create a Windows 8 project and only run the Device.DevFund INF test.
C. Package the results of the projects for submission uploading, using the portal
packaging tools.
D. Reference errata ID 2656 “Windows 8.1 to Windows 8 driver certification
downgrade special” in the README folder.
The submission will be processed in the following manner:
A. Confirm the Windows 8.1 test results.
B. Confirm the Devfund INF test is passing for Windows 8.
C. Confirm using the same binary is used in both projects.
Testing policies for devices
Device family testing
The Windows Certification Program requires that each family of devices be tested
and submitted to Microsoft, even if the driver is identical for each submission. If your
INF file contains devices that are considered different device families but you don't
intend to test them, remove the extra devices from the INF file.
Definition of family
A device product family is a set of devices that expose the same functionality or a
subset of functionality and would interoperate with Windows in exactly the same
manner. A member of the device family that contains the full set of all the features
must be the "tested representative" for the family. All devices that are a subset of the
most fully featured products must meet all certification requirements for their
functionality.
Determining when to consider a group of devices as a separate family
Evaluate each device that the driver supports. If any of the following conditions apply,
create a new family:

If a device uses a different device class, Peripheral Component Interconnect
(PCI) class and subclass, or vendor ID (VID).

If a device uses different driver binaries or uses a separate INF file.

If a device has different firmware.

If a device supports different bus protocols. If multiple protocols are
supported, such as SCSI, Internet SCSI (iSCSI), or Fibre Channel, these
protocols must be tested separately and are considered separate families.

If a device supports different media or drive types.

If a device supports multiple protocols, media, and drive types, each
combination must be tested separately and are considered separate families.
January 7, 2014
© 2014 Microsoft. All rights reserved.
Windows Certification Program - 22
There are some exceptions to these rules. The following devices have additional
characteristics to classify families.
South Bridge SATA and ATA/ATAPI controller families
Controllers that are integrated into a South Bridge chipset must support the same
base logic. If the driver supports an add-in controller, the add-in must be tested as a
separate family device.
RAID controller, iSCSI adapter, and Fibre Channel adapter families
Controllers that have identical core BIOS code and ASIC firmware are tested as a
single family. String changes to the BIOS code are allowed between family members.
If the BIOS code or firmware is updated, another family submission is required.
RAID system and RAID JBOD families
The number of controller modules within the same family may differ.
Controller hardware and firmware must be the same for a particular family.
If the controller hardware or firmware is virtual (consists of only software), any major
revision of this software for added functionality (such as bus speed) requires a new
family group.
Non-multipath or non-Microsoft Multipath I/O (MPIO) drivers: A complete RAID
system test must be completed against each RAID system device that is included in
the INF file.
Third-party multipath and Microsoft MPIO driver implementations: A scaled test
procedure is available to test multiple families. For more information, see the
corresponding section of the multipath test procedure. This scaled test procedure
does not grant base qualification or certification to these additional subsystems.
GPU families
Graphics processing units (GPUs) that don't support the same major Microsoft
DirectX revisions are in different GPU families.
Here are some DirectX revision examples:

GPU A supports DirectX 10 and GPU B supports DirectX 10.1 = same GPU
family.

GPU A supports DirectX 9 and GPU B supports DirectX 10 = not the same GPU
family.

GPU A supports DirectX 10 and GPU B supports DirectX 11 = not the same
GPU family.

GPUs that are not manufactured by the same company are part of different
GPU families. For example, GPU from Vendor A and GPU from Vendor B (any
DirectX revisions) = not the same GPU family.
Mobile broadband device families

If a mobile broadband device supports multimode operation (for example,
GSM and CDMA), the mobile broadband device must be tested and
submitted in all supported modes.
January 7, 2014
© 2014 Microsoft. All rights reserved.
Windows Certification Program - 23

Any firmware changes that affect the mobile broadband data path and
control path functionality that are defined in the Windows mobile broadband
driver model require a resubmission.

Firmware changes in a mobile broadband device that don't affect the data
path and control path also require a resubmission, except in the following
cases:

Firmware changes to support different frequency bands for different
geographies and operators

Firmware changes to support different VID or product ID (PID) for
mobile operator or OEM customization

Firmware changes to add OEM-specific module authentication

INF file changes in a mobile broadband driver to update the VID or PID for
mobile operator or OEM customization are in the same device family and
don't require resubmission.

Devices that have a different generation of chipset are considered a member
of a different family and require resubmission.

Devices that have a chipset from a different manufacturer are considered a
member of a different family and require resubmission.

For a multifunction mobile broadband device (for example, a mobile
broadband device that also includes GPS functionality), the impact of a
firmware change to the other functions of the device (in this example, GPS)
on the device family is governed by the guidelines of the certification
program for that device class.
Windows 7 touch families
In the case of Windows Touch digitizers that differ only in screen size, this policy is
clarified in the following way.
Note: the following clarification applies to only differences in the dimensions of the
screen size of the devices and only for Windows 7 submissions. Any changes to
drivers, firmware, controller/optical/sensors, or bus connections require
resubmission of the device according to standard procedures.
Manufacturers of Windows Touch digitizers don't need to resubmit devices that differ
only in screen size if the differences fall into an allowable range that has been defined
by previous submissions of the same device. The allowable range for a particular
device is defined when:

At least three successful submissions have been approved for that device at
different screen sizes.

Of the three successful submissions, the size of the midsized screen falls into
the middle third of the distance between the smallest and largest size
screens.

The new device does not add a different power capability (for example, DC)
that isn't present in the three devices, which define the range.
January 7, 2014
© 2014 Microsoft. All rights reserved.
Windows Certification Program - 24
Screen size is measured as the diagonal dimension of the touchable area of the
screen, in millimeters, to two decimal places. Submissions that make up a range may
be submitted in any order.
For example, a partner makes three successful submissions of the same device, with
same power configuration, at screen sizes of 600 mm, 500 mm, and 560 mm. These
three submissions define an allowable range for that device of 500 mm to 600 mm.
(For the midsized device, any size between 533.33 mm and 566.67 mm is considered
valid as the midpoint of this allowable range. The middle third is defined as one-third
of the difference between the smallest and largest size [100 mm / 3 = 33.33 mm]. The
33.33 mm falls in the middle band, with 16.67 mm on either side of the midpoint.)
After an allowable range is defined, any new devices that are produced within the
allowable range are not required to be resubmitted for certification.
Devices that have a screen size outside that of the allowable range, or that add new
power capabilities such as DC battery power, must be submitted in accordance with
standard submission procedures.
Any submission of the same device at a different screen size that fails the Windows
Touch verification tests does not invalidate certification for the sizes that were
previously submitted. Failing the Windows Touch verification tests simply means that
the experience at that screen size is inappropriate for the purposes of defining or
extending the allowable submission range for the device.
Portable device families
Devices that are submitted for portable devices product types require hardware
certification testing at the product family level.
Any licensee or reseller of a portable device product family can take advantage of
submissions that were made by the original submitter by completing a reseller
submission. A reseller submission is necessary to legally transfer the certification
rights to the licensee.
The definition of the portable devices product family consists of the following areas:


Software requirements: Product family uses the same operating system and
firmware.

Operating system may include a service pack (point upgrade) from
the original submission.

OEMs that add extra functionality on the interaction with the PC are
required to make a new submission.

Firmware must be evaluated to provide an acceptable experience
with the device operating system.
Common components: The family of devices must support the same core
components that outline the experience with Windows, such as:

Codecs

Transports

Protocol
January 7, 2014
© 2014 Microsoft. All rights reserved.
Windows Certification Program - 25
Additional supported features are acceptable unless they affect the overall kit
results for the product type.

Minimum hardware specifications: A baseline specification is required to
belong to the product family.

Chipsets: Processor capacity can't be lower than that in the original
submission specification.

Memory: Capacity that is available to the system must exceed the original
submission.
We exclusively define the list of product families. We reserve the right to modify the
list of product families at any time without prior notice.
Network media device families
Devices submitted for the Digital Media Renderer (DMR) product family require
hardware certification testing at the product family level. Successful passing of
hardware certification tests enable certification of the other members of the product
family.
We exclusively define the product families by using the following characteristics:

Operating system

Firmware

Minimum hardware specifications
If a product family is developed by a third-party OEM and resold to other
manufacturers, then the product certification applies to all devices that are released
under the same hardware design, operating system, and firmware that were released
under a reseller agreement.
Changes to firmware require a new submission for the parent device using the
updated firmware.
Significant changes to hardware that may affect the certification test results also
require a new submission.
Software-based network media devices can be grouped as a family of products. The
following requirements define a software product family:

Software DMRs must pass the same tests as hardware DMRs. The
implementer must install the software DMR in its typical platform. The DMR
is then connected to the PCs that drive the certification tests. Each test
results in a pass/fail outcome. A DMR that passes all tests can apply for
Windows certification.

Software DMRs apply for certification for a specific platform. The following
parameters define a platform:
Parameter
Operating
1
Options1
Windows 7, Windows 8, Windows RT
Implementers can enter other options if they are not listed here.
January 7, 2014
© 2014 Microsoft. All rights reserved.
Windows Certification Program - 26
system
CPU base

Android Gingerbread, Android Honeycomb, Android Ice
Cream Sandwich
Mac OS X Snow Leopard, Mac OS X Lion
iOS version 4, iOS version 5
Intel x86, Intel x64, ARM, Apple A4/A5
Any change in platform parameters requires recertification. For example, a
software DMR that runs in Windows 7 must be recertified for Windows 8.
Additional notes, clarifications, and processes
Although it's possible to test multifunction devices by using the family rules described
previously, be aware that the resulting certification might cause some confusion in
the catalog and marketplace. The highest set of features is associated with the
submission, so a catalog listing where a particular sought-after feature isn't included
in all devices in the family could be confusing.
For example, in a multifunction family submission, if the highest-functioning device
used several connectivity pathways, but some of the subset family members did not
include all of the connectivity pathways, the catalog listing might be confusing.
There's currently no way for the certification program to handle this listing issue.
Device drivers often support more than one device, such as a printer driver that
supports 10 different models of printers, or a display driver that supports 25 different
PnP IDs. To assure quality, we recommend that vendors test every device that a
particular driver supports.
We recognize that in a particular device category, there are cases where testing a
model that is the most fully featured, or one that is physically and electrically
identical to another model, offers no increase in test coverage. In these cases,
conducting an additional test pass for certification would not expose any additional
hardware or driver flaws.
In an effort to simplify and reduce the amount of testing that is required to achieve a
certification on every hardware/driver combination, the following rules apply to your
device testing coverage plan. Devices that are considered equal to each other are a
family of devices. A particular driver may have 100 unique PnP IDs in the INF file, but
after you apply these device-testing policies, you may find that only 10 devices must
be tested to achieve full test coverage for your device/driver combinations.
Multifunction devices
Some devices contain multiple features that are associated with more than one
unique product type. Multifunction printers, for example, often include a scanner,
fax, and removable storage. Radio devices may support multiple frequencies and
protocols, which expose to Windows as seemingly unrelated features.
A multifunction device presents to the Windows HCK by its Container ID, which
identifies the collection of devices bound together in the same plastic, same chip set,
or same card. The Windows HCK probes each PnPID in the collection for the features
it exposes. The entire collection must pass in order for the multifunction device to be
certified. It's acceptable for some of the devices in the collection to offer unique
January 7, 2014
© 2014 Microsoft. All rights reserved.
Windows Certification Program - 27
functionality that does not match a product type (Signature-only product as
described previously). A multifunction device, which includes these Signature-only
products, is certified if matches at least one product type and passes testing of all
exposed features.
As with any product tested in the Windows HCK, all features detected on the device
must pass in order for the product to receive certification. There are some special
testing cases in which certain devnodes can be deselected if they match the criteria
that follow.
If for some reason the use of a ContainerID isn't appropriate, each functional unit and
connectivity type in the multifunction device must be tested separately and the logs
combined and submitted as a single submission. For a multifunction device that
works with multiple drivers, all drivers must be installed on the test machine prior to
testing the entire device. This requirement ensures that the
installation/uninstallation of one of the drivers of a multifunction device doesn't
impair or interfere with the operation of the other drivers or functionality of the
device.
Devices may include a bus port that enumerates no functional units and is for
maintenance only. If multiple bus ports exist, each must have identical functionality.
It isn't acceptable for any bus port to offer only a subset of supported functional
endpoints.
Special cases for multifunction devices
The general rule for all Windows HCK testing is that any exposed features must be
tested in their entirety for the device to be certified. However, with some common
multifunction devices, there's an exception is made for the child nodes of USB
composite devices. In these situations, you may deselect certain tests because the
device fundamental testing against the parent node exercises the USB child nodes.
Rules for deselecting certain Device Fundamental tests:
1. These exceptions are allowed only for multifunction devices that contain
printing, storage, or mobile broadband product types as part of the
multifunctionality. All other multifunction devices must be tested in their
entirety.
2. The parent node USB Composite Device DevFund tests are run in their
entirety.
3. Any child USB composite nodes that don't contain any feature sets other than
the Device Fundamental tests may be deselected and not tested. If the
subnode contains additional features, none of the features may be
deselected from it. All features in that subnode must be tested.
4. For multifunction devices with an internal USB hub, you may not deselect any
USB root hub devnodes with child nodes that expose features that run
additional DevFund tests.
For clarification regarding these rules, contact [email protected] and include a
screenshot of the nodes or the full name of the node.
January 7, 2014
© 2014 Microsoft. All rights reserved.
Windows Certification Program - 28
The Windows Hardware Certification Program reserves the right to expand or
contract the areas covered in the "Special Cases" section as more devices are
identified or user experience issues are detected. The Windows Hardware
Certification Program reserves the right to eliminate the "Special Cases" clause of this
policy if evidence of impact to user experience is related due to the application of the
criteria specified in the "Special Cases" section.
Testing devices with multiple connectivity
Test a multiple connectivity device by connecting the device to a client through all
available pathways that the device supports. After a device is identified as the testing
target, the device's multiple connectivity are detected and treated as features,
minimizing the number of tests that must be run.
Switched-mode devices
Some devices—cameras, for example —switch modes on the device controls,
establishing a different communication with Windows for each mode. The Windows
HCK can't detect these different modes automatically and doesn't automatically test
all features of the multifunction device. These devices require manual reconfiguration
to completely test the functionality. We recommend that you treat each mode as a
separate project and merge multiple projects into a single submission package.
Network Media devices may contain a single device that communicates with the
system, but that one device may contain multiple product types, such as both
Network Media Display and Render. After the Windows HCK identifies the target,
these functions are enumerated as part of the gatherer activity, and all of the
features are exposed for testing. In some cases a Network Media device may have
certain functions that are only exposed if the device experiences a mode change. A
tester with knowledge of the device should recognize the inability of the controller to
detect this feature and manually reset the device, testing these additional features as
separate projects and merging the multiple projects into a single submission package.
Windows RT connected device certification and testing
Windows RT uses class drivers and in-box drivers exclusively, departing from a
common driver added scenario on the x64 or x86 architectures. Connected devices
on Windows RT are tested and certified using only the in-box or class driver.
A device cannot be certified only for Windows RT and not Windows 8 as well. The
Windows RT certification is always in addition to the certification the device has
undertaken for Windows 8.
Windows RT occurs with the device connected to a Windows RT system running as a
client in the Windows HCK environment (subject to the exceptions noted below).
Connected devices are certified for Windows RT if the device passes all relevant
certification tests with the Windows RT in-box or class driver, passed Windows 8
certification on X64, and meets the additional requirements found in the Logo
Licensing Agreement (LLA). The LLA includes important details for how certain
connected devices may display the Windows RT Certification Logo and additional
information that must be disclosed on packaging for multifunction printers that
January 7, 2014
© 2014 Microsoft. All rights reserved.
Windows Certification Program - 29
display the Windows RT Certification Logo. The Windows RT testing exceptions
follow.
Testing exception for network media devices and routers
Network media devices and routers interoperate with Windows using network
protocols, not architecture-specific drivers. Network media devices (NMD) and
routers can be certified for Windows RT when they pass Windows HCK tests using an
x86/x64 client system. An NMD or router does not need to be retested in a
Windows RT environment to display the Windows RT logo. Testing for routers is
available only in the x86 environment and testing in the x86 environment is sufficient
for x64 certification. Similarly, a NMD need only be tested on x64 or x86 to qualify for
certification for all three platforms (x86, x64, and RT). See the LLA for additional
information regarding the appropriate use of the certification logo on connected
devices that are certified for Windows RT.
Para-virtualization drivers
Para-virtualization drivers are device drivers in a virtual machine instance of the
Windows operating system that represent hardware and functionality similar to, but
not necessarily identical with, the underlying physical hardware that the system
virtualization software layer uses.
For example, the physical network interface adapter that is installed in the system
can be either presented or abstracted to the virtual instances of Windows. The paravirtualization driver emulates a network adapter, but it's not necessarily the same
network adapter as the physical device.
The Windows Certification Program qualifies device and driver combinations
according to the Windows Hardware Certification Requirements and the relevant
tests. The Hardware Dashboard accepts para-virtualization driver submissions by
using the current testing guidelines. These drivers are tested, submitted, signed,
granted certification, or displayed in the relevant catalog through existing device
driver procedures. Specifically:

The submitted para-virtualization driver must emulate the same functionality
that is required of physical devices and their associated drivers. This includes
installation, Advanced Configuration and Power Interface (ACPI), PnP, and
other functionality, as described in the respective Windows Hardware
Certification Requirements.

A submission of a para-virtualization driver may occur only for the version of
the Windows Server operating system that is used for testing as a virtual
instance. In addition, a submission of a para-virtualization driver may occur
only for the platform version of the Windows Server operating system that is
used for testing as a virtual instance—specifically, the x86, x64, or Itanium
processor platforms.

The para-virtualization driver must be tested in accordance with the test
requirements that are relevant to the Windows operating system version for
which the para-virtualization driver is being submitted. For example, server
storage and networking drivers must be tested on a system that has a
minimum of 4 processors and 6 gigabytes (GB) of memory installed. The
January 7, 2014
© 2014 Microsoft. All rights reserved.
Windows Certification Program - 30
submitted storage or networking para-virtualization driver must be tested in
a virtual machine instance of Windows that has 4 processors and 6 GB of
RAM represented, if the virtualization product supports those capabilities. In
testing storage and networking para-virtualization drivers, if the virtualization
product can't support a Windows virtual instance of 4 processors and 6 GB of
RAM, the testing should occur with the maximum processor count that is
supported by the virtualization product for a Windows Server virtual
instance, and with the maximum amount of RAM that is supported by the
virtualization product for a Windows Server virtual instance, not to exceed 6
GB of RAM.

Other device category requirements for the minimum number of processors
and the minimum amount of memory required for testing of that device
category apply, as detailed in the documentation for the test that is
appropriate for that version of the Windows Server operating system.

The submitted para-virtualization driver must pass all the tests that are
defined and required for the device category that the para-virtualization
driver represents to a virtual instance of Windows, appropriate to that
version of Windows.

The submitted para-virtualization driver that meets all the requirements and
passes all the tests that are defined and required for the device category that
the para-virtualization driver represents to a virtual instance of Windows will
be granted certification.

If the Windows HCK exposes a feature, the feature must be tested and pass
to receive a signature. In the earlier Windows Logo Program, it was possible
to receive a signature if the device could not pass the full requirements of a
category. In the current Windows Certification Program, all exposed feature
must pass testing.

No submitted para-virtualization drivers may use the universal/Signatureonly category for a submission if the Windows HCK exposes a feature or if a
Windows Certification Program device category exists for the class of device
and driver that the para-virtualization represents to a virtual instance of the
Windows operating system. If the Windows Certification Program determines
that there's no suitable device category for the - driver, the
universal/Signature-only category tests may be used for testing and
submission. Vendors of para-virtualization drivers that the vendors believe
should use the universal/Signature-only category must communicate with the
Windows Certification Program and confirm that the Windows Certification
Program agrees with their assertion prior to testing and submission.

The submitted para-virtualization driver that meets all the requirements and
passes all the tests that are defined and required for the universal/Signatureonly category will receive a Signature-only, because there's no certification
for universal/Signature-only devices or drivers.

If an issue is encountered during testing of the para-virtualization driver, that
issue must be resolved before a test submission occurs. Resolution can occur
in the following ways: by correcting the issue; by referencing an errata ID,
January 7, 2014
© 2014 Microsoft. All rights reserved.
Windows Certification Program - 31
incident ID, or contingency ID number; or by following the process that is
outlined in the Hardware Certification Program Policy for Issue Resolution.

All other Windows Certification Program policies apply to para-virtualization
drivers, including policies regarding required retests, resubmissions, product
naming, reseller, audit, grant of certification, and distribution.

The Windows Certification Program will cease accepting submissions of paravirtualization drivers for a specific version of Windows on the same date that
submissions are no longer accepted for physical devices.
Touch device testing
Successful touch devices depend on a high degree of integration between many
materials. Although the Windows operating system interoperates with the controller,
a good controller may still provide a bad user experience if it's paired with the other
components incorrectly. For this reason, touch hardware must be submitted, because
it will be paired for shipping as a touch device.
The touch device consists of the key components integrated together, which allows
for physical user input and interactions to be interpreted and communicated to the
system via a bus. All components must be integrated together as a device that is
targeted at a specific environment or system, to help ensure that touch quality does
not degrade after it is integrated into a system.
The components that define a touch device are not bound to a specific touch
technology and may include (but are not limited to):

Controller, including all touch device firmware, configuration software,
integrated circuits, and board design.

Conductor layout and pattern.

Glass and/or film configuration, including digitizer, display and cover glass
stack, glass/film thickness, bonding architecture, and surface treatment.

Display characteristics, including screen size, aspect ratio, and resolution.

Image sensor positions (locations and height) and reflector material.

Transducers or other methods of sensor detection.

Communication bus (USB or I2C)
Touch devices must be pre-calibrated and must not require any additional calibration
before usage.
All touch devices in a system must be separately addressable and independent of one
another. Each touch device must be individually tested and submitted for
certification.
Touch Device Resubmission and Multi-source Subcomponents
Any changes to touch device components require a full retesting and submission of
the touch device for recertification. If identical subcomponents are sourced from
different manufactures, recertification must occur to ensure touch reliability and
performance is maintained. The same PID and THQA may be utilized when identical
subcomponents are utilized in and existing touch device.
January 7, 2014
© 2014 Microsoft. All rights reserved.
Windows Certification Program - 32
A touch module is defined as the combination of a unique touch controller IC and
touch sensor. Each distinct touch module must have a unique PID that is exposed to
the host. Multiple systems may use the same touch module with differing LCD panels,
however it is highly recommended that each touch module and LCD panel pairing be
independently certified. Changes in bus connectivity (USB/I2C) for a touch module
shall not require a PID change as the module itself is materially identical, however it is
highly recommended that a module be independently certified with each connectivity
option.”
Graphic Adapters Test Optimization Procedure
To encourage a high quality hardware ecosystem for Windows 8.1, a set of test
optimizations are being introduced to help re-balance logo testing and allow partners
to invest more in Windows 8.1.
This procedure becomes effective immediately and is only applicable for Graphic
adapter product type on client OS SKU’s.
The following grid outlines the testing requirements of this procedure.
Client OS/Arch
Certification Log Requirements for Windows 8.1
Windows 8.1 client x86
Reduced WHCK logs *
Windows 8.1 client x64
Complete WHCK logs
Windows 8 client x86
Reduced WHCK logs *
Windows 8 client x64
Reduced WHCK logs * if the same GPU is targeted for logo for
Windows 8.1 client, else Complete WHCK logs
Windows 7 client x86
Reduced WHCK logs *
Windows 7 client x64
Complete WHCK logs
*Reduced Testing is required to ensure that the necessary logs are included for the
drivers to be signed for PE and involves the partner joining one client and running the
included tests.
Procedure Applies
Description
Tests Included
Applicable Product Type
Test Environment
Requirement
1. Device Driver INF Verification Test (Certification)
2. COPP - Protocol Test
3. OPM - Protocol Test
Full graphic adapter product types
WHCK Release with Windows 8.1
January 7, 2014
© 2014 Microsoft. All rights reserved.
Windows Certification Program - 33
Log requirement for
Windows 8.1 with previous
OS submission
Log requirement for Win 8.1 full-set for x64 and reduced log
set for x86 stands true if log submission requirement met for
either Win7 x86/x64 or Win8 x86/x64.
Submission Requirements:
 Listing errata 1274 in the readme
 The 64-bit and 32-bit drivers must be submitted together for this
optimization to apply.
o Since both the 64-bit and 32-bit drivers are Logo certified, both will
be entered into the LPL
This procedure does not apply for below condition, and a complete WHCK log set is
required for both x86 and x64:
Procedure DOES NOT Apply
Description
OS Architecture
Windows RT architecture
Applicable Product Type
DisplayOnly or RenderOnly graphic adapter product types
Test Environment
Requirement
If testing for a single OS only
OPT-Out
Any device may choose to conduct full Logo testing and will
continue to receive a Logo certification
Microsoft Reserved Right:
It is expected that partners will continue to thoroughly test the Windows drivers and
will ensure high quality of drivers. Microsoft reserves the right to terminate this
Optimization Procedure at any time without prior notice.
Testing policies for client systems
Certified components
Certified systems must use certified components. Component-level testing reduces
the need to repeat the same testing for the system certification. Component features
require retesting on the system level only when there's a possibility that integration
issues may be exposed in the context of a completed system. Some Windows
Hardware Certification Requirements may exceed system requirements, and systems
must meet all of the certification requirements to obtain a certification.
Digital signature policy for systems
The Microsoft digital signature on drivers helps ensure reliability and compatibility
with Windows. The preinstalled image that is shipped on certified systems must
include device drivers that are signed for the shipped operating system or use in-box
January 7, 2014
© 2014 Microsoft. All rights reserved.
Windows Certification Program - 34
drivers. All components in a system must meet the definition of a defined product
type to be included in a system, unless a product type does not exist.
For example, if the system ships with Windows 8, all drivers on the system must be
signed for Windows 8 or use in-box Windows 8 drivers. Similarly, if the system ships
with Windows 7 and is shipping Windows 7 preinstalled, all drivers that are shipped
on the system must be signed for Windows 7.
The drivers may be signed for multiple versions of Windows.
Systems and the use of Signature-only components
A certified system may use a Signature-only component only if the Signature-only
component serves a unique function beyond the functionality that Windows natively
supports. If a defined product type that an end user would expect to find on a
certified system exists, the use of a Signature-only component that does not include
all of the features expected of the component makes the system ineligible for
certification. This rule applies for all Windows client and server operating systems.
Contact [email protected] with specific questions.
System form-factor definitions
Certain Windows scenarios apply to particular form factors, and the features and
requirements for those scenarios are required only for those form factors. The formfactor restrictions are specified in the requirements. The Windows 8 form-factor
definitions are as follows:
Tablet
A tablet form factor defines a stand-alone device that combines
the PC, display, and rechargeable power source in a single chassis.
A tablet does not include a permanently attached keyboard and
pointing device but connects to a port replicator, keyboard, and/or
clamshell dock.
Convertible
A convertible form factor defines a stand-alone device that
combines the PC, display, and rechargeable power source with a
mechanically attached keyboard and pointing device in a single
chassis. A convertible optionally configures as a tablet, with the
attached input devices hidden, leaving the display as the only input
mechanism.
Desktop
A desktop system is a uniprocessor or multiprocessor system that
requires AC power for continuous operation. A desktop system
does not include attached peripheral devices such as mice,
monitors, keyboards, or printers.
All-in-one
An all-in-one is a uniprocessor or multiprocessor system that has a
permanently attached integrated display. All-in-ones typically
include integrated components that are based on mobile hardware
designs.
Laptop
A laptop is a uniprocessor or multiprocessor system that can be
physically carried, has integrated display and input devices, and
January 7, 2014
© 2014 Microsoft. All rights reserved.
Windows Certification Program - 35
has a battery that can provide continuous operation when it's not
plugged in.
Windows 8 uses a simple form-factor breakdown of the system. Tablets and
convertibles share requirements enhancing the mobile and touch-oriented scenarios.
The requirements for the other form factors—desktop, laptop, and all-in-one—share
the other common feature-based requirements. If these less mobile and touchoriented form factors expose these additional features, they're expected to meet the
requirements as defined.
The Windows 7 system requirements also break down per form factor. The
Windows 7 form-factor definitions are as follows:
Desktop
A uniprocessor or multiprocessor system that requires AC
power for continuous operation. A desktop system does not
include attached peripheral devices such as mice, monitors,
keyboards, or printers.
All-in-one
A uniprocessor or multiprocessor system that incorporate a
permanently attached integrated display. All-in-ones typically
include integrated components that are based on mobile
hardware designs.
Mobile
A uniprocessor or multiprocessor system that can be physically
carried, has integrated display and input devices, and has a
battery that can provide continuous operation when it's not
plugged in.
Ultra mobile
A mobile system that has a 10.2-inch or smaller screen size.
Using previously certified motherboards in client systems
OEMs may use a previously certified motherboard to certify client systems for
Windows 7 or Windows 8 without running the "Fidelity Test (System, Manual)" and
"Class Driver Fidelity Test (System, Manual" tests in the Windows HCK. Partners who
choose to use a certified motherboard for Windows 7 or Windows 8 must meet all of
the client system requirements for the version of Windows for which they are
certifying for. The version of Windows that the system is being certified for must
match the version of Windows that the motherboard was certified for. For example,
if the system is being certified for Windows 8, then the motherboard must, at a
minimum, be certified for Windows 8. The certified motherboard used for a client
system submission must be listed on the Windows Certified Products List, which
indicates that the motherboard satisfied the Fidelity Test and Class Driver Fidelity
Test when it was certified. The BIOS version must match the one used for the
motherboard submission, subject to the exceptions listed in the system family testing
and updates policy that require a new submission.
When you make your system submission, include a Readme.doc file that references
manual errata ID 738, the product name of the motherboard, and the submission ID.
January 7, 2014
© 2014 Microsoft. All rights reserved.
Windows Certification Program - 36
The product name and submission ID must exactly match the listing in the Windows
Certified Products List.
Specialized PCs
A Specialized PC (SPC) is a system, either Client or Server, that has been designed
specifically for an enterprise vertical market or a niche use case scenario which has an
explicit design need to bypass or remove features required by certification. A
certification review board will review the requests. If the board agrees the
certification failures are necessary to meet the unique user scenarios for which the
system was designed, the specialized PC may still be certified, provided there is
adequate disclosure of the ways the system departs from the certification standards
and it is clear what the end user impacts will be. A specialized PC is expected to meet
all other certification requirements except those explicitly required to meet the use
case and disclosed. The certification process validates that the system passes all
certification requirements with the exception of those reviewed, approved for this
special case, and disclosed.
Examples of SPC would be a ruggedized system with resistive touch screens, a
technology that currently cannot meet the 5 touch minimum. Other examples are
systems sold into highly regulated medical environments needing sealed surfaces and
signal screening, or systems sold into specialty applications such as ATMs and kiosks.
Examples of removals at bid request would be a certified system where the webcam
was removed for security reasons, or networking removed and replaced by a
proprietary secure communication channel.
Specialized PCs require a formal request documenting the specific feature areas
which have been requested for removal or bypass as a part of the certification
process. This program cannot be used as a bypass for failing features in a system
designed for general use. For a system to use the designation of “Specialized PC” and
use the certification logo, the OEM must submit a special review request using a form
available through the [email protected] alias. Should the request be approved
a set of conditions are placed on the certification including:
1. The system is sold only through acceptable enterprise channels. The system
may not be sold through consumer channels.
2. The system is sold only with the Professional SKU, or appropriate Server SKU.
3. The OEM must disclose the results of the certification testing including
conspicuous disclosure of any limitations in a system’s Windows features or
functionality as compared to a system that passes all certification
requirements.
4. As a part of OEM disclosure, an OEM must make applicable disclosures which
have been designated through the Specialized PC approval process in a
prominent and conspicuous manner to customers prior to purchase of the
system. This may include a warning on the system directly, and additional
disclosures in marketing literature, conspicuous placement on the OEM
website, product purchase pages, support pages, and other relevant locations
which are easily discoverable by a user prior to purchase of the system.
January 7, 2014
© 2014 Microsoft. All rights reserved.
Windows Certification Program - 37
5. The OEM will be responsible for the support burden that may come from the
loss of functionality, holding Microsoft harmless.
SPC submissions are always marked for manual review and fail if the failures
in the submission do not match with those specifically defined in the
contingency.
The following hypothetical Specialized PC disclaimer is provided as an example:
This device has been certified for Windows 8 as a Specialized PC (SPC). The
SPC certification program allows for the certification of commercial devices
designed with industry specific features that conflict with the standard
Windows 8 certification requirements. As a result, certain features or
functionality of Windows 8 may not work as expected. For complete details,
including information about features which are not in compliance with the
standard Windows 8 certification requirements go to <link to OEM website>.
For more information, see Specialized PCs on the Windows Hardware Dev
Center.
Testing a docking station designed for the system
A docking station is any peripheral device which is designed to add functionality to a
mobile system when it is at a more permanent location. Typically, docking stations
add additional external ports and even functionality internal to the station, which
may allow keyboard, mice, additional storage, a second monitor, other handy
peripherals and a power connection to all be added to the system in a single
connection.
By their very nature, docking stations add multiple potential points of failure to a
system, since all of these additional devices are added and removed in a single action.
If an OEM creates a docking station for a certified system or system family, whether
the docking station is sold with the system or separately, the system must pass all
relevant testing both in and out of the docking station. During the testing a
representative load of certified attached devices should populate the docking station.
On successful testing of the system with the docking station, the docking station is
certified as a multi-function peripheral.
Should the docking station not be certified, the system itself can lose its certified
status since we cannot assure that the system handles easily expected surprise
removal and sleep removal scenarios. During Windows HCK testing, the system
remains docked and connected to AC power unless otherwise noted by a specific test
in the Windows HCK. A test in the Windows HCK may ask the tester to disconnect the
AC power from the wall or for the end user to undock the system to ensure that the
system is meeting certification requirements in both undocked and docked situations.
System family testing and updates that require a new submission
To make system certification simpler by using the Windows HCK, we define a system
family as follows:

Same major BIOS version.
January 7, 2014
© 2014 Microsoft. All rights reserved.
Windows Certification Program - 38

Same motherboard manufacturer and model. The motherboard in the same
systems within a family must have the same VID and PID.

Same CPU family, which is defined as having the same manufacturer and
being PIN compatible with the socket on the system.
It's acceptable to test systems that have either the same or different range of
memory (RAM), different storage capacity, or different CPU speeds, provided that the
CPUs meet the family definition described previously.
The system form factor must be the same for all systems within a system family.
Swapping devices on a system can have an impact on the stability, reliability, and
performance of the system. Certain changes require you to test the system, including:

Swapping of touch devices.

Sensors.

GPUs that span different families.
For instructions on how to set up a system family for the Windows HCK, see the
Windows HCK documentation.
Testing GPUs across different GPU families
If you're swapping a GPU with one from a different GPU family, you can either run
another system submission or add the system to the family of systems that is being
tested.
A GPU family has the following requirements:

GPUs that are manufactured by two different independent hardware vendors
(IHVs) are in different GPU families.

GPUs that don't support the same major DirectX revisions are in different
GPU families.
For example:

GPU A supports DirectX 10 and GPU B supports DirectX 10.1 = same
GPU family.

GPU A supports DirectX 9 and GPU B supports DirectX 10 = not the
same GPU family.

GPU A supports DirectX 10 and GPU B supports DirectX 11 = not the
same GPU family.
Using Distributed Testing for System Family Testing
The Windows HCK has added the ability to create a system project with more than
one system as a target. In this case the testing is distributed across the available
systems greatly reducing the testing period required. Although originally designed
for use with identical systems, this does allows the test pool to contain
representatives with the acceptable changes described above for family systems. The
graphics tests will run on each system that you put into your product instance as an
alternative method to complete the GPU testing described above. This technique
January 7, 2014
© 2014 Microsoft. All rights reserved.
Windows Certification Program - 39
avoids the need to run separate projects for each of the graphics variations used with
the system. The rest of the systems tests are distributed over the target pool saving
time.
Distributed testing is not appropriate for all tests. The kit itself will limit what tests
can be distributed. If more targets are in the pool, the non-distributable tests will be
run against every identified target.
The following rules must be followed when enabling distributed testing:






The motherboard must be the same for all the systems.
The CPU must be from the same IHV and PIN compatible
All systems use the same UEFI Firmware
The feature set must be the same
It is acceptable to swap GPU’s even if they span multiple device families
It is acceptable to have different swappable components (hard drives,
memory, etc.)
Touch device
If you have a different touch device, the touch tests must run against that system.
You can include the separate system in the family machine pool.
Sensors
If you swap sensors, that system must be retested. Sensor integration is a critical
aspect of system design and can significantly change the end-user experience. If
multiple sensor combinations are anticipated, it's acceptable to add them to a system
family machine pool so that they're tested in the initial system submission.
UEFI requirements for systems and devices
UEFI configuration for system certification
Windows operating systems can be 32-bit or 64-bit, but not both simultaneously.
UEFI can be 32-bit or 64-bit, but not both simultaneously. The architecture version of
UEFI must match the architecture version of the operating system. For example, 32bit UEFI (UEFI32) can only boot a 32-bit operating system; 64-bit UEFI (UEFI64) can
only boot a 64-bit operating system.
Windows 8 and later certification requires that systems implement UEFI native boot
as the firmware boot mode and Secure Boot as the default out-of-box configuration.
A system chassis must meet the following requirements:

If it ships with a 32-bit OS, it must be certified for UEFI32 and Windows x86.

If it ships with a 64-bit OS, it must be certified for UEFI64 and Windows x64.

If it ships with both 32-bit and 64-bit configurations, it must be certified for
both configurations.
January 7, 2014
© 2014 Microsoft. All rights reserved.
Windows Certification Program - 40

If it's capable of both 32-bit and 64-bit support but only ships in one of those
configurations, it must be certified in the configuration it ships in. Compliance
with this requirement is verified by audits.

If it ships to an enterprise with Windows 7 installed, it must be certified for
both Windows 7 with CSM and with Windows 8 x64 with UEFI64 or
Windows 8.1 x64 with UEFI64 . Compliance with this requirement is verified
by audits.
The following table summarizes the acceptable system configurations:
Operating system CPU type
32-bit
ARM capable
Firmware type Boot mode
UEFI32
Native UEFI
32-bit
x86 and/or x64 capable UEFI32
Native UEFI
64-bit
x86 and/or x64 capable UEFI64
Native UEFI
The primary expected configuration for Windows 8 systems is 64-bit with UEFI64
firmware.
UEFI client system required for device testing
Windows 8 or Windows 8.1 device certification requires that a device is tested for
client (not server) on a UEFI mode system. If the device testing takes place on a single
client system, that system must be UEFI-enabled. However, if a distributed testing
environment is set up using more than one test computer in the machine pool, not all
have to be running UEFI.
Test environments must meet the following requirements:

At least one client system used for device testing must have UEFI mode enabled
in a multisystem distributed test setup.

At least one client system used in each device family must have UEFI mode
enabled in a multisystem distributed test project using multiple device families.
UEFI and Server systems
Windows Server 2012 R2 and later supports but does not require UEFI. When
certifying Servers following the following rules regarding UEFI.
1. For systems that support Class 3 UEFI implementations, vendors certify
and submit them as UEFI platforms.
2. For systems that support Class 2 UEFI implementations (UEFI+CSM),
we encourage the vendors to certify and submit as UEFI platforms. For
Windows Server 2012 R2, we no longer require the Class 2 UEFI
systems to certify and submit twice, once for legacy BIOS mode and
the other for UEFI mode.
3. For systems that support legacy BIOS implementations, vendors certify
and submit them as they are.
January 7, 2014
© 2014 Microsoft. All rights reserved.
Windows Certification Program - 41
Testing policies for server system
Up-level and down-level certification policies for Windows Server 2012
and Windows Server 2012 R2
Re-Certification is required for previously certified Windows Server 2012 systems to
obtain the Windows Server 2012 R2 logo.
Systems successfully certified against Windows Server 2012 R2 will earn “DownLevel” hardware certification status for Windows Server 2012.
Run Server tests on physical hardware
Windows Server system testing must take place with the operating system directly
controlling the system hardware resources.
Hypervisor or host-based virtualization solutions can't be submitted for the Windows
system certification. These solutions must be tested and submitted according to the
requirements of the Server Virtualization Validation Program. For more information,
see the Windows Server catalog.
Rules that control server system testing and retesting
A Windows Server–based system is tested at the fastest (preferred) or maximum
configuration of the components of the system, and must be retested whenever a
significant change occurs in one of the fundamental components of the system.
Those fundamental components are the processors, memory, chipset, BIOS or UEFI,
and I/O.
Some changes may be made to a server system without triggering a new submission.
New device driver combinations (such as PCI adapters and hard disk drives) can be
substituted for device driver combinations that were included in the original system
at any time, without a system resubmission.
The following changes are considered significant changes and require the modified
server system to be retested and resubmitted with a new system name and model
number.
Processor

Change in architecture or CPU manufacturer.

Change in number of processor sockets.

Change in processor model.

Change in processor speed. If the only change is clock speed, the retested
system may use the previous submitted name.
Note: Test the configuration of processor cores and sockets that allows the highest
clock speeds of the processor or processors in the system while populating all
sockets.
Memory

Change in maximum supported RAM
January 7, 2014
© 2014 Microsoft. All rights reserved.
Windows Certification Program - 42

Architecture changes to the memory (for example, the maximum supported
clock to access memory or the pin outs to that memory change from DDR2 to
DDR3)
Note: Test memory at the highest memory clock speed that is supported on the
largest memory capacity configuration of the server that supports that maximum
memory clock speed, regardless of the number of memory channels or DIMM slots.
Chipset

Northbridge or Southbridge change

Processor integrated component change

Architecture changes to the chipset (for example, the pin outs to that chipset
change)
BIOS or UEFI

Changes to ACPI, PnP, or power management functionality. Minor BIOS
changes, such as fixes to timing issues or changes to the splash screen (the
screen that appears during system startup) don't require resubmission.
I/O backplane or external chassis

OEMs that want to submit systems that have multiple I/O backplane options
are not required to make submissions for each option. One submission is
required—specifically, the "maximum" configuration possible for the system,
preferably a "hybrid" if available. Other options can be submitted as
marketing names if required. All other relevant requirements must be met.
System board

Any physical changes to the motherboard of the test system, such as new
traces or on-motherboard components that are not devices separately
tested, examples; NIC on motherboard, HBA on motherboard, graphics chip
on motherboard, etc.
Closing comments
We are extremely pleased to share the feature-based requirements, Windows HCK,
and the Hardware and Desktop dashboard on the Windows Dev Center. Together,
these represent a significant investment we've made in the ecosystem, and they can
help you build great products.
For any questions about the content of this document, contact
[email protected].
January 7, 2014
© 2014 Microsoft. All rights reserved.