Systems
Systems
Page 1 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
Disclaimer
This document is provided “as-is”. Information and view expressed in this document, including URL and other
Internet website references, may change without notice.
Some examples depicted herein are provided for illustration only and are fictitious. No real association or connection
is intended or should be inferred.
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. This document is confidential and proprietary
to Microsoft. It is disclosed and can be used only pursuant to a nondisclosure agreement.
Internet Explorer, Microsoft, TechNet, Windows, and Excel are trademarks of the Microsoft group of
companies. All other trademarks are property of their respective owners.
Page 2 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
Microsoft Corporation Technical Documentation License Agreement (Standard)
READ THIS! THIS IS A LEGAL AGREEMENT BETWEEN MICROSOFT CORPORATION ("MICROSOFT") AND THE RECIPIENT OF THESE
MATERIALS, WHETHER AN INDIVIDUAL OR AN ENTITY ("YOU"). IF YOU HAVE ACCESSED THIS AGREEMENT IN THE PROCESS OF
DOWNLOADING MATERIALS ("MATERIALS") FROM A MICROSOFT WEB SITE, BY CLICKING "I ACCEPT", DOWNLOADING, USING OR
PROVIDING FEEDBACK ON THE MATERIALS, YOU AGREE TO THESE TERMS. IF THIS AGREEMENT IS ATTACHED TO MATERIALS, BY
ACCESSING, USING OR PROVIDING FEEDBACK ON THE ATTACHED MATERIALS, YOU AGREE TO THESE TERMS.
1. For good and valuable consideration, the receipt and sufficiency of which are acknowledged, You and Microsoft agree as follows:
(a) If You are an authorized representative of the corporation or other entity designated below ("Company"), and such Company has executed a Microsoft Corporation
Non-Disclosure Agreement that is not limited to a specific subject matter or event ("Microsoft NDA"), You represent that You have authority to act on behalf of
Company and agree that the Confidential Information, as defined in the Microsoft NDA, is subject to the terms and conditions of the Microsoft NDA and that
Company will treat the Confidential Information accordingly;
(b) If You are an individual, and have executed a Microsoft NDA, You agree that the Confidential Information, as defined in the Microsoft NDA, is subject to the terms
and conditions of the Microsoft NDA and that You will treat the Confidential Information accordingly; or
(c)If a Microsoft NDA has not been executed, You (if You are an individual), or Company (if You are an authorized representative of Company), as applicable, agrees:
(a) to refrain from disclosing or distributing the Confidential Information to any third party for five (5) years from the date of disclosure of the Confidential Information
by Microsoft to Company/You; (b) to refrain from reproducing or summarizing the Confidential Information; and (c) to take reasonable security precautions, at least
as great as the precautions it takes to protect its own confidential information, but no less than reasonable care, to keep confidential the Confidential Information.
You/Company, however, may disclose Confidential Information in accordance with a judicial or other governmental order, provided You/Company either (i) gives
Microsoft reasonable notice prior to such disclosure and to allow Microsoft a reasonable opportunity to seek a protective order or equivalent, or (ii) obtains written
assurance from the applicable judicial or governmental entity that it will afford the Confidential Information the highest level of protection afforded under applicable
law or regulation. Confidential Information shall not include any information, however designated, that: (i) is or subsequently becomes publicly available without
Your/Company’s breach of any obligation owed to Microsoft; (ii) became known to You/Company prior to Microsoft’s disclosure of such information to You/Company
pursuant to the terms of this Agreement; (iii) became known to You/Company from a source other than Microsoft other than by the breach of an obligation of
confidentiality owed to Microsoft; or (iv) is independently developed by You/Company. For purposes of this paragraph, "Confidential Information" means nonpublic
information that Microsoft designates as being confidential or which, under the circumstances surrounding disclosure ought to be treated as confidential by Recipient.
"Confidential Information" includes, without limitation, information in tangible or intangible form relating to and/or including released or unreleased Microsoft
software or hardware products, the marketing or promotion of any Microsoft product, Microsoft's business policies or practices, and information received from others
that Microsoft is obligated to treat as confidential.
2. You may review these Materials only (a) as a reference to assist You in planning and designing Your product, service or technology ("Product") to interface with a
Microsoft Product as described in these Materials; and (b) to provide feedback on these Materials to Microsoft. All other rights are retained by Microsoft; this
agreement does not give You rights under any Microsoft patents. You may not (i) duplicate any part of these Materials, (ii) remove this agreement or any notices
from these Materials, or (iii) give any part of these Materials, or assign or otherwise provide Your rights under this agreement, to anyone else.
3. These Materials may contain preliminary information or inaccuracies, and may not correctly represent any associated Microsoft Product as commercially released.
All Materials are provided entirely "AS IS." To the extent permitted by law, MICROSOFT MAKES NO WARRANTY OF ANY KIND, DISCLAIMS ALL EXPRESS, IMPLIED
AND STATUTORY WARRANTIES, AND ASSUMES NO LIABILITY TO YOU FOR ANY DAMAGES OF ANY TYPE IN CONNECTION WITH THESE MATERIALS OR ANY
INTELLECTUAL PROPERTY IN THEM.
4. If You are an entity and (a) merge into another entity or (b) a controlling ownership interest in You changes, Your right to use these Materials automatically
terminates and You must destroy them.
5. You have no obligation to give Microsoft any suggestions, comments or other feedback ("Feedback") relating to these Materials. However, any Feedback you
voluntarily provide may be used in Microsoft Products and related specifications or other documentation (collectively, "Microsoft Offerings") which in turn may be
relied upon by other third parties to develop their own Products. Accordingly, if You do give Microsoft Feedback on any version of these Materials or the Microsoft
Offerings to which they apply, You agree: (a) Microsoft may freely use, reproduce, license, distribute, and otherwise commercialize Your Feedback in any Microsoft
Offering; (b) You also grant third parties, without charge, only those patent rights necessary to enable other Products to use or interface with any specific parts of a
Microsoft Product that incorporate Your Feedback; and (c) You will not give Microsoft any Feedback (i) that You have reason to believe is subject to any patent,
copyright or other intellectual property claim or right of any third party; or (ii) subject to license terms which seek to require any Microsoft Offering incorporating or
derived from such Feedback, or other Microsoft intellectual property, to be licensed to or otherwise shared with any third party.
6. Microsoft has no obligation to maintain confidentiality of any Microsoft Offering, but otherwise the confidentiality of Your Feedback, including Your identity as the
source of such Feedback, is governed by Your NDA.
7. This agreement is governed by the laws of the State of Washington. Any dispute involving it must be brought in the federal or state superior courts located in King
County, Washington, and You waive any defenses allowing the dispute to be litigated elsewhere. If there is litigation, the losing party must pay the other party’s
reasonable attorneys’ fees, costs and other expenses. If any part of this agreement is unenforceable, it will be considered modified to the extent necessary to make
it enforceable, and the remainder shall continue in effect. This agreement is the entire agreement between You and Microsoft concerning these Materials; it may be
changed only by a written document signed by both You and Microsoft.
Page 3 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
Table of Contents
Disclaimer........................................................................................................................................................................................................................... 2
Overview of Windows Hardware Compatibility Program ........................................................................................................................... 15
Glossary ............................................................................................................................................................................................................................ 16
System Requirements ................................................................................................................................................................................................ 17
System.Client.BluetoothController.Base ........................................................................................................................................................ 17
System.Client.BluetoothController.Base.4LeSpecification ................................................................................................................. 17
System.Client.BluetoothController.Base.Audio.CoreRequirement ................................................................................................. 17
System.Client.BluetoothController.Base.CS ............................................................................................................................................. 18
System.Client.BluetoothController.Base.LEWhiteList ........................................................................................................................... 18
System.Client.BluetoothController.Base.NoBluetoothLEFilterDriver ............................................................................................. 18
System.Client.BluetoothController.Base.OnOffStateControllableViaSoftware.......................................................................... 19
System.Client.BluetoothController.Base.SimultaneousBrEdrAndLeTraffic .................................................................................. 19
System.Client.BluetoothController.Base.WidebandSpeech .............................................................................................................. 20
System.Client.BluetoothController.Base.WLANBTCoexistence........................................................................................................ 20
System.Client.BluetoothController.Base.Audio ........................................................................................................................................... 20
System.Client.BluetoothController.Base.Audio.CoreRequirement ................................................................................................. 20
System.Client.BluetoothController.CoreSpecification4Dot1.LELinkLayerTopology..................................................................... 21
System.Client.BluetoothController.CoreSpecification4Dot1.LELinkLayerTopology.CoreRequirement .......................... 21
System.Client.BluetoothController.CoreSpecification5.LEExtendedAdvertising ........................................................................... 21
System.Client.BluetoothController.CoreSpecification5.LEExtendedAdvertising.CoreRequirement ................................. 21
System.Client.BluetoothController.CoreSpecification5Dot2.LEPowerControl ............................................................................... 22
System.Client.BluetoothController.CoreSpecification5Dot2.LEPowerControl.CoreRequirement ..................................... 22
System.Client.BluetoothController.CoreSpecification5Dot3.LEEnhancedConnectionUpdate................................................. 22
System.Client.BluetoothController.CoreSpecification5Dot3.LEEnhancedConnectionUpdate.CoreRequirement ...... 22
System.Client.BluetoothController.CoreSpecification5Dot3.LEChannelClassification ................................................................ 23
System.Client.BluetoothController.CoreSpecification5Dot3.LEChannelClassification.CoreRequirement ...................... 23
System.Client.BluetoothController.ErrorRecovery ..................................................................................................................................... 23
System.Client.BluetoothController.ErrorRecovery.CoreRequirement ........................................................................................... 23
System.Client.BluetoothController.HciExtensions1 ................................................................................................................................... 24
System.Client.BluetoothController.HciExtensions1.CoreRequirement ......................................................................................... 24
System.Client.BluetoothController.HciExtensions.EnhancedControllerDiagnostics .................................................................... 25
System.Client.BluetoothController.HciExtensions.EnhancedControllerDiagnostics.CoreRequirement .......................... 25
Page 4 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
System.Client.BluetoothController.HciExtensions.A2dpOffload .......................................................................................................... 25
System.Client.BluetoothController.HciExtensions.A2dpOffload.Initialization ........................................................................... 25
System.Client.BluetoothController.HciExtensions.A2dpOffload.Streaming ............................................................................... 26
System.Client.BluetoothController.HciExtensions.A2dpOffload.ReportedCodecCapabilities ............................................ 26
System.Client.BluetoothController.HciExtensions.A2dpOffload.SimultaneousSco ................................................................. 26
System.Client.BluetoothController.HciExtensions.MonitorAdvertisementV2 ................................................................................ 27
System.Client.BluetoothController.HciExtensions.MonitorAdvertisementV2.CoreRequirement ...................................... 27
System.Client.BluetoothController.LEAudioUnicast .................................................................................................................................. 27
System.Client.BluetoothController.LEAudioUnicast.HciExtensionsMonitorAdvertisementV2 ........................................... 28
System.Client.BluetoothController.LEAudioUnicast.BRSecureConnections ............................................................................... 28
System.Client.BluetoothController.LEAudioUnicast.ConnectedIsochronousStreams ............................................................ 28
System.Client.BluetoothController.LEAudioUnicast.LEPowerControl ........................................................................................... 28
System.Client.BluetoothController.LEAudioUnicast.LEEnhancedConnectionUpdate ............................................................ 29
System.Client.BluetoothController.LEAudioUnicast.LEChannelClassification ............................................................................ 29
System.Client.BluetoothController.LEAudioUnicast.CoreSpecification5Dot3 ........................................................................... 29
System.Client.BluetoothController.LEAudioUnicast.Transport ........................................................................................................ 29
System.Client.BluetoothController.MicrosoftStack ................................................................................................................................... 30
System.Client.BluetoothController.MicrosoftStack.BluetoothDeviceClass ................................................................................. 30
System.Client.BluetoothController.NonUSB ................................................................................................................................................ 30
System.Client.BluetoothController.NonUSB.NonUsbUsesMicrosoftsStack................................................................................ 30
System.Client.BluetoothController.NonUSB.ScoSupport ................................................................................................................... 30
System.Client.BluetoothController.CoreSpecification5Dot2.AutoConnectionEstablishmentProcedure ............................ 31
System.Client.BluetoothController.CoreSpecification5Dot2.AutoConnectionEstablishmentProcedure.CoreRequire
ment ......................................................................................................................................................................................................................... 31
System.Client.BluetoothController.USB ......................................................................................................................................................... 31
System.Client.BluetoothController.USB.ScoDataTransportLayer .................................................................................................... 31
System.Client.BluetoothController.UsbTransport.Transport ....................................................................................................... 31
System.Client.BluetoothController.UsbTransport.Transport.UsbDescriptors ............................................................................ 31
System.Client.BluetoothController.UsbTransport.AlternateSetting6 ..................................................................................... 32
System.Client.BluetoothController.UsbTransport.AlternateSettings6.CoreRequirement ..................................................... 32
System.Client.BrightnessControls ..................................................................................................................................................................... 32
System.Client.BrightnessControls.BacklightOptimization ................................................................................................................. 32
System.Client.BrightnessControls.BrightnessControlButtons .......................................................................................................... 33
System.Client.BrightnessControls.SmoothBrightness ......................................................................................................................... 34
System.Client.Buttons ............................................................................................................................................................................................ 35
Page 5 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
System.Client.Buttons.HardwareButtons .................................................................................................................................................. 35
System.Client.Camera ............................................................................................................................................................................................ 36
System.Client.Camera.Base.CameraControls .......................................................................................................................................... 36
System.Client.Camera.Base.Device .............................................................................................................................................................. 38
System.Client.Camera.Base.PhysicalLocation .......................................................................................................................................... 38
System.Client.Camera.SensorCapture.SensorCapture ........................................................................................................................ 39
System.Client.Camera.VideoCapture.VideoCapture ............................................................................................................................ 39
System.Client.Digitizer .......................................................................................................................................................................................... 40
System.Client.Digitizer.Base.SystemDigitizersBase ............................................................................................................................... 40
System.Client.Digitizer.SystemPen .............................................................................................................................................................. 40
System.Client.Digitizer.SystemTouch ......................................................................................................................................................... 41
System.Client.Digitizer.SystemPrecisionTouchpad ............................................................................................................................... 42
System.Client.Digitizer.Pen .................................................................................................................................................................................. 43
System.Client.Digitizer.Pen.Accuracy ......................................................................................................................................................... 43
System.Client.Digitizer.Pen.BarrelButton .................................................................................................................................................. 43
System.Client.Digitizer.Pen.Buffering ......................................................................................................................................................... 43
System.Client.Digitizer.Pen.CustomGestures .......................................................................................................................................... 44
System.Client.Digitizer.Pen.Eraser ............................................................................................................................................................... 44
System.Client.Digitizer.Pen.HIDCompliant ............................................................................................................................................... 44
System.Client.Digitizer.Pen.HighResolutionTimeStamp ..................................................................................................................... 44
System.Client.Digitizer.Pen.HoverRange .................................................................................................................................................. 45
System.Client.Digitizer.Pen.Jitter .................................................................................................................................................................. 45
System.Client.Digitizer.Pen.NoiseSuppression ....................................................................................................................................... 45
System.Client.Digitizer.Pen.Pressure........................................................................................................................................................... 45
System.Client.Digitizer.Pen.ReportRate ..................................................................................................................................................... 46
System.Client.Digitizer.Pen.Resolution ...................................................................................................................................................... 46
System.Client.Digitizer.Pen.ResponseLatency ........................................................................................................................................ 46
System.Client.Digitizer.Pen.ThirdPartyDrivers ........................................................................................................................................ 46
System.Client.Digitizer.PrecisionTouchpad .................................................................................................................................................. 47
System.Client.Digitizer.PrecisionTouchpad.Accuracy .......................................................................................................................... 47
System.Client.Digitizer.PrecisionTouchpad.Buffering .......................................................................................................................... 47
System.Client.Digitizer.PrecisionTouchpad.Buttons ............................................................................................................................. 47
System.Client.Digitizer.PrecisionTouchpad.ContactTipSwitchHeight ........................................................................................... 47
System.Client.Digitizer.PrecisionTouchpad.DeviceTypeReporting ................................................................................................ 47
System.Client.Digitizer.PrecisionTouchpad.Dimensions .................................................................................................................... 48
Page 6 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
System.Client.Digitizer.PrecisionTouchpad.FingerSeparation ......................................................................................................... 48
System.Client.Digitizer.PrecisionTouchpad.HIDCompliant ............................................................................................................... 48
System.Client.Digitizer.PrecisionTouchpad.HighResolutionTimeStamp ..................................................................................... 48
System.Client.Digitizer.PrecisionTouchpad.InputResolution ............................................................................................................ 49
System.Client.Digitizer.PrecisionTouchpad.Jitter .................................................................................................................................. 49
System.Client.Digitizer.PrecisionTouchpad.MinMaxContacts .......................................................................................................... 49
System.Client.Digitizer.PrecisionTouchpad.NoiseSuppression ....................................................................................................... 49
System.Client.Digitizer.PrecisionTouchpad.ReportRate ..................................................................................................................... 50
System.Client.Digitizer.PrecisionTouchpad.ResponseLatency ......................................................................................................... 50
System.Client.Digitizer.PrecisionTouchpad.SelectiveReporting ...................................................................................................... 50
System.Client.Digitizer.PrecisionTouchpad.ThirdPartyDrivers ......................................................................................................... 50
System.Client.Digitizer.PrecisionTouchpad.Reporting ........................................................................................................................ 51
System.Client.Digitizer.Touch ............................................................................................................................................................................. 51
System.Client.Digitizer.Touch.Accuracy..................................................................................................................................................... 51
System.Client.Digitizer.Touch.Buffering .................................................................................................................................................... 51
System.Client.Digitizer.Touch.CustomGestures ..................................................................................................................................... 52
System.Client.Digitizer.Touch.FingerSeparation .................................................................................................................................... 52
System.Client.Digitizer.Touch.HIDCompliant .......................................................................................................................................... 52
System.Client.Digitizer.Touch.HighResolutionTimeStamp ................................................................................................................ 52
System.Client.Digitizer.Touch.Jitter ............................................................................................................................................................. 53
System.Client.Digitizer.Touch.MinContactCount .................................................................................................................................. 53
System.Client.Digitizer.Touch.NoiseSuppression .................................................................................................................................. 53
System.Client.Digitizer.Touch.ReportRate ................................................................................................................................................ 54
System.Client.Digitizer.Touch.Resolution ................................................................................................................................................. 54
System.Client.Digitizer.Touch.ThirdPartyDrivers ................................................................................................................................... 54
System.Client.Digitizer.Touch.ResponseLatency ................................................................................................................................... 54
System.Client.Firmware.UEFI.GOP .................................................................................................................................................................... 55
System.Client.Firmware.UEFI.GOP.Display ............................................................................................................................................... 55
System.Client.Graphics .......................................................................................................................................................................................... 56
System.Client.Graphics.FullGPU .................................................................................................................................................................... 56
System.Client.Graphics.NoMoreThanOneInternalMonitor ............................................................................................................... 57
System.Client.Graphics.Brightness3Calibration ..................................................................................................................................... 57
System.Client.Graphics.WDDM ..................................................................................................................................................................... 57
System.Client.Graphics.WDDMSupportRotatedModes ...................................................................................................................... 58
System.Client.Graphics.WirelessUSBDisplay ........................................................................................................................................... 58
Page 7 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
System.Client.Graphics.InternalDisplay.HDR................................................................................................................................................ 59
System.Client.Graphics.InternalDisplay.HDR.CoreRequirement ..................................................................................................... 59
System.Client.Graphics.ExternalDisplay.HDR ............................................................................................................................................... 60
System.Client.Graphics.ExternalDisplay.HDR.CoreRequirement ..................................................................................................... 60
System.Client.MobileBroadband ...................................................................................................................................................................... 60
System.Client.MobileBroadband.ComplyWithBaseReq...................................................................................................................... 60
System.Client.MobileBroadband.EAPSIM ................................................................................................................................................. 72
System.Client.MobileBroadband.FWComplyWithMBSpec ................................................................................................................ 73
System.Client.MobileBroadband.Loopback ............................................................................................................................................. 75
System.Client.MobileBroadband.SupportUSBSelectiveSuspend .................................................................................................... 76
System.Client.MobileBroadband.SupportWakeOnMB ....................................................................................................................... 77
System.Client.MobileBroadband.NITZ ........................................................................................................................................................... 79
System.Client.MobileBroadband.NITZ.Discretional ............................................................................................................................. 79
System.Client.MobileBroadband.PLDR .......................................................................................................................................................... 79
System.Client.MobileBroadband.PLDR.Discretional ............................................................................................................................ 80
System.Client.MobileBroadband.ModemLogging .................................................................................................................................... 80
System.Client.MobileBroadband.ModemLogging.Discretional ...................................................................................................... 80
System.Client.MobileBroadband.LteAttach .................................................................................................................................................. 81
System.Client.MobileBroadband.LteAttach.Discretional .................................................................................................................... 81
System.ClientMobileBroadband.PCO ............................................................................................................................................................. 83
System.Client.MobileBroadband.PCO.Discretional .............................................................................................................................. 83
System.Client.MobileBroadband.FirmwareUpdater .................................................................................................................................. 84
System.Client.MobileBroadband.FirmwareUpdater.FirmwareUpgrade ....................................................................................... 84
System.Client.MobileBroadband.MultiModemMultiExecutor .............................................................................................................. 85
System.Client.MobileBroadband.DSSA.Discretional ............................................................................................................................ 85
System.Client.PCContainer .................................................................................................................................................................................. 86
System.Client.PCContainer.PCAppearsAsSingleObject ...................................................................................................................... 86
System.Client.RadioManagement .................................................................................................................................................................... 87
System.Client.RadioManagement.HardwareButton ............................................................................................................................. 87
System.Client.RadioManagement.RadioMaintainsState .................................................................................................................... 88
System.Client.RadioManagement.RadioManagementAPIHID ........................................................................................................ 88
System.Client.RadioManagement.ConnectedStandby ............................................................................................................................ 91
System.Client.RadioManagement.ConnectedStandby.NoRadioStatusIndicatorLights ......................................................... 91
System.Client.Sensor .............................................................................................................................................................................................. 91
System.Client.Sensor.HumanPresence.SystemLevel ............................................................................................................................ 91
Page 8 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
System.Client.Sensor.HumanPresence.PhysicalDeviceLocation ...................................................................................................... 91
System.Client.Sensor.Accelerometer ............................................................................................................................................................... 91
System.Client.Sensor.Accelerometer.Shake ............................................................................................................................................. 91
System.Client.Sensor.Accelerometer.EnumerationProperties .......................................................................................................... 92
System.Client.Sensor.ActivitySensor................................................................................................................................................................ 92
System.Client.Sensor.ActivitySensor.EnumerationProperties .......................................................................................................... 92
System.Client.Sensor.AmbientLightSensor ................................................................................................................................................... 93
System.Client.Sensor.AmbientLightSensor.AutoBrightnessPreferred .......................................................................................... 93
System.Client.Sensor.AmbientLightSensor.ColorCalibration ........................................................................................................... 93
System.Client.Sensor.AmbientLightSensor.EnumerationProperties .............................................................................................. 93
System.Client.Sensor.AmbientLightSensor.IsValid ............................................................................................................................... 94
System.Client.Sensor.AmbientLightSensor.LightCalibration ............................................................................................................ 94
System.Client.Sensor.AmbientLightSensor.LightRange ...................................................................................................................... 94
System.Client.Sensor.CustomSensor ............................................................................................................................................................... 95
System.Client.Sensor.CustomSensor.EnumerationProperties .......................................................................................................... 95
System.Client.Sensor.General.EnumerationProperties ........................................................................................................................ 95
System.Client.Sensor.General.OptionalEnumerationProperties ...................................................................................................... 96
System.Client.Sensor.General.OptionalProperties ................................................................................................................................ 96
System.Client.Sensor.General.Properties .................................................................................................................................................. 97
System.Client.Sensor.General.Wake ........................................................................................................................................................... 98
System.Client.Sensor.Gyrometer ....................................................................................................................................................................... 98
System.Client.Sensor.Gyrometer.DynamicRange .................................................................................................................................. 98
System.Client.Sensor.General ............................................................................................................................................................................. 98
System.Client.Sensor.General.ConnectionType ..................................................................................................................................... 98
System.Client.Sensor.General.MaximumMeasuringLatency ............................................................................................................. 99
System.Client.Sensor.General.OEMSettings ............................................................................................................................................ 99
System.Client.Sensor.General.PhysicalDeviceLocation ..................................................................................................................... 100
System.Fundamentals.Firmware.Boot.SystemWithBootDeviceGreaterThan............................................................................ 128
System.Fundamentals.Firmware.CS ............................................................................................................................................................... 129
System.Fundamentals.Firmware.CS.CryptoCapabilities .................................................................................................................... 129
System.Fundamentals.Graphics.DisplayRender.StableAndFunctional........................................................................................ 135
System.Fundamentals.Graphics.HybridGraphics ...................................................................................................................................... 135
System.Fundamentals.Graphics.HybridGraphics.MultiGPU ............................................................................................................ 135
System.Fundamentals.HAL.IfCSRTPresent.............................................................................................................................................. 139
System.Fundamentals.HAL.HPETRequired ............................................................................................................................................. 140
System.Fundamentals.Input.............................................................................................................................................................................. 141
System.Fundamentals.PXE.PXEBoot.......................................................................................................................................................... 150
System.Fundamentals.Reliability..................................................................................................................................................................... 151
System.Fundamentals.Reliability.SystemReliability ............................................................................................................................ 151
Page 13 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
System.Fundamentals.SystemPCIController.PCIRequirements ..................................................................................................... 178
System.Fundamentals.SystemUSB ................................................................................................................................................................. 179
System.Fundamentals.SystemUSB.TestedUsingMicrosoftUsbStack............................................................................................ 182
System.Fundamentals.SystemUSB.USBDevicesandHostControllersWorkAfterPowerCycle .............................................. 182
System.Fundamentals.SystemUSB.USB4 ..................................................................................................................................................... 183
The Windows Hardware Compatibility Program (WHCP) is the primary channel that we use to communicate to the
partner community the core expectations that Windows places on devices, kernel-affecting software, systems and
solutions. The purpose of the document is to help ensure that 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 product-specific features.
These design features are codified as discrete requirements which define what Windows expects from the various
components and connected devices. A product 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 Microsoft freely provides in
order to assist partners build, test, secure, and maintain products for success in the Windows environment. No other
program provides access to in-the-field telemetry in order to facilitate end-user support and quality assurance, nor as
powerful a method to deliver software, drivers and certain firmware updates to end-users necessary to correct
identified problems or allow new features to be embraced.
Partners can self-assess how their products comply with WHCP requirements by using the tests in the Windows
Hardware Lab Kit (Windows HLK) for Windows 10. The Windows HLK 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 able to be tested in an automated fashion, and automated testing can't
fully assure absolute compliance with the requirements, so we continually analyze the end-user experience and
improve the tools over time.
All products will expose a suite of features that can be categorized into four basic groupings, and they must meet all
applicable requirements in order to be qualified for Windows Compatibility status. The four groups are:
Page 15 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
• Device.Devfund - fundamental requirements expected of any device, filter or system (the fundamental
features).
• Device.Connectivity - The connectivity requirements exposed for the type of connectivity the device uses.
Devices that use more than one type of connectivity bus must meet all of the applicable connectivity buses
requirements.
• Device/Filter/System specific requirements - The Device/System specific requirements assure that the
device/system behaves as Windows expects.
• Additional requirements that are related to secondary functions added to the product. For example,
removable storage is commonly found on mobile broadband USB-connected units. Both storage and the
mobile broadband portion of the requirements must be met in order to be considered as Compatible.
Compatibility is a public statement of confidence from us that the tested device, filter driver, or system works well
with Windows. Compatibility benefits include:
Glossary
If-Implemented: An If-Implemented requirement is a mandatory requirement for an optional feature or
function. The product is not required to implement the feature or function defined by the requirement, however if
the feature or function is implemented, it must comply with the requirement.
For example: Systems are not required to support USB Type C in the current requirements. If a system does
support USB Type C functionality, then the system is required to comply with all of the defined USB Type C
requirements.
Optional: An optional requirement is a recommendation that Microsoft strongly encourages be implemented when a
product supports the described features or functions. This optional requirement is not enforced during the Windows
Hardware Compatibility Program qualification. Therefore, it is possible to become Windows Hardware Compatibility
Program qualified and not comply with the given optional requirement.
For example: Microsoft recommends that HDD and SDD storage devices support Self-Monitoring, Analysis
and Reporting Technology (SMART) metrics per the ATA8-ACS4 specification in order to reduce the chance
of unexpected device failure or data loss. A storage device is not required to comply with this optional
requirement, even when the device supports SMART.
Page 16 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
System Requirements
System.Client.BluetoothController.Base
These requirements apply to systems that have generic Bluetooth controllers
System.Client.BluetoothController.Base.4LeSpecification
If a system includes a Bluetooth enabled controller it must support the Bluetooth 4.0 specification requirements.
Description
The Bluetooth enabled controller must comply with the Basic Rate (BR) and Low Energy (LE) Combined Core
Configuration Controller Parts and Host/Controller Interface (HCI) Core Configuration requirements outlined in the
Compliance Bluetooth Version 4.0 specifications.
System.Client.BluetoothController.Base.Audio.CoreRequirement
Applies to Windows 11 Client x64
Terms: If-Implemented
Description
This requirement will be enforced as “If Implemented” from Feb 2022 onwards.
Page 17 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
Bluetooth audio A2dp and HFP should play. Additionally, they should be able to be turned off and back on multiple
times.
System.Client.BluetoothController.Base.CS
Systems that support Modern Standby with Bluetooth enabled controllers must ship with Microsoft's inbox Bluetooth
stack and support the MSFT Defined HCI extensions support for hardware offload of advertisement and RSSI monitoring
(see System.Client.BluetoothController.Base.HciExtensions).
Description
Systems that support Modern Standby that ship with Bluetooth enabled controllers must ship with Microsoft's inbox
Bluetooth stack.
System.Client.BluetoothController.Base.LEWhiteList
Systems with Bluetooth enabled controllers must support a minimum LE allow list size of 25 entries.
Description
The Bluetooth enabled controller on the system must support a minimum of 25 entries in its allow list for remote Low
Energy (LE) devices.
System.Client.BluetoothController.Base.NoBluetoothLEFilterDriver
Bluetooth LE filter drivers are not allowed to load on BTHLEENUM.SYS.
Description
Page 18 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
To ensure a uniform experience across Windows Store Apps using the Bluetooth LE (GATT) WinRT API, filter drivers
shall not be loaded on BTHLEENUM.SYS.
System.Client.BluetoothController.Base.OnOffStateControllableViaSoftware
Bluetooth enabled controllers’ On/Off state must be controllable via software.
Description
When turning the radio “off”, Bluetooth enabled controllers shall be powered down to its lowest supported power
state and no transmission/reception shall take place. Windows will terminate Bluetooth activity by unloading the
inbox protocol drivers and their children, submitting the HCI_Reset command to the controller, and then setting the
controller to the D3 logical power state, allowing bus drivers to power down the radio as appropriate. The radio can
be completely powered off if a bus-supported method is available to turn the radio back on. No additional vendor
software control components will be supported.
On turning the radio back on, the Bluetooth stack for Windows shall resume the device to D0, allowing bus drivers to
restart the device. The Windows Bluetooth stack shall then reinitialize the Bluetooth enabled components of the
controller.
Bluetooth Radio Management shall only be enabled for internal Bluetooth 4.0 enabled controllers.
Bluetooth enabled controllers’ On/Off state shall be controllable via software as described in Bluetooth Software
Radio Switch. The Off state is defined, at a minimum, as disabling the antenna component of the Bluetooth enabled
module so there can be no transmission/reception. There must not be any hardware-only switches to control power
to the Bluetooth enabled radio.
The radio must maintain on/off state across sleep and reboot.
System.Client.BluetoothController.Base.SimultaneousBrEdrAndLeTraffic
Bluetooth enabled controllers must support simultaneous BR/EDR and LE traffic.
Description
Page 19 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
Bluetooth enabled controllers must allow the simultaneous use of both Basic Rate (BR)/Enhanced Data Rate (EDR) and
Low Energy (LE) radios.
System.Client.BluetoothController.Base.WidebandSpeech
Applies to Windows 11 Client ARM64
Description:
Wideband speech enables high definition voice quality (audio is sampled at 16 KHz as opposed to only 8 KHz) for
telephony audio on Windows devices when the user is communicating via a Bluetooth peripheral that also supports
wideband speech.
What this means is that Bluetooth radios must support wideband speech in the hardware as defined by the Bluetooth
SIG Hands-Free Profile (HFP) 1.6 specification and the Core Specification Addendum (CSA) 2 which is included in the
Core Version 4.1 Bluetooth specification. At a minimum it must use at least one Bluetooth SIG defined wideband
speech codec (currently mSBC).
Business Justification:
We want users to experience the best possible quality audio when using Bluetooth peripherals on Windows.
Wideband speech is becoming a standard for peripherals that support the HFP profile. Our competition already
supports it
System.Client.BluetoothController.Base.WLANBTCoexistence
Windows Systems that support both WLAN and Bluetooth must meet WLAN-BT Co-existence requirements.
Description
Windows systems that support both WLAN and Bluetooth must meet WLAN-BT Co-existence requirements listed
below. The requirement is applicable to all WLAN devices across all bus types.
• Must not drop the connection with WLAN AP when Bluetooth is scanning for new devices.
• Must be able to scan simultaneously for both WLAN and Bluetooth networks.
System.Client.BluetoothController.Base.Audio
This section contains requirements for Bluetooth audio.
System.Client.BluetoothController.Base.Audio.CoreRequirement
Applies to Windows 11 Client x64
Page 20 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
Windows 11 Client ARM64
Terms: If-Implemented
Description
Bluetooth audio A2dp and HFP should play. Additionally, they should be able to be turned off and back on multiple
times.
System.Client.BluetoothController.CoreSpecification4Dot1.LELinkLayerTopol
ogy
These requirements apply to systems with Bluetooth controllers implementing LE Link Layer Topology as defined in the
Bluetooth 4.1 specification.
System.Client.BluetoothController.CoreSpecification4Dot1.LELinkLayerTopology.CoreReq
uirement
Systems with Bluetooth enabled controllers must support a minimum set of LE state combinations.
Description
The Bluetooth controller must allow the spec-defined LE state combinations (as allowed in section [Vol 6] Part B,
Section 1.1.1 of the Bluetooth Core version 5.0 specification): Only the following states are not required to be
supported:
• Any combination of states that include the Low Duty Cycle Directed Advertising state.
• Any combination of states that include the High Duty Cycle Directed Advertising state
System.Client.BluetoothController.CoreSpecification5.LEExtendedAdvertisin
g
These requirements apply to systems with Bluetooth controllers implementing the LE Extended Advertising feature.as
defined in the Bluetooth 5.0 specification.
System.Client.BluetoothController.CoreSpecification5.LEExtendedAdvertising.CoreRequir
ement
Bluetooth controllers must support the LE Extended Advertising feature as defined in the Bluetooth 5.0 specification.
Page 21 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
Terms : If-Implemented
Description
Windows will not use the LE Extended Advertising feature unless support is declared and this requirement is satisfied.
To declare support, include the following in the DDInstall.HW section of the INF file for the Bluetooth controller:
Include = bth.inf
Needs = BthLEExtendedAdvertisingOptIn.HW
The controller must also implement support to enable the Link Layer Features as defined in the Bluetooth 5.0
specification:
12 LE Extended Advertising
System.Client.BluetoothController.CoreSpecification5Dot2.LEPowerControl
This section contains requirements for LE Power Control feature as defined in the Bluetooth Core Specification 5.2 and
any erratas thereafter.
System.Client.BluetoothController.CoreSpecification5Dot2.LEPowerControl.CoreRequire
ment
Applies to Windows 11 Client x64
Windows 11 Client ARM64
Description
Implement LE Power Control feature that was added in the Bluetooth Core Specification version 5.2 and any erratas
since then.
This requirement refers to bit 33 and 34 of the Link Layer supported features as defined in BLUETOOTH
SPECIFICATION Version 5.2 | Vol 6, Part B, section 4.6 FEATURE SUPPORT.
System.Client.BluetoothController.CoreSpecification5Dot3.LEEnhancedConn
ectionUpdate
This section contains requirements for LE Enhanced Connection Update feature as defined in the Bluetooth Core
Specification 5.3 and any erratas thereafter.
System.Client.BluetoothController.CoreSpecification5Dot3.LEEnhancedConnectionUpdat
e.CoreRequirement
Applies to Windows 11 Client x64
Windows 11 Client ARM64
Description
Page 22 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
Implement LE Enhanced Connection Update feature that was added in the Bluetooth Core Specification version 5.3
and any erratas since then.
This requirement refers to bit 37 and 38 of the Link Layer supported features as defined in BLUETOOTH
SPECIFICATION Version 5.3 | Vol 6, Part B, section 4.6 FEATURE SUPPORT.
System.Client.BluetoothController.CoreSpecification5Dot3.LEChannelClassifi
cation
This section contains requirements for LE Channel Classification feature as defined in the Bluetooth Core Specification
5.3 and any erratas thereafter.
System.Client.BluetoothController.CoreSpecification5Dot3.LEChannelClassification.CoreR
equirement
Applies to Windows 11 Client x64
Windows 11 Client ARM64
Description
Implement LE Channel Classification feature that was added in the Bluetooth Core Specification version 5.3 and any
erratas since then.
This requirement refers to bit 39 of the Link Layer supported features as defined in BLUETOOTH SPECIFICATION
Version 5.3 | Vol 6, Part B, section 4.6 FEATURE SUPPORT.
System.Client.BluetoothController.ErrorRecovery
These requirements apply to systems with internal Bluetooth controllers that implement one or more platform-defined
error recovery mechanisms.
System.Client.BluetoothController.ErrorRecovery.CoreRequirement
Internal Bluetooth controllers and the platforms they are present on must support one or more platform-defined
error recovery mechanisms to be able to recover from certain error conditions.
Terms: If-Implemented
This requirement will become mandatory in the next Windows major release(2023).
Description
Platforms that support internal Bluetooth controllers must support one or more platform-defined error recovery
mechanisms as documented in MSDN. Specifically. support for Platform-Level Device Reset (PLDR) and/or Function-
Level Device Reset (FLDR) is required. Supporting these mechanisms allows the Bluetooth stack to recover the stack
from certain otherwise irrecoverable error conditions by attempting to reset the Bluetooth controller in order to
return to a clean working state.
Page 23 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
System.Client.BluetoothController.HciExtensions1
These requirements apply to systems with Bluetooth controllers implementing the Microsoft Bluetooth HCI Extensions
version 1.
System.Client.BluetoothController.HciExtensions1.CoreRequirement
MSFT Defined HCI extensions support for hardware offload of advertisement and RSSI
monitoring
Applies to Windows 11 Client x64
Description
Radios must comply with the Microsoft defined Bluetooth HCI extensions specification. The details of the
specifications are located on MSDN: https://aka.ms/bthciextensions
0x00000000 00000001 Controller supports the RSSI Monitoring feature for BR/EDR connections. In
addition, the controller supports HCI_VS_MSFT_Read_Absolute_RSSI to read the
absolute RSSI metric of a BR/EDR connection.
0x00000000 00000002 Controller supports the RSSI Monitoring feature for LE connections.
The following feature is required if the HCI commands added in Erratum 10734 are not supported:
Page 24 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
0x00000000 00000010 Controller supports verifying the validity of the public X and Y coordinates on the
curve during the Secure Simple pairing process for P-192 and P-256.
For more information, see Bluetooth Core Specification Erratum 10734.
System.Client.BluetoothController.HciExtensions.EnhancedControllerDiagno
stics
These requirements apply to Bluetooth controllers implementing Enhanced Controller Diagnostics
portion of Microsoft defined Hci Extensions.
System.Client.BluetoothController.HciExtensions.EnhancedControllerDiagnostics.CoreRe
quirement
Applies to Windows 11 Client x64
Terms : If-Implemented
Description
This requirement enforces sequence of vendor specific HCI commands/events needed to enable the Bluetooth
controller to provide diagnostic information to Windows.
System.Client.BluetoothController.HciExtensions.A2dpOffload
This section contains requirements for Bluetooth A2DP offloading.
System.Client.BluetoothController.HciExtensions.A2dpOffload.Initialization
AVDTP offload commands should be supported if the radio supports A2DP offload.
Page 25 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
Terms: If-Implemented
Description
The IHV driver, Controller, and Windows stack should work together to bring up and tear down an A2DP offloaded
stream. As subparts, if HCI_VS_MSFT_Read_Supported_Features has the offload command bit set, then
HCI_VS_MSFT_Avdtp* HCI commands should exist and if the IHV audio driver and the controller both support A2DP
offloading then the host should express support.
The tests for this requirement may need special hardware to execute. Please see https://aka.ms/bthlksetup for more
information.
System.Client.BluetoothController.HciExtensions.A2dpOffload.Streaming
AVDTP offload commands should be supported if the radio supports A2DP offload.
Terms: If-Implemented
Description
This requirement will be enforced as “If Implemented” from Feb 2022 onwards.
The A2DP audio stream should be able to stream audio data with few to no glitches.
The tests for this requirement may need special hardware to execute. Please see https://aka.ms/bthlksetup for more
information.
System.Client.BluetoothController.HciExtensions.A2dpOffload.ReportedCodecCapabilitie
s
Bluetooth controller should only report known codecs.
Terms: If-Implemented
Description
This requirement will be enforced as “If Implemented” from Feb 2022 onwards.
Bluetooth controller and IHV audio driver MUST report SBC as one of the supported codecs. Additional codecs
reported MUST be from the list below (list can be appended in new releases):
- AAC
- aptX
The tests for this requirement may need special hardware to execute. Please see https://aka.ms/bthlksetup for more
information.
System.Client.BluetoothController.HciExtensions.A2dpOffload.SimultaneousSco
IHV Audio driver and Bluetooth Controller should ensure that A2DP offload should suspend if SCO is active.
Page 26 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
Terms: If-Implemented
Description
This requirement will be enforced as “If Implemented” from Feb 2022 onwards.
IHV audio driver and Bluetooth Controller should stop streaming A2DP audio data when told to suspend and should
restart when told to restart. This is a common scenario when a SCO channel is opened/closed e.g. when a user
answers a phone call while streaming music.
The tests for this requirement may need special hardware to execute. Please see https://aka.ms/bthlksetup for more
information.
System.Client.BluetoothController.HciExtensions.MonitorAdvertisementV2
This section contains requirements for Microsoft .Vendor HCI Extensions to filter extended advertisements.
System.Client.BluetoothController.HciExtensions.MonitorAdvertisementV2.CoreRequirem
ent
Applies to Windows 11 Client x64
Windows 11 Client ARM64
Terms: If-Implemented
Description
Radios must comply with the Microsoft defined Bluetooth HCI extensions specification. The details of the
specifications are located on MSDN: https://aka.ms/bthciextensions
System.Client.BluetoothController.LEAudioUnicast
This section contains requirements for LE Audio Unicast feature. This is an optional feature, but all requirements under
this section must be implemented if LE Audio Unicast feature is supported.
To declare support, include the following in the DDInstall.HW section of the INF file for the Bluetooth controller:
Include = bth.inf
Needs = BthLEConnectedIsochronousStreamsOptIn.HW
Page 27 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
System.Client.BluetoothController.LEAudioUnicast.HciExtensionsMonitorAdvertisementV
2
Applies to Windows 11 Client x64
Windows 11 Client ARM64
Terms: If-Implemented
Description
WHCP feature System.Client.BluetoothController.HciExtensions.MonitorAdvertisementV2 must be supported.
System.Client.BluetoothController.LEAudioUnicast.BRSecureConnections
Applies to Windows 11 Client x64
Windows 11 Client ARM64
Terms: If-Implemented
Description
Implement BR secure connections feature that was added in the Bluetooth Core Specification version 4.1 and any
erratas since then.
This requirement refers to feature number 51, 64, 67, and 136 in BLUETOOTH SPECIFICATION Version 4.1 | Vol 2, Part
C, section 3.3 FEATURE MASK.
System.Client.BluetoothController.LEAudioUnicast.ConnectedIsochronousStreams
Applies to Windows 11 Client x64
Windows 11 Client ARM64
Terms: If-Implemented
Description
This requirement refers to bit 28, 29, and 32 of the Link Layer supported features as defined in BLUETOOTH
SPECIFICATION Version 5.2 | Vol 6, Part B, section 4.6 FEATURE SUPPORT.
System.Client.BluetoothController.LEAudioUnicast.LEPowerControl
Applies to Windows 11 Client x64
Windows 11 Client ARM64
Terms: If-Implemented
Description
Page 28 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
WHCP feature System.Client.BluetoothController.CoreSpecification5Dot2.LEPowerControl must be supported.
System.Client.BluetoothController.LEAudioUnicast.LEEnhancedConnectionUpdate
Applies to Windows 11 Client x64
Windows 11 Client ARM64
Terms: If-Implemented
Description
WHCP feature System.Client.BluetoothController.CoreSpecification5Dot3.LEEnhancedConnectionUpdate must be
supported.
System.Client.BluetoothController.LEAudioUnicast.LEChannelClassification
Applies to Windows 11 Client x64
Windows 11 Client ARM64
Terms: If-Implemented
Description
WHCP feature System.Client.BluetoothController.CoreSpecification5Dot3.LEChannelClassification must be supported.
System.Client.BluetoothController.LEAudioUnicast.CoreSpecification5Dot3
Applies to Windows 11 Client x64
Windows 11 Client ARM64
Terms: If-Implemented
Description
Controller shall be Bluetooth Core Specification.version 5.3 compliant and shall reflect this in the returned parameters
of the HCI_Read_Local_Version_Information command’s HCI_Version and LMP_Version.
System.Client.BluetoothController.LEAudioUnicast.Transport
Applies to Windows 11 Client x64
Windows 11 Client ARM64
Terms: If-Implemented
Description
Implement BR secure connections feature that was added in the Bluetooth Core Specification version 4.1 and any
erratas since then.
Page 29 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
This requirement refers to feature number 51, 64, 67, and 136 in BLUETOOTH SPECIFICATION Version 4.1 | Vol 2, Part
C, section 3.3 FEATURE MASK.
System.Client.BluetoothController.MicrosoftStack
System.Client.BluetoothController.MicrosoftStack.BluetoothDeviceClass
Applies to Windows 11 Client x64
Windows 11 Client ARM64
Description
The Microsoft Bluetooth stack must be present if there are any devices with the Bluetooth device class.
System.Client.BluetoothController.NonUSB
These requirements apply to systems that have non-USB Bluetooth enabled controllers.
System.Client.BluetoothController.NonUSB.NonUsbUsesMicrosoftsStack
Any platform using a non-USB connected Bluetooth enabled controller must ship with Microsoft’s inbox Bluetooth stack.
Description
Any platform using a non-USB connected Bluetooth enabled controller must ship with Microsoft’s inbox Bluetooth
stack.
System.Client.BluetoothController.NonUSB.ScoSupport
Any platform with a non-USB connected Bluetooth enabled controller must use a sideband channel for SCO.
Description
Any platform using a Non-USB connected Bluetooth enabled controller must use sideband channel for SCO (such as
SCO over an I2S/PCM interface).
Page 30 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
System.Client.BluetoothController.CoreSpecification5Dot2.AutoConnectionE
stablishmentProcedure
These requirements apply to Bluetooth controllers implementing LE Auto Connection Establishment
Procedure as defined in the Bluetooth 5.2 specification.
System.Client.BluetoothController.CoreSpecification5Dot2.AutoConnectionEstablishment
Procedure.CoreRequirement
Applies to Windows 11 Client x64
Windows 11 Client ARM64
Terms : If-Implemented
Description
Windows will not use the LE Auto Connection Establishment Procedure feature unless support is declared and this
requirement is satisfied. To declare support, include the following in the DDInstall.HW section of the INF file for the
Bluetooth controller:
Include = bth.inf
Needs = BthLEAutoConnectionEstablishmentProcedureOptIn.HW
System.Client.BluetoothController.USB
These requirements apply to systems that have USB Bluetooth enabled controllers.
System.Client.BluetoothController.USB.ScoDataTransportLayer
Bluetooth enabled host controllers support the SCO data transport layer as specified in the Bluetooth 2.1+EDR
specifications.
Description
A System with a Bluetooth enabled controller must comply with the Synchronous Connection Oriented (SCO)-USB
requirements that are outlined in the Specification of the Bluetooth System, Version 2.1 + Enhanced Data Rate (EDR),
Part A, Section 3.5.
System.Client.BluetoothController.UsbTransport.Transport
This section contains requirements for any Bluetooth controller which communicates with the host computer via the Host
Controller Interface (HCI) over the Universal Serial Bus (USB).
System.Client.BluetoothController.UsbTransport.Transport.UsbDescriptors
Applies to Windows 11 Client x64
Windows 11 Client ARM64
Terms: Optional
Description
Page 31 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
A controller shall report the attributes of its USB interface via USB descriptors. For more information, see section 9.6
“Standard USB Descriptor Definitions” of USB 2.0 Specification or USB 3.2 Specification.
The USB interface shall support necessary endpoints which meet the requirements as described in section 2 “USB
ENDPOINT EXPECTATIONS” of Bluetooth Core Specification version 5.3 | Vol 4 (Host Controller Interface), Part B (USB
Transport Layer). In addition, the maximum packet size for an isochronous endpoint shall have the same value as its
“suggested max packet size” counterpart. For example, the maximum packet sizes for alternate setting 2 and 6, if
implemented, must be 17 and 63 respectively (see Table 2.1 “USB firmware interface and endpoint settings” in
Bluetooth Core Specification | Vol 4, Part B).
System.Client.BluetoothController.UsbTransport.AlternateSetting6
This section contains requirements for those USB-based Bluetooth controllers which support alternate setting 6.
System.Client.BluetoothController.UsbTransport.AlternateSettings6.CoreRequirement
Applies to Windows 11 Client x64
Windows 11 Client ARM64
Terms: Optional
Description
Alternate setting 6 shall be implemented in such a way that the controller guarantees the following:
• Given an outgoing HCI packet sent by the host, the first octet in its payload shall be transmitted as the first
octet in the payload of an enhanced synchronous connection-oriented (eSCO) packet.
• Each incoming USB isochronous packet received by the host, if present, shall contain a full maximum packet
size’s worth of data. (In other words, each packet should be 63 bytes in length for USB alternate setting 6
assuming full-speed USB). If the actual packet size is different from maximum packet size, the host may drop
the data.
System.Client.BrightnessControls
This section describes requirements systems with brightness controls.
System.Client.BrightnessControls.BacklightOptimization
Windows Display Driver Model (WDDM) 1.2 drivers must enable scenario based backlight power optimization to reduce
backlight level used by integrated panel.
Description
a. If WDDM driver supports scenario based backlight power optimization, it must indicate the support by
implementing the DXGK_BRIGHTNESS_INTERFACE2 interface.
Page 32 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
b. When Windows sets the current scenario by using the DxgkDdiSetBacklightOptimization function, the
WDDM driver is required to honor the intent of the scenario as follows:
c. Driver is allowed to dynamically change the aggressiveness level based on the content on the screen.
d. Driver is required to handle Windows requests for change to brightness level (based on user input or
ambient light sensor) while keeping backlight optimization enabled.
a. This is important in the case when user briefly invokes playback controls. At that time, Windows will
reset the scenario from DxgkBacklightOptimizationDynamic to DxgkBacklightOptimizationDesktop.
The transition must not be a step but must be gradual.
g. Connecting additional display devices to the system must not impact the ability to perform backlight
optimization on the integrated panel of the system.
System.Client.BrightnessControls.BrightnessControlButtons
Systems that have built in physical brightness control function keys use standard ACPI events and support control of LCD
backlight brightness via ACPI methods in the system firmware.
Description
Windows provides users with an LCD brightness control user interface. If the system implements keys that are
invisible to the operating system, these keys must use Advanced Configuration and Power Interface (ACPI) methods.
These keys must not directly control the brightness after Bit 2 of the _DOS method has been set. This requires the
implementation of ACPI brightness methods in the system firmware.
Page 33 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
_BCL
_BCM
Bit 2 of the _DOS method must be disabled so that the system firmware cannot change the brightness levels
automatically.
Support for the _BQC method is highly recommended but not required. Systems must map keys to the following ACPI
notification values:
1. ACPI_NOTIFY_CYCLE_BRIGHTNESS_HOTKEY 0x85
2. ACPI_NOTIFY_INC_BRIGHTNESS_HOTKEY 0x86
3. ACPI_NOTIFY_DEC_BRIGHTNESS_HOTKEY 0x87
4. ACPI_NOTIFY_ZERO_BRIGHTNESS_HOTKEY 0x88
Design Notes:
The _BCL and _BCM methods in the firmware enable the operating system to query the brightness range and values
and to set new values. Refer to the ACPI 3.0 specification for more details.
System.Client.BrightnessControls.SmoothBrightness
Driver must support a smooth transition in response to all brightness change requests from Windows.
Description
A. All Windows systems that support brightness control, are required to support smooth brightness control
B. All Windows systems are required to report 101 brightness levels to Windows. Brightness is reported as a %
so this means 0 to 100 levels, including 0 and 100. Internally the driver might support more granular
brightness control.
C. This is to ensure that Windows has the ability to make fine grained changes to the screen brightness.
However, the brightness slider UI might expose fewer levels through the slider because it might be
cumbersome for the user to adjust so many levels.
D. WDDM driver is required to implement smooth brightness control in the driver without depending on the
embedded controller (EC) for the smoothness.
E. WDDM driver is required to indicate support for smooth brightness control using the capability bit defined
in the DXGK_BRIGHTNESS_INTERFACE2 interface.
F. WDDM driver must enable/disable smooth brightness control based on state set using
DxgkDdiSetBrightnessState.
G. When Windows requests a change to brightness, driver is required to gradually change the brightness level
over time so that the change is not a step.
Page 34 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
H. WDDM driver is allowed to select an appropriate slope for transition. However, the transition must complete
in less than 2s.
I. WDDM driver is allowed to alter the slope based on panel characteristics to ensure smoothness of brightness
control.
J. WDDM driver is required to start responding immediately to new brightness level requests. This must be
honored even if the system is already in the process of an existing transition. At such a time, the system must
stop the existing transition at the current level and start the new transition from the current position. This will
ensure that when a user is using the slider to manually adjust the brightness, the brightness control is still
responsive and not sluggish.
K. WDDM driver is required to continue supporting smooth brightness control, even if content based adaptive
brightness optimization is currently in effect.
L. When WDDM driver is pnp started, it must detect the brightness level applied by the firmware and smoothly
transition from that level to the level set by Windows.
M. Connecting additional display devices to the system must not impact the ability to do smooth brightness
control on the integrated panel of the system.
N. Brightness levels are represented as a % in Windows. Therefore there is no absolute mapping between
brightness % level and physical brightness level. For Windows 8, the following is the guidance.
System.Client.Buttons
System.Client.Buttons.HardwareButtons
Hardware buttons are implemented correctly
Description:
Page 35 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
Hardware buttons must be implemented according to the guidance on the following page:
https://msdn.microsoft.com/en-us/library/windows/hardware/dn957423(v=vs.85).aspx
GPIO buttons must be specified using the standardized ACPI generic button device (ACPI0011):
https://msdn.microsoft.com/en-us/library/windows/hardware/dn957422(v=vs.85).aspx
In the case where buttons are not wired through GPIO interrupts, buttons must be reported to Windows as HID
collections. HID button report descriptors must follow the report descriptors specified on the following page:
https://msdn.microsoft.com/en-us/library/windows/hardware/dn457881(v=vs.85).aspx
System.Client.Camera
System.Client.Camera.Base.CameraControls
Systems with integrated cameras meet the requirements of, and can support the Windows Capture Infrastructure.
Description
System Memory:
Independent Streaming:
All integrated Cameras must support independent streaming between different pins and different filters (cameras)
according to the capabilities listed in the Profiles advertised by the device. If the camera does not support Profiles,
then concurrent streaming for all system cameras is required.
Mirroring:
Page 36 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
• Contrast
• Exposure Compensation
• Hue
• Pan
• Tilt
• Roll
• Video Stabilization
• Variable Frame Rate
• Face Detection
• Video HDR
• Histogram
• Advanced Photo
• Background Segmentation
• Eyegaze Correction
• Digital Window
If any individual control is implemented in the camera driver, it must comply with the control specification in the
WDK.
Photo Sequence captures a sequence of photos in response to a single photo click. Capture pipeline would send
buffers to the camera driver continuously to capture the photos in sequence. This mode also allows capturing photos
from the time before the “user click” thus helping users not to lose a moment.
If camera HW supports Photo Sequence, it must expose the capability through the Photo Mode property and comply
with the performance requirements.
Page 37 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
Variable Photo Sequence captures a finite number of images and supports the ability to vary the capture parameters
for each of the captured images. If implemented in Camera driver then the driver should be able to return the
requested number of images, in order, each with varying capture parameters as instructed by the application. The
driver shall be able to preprogram the number of frames needed and set independent capture parameters for each
frame before capture is initiated.
It is recommended that the variable photo sequence allows the application to specify the following parameters for
each frame, but at least one of these must be implemented if VPS is supported:
1. Exposure
2. ISO
3. Exposure Compensation in EV
4. Focus position
5. Flash
If any parameter is not set in per frame settings the driver shall follow the global settings and 3A locks. For example
when EV bracketing is used, the driver shall ensure that exposure related parameters like gain and exposure are set
according to EV bracketing settings. The driver may vary auto white balance settings for image frames unless the per
frame settings use manual white balance settings or in case of application uses white balance lock. It not
recommended that lens position is automatically changed between the VPS frames (unless manually specified by the
application).
System.Client.Camera.Base.Device
Systems with integrated cameras must meet camera device requirements.
Description
Each integrated camera on a system must comply with Device.Streaming.Camera.Base and all related requirements.
If the integrated camera is a USB camera, it must also comply with Device.Streaming.Camera.UVC for the system
seeking certification.
Note: With regards to ‘Device.Streaming.Camera.Base.UsageIndicator’ if a system has multiple cameras, then one
physical indicator (e.g. LED) is acceptable so long as it indicates usage whenever one or more cameras are in use.
Systems without a display must have a physical indicator.
System.Client.Camera.Base.PhysicalLocation
Systems with integrated cameras must report the physical location of each camera.
Description
Page 38 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
For any camera device that is built into the chassis of the system and has mechanically fixed direction, the firmware
must provide the _PLD method and set the panel field (bits [69:67]) to the appropriate value for the panel and cabinet
on which the camera is mounted. For example, "Front" indicates the camera faces the user, while "back" indicates that
the camera faces away from the end user.
In addition, bits 143:128 (Vertical Offset), and bits 159:144 (Horizontal Offset) must provide the relative location of the
camera with respect to the display. This origin is relative to the native pixel addressing in the display component. The
origin is the lower left hand corner of the display, where positive Horizontal and Vertical Offset values are to the right
and up, respectively. For more information, see the ACPI version 5.0 Section 6.1.8 "Device Configuration _PLD
(Physical Device Location)."
Camera device orientation with respect to the default system display orientation (also known as native system display
orientation) must be specified in the _PLD rotation field (bits 115-118). When the pixels read out from the camera
sensor can be displayed correctly without any rotation, then the camera sensor’s _PLD rotation value must be set to 0.
When the pixels read out from the camera sensor need to be rotated clockwise to display correctly, then the camera
sensor’s _PLD rotation value must be set accordingly (‘0’ for 0°, ‘2’ for 90°, ‘4’ for 180°, and ‘6’ for 270°).
System.Client.Camera.SensorCapture.SensorCapture
Systems with integrated cameras meet the requirements of, and can support the Windows Capture Infrastructure.
Description
Systems supporting a sensor capture camera must be able to support basic Windows Media Pipeline streaming. There
is currently no requirements on the definition of the payload provided, but the device must provide samples that can
be captured and provided to a generic, third party application even if no standard definition of that payload exists.
System.Client.Camera.VideoCapture.VideoCapture
Systems with integrated cameras meet the requirements of, and can support the Windows Capture Infrastructure.
Description
Systems supporting a video capture camera must be able to support basic Windows Media Pipeline scenarios. These
include, but are not limited to:
• Video Preview of mediatypes available from the output of either the camera source or its user mode component
• (Optional) Video Record of compressed mediatypes available from the output of either the camera source or its
user mode component to Windows provided record sinks
• Video Record of uncompressed mediatypes available from the output of either the camera source or its user
mode components to system provided encoders and finalized in Windows provided record sinks
Page 39 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
• Photo of mediatypes available from the output of either the camera source or its user mode components to
Windows provided photo sinks.
• All mediatypes provided by the output of the camera source or its user mode components (which ever is the
latest in the pipeline) must be consumable by a generic, third party application.
System.Client.Digitizer
System.Client.Digitizer.Base.SystemDigitizersBase
System Digitizer Base
Description
The following Digitizer Base device level requirements must be met and verified upon integration into a system.
Please refer to the following Device.Input.Digitizer.Base requirements for full requirement details:
Device.Input.Digitizer.Base.NoiseSuppression
Device.Input.Digitizer.Base.HIDCompliant
Device.Input.Digitizer.Base.ThirdPartyDrivers
System.Client.Digitizer.SystemPen
System Pen
Description
The following Pen device level requirements must be met and verified upon integration into a system. Please refer to
the following Device.Input.Digitizer.Pen requirements for full requirement details:
Device.Input.Digitizer.Pen.Accuracy
Device.Input.Digitizer.Pen.BarrelButton
Device.Input.Digitizer.Pen.Buffering
Device.Input.Digitizer.Pen.CustomGestures
Device.Input.Digitizer.Pen.Eraser
Device.Input.Digitizer.Pen.HIDCompliant
Page 40 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
Device.Input.Digitizer.Pen.HighResolutionTimeStamp
Device.Input.Digitizer.Pen.HoverRange
Device.Input.Digitizer.Pen.Jitter
Device.Input.Digitizer.Pen.NoiseSuppression
Device.Input.Digitizer.Pen.Pressure
Device.Input.Digitizer.Pen.ReportRate
Device.Input.Digitizer.Pen.Resolution
Device.Input.Digitizer.Pen.ResponseLatency
Device.Input.Digitizer.Pen.ThirdPartyDrivers
System.Client.Digitizer.SystemTouch
System Touch
Description
The following Touch device level requirements must be met and verified upon integration into a system. Please refer
to the following Device.Input.Digitizer.Touch requirements for full requirement details:
Device.Input.Digitizer.Touch.Accuracy
Device.Input.Digitizer.Touch.Buffering
Device.Input.Digitizer.Touch.CustomGestures
Device.Input.Digitizer.Touch.FingerSeparation
Device.Input.Digitizer.Touch.HIDCompliant
Device.Input.Digitizer.Touch.HighResolutionTimeStamp
Device.Input.Digitizer.Touch.Jitter
Device.Input.Digitizer.Touch.MinContactCount
Device.Input.Digitizer.Touch.NoiseSuppression
Device.Input.Digitizer.Touch.ReportRate
Device.Input.Digitizer.Touch.Resolution
Device.Input.Digitizer.Touch.ResponseLatency
Device.Input.Digitizer.Touch.ThirdPartyDrivers
Page 41 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
Microsoft strongly recommends touch solutions capable of reporting 5 or more simultaneous contact points. This ensures that
the platform is compatible with third party applications that rely upon touch input, and that end users are able to invoke all of
the system gestures provided by Windows.
Microsoft recognizes that extenuating circumstances exist whereby an extended gesture experience is not necessary. In order
to accommodate this very limited set of systems, we make the following allowances:
Systems that are sold as build to configure, custom enterprise images, or are designed for specific vertical enterprise markets,
have the option to ship a touch screen capable of reporting only a single contact point. Examples include systems designed for
health care, military applications, and Point of Sale.
Any system incapable of supporting more than a single contact point will be unable to invoke any system gestures other than
generic mouse-like behavior.
A system reliant upon a keyboard and mouse as the primary input modality, without the capability to convert into a tablet
mode device, may choose to integrate a touch solution capable of supporting a minimum of 2 simultaneous contact
points. Examples include: external displays, All-In-One desktop systems.
Any system incapable of supporting more than 2 simultaneous contact points will be unable to invoke 4 finger accessibility
gestures.
System.Client.Digitizer.SystemPrecisionTouchpad
Precision Touchpad
Description
The following Precision Touchpad device level requirements must be met and verified upon integration into a system.
Please refer to the following Device.Input.Digitizer.PrecisionTouchpad requirements for full requirement details:
Device.Input.Digitizer.PrecisionTouchpad.Accuracy
Device.Input.Digitizer.PrecisionTouchpad.Buffering
Device.Input.Digitizer.PrecisionTouchpad.Buttons
Device.Input.Digitizer.PrecisionTouchpad.ContactTipSwitchHeight
Device.Input.Digitizer.PrecisionTouchpad.DeviceTypeReporting
Device.Input.Digitizer.PrecisionTouchpad.Dimensions
Device.Input.Digitizer.PrecisionTouchpad.FingerSeparation
Device.Input.Digitizer.PrecisionTouchpad.HIDCompliant
Device.Input.Digitizer.PrecisionTouchpad.HighResolutionTimeStamp
Device.Input.Digitizer.PrecisionTouchpad.InputResolution
Device.Input.Digitizer.PrecisionTouchpad.Jitter
Page 42 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
Device.Input.Digitizer.PrecisionTouchpad.MinMaxContacts
Device.Input.Digitizer.PrecisionTouchpad.NoiseSuppression
Device.Input.Digitizer.PrecisionTouchpad.ReportRate
Device.Input.Digitizer.PrecisionTouchpad.ResponseLatency
Device.Input.Digitizer.PrecisionTouchpad.SelectiveReporting
Device.Input.Digitizer.PrecisionTouchpad.ThirdPartyDrivers
A touchpad may not be marketed as a Precision Touchpad if the device requires a 3rd party driver be installed in order
to report as a Precision Touchpad.
System.Client.Digitizer.Pen
Important Note: One or more of the following supported protocols are required:
System.Client.Digitizer.Pen.Accuracy
System Pen Contact Accuracy
Description:
The following Pen device level requirement must be met and verified upon integration into a system. Please refer to
the Device.Input.Digitizer.Pen.Accuracy requirement for full requirement details.
System.Client.Digitizer.Pen.BarrelButton
System Pen Barrel Button Affordance
Description
The following Pen device level requirement must be met and verified upon integration into a system. Please refer to
the Device.Input.Digitizer.Pen.BarrelButton requirement for full requirement details.
System.Client.Digitizer.Pen.Buffering
System Pen Buffering for buses with High Resume latency
Page 43 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
DescriptionThe following Pen device level requirement must be met and verified upon integration into a system.
Please refer to the Device.Input.Digitizer.Pen.Buffering requirement for full requirement details.
System.Client.Digitizer.Pen.CustomGestures
System Pen Custom Run-Time System Gestures
Description
The following Pen device level requirement must be met and verified upon integration into a system. Please refer to
the Device.Input.Digitizer.Pen.CustomGestures requirement for full requirement details.
System.Client.Digitizer.Pen.Eraser
System Pen Eraser Affordance
DescriptionThe following Pen device level requirement must be met and verified upon integration into a system.
Please refer to the Device.Input.Digitizer.Pen.Eraser requirement for full requirement details.
System.Client.Digitizer.Pen.HIDCompliant
System Pen HID Compliant Device Firmware and/or HID Mini-port Driver
Description
The following Pen device level requirement must be met and verified upon integration into a system. Please refer to
the Device.Input.Digitizer.Pen.HIDCompliant requirement for full requirement details.
System.Client.Digitizer.Pen.HighResolutionTimeStamp
System Pen Hardware Scan Time
The following Pen device level requirement must be met and verified upon integration into a system. Please refer to
the Device.Input.Digitizer.Pen.HighResolutionTimeStamp requirement for full requirement details.
Page 44 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
System.Client.Digitizer.Pen.HoverRange
System Pen Hover Range
Description
The following Pen device level requirement must be met and verified upon integration into a system. Please refer to
the Device.Input.Digitizer.Pen.HoverRange requirement for full requirement details.
System.Client.Digitizer.Pen.Jitter
System Pen Jitter and Linearity
Description
The following Pen device level requirement must be met and verified upon integration into a system. Please refer to
the Device.Input.Digitizer.Pen.Jitter requirement for full requirement details.
System.Client.Digitizer.Pen.NoiseSuppression
System Pen Digitizer Reliability
Description
The following Pen device level requirement must be met and verified upon integration into a system. Please refer to
the Device.Input.Digitizer.Pen.NoiseSuppression requirement for full requirement details.
System.Client.Digitizer.Pen.Pressure
System Pen Pressure Reporting
Description
The following Pen device level requirement must be met and verified upon integration into a system. Please refer to
the Device.Input.Digitizer.Pen.Pressure requirement for full requirement details.
Page 45 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
System.Client.Digitizer.Pen.ReportRate
System Pen Report Rate
Description
The following Pen device level requirement must be met and verified upon integration into a system. Please refer to
the Device.Input.Digitizer.Pen.ReportRate requirement for full requirement details.
System.Client.Digitizer.Pen.Resolution
System Pen Input Resolution
Description
The following Pen device level requirement must be met and verified upon integration into a system. Please refer to
the Device.Input.Digitizer.Pen.Resolution requirement for full requirement details.
System.Client.Digitizer.Pen.ResponseLatency
System Pen Response Latency
Description
The following Pen device level requirement must be met and verified upon integration into a system. Please refer to
the Device.Input.Digitizer.Pen.ResponseLatency requirement for full requirement details.
System.Client.Digitizer.Pen.ThirdPartyDrivers
System Pen Servicing and 3rd Party Driver Availability
Description
The following Pen device level requirement must be met and verified upon integration into a system. Please refer to
the Device.Input.Digitizer.Pen.ThirdPartyDrivers requirement for full requirement details.
Page 46 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
System.Client.Digitizer.PrecisionTouchpad
System.Client.Digitizer.PrecisionTouchpad.Accuracy
System Precision Touchpad Accuracy
Description
The following Precision Touchpad device level requirement must be met and verified upon integration into a system.
Please refer to the Device.Input.Digitizer.PrecisionTouchpad.Accuracy requirement for full requirement details.
System.Client.Digitizer.PrecisionTouchpad.Buffering
System Precision Touchpad Buffering for Buses with High Resume Latency
Description
The following Precision Touchpad device level requirement must be met and verified upon integration into a system.
Please refer to the Device.Input.Digitizer.PrecisionTouchpad.Buffering requirement for full requirement details.
System.Client.Digitizer.PrecisionTouchpad.Buttons
System Precision Touchpad Physical Buttons and Button Reporting
Description
The following Precision Touchpad device level requirement must be met and verified upon integration into a system.
Please refer to the Device.Input.Digitizer.PrecisionTouchpad.Buttons requirement for full requirement details.
System.Client.Digitizer.PrecisionTouchpad.ContactTipSwitchHeight
System Precision Touchpad Contact Tip Switch Height
Description
The following Precision Touchpad device level requirement must be met and verified upon integration into a system.
Please refer to the Device.Input.Digitizer.PrecisionTouchpad.ContactTipSwitchHeight requirement for full
requirement details.
System.Client.Digitizer.PrecisionTouchpad.DeviceTypeReporting
System Precision Touchpad Device Type
Page 47 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
Applies to Windows 11 Client x64
Windows 11 Client ARM64
Description
The following Precision Touchpad device level requirement must be met and verified upon integration into a system.
Please refer to the Device.Input.Digitizer.PrecisionTouchpad.DeviceTypeReporting requirement for full
requirement details.
System.Client.Digitizer.PrecisionTouchpad.Dimensions
System Precision Touchpad Dimensions
Description
The following Precision Touchpad device level requirement must be met and verified upon integration into a system.
Please refer to the Device.Input.Digitizer.PrecisionTouchpad.Dimensions requirement for full requirement details.
System.Client.Digitizer.PrecisionTouchpad.FingerSeparation
System Precision Touchpad Finger Separation
Description
The following Precision Touchpad device level requirement must be met and verified upon integration into a system.
Please refer to the Device.Input.Digitizer.PrecisionTouchpad.FingerSeparation requirement for full requirement
details.
System.Client.Digitizer.PrecisionTouchpad.HIDCompliant
System Precision Touchpad HID Compliant Device Firmware and/or HID Mini-port Driver
Description
The following Precision Touchpad device level requirement must be met and verified upon integration into a system.
Please refer to the Device.Input.Digitizer.PrecisionTouchpad.HIDCompliant requirement for full requirement
details.
System.Client.Digitizer.PrecisionTouchpad.HighResolutionTimeStamp
System Precision Touchpad Hardware Scan Time
The following Precision Touchpad device level requirement must be met and verified upon integration into a system.
Please refer to the Device.Input.Digitizer.PrecisionTouchpad.HighResolutionTimeStamp requirement for full
requirement details.
System.Client.Digitizer.PrecisionTouchpad.InputResolution
System Precision Touchpad Input Resolution
Description
The following Precision Touchpad device level requirement must be met and verified upon integration into a system.
Please refer to the Device.Input.Digitizer.PrecisionTouchpad.Input Resolution requirement for full requirement
details.
System.Client.Digitizer.PrecisionTouchpad.Jitter
System Precision Touchpad Jitter and Linearity
Description
The following Precision Touchpad device level requirement must be met and verified upon integration into a system.
Please refer to the Device.Input.Digitizer.PrecisionTouchpad.Jitter requirement for full requirement details.
System.Client.Digitizer.PrecisionTouchpad.MinMaxContacts
System Precision Touchpad Contact count
Description
The following Precision Touchpad device level requirement must be met and verified upon integration into a system.
Please refer to the Device.Input.Digitizer.PrecisionTouchpad.MinMaxContacts requirement for full requirement
details.
System.Client.Digitizer.PrecisionTouchpad.NoiseSuppression
System Precision Touchpad Digitizer Reliability
Page 49 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
Description
The following Precision Touchpad device level requirement must be met and verified upon integration into a system.
Please refer to the Device.Input.Digitizer.PrecisionTouchpad.NoiseSuppression requirement for full requirement
details.
System.Client.Digitizer.PrecisionTouchpad.ReportRate
System Precision Touchpad Report Rates
Description
The following Precision Touchpad device level requirement must be met and verified upon integration into a system.
Please refer to the Device.Input.Digitizer.PrecisionTouchpad.ReportRate requirements for full requirement details.
System.Client.Digitizer.PrecisionTouchpad.ResponseLatency
System Precision Touchpad Response latency
Description
The following Precision Touchpad device level requirement must be met and verified upon integration into a system.
Please refer to the Device.Input.Digitizer.PrecisionTouchpad.ResponseLatency requirement for full requirement
details.
System.Client.Digitizer.PrecisionTouchpad.SelectiveReporting
System Precision Touchpad Selective Reporting
Description
The following Precision Touchpad device level requirement must be met and verified upon integration into a system.
Please refer to the Device.Input.Digitizer.PrecisionTouchpad.SelectiveReporting requirements for full requirement
details.
System.Client.Digitizer.PrecisionTouchpad.ThirdPartyDrivers
System Precision Touchpad Servicing and 3rd Party Driver Availability
Page 50 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
Applies to Windows 11 Client x64
Description
The following Precision Touchpad device level requirement must be met and verified upon integration into a system.
Please refer to the Device.Input.Digitizer.PrecisionTouchpad.ThirdPartyDrivers requirements for full requirement
details.
System.Client.Digitizer.PrecisionTouchpad.Reporting
Systems which have a touchpad must be PTP compliant.
Description
Touchpads must report as Precision Touchpads and meet relevant HLK requirements on all devices which expose a
HID mouse top level collection to the host, except when that mouse collection is a sibling of a touch or pen device. In
addition, any touchpad built into any accessory shipping with the device must also report as a Precision Touchpad
and meet the respective HLK requirements.
System.Client.Digitizer.Touch
System.Client.Digitizer.Touch.Accuracy
System Touch Accuracy
Description
The following Touch device level requirements must be met and verified upon integration into a system. Please refer
to the following Device.Input.Digitizer.Touch.Accuracy requirement for full requirement details.
System.Client.Digitizer.Touch.Buffering
System Touch Buffering for Buses with High Resume Latency
Description
Page 51 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
The following Touch device level requirements must be met and verified upon integration into a system. Please refer
to the following Device.Input.Digitizer.Touch.Buffering requirement for full requirement details.
System.Client.Digitizer.Touch.CustomGestures
System Touch Custom Run-Time System Gestures
Description
The following Touch device level requirements must be met and verified upon integration into a system. Please refer
to the following Device.Input.Digitizer.Touch.CustomGestures requirement for full requirement details.
System.Client.Digitizer.Touch.FingerSeparation
System Touch Finger Separation
Description
The following Touch device level requirements must be met and verified upon integration into a system. Please refer
to the following Device.Input.Digitizer.Touch.FingerSeparation requirement for full requirement details.
System.Client.Digitizer.Touch.HIDCompliant
System Touch HID Compliant Device Firmware and/or HID Mini-port Driver
Description
The following Touch device level requirements must be met and verified upon integration into a system. Please refer
to the following Device.Input.Digitizer.Touch.HIDCompliant requirement for full requirement details.
System.Client.Digitizer.Touch.HighResolutionTimeStamp
System Touch Hardware Scan Time
Page 52 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
Description
The following Touch device level requirements must be met and verified upon integration into a system. Please refer
to the following Device.Input.Digitizer.Touch.HighResolutionTimeStamp requirement for full requirement details.
System.Client.Digitizer.Touch.Jitter
System Touch Jitter and Linearity
Description
The following Touch device level requirements must be met and verified upon integration into a system. Please refer
to the following Device.Input.Digitizer.Touch.Jitter requirement for full requirement details.
System.Client.Digitizer.Touch.MinContactCount
System Touch Minimum simultaneous reportable contacts
Description
The following Touch device level requirements must be met and verified upon integration into a system. Please refer
to the following Device.Input.Digitizer.Touch.MinContactCount requirement for full requirement details.
System.Client.Digitizer.Touch.NoiseSuppression
System Touch Digitizer Reliability
Description
The following Touch device level requirements must be met and verified upon integration into a system. Please refer
to the following Device.Input.Digitizer.Touch.NoiseSuppression requirement for full requirement details.
Page 53 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
System.Client.Digitizer.Touch.ReportRate
System Touch Report Rate
Description
The following Touch device level requirements must be met and verified upon integration into a system. Please refer
to the following Device.Input.Digitizer.Touch.ReportRate requirement for full requirement details.
System.Client.Digitizer.Touch.Resolution
System Touch Input Resolution
Description
The following Touch device level requirements must be met and verified upon integration into a system. Please refer
to the following Device.Input.Digitizer.Touch.Resolution requirement for full requirement details.
System.Client.Digitizer.Touch.ThirdPartyDrivers
System Touch Servicing and 3rd Party Driver Availability
Description
The following Touch device level requirements must be met and verified upon integration into a system. Please refer
to the following Device.Input.Digitizer.Touch.ThirdPartyDrivers requirement for full requirement details.
System.Client.Digitizer.Touch.ResponseLatency
System Touch Response Latency
Page 54 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
Description
The following Touch device level requirements must be met and verified upon integration into a system. Please refer
to the following Device.Input.Digitizer.Touch.ResponseLatency requirement for full requirement details.
System.Client.Firmware.UEFI.GOP
System.Client.Firmware.UEFI.GOP.Display
System firmware must support Graphics Output Protocol (GOP) and Windows display requirements.
Description
Every firmware on a Windows client system must support the GOP as defined in UEFI 2.3.1.
The display is controlled by the system UEFI before the WDDM graphics driver takes over. GOP must be available
when the Windows EFI boot manager loads. VBIOS is not supported. It is also required for prior UI, such as OEM
logo, firmware setup, or password prompt screens to enable GOP. During this time when the firmware is in control,
the following are the requirements.
Topology Selection
• UEFI must reliably detect all the displays that are connected to the POST adapter. The Pre-OS screen can only be
displayed on a display connected to the POST adapter.
• In case multiple displays are detected, UEFI must display the Pre-OS screen based on the following logic:
o System with an Integrated display(Laptop, All In One, Tablet): UEFI must display the Pre-OS screen only
on the integrated display.
o System without an Integrated display (integrated display is shut or desktop system): UEFI must display
the Pre-OS screen on one display. UEFI must select the display by prioritizing the displays based on
connector type. The prioritization is as follows: DisplayPort, HDMI, DVI, HD15, Component, S-Video. If
there are multiple monitors connected using the same connector type, the firmware can select which
one to use.
Mode Selection
• Once UEFI has determined which display to enabled to display the Pre-OS screen, it must select the mode to
apply based on the following logic.
o System with an Integrated display (Laptop, All In One, Tablet): The display must always be set to its
native resolution and native timing.
o System without an Integrated display (desktop):
Page 55 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
▪ UEFI must attempt to set the native resolution and timing of the display by obtaining it from
the EDID.
▪ If that is not supported, UEFI must select an alternate mode that matches the same aspect ratio
as the native resolution of the display.
▪ At the minimum, UEFI must set a mode of 1024 x 768.
▪ If the display device does not provide an EDID, UEFI must set a mode of 1024 x 768.
o The firmware must always use a 32 bit linear frame buffer to display the Pre-OS screen.
o PixelsPerScanLine must be equal to the HorizontalResolution.
o PixelFormat must be PixelBlueGreenRedReserved8BitPerColor. Note that a physical frame buffer is
required; PixelBltOnly is not supported.
Mode Pruning
• UEFI must prune the list of available modes in accordance with the requirements called out in
EFI_GRAPHICS_OUTPUT_PROTOCOL.QueryMode() (as specified in the UEFI specification version 2.1)
• Once the UEFI has set a mode on the appropriate display (based on Topology Selection), UEFI must obtain the
EDID of the display and pass it to Windows when Windows uses the EFI_EDID_DISCOVERED_PROTOCOL (as
specified in the UEFI specification version 2.1 )to query for the EDID:
o It is possible that some integrated panels might not have an EDID in the display panel itself. In this case,
UEFI must manufacture the EDID. The EDID must accurately specify the native timing and the physical
dimensions of the integrated panel.
o If the display is not integrated and does not have an EDID, then the UEFI does not need to manufacture
an EDID.
System.Client.Graphics
System.Client.Graphics.FullGPU
A Windows client system must have a "Full" graphics device and that device must be the post device.
Description
WDDM 1.3 introduces multiple driver/device types: Full, Render only, and Display only. For a detailed description of
each, refer to the WDDM 1.3 in requirement Device.Graphics.WDDM13.Base.
Each of these driver/device types are designed for specific scenarios and usage case. All client scenarios expect a "full"
graphics device. Also
Page 56 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
many applications assume that the post device is the "best" graphics devices and use that device exclusively. For this
reason, a Windows client system must have a "full" graphics driver/device that is capable of display, rendering, and
video.
System.Client.Graphics.NoMoreThanOneInternalMonitor
Graphics driver must not enumerate more than one monitor as internal.
Description
The graphics driver must not enumerate more than one display target of the D3DKMDT_VOT_INTERNAL type on any
adapter.
Design Notes:
For more information, see the Graphics guide for Windows 7 at http://go.microsoft.com/fwlink/?LinkId=237084.
System.Client.Graphics.Brightness3Calibration
Windows graphics drivers that implement the calibrated Brightness3 DDI must be calibrated
Description
All graphics drivers that implement the calibrated Brightness3 DDI must be calibrated within +/- 5% of the set
brightness level when the On Pixel Ratio is 100% for LCD displays and 50% for OLED displays where each pixel is set
to an RGB value of (255, 255, 255). In other words, if the graphics driver is set to 100 nits, then the absolute brightness
of the physical display must be in between 95 and 105 nits.
System.Client.Graphics.WDDM
All Windows graphics drivers must be Windows Display Driver Model (WDDM).
Page 57 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
Description
The WDDM architecture offers functionality to enable features such as desktop composition, enhanced fault
Tolerance, video memory manager, scheduler, cross process sharing of D3D surfaces and so on. WDDM was
specifically designed for modern graphics devices that are a minimum of Direct3D 10 Feature Level 9_3 with pixel
shader 2.0 or better and have all the necessary hardware features to support the WDDM functionality of memory
management, scheduling, and fault tolerance.
Table below explains the scenario usage for the Graphic driver types:
System.Client.Graphics.WDDMSupportRotatedModes
If accelerometer is present, Windows Display Driver Model (WDDM) driver must support all rotated modes.
Description
On a system with an accelerometer, the WDDM driver is required to support all rotated modes for every resolution
enumerated for the integrated panel:
• A WDDM driver is required to enumerate source modes for the integrated display. The WDDM driver must
support rotated modes (0, 90, 180 and 270) for every mode that it enumerates for the integrated panel.
• The rotation is required to be supported even if the integrated panel is in a duplicate or extended topology with
another display device. For duplicate mode, it is acceptable to rotate all targets connected to the rotated source.
Per path rotation is allowed but not required.
Both the above mentioned requirements are optional for Stereo 3D capable resolutions.
System.Client.Graphics.WirelessUSBDisplay
System limitations for wireless and USB connected displays.
Page 58 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
Applies to Windows 11 Client x64
Description
• Display devices (Monitor, LCD, TV, Projectors) are enumerated to Windows only via the WDDM Graphics driver.
An Indirect Display is a WDDM driver for the purposes of this document
• There must be at least one display device physically connected to a full WDDM graphics hardware that supports
at least DX 9_1 in the hardware.
• Windows only supports a fixed set of display connectors as defined in WDDM as part of the
D3DKMDT_VIDEO_OUTPUT_TECHNOLOGY enumeration.
• The WDDM (or Indirect Display) driver is required to accurately report the connection medium used to connect
the display device to the system.
• Windows supports wireless displays via Miracast connection or Indirect Display, via WDDM1.3 or WDDM2.0
display drivers.
• Systems may connect a display using the USB Type C alternate mode for DisplayPort, and this display should be
enumerated as a typical DisplayPort connection.
• Systems may use an Indirect Display driver to connect a USB display.
System.Client.Graphics.InternalDisplay.HDR
Systems may choose to include or support HDR displays.
System.Client.Graphics.InternalDisplay.HDR.CoreRequirement
Recommendation for systems with HDR displays
Description
Systems intending to support HDR functionality are recommended to validate behavior against the VESA DisplayHDR
standard. Specific details will depend on the target level of support (e.g., DisplayHDR400, DisplayHDR600, etc.). More
information can be found through the VESA DisplayHDR documentation.
Provisioning of HDR can be implemented through any of the supported paths as described in the HDR and WCG
Ecosystem Guidance for Windows 10 specification and the supplemental ICC Profile Provisioning Guidance.
Page 59 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
System.Client.Graphics.ExternalDisplay.HDR
Systems may choose to include or support HDR displays.
System.Client.Graphics.ExternalDisplay.HDR.CoreRequirement
Recommendation for systems with HDR displays
Description
Systems intending to support HDR functionality are recommended to validate behavior against the VESA DisplayHDR
standard. Specific details will depend on the target level of support (e.g., DisplayHDR400, DisplayHDR600, etc.). More
information can be found through the VESA DisplayHDR documentation.
System.Client.MobileBroadband
Mobile broadband
System.Client.MobileBroadband.ComplyWithBaseReq
Mobile broadband devices must comply with the following base requirements.
Description
Mobile Broadband devices must comply with the following base requirements:
• MUST conform to NDIS 6.30 and Microsoft Mobile Broadband Driver Model Specification requirements in
the Windows Driver Kit.
• MUST comply with power management specifications.
• MUST comply with both hardware and software radio management specifications.
• MUST meet the performance target for various operation specified for various class of devices in the Mobile
Broadband Driver Model Specification.
• Mobile broadband device driver must implement and conform to the NDIS 6.30 and Microsoft Mobile
Broadband Driver Model Specifications. All recommended implementation specified in the Mobile
Broadband Driver Model Specifications needs to be implemented. Note that Microsoft's MB class driver is
compliant to above requirements. A mobile broadband device must support the Power Management Policy
Page 60 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
as outlined in the Network Device Class Power Management Reference Specification, Version 2.0. Device
must be functional after various OS Power Management operations. Device must meet the performance
targets described in the Mobile Broadband Driver Model Specification.
Design Notes:
1. TestConnect
Description : The test verifies if the device can connect, disconnect and access cellular data
successfully. The test also validates that if packet-service is detached, the connection fails
with WWAN_STATUS_PACKET_SVC_DETACHED. Reference : OID_WWAN_CONNECT -
Windows drivers | Microsoft Docs
Test Setup : The test requires a test device and a data-capable SIM card of any operator
Test parameters :
UserName : Specifies the user name to use when making a connection (optional)
2. TestDeviceCapsEx
Description : The test queries modem system capability and extended device capability and
verifies data members. The test also queries both DeviceCaps and DeviceCapsEx and verifies
data members match correctly.
Page 61 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
Reference : OID_WWAN_DEVICE_CAPS - Windows drivers | Microsoft Docs,
OID_WWAN_DEVICE_CAPS_EX - Windows drivers | Microsoft Docs
Test Setup : The test requires a test device and a data-capable SIM card of any operator
Test parameters :
No parameters
3. TestDisableEnable
Description : The test disables and then enables the device and verify radio is turned on
correctly, and the device moves to readystateInitialized. The test also queries the device-
capabilities after disable/enable and ensure everything looks correct. This test also has a
subtest which first establishes a connection, then disables/enables the device and try to re-
establish the connection and see if the process is successful.
Test Setup : The test requires a test device and a data-capable SIM card of any operator
Test parameters :
UserName : Specifies the user name to use when making a connection (optional)
4. TestDSS
Decription : The test will open a device service session and verify successful response is
received from the modem, the test subsequently closes that session and validates modem
response as well. Reference : OID_WWAN_DEVICE_SERVICE_SESSION - Windows
drivers | Microsoft Docs, OID_WWAN_DEVICE_SERVICE_SESSION_WRITE -
Windows drivers | Microsoft Docs
Test Setup : The test requires a test device and a data-capable SIM card of any operator
Test parameters :
Page 62 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
No parameters
5. TestHomeProvider
Test Setup : The test requires a test device and a data-capable SIM card of any operator
Test parameters :
No parameters
6. TestHotSwap
Description : The test verifies that the device supports “hotswap”, i.e, remove the SIM and re-
insert same/another SIM while the device is active (not sleeping, not shutdown nor
hibernating). Please note that this is a manual test – the test requires the tester to remove the
SIM and reinsert the SIM into the device when corresponding notifications are shown on cmd
line in the Device Under Test (DUT). The notification will be shown in a green background in
cmd line like this : “Please remove the SIM from the device within 30 secs!” – this is the
indication for the tester to remove the SIM card. A followup notification will be shown by the
test as “Please re-insert the SIM to the device within 30 secs!” – this is the indication for the
tester to re-insert the SIM card.
Test Setup : The test requires a test device and a data-capable SIM card of any operator
Test parameters :
No parameters
7. TestPacketService
Description : The test performs packet-service attach operation and a subsequent packet-
service-detach and validates the responses from modem. Reference :
OID_WWAN_PACKET_SERVICE - Windows drivers | Microsoft Docs
Page 63 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
Test Setup : The test requires a test device and a data-capable SIM card of any operator
Test parameters :
No parameters
8. TestPin
Test Setup : The test requires a test device and a data-capable SIM card of any operator. The
SIM card should be able to support setting PIN and PUK parameters
Test parameters :
9. TestPowerStates
Page 64 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
a) The test establishes a cellular connection, puts the machine into hiberantion mode,
wakes the machine, and connects
b) The test establishes a cellular connection, puts the machine into hiberantion mode,
manually switch sim, wakes the machine, and re-connects
c) The test puts the machine into S0 Idle (Modern standby) mode, connects &
download small data while in S0 Idle and then wakes the machine
d) The test verifies whether we can successfully unlock SIM PIN after hibernation and
wake. The device must support D3Cold capability (Supporting D3cold in a Driver -
Windows drivers | Microsoft Docs) Initial state should be SimPinDisabled
Test Setup : The test requires a test device and 2 data-capable SIM card of any operator. The
SIM card should be able to support setting PIN parameter. The HLK checks if device supports
hibernate/S0 sleep and skips the test if it doesn’t. If the device is AOAC capable, then D3Cold
support is mandatory.
For test scenario (a), there is no manual action needed from the tester.
Please note that for test scenario (b), the tester need to manually switch the SIM once the
device is in hibernation. The HLK will notify the user via cmd line output on the test device, a
line in green color should appear like this : “Once system fully hibernates, please remove old
SIM and insert a new one!” – this is the indication for the tester to wait until device
hibernates, then switch the SIM to a new SIM card (the new SIM could be from the same
operator or even a different one)
For test scenario (c), there is no manual intervention needed from the tester
For test scenario (d) there is no manual intervention needed from the tester
Test parameters :
UserName : Specifies the user name to use when making a connection (optional)
SecondSimAccessString : Specifies the access string to use when removing existing SIM and
inserting a new one (could be same as first SIM’s accessString, if both SIMs are from same operator)
PIN1 : Specifies the PIN1 to use on the SIM being used for testing
10. TestPreferredProvider
Page 65 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
Description : The test validates multiple scenarios :
Test Setup : The test requires a test device and a data-capable SIM card of any operator
Test parameters :
No parameters
11. TestProvisionedContext
Test Setup : The test requires a test device and a data-capable SIM card of any operator
Test parameters :
No parameters
Page 66 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
12. TestRadioStateHardware
a) The test turns the hardware radio off and on when registered and validates modem
responses
b) The test turns the hardware radio off and on when packet service attached and validates
modem responses
c) The test turns the hardware radio off and on when cellular connected and validates
modem responses
Test Setup : The test requires a test device and a data-capable SIM card of any operator
Test parameters :
UserName : Specifies the user name to use when making a connection (optional)
13. TestRadioStateSoftware
d) The test turns the software radio off and on when registered and validates modem
responses
e) The test turns the software radio off and on when packet service attached and validates
modem responses
f) The test turns the software radio off and on when connected and validates modem
responses
Test Setup : The test requires a test device and a data-capable SIM card of any operator
Test parameters :
Page 67 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
AccessString : Specifies the access string to use when making a connection
UserName : Specifies the user name to use when making a connection (optional)
14. TestReadyInfo
Description : The test queries readyInfo from the modem (for the active slot) and validates
modem response. The test also validates following scenarios :
a) If modem supports multiple slots, the test does switch slot operations and validate
appropriate readyState indications come from modem.
b) If the modem supports UICC_RESET, the test executes UICC Passthrough Disable and
then UICC Passthrough Enable and verify appropriate readyState indications come from
the modem.
c) If the modem supports DEVICE_RESET, the test issues a device reset and queries for
readyInfo and validates modem responses.
Test Setup : The test requires a test device and a data-capable SIM card of any operator
Test parameters :
No parameters
15. TestRegisterState
a) The test queries register state and verifies data members of the modem response
b) The test attempts to register in automatic-register mode
c) The test attempts to register to the home provider in manual-register mode
Test Setup : The test requires a test device and a data-capable SIM card of any operator
Page 68 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
Test parameters :
No parameters
16. TestRemoval
Description : The test verifies if the device is removable and if it is removable, it validates the
following scenarios :
a) Prompts the tester to remove the device when the device is registered and validates that
the interface is gone. Then the test prompts the tester to reinsert the device and ensure
that the device is back registered successfully. Please note this is a manual test – the test
prompts user to remove the device by this message in cmd line “Please remove the
device” on the device under test (DUT). The test also prompts user to re-insert the device
by this message in the cmd line “Please insert the device”.
b) The test performs same steps as (a), this time ensuring that the device is packet-state
attached. Test performs a registration, packet-attach and prompt for tester to remove the
device. Once the device is reinserted, the test verifies if the device is re-registered and
packet-state attached. Please note this is a manual test – the test prompts user to remove
the device by this message in cmd line “Please remove the device” on the device under
test (DUT). The test also prompts user to re-insert the device by this message in the cmd
line “Please insert the device”.
c) The test performs similar steps as (a), this time establishes a cellular connection, then
prompts for the tester to remove the device. Once the tester removes and re-inserts the
device, test tries to establish a connection again. Please note this is a manual test – the
test prompts user to remove the device by this message in cmd line “Please remove the
device” on the device under test (DUT). The test also prompts user to re-insert the device
by this message in the cmd line “Please insert the device”.
Test Setup : The test requires a test device and a data-capable SIM card of any operator. It is
not mandatory that the modem is removable, if the modem is not a removable modem, the
test skips.
Test parameters :
UserName : Specifies the user name to use when making a connection (optional)
Page 69 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
17. TestSetup
Description : This test attempts to read NDIS co-installer values and validates that they are of
expected type. (For example, one of the values read is NIC’s mediatype and validated that
mediatype = NdisMediumWirelessWan). This test also does some other basic queries such as
readyInfo, deviceCaps, driverCaps, supported OIDs etc.
Test Setup : The test requires a test device and a data-capable SIM card of any operator
Test parameters :
No parameters
18. TestSignalState
Description : This test queries the signal-state of the device and validates modem response.
Reference : OID_WWAN_SIGNAL_STATE - Windows drivers | Microsoft Docs
Test Setup : The test requires a test device and a data-capable SIM card of any operator. The
test device should be at a location where cellular signal is available.
Test parameters :
No parameters
19. TestSimNotInserted
Description : This HLK test validates that all the operations that must be successful without a
SIM can be performed on the device with SIM not inserted. Such operations are :
GetDriverCaps, GetDeviceCaps, GetRadioState and GetSignalState. Radio operation too must
succeed without a SIM – turn radio on/off.
This HLK test also validates that following operations are unsuccessful without the SIM
inserted : GetPinEx, GetPinList, GetHomeProvider, GetSMSConfiguration, GetSMSStatus
This test-case will also test the following scenarios without a SIM, but those scenarios can fail
or return success based on the implementation – hence all that the HLK validates is that
those operations can be invoked : GetContextState, GetVisibleProviders, GetRegisterState,
Page 70 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
GetPacketService, retrieve supported OIDs, GetPreferredProviders and
GetProvisionedContexts.
Test Setup : The test requires a test device with no SIM card inserted.
Test parameters :
No parameters
20. TestSimRoaming
Description : The test verifies that the tester has inserted a roaming SIM into the device by
querying the register-state and ensuring that the device is registered to “roaming” or
“partner” network. The test also tries to establish a cellular connection while roaming and
ensure that disconnect happen successfully.
Test Setup : The test requires a test device with a roaming SIM card inserted.
Test parameters :
21. TestVisibleProvider
a) The test turns the radio Off, and ensure that the device is de-registered. Then it queries
the visible-providers and validate the response from modem.
b) The test attempts to auto-register the device and after registration, queries the visible-
providers and validates the response from the modem.
c) The test establishes a cellular connection and then queries the visible-providers and
validates the response from the modem.
Page 71 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
Reference : OID_WWAN_VISIBLE_PROVIDERS – Windows drivers | Microsoft
Docs
Test Setup : The test requires a test device and a data-capable SIM card of any operator
Test parameters :
UserName : Specifies the user name to use when making a connection (optional)
System.Client.MobileBroadband.EAPSIM
GSM class of Mobile Broadband devices that support the extensible authentication protocol method for GSM Subscriber
Identity Module (EAP-SIM) must support EAP-SIM defined in RFC 4186.
Description
GSM devices that support EAP-SIM must support EAP-SIM as defined in RFC 4186.
1. TestAuthChallenge
Description : The test verifies if the AUTH_CHALLENGE feature is supported by the device and
if it is supported, it queries auth challenge and validates the response from the modem. The
test queries 3 types of authentication mechanism – AUTH SIM, AUTH AKA and AUTH AKA
PRIME. Reference : OID_WWAN_AUTH_CHALLENGE - Windows drivers | Microsoft
Docs.
Partner should familiarize themselves with following MBIM CIDs as well from the MBIM spec :
MBIM_CID_AKA_AUTH, MBIM_CID_AKAP_AUTH and MBIM_CID_SIM_AUTH
Test Setup : The test requires a test device and a data-capable SIM card of any operator
Page 72 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
Test parameters :
There are test-parameters available, but the tester can choose to keep the default values as
well for testing.
System.Client.MobileBroadband.FWComplyWithMBSpec
USB interface based GSM class of Mobile Broadband device firmware must comply with USB-IF's Mobile Broadband
Interface Model Specification.
Description
USB interface based GSM class of Mobile Broadband device firmware implementation must comply with the USB-IF's
Mobile Broadband Interface Model (MBIM) Specification. No additional IHV drivers are needed for the functionality of
the device and the device must work with Microsoft's Mobile Broadband (MB) class driver implementation.
Device firmware must also comply with the MBIM Errata* in addition to the MBIM 1.0 specification. In specific, the
following items in MBIM Errata need to be compliant with:
• MEFD (MB Extended Functional Descriptor): Devices with Operator specific firmware must report the correct
MTU size as required by the Mobile Network Operator for carrier certified devices.
*USB-IF Link that is accessible only to NCM DWG members. This errata will be published once it gets approved.
Page 73 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
Additional Details:
1. TestClassDriver
Description : This is a very simple test which validates if a USB device uses Mobile Broadband
Class Driver from Microsoft.
Test Setup : The test requires a test device and a data-capable SIM card of any operator
Test parameters :
No parameters
Description : This is a very simple test which queries device-services and validates the
response from the modem. Reference : OID_WWAN_DEVICE_SERVICES - Windows
drivers | Microsoft Docs
Test Setup : The test requires a test device and a data-capable SIM card of any operator
Test parameters :
No parameters
4. TestUSBDescriptor
Description : This test does query some basic data and validate the data has acceptable
values – some of the data it queries is :
a) Interface device info data from registry : Enumerate the device info and query for
NetCfgInstanceId
b) Check if the device is using cxwmbclass service
Page 74 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
c) Find the interface port number for the mobile broadband device
d) Find the USB hub for the mobile broadband device
Test Setup : The test requires a test device and a data-capable SIM card of any operator
Test parameters :
No parameters
System.Client.MobileBroadband.Loopback
Mobile broadband devices based on USB protocol MUST implement loopback functionality for performance and payload
conformance testing.
Description
Mobile broadband devices based on the USB protocol must implement a loopback functionality as detailed in the
specification in the device firmware. Note that Loopback functionality is only tested for the data packet as it is the one
in the performance critical path. Devices must pass the loopback test for performance requirements. Specifically,
devices must be able to support combined throughput of 100 Mbps (50 Mbps uplink / 50 Mbps downlink) or above
and up to 5% loss rate.
Links to the relevant specifications are provided in the Additional Information section below.
Additional Information:
1. TestLoopback
Page 75 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
Description : This test basically creates a loopback connection (a cellular connection with APN as “loopback”)
Any data sent to this connection is looped back to the sender by the mobile broadband device (modem).
a) This test sends some fixed amount of traffic to the loopback connection, receives the data and mentions
if there is any data-loss. The data-loss must be less than 5% for the test to pass. The test also calculates
the bandwidth and validates that it should be > 100mbps. Please note that TestLoopback is meant to
just validate the loopback functionality and is not a benchmark tool to measure the modem bandwidth
b) The test sends incremental data traffic to the loopback connection and validates data-loss and
bandwidth as mentioned above.
Test Setup : The test requires a test device and a data-capable SIM card of any operator
Test parameters :
MinDataPacketSize : Minimum size in bytes of the data packet to be used for loopback (eg : 25000)
MaxDataPacketSize : Maximum size in bytes of the data packet to be used for loopback (eg : 30000)
System.Client.MobileBroadband.SupportUSBSelectiveSuspend
USB based Mobile Broadband devices must support Windows implementation of USB selective suspend.
Description
USB based Mobile Broadband devices must support Windows implementation of USB selective suspend (SS). No
alternate USB SS implementation is allowed.
1. TestSelectiveSuspend
Description : The test blocks outbound IP traffic to verify the device enters selective suspend state. The test
will then unblock outbound traffic and verify the device comes out of selective suspend state
Page 76 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
Test Setup : The test requires a test device and a data-capable SIM card of any operator
Test parameters :
UserName : Specifies the user name to use when making a connection (optional)
System.Client.MobileBroadband.SupportWakeOnMB
Mobile broadband class of devices must support the following wake on mobile broadband capabilities.
Description
Mobile broadband class of devices must support the following wake on mobile broadband capabilities when system
power state is ModernStandby
Mobile broadband class of devices must support wake on mobile broadband. A device should wake the system on
above mentioned events. Note that wake on USSD is mandatory only if the device reports that it supports USSD;
otherwise, it is optional. See the following MSDN documentation for more information on the SMS and register state
wake events.
1. NDIS_STATUS_WWAN_REGISTER_STATE
2. NDIS_STATUS_WWAN_SMS_RECEIVE
Page 77 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
1. TestWake
Description : The test validates 3 different scenarios : Put the mobile broadband device into low-power state
(PowerState D2) and try to wake the device by incoming SMS, registerState change and incoming data
packet
a) Validate wake of the mobile broadband device by incoming SMS : This is a manual test, i.e, manual input
is needed at some point of this HLK execution. HLK first verifies that the device support AOAC, if not
skips this test. The test notifies NDIS to enter Network Quiet Mode and waits until the MBB device is in
low power state (D2). Once the device is in low power state, the HLK notifies the tester to send an SMS
to the device by this line highlighted in green background on the cmd prompt in the DUT : “Please send
Mobile Terminated SMS message to the device in 30sec”. Once the tester sees this message on the cmd
line on the Device Under Test (DUT), the tester must send an SMS to the DUT. Once the DUT receives
the SMS, HLK validates that it wakes the device and wake reason is “WwanSMSReceive”
b) Validate wake of the mobile broadband device by RegisterStateChange : This is a manual test, i.e,
manual input is needed at some point of this HLK execution. HLK first verifies that the device support
AOAC, if not skips this test. The test notifies NDIS to enter Network Quiet Mode and waits until the MBB
device is in low power state (D2). Once the device is in low power state, the HLK notifies the tester to
change its registration state by this line highlighted in green background on the cmd prompt in the DUT
: “Please trigger device to change its registration status in 600 sec”. Once the tester sees this message
on the cmd line on the Device Under Test (DUT), the tester must trigger a register state change on the
device (you can cause the registered device to deregister – which is acceptable state change). Once the
DUT changes register state, HLK validates that it wakes the device and wake reason is
“WwanRegisterState”
c) Validate wake of the mobile broadband device by IncomingDataPacket : This is a manual test, i.e,
manual input is needed at some point of this HLK execution. HLK first verifies that the device support
AOAC, if not skips this test. AT this point the test shows following line in the cmd prompt on the DUT :
“Start app (like Skype) to wait for incoming data, press enter to continue ....”. When tester sees this
displayed on DUT s/he should open an app such as microsoft teams, or skype on the DUT to receive
data. The test notifies NDIS to enter Network Quiet Mode and waits until the MBB device is in low
power state (D2). Once the device is in low power state, the HLK notifies the tester to send incoming
data to the DUT by this line highlighted in green background on the cmd prompt in the DUT : “Please
trigger incoming data request using installed app (like Skype)”. Once the tester sees this message on the
cmd line on the Device Under Test (DUT), the tester must send some IM messages to the skype account
or teams account on the DUT. Once the DUT receives this incoming message, HLK validates that it wakes
the device and wake reason is “Packet”
Test Setup : The test requires a test device and a data-capable SIM card of any operator
Test parameters :
Page 78 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
AccessString : Specifies the access string to use when making a connection
UserName : Specifies the user name to use when making a connection (optional)
System.Client.MobileBroadband.NITZ
Mobile broadband
System.Client.MobileBroadband.NITZ.Discretional
Mobile broadband devices that implement Network Identity and Time Zone (NITZ) must support the standardized
interface changes based on the Mobile Broadband Driver Model.
Terms: If-Implemented
Description
Windows Mobile Broadband Driver Model is updated to include support for getting NITZ information, containing the
date, time, time zone offset and daylight-saving offset, from the modem. If the device supports Mobile Broadband
Driver Model NITZ, the device firmware needs allow querying NITZ information and notify when the NITZ information
is updated.
1. TestNitzInfo
Description : This is a very simple test which verifies if the device supports NITZ capability. If the device
support this capability, query the mobile broadband device for NITZ info and validate the response from the
modem, Reference : OID_WWAN_NITZ - Windows drivers | Microsoft Docs
Test Setup : The test requires a test device and a data-capable SIM card of any operator
Test parameters :
No parameters
System.Client.MobileBroadband.PLDR
Mobile broadband
Page 79 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
System.Client.MobileBroadband.PLDR.Discretional
Mobile broadband devices that implement Platform Level Device Reset (PLDR) must support exchange interface based on
the Mobile Broadband Driver Model.
Terms: If-Implemented
Description
Windows Mobile Broadband Driver Model is updated to include the full support of PLDR. Mobile broadband devices
that support this feature must have ACPI updated to declare its support for PLDR and have an updated ACPI/BIOS
that supports PLDR. Once PLDR on a mobile broadband device is triggered, the device must reset according to the
specification of PLDR.
1. TestPLDR
Description : This HLK test does a platform level device reset and monitors that the interface goes away from
the bus and is available back in 50 secs.
Test Setup : The test requires a test device and a data-capable SIM card of any operator
Test parameters :
No parameters
System.Client.MobileBroadband.ModemLogging
Mobile broadband
System.Client.MobileBroadband.ModemLogging.Discretional
Mobile broadband devices that implement support for providing DSS based modemlogging must support the
standardized interface changes based on the Mobile Broadband Driver Model.
Terms: If-Implemented
Description
This requirement is very specific to modem logging based on Device Service Stream. If any modem uses the standard
DSS based modemlogging as proposed by Microsoft MBIM standards, they need to run this HLK. The feature as such
allows the device to configure the modem logging parameters such as the level of logging, segmentsize and
Page 80 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
maxFlushtime. Whenever the system initiates modemLogging, it first configures the aforementioned parameters and
then starts a DSS session, just for the logs to flow. Once the session is started, and data is available in the DSS
channel, read notifications appear in wwansvc which will have the requested log data.
1. TestModemLoggingConfig
Description : The test validates following scenarios :
a) The test queries Modem Logging Config and verifies response from the modem
b) The test sets a modem logging configuration, queries back the modem logging config and compare
loglevel to ensure that it is set correctly
c) The test sets a modem logging configuration with log level verbose and waits for 60 secs to receive logs
from modem via DSS data channel
Reference : OID_WWAN_MODEM_LOGGING_CONFIG - Windows drivers | Microsoft Docs,
OID_WWAN_DEVICE_SERVICE_SESSION - Windows drivers | Microsoft Docs,
OID_WWAN_DEVICE_SERVICE_SESSION_WRITE - Windows drivers | Microsoft Docs
If the device does not support DSS or ModemLooggingConfig feature, then the test will be skipped
Test Setup : The test requires a test device and a data-capable SIM card of any operator
Test parameters :
MaxSegmentSize : The maximum size in bytes of each log data packet from modem (eg: 1024)
MaxFlushTime : Maximum flush time in ms after which modem has to send a log packet (eg : 10000)
System.Client.MobileBroadband.LteAttach
Mobile broadband
System.Client.MobileBroadband.LteAttach.Discretional
Mobile broadband devices that implement support for LteAttach must support the standardized interface changes based
on the Mobile Broadband Driver Model.
Description
Windows Mobile Broadband Driver Model is updated to include the full support for LteAttach. Modems
implementiong LteAttach scenarios have support for both configuring the LteAttach parameters ( AccessString,
IpType, Username, password, Compression & authProtocol) as well as receiving the LteAttach Status ( LteAttachState,
AccessString, IpType, Username, password, Compression & authProtocol).
1. TestLTEAttach
Page 81 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
Description : The test verifies the following scenarios :
a) The test verifies that it can sucessfully query Lte Attach configurations on the MBB device
b) The test verifies that it can sucessfully set Lte Attach configurations on the MBB device
c) The test verifies that it can successfully query Lte Attach status
Test Setup : The test requires a test device and a data-capable SIM card of any operator which supports LTE
attach capability
Test parameters :
This test allows to configure a lot of parameters, but the tester can choose to use the default values (which
are already pre-populated)
LteSetOp : Specifies the type of operation is used for. Default overwrites existing LTE attach contexts; Reset
restores factory pre-configured contexts. [Default|Reset]
LteRoam0 : Roaming policy of the first LTE Attach context. (All three policies need to be used despite order)
[home|partner|nonpartner]
LteRoam1 : Roaming policy of the second LTE Attach context. (All three policies need to be used despite
order) [home|partner|nonpartner]
LteRoam2 : Roaming policy of the third LTE Attach context. (All three policies need to be used despite order)
[home|partner|nonpartner]
Page 82 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
System.ClientMobileBroadband.PCO
Mobile broadband
System.Client.MobileBroadband.PCO.Discretional
Mobile broadband devices that implement support for protocol configuration operations (PCO) must support the
standardized interface changes based on the Mobile Broadband Driver Model.
Terms: If-Implemented
Description
Windows Mobile Broadband Driver model is updated to include managing the cellular data connection based on the
operator specific PCO elements that is received from the network. Devices that implement PCO can optionally
support PCO based on the Mobile Broadband Driver Model.
If the device supports Mobile Broadband Driver Model PCO, the device firmware needs to support the following at
minimum:
1. TestPCO
Description : This test first establishes a cellular connection and query for PCO status from mobile broadband
device and validates the response from modem. Reference : OID_WWAN_PCO - Windows drivers | Microsoft
Docs
Test Setup : The test requires a test device and a data-capable SIM card of any operator
Test parameters :
UserName : Specifies the user name to use when making a connection (optional)
Page 83 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
System.Client.MobileBroadband.FirmwareUpdater
Mobile broadband
System.Client.MobileBroadband.FirmwareUpdater.FirmwareUpgrade
USB interface based GSM mobile broadband devices that comply with Microsoft's firmware update platform must
implement Firmware ID Device Service and an UMDF based firmware update driver for the firmware payload update to
the device.
Description
GSM mobile broadband devices that comply with Microsoft's firmware update platform must implement Firmware ID
Device Service and an UMDF based firmware update driver for the firmware payload update to the device. . Windows
Mobile Broadband Driver Model is updated to include the support for device reset and UICC reset (including modem
passthrough). UICC reset includes a flag to turn the passthrough mode on and off, upon UICC reset. In the
passthrough mode, the device will not interfere with the UICC even if the UICC appears to have no Telecom file
system. This command is designed to be used in UICC firmware update scenarios. The passthrough mode could be
set and queried.
Page 84 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
Test Setup : The test requires a test device and a data-capable SIM card of any operator
Test parameters :
No parameters
System.Client.MobileBroadband.MultiModemMultiExecutor
Mobile broadband
System.Client.MobileBroadband.DSSA.Discretional
Mobile broadband devices that implement support for multiple modem and multiple executor configurations must
support interface changes based on the Mobile Broadband Driver Model.
Description
Windows Mobile Broadband Driver model is updated to include support for modems that have multiple SIM slots.
Hardware configuration can defer between products. For example, a modem with dual SIM slots can either be dual-
SIM single active (DSSA), dual SIM dual standby (DSDS) or dual SIM dual active (DSDA).
Executor is the term Windows uses to define the physical interfaces. A modem that supports multiple SIM slots are
expected to enumerate the same number of physical interfaces as the provided executor numbers. Mobile
broadband class drives must support:
1. TestSlot
a) The test verifies that it can successfully query device’s slot mapping
b) The test verifies that it can successfully set device slot mappings on MBB device
Reference : OID_WWAN_DEVICE_SLOT_MAPPING_INFO - Windows drivers | Microsoft Docs
c) The test queries for system capabilities and for each slot, queries the state of the slot and validates the
response from modem. Reference : OID_WWAN_SLOT_INFO - Windows drivers | Microsoft Docs
Page 85 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
d) The test validates that appropriate ReadyInfo notifications are received from the modem when the test
performs SLOT_MAPPING changes
e) The test verifies support of DSSA scenarios on different MBIMEx versions (This includes
openchannel/closechannel/ retrieve ATR-info etc)
Test Setup : The test requires a test device and a data-capable SIM card of any operator
Test parameters :
No parameters
System.Client.PCContainer
Windows is moving towards a device centric presentation of computers and devices. Elements of the Windows user
interface (UI), such as the Devices and Printers folder, will show the computer and all devices that are connected to the
computer. The requirements in this section detail what is required to have the PC appear as a single object in the
Windows UI.
System.Client.PCContainer.PCAppearsAsSingleObject
Computers must appear as a single object in the Devices and Printers folder.
Description
Computers must appear as a single object in the Devices and Printers folder. Windows has a platform layer which
groups all functionality exposed by the computer into a single object. This object is referred to as the computer
device container. The computer device container must contain all of the device functions that are located physically
inside the computer chassis. This includes, but is not limited to, keyboards, touch-pads; media control/media
transport keys, wireless radios, storage devices, and audio devices. The computer device container is used throughout
the Windows platform and is visibly exposed to the user in the Devices and Printers user interface. This requirement
ensures a consistent and high quality user experience by enforcing the "one object per physical device" rule in the
Devices and Printers folder.
The computer must appear as a single device container in the Devices and Printers folder for the following reason:
• Devices and Printers will be unable to provide a logical and understandable representation of the computer to
the user. Accurate information as to which devices are physically integrated with the computer must be supplied
to support this and dependent Windows features.
Design Notes:
Windows is moving towards a device centric presentation of computers and devices. The Devices and Printers folder
will show the computer and all devices that are connected to the computer. In Devices and Printers the computer is
represented by a single icon. All of the functionality exposed by the computer will be available through this single
icon object, providing one location for users to discover devices integrated with the computer and execute specific
actions on those integrated devices. To enable this experience, the computer must be able to detect and group all
computer integrated devices (all devices physically inside the PC). This requires that computer integrated devices
properly identify themselves as integrated components. This can be achieved by indicating that the device is not
Page 86 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
removable from computer, properly configuring ACPI for the port to which the device is attached, or creating a
registry DeviceOverride entry for the device. (Note: Each bus type has different mechanisms for identifying the
removable relationship for devices attached to that bus.
To group the functionality exposed by the computer into a single device container, Windows uses information
available in the device hardware, bus driver, and system UEFI or BIOS and Windows registry. The bus type to which a
given device is attached determines the heuristic Windows applies to group that device. The whitepaper titled
"Multifunction Device Support and Device Container Groupings in Windows 7," which can be found at
http://www.microsoft.com/whdc/Device/DeviceExperience/ContainerIDs.mspx, explains the heuristic for many bus
types, including:
The Single Computer Display Object test (ComputerSingleDDOTest.exe) must be executed on the system to check if
this requirement has been met. The tool is available in Windows Lab Kit.
System.Client.RadioManagement
This feature contains requirements for buttons that control the management of any radios in a laptop or
Tablet/convertible PC. It also contains requirements for GPS radios, Near Field Proximity radios, and Bluetooth enabled
radios that do not use the Windows native Bluetooth stack.
System.Client.RadioManagement.HardwareButton
If a PC has a physical (hardware) button switch on a PC that turns wireless radios on and off, it must be software
controllable and interact appropriately with the Radio Management UI.
Description
There does not need to be a hardware button for wireless radios on Windows 10 laptops or tablet/convertible PCs. A
wireless hardware button is one of the following:
When there is a hardware button for wireless radios there must not be more than one, and it must control all the
radios present in the computer. An LED to indicate the state of the switch is optional. Please note that an LED
Page 87 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
indicating wireless status is not allowed on systems that support modern standby. If an LED is present along with the
button, it must behave as defined here:
• There must only be one LED to indicate wireless status (there must not be one LED for Bluetooth, one for Wi-Fi,
etc.).
• If the global wireless state is ON, the LED must be lit.
• When the global wireless state is OFF, the LED must not be lit.
• When the button is pressed or switch is flipped, it must send a HID message that can be consumed by the Radio
Management API.
• When the Radio Management API sends a HID message, the button or switch must receive the message and
change the state of the LED accordingly.
System.Client.RadioManagement.RadioMaintainsState
Radio maintains on/off state across sleep and reboot power cycles.
Description
The state of the wireless radio must persist across sleep, reboot, user log off, user switching and hibernate.
System.Client.RadioManagement.RadioManagementAPIHID
Wireless hardware button must communicate the change of state to the Radio Management API using HID.
Description
When the state of wireless radio switch changes, whether it is a slider A-B switch (with or without LED) or toggle
button (with or without LED), this HID-compliant hardware switch/button must expose the HID collections to be
consumed by the radio management API. Toggle button must not change the state of the device radio directly. A-B
switch can be wired directly to the radios and change their state as long as it communicates the change of state to
the Radio Management API using the HID driver and it changes the state in all radios present in the PC. The HID
usage IDs are:
Page 88 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
The collections are:
Button without LED (stateless button) – For laptops, tablets and convertibles
USAGE_PAGE (Generic Desktop) 05 01
USAGE (Wireless Radio Controls) 09 0C
COLLECTION (Application) A1 01
LOGICAL_MINIMUM (0) 15 00
LOGICAL_MAXIMUM (1) 25 01
USAGE (Wireless Radio Button) 09 C6
REPORT_COUNT (1) 95 01
REPORT_SIZE (1) 75 01
INPUT (Data,Var,Rel) 81 06
REPORT_SIZE (7) 75 07
INPUT (Cnst,Var,Abs) 81 03
END_COLLECTION C0
Button with LED – For laptops, tablets and convertibles that do NOT support modern standby
USAGE_PAGE (Generic Desktop) 05 01
USAGE (Wireless Radio Controls) 09 0C
COLLECTION (Application) A1 01
LOGICAL_MINIMUM (0) 15 00
LOGICAL_MAXIMUM (1) 25 01
USAGE (Wireless Radio Button) 09 C6
REPORT_COUNT (1) 95 01
REPORT_SIZE (1) 75 01
INPUT (Data,Var,Rel) 81 06
REPORT_SIZE (7) 75 07
INPUT (Cnst,Var,Abs) 81 03
USAGE (Wireless Radio LED) 09 C7
REPORT_SIZE (1) 75 01
OUTPUT (Data,Var,Rel) 91 02
REPORT_SIZE (7) 75 07
OUTPUT (Cnst,Var,Abs) 91 03
END_COLLECTION C0
Slider Switch with LED- Laptops, tablets and convertibles that do NOT support modern standby
USAGE_PAGE (Generic Desktop) 05 01
USAGE (Wireless Radio Controls) 09 0C
COLLECTION (Application) A1 01
LOGICAL_MINIMUM (0) 15 00
LOGICAL_MAXIMUM (1) 25 01
USAGE (Wireless Radio Slider Switch) 09 C8
REPORT_COUNT (1) 95 01
REPORT_SIZE (1) 75 01
INPUT (Data,Var,Abs) 81 02
REPORT_SIZE (7) 75 07
INPUT (Cnst,Var,Abs) 81 03
USAGE (Wireless Radio LED) 09 C7
REPORT_SIZE (1) 75 01
OUTPUT (Data,Var,Rel) 91 02
REPORT_SIZE (7) 75 07
OUTPUT (Cnst,Var,Abs) 91 03
END_COLLECTION C0
LED Only (No button or slider) - Laptops, tablets and convertibles that do NOT support modern standby
USAGE_PAGE (Generic Desktop) 05 01
USAGE (Wireless Radio Controls) 09 0C
COLLECTION (Application) A1 01
LOGICAL_MINIMUM (0) 15 00
LOGICAL_MAXIMUM (1) 25 01
USAGE (Wireless Radio LED) 09 C7
REPORT_COUNT (1) 95 01
REPORT_SIZE (1) 75 01
OUTPUT (Data,Var,Rel) 91 02
REPORT_SIZE (7) 75 07
OUTPUT (Cnst,Var,Abs) 91 03
END_COLLECTION C0
Wireless radio LED must have a HID-compliant driver to reflect the state of the airplane mode switch located in the
user interface. Wireless radio LED only uses HID for output (no input since there is no button).
When the Radio Management API sends a HID message because the global wireless state (airplane mode) has
changed, the switch must consume this message and toggle the state.
For an A-B switch, the manufacturer's proprietary embedded controller must report the correct state of the switch at
all times by sending a HID message to the HID driver, including every time the PC is turned on back on. Reporting the
state of the A-B switch when the computer is turned back on is especially important in the case that the switch
Page 90 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
changed states while the PC was in states S3/S4/S5.
System.Client.RadioManagement.ConnectedStandby
This feature contains requirements for buttons that control the management of any radios in a laptop or
Tablet/convertible PC. The radios that this requirement applies to are GPS.
System.Client.RadioManagement.ConnectedStandby.NoRadioStatusIndicatorLights
Systems that support Modern Standby must not include a light indicating the status of the radios in the system.
Description
In order to conserve energy, systems that support modern standby cannot include a status indicator indicating
whether the radios are on.
System.Client.Sensor
System.Client.Sensor.HumanPresence.SystemLevel
Human presence proximity sensors must meet all device level requirements after being integrated.
Applies to Windows 11 Client x64
Windows 11 Client ARM64
Description
Human presence sensors must meet all requirements under the
Device.Input.Sensor.ProximitySensor.HumanPresence.* namespace after being integrated into a system or peripheral.
System.Client.Sensor.HumanPresence.PhysicalDeviceLocation
Sensors should report their physical location on the device.
Applies to Windows 11 Client x64
Windows 11 Client ARM64
Description
Human presence sensors must report their physical location (e.g. ACPI PLD).
System.Client.Sensor.Accelerometer
System.Client.Sensor.Accelerometer.Shake
If an accelerometer supports shake event, then it must report the HasShake data field
Description
Accelerometers are not required to support shake detection. If an accelerometer does support shake detection, then
the HasShake data field is required to be reported. It is up to the OEM/IHV to determine what constitutes a shake
event. For more information, see accelerometer data fields.
System.Client.Sensor.Accelerometer.EnumerationProperties
Accelerometer must support the correct enumeration properties
Description
Accelerometer must report DEVPKEY_Sensor_ConnectionType even though this is not a required enumeration
property for some other sensors.
System.Client.Sensor.ActivitySensor
System.Client.Sensor.ActivitySensor.EnumerationProperties
Activity sensors are required to report supported activity types and minimum detection interval through enumeration
properties
Description
Page 92 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
System.Client.Sensor.AmbientLightSensor
System.Client.Sensor.AmbientLightSensor.AutoBrightnessPreferred
If an ambient light sensor is used for autobrightness, then it must be properly tagged in PnP
If an ambient light sensor is intended to be used with the autobrightness feature, then the following enumeration
property is required to be reported:
System.Client.Sensor.AmbientLightSensor.ColorCalibration
Ambient light sensors that support color capable must be properly calibrated
Description
Ambient light sensors are no required to support color. If an ambient light sensor does support color, then it is
required to be properly calibrated while a light source is aimed directly at the sensor:
- The detected ambient lux is either within 10% or 1 lux of the actual incoming light
- The detected chromaticity x and y are within 0.025 of the actual incoming light
System.Client.Sensor.AmbientLightSensor.EnumerationProperties
Ambient Light Sensor must support the correct enumeration properties
Description
An ambient light sensor must report DEVPKEY_Sensor_ConnectionType even though this is not a required
enumeration property for some other sensors.
Page 93 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
System.Client.Sensor.AmbientLightSensor.IsValid
Ambient light sensors that report the IsValid data field must properly indicate when data is valid.
Ambient light sensors are not required to report when light sensor samples are valid or not. If an ambient light sensor
does support this though, then the follow requirements must be met:
If this value changes, a sample must be reported regardless of if the thresholds have been met. See below for
examples:
• If the last reported sample was 100 lux and the next sample is 100 lux, but the sensor is now blocked (previous
sample's PKEY_SensorData_IsValid was true):
o The current sample would get reported with 100 lux and PKEY_SensorData_IsValid set to false.
• The last reported sample was 100 lux and was blocked (previous sample's PKEY_SensorData_IsValid was
false). The next sample is 100000 lux and the sensor is still blocked (PKEY_SensorData_IsValid is false):
o No sample is reported
• The last reported sample was 0 lux and was blocked (previous sample's PKEY_SensorData_IsValid was false).
The next sample is still 0 lux, but the sensor is now unblocked (PKEY_SensorData_IsValid is true):
o The current sample would get reported as 0 lux but with PKEY_SensorData_IsValid set to true.
System.Client.Sensor.AmbientLightSensor.LightCalibration
Ambient light sensor that don’t support color must be properly calibrated to report within 4% or at least 1 lux of the
actual incoming light level.
The autobrightness service needs light sensors to report an accurate measurement of the light level in the
environment. When the light source is aimed directly at a light sensor that doesn’t support color, the reported light
level is required to be within 4% or at least 1 lux of the actual incoming light level.
System.Client.Sensor.AmbientLightSensor.LightRange
Ambient light sensors are required to be able to detect a minimum of 1 lux and up to 10,000 lux
Page 94 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
Windows 11 Client ARM64
Description
The autobrightness service in Windows needs to be able to detect a reasonable range of light levels from 1 to 10,000
lux. If the range is smaller than this, then the adjusted autobrightness may not be able to match the actual brightness
of the environment.
System.Client.Sensor.CustomSensor
System.Client.Sensor.CustomSensor.EnumerationProperties
Custom sensors are required to report sensor name as an enumeration property.
Description
System.Client.Sensor.General.EnumerationProperties
Sensors are required to report the expected properties via PnP
Description
Page 95 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
The required enumeration properties for all sensors are shown below:
System.Client.Sensor.General.OptionalEnumerationProperties
Sensors can optionally report some enumeration properties
Description
The optional enumeration properties for all sensors are shown below:
System.Client.Sensor.General.OptionalProperties
Sensors can optionally report some sensor properties
Page 96 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
Windows 11 Client ARM64
Description
System.Client.Sensor.General.Properties
Sensors are required to report the expected sensor properties
Description
The required sensor properties for all sensors are shown below:
1Foractivity detection sensors, this value must be the maximum over the minimum detection intervals for the
supported activities.
Page 97 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
System.Client.Sensor.General.Wake
Sensors that support wake must be capable of waking the system from connected standby and S3
Description
Sensors are not required to support wake. If a sensor does support wake, then it is required to be able to wake the
system from connected standby and S3. Additionally, the sensor must report PKEY_Sensor_WakeCapable as true and
also implement the wake DDI.
System.Client.Sensor.Gyrometer
System.Client.Sensor.Gyrometer.DynamicRange
Gyrometers are required to have a dynamic range of ±720 degrees per second or more
Description
Gyrometers are required to have a sufficiently large dynamic range of ±720 degrees per second. The recommended
dynamic range is ±2000 degrees per second or more.
System.Client.Sensor.General
System.Client.Sensor.General.ConnectionType
Sensors must correctly report their connection type to the system
Description
Sensors should report the correct connection type, for more information see below.
Sensor connection type is reported through the DEVPKEY_Sensor_ConnectionType enumeration property and may
have one of three values:
Page 98 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
SensorConnectionType_Integrated = 0,
SensorConnectionType_Attached,
SensorConnectionType_External
} SENSOR_CONNECTION_TYPES;
Where:
Constant Definition
SensorConnectionType_Integrated The sensor is built into the system.
The sensor is attached to the computer, such as
SensorConnectionType_Attached
through a peripheral device.
The sensor is connected by external means, such as
SensorConnectionType_External
through a network.
System.Client.Sensor.General.MaximumMeasuringLatency
Sensors must promptly report reading changes
Description
Sensors should promptly report reading changes. For example, non-color capable ambient light sensors must report a
change in ambient light within 250 milliseconds of the ambient light actually changing. The table below shows the
timing requirements per sensor:
For sensors that aren’t listed, there is no exact timing required. However, the measuring latency should still be
reasonable.
“Warm up” is defined as the time between when EvtSensorStart is called and the first sample is reported.
System.Client.Sensor.General.OEMSettings
If a device implements an OEM setting related to sensors, then the setting must be of the correct type and value
Description
If a device implements an OEM setting related to sensors, then they must be of the correct type and the value must
be in the correct range. More information about the OEM settings can be found under the “Registry Settings” section
of the Ambient Light Sensor Integration document.
Page 99 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
System.Client.Sensor.General.PhysicalDeviceLocation
Sensors should report their physical location on the device
Description
If there is more than one sensor of the same type on a device, the physical location of those sensors must be reported
(e.g. through ACPI PLD). The hinge and fold gesture sensors must always report their physical device location even if
there’s only one on the system.
System.Client.Sensor.General.PowerState
Sensors must be in a lower power state when not under use
Description
A sensor must enter low power state when there are no clients connected.
System.Client.Sensor.General.StableReading
Sensors must provide a stable sensor reading if there is no change in sensor stimulus
Description
Sensors are required to provide a stable sensor reading if there is no change in sensor stimulus. For example, an
ambient light sensor should report a constant light sensor reading if the lighting environment does not change.
System.Client.Sensor.Magnetometer
System.Client.Sensor.Magnetometer.DynamicRange
Magnetometers are required to have a dynamic range of ±1000 µT or more
Magnetometers are required to have a sufficiently large dynamic range of ±1000 µT or more.
System.Client.Sensor.Orientation
System.Client.Sensor.Orientation.GyrometerPresent
Orientation sensors can optionally report if a gyroscope is used.
Description
System.Client.Sensor.Pedometer
System.Client.Sensor.Pedometer.EnumerationProperties
A Pedometer are required to report the supported step types and minimum detection interval to PnP
Description
System.Client.Sensor.ProximitySensor
System.Client.Sensor.ProximitySensor.EnumerationProperties
A proximity sensor is required to report Proximity Type (Object Proximity or Human Proximity) as an enumeration
property.
Description
System.Client.Sensor.HumanPresence
System.Client.Sensor.HumanPresence.SystemLevel
Human presence proximity sensors must meet all device level requirements after being integrated.
Applies to Windows 11 Client x64
Windows 11 Client ARM64
Description
Human presence sensors must meet all requirements under the Device.Input.Sensor.HumanPresence.* namespace
after being integrated into a system or peripheral.
System.Client.Sensor.HumanPresence.PhysicalDeviceLocation
Sensors should report their physical location on the device.
Applies to Windows 11 Client x64
Windows 11 Client ARM64
Description
Human presence sensors must report their physical location (e.g. ACPI PLD).
System.Client.Sensor.SimpleDeviceOrientation
System.Client.Sensor.SimpleDeviceOrientation.PhysicalLocation
If a system has more than one simple device orientation sensor integrated into the system, then the simple device
orientation sensors must report their physical location on the system
Description
If there is more than one simple orientation sensor integrated into a system, then all simple device orientation sensors
on the system must have their locations marked using ACPI PLD.
Description
For all other Windows 10 systems, the table below lists the minimum required components to be
present in a system in order for it to be compatible for Windows 10. All components must meet the
compatibility requirements and pass device compatibility testing for Windows 10.
Graphics GPU Minimum of Direct3D 10 Feature Level 9_3 and see System.Fundamentals.Graphics.WDDM
System.Client.SystemImage
The requirements in this section describe the level two quality of HW + SW + OEM image
System.Client.SystemImage.SystemRecoveryEnvironment
System includes Windows Recovery Environment on a separate partition.
Description
A system must include a separate partition with a bootable Windows Recovery Environment image file (winre.wim).
The GPT partition should be of type PARTITION_MSFT_RECOVERY_GUID, includes the
System.Client.SystemPartition
The requirements in this section describe the PC system partition configuration requirements.
System.Client.SystemPartition.DiskPartitioning
Systems that ship with a Windows operating system must meet partitioning requirements.
Description
Windows systems must ship with an active system partition in addition to the operation system partition (configured
as Boot, Page File, Crash Dump, etc.). This active system partition must have at least 250 MB of free space, above and
beyond any space used by required files. This additional system partition can be used to host Windows Recovery
Environment (RE) and OEM tools (provided by the OEM), so long as the partition still meets the 250 MB free space
requirement.
Implementation of this partition allows support of current and future Windows features such as BitLocker, and
simplifies configuration and deployments.
Tools and documentation to implement split-loader configuration can be found in Windows OEM Preinstallation
Kit/Automated Installation Kit (OPK/AIK).
System.Client.SystemPartition.OEMPartition
Windows systems with recovery & OEM partitions must meet partitioning requirements.
Description
If a system includes a separate partition for recovery purposes or an OEM partition for any other purpose, this
separate partition must be identified with the GPT_ATTRIBUTE_PLATFORM_REQUIRED attribute. This attribute is
defined as part of the PARTITION_INFORMATION_GPT (http://msdn.microsoft.com/en-
us/library/aa365449(VS.85).aspx) structure.
• If this separate partition includes a bootable Windows Recovery Environment image file, the GPT partition must
be of type PARTITION_MSFT_RECOVERY_GUID and include the GPT_ATTRIBUTE_PLATFORM_REQUIRED attribute.
Partitions which are identified with the GPT_ATTRIBUTE_PLATFORM_REQUIRED attribute must not be used for storing
user data (such as through data backup, for example).
System.Client.ScreenRotation
System.Client.ScreenRotation.SmoothRotation
Systems with accelerometers perform screen rotation in 300 milliseconds and without any video glitches.
Description
All Windows systems with an accelerometer must have sufficient graphics performance to meet performance
requirements for screen rotation:
• A WDDM driver is required to enumerate source modes for the integrated display. The WDDM driver must
support rotated modes (0, 90, 180 and 270) for every mode that it enumerates for the integrated panel.
• The rotation is required to be supported even if the integrated panel is in a duplicate or extended topology with
another display device. For duplicate mode, it is acceptable to rotate all targets connected to the rotated source.
Per path rotation is allowed but not required.
Both the above mentioned requirements are optional for Stereo 3D capable resolutions.
System.Client.Tablet.Graphics
System.Client.Tablet.Graphics.SupportAllModeOrientations
Graphics drivers on Tablet systems are required to support all mode orientations.
Graphics drivers on tablet systems are required to support all mode orientations for every resolution enumerated for
the integrated panel:
• A graphics driver is required to enumerate source modes for the integrated display. For each source mode
enumerated the graphics driver is required to support each orientation (0, 90, 180 and 270).
• Each orientation is required even if the integrated panel is in a duplicate or extended topology with another
display device. For duplicate mode, it is acceptable to rotate all targets connected to the rotated source. Per path
rotation is allowed but not required.
Both the above mentioned requirements are optional for Stereo 3D capable resolutions.
System.Client.WLAN.BasicConnectivity
System.Client.WLAN.BasicConnectivity.WlanBasicConnectivity
Applies to Windows 11 Client x64
Description:
If present WLAN allows for untethered connectivity to networks allowing for a wide range of scenarios such as
browsing the web or streaming video content. When present the WLAN device must support, at a minimum,
connecting to a WPA2 psk AES ap and all associated actions to enable making that connection. This includes the
following:
• Scanning for available networks
• Device Enumeration
• Capabilities check
• Radio on / off
• Querying interface properties
• Connecting to a WPA2 PSK AES ap in the specified time as stated in the Windows 10 WLAN Requirements
Timing for the above actions can be found in the Windows 10 WLAN Device requirements.
Microsoft highly recommend WLAN hardware module to support at least 802.11ac 2x2 configuration/design. This
recommendation may become a requirement for the future release of the Windows Hardware Compatibility Program
at Microsoft's discretion
Terms: If-Implemented
Description:
Wi-Fi device firmware has been known to hang and / or get in a stuck state. Once that happens, the Lower Edge
driver would either crash causing a 9F (Blue Screen) or the Wi-Fi subsystem gets into a state which requires a system
reboot for the device to be functional again. In either case, the user is faced with a negative experience in their
connectivity and their general system usage is disrupted. As an integral part of WDI, we have designed a mechanism
to detect when the firmware gets into these states and recover the device seamlessly. This will ensure that user will
see a minimal disruption in service by ensuring that the Wi-FI device stack recovers and resumes connectivity to the
network without the system needing a reboot. Devices must report support for Hang Detection and Recovery in
WDI_GET_ADAPTER_CAPABILITIES. Please refer to the WDI Spec for implementation details.
System.Client.WLAN.HostedNetwork
System.Client.WLAN.HostedNetwork.WlanHostedNetwork
Applies to Windows 11 Client x64
Terms: If-Implemented
Description:
With this feature, a Windows computer can use a single physical wireless adapter to connect as a client to a hardware
access point (AP), while at the same time acting as a software AP allowing other wireless-capable devices to connect
to it.
Terms: If-Implemented
Description:
Support for Wi-Fi Direct by the Wi-Fi Driver to enable Miracast, Public APIs for Wi-Fi Direct to allow pairing to & from
the PC, Accepting and Connecting to other Wi-Fi Direct Device for the GO & the Client Role. This includes support for
concurrent operation over Wi-Fi Direct & Station.
System.Client.WLAN.Miracast
System.Client.WLAN.Miracast.WlanMiracast
Applies to Windows 11 Client x64
Terms: If-Implemented
Description:
Miracast requires both WiFiDirect support in the WLAN Adapter and support in the Graphics driver. Miracast allows
the user to extend their display to a Miracast supported sync device.
System.Fundamentals.DebugPort
The ability to debug a system is crucial to supporting customers in the field and root-causing behavior in the
kernel. Requirements in this area support the ability to kernel debug a Windows system.
System.Fundamentals.DebugPort.SystemExposesDebugInterface
System exposes debug interface that complies with Debug Port Specification.
Windows 11 supports several different debug transports. They are listed below in the preferred order of
implementation.
• Ethernet Network Interface Card from the supported list: Supported Ethernet NICs for Network Kernel Debugging
in Windows 11 - Windows drivers | Microsoft Docs
ADDITIONAL REQUIREMENTS
FOR ALL OF THE ABOVE IMPLEMENTATIONS THE FOLLOWING MUST APPLY:
• There must be at least one user accessible debug port on the machine. It is acceptable on systems which choose
to not expose a USB port or any other acceptable port from the list above to instead require a separate
debugging board or device that provides the ability to debug via one (or more) of the transports above. That
device/board must terminate in the same standard port as would be used for the transport if it were ‘onboard’
the machine. If this device is required it must be documented in the system specifications, be user serviceable, be
user installable on the machine, and available for sale from the machine’s vendor.
• On retail PC platforms, it is strongly recommended that machines have 2 user accessible debug ports from the
above list. The secondary debug port is required to debug scenarios where the first debug port is in use as part
of the scenario. Microsoft is not responsible for debugging or servicing issues which cannot be debugged on the
retail platform, or reproduced on development platforms.
• SoC development or prototype platforms provided to Microsoft for evaluation must have a dedicated debug port
available for debugging. If the debug port is used for any scenarios that are expected to also be used on retail
shipping devices, in that case, there must be a secondary debug port available for debugging. This is to ensure
that SoC development platforms can be used to test and debug all scenarios for all available transports, including
USB host and function.
• All debug device registers must be memory or I/O mapped. For example, the debug device must not be
connected behind a shared bus such as SPI or I2C. This would prevent other devices on the same bus from being
debugged.
• When enabled, the debug device shall be powered and clocked by the UEFI
System.Fundamentals.EnergyEstimation
There are currently three energy micro-benchmark tests in the HLK including primary storage, network, and primary
display. These benchmarks are targeted to execute on any battery powered device. While in execution, the
benchmarks emulate a set of steady state workloads of a particular component. At the same time, they also observe
the battery drain.
• The battery must be nearly fully charged before executing a benchmark. A benchmark usually has multiple
assessments. Before an assessment starts, the benchmark will estimate the expected runtime. If the remaining
battery life duration is less than the time estimate required for executing the entire assessment, then the
execution will immediately stop with an error message.
• Also note that some devices don’t have a battery drain report correctly when it is at 100% capacity. Make sure
it is less than or equal to 99% battery capacity remaining before executing a benchmark.
• Display benchmark requirements:
Display benchmark tests the battery drain during different brightness settings. Therefore the device has to be able to
adjust the brightness level through software control.
o Open a command window as administrator
o Run the following commands to see if the brightness changes:
▪ powercfg /setacvalueindex scheme_current sub_video aded5e82-b909-4619-9949-
f5d71dac0bcb 10
▪ powercfg /setdcvalueindex scheme_current sub_video aded5e82-b909-4619-9949-
f5d71dac0bcb 10
▪ powercfg /setactive scheme_current
o If the brightness doesn’t change, then the device is not suitable for this benchmark test.
• Network benchmark requirements: None
• Storage benchmark requirements:
Storage benchmark needs to setup a fake drive get the baseline power.
▪ This step needs the system with testsigning on and WTT service enabled. Once the test machine is set
up through HLK controller, these should be automatically set up.
▪ Open a command window as administrator, and cd to the folder of e3hlk\storhba. The storhba folder
can also be found in <controller-name>\Tests\<processor architecture>\e3hlk.
▪ cscript Scripts\Install_Storhba.wsf /storhba:1 /TestParameter:6 /LogicalUnitDiskSizeInMB:4096
/PhysicalLuns:1
▪ Diskmgmt.msc (to open disk management).
▪ Find the new disk with 4GB size.
▪ Initialize the disk using MBR partition style.
System.Fundamentals.Firmware
System.Fundamentals.Firmware.ACPI
ACPI System Requirements
Description
DSDT Requirements
As per ACPI 4.0a, all devices in the ACPI namespace must include:
• If any devices in the namespace share the same Hardware ID, then each is required to have a distinct Unique
Identifier (_UID object).
• If any device in the namespace is enumerated by its parent bus (Plug and Play buses), the address of the device
on its parent bus (_ADR object) is required.
• If any device in the namespace is compatible with a Microsoft-provided driver, the Compatible ID (_CID object)
defined for that device type is required.
GPIO Controllers for pins used by Windows drivers or ASL control methods must appear as devices in the ACPI
namespace.
Devices in the namespace that are connected to GPIO pins on an enumerated controller device must:
• Include GPIO IO Connection resource descriptors in their _CRS for any GPIO I/O pins connected. Include GPIO
Interrupt Connection resource descriptors in their _CRS object for any GPIO interrupt pins connected.
Simple Peripheral Bus (SPB) on any System that supports Modern Standby
SPB Controllers for connections used by Windows drivers or ASL control methods must appear as devices in the ACPI
Page 112 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
namespace.
Devices in the namespace that are connected to an enumerated SPB controller device (UART, I2C, SPI) must include
SPB Connection resource descriptors in their _CRS for the SPB Connection(s) used.
Power Button
The power button, whether implemented as an ACPI Control Method Power Button or as part of the Windows-
compatible Button Array, must:
Systems dependent on built-in (or connected) keyboards/mice for input must conform to the ACPI Control Method
Power Button (Section 4.7.2.2.1.2 of the ACPI 4.0a Specification). In addition, systems that support modern
standby must:
• Implement the ACPI Control Method Power Button (Section 4.7.2.2.1.2 of the ACPI 4.0a Specification) using a
dedicated GPIO interrupt pin to signal button press events.
• Configure the power button's GPIO interrupt pin as a non-shared, wake-capable (ExclusiveAndWake) GPIO
interrupt connection resource.
• List the Power Button's GPIO interrupt connection resource in the ACPI Event Information (_AEI object) of the
GPIO controller device to which it is connected.
• Provide the event method (_Lxx or _Exx object) for the power button event under the GPIO controller device in
the ACPI namespace.
NOTE: For systems that require a separate driver to handle power button presses, it is acceptable to have that driver
evaluate a control method that performs a Notify(
) on the Control Method Power Button device instead of using the GPIO-based solution above.
All battery-powered systems which are not capable of supporting Modern Standby are required to implement the
Alarm capabilities of the ACPI Time and Alarm control method device.
Any system that supports Modern Standby that sets the "CMOS RTC Not Present" bit in the IAPC_BOOT_ARCH flags
field of the FADT must implement the device's Time capabilities.
System.Fundamentals.Firmware.FirmwareSupportsBootingFromDVDDevice
System firmware supports booting from DVD device as defined by the El Torito specification
Applies to
Description
The system firmware must support booting the system DVD if the system includes a DVD. The system firmware or
option ROM must support the No-Emulation mode in the "El Torito" Bootable CD-ROM Format Specification, Version
1.0, for installing Windows® from optical media, such as bootable DVD media. The primary optical device must be
bootable. This requirement applies to the primary optical storage and the primary bus to which the device is attached.
System.Fundamentals.Firmware.FirmwareSupportsUSBDevices
System firmware provides USB boot support for USB keyboards, mouse, and hubs
Applies to
Description
If the system includes support for USB keyboards and pointing devices, then the system firmware must: Support USB
keyboards and pointing devices during system boot, resume from hibernate, and operating system setup and
installation.
Support USB input devices at least three levels of physical hubs below the host controller.
Support composite input devices by the boot protocol as defined in HID.
For Windows Server systems, it is acceptable to enumerate, but not initialize all devices. If the device is accessed, it
must be fully initialize before proceeding.
The USB controller and USB devices must be fully enumerated when:
• Anything other than the Windows Boot Manager is at the top of the system boot order
• A boot next variable has been set to boot to something other than the Windows Boot Manager
• On a system where the Windows Boot Manager is at the top of the list, an error case has been hit, such
that the firmware fails over from the Windows Boot Manager to the next item in the list
• Resuming from hibernate, if the system was hibernated when booted from USB
• Firmware Setup is accessed.
Description
This requirement limits the amount of memory that is reserved by the hardware (including drivers or firmware) and
not available to the OS or user applications on a system. Taking into consideration the changes required to meet this
requirement, it will be introduced in a phased manner. <=2GB systems – max of 3% + 25MB of 2GB (86.5MB)
Design Notes:
• Hardware memory reservation is computed as the difference between the physical memory that is mapped as
visible to the Windows OS (excluding all device/firmware reservations) compared to the installed RAM on the
machine.
Installed memory is queried via Query GetPhysicallyInstalledSystemMemory() and OS visible memory is queried via
GlobalMemoryStatusEx() – ullTotalPhys.
System.Fundamentals.Firmware.HSTI
The Hardware Security Testability Interface provides a standardized mechanism for reporting the results of Security
Configuration Self-Tests
Mandatory: Effective July 28, 2018, Systems must implement and accurately report the results of HSTI 1.1a or greater.
System.Fundamentals.Firmware.NoExternalDMAOnBoot
All external DMA ports must be off by default until the OS explicitly powers them through related controller(s).
Description
The firmware must protect physical memory from unauthorized DMA. Refer to the "Windows DMA Protection
Specification" for details.
System.Fundamentals.Firmware.UEFIBitLocker
A system with TPM that supports wired LAN in pre-OS must support the UEFI 2.3.1 EFI_DHCP4_PROTOCOL protocol and
the UEFI 2.3.1 EFI_DHCP6_PROTOCOL (and the corresponding service binding protocols).
Description
Systems which support TPM and wired LAN networking must support EFI_DHCP4_protocol,
EFI_DHCP4_SERVICE_BINDING_PROTOCOL, EFI_DHCP6_protocol, and EFI_DHCP6_SERVICE_BINDING_PROTOCOL for
wired LAN as defined in UEFI 2.3.1.
At pre-boot, BitLocker must be able to discover its Network Unlock provider on a Windows Deployment Server (WDS)
via DHCP, and unlock the OS volume after retrieving a secret from WDS.
Details
All UEFI systems with TPM present and a wired LAN port must support BitLocker Network Unlock . This requires full
DHCP support for wired LAN during preboot through a UEFI DHCP driver. Specifically, there must be UEFI driver
implementations for EFI_DHCP4_protocol, EFI_DHCP4_SERVICE_BINDING_PROTOCOL , EFI_DHCP6_protocol, and
EFI_DHCP6_SERVICE_BINDING_PROTOCOL for wired LAN, as defined in UEFI 2.3.1.
Description
UEFI systems must allow the Operating System to create both generic and device specific boot entries with
Messaging Device path, specifically USB Class Device Path (UEFI version 2.3 main specification section 9.3.5.9). The
firmware must respect these settings and not modify them once the OS has changed them. Furthermore, the firmware
must accurately report the boot entries to the OS.
Functional Notes:
If the device corresponding to a boot entry is not found, it is preferable for the system to proceed to the next boot
entry silently (without presenting an error message or requiring user intervention).
If the system is booted from an internal USB device and there is a USB class entry at the top of the boot order, the
system should first attempt to boot from external USB devices before attempting internal USB boot devices.
Design Notes:
The UEFI specification requires that the software bootmanager be allowed to do the boot order programming (UEFI v.
2.3 Section 3.1.1 "Boot Manager Programming").
The firmware should interpret load options and device paths as specified in Section 9 "Protocols - Device Path
Protocol."
The UEFI specification describes the variables that must be modifiable at runtime in Section 3.2, table 10.
The UEFI specification is available at http://www.UEFI.org.
System.Fundamentals.Firmware.UEFICompatibility
System firmware must meet Windows Compatibility requirements.
Description
All systems which ship with a UEFI-compatible OS must be compatible with the following sections of the UEFI 2.3.1
specification:
2.3, 3.1, 4.3, 6.1 ~ 6.5, 7.1~7.5, 8.1, 8.2, 9.1, 9.5, 11.2 ~ 11.4, 11.8, 11.9, 12.4, 12.7, 12.8, 12.9, 18.5, 21.1, 21.3, 21.5,
If the system includes any device which has a UEFI driver that uses run-time memory after the operating system
boots, then a Memory Attributes Table must be included. The Memory Attributes Table must conform to the format
described in the UEFI 2.6 specification version, unless the version of the system's UEFI implementation is a later
revision, in which case the Memory Attributes Table must use the format specified for that version.
All Windows systems must boot in UEFI mode by default. Other requirements may add additional sections of
compatibility to this list, but this is the baseline.
All systems, except servers, must be certified in UEFI mode without activating CSM. If a system is available with 32bit
and/or 64bit UEFI, both configurations must be tested for certification.
OEMs may ship with CSM mode activated and the enterprise or government customer's licensed OS selection when
requested.
System.Fundamentals.Firmware.UEFIDefaultBoot
All client systems must be able to boot into UEFI boot mode and attempt to boot into this mode by default.
Description
The System firmware must be able to achieve UEFI mode boot by default. Such a system may also support fallback to
legacy BIOS mode boot for deploying OS images which do not support UEFI, if the user explicitly selects that option
in the pre-boot UEFI BIOS menu.
System.Fundamentals.Firmware.UEFILegacyFallback
System firmware must not fall back to legacy BIOS mode without explicit user action.
If the system ships with a UEFI-compatible OS, system firmware must be implemented as UEFI and it must be able to
achieve UEFI boot mode by default. Such a system may also support fallback to legacy BIOS boot on systems with OS
which do not support UEFI, but only if the user selects that option in a pre-boot firmware user interface. Legacy
option ROMs also may not be loaded by default.
"Explicit User Action" means that end user (or in case of enterprise customer, the IT pro) must manually access the
pre-boot firmware configuration screen and change the setting. It may not ship in the BIOS mode by default and
programmatic methods which can be attacked by malware are not acceptable.
All systems with Class 2 UEFI must not fall back to legacy BIOS mode nor load legacy Option ROM's without explicit
user action within the pre-boot UEFI configuration UI."
An OEM may not ship a 64 bit system which defaults to legacy BIOS or loads legacy option ROMs if that system ships
with a UEFI-compatible OS.
When Secure Boot is Enabled, Compatibility Support Modules (CSM) must NOT be loaded. Compatibility Support
Modules are always prohibited on systems that support modern standby.
System.Fundamentals.Firmware.UEFISecureBoot
All client systems must support UEFI Secure boot.
Description
1. Secure Boot must ship enabled with minimum of UEFI 2.3.1 Errata C.
2. For the purposes of UEFI Secure Boot, the platform shall expose an interface to Secure Boot, whereby the system
firmware is compliant with the following sections and sub-sections of UEFI version 2.3.1 Errata C:
• 7.1
• 7.2
• 7.2.1
• 27.2
• 27.5 - 27.8 (as further profiled below).
3. UEFI Version 2.3.1 Errata C variables must be set to SecureBoot=1 and SetupMode=0 with a signature database
(EFI_IMAGE_SECURITY_DATABASE) necessary to boot the machine securely pre-provisioned, and include a PK that is set
and a valid KEK database. The system uses this database to verify that only trusted code (for example: trusted signed
boot loader) is initialized, and that any unsigned image or an image that is signed by an unauthorized publisher does
not execute. The contents of the signature database are determined by the OEM, based on the required native and
third- party UEFI drivers, respective recovery needs, and the OS Boot Loader installed on the machine. The following
Microsoft-provided EFI_CERT_X509 signature shall be included in the signature database: "CN=Microsoft Windows
Production PCA 2011" and "Cert Hash(sha1): 58 0a 6f 4c c4 e4 b6 69 b9 eb dc 1b 2b 3e 08 7b 80 d0 67 8d" which shall
Page 119 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
use the following SignatureOwner GUID: {77fa9abd-0359-4d32- bd60-28f4e78f784b}, must also be included in the form
of either an EFI_CERT_X509_GUID or EFI_CERT_RSA2048_GUID type:
• Note: Must NOT contain the following certificate: "CN=Microsoft Windows PCA 2010" and "Cert Hash(sha1):
c0 13 86 a9 07 49 64 04 f2 76 c3 c1 85 3a bf 4a 52 74 af 88"
• Note II: Systems which have the Windows Server operating system pre-installed must have Secure Boot
enabled. Systems which are intended to have Windows Server operating system installed by the end
Customer, and thus do NOT have the Windows Server operating system pre-installed, may ship with Secure
Boot disabled, but all other provisions of this sub-requirement must be met
4. When Secure Boot is Enabled, Compatibility Support Modules (CSM) must NOT be loaded.
5. The initial UEFI signature databases (db) shall be created with the
EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS attribute stored in firmware flash and may be updated
only with an OEM-signed firmware update or through UEFI authenticated variable write.
6. Support for the UEFI "forbidden" signature database (EFI_IMAGE_SECURITY_DATABASE1) must be implemented.
7. The platform shall ship with a "forbidden" signature database (EFI_IMAGE_SECURITY_DATABASE1) created with the
EFI_VARIABLE_TIME_BASED_AUTHENTICATED_ACCESS attribute. When a signature is added to the forbidden signature
database, upon reboot, any image certified with that signature must not be allowed to initialize/execute.
8. Secure Boot must be rooted in a protected or ROM-based Public Key. Secure Boot must be rooted in an RSA public key
with a modulus size of at least 2048 bits, and either be based in unalterable ROM or otherwise protected from alteration
by a secure firmware update process, as defined below.
9. Firmware must support authentication and updates for Secure Boot DB, KEK, and PK variables with RSA public key
modulus sizes of at least 4096 bits.
10. Secure firmware update process. If the platform firmware is to be serviced, it must follow a secure update process. To
ensure the lowest level code layer is not compromised, the platform must support a secure firmware update process
that ensures only signed firmware components that can be verified using the signature database (and are not
invalidated by the forbidden signature database) can be installed. UEFI Boot Services variables must be hardware-
protected and preserved across flash updates. The Flash ROM that stores the UEFI BIOS code must be protected. Flash
that is typically open at reset (to allow for authenticated firmware updates) must subsequently be locked before running
any unauthorized code. The firmware update process must also protect against rolling back to insecure versions, or
non-production versions that may disable Secure Boot or include non-production keys. A physically present user may
however override the rollback protection manually. In such a scenario (where the rollback protection is overridden), the
TPM must be cleared. Further, it is recommended that manufacturers writing BIOS code adhere to the NIST guidelines
set out in NIST SP 800-147 (http://csrc.nist.gov/publications/nistpubs/800-147/NIST-SP800-147-April2011.pdf), BIOS
Protection Guidelines, which provides guidelines for building features into the BIOS that help protect it from being
modified or corrupted by attackers. For example, by using cryptographic digital signatures to authenticate BIOS
updates.
11. Signed Firmware Code Integrity Check. Firmware that is installed by the OEM and is either read-only or protected by a
secure firmware update process, as defined above, may be considered protected. Systems shall verify that all
unprotected firmware components, UEFI drivers, and UEFI applications are signed using minimum RSA-2048 with SHA-
256 (MD5 and SHA-1 are prohibited), and verify that UEFI applications and drivers that are not signed as per these
requirements will fail to run (this is the default policy for acceptable signature algorithms). If an images signature is not
found in the authorized database, or is found in the forbidden database, the image must not be started, and instead,
information about it shall be placed in the Image Execution Information Table.
12. UEFI firmware and driver implementations must be resistant to malicious input from untrusted sources. Incomplete
input validation may result in buffer overflows, integer and pointer corruption, memory overwrites, and other
vulnerabilities, compromising the runtime integrity of authenticated UEFI components.
13. Verify Signature of all Boot Apps and Boot Loaders. Upon power-on, the platform shall start executing boot firmware
and use public key cryptography as per algorithm policy to verify the signatures of all images in the boot sequence up-
to and including the Windows Boot Manager.
Copy
EFI_VARIABLE_NON_VOLATILE
EFI_VARIABLE_BOOTSERVICE_ACCESS
EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS
EFI_VARIABLE_APPEND_WRITE
EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS
36. Microsoft UEFI CA key MUST be included in SecureBoot DB unless the platform, by design, blocks all the 3rd party UEFI
extensions.
37. All Windows client systems must ship with up-to-date DBX content out-of-the-box.
38. Platform MUST expose dbDefault, dbxDefault, KEKDefault, & PKDefault to be accessible for read by the OS.
39. [If Implemented] If platform ships with support for Customized Deployment of Secure boot (Revision 1263, Section 30.3
of UEFI 2.7), then the device MUST ship in deployed mode. Devices may be shipped in User Mode for custom orders
from enterprise customers.
40. [If Implemented] If platform ships with support for HTTP Boot (Revision 1214, Section 23.7 of UEFI 2.7), then the client
connection to the server must be based on a strong server authentication. In case of HTTP it must be HTTPS with
minimum of EV TLS 1.2 authentication, which must be pinned to the Root Certificate Authority.
41. [If Implemented] If platform ships with support for Platform Recovery (Revision 1227, Section 23.7 of UEFI 2.7), then
platform MUST also support HTTP Boot as mentioned above.
42. [If Implemented] If platform ships with support for Customized Deployment of Secure Boot (Revision 1263, Section 30.3
of UEFI 2.7), then the Platform MUST provide consistent Secure Boot workflows as specified in the “Windows Consistent
Secure Boot Workflows” document available on CONNECT.
43. Authenticated and Rollback-protected Storage: External memory for non-volatile storage of all UEFI variables and
security sensitive BIOS settings must have strongly authenticated write access protection, ensuring that authenticated
update mechanisms are not bypassed. Variables and settings shall only be modifiable through defined firmware
interfaces or the device itself. Updates to such variables and settings must be authorized by a Platform Administrator
or part of an authorized firmware update mechanism. Updates must be protected against rollback attacks, preventing
unauthorized updates of the device firmware, UEFI Variables, and security-sensitive BIOS settings to an earlier authentic
version that has a security weakness or would enable updates to a version with a known security weakness
For example, one possible implementation is the use of UFS storage Replay Protected Memory Block. Other
implementations include, but are not limited to, the use of secure TPM counters or a Replay Protected Monotonic
Counter. In all cases, the system should ensure that the authentication mechanism is shielded from unauthenticated
attackers. One example of this would be an on-chip key only accessible to firmware.
System.Fundamentals.Firmware.UEFITimingClass
System firmware must expose timing and class information.
Description
• These timings shall measure tEnd of reset sequence (Timer value noted at beginning of BIOS initialization -
typically at reset vector) Handoff to OS Loader.
System.Fundamentals.Firmware.Update
System firmware must meet the requirements in order to support system and/or device firmware updates using firmware
driver package.
Description
These requirements must be met by any system that updates system and/or device firmware using the Windows
firmware driver package mechanism.
• The ESRT table must define at least one firmware resource (ESRE) in the resource list, which must include
a system firmware resource.
• Only one system firmware resource can be defined in the ESRT.
• No two resources in the ESRT table are permitted to have the same firmware class GUID.
• ESRE must provide appropriate status code including success or failed firmware update attempt, on the
subsequent boot, to the OS.
• Firmware for every resource defined by the ESRT must be upgradable to a newer version
• Firmware version of a particular resource must not break compatibility with firmware versions of other
resources.
• Firmware must provide the lowest supported firmware version using the field
"LowestSupportedFirmwareVersion" in the ESRE table. Firmware must not allow rollback to any version
lower than the lowest supported version. Whenever a security related update has successfully been
made, this field must be updated to match the "FirmwareVersion" field in the ESRE. When the lowest
firmware version does not match the current firmware version, firmware must allow rollbacks to any
version between the current version and the lowest supported version (inclusive).
• Firmware must seamlessly recover from failed update attempts if it is not able to transfer control to the
OS after an update is applied.
System.Fundamentals.Firmware.OSRecovery
Dependencies required in system BIOS/UEFI in order to support a device to recover from bare metal state
Description
1. Secure Boot must ship enabled with minimum of UEFI 2.7 Errata A
a. For example, UDK 2018 with current patches is acceptable.
2. Device UEFI firmware must have implemented the following EFI protocols, along with corresponding UEFI
driver support:
System.Fundamentals.Firmware.Boot
This section describes boot requirements for all client systems.
System.Fundamentals.Firmware.Boot.EitherGraphicsAdapter
System firmware must be able to boot a system with onboard or integrated graphics and with multiple graphics
adapters.
Description
Systems with GPUs on the system board and mobile systems that can use a docking station with PCI slots must
provide a means in the system firmware setup utility to compel the system to use the onboard graphics device to
boot. This capability is required so the onboard graphics device can be used in a multiple-monitor configuration and
for hot undocking a mobile system.
If the system includes PCI, AGP, or PCI Express expansion slots, the system firmware must be able to boot a system
with multiple graphics adapters. The system BIOS must designate one device as the VGA device and disable VGA on
all other adapters. A system with an integrated graphics chipset and one or more discrete graphics adapters must be
able to disable the integrated graphics chipset if the integrated graphics chipset cannot function as a non-VGA
chipset.
System.Fundamentals.Firmware.Boot.SystemWithBootDeviceGreaterThan
Systems with a boot device with a capacity greater than 2.2 terabytes must comply with requirements.
Description
Systems with a boot device with a capacity greater than 2.2 terabytes must comply with the following requirements:
Description
Since all components in the boot path as well as many performance-critical OS subsystems will invoke cryptographic
functions, run-time performance of these functions is critical. The following requirements have been drafted to help
ensure sufficient cryptographic capabilities are in place to meet customer expectations on platform speed and
performance:
• The platform must meet cryptographic performance requirements as stated in Table 1. The platform may meet
these requirements through any combination of hardware or software. The following general remarks apply to all
algorithms in Table below:
a. Target performance must be achieved in a multi-threaded test. The number of threads will be
determined by querying the property named L"HardwareThreads" on the BCrypt provider through the
CNG BCryptGetProperty interface. The provider is required to return a DWORD value in response. If the
provider does not support this property, the test will run single-threaded.
b. When cryptographic acceleration engines are used: Due to the overhead involved in dispatching
requests to hardware acceleration engines, it is recommended that small requests be handled in
software. Similarly, it is recommended that vendors consider using CPU-based cryptography to improve
throughput when all cryptographic acceleration engines are fully utilized, idle capacity is available on
the CPU, and the device is in a high-performance mode (such as when connected to AC power).
• ARM based platforms must implement the EFI_HASH_PROTOCOL from UEFI Industry Group, Unified Extensible
Firmware Interface Specification version 2.3.1 Errata B. The EFI_HASH_PROTOCOL implementation must be
accessible from Windows pre-Operating System code (i.e. in the Boot Services phase of platform boot). Both the
UEFI hash protocols EFI_HASH_ALGORITHM_SHA1_NOPAD_GUID
and EFI_HASH_ALGORITHM_SHA256_NOPAD_GUID must be supported, and the implementation must support
passing a Message at least 10 Mbytes long (Note: No padding must be applied at any point to the input data).
• To make entropy generation capabilities available to Windows pre-Operating System code, the platform shall
support the EFI_RNG_PROTOCOL for pre-Operating System read of at least 256 bits of entropy in a single call (i.e.
256 bits of full entropy from a source with security strength of at least 256 bits). The protocol definition can be
found in Microsoft Corporation, "UEFI Entropy-Gathering Protocol,"2.
• OPTIONAL. It is recommended that the platform's cryptographic capabilities also be accessible from the runtime
OS in user mode, through the interface previously referenced in Requirement 4.
• The OS interface library shall be implemented in such a way that when an unprivileged process is operating on a
given key in a given context, it shall not be able to access the key material or perform key operations associated
with other contexts.
• OPTIONAL. It is highly recommended that the RNG capability of the platform be exposed through an OS entropy
source through the interface specified in Microsoft Corporation, "BCrypt Profile for SoC Acceleration," previously
referenced in Requirement 4.
• OPTIONAL. (Applies when a cryptographic acceleration engine is used) It should be possible to maintain and
perform cryptographic operations on at least three distinct symmetric keys or two symmetric keys and one
asymmetric key simultaneously in the acceleration engine.
Table: Algorithm-specific requirements. The "Category" column classifies algorithms as mandatory to support
at the software interface as per requirement 4 (M), or optional (O). Note that all algorithms that are
accelerated in hardware must also be exposed through the software interface.
1The Modern Standby vendor shall supply documentation indicating, and allowing Microsoft to estimate, the quality
of the entropy source. The entropy shall be assessed using the min-entropy method of Appendix C of National
Institute for Standards and Technology, "Recommendation for Random Number Generation using Deterministic
Random Bit Generators," FIPS 800-90, March 2007 and must surpass or be equal to 256 bits before the runtime OS
starts.
2This specification must be requested explicitly from Microsoft. To request the current version, please contact
http://go.microsoft.com/fwlink/?LinkId=237130.
System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby
All client systems that support Modern Standby must support UEFI Secure Boot.
Description
1. Modern standby systems must meet all of the requirements cited in this section and under
System.Fundamentals.Firmware.Uefisecureboot section. In addition MUST meet the following requirement.
2. Boot Integrity. Platform uses on-die ROM or One-Time Programmable (OTP) memory for storing initial boot code and
initial public key (or hash of initial public key) used to provide boot integrity, and provides power-on reset logic to
execute from on-die ROM or secure on-die SRAM.
3. Secure Boot launch of Windows 8 BootMgr must not require use of an Allowed DB entry other than the Microsoft-
provided EFI_CERT_X509 signature with "CN=Microsoft Windows Production PCA 2011" and "Cert Hash(sha1): 58 0a
6f 4c c4 e4 b6 69 b9 eb dc 1b 2b 3e 08 7b 80 d0 67 8d.
4. The policy for acceptable signature algorithms (and padding schemes) shall be possible to update. The exact method
for updating the policy is determined by each authority (for example: Microsoft determines policies for binaries it is
responsible for; SOC vendor for firmware updates). It is recognized that the initial ROM code need not have an ability
to update the initial signature scheme.
5. The platform shall maintain and enforce a policy with regards to signature authorities for firmware and pre-Operating
System components; the policy (and hence the set of authorities) shall be possible to update. The update must
happen either as a result of actions by a physically present authorized user or by providing a policy update signed by
an existing authority authorized for this task.
6. Upon power-on, the platform shall start executing read-only boot firmware stored on-die and use public key
cryptography as per algorithm policy to verify the signatures of all images in the boot sequence up- to the Windows
Boot Manager.
7. Protection of physical memory from unauthorized internal DMA (for example: GPU accessing memory outside of
video-specific memory) and no unauthenticated DMA access to the SOC. The firmware shall enable this protection as
early as feasible, preferably within the initial boot firmware.
8. Optional: The memory containing the initial boot firmware (executing in SRAM) may be made inaccessible upon
jumping to the next validated stage of the boot sequence. The initial boot firmware may remain inaccessible until
power-on-reset is triggered.
9. The platform shall enforce policy regarding the replacement of firmware components. The policy must include
protection against rollback. It is left to the platform vendor to define the exact method for policy enforcement, but
the signature verification of all firmware updates must pass and the update must be identified in such a manner that a
later version of a component cannot, without proper authorization (for example: physical presence), be replaced by an
earlier version of the component where earlier and later may be defined by a (signed) version number, for example.
10. Optional: The platform shall offer at least 112 logical eFuse bits to support platform firmware revision control in
accordance with the above requirement.
11. Physical Security Requirements. In retail parts, once the platform is configured for Production mode, the hardware
must disable all external hardware debug interfaces such as JTAG that may be used to modify the platform's security
state, and disable all hardware test modes and disable all scan chains. The disabling must be permanent unless re-
enablement unconditionally causes all device-managed keys that impact secure boot, TPM, and storage security to be
rendered permanently erased.
System.Fundamentals.Firmware.KernelDMAProtection
System.Fundamentals.Firmware.KernelDMAProtection,KernelDMAProtection
All systems with external PCIe capable ports (e.g. Thunderbolt™) must support Kernel DMA Protection, to prevent drive-
by DMA attacks via externally facing PCIe capable ports.
Description
Kernel DMA Protection allows the system to leverage the system I/O Memory Management Unit (IOMMU) to isolate
memory accessible by DMA capable device and provide a native OS security against drive-by DMA attacks.
Prerequisites
System.Fundamentals.Firmware.TPR
This feature includes requirements specific to system firmware with eDrive support.
System.Fundamentals.Firmware.TPR.UEFIEncryptedHDD
Systems which ship with a self-encrypting hard drive as a storage device must support the UEFI 2.3.1
EFI_STORAGE_SECURITY_COMMAND_PROTOCOL protocols and shall contain a non-OS partition that can be used to
store WinRE.
If self-encrypted drive support is implemented it must have a UEFI-compatible OS and contain system firmware both
conforming to system firmware logo requirements as defined in System.Fundamentals.Firmware and also contain a
separate WINRE partition.
BitLocker shall support self-encrypting drivers that conform to the eDrive Device Guidelines available on WHDC at
http://msdn.microsoft.com/en-us/library/windows/hardware/br259095
UEFI – Trusted Command Support in UEFI 2.3 + UEFI Mantis change number 616 or UEFI 2.3.1
All necessary partitions have to be created, managed individually pre/post encryption. The WINRE partition must
always be separate and outside of the OS/encryption partition.
If WinRE is on the system partition, the size is 350 MB. If it’s not the system partition, then it’s 300MB. This is assuming
MBR layout. (For GPT, WinRE is always separate from the ESP, therefore 300 MB.)
System.Fundamentals.Graphics
System.Fundamentals.Graphics.FirmwareSupportsLargeAperture
32-bit and 64-bit system firmware supports large aperture graphic adapters.
Description
The system firmware (BIOS/UEFI) must support large aperture graphics adapters. The 32-bit system firmware
(BIOS/UEFI) must be able to support at least 256 MB aperture. On 64-bit systems the firmware (BIOS/UEFI) must be
able to support at least 1GB aperture.
A system that supports multiple graphics adapters must ensure sufficient resources for each adapter. For example
on a 32bit system with 4 graphics adapters, each adapter must receive at least 256 MB memory resources each on
the PCI bus.
System.Fundamentals.Graphics.MicrosoftBasicDisplayDriver
System is compatible with the Microsoft Basic Display Driver.
Description
The System must boot in a mode where the frame buffer used by the Microsoft basic display driver is displayed
whenever the Microsoft display driver writes to the frame buffer. No other driver is involved to accomplish this
output. The frame buffer must be linear and in BGRA format.
System.Fundamentals.Graphics.DisplayRender
The requirements in this section are enforced on any graphics device implementing display and render portion of the
WDDM.
System.Fundamentals.Graphics.DisplayRender.StableAndFunctional
Display device functions properly and does not generate hangs or faults under prolonged stress.
Description
The system must run under prolonged stress without generating hangs or faults.
System.Fundamentals.Graphics.HybridGraphics
Hybrid Graphics Feature
System.Fundamentals.Graphics.HybridGraphics.MultiGPU
Hybrid Graphics
Description
New systems shipping in Windows 10 that expect to be hybrid capable must adhere to the following requirements:
• A Microsoft supported hybrid system can only be composed as one integrated GPU (iGPU) and one discrete GPU
(dGPU)
• Cannot have more than two GPUs
• Both GPU’s must be DX11.0 or higher
• Both GPU’s driver must be WDDM 2.0 or higher
• Both GPUs must implement the standard allocation type added to the KM and associated UM DDIs to support
cross adapter shared surfaces.
• If each GPU has separate standard drivers, then they must be independent of each other and able to be updated
independently without breaking hybrid functionality
• The dGPU must be equal or higher performance than the iGPU
• The dGPU adapter is the one that sets the discrete hybrid cap
All other multi-GPU configurations do not get Microsoft hybrid support. They will be treated the same way as defined
by the “System.Fundamentals.Graphics.MultipleOperatingMode” requirement.
D-list requirements
This is the list of applications maintained by the dGPU IHV for choosing a GPU for an app to run in hybrid mode or
not:
• The D-list DLL can be loaded into a process and queried at most once during D3D initialization
• The DLL size must be under 200KB
• The DLL must be able to return the GPU selection choice within 4ms
Latency tolerance
Engine (monitor ON)
Initial state 0.08 ms
After 200 ms of idle time 15 ms
No context on the engine 30 ms
Engine (monitor OFF)
Initial state 2 ms
After 200 ms of idle time 50 ms
No context on the engine 100 ms
Memory
Active context exists 15 ms
No active context exists 30 ms
Memory refresh
Initial state 0.08 ms
No active context exists 30 ms
Monitor off and no active context exists 80 ms
D3 transition
Initial state 0.08 ms
After 10 s of all engines idle time 15 ms
No active context 200 ms
Monitor off and (no active context or all engines idle for 60 s) 250 ms
System.Fundamentals.Graphics.InternalDisplay
Base for Graphics on Systems
System.Fundamentals.Graphics.InternalDisplay.NativeResolution
Systems with integrated displays must use native resolution by default.
Description
A system with an integrated display must support the native resolution of the display and use native resolution as the
default.
An "integrated" display is any display that is built into the system. A laptop lid is an example of an integrated display.
System.Fundamentals.Graphics.MultipleDevice
Requirements which apply to systems with more than one graphics device.
System.Fundamentals.Graphics.MultipleDevice.Configure
On a system with multiple graphics adapters, system firmware will allow the user to configure the usage of the adapters.
Description
On a system with multiple graphics adapters, the system firmware (BIOS, UEFI, etc), must provide the user with the
ability to modify the following settings:
System.Fundamentals.Graphics.RenderOnly
Requirements which apply to a graphics device only implementing WDDM Render DDI's.
System.Fundamentals.Graphics.RenderOnly.MinimumDirectXLevel
Render Only device on client or server system must be Direct3D 10 capable or greater.
Description
If a client or server system includes a render only device, the device must be Direct3D 10 capable or greater. This
device can only be supported by a WDDMv1.2 Render Only Driver. Render Only devices are not allowed as the
primary graphics device on client systems. All Windows client systems must have a full graphics WDDM v1.3 device
as the primary boot device.
System.Fundamentals.HAL
This feature defines Hardware Abstraction Layer (HAL) requirements for systems.
System.Fundamentals.HAL.IfCSRTPresent
Signed HAL extensions are required for timers and DMA controllers that are not supported in-box
Applies to
Description
If the platform includes a system (shared) DMA controller, the CSRT must include the entries to describe this
controller. In addition, the OS image on the platform must contain Microsoft signed HAL extensions that are properly
linked to these entries in the CSRT, and these HAL extensions must register the DMA resources required by Windows:
at least one DMA Controller, and all DMA Channels for each registered DMA Controller.
Additional Information
Business Justification The information in the tables helps Windows identify the HAL extension module(s) that
need to be loaded to support the hardware implemented on the platform. The HAL
extension gets information from these tables on how the core system resources are
implemented and configured on this platform, to accommodate any variations among
platforms.
System.Fundamentals.HAL.HPETRequired
System provides a high-precision event timer
Applies to
Description
Systems must implement a High Precision Event Timer (HPET) that complies with the following points of the Intel
Architecture Personal Computer (IA-PC) HPET Specification:
• The main counter frequency must be greater than or equal to 10 MHz and less than or equal to 500
MHz
• The main counter must monotonically increase, except on a roll-over event.
• The main counter and comparators must be at least 32 bits wide.
• The main counter must have at least three comparators.
• All of the comparators must be able to fire aperiodic, "one-shot" interrupts.
• At least one of the comparators must be able to fire periodic interrupts.
• Each comparator must be able to fire a unique and independent interrupt.
• HPET must support edge triggering interrupts.
• Timer interrupts must not be shared in LegacyIRQRouting mode.
System.Fundamentals.Input.I2CDeviceUniqueHWID
I2C connected HID devices must have a Unique HWID along with a HID compatible ID.
Description
All I2C connected HID devices must have a unique HWID and a HID compatible ID that will allow WU to identify the
device (when needed) and allow drivers to be loaded from WU.
Design Notes:
System.Fundamentals.Input.PS2UniqueHWID
All PS/2 connected devices (such as internal keyboards) must have a unique hardware ID.
Description
All PS/2 connected devices (such as touchpads and keyboards) must have a unique hardware ID that enables the third
party driver to ship with WU.
Design Notes:
System.Fundamentals.MarkerFile.SystemIncludesMarkerFile
System includes marker file
Description
The marker file gives additional information regarding the maker of the PC system and model. This information is
used to collect and distribute On-line Crash Analysis information. The marker file is a text file with a .mrk extension.
The .MRK filename must be under 256 characters in length including the path. The characters must be letters,
numbers, periods, hyphens, commas and parentheses.
The marker file format is:
For companies with PCI Vendor IDs:
VendorID_CompanyName_Division_Marketing Model Name_other
info.MRK
Each column is separated by the underscore '_' character. The values in each column are
VendorID
= The PCI vendor ID for the PC manufacturer.
CompanyName = Name of the company go here. This should be consistent for each marker file.
Division = this represents the division within the company. If your company doesn't not have divisions please put 'na.'
Marketing Model Name = product name the system will be shipped as. This should be the same as the marketing
name entered at the time of logo submission.
Other info = optional ad can be added by putting more underscores. The additional fields may be used for identifying
any other critical information about the system.
Optionally, the _I field can be used as a part number that can be used to link the marketing model name to.
Design Notes:
The marker file goes in the c:\windows\system32\drivers folder.
These are system level requirements that may impact the integration with a type of network device .
System.Fundamentals.Network.NetworkListOffloads
Wireless LAN networking device on systems that support Modern Standby must support NDIS 6.30 and support offloads.
Description
The following requirements apply to wireless LAN devices. WLAN Devices must support the following features.
Feature Requirement
No Pause on Suspend Required
D0 offload Required
USB Selective Suspend Required- If USB based
Network List offload Required
Wi-Fi PSM Required
Wi-Fi Direct Required
Radio Management Required
WPS 2.0 Required
WoWLAN Required
Systems that support Modern Standby require the use of an NDIS 6.30 Ethernet driver. The device must support the
features listed below.
Feature Required
Wakeup on LAN Yes
D0 & D3 Protocol Offloads (Protocols Jun. 26, 2013) Yes
Interrupt Moderation Yes
OS-programmable packet filtering Yes
System.Fundamentals.Network.PowerRequirements
All physical network devices in a system (inclusive of docking stations) must meet device certification criteria for power
management requirements.
Net new ethernet devices included in a modern standby capable system will require the use of a NetAdapterCx
2.1 2.2 driver and above. (Existing devices will continue to be supported through NDIS).
System.Fundamentals.NX
System.Fundamentals.NX.SystemIncludesNXProcessor
Systems must ship with processors that support NX and include drivers that function normally when NX is enabled
Applies to
Description
To ensure proper device and driver behavior in systems all drivers must operate normally with Execution
Protection. Specifically, drivers must not execute code out of the stack, paged pool and session pool. Additionally,
drivers must not fail to load when Physical Address Extension (PAE) mode is enabled, a requirement for operation
of NX.In addition, the system firmware must have NX on and data execution prevention (DEP) policy must not be set
to “always off."
System.Fundamentals.PowerManagement
Power management is a feature that turns the PC off or into a lower power state. Requirements in this section describes
requirements around power management.
System.Fundamentals.PowerManagement.DockUndock
System supports docking and undocking across a hibernate transition.
Description
System.Fundamentals.PowerManagement.Lid
If a system has a physical lid, then lid state (open/close) is validated.
Description
Confirms proper lid status reporting—accurate and reliable reporting of the lid’s state is critical for battery life and the
overall customer experience.
A system that has a lid must meet minimal reliability standards as tested for this requirement.
Design Notes:
To help ensure the reliability of a lid state reporting, the system will be subjected to the following tests:
Prerequisites:
System.Fundamentals.PowerManagement.MultiPhaseResume
Storage subsystem supports multi-phase resume from Hibernate
Description
The driver and hardware subsystems for the boot storage device must support multi-phase resume from Hibernate. In
order to do this, the system must be able to maintain the system's ability to identify definitively all of the memory
needed on resume. This is not limited to, but should include that:
System.Fundamentals.PowerManagement.PCSupportsLowPowerStates
Systems support S4 and S5 and either S0 low power idle or S3, states.
Description
A desktop or mobile system installed with a client operating system must support the S4 (Hibernate) and S5 (Soft-off)
states and either S0 low power idle, or S3 (Sleep). Systems that support Modern Standby must also support S4
(Hibernate). Every system must support wake from all implemented sleep states. Wake from S5 is only required from
the power button.
Systems which support S0 low power idle must report that behavior by setting the following bits in the FACP flags.
If a USB host controller is implemented on the system, then at least one external port on the controller must support
wake-up capabilities from S3. If the system contains multiple USB host controllers, all host controllers integrated on
the system board (that is, not add-on cards) must support wake-up from S3. USB host controllers are not required to
support wake-up when a mobile system is running on battery power.
Server systems are not required to implement S0 idle, S3, S4, or S5 states. If a server system does implement any of
these behaviors, they must work correctly.
Power Management is an important aspect of good user experience. The system should be able to control what
System.Fundamentals.PowerManagement.ModernStandby
Power management is a feature that turns the PC off or into a lower power state. Requirements in this section describes
requirements around power management for systems that support Modern Standby.
System.Fundamentals.PowerManagement.ModernStandby.Quality
Systems that support S0 low power idle must meet reliability standards for Runtime Power Management.
Description
Systems that support Modern Standby must meet minimal reliability standards as tested for this requirement. The
Modern Standy Basic Requirement Test associated with this requirement will exercise minimum criteria to achieve
reasonable performance and reach systems power floor during Modern Standby.
The device must also properly implement thermal zones. For more information on this design, please see the
"Guidance Specific to Modern Standby" section of the Thermal Design Guide on MSDN. The Modern Standby Check
Thermal Zones Test checks thermal zones for compliance with modern standby requirements.
Design Notes:
To help ensure the reliability of a system that supports Modern Standby, the system will be subjected to the Modern
Standby Basic Requirement Test:
This test will be run with a simulated battery and software power button. Success criteria is based on meeting the
following metrics:
*A device with rotational hard disk drive (HDD) as its primary boot drive is excused from exit latency requirement
To help ensure proper thermal zone implementation while in modern standby, the system will be subjected to the
"Modern Standby Check Thermal Zones" test.
• All Modern Standby PCs must have a thermal manager that will implement a critical hibernate or critical
shutdown policy. This can be satisfied in one of two ways:
o A thermal management driver on the system can advertise that it implements critical policy by
implementing the device interface GUID_DEVINTERFACE_THERMAL_MANAGER.
Page 147 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
o The system can implement at least one ACPI thermal zone for which a critical hibernate (_HOT) or
critical shutdown (_CRT) temperature is defined. For x86 and amd64 systems, we recommend
defining a critical hibernate temperature (_HOT) to trigger the saving of user data. If both
thresholds are defined, _HOT must be lower than _CRT. Both thresholds should be lower than the
firmware fail-safe thermal trip point.
• [If Implemented] Each thermal zone which implements passive or active cooling will be validated to contain
the correct set of ACPI objects for each policy:
o Passive cooling thermal zones require _PSV, _TC1, _TC2, _TSP or _TFP, and _PSL or _TZD.
o Active cooling thermal zones require each _ALx have a matching _ACx.
• [If Implemented] When the real temperature hit the threshold of hibernation point (ie. _HOT), each thermal
zone must report actual temperature via _TMP or a temperature sensor driver. The platform does not need
to notify the OS of temperature change, but the platform should still return correct temperature if the OS
runs _TMP on its own without a notification. The test runs a varying workload on the PC, and the
temperature is expected to change.
System.Fundamentals.PowerManagement.PowerProfile
System must report form factor via power management profile
Description
The Preferred_PM_Profile in the FADT table must be set to one of the values based on the form factor of the system
as outlined in the ACPI specification version 5.0. This value shall not be unspecified (0).
Design Notes:
For more information see page 119 of the ACPI specification version 5.0.
System.Fundamentals.PowerManagement.Processor
Processor power management comprises of processor idle and performance state support. These capabilities are
enumerated by the platform and must work correctly for the OS to implement appropriate performance and power
trade-offs.
Description:
This test conducts checks to validate that processor performance state and idle states have been defined; checks that
those performance state and idle state definitions are correct and validates the behavior of processor performance
states with a frequency varying workload. For more information see Processor Configuration and Control section in
ACPI. Link: https://uefi.org/sites/default/files/resources/ACPI%206_2_A_Sept29.pdf
System.Fundamentals.PowerManagement.ModernStandby.DirectedFx.Reliability
Drivers for devices in DRIPS constraint device hierarchies on Modern Standby systems must support Directed PoFx (DFx)
Description
Directed PoFx (DFx) provides APIs to force devices into a low power state in the absence of legitimate software
activity during Modern Standby. DFx applies to devices that are constraints for the system to enter DRIPS and their
child devices. Driver implications of DFx are outlined in the DFx Partner Implementation Guide.
In addition to the required system-level HLK test for Directed PoFx (DFx), optional tests are available for testing and
validating implementations of DFx at the device level.
More details about these tests can be found in the DFx Partner Implementation Guide.
Prerequisites
System.Fundamentals.PowerManagement.ModernStandby.Battery
Power management is a feature that turns the PC off or into a lower power state. Requirements in this section describes
requirements around power management for systems that support modern standby and have a battery installed.
System.Fundamentals.PowerManagement.ModernStandby.Battery.Quality
Systems that support S0 low power idle must meet reliability standards for Runtime Power Management.
Description
Systems that support Modern Standby and have a battery installed must meet minimal reliability standards as tested
for this requirement. The test associated with this requirement will exercise minimum criteria to achieve reasonable
performance and reach systems power floor during Modern Standby on both AC & DC.
Design Notes:
To help ensure the reliability of a system that supports Modern Standby, the system will be subjected to the
following tests:
This test will be run with a simulated battery and software power button. Success criteria is based on meeting the
following metrics:
*A device with rotational hard disk drive (HDD) as its primary boot drive is excused from exit latency requirement
System.Fundamentals.PXE
System.Fundamentals.PXE.PXEBoot
Remote boot support for PXE complies with BIOS Boot Specification 1.01 or EFI boot manager
Applies to
Description
All systems are required to be PXE capable. The system must support booting from the network as defined in
BIOS Boot Specification, Version 1.01, Appendix C, or as controlled by the EFI boot manager. This requirement is
exempt for systems that are configured with Wireless LAN only.
Systems shipping with a UEFI compatible operating system and supporting PXE boot must support IPV4 PXE and
IPV6 PXE booting as defined in UEFI 2.3.1.
UNDI must support :
• a DUID-UUID per IEFT draft
• (http://tools.ietf.org/html/draft-narten-dhc-duid-uuid-01)
• DHCP6, DUID-UUID, IPv6 IPV4 multicast
Design Notes:
Microsoft recommends that the implementation of accessing PXE be consistent with BIOS Boot Specification,
Version 1.01, and Appendix C.
Description
All drivers in a system must pass all requirements under Device.DevFund.Reliability. All systems will need to pass
Common Scenario stress:
System.Fundamentals.Security
This requirement outlines the system capabilities and firmware tables required to support virtualization based
security features. These requirements are applicable to all editions of Windows – Windows Home, Windows
Professional, Windows Enterprise, Windows Education, and Windows Server.
System.Fundamentals.Security.CryptoOffloadHardware
Systems must ensure BitLocker / device encryption does not impact system performance
Description:
Systems must meet the security and performance needs to support BitLocker encryption and file encryption on the fly
without impacting the user experience, including battery life. For those systems that would instead use a 3rd party
encryption solution, BitLocker can be turned off as described in this document.
1. MUST have storage controller with inline crypto engine with AES-XTS capability
OR
2. MUST have AES crypto acceleration instructions (either AES-NI or ARMv8 AES instructions)
Description:
Our goal to offer password less multi-factor authentication is achievable for type 1 workers using Windows Hello for
Business where worker can enroll their biometrics / setup PIN on their assigned device.
Windows logon with FIDO is targeted for type 2 worker population where it enables password less MFA for workers
who use shared PC’s and do not want to enroll biometrics / setup PIN on every machine. That said, the FIDO
authenticator should be portable, the worker can carry it with them to from one PC to the other as their identity to
login.
We discourage OEM’s from embedding FIDO authenticators in chassis as it breaks the assumption of this credential
being portable and used across different PCs.
Systems supporting FIDO for Windows Logon MUST ensure there is no other FIDO authenticator built in chassis. This
includes U2F and FIDO 2.0 CTAP authenticators.
System.Fundamentals.Security.DeviceEncryption
Systems that support modern standby must support device encryption.
Description
Systems that support modern standby must meet the security requirements to support enablement of Device
Encryption. OEMs must not block the enablement of Device Encryption when deploying the OS images unless the
device is pre-provisioned with a third-party disk encryption solution. Device Encryption will be enabled on these
systems to ensure that user data is protected. As pre-requisites for Device Encryption, modern standby systems must
meet requirements for TPM and Secure Boot as outlined in System.Fundamentals.TPM20 and
System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby. Systems must meet the security and
performance needs to support BitLocker encryption and file encryption on the fly without impacting the user
experience, including battery life. For those systems that would instead use a 3rd party encryption solution, BitLocker
can be turned off as described in this document. Either one of these requirements must be met:
Page 152 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
1. MUST have storage controller with inline crypto engine (JESD220C UFS version 2.1) with AES-XTS capability
OR
2. MUST have AES crypto acceleration instructions (either AES-NI or ARMv8 AES instructions)
System.Fundamentals.Security.NoTDIFilterAndLSP
No TDI filters or LSPs are installed by the driver or associated software packages during installation or usage.
Description
There can be no use of TDI filters or LSPs by either kernel mode software or drivers, or user mode software or drivers.
System.Fundamentals.Security.PlayReadyModule
Applies to Windows 11 Client x64
Description
PlayReadyModule, when available on a device in secure firmware in conjunction with a compatible graphics driver,
enables hardware-based content protection for media. If implemented, this module provides hardware-rooted
protection of device keys, content keys and media content/samples that flow through a media pipeline. It will enable
the device to have access to high definition (1080p and above) premium content. OEMs shipping on chipsets/SoCs
that have a PlayReadyModule available (in the form of secure firmware available from the chipset vendor) must
include PlayReadyModule on devices with screen resolutions of 1080p or higher.
System.Fundamentals.Security.SecureBiometrics
Hardened biometric security leveraging virtualization
Terms: If-Implemented
Description:
The following shows the hardware, firmware, and software requirements for virtualization-based hardening of
biometrics on new platforms, new chassis.
1. Must meet all criteria for Virtualization Based Security (VBS) support as described in
System.Fundamentals.Security. VirtualizationBasedSecurity.VirtualizationSupport.
2. Must have specific supported IR Camera and/or fingerprint hardware and meet the requirements below:
1. USB camera and associated USB XHCI controller must be specified as secure devices using the Secure Devices
ACPI table. (ACPI version 6.2, section 5.2.26). The SDEV XHCI secure device descriptor for the camera must have
Revision set to at least 2.
2. Any workarounds implemented in BIOS/firmware via ACPI methods that access the PCI configuration space or
the MMIO register space of a secure USB XHCI controller must be disabled when VTIO is enabled.
3. USB XHCI controller must support multiple bus/device/functions (BDF) or a dedicated controller must be used for
the USB camera.
4. USB Camera must be connected to a root port.
5. Camera must use the Microsoft USB Video class driver (USBVideo.sys) as required by
Device.Streaming.Camera.UVC.
6. Camera must meet all criteria described under System.Client.Camera.CameraControls.
7. Camera must meet all criteria described under System.Client.Camera.SensorCapture.
8. Camera must meet all criteria described under System.Client.Camera.PhysicalLocation.
9. Camera must meet all criteria described under System.Client.Camera.Device.
10. Camera must meet all criteria described under Device.Streaming.Camera.Base.Sharing.FaceAuthMode.
11. Camera must not support any means to replay a previously captured frame.
12. Camera firmware must be updateable using a hardened mechanism or must not support in field firmware
updates. This can be achieved using a locked down GPIO mechanism. Any update of the camera firmware must
also be accompanied by a corresponding update to the firmware hash listed in the SDEV entry describing the
USB camera.
13. Camera must be able to support reporting a hash of its firmware at runtime as specified in the USB FW Update
ECN of the USB 3.2 specification.
1. MIPI camera must be specified as a secure device using the Secure Devices ACPI table. (ACPI version 6.2, section
5.2.26).
2. MIPI camera drivers must support a split architecture using the WDF companion host model. All camera registers
must be programmed from components running in VBS.
3. Camera must meet all criteria described under System.Client.Camera.CameraControls.
4. Camera must meet all criteria described under System.Client.Camera.SensorCapture.
5. Camera must meet all criteria described under System.Client.Camera.PhysicalLocation.
6. Camera must meet all criteria described under System.Client.Camera.Device.
7. Camera must meet all criteria described under Device.Streaming.Camera.Base.Sharing.FaceAuthMode.
Fingerprint requirements:
System.Fundamentals.Security.VirtualizationBasedSecurity.VirtualizationSupport
Systems with applicable processor generations must ship with hardware virtualization extensions enabled by default in
the BIOS, and available for exclusive use by the operating system.
Description
The following system capabilities required to properly support Microsoft’s Virtualization Based Security (VBS)
platform. VBS supports a range of OS protections and security features (e.g. Secure Biometrics, Credential Guard,
Exploit Guard, System Guard).
End users can opt into enabling VBS and HVCI in the Windows Security UI
Automatic enablement of VBS will still be provided via sysprep if the following requirements are met:
• Virtual machine extensions (Intel VT-X, AMD-V, ARM64 EL2) with extended page tables (second level page
tables).
• Per-page attribute controls in the second level page table which allow the operating system to set execute
permissions separately for user and supervisor mode
Page 155 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
• Intel and AMD systems must have hardware support for APIC virtualization
• All I/O devices must be behind an IOMMU/SMMU (Intel VT-D, AMD-Vi, ARM64 SMMUs).
• If system firmware provides the ability to control the exposure of platform virtualization extensions, including
processor virtualization technology and system IOMMUs, to system software, these controls must be in the
“enabled” state by default.
• The OS must have exclusive use and control of the physical processor’s hardware virtualization extensions, with
no other virtual machine monitor or hypervisor assuming control of these functions and showing virtualized
facsimiles to the operating system.
• Systems must have a minimum of 4GB of system memory.
• UEFI Memory Reporting - UEFI firmware must adhere to the following memory map reporting format and
memory allocation guidelines in order for firmware to ensure compatibility:
o UEFI v2.6 Memory Attributes Table (MAT) - Firmware must cleanly separate EFI runtime
memory ranges for code and data, and report this to the operating system. Proper segregation
and reporting of EFI runtime memory ranges allows VBS to apply the necessary page
protections to EFI runtime services code pages within the VBS secure region. Conveying this
information to the OS is accomplished using the EFI_MEMORY_ATTRIBUTES_TABLE.
o The entire EFI runtime must be described by this table. All appropriate attributes for
EfiRuntimeServicesData and EfiRuntimeServicesCode pages must be marked. These ranges
must be aligned on page boundaries (4KB), and cannot overlap.
o EFI Page Protections - All entries must include attributes EFI_MEMORY_RO, EFI_MEMORY_XP, or
both. All UEFI memory that is marked executable must be read only. Memory marked writable
must not be executable. Entries may not be left with neither of the attributes set, indicating
memory that is both executable and writable.
▪ Windows SMM Security Mitigations ACPI Table (WSMT) – System firmware must adhere to the
recommendations for hardening SMM code described in the Windows SMM Security Mitigations Table (WMST)
specification. Firmware must implement the protections described in the WSMT specification, and set the
corresponding protection flags as described in the specification to report compliance with these requirements
to the operating system.
o Note: This sub-requirement is If-implemented for Windows Server vNext
▪ Secure MorLock Rev 2 must be enabled , details here
▪ Ensure all system drivers have been tested and verified to be compatible with hypervisor-enforced code
integrity (HVCI).
System.Fundamentals.Security.KernelHardwareEnforcedStackProtection
OEM drivers must be compatible with hardware-enforced stack protection and tested using CPU supporting either
Intel's Control-flow enforcement technology or AMD's Shadow Stack.
Applies to Windows 11 Client x64
Description
Hardware-enforced stack protection is Windows' supporting for hardware shadow stacks protection. Shadow stacks is
a mechanism to enforce back-edge control flow integrity. This mitigation maintains a secondary stack that shadows
the data stack and prevents an exploit technique known as return-oriented programming (ROP) which hijacks the
instruction pointer by overwriting the return address via a memory corruption vulnerability. This mitigation will
protect kernel mode code in the near future.
Drivers must ensure compatibility with Hardware-enforced stack protection (kernel mode). The requirement is as follows:
1. Use a machine with a CPU that supports hardware shadow stacks (Intel 11th Gen Mobile or AMD Zen3 or newer
processors).
2. Set the machine to take insider dev external builds. Take the OS update and reboot the system.
3. Ensure your drivers are compiled with the /CETCOMPAT linker flag. This switch is offered in Visual Studio 16.7 Preview
4 and newer:
• https://docs.microsoft.com/en-us/cpp/build/reference/cetcompat?view=msvc-170
System.Fundamentals.Security.AntiMalware
Description
Systems must not include software/drivers intentionally designed to cause disruption, leak private information, gain
unauthorized access, deprive users access to information or which unknowingly interferes with the user's computer
security and privacy.
Design Notes:
During the test, a full-system scan will be performed with Microsoft Defender Antivirus
System.Fundamentals.Security.DGCG
For Device Guard and Credential Guard, Intel TXT fully works when enabled and operates in parallel with these feature
sets.
System.Fundamentals.Security.DGCG.CredentialGuard
This feature checks for Credential Guard.
Applies to
Windows 11 Client x64
Windows 11 Client ARM64
Terms: If-Implemented
Description:
1. MUST meet all Device Guard requirements as described in System.Fundamentals.Security.DeviceGuard (except for
the need of HVCI compatible drivers and Firmware UEFI NX Protection)
2. MUST meet the additional requirements as described in the table below:
Requirement Description
Trusted Platform TPM 2.0 provides protection for encryption keys that are stored in the firmware. Either
Module (TPM) discrete or firmware TPMs will suffice.
version 2.0
Firmware security Secure MOR Revision 2 bit prevents certain memory attacks and is necessary for Credential
patch for Secure Guard. This will further enhance security of Credential Guard.
MOR
Implementation
System.Fundamentals.Security.DGCG.HVCI
Device Guard requirement for systems
Applies to
Windows 11 Client x64
Windows 11 Client ARM64
Description:
Windows 11 has a security feature called HVCI that provides advanced malware protection against new and unknown
malware variants as well as Advanced Persistent Threats (APTs). The following table shows the hardware, firmware and
software requirements for HVCI. All Win11 devices must meet basic requirements to enable HVCI, and HVCI will be
automatically enabled by default on some devices during sysprep. The ability for OEMs to opt-out of this automatic
enablement will be removed in 2022 Release.
Requirement Description
Windows 10/11 OS Windows 10/11 Enterprise, Windows 10 Education, Windows Server vNext, Windows
SKUs 10/11 IoT Enterprise
x64 architecture Virtualization-based security (VBS) features require the Windows hypervisor, which is
only supported on 64-bit processors
Secure firmware Like UEFI software, UEFI firmware can have security vulnerabilities. It is essential to have
update process the capability to immediately patch such vulnerabilities when found through firmware
updates. UEFI firmware must support secure firmware update as described in
System.Fundamentals.Firmware.UEFISecureBoot.
VT-D or AMD Vi In Windows 10, an IOMMU can be used to enhances system resiliency against memory
IOMMU attacks. For more information, see ACPI description tables.
(Input/output
memory
management unit)
VBS enablement of VBS will enable No-Execute (NX) protection on UEFI runtime service code and data
NX protection for memory regions. UEFI runtime service code must support read-only page protections,
UEFI runtime services and UEFI runtime service data must not be executable.
Note: this only applies to UEFI runtime service memory, and not UEFI boot service
memory.
Note: this protection is applied by VBS on OS page tables.
Firmware support for The Windows SMM Security Mitigations Table (WSMT), Revision 1, April 18, 2016
SMM protection specification contains details of an Advanced Configuration and Power Interface (ACPI)
table that was created for use with Windows operating systems that support Windows
virtualization-based security (VBS) features.
• For more information, see the Windows SMM Security Mitigations Table (WMST)
specification.
System.Fundamentals.Security.SystemGuard
This feature includes requirements specific to the enablement of a dynamic root of trust for protecting and hardening
VBS and the Hypervisor
System.Fundamentals.Security.SystemGuard
Systems must meet the following requirements
Term: if-implemented
Description
• For Intel vPro® processors starting with Intel® Alder Lake or later silicon
o Recommended: Platforms should configure SMM access to State Save Registers as follows:
• Read/write access from/to State Save registers should be denied, except:
• Read access to IO_MISC – always allowed
• Read access to AL/AX/EAX on trapped IO port write (width derived from IO_MISC)
• Write access to AL/AX/EAX on trapped IO port read (width derived from IO_MISC)
• Note: No support for INS or OUTS trapping
o Recommended: Platforms should configure SMM access to MMIO as follows:
• Deny write access to TXT Private/Public Space
o Recommended: Platforms should configure System Memory access as follows:
• Deny write access to TXT Heap/DPR region
o Recommended: Platforms should ensure that SMM does NOT contain any mappings to the following
Model Specific Registers:
• Add to deny-list below IA32_RTIT_CTL_MSR
• For Intel vPro® processors starting with Intel® Cometlake or later silicon
• Platforms must provide dynamic attestation of the platform’s SMM configuration and access policies. This
capability integrates with Intel® System Security Report (a.k.a. Nifty Rock).
• For Intel vPro® processors starting with Intel® Coffee Lake, Whiskey Lake, or later silicon
o Platforms must meet the Windows DMA Protection Specification, please reference the
System.Fundamentals.Firmware.NoExternalDMAOnBoot requirement for more details.
o Platforms must have all SMM communication buffers implemented in:
o EfiRuntimeServicesData, EfiRuntimeServicesCode , EfiACPIMemoryNVS, or
EfiReservedMemoryType memory types
o Platforms must have all SMM page tables as follows:
o Do NOT contain any mappings to EfiConventionalMemory (e.g. no OS/VMM owned memory)
o Do NOT contain any mappings to code sections within EfiRuntimeServicesCode
o Do NOT have execute and write permissions for the same page
o Platforms must allow ONLY that TSEG pages can be marked executable and the
memory map must report TSEG EfiReservedMemoryType
o Platforms must provide mechanism to protect the SMM page tables from modification:
• BIOS SMI handler must be implemented such that SMM page tables are locked on every SMM entry
o Platforms must support Modern/Connected Standby (S3 will not be in scope in the future for this feature)
o Platform firmware must set up a TPM NV index for use by the OS with:
• Handle: 0x01C101C0
• Size of exactly 128 bytes
• NameAlg= SHA256
• Policy Digest: 0xcb, 0x45, 0xc8, 0x1f, 0xf3, 0x4b, 0xcf, 0x0a, 0xfb, 0x9e, 0x1a, 0x80, 0x29, 0xfa, 0x23,
0x1c,0x87, 0x27, 0x30, 0x3c, 0x09, 0x22, 0xdc, 0xce, 0x68, 0x4b, 0xe3, 0xdb, 0x81, 0x7c, 0x20, 0xe1
• Attributes:
o TPMA_NV_POLICYWRITE
o TPMA_NV_PPREAD
o TPMA_NV_OWNERREAD
o TPMA_NV_AUTHREAD
o TPMA_NV_POLICYREAD
o TPMA_NV_NO_DA
o TPMA_NV_PLATFORMCREATE
o TPMA_NV_POLICY_DELETE.
• Policy:
o A = TPM2_PolicyAuthorize(MSFT_DRTM_AUTH_BLOB_SigningKey)
o B = TPM2_PolicyCommandCode(TPM_CC_NV_UndefineSpaceSpecial)
o authPolicy = {A} OR {{A} AND {B}}.
o Platform firmware must carry all code required to execute an Intel® Trusted Execution Technology secure
launch. It is Mandatory that one of the following methods is used to provide the SINIT ACM to the platform:
o Optional: Intel SINIT ACM be carried in the OEM BIOS, and the ACM must be an Intel®
production ACM signed by the correct production Intel ACM signer for the platform
o Recommended: Platform publishes a device for the ACM via ACPI with the following
parameters to enable update of the SINIT ACM via Windows Update. The shipping OEM
Windows system image MUST be built to include a corresponding ACM package.
• _HID set to “INTC1025”
• _CID set to “INT_WHL_SINIT” for Whiskey Lake and “INT_ICL_SINIT” for Ice Lake
o Platform firmware must set up a TPM NV index for use by the OS with:
• Handle: 0x01C101C0
• Size of exactly 128 bytes
• NameAlg= SHA256
• Policy Digest: 0xcb, 0x45, 0xc8, 0x1f, 0xf3, 0x4b, 0xcf, 0x0a, 0xfb, 0x9e, 0x1a, 0x80, 0x29,
0xfa, 0x23, 0x1c,0x87, 0x27, 0x30, 0x3c, 0x09, 0x22, 0xdc, 0xce, 0x68, 0x4b, 0xe3, 0xdb,
0x81, 0x7c, 0x20, 0xe1
• Attributes:
o TPMA_NV_POLICYWRITE
o TPMA_NV_PPREAD
o TPMA_NV_OWNERREAD
o TPMA_NV_AUTHREAD
o TPMA_NV_POLICYREAD
o TPMA_NV_NO_DA
o TPMA_NV_PLATFORMCREATE
o TPMA_NV_POLICY_DELETE
• Policy:
o A = TPM2_PolicyAuthorize(MSFT_DRTM_AUTH_BLOB_SigningKey)
o B = TPM2_PolicyCommandCode(TPM_CC_NV_UndefineSpaceSpecial)
o Platform firmware must carry all code required to execute an Intel® Trusted Execution
Technology secure launch:
o Intel SINIT ACM must be carried in the OEM BIOS
o Platforms must ship with a production ACM signed by the correct production
Intel ACM signer for the platform
• For AMD® Ryzen® PRO® processors starting with Zen3® and beyond
o Recommended: Platforms should ensure that SMM does NOT contain any mappings to the following Model
Specific Registers:
• MSRC001_1010 (Core::X86::Msr::BT_CTL)
• MSRC001_1024 (Core::X86::Msr::DBG_CTL_MSR2)
• MSRC001_1018 (Core::X86::Msr::EXCP_BP_CTL)
System.Fundamentals.SignedDrivers
This feature checks for signed drivers.
System.Fundamentals.SignedDrivers.BootDriverEmbeddedSignature
Boot drivers must be self-signed with an embedded signature.
Description
All boot start drivers must be embedded-signed using a Software Publisher Certificate (SPC) from a commercial
certificate authority. The SPC must be valid for kernel modules. Drivers must be embedded-signed through self-
signing before the driver submission.
Design Notes:
For more information about how to embedded-sign a boot start driver, see "Step 6: Release-Sign a Driver Image File
by Using an Embedded Signature" at the following website:
http://www.microsoft.com/whdc/winlogo/drvsign/kmcs_walkthrough.mspx
After the file is embedded-signed, use SignTool
Verifying: toaster.sys
SHA1 hash of file: 2C830C20CF15FCF0AC0A4A04337736987C8ACBE3
Signing Certificate Chain:
Issued to: Microsoft Code Verification Root
Issued by: Microsoft Code Verification Root
Expires: 11/1/2025 5:54:03 AM
SHA1 hash: 8FBE4D070EF8AB1BCCAF2A9D5CCAE7282A2C66B3
...
Successfully verified: toaster.sys
Number of files successfully Verified: 1
Number of warnings: 0
Number of errors: 0
In the Windows Hardware Lab Kit, this requirement will be tested by using the Embedded Signature Verification test.
System.Fundamentals.SignedDrivers.DigitalSignature
System must contain compatible qualified devices.
Description
All buses, devices and other components in a system must meet their respective Windows Compatible Hardware
Requirements and use drivers that either are included with the Windows operating system installation media or are
digitally signed by Microsoft through the Windows Hardware Compatibility Program that match the Windows OS
version being submitted for and shipping with.
For example, if a logo qualifying a system for Windows 10, then all drivers on the system must be signed by Microsoft
for Windows 10 or be drivers that ship on the Windows 10 media. All devices in the system would also need to be
logo qualified or certified for Windows 10. This requirement applies to all versions of Microsoft Windows.
All devices and drivers need to be fully installed,and does not contain any problem codes.
▪ Device.DevFund.INF.DDInstall.CoInstallers
▪ Device.DevFund.DriverSecurity.DriverPackage
Page 168 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
▪ Device.DevFund.Reliability.ProperINF
▪ Device.DevFund.CDA.Application (If applicable)
All drivers and firmware servicing must use Windows Update, with the exception that use of Windows Update is If
Implemented for Windows Server.
System.Fundamentals.SMBIOS
System Management BIOS (SMBIOS) requirements defines data structures in the system firmware which allows a user or
application to store and retrieve information about the computer.
System.Fundamentals.SMBIOS.SMBIOSSpecification
System firmware support for SMBIOS complies with the SMBIOS specification.
Description
The system firmware must implement support for SMBIOS that complies with System Management BIOS Reference
Specification, Version 3.0 or later version, as needed to correctly and uniquely identify the system using the mandated
structures and data below. The SMBIOS implementation must follow all conventions and include all required
structures and fields as indicated in the SMBIOS Specification, Section 6.2, “Required structures and data”, and follow
all conformance requirements as indicated in ANNEX A (Informative). Bit 2 in the BIOS Characteristics Extension Byte 2
field must be set (Section 3.3.1.2.2 of the specification). The length of the Type 1 (System Information) table must be
at least 1Bh bytes (includes SKU Number and Family fields from Version 3.0 or later of the specification).
Additionally, the following fields must have non-Null values that accurately describe the computer system or
computer system component, with no “generic”, “universal”, indefinite or other non-specific values or strings in the
below structures that would preclude unique identification of a system:
Microsoft recommends that the following fields have non-Null values that accurately describe the computer system or
computer system component:
2These fields gain prominence as fields which will be used for identifying unique system configurations for telemetry
and servicing. The Manufacturer, Product Name, SKU Number, Family, Base Board Product and System Enclosure
fields must not be longer than 64 characters in length. Avoid leading or trailing spaces or other invisible characters.
The Type field value must be from the “System Enclosure or Chassis Types” table.
3If the system has a field upgradeable embedded controller firmware; these values should not be equal to 0FFh.
Design Notes:
Inputs to the identified SMBIOS fields are to remain consistent by avoiding variations in punctuation, abbreviations,
spacing, capitalization, and spelling errors.
Company must ensure updates to firmware do not modify the values for the “Manufacturer”, “Family”, “Product
Name”, “Baseboard Product”, “SKU Number” and “Enclosure Type” fields defined in the SMBIOS specification
As new form factors are developed in partnership with Distributed Management Task Force, Inc. (“DMTF”) to provide
new byte values for new “enclosure type” fields. Company must begin to accurately report the new byte value for
new “enclosure type” field for new Product Name systems to which the new form factor applies within one-hundred
and twenty (120) days of the new byte value being made available.
System.Fundamentals.StorageAndBoot
This section summarizes the requirements for storage and boot devices.
Description
The following requirements apply to Boot Devices in systems that support Modern Standby.
The Windows platform supports SATA, USB, NVMe, eMMC SD and UFS based storage. The table below shows which
bus types can be used for the boot device.
ACPI interfaces must specify whether the storage device is internal or external and whether or not it is removable or
fixed.
_RMV must be defined in ACPI namespace for any embedded devices attached to an SD host controller, where 0 is
defined as non-removable. _RMV may optionally be defined for external slots as 1.
The following parameters must be defined within the “Storage Class-Specific Information” to be returned by the ACPI
_DSM method for an SD/eMMC Storage Controller:
• Number of Sockets
• Socket Addresses
When using eMMC as the primary boot device, the eMMC memory must be hardware partitioned such that the boot
critical portion of the EFI Firmware resides in an area of the device that is not accessible by Windows.
The CPU Vendor and/or Firmware Provider must furnish the software tools needed to maintain and update the
firmware.
The following requirements are applicable to solid state (SATA SSD, NVMe, eMMC and UFS) boot storage media and
are tested with the smaller of 2% or 1GB free space.
Maximum of 20 seconds sum-total of user-perceivable I/O latencies over any 1 hour period of a user-representative
workload, where a user-perceivable I/O is defined as having a latency of at least 100 milliseconds.
The following requirements are applicable to SATA HDD boot storage media
Feature Specification
Max Standby Power <= 250 mW
System.Fundamentals.StorageAndBoot.EncryptedDrive
Systems which ship with a Encrypted Drive as a boot storage device must support security command protocols in order
to make sure the data at rest is always protected.
o Trusted Command Support in UEFI 2.3 + UEFI Mantis change number 616 or
o UEFI 2.3.1
c. The implementation of the Trusted Computing Group Platform Reset Attack Mitigation Specification
(http://www.trustedcomputinggroup.org/resources/pc_client_work_group_platform_reset_attack_mitigation_s
pecification_version_10) MUST unconditionally issue TPer Reset (OPAL v2.0 in section 3.2.3) for all scenarios
whenever memory is cleared.
e. The system MUST enumerate all Encrypted Drives and TPer Reset MUST be issued prior to executing any
firmware code not provided by the platform manufacturer in the base UEFI image.
f. The TPer Reset MUST be issued regardless of whether the TPM has had ownership taken or not.
Note: The TPer Reset action will occur later in the boot process than the memory clear action because it has a
dependency on the EFI_STORAGE_SECURITY_COMMAND_PROTOCOL.
System.Fundamentals.StorageAndBoot.SATABootStorage
System with SATA boot storage must meet requirements.
Description
AHCI Host Controllers using Windows for boot support must be compliant with the AHCI specification.
When used in systems that support modern standby, the SATA device must meet the power requirements stated in
the section for System.Fundamentals.StorageAndBoot.BootPerformance.
System.Fundamentals.StorageClassMemory
System.Fundamentals.StorageClassMemory
System.Fundamentals.StorageClassMemory
Applies to
Windows 11 Client x64
Description:
• Platforms supporting the use of Storage Class Memory devices must implement the relevant portions of
ACPI 6.1 (or newer), specifically:
• NVDIMM Firmware Interface Table (NFIT)
• NVDIMM Root Device reported under the _SB namespace in Differentiated System Description
Table (DSDT) or Secondary System Description Table (SDDT)
• NVDIMM Device reported under the NVDIMM Root Device in the DSDT or SSDT for every module
in the system
• NVDIMM Root Device Notification value of 0x81 (Unconsumed Uncorrectable Memory Error
Detected)
• NVDIMM Devie Notification value of 0x81 (NFIT Health Event Notification)
• Persistent memory regions reported in the Memory Affinity Structure(s) in the System Resource
Affinity Table (SRAT)
• Continuously running Address Range Scrub (ARS)
• Heterogeneous Memory Attribute Table (HMAT)
• Firmware shall not map any Storage Class Memory devices to the 4GB region starting at address
0xFFFF00000000 in system address space.
• Platforms must support Asynchronous DRAM Refresh (ADR) on Intel-based systems.
• Platform must only present 1 namespace per physical device. If there are more than one namespace on a
physical device, only a single namespace will be usable.
System.Fundamentals.StorageClassMemory.1GibMappings
The starting address of all byte addressable persistent memory regions is mapped at 1GiB granularity.
Applies to
Windows 11 Client x64
Page 174 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
Description
SCM-capable platforms must map the starting address of byte addressable persistent memory regions at 1GiB
granularity.
Note: If this granularity is not provided, the Windows SCM stack will not load.
System.Fundamentals.StorageClassMemory.INVDIMM.DSMCompliance
System.Fundamentals.StorageClassMemory.INVDIMM.DSMCompliance
Applies to
Windows 11 Client x64
Description:
• Platforms supporting the use of INVDIMM devices need to comply with the _DSM specification with version
1.7 or newer located here: http://pmem.io
System.Fundamentals.StorageClassMemory.INVDIMM.Label
System.Fundamentals.StorageClassMemory.INVDIMM.Label
Applies to
Windows 11 Client x64
Description:
• Platforms supporting the use of INVDIMM devices need support for Labels with BTT support, with BTT
implementation compliant with UEFI 2.7 or newer.
• Platforms must support creating and removing namespaces which span the entirety of the available
persistent memory region attached to a memory controller or socket.
o Multiple namespaces per device or per interleave set are not supported.
System.Fundamentals.StorageClassMemory.NVDIMMN.DSMCompliance
System.Fundamentals.StorageClassMemory.NVDIMM-N.DSMCompliance
Applies to
Windows 11 Client x64
Description:
Platforms supporting the use of NVDIMM-N devices have to comply with the Microsoft _DSM for JEDEC Byte-
Addressable Energy-Backed Interface NVDIMMs specification, located here:
• https://msdn.microsoft.com/en-us/library/windows/hardware/mt604741(v=vs.85).aspx
Note: NVDIMM-N devices are identified through the Firmware’s NFIT table as defined in ACPI 6.1, or a newer revision.
Applies to
Windows 11 Client x64
Description:
• Platforms supporting the use of NVDIMM-N devices may support the use of Labels. If implemented, Labels
must be compliant with UEFI 2.7
System.Fundamentals.StorageClassMemory.NVDIMMN.Persistence
System.Fundamentals.StorageClassMemory.NVDIMM-N.Persistence
Applies to
Windows 11 Client x64
Description:
Platforms supporting NVDIMM-N devices must appropriately trigger save / restore operations across planned and
unplanned power cycles of the system. It is expected that data will be persisted upon power loss, provided the device
indicated to be armed and ready for a back-up at the time of power loss.
Note: It is highly recommended that persistence is achieved by implementing ADR support in the platform.
System.Fundamentals.SystemAudio
System.Fundamentals.SystemAudio.Audio
Systems contain audio devices that conform to Windows Logo requirements.
Description
Devices that support Windows Assistants or Multiple Voice Assistant with Hardware Keyword Spotter must make sure
that the system enters HWDRIPS on paused audio streams.
Modern Standby Voice Activation Power Test on DC-power Source and Modern Standby Voice Activation Power Test
on AC-power Source tests will:
Page 176 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
a) Create a paused audio render stream on every render endpoint in the system
b) Arm all of the keyword detectors in the system using VoiceActivationManager
c) Check that system meets below requirements from Modern Standby Basic Requirement Test
Modern Standby Basic Requirement Test will be run with a simulated battery and software power button. Success
criteria is based on meeting the following metrics:
*A device with rotational hard disk drive (HDD) as its primary boot drive is excused from exit latency requirement
System.Fundamentals.SystemAudio.MicrophoneLocation
Microphone Location Reporting Requirement
Description
• All active onboard fixed-position single element microphones and onboard fixed-position microphone
arrays (multiple combined elements) on a system must be available for independent capture.
• Systems with no onboard fixed-position microphone arrays, but with multiple onboard fixed-position
microphones (e.g. Front/Back), AND no combined microphone, must have exactly one with GeoLocation
= “Front” (which will be set as the default microphone on that system).
• Systems with multiple onboard fixed-position microphone arrays must have exactly one with
GeoLocation = “Front.”
• Mic arrays with “n” elements must deliver RAW audio to the system. The RAW format must have “n”
channels, and data must come directly from the mic elements, free of signal processing.
• If a microphone and a camera are physically co-located onboard then stated location information for
each must match.
• For devices with multiple onboard fixed-position microphones or multiple arrays, the names of these
endpoints should be unique on the system. To specify a unique name, there are a few different
methods using KSPROPERTY_PIN_NAME, IPinName and .inf pin description name GUID registration.
System.Fundamentals.SystemAudio.SystemUsesHDAudioPinConfigs
System uses the HD Audio device pin configuration registers to expose logical devices supported by the Windows UAA
HD Audio class driver.
Page 177 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
Applies to Windows 11 Client x64
Description
If the PnP ID of an HD Audio device matches as compatible with any of the audio class drivers packaged with
Windows, the device must provide basic functionality for all of its endpoints when using that driver. Audio device
must follow Microsoft HD Audio pin configuration programming guidelines and expose devices divided into areas
based on audio device hardware functionality resources.
See the Pin Configuration Guidelines for High Definition Audio Devices white paper at
http://go.microsoft.com/fwlink/?LinkId=58572.
System.Fundamentals.SystemAudio.AudioProcessingObjects
System audio will continue to work safely without the presence of some or all Audio Processing Objects
Description
All systems need to safely function without the presence of all or some of the provided Audio Processing Objects. The
hardware system (including the Audio Codec, DSP and peripheral system audio endpoint (analog or digital)) must
default to an operating mode that will not cause damage to the physical system hardware and provide an acceptable
baseline audio experience. In addition, each Audio Processing Object must function in isolation as there is no
guarantee that other Audio Processing Objects will be loaded.
System.Fundamentals.SystemPCIController
System.Fundamentals.SystemPCIController.PCIRequirements
System devices and firmware meet PCI requirements
Applies to
Description
All PCI Express devices must comply with the PCI Base Express Specification 1.1 or later unless specified otherwise
below.
System firmware disables the extended (non-VC0) virtual channels in PCI Express devices.
The system firmware sets the VC enable bit (PCI Express Base Specification, Revision 1.0a, Section 7.11.7, "VC
Resource Control Register: bit 31") to 0 for all extended (non-VC0) virtual channels in all PCI Express devices. This
requirement does not apply to PCI Express High Definition Audio controllers, which use class code 04 and
subclass code 03.Because extended support for VC hardware is optional, this requirement addresses the scenario
in which incompatible VC hardware implementations might cause system reliability, stability, and performance
issues. Hardware vendors are encouraged to work with Microsoft to define the future direction of extended virtual
channel support.
System firmware for PCI-X Mode 2 capable and PCI Express systems implements MCFG table for
configuration space access. PCI-X Mode 2-capable and PCI Express systems must implement the MCFG ACPI table in
PCI Firmware. Specification, Revision 3.0.The configuration space of PCI-X Mode 2 and PCI Express devices must be
accessible through the memory-mapped configuration space region defined in this table.
Virtual bridges that comply with PCI Express also comply with PCI-to-PCI Bridge Architecture Specification, Revision
1.1. In addition, VGA 16-bit decode (Section 3.2.5.18, "Bridge Control Register, bit 4") and SSID and SSVID (Section
3.2.5.13) from PCI-to-PCI Bridge Architecture Specification, Revision 1.2, must also be supported.
SSID and SSVID support is not required until January 1, 2011. If implemented, SSID and SSVID must meet the
specification. SSVID is not required for PCIe to PCI/PCI-X bridges.
x64-based system provides 64-bit support in PCI subsystem. For x64-based systems, all PCI bridges on the system
board must support dual-access cycle (DAC) for inbound access, and DAC-capable devices must not be connected
below non-DAC-capable bridges, such as on adapter cards.
All 64-bit adapters must be DAC capable. This DAC requirement does not apply to outbound accesses to PCI devices.
However, for systems in which DAC is not supported on outbound accesses to PCI devices, the system firmware must
not claim that the bus aperture can be placed above the 4-GB boundary.
System.Fundamentals.SystemUSB
This section contains requirements for systems with USB host controllers.
System.Fundamentals.SystemUSB.ExternalUSBonCSisEHCIorXHCI
External USB ports on system that support modern standby must be EHCI or XHCI
Description
USB host controllers on systems that support Modern Standby must implement xHCI (eXtensible Host Controller
Interface) or EHCI (Enhanced Host Controller Interface). Legacy companion controllers (UHCI/OHCI) are not
supported.
Page 179 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
All exposed ports must support all speeds slower than the maximum speed of the host controller, to enable support
of legacy devices including keyboards and mice.
Required Speed Support EHCI Port (USB 2.0) XHCI Port (USB 3.x)
Low-Speed Yes Yes
Full-Speed Yes Yes
Hi-Speed Yes Yes
Super-Speed No Yes
Transaction translators (TTs), integrated with the EHCI host controller, are not standardized, but the Windows EHCI
driver supports serveral implementations of a controller- integrated TT. The supported integrated TT implementation
must be identified in ACPI using the _HRV hardware revision for the USB controller. Please contact the USB team to
determine if your implementation is supported and for more information about which _HRV value should be reported.
If the USB EHCI controller does not feature an integrated TT, any externally exposed ports must be routed through an
embedded rate-matching hub.
For improved power efficiency and performance, USB Host Controllers on systems that support Modern Standby are
recommended to be at least USB 3.x compatible, with an XHCI controller integrated into the SoC or chipset. The
operating system supports standard EHCI and XHCI controllers including debug registers.
System.Fundamentals.SystemUSB.SuperSpeedCapableConnectorRequirements
Each exposed SuperSpeed capable connector supports SuperSpeed, high, full and low speed USB devices routed through
its xHCI controller.
Description
xHCI Controllers are backwards compatible with SuperSpeed, high, full, and low speed USB devices. Backwards
compatible is defined as all USB devices enumerate and function at their intended speeds. More than one xHCI
controller may be present on a system as long as the SuperSpeed capable ports are correctly routed. EHCI controllers
may also be present on the system; however, SuperSpeed capable ports should not be routed through them.
In general, it is a best practice to route SuperSpeed, high, full, and low-speed device connections through the same
xHCI controller. However, it is permitted to route the SuperSpeed connections to one xHCI controller and high, full,
and low speed connections to a second xHCI controller. The high, full and low speed connections shall not be routed
Page 180 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
to a non-xHCI controller, and the port routing shall not change in normal operation, for example: system reboot,
hibernate, or disable/enable of the controller.
System.Fundamentals.SystemUSB.SystemExposesUSBPort
Systems are recommended to expose at least one user-accessible USB port.
Description
Systems are recommended to expose at least one external USB host port. If a system exposes such port(s), the
following requirement applies.
USB ports must be correctly described in ACPI with the _UPC (USB Port Capabilities) package type parameter as
defined in the ACPI 6.1 specification, section 9.14. This information allows Windows to determine when a USB-C port
is exposed, or when a micro-A/B port is exposed (meaning ID pin detection is necessary).
If the system's form factor is too thin to expose a standard USB A port, it is recommended to expose a Type-C port
and acceptable to expose a micro-A/B port. See the table below for the complete list of options.
While USB 2.0 capable controllers are acceptable, USB 3.1 XHCI host controllers are preferred. The USB ports must
fully comply with the USB 3.1 or USB 2.0 specification. USB 3.1 connectors must properly support 900mA USB 3.1
devices, and 500 mA USB 2.0 and 1.1 devices. USB 2.0 ports must properly support 500 mA USB 2.0 and 1.1 devices.
It is optional to include an adapter that converts the port from micro USB or USB Type-C to USB A. If you bundle an
adapter, the adapter capabilities must match that of the exposed connector of the USB host controller.
A Standard-A-to-A cable defined as defined by the USB 3.1 specification can be used to expose XHCI host debug
transport from a Standard USB-A port. These ports must tolerate being back-powered and it is strongly
recommended that the standard USB A port provide built-in protection against a short on the VBus line., which can
If a system exposes multiple Dual Role capable ports, only one port should in function mode at any given time. If the
micro-USB B port provides no additional functionality beyond debugging, it must be hidden in the battery
compartment or behind a easily removable cover. In order to comply with USB-IF requirements, VBUS must not be
asserted on the micro-A/B port until the resistance to ground of the ID pin of the micro-USB A/B port is less than 10
Ohms. This will prevent a short-circuit when a user connects a micro-USB B cable to another USB host, such as a
desktop. Alternatively, the port can implement short protection circuitry for VBus.
System.Fundamentals.SystemUSB.TestedUsingMicrosoftUsbStack
Systems with USB host or function controllers must be tested with Microsoft's USB drivers installed.
Description
Systems with USB host or function controllers must be tested with Microsoft's USB drivers installed and enabled.
Any system using a USB host or function controller, for example, xHCI, xDCI or a dual-role controller in device role,
must ship using Microsoft’s inbox USB drivers. Additionally if a system ships with dock that has an xHCI controller,
that dock must use Microsoft’s xHCI drivers.
System.Fundamentals.SystemUSB.USBDevicesandHostControllersWorkAfterPowerCycle
All USB devices and host controllers work properly upon resume from sleep, hibernation or restart without a forced reset
of the USB host controller.
Description
Design Notes:
Registry key ForceHCResetOnResume documented at the KB below is not needed for devices to function properly
upon resume in Windows 7 or newer.
http://support.microsoft.com/kb/928631
Note that a known set of currently existing devices do require a forced reset upon resume, these devices should be
covered in a list kept by the OS which will reset these devices upon resume. The goal of this requirement is to ensure
that this list of devices which need a reset to appear after resume does not grow and that devices can properly handle
sleep state transitions without being reset.
A reset of the entire USB Host Controller results in significantly increased time that it takes for all USB devices to
become available after system resume since there could be only one device at address 0 at a time, this enumeration
has to be serialized for all USB devices on the bus. We have also seen that resetting the host controller can lead to an
illegal SE1 signal state on some host controllers, which in turn can cause some USB devices to hang or drop off the
bus. Moreover, devices cannot maintain any private state across sleep resume as that state will be lost on reset.
System.Fundamentals.SystemUSB.USB4
This section contains requirements for systems that support USB4.
System.Fundamentals.SystemUSB.USB4.BiosHandoff
Systems with USB4 Host Routers must support TBD bios handoff mechanism.
Applies to Windows 11 Client x64
Description Systems with USB4 Host Routers must support bios handoff per update to the ACPI 6.4 specification
(Advanced Configuration and Power Interface (ACPI) Specification — ACPI Specification 6.4 documentation (uefi.org)),
section 6.2.11.2 Platform-Wide OSPM Capabilities. The system must grant control of "Native USB4 Support" in
Platform-Wide OSPM Capabilities (UUID: 0811B06E-4A27-44F9-8D60-3CBBC22E7B48) for OS versions that support
Software CM. The control is granted when _OSC is called by OS with Query Flag set to 0 and "Native USB4 Support"
set to 1.
On OS downgrade to an OS that does not support software connection manager, when the _OSC method is called
with Query Flag set to 0 and "Native USB4 Support" set to 0, the platform must switch to firmware CM if supported in
the system.
System.Fundamentals.SystemUSB.USB4.SupportDisplayPortAlternateMode
Systems that support USB4 must support DP alternate mode on all exposed USB4 ports.
Description
Page 183 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
Systems that incorporate a USB4 Host Router and support external user connectable USB4 port(s) must support
DisplayPort (DP) Alternate Mode on all exposed USB4 connectors in accordance with the Power Deliver Specification
and the VESA specification for DisplayPort Alternate Mode on USB Type-C Connector Standard.
A broad ecosystem of USB Type-C DP Alternate Mode compatible hosts and peripherals exists today, and DP
“dongles” are becoming ubiquitous as USB Type-C quickly replaces legacy display connections on mobile computing
devices. Users will expect these peripherals to continue to work with their new USB4 enabled systems and will not
appreciate the difference between a DP tunnel and DP Alternate Mode if USB4 hosts do not interoperate with them.
Thus, with the goal of maximizing compatibility with the existing ecosystem of USB Type-C DisplayPort Alternate
Mode peripherals, all systems supporting USB4 must support DisplayPort Alternate Mode on all exposed USB4
connectors.
Implementation Notes:
- It is expected that the most feasible method to implement DP Alternate Mode on a USB4 port is in the USB4
Host Router silicon, although it may also be achievable via other means.
- Each USB4 port must support DisplayPort alternate mode, but they need not necessarily all operate
simultaneously. If for example the host system’s GPU supports fewer display outputs than there are USB4
ports, the display streams may only be available on a first-come, first-serve basis.
System.Fundamentals.SystemUSB.USB4.SupportPCIeTunneling
Systems that support USB4 must support PCIe Tunneling on all exposed USB4 ports.
Description
Systems that incorporate a USB4 Host Router and support external user connectable USB4 port(s) must support PCI
Express (PCIe) tunneling on all exposed USB4 connectors in accordance with chapter 11 of the USB4 Specification and
the PCI Express Specification.
Extensibility of PCIe via the USB4 connector enables scenarios such as external graphics processing units (GPUs) and
high-performance storage and is a key motivator of the USB4 technology. Users will expect their USB4 docks and
peripherals with PCIe functions to work on any USB4 host. Thus, with the goal of maximizing compatibility across the
ecosystem, all systems that support USB4 on external connector(s) must support tunneling the PCIe protocol.
System.Fundamentals.SystemUSB.USB4.SupportThunderboltCompatibility
Systems that support USB4 must support backwards compatibility with Thunderbolt® 3.
Description
USB4 is an evolution of the TBT3 technology, using the same connector and filling many of the same high-
performance requirements for users. As such, they will expect their existing TBT3 compatible peripherals to continue
to function on their new USB4 enabled system. Thus, with the goal of maximizing compatibility with the existing TBT3
cable and peripheral ecosystem, all systems that support USB4 on external connector(s) must support interoperability
with TBT3 Device Routers and cables.
System.Fundamentals.SystemUSB.USB4.TestedUsingMicrosoftUsbStack
Systems with USB4 Host Routers must be tested with Microsoft's USB4 driver stack installed.
Description
Systems with USB4 Host Routers must be tested with Microsoft’s USB4 Host Router driver stack installed and enabled.
Any system implementing USB4 must ship with Microsoft’s inbox USB4 stack. Additionally, if a system ships with a
USB4 dock or hub, that device must also use Microsoft’s USB4 Device Router driver stack.
System.Fundamentals.SystemUSB.USB4.AllTypeCPortsSupportUSB4
Systems that support USB4 must support USB4 on all user-accessible USB Type-C connectors.
Description
A system that supports USB4 must support it on all user-accessible USB Type-C connectors or clearly mark the
connectors to indicate to the user which connectors support USB4. Consumers will expect their USB4 devices to just
work with their PC or host device that supports USB4 and may plug it into any matching USB Type-C connector on
their system. It is strongly encouraged to support USB4 on all user-accessible USB Type-C connectors so that the user
experience is consistent and seamless, but if this is not possible, the system must clearly indicate to the user which
connectors to use with their USB4 peripherals.
System.Fundamentals.SystemUSB.USB4.HostRouterACPINames
Systems with USB4 Host Routers described in ACPI must assign unique numerical identifiers
Description
Systems with ACPI-described USB4 Host Routers must set the last character of each device’s ACPI name to a
numeric digit in the range 0-7 (inclusive) that is unique across all USB4 Host Routers integrated into the
system. Per ECN 11241 (usb.org) to the USB4 specification, the USB4 Configuration Manager (CM) uses a 4-bit field in
the DPCD register to communicate to the GPU which USB4 Host Router instance is tunneling the DisplayPort
stream. Graphics software will retrieve this identifier via the GPU and use it to locate and establish a relationship with
the USB4 CM in order to coordinate power management.
System.Fundamentals.SystemUSB.USB4.PlatformUSBCapabilities
Systems that support USB4 must support OS capabilities for USB
Description
Systems with USB4 Host Routers must support _OSC for USB Capabilities (UUID: 3A0D13A-26AB-486C-9C5F-
0FFA525A575A) in platform scope as per ACPI 6.4 (TBD ECN) specification, section 6.2.11.3 Operating System
Capabilities for USB. The system must always grant control for USB Tunneling, DisplayPort Tunneling and Inter-
domain USB4 Internet Protocol upon the _OSC execution by OS for Software CM to function normally.
Should the platform choose to disable USB4 PCIe tunneling, it must do so by setting PCI Express Tunneling to 0 when
_OSC method is executed.
System.Fundamentals.SystemUSB.USB4.GraphicsDriverMustSupportUSB4
Systems that support USB4 must support a USB4 capable graphics driver
Description
System.Fundamentals.SystemUSB.USB4.TunneledUSB3PortMapping
Systems with USB4 Host Routers must support _DSD to report USB3 – USB4 port mapping to Windows.
Description
Systems with USB4 Host Routers must support _DSD on the USB4 Host Router device or the _DSD ACPI method as
defined here to map tunneled native protocol ports (USB3) to the correct USB4 Host Router. This enables Windows
to enumerate the correct dependencies between the tunneled protocols and the USB4 Host Routers on the system.
System.Fundamentals.SystemUSB.USB4.TunneledPCIePortMapping
Systems with USB4 Host Routers must support _DSD to report PCIe – USB4 port mapping to Windows.
Description
Systems with USB4 Host Routers must support _DSD on the USB4 Host Router device or the _DSD ACPI method as
defined here to map tunneled native protocol ports (PCIe) to the correct USB4 Host Router. This enables Windows to
enumerate the correct dependencies between the tunneled protocols and the USB4 Host Routers on the system.
Note: In the first Windows release supporting the USB4 Software CM, USB4 capable systems must describe their
tunneled protocol mappings using the _DSD method in ACPI. Support for PCIe add-in cards with DVSEC-described
mapping will not be supported until a later release.
System.Fundamentals.SystemUSB.USB4.USB3HostController
USB3 tunneled devices on USB4 systems should pass USB3 xHCI requirements.
Description
Page 187 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
USB3 devices connected over USB4 will make use of the xHCI controller and must be tested against USB3 host
controller requirements.
System.Fundamentals.SystemUSB.USBC
System.Fundamentals.SystemUSB.USBC.USBTypeCCharging
USB Type-C Charging cases are supported.
Description
If a System contains a USB Type-C port that can be used to charge the system, that port must support the following
requirements addition to the USB Type-C and PD specs:
• If the system ships with or is sold with a Type-C charger, the system must be able to charge from a dead
battery using that charger.
• For multiple USB Type-C port systems, it is recommended that all USB Type-C ports on the system can
be used to charge the system to reduce user confusion.
System.Fundamentals.SystemUSB.USBC.USBTypeCCertifiedCables
USB Type-C Systems and Devices that ship with Cables ship with certified cables
Description
If a system or device is USB Type-C and ships with a USB Type-C cable or an adapter, the cable and/or adapter must
be USB-IF certified.
In addition, if the USB Type-C cable or adapter is used for an Alternate Mode Standard and the industry group that
owns that Standard has a corresponding certification, the cable or adapter must get that certification.
System.Fundamentals.SystemUSB.USBC.USBTypeCUCM
USB Type-C systems must support UCM
Description
This requirement applies to systems that support Power Delivery or Dual Role or Alternate Modes.
Systems with local USB-C ports (e.g. directly on the system compared to on a detachable or separate device or dock)
that do not implement UCSI or UcmTcpci must ship with a 3rd-party UcmCx client driver.
3rd-party UcmCx client drivers must be implemented as per the following MSDN documentation:
• https://msdn.microsoft.com/en-us/library/windows/hardware/mt188011(v=vs.85).aspx
• UcmInitializeDevice
• UcmConnectorCreate
• UcmConnectorTypeCAttach
• UcmConnectorTypeCDetach
• UcmConnectorTypeCCurrentAdChanged
• UcmConnectorChargingStateChanged
If the system or controller supports Power Delivery, the following additional APIs must be implemented:
1. UcmConnectorPowerDirectionChanged
2. UcmConnectorPdSourceCaps
3. UcmConnectorPdPartnerSourceCaps
4. UcmConnectorPdConnectionStateChanged
If the system or controller exposes dual role ports, the following additional APIs must be implemented:
• UcmConnectorDataDirectionChanged
System.Fundamentals.SystemUSB.USBC.USBTypeCUCMTCPCI
USB Type-C systems that support UCMTCPCI must implement it correctly
Terms: If-Implemented
Description
This requirement applies to systems that support Power Delivery or Dual Role or Alternate Modes.
Page 189 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
Systems with local USB-C ports that have Type-C Port Controller(s) but do not have Type-C Port Manager silicon that
provides the Type-C policy engine and protocol layer should implement a UcmTcpciCx client driver.
If the system implements UcmTcpci, the UcmTcpciCx client driver is required to implement the following APIs:
1. UcmTcpciPortControllerCreate
2. UcmTcpciPortControllerSetHardwareRequestQueue
3. UcmTcpciPortControllerStart
4. UcmTcpciPortControllerAlert
If the system has a battery, supports PD charging, and implements UcmTcpci, it must have silicon that handles PD
charging before the OS has started.
System.Fundamentals.SystemUSB.USBC.USBTypeCUCSI.USBTypeCUCSI
USB Type-C Systems that support UCSI must implement USCI correctly
Description
This requirement applies to systems that support Power Delivery or Dual Role or Alternate Modes.
Systems with local USB-C ports (e.g. directly on the system compared to on a detachable or separate device or dock)
that have an Embedded Controller which implements PD policy should implement UCSI.
If the system implements UCSI, it must implement UCSI v1.0 (or later). It must specify the UCSI version number that is
implemented in the VERSION field of the UCSI data structure. In addition, the system must implement the following
optional features from the UCSI spec.
Commands
• GET_ALTERNATE_MODES
• GET_CAM_SUPPORTED
• GET_PDOS
• GET_CABLE_PROPERTY
• SET_NOTIFICATION_ENABLE
o The system or controller must support the following notifications within this command:
• GET_CONNECTOR_STATUS
Page 190 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
o The system or controller must support the following Connector Status Changes within this
command:
System.Fundamentals.SystemUSB.XhciBiosHandoffFollowsSpec
xHCI BIOS handoff follows specification
Description
For all xHCI controllers exposed to the OS, the system firmware must follow the BIOS handoff procedure defined in
section 4.2.2.1 of the XHCI specification.
System.Fundamentals.SystemUSB.XHCIControllersMustHaveEmbeddedInfo
Systems with xHCI controllers must have embedded ACPI information for port routing.
Description
All connectable USB ports are required to have a _PLD object. In addition, two fields in the _PLD object: Group token
(Bit 86:79) and Group Position (Bit 94:87) should be correctly defined for all USB connection points, including those
that are not visible externally (which should be indicated by setting bit 64 to zero).
No two USB connection points should have identical combination of Group token and Group Position. If two ports are
sharing a connection point, they should have identical _PLD objects. If the connection point is a Type C connector, the
_PLD specified for that connector under the UCSI node must match the _PLD specified under the USB controller node.
If the USB controller is a dual role controller that uses the inbox USB Role Switch (URS) driver, then the same _PLD
object for the connector should be specified under both USB Host and USB Function.
This information helps define the mapping of USB ports to uniquely identifiable connection points. The Windows USB
3.x stack will use this information to determine which ports are tied to the same connection points. Any USB port that
does not have a _PLD object will be assumed to be not connectable and not visible (i.e. it is not being used at all). The
definition of connectable port as per ACPI 6.1 spec (section 9.14), is a port on which either a user can connect a device
OR there is an integrated device connected to it.
Please see design notes for additional information on how to implement this requirement.
Design Notes:
Example
This example is based on xHCI Spec (Version .95) Appendix D. The hardware configuration is exactly the same as in
that Appendix. The ACPI representation of that hardware configuration differs in this example; those differences are
highlighted.
The following is an example of the ACPI objects defined for an xHCI that implements a High-speed and SuperSpeed
Bus Instance that are associated with USB2 and USB3 Protocol Root Hub Ports, respectively. The xHCI also supports an
integrated High-speed hub to provide Low- and Full-speed functionality. The External Ports defined by the xHC
implementation provide either a USB2 data bus (i.e. a D+/D- signal pair) or a SuperSpeed (or future USB speed) data
bus (i.e. SSRx+/SSRx- and SSTx+/SSTx-signal pairs).
Where:
• The xHCI implements a High-speed Bus Instance associated with USB2 Protocol Root Hub ports, e.g. HCP1
and HCP2 are High-speed only, i.e. they provide no Low- or Full-speed support.
• The xHCI presents 7 External Ports (P1 - P7):
• P5 is attached to motherboard connector C5, providing the LS/FS/HS support to the motherboard USB3
connector C5.
• External Port 6 (P6) is attached to the SuperSpeed logical hub of the Embedded USB3 Hub on the
motherboard. The SuperSpeed logical hub supports the SS connections of 2 ports (EP1 - EP2).
• The SuperSpeed connections of motherboard hub ports EP1 and EP2 are attached to motherboard
connectors C3 and C4 respectively, providing the SS support for the USB3 connectors.
• External Port 7 (P7) is attached to motherboard connectors C5, providing the SS support for the USB3
connector.
• The xHCI implements 4 internal HS Root Hub ports (HCP1 - HCP4), 2 High-speed and 2 SuperSpeed:
• Ports 1 to 4 (IP1-IP4) of the Integrated Hub attach to External Ports 2 to 5 (P2-P5), respectively.
• Internal Ports 3 and 4 (HCP3, HCP4) attach to External Ports 6 and 7 (P6, P7), respectively.
• All connectors are located on the back panel and assigned to the same Group.
• Connectors C1 and C2 are USB2 compatible and their color is not specified. Connectors C3 to C5 are USB3
compatible and their color is specified.
• External Ports P1 - P5 present a USB2 data bus (i.e. a D+/D- signal pair). External Ports P6 and P7 present a
SuperSpeed data bus (i.e. SSRx+/SSRx- and SSTx+/SSTx- signal pairs).
Scope( \_SB ) {
Device( PCI0 ) {
} // Device( USB0 )
//
// Define other control methods, etc.
} // Device( PCIO )
} // Scope( \_SB )
System.Fundamentals.SystemUSB.XhciSupportsMinimum31Streams
xHCI controller must support at least 31 primary streams per endpoint.
This requirement is for the MaxPSASize in the HCCPARAMS to be set to 4 at the minimum to enable ultimate data
transfer rate with UAS devices.
Storage devices based on the USB Attached SCSI Protocol (UASP) will utilize streams to achieve faster data transfer
rates. To enable the best experience with these devices, every xHCI controller will need to support at least 31 primary
streams.
System.Fundamentals.TPM20
System.Fundamentals.TPM20.TPM20
All systems as specified below must contain an HLK certified TPM 2.0 device
1. Mandatory: All systems must contain a TPM 2.0, and the TPM 2.0 must be both available to the system and
enabled in the shipping configuration.
2. Mandatory: The TPM 2.0 must be a model and firmware certified under
Device.TrustedPlatformModule.TPM20.
3. Mandatory: The TPM 2.0 must have associated EK Certificates compliant with
Device.TrustedPlatformModule.TPM20.EKCert
4. Mandatory: Systems should not add undue overhead to the performance of TPM commands. The system
should not add more than 10ms overhead to TPM commands. Individual performance requirements for
many TPM commands are enumerated in the Device.TrustedPlatformModule requirements for TPM vendors.
5. Recommended: The System should not provide a mechanism to put the TPM in a state where it is visible to
Windows but disabled or with hierarchies disabled.
6. Recommended: The TPM Interrupt PIN should be connected to an Interrupt Controller and the System
should configure this Interrupt Controller to allow interrupts. This requirement applies to discrete TPM
devices only.
a. Informative: OEM’s can enable interrupt support through the registry settings and can submit the
HLK results with Interrupts enabled.
7. For Server Only: For all server systems based on silicon platforms introduced to the market after January 1, 2021
these requirements become Mandatory and the TPM 2.0 must be installed and enabled.
System.Fundamentals.TPM20.PlatformSpecifications
All platforms which contain a TPM 2.0 must meet these functionality requirements for proper operation of the TPM.
1. Mandatory: The platform shall comply with “TCG PC Client Platform Firmware Profile Specification for TPM
Family 2.0 Level 00 Revision 1.04” dated June 3rd, 2019.
2. Mandatory: The platform shall comply with Trusted Computing Group “TCG EFI Protocol Specification” for
Family “2.0”, denoted “Level 00 Revision 00.13”, dated March 30, 2016 including Errata Version 0.5
3. Mandatory: The platform shall comply with the requirements defined in Trusted Computing Group, "TCG
ACPI Specification”, “Version 1.3 Revision 8” dated August 5, 2021.
4. Mandatory: The platform must comply with the Trusted Computing Group “Physical Presence Interface
Specification”, Version 1.30, Revision 00.52. Dated July 28, 2015 along with “Errata for Physical Presence
Interface Specification” Version 0.4 dated September 29, 2017
5. Mandatory: The platform must comply with the Trusted Computing Group. “Platform Reset Attack
Mitigation Specification”, Version 1.10 revision 17 Dated January 21, 2019.
System.Fundamentals.TPM20.PlatformConfiguration
All platforms which contain a TPM 2.0 must meet these functionality requirements for proper operation of the TPM.
1. Mandatory: During the boot sequence, the boot firmware/software shall measure all firmware and all software
components it loads after the core root of trust for measurement is established. The measurements shall be
logged as well as extended to platform configuration registers in a manner compliant with the requirements
in System.Fundamentals.TPM20.PlatformSpecifications.
2. Mandatory: The measurements must be implemented such that they reliably and verifiably allow a third party to
identify all components in the boot process up until the point either the boot finished successfully or when
software with an exploited vulnerability was loaded.
a) For example, if the third component loaded includes an exploited vulnerability, then values for the
first, second, and third component in the trusted boot log correctly reflect the software that loaded
but any values after that may be suspect.
System.Fundamentals.USBBoot
The feature and requirements are about being able to boot from a USB device.
System.Fundamentals.USBBoot.BootFromUSB
System firmware supports booting from all exposed USB 1.x, 2.x, and 3.x ports
Description
The system must also support booting Windows PE images from a USB 2.0 device by using extended INT 13 or UEFI
native interface in less than 90 seconds.
Design Notes:
OEMs are encouraged to test the boot functionality by creating a bootable USB flash drive with WinPE. See the OPK
for details. Vendors may license WinPE (at no charge). For information, send an e-mail to [email protected].
System.Fundamentals.USBBoot.SupportSecureStartUpInPreOS
Systems support secure startup by providing system firmware support for writing to and reading from USB flash devices
in the pre-operating system environment.
Page 203 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
Applies to Windows 11 Client x64
Description
On all UEFI systems and all systems that implement a TPM, the system must support BitLocker recovery and strong
authentication scenarios. This is accomplished by enabling enumeration and full-speed reading/ writing of data (such
as key backup and recovery information) from and to a USB mass storage class device, and the UEFI firmware will
provide an instance of the block I/O protocol for access to these USB devices.
Design Notes:
See the USB Mass Storage Class Bulk-Only Transport and the USB Mass Storage Class UFI Command specifications,
downloadable from http://go.microsoft.com/fwlink/?LinkId=58382.
System.Fundamentals.USBDevice
These requirements apply to USB devices that are integrated into a system.
System.Fundamentals.USBDevice.SelectiveSuspend
All internally connected USB devices must support selective suspend by default.
Description
Selective suspend is an important power saving feature of USB devices. Selective suspension of USB devices is
especially useful in portable computers, since it helps conserve battery power.
If a USB device is internally connected, the device driver must enable selective suspend by default. Every USB device
driver must place the device into selective suspend within 60 seconds of no user activity. This timeout should be as
short as possible while maintaining a good user experience. The selective suspend support can be verified by
reviewing the report generated by the powercfg -energy command.
Implementation Notes:
When devices enter selective suspend mode, they are limited to drawing a USB specification defined 2.5mA of current
from the USB port. It is important to verify that devices can quickly resume from selective suspend when they are
required to be active again.
For more information about enabling selective suspend for HID devices, please refer to this MSDN article
http://msdn.microsoft.com/en-us/library/ff538662(VS.85).aspx
For more information about how to implement selective suspend in a driver, please refer to this white paper:
http://www.microsoft.com/whdc/driver/wdf/USB_select-susp.mspx
To specify a port that is internal (not user visible) and can be connected to an integrated device, the ACPI properties
_UPC.PortIsConnectable byte must be set to 0xFF and the _PLD.UserVisible bit must be set to 0. More details are
available on MSDN.
System.Fundamentals.Video
System.Fundamentals.Video.HDRStreamingDisplayCharacteristics
All system with an 8-bit, SDR integrated display that is designed to support HDR video streaming must be provisioned
with the display characteristics required by Windows to enable the feature.
Description
Starting with Windows 10, version 1703, Windows support HDR video content playback and streaming on high-end
systems with SDR integrated displays with a peak brightness of 300 nits or greater. To enable this feature, OEM must
provision the system with the brightness and color characteristics of the integrated SDR panel on the device. The
following characteristics must be accurately provisioned by the OEM so they are available the OS to enable the
feature:
1. Max Luminance // 10% screen area
2. Min Luminance // black level
3. Max Full Frame Luminance // e.g. max ‘paper white’
4. Chromaticities of Primaries (i.e., red, green, and blue primaries)
5. Chromaticity of white point // default D65
The colorimetry data reported to the OS deviate from the actual panel color characteristics by no more than 1.0 CIE
Delta E 2000 (DE00); this applies for all reported values.
In RS3, OEM can provision these display colorimetric values by choosing from one of three methods:
Please see HDR and WCG Ecosystem Guidance for Windows documents for complete details of these three options.
System.Fundamentals.WatchDogTimer
A watchdog timer is a device that provides basic watchdog support to a hardware timer exposed by the Microsoft
hardware watchdog timer resource table.
System.Fundamentals.WatchDogTimer.IfWatchDogTimerImplemented
If a Watch Dog Timer is implemented and exposed through a WDRT (supported for versions prior to Windows 8) or
WDAT (required for Windows 8 and later versions), it must meet Windows compatibility and functionality requirements.
Description
Hardware watchdog timer monitors the OS, and reboots the machine if the OS fails to reset the watchdog. The
watchdog must meet the requirements and comply with the specification in http://MSDN.microsoft.com/en-
us/windows/hardware/gg463320.aspx.
OS Auto Healing can be leveraged by the IHV and the OEM by adding the needed ACPI/BIOS changes, so that Wi-Fi
device has a defined way to be reset. This will help the OS to initiate device resets while collecting the necessary logs.
When is PLDR triggered? When OS detects that IHV driver or firmware is not responding and may be hung.
Software Support
• Current Windows WDI version is 1.1.6 and most new drivers are compliant
to that
3. UEFI /ACPI Definitions OEM/ODM needs to work with the BIOS/UEFI Vendor and Wi-Fi IHV to ensure
that the ACPI routines for resetting Wi-Fi device are supported in the BIOS.
Hardware Support