Thanks to visit codestin.com
Credit goes to www.scribd.com

0% found this document useful (0 votes)
73 views208 pages

Systems

yo

Uploaded by

Tre
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
73 views208 pages

Systems

yo

Uploaded by

Tre
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 208

Windows Hardware Compatibility

Specifications for Windows 11, version


22H2– Systems

Microsoft Confidential: Internal Use and Partners Under NDA Only


© 2022 Microsoft. All rights reserved. These materials are confidential to and maintained as a trade secret by
Microsoft Corporation. Information in these materials is restricted to Microsoft authorized recipients only. Any use,
distribution or public discussion of, and any feedback to, these materials is subject to the terms of the attached
license. By providing any feedback on these materials to Microsoft, you agree to the terms of that license.

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.Client.Sensor.General.PowerState .............................................................................................................................................. 100


System.Client.Sensor.General.StableReading ....................................................................................................................................... 100
System.Client.Sensor.Magnetometer ............................................................................................................................................................ 100

System.Client.Sensor.Magnetometer.DynamicRange ....................................................................................................................... 100


System.Client.Sensor.Orientation ................................................................................................................................................................... 101
System.Client.Sensor.Orientation.GyrometerPresent ........................................................................................................................ 101

System.Client.Sensor.Pedometer .................................................................................................................................................................... 101


System.Client.Sensor.Pedometer.EnumerationProperties ............................................................................................................... 101
Page 9 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.ProximitySensor ......................................................................................................................................................... 101
System.Client.Sensor.ProximitySensor.EnumerationProperties .................................................................................................... 101

System.Client.Sensor.HumanPresence ......................................................................................................................................................... 102


System.Client.Sensor.HumanPresence.SystemLevel .......................................................................................................................... 102
System.Client.Sensor.HumanPresence.PhysicalDeviceLocation .................................................................................................... 102

System.Client.Sensor.SimpleDeviceOrientation ....................................................................................................................................... 102


System.Client.Sensor.SimpleDeviceOrientation.PhysicalLocation ................................................................................................ 102
System.Client.SystemConfiguration .............................................................................................................................................................. 103

System.Client.SystemConfiguration.Windows10RequiredComponents ................................................................................... 103


System.Client.SystemImage .............................................................................................................................................................................. 103
System.Client.SystemImage.SystemRecoveryEnvironment ............................................................................................................ 103

System.Client.SystemPartition ......................................................................................................................................................................... 104


System.Client.SystemPartition.DiskPartitioning ................................................................................................................................... 104
System.Client.SystemPartition.OEMPartition ........................................................................................................................................ 104
System.Client.ScreenRotation .......................................................................................................................................................................... 105

System.Client.ScreenRotation.SmoothRotation .................................................................................................................................. 105


System.Client.Tablet.Graphics .......................................................................................................................................................................... 105
System.Client.Tablet.Graphics.SupportAllModeOrientations ......................................................................................................... 105

System.Client.WLAN.BasicConnectivity ........................................................................................................................................................ 106


System.Client.WLAN.BasicConnectivity.WlanBasicConnectivity ................................................................................................... 106
System.Client.WLAN.HangDetectionAndRecovery ................................................................................................................................. 107

System.Client.WLAN.HangDetectionAndRecovery.WlanHangDetectionAndRecovery (WDI Drivers Only) .............. 107


System.Client.WLAN.HostedNetwork ........................................................................................................................................................... 107
System.Client.WLAN.HostedNetwork.WlanHostedNetwork .......................................................................................................... 107

System.Client.WLAN.WiFiDirect ...................................................................................................................................................................... 108


System.Client.WLAN.WiFiDirect.WlanWiFiDirect ................................................................................................................................. 108
System.Client.WLAN.Miracast .......................................................................................................................................................................... 108

System.Client.WLAN.Miracast.WlanMiracast ........................................................................................................................................ 108


System.Fundamentals.DebugPort .................................................................................................................................................................. 108
System.Fundamentals.DebugPort.SystemExposesDebugInterface ............................................................................................. 108

System.Fundamentals.EnergyEstimation ..................................................................................................................................................... 109


System.Fundamentals.EnergyEstimation.Discretional ....................................................................................................................... 110
System.Fundamentals.Firmware...................................................................................................................................................................... 111

System.Fundamentals.Firmware.ACPI ...................................................................................................................................................... 111


System.Fundamentals.Firmware.FirmwareSupportsBootingFromDVDDevice ........................................................................ 114
Page 10 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.Firmware.FirmwareSupportsUSBDevices .................................................................................................. 114
System.Fundamentals.Firmware.HardwareMemoryReservation................................................................................................... 115

System.Fundamentals.Firmware.HSTI ...................................................................................................................................................... 115


System.Fundamentals.Firmware.NoExternalDMAOnBoot ............................................................................................................... 116
System.Fundamentals.Firmware.UEFIBitLocker .................................................................................................................................... 116

System.Fundamentals.Firmware.UEFIBootEntries ............................................................................................................................... 117


System.Fundamentals.Firmware.UEFICompatibility ........................................................................................................................... 117
System.Fundamentals.Firmware.UEFIDefaultBoot .............................................................................................................................. 118

System.Fundamentals.Firmware.UEFILegacyFallback ........................................................................................................................ 118


System.Fundamentals.Firmware.UEFISecureBoot ............................................................................................................................... 119
System.Fundamentals.Firmware.UEFITimingClass .............................................................................................................................. 123

System.Fundamentals.Firmware.Update ................................................................................................................................................. 124


System.Fundamentals.Firmware.OSRecovery ....................................................................................................................................... 124
System.Fundamentals.Firmware.Boot ........................................................................................................................................................... 127
System.Fundamentals.Firmware.Boot.EitherGraphicsAdapter ....................................................................................................... 127

System.Fundamentals.Firmware.Boot.SystemWithBootDeviceGreaterThan............................................................................ 128
System.Fundamentals.Firmware.CS ............................................................................................................................................................... 129
System.Fundamentals.Firmware.CS.CryptoCapabilities .................................................................................................................... 129

System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby ................................................................................ 131


System.Fundamentals.Firmware.KernelDMAProtection ........................................................................................................................ 133
System.Fundamentals.Firmware.KernelDMAProtection,KernelDMAProtection ..................................................................... 133

System.Fundamentals.Firmware.TPR ............................................................................................................................................................. 133


System.Fundamentals.Firmware.TPR.UEFIEncryptedHDD ............................................................................................................... 133
System.Fundamentals.Graphics....................................................................................................................................................................... 134

System.Fundamentals.Graphics.FirmwareSupportsLargeAperture .............................................................................................. 134


System.Fundamentals.Graphics.MicrosoftBasicDisplayDriver........................................................................................................ 134
System.Fundamentals.Graphics.DisplayRender ........................................................................................................................................ 135

System.Fundamentals.Graphics.DisplayRender.StableAndFunctional........................................................................................ 135
System.Fundamentals.Graphics.HybridGraphics ...................................................................................................................................... 135
System.Fundamentals.Graphics.HybridGraphics.MultiGPU ............................................................................................................ 135

System.Fundamentals.Graphics.InternalDisplay ....................................................................................................................................... 137


System.Fundamentals.Graphics.InternalDisplay.NativeResolution .............................................................................................. 137
System.Fundamentals.Graphics.MultipleDevice ....................................................................................................................................... 138

System.Fundamentals.Graphics.MultipleDevice.Configure ............................................................................................................. 138


System.Fundamentals.Graphics.RenderOnly ............................................................................................................................................. 139
Page 11 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.Graphics.RenderOnly.MinimumDirectXLevel .......................................................................................... 139
System.Fundamentals.HAL ................................................................................................................................................................................ 139

System.Fundamentals.HAL.IfCSRTPresent.............................................................................................................................................. 139
System.Fundamentals.HAL.HPETRequired ............................................................................................................................................. 140
System.Fundamentals.Input.............................................................................................................................................................................. 141

System.Fundamentals.Input.I2CDeviceUniqueHWID ........................................................................................................................ 141


System.Fundamentals.Input.PS2UniqueHWID ..................................................................................................................................... 141
System.Fundamentals.MarkerFile ................................................................................................................................................................... 142

System.Fundamentals.MarkerFile.SystemIncludesMarkerFile ........................................................................................................ 142


System.Fundamentals.Network ....................................................................................................................................................................... 143
System.Fundamentals.Network.NetworkListOffloads ....................................................................................................................... 143

System.Fundamentals.Network.PowerRequirements ........................................................................................................................ 143


System.Fundamentals.NX .................................................................................................................................................................................. 144
System.Fundamentals.NX.SystemIncludesNXProcessor .................................................................................................................. 144
System.Fundamentals.PowerManagement ................................................................................................................................................ 144

System.Fundamentals.PowerManagement.DockUndock ................................................................................................................ 144


System.Fundamentals.PowerManagement.Lid .................................................................................................................................... 145
System.Fundamentals.PowerManagement.MultiPhaseResume ................................................................................................... 145

System.Fundamentals.PowerManagement.PCSupportsLowPowerStates ................................................................................. 146


System.Fundamentals.PowerManagement.ModernStandby .............................................................................................................. 147
System.Fundamentals.PowerManagement.ModernStandby.Quality ......................................................................................... 147

System.Fundamentals.PowerManagement.PowerProfile ................................................................................................................ 148


System.Fundamentals.PowerManagement.Processor ...................................................................................................................... 148
System.Fundamentals.PowerManagement.ModernStandby.DirectedFx.Reliability ............................................................. 149

System.Fundamentals.PowerManagement.ModernStandby.Battery .............................................................................................. 149


System.Fundamentals.PowerManagement.ModernStandby.Battery.Quality .......................................................................... 149
System.Fundamentals.PXE ................................................................................................................................................................................. 150

System.Fundamentals.PXE.PXEBoot.......................................................................................................................................................... 150
System.Fundamentals.Reliability..................................................................................................................................................................... 151
System.Fundamentals.Reliability.SystemReliability ............................................................................................................................ 151

System.Fundamentals.Security ........................................................................................................................................................................ 151


System.Fundamentals.Security.CryptoOffloadHardware ................................................................................................................. 151
System.Fundamentals.Security.FIDO ........................................................................................................................................................ 152

System.Fundamentals.Security.DeviceEncryption ............................................................................................................................... 152


System.Fundamentals.Security.NoTDIFilterAndLSP ........................................................................................................................... 153
Page 12 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.Security.PlayReadyModule ............................................................................................................................. 153
System.Fundamentals.Security.SecureBiometrics ............................................................................................................................... 153

System.Fundamentals.Security.VirtualizationBasedSecurity.VirtualizationSupport .............................................................. 155


System.Fundamentals.Security.KernelHardwareEnforcedStackProtection ............................................................................... 156
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. ..................................................................... 156
System.Fundamentals.Security.AntiMalware ........................................................................................................................................ 157

System.Fundamentals.Security.DGCG .......................................................................................................................................................... 157


System.Fundamentals.Security.DGCG.CredentialGuard ................................................................................................................... 157
System.Fundamentals.Security.DGCG.HVCI .......................................................................................................................................... 158

System.Fundamentals.Security.SystemGuard ............................................................................................................................................ 160


System.Fundamentals.Security.SystemGuard ....................................................................................................................................... 160
System.Fundamentals.SignedDrivers ............................................................................................................................................................ 167
System.Fundamentals.SignedDrivers.BootDriverEmbeddedSignature ...................................................................................... 167

System.Fundamentals.SignedDrivers.DigitalSignature ..................................................................................................................... 168


System.Fundamentals.SMBIOS ........................................................................................................................................................................ 169
System.Fundamentals.SMBIOS.SMBIOSSpecification ....................................................................................................................... 169

System.Fundamentals.StorageAndBoot ...................................................................................................................................................... 170


System.Fundamentals.StorageAndBoot.BootPerformance............................................................................................................. 171
System.Fundamentals.StorageAndBoot.EncryptedDrive ................................................................................................................. 172

System.Fundamentals.StorageAndBoot.SATABootStorage ............................................................................................................ 173


System.Fundamentals.StorageClassMemory ............................................................................................................................................. 174
System.Fundamentals.StorageClassMemory ........................................................................................................................................ 174

System.Fundamentals.StorageClassMemory.1GibMappings ......................................................................................................... 174


System.Fundamentals.StorageClassMemory.INVDIMM.DSMCompliance ............................................................................... 175
System.Fundamentals.StorageClassMemory.INVDIMM.Label ...................................................................................................... 175

System.Fundamentals.StorageClassMemory.NVDIMMN.DSMCompliance ............................................................................. 175


System.Fundamentals.StorageClassMemory.NVDIMMN.Label .................................................................................................... 176
System.Fundamentals.StorageClassMemory.NVDIMMN.Persistence ........................................................................................ 176

System.Fundamentals.SystemAudio ............................................................................................................................................................. 176


System.Fundamentals.SystemAudio.Audio ........................................................................................................................................... 176
System.Fundamentals.SystemAudio.MicrophoneLocation ............................................................................................................. 177

System.Fundamentals.SystemAudio.SystemUsesHDAudioPinConfigs ...................................................................................... 177


System.Fundamentals.SystemAudio.AudioProcessingObjects...................................................................................................... 178
System.Fundamentals.SystemPCIController .............................................................................................................................................. 178

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.ExternalUSBonCSisEHCIorXHCI ............................................................................................ 179


System.Fundamentals.SystemUSB.SuperSpeedCapableConnectorRequirements ................................................................ 180
System.Fundamentals.SystemUSB.SystemExposesUSBPort ........................................................................................................... 181

System.Fundamentals.SystemUSB.TestedUsingMicrosoftUsbStack............................................................................................ 182
System.Fundamentals.SystemUSB.USBDevicesandHostControllersWorkAfterPowerCycle .............................................. 182
System.Fundamentals.SystemUSB.USB4 ..................................................................................................................................................... 183

System.Fundamentals.SystemUSB.USB4.BiosHandoff ...................................................................................................................... 183


System.Fundamentals.SystemUSB.USB4.SupportDisplayPortAlternateMode ........................................................................ 183
System.Fundamentals.SystemUSB.USB4.SupportPCIeTunneling ................................................................................................. 184

System.Fundamentals.SystemUSB.USB4.SupportThunderboltCompatibility .......................................................................... 184


System.Fundamentals.SystemUSB.USB4.TestedUsingMicrosoftUsbStack ................................................................................ 185
System.Fundamentals.SystemUSB.USB4.AllTypeCPortsSupportUSB4 ....................................................................................... 185
System.Fundamentals.SystemUSB.USB4.HostRouterACPINames ................................................................................................ 185

System.Fundamentals.SystemUSB.USB4.PlatformUSBCapabilities .............................................................................................. 186


System.Fundamentals.SystemUSB.USB4.GraphicsDriverMustSupportUSB4 ........................................................................... 186
System.Fundamentals.SystemUSB.USB4.TunneledUSB3PortMapping ...................................................................................... 187

System.Fundamentals.SystemUSB.USB4.TunneledPCIePortMapping ........................................................................................ 187


System.Fundamentals.SystemUSB.USBC ..................................................................................................................................................... 188
System.Fundamentals.SystemUSB.USBC.USBTypeCCharging ....................................................................................................... 188

System.Fundamentals.SystemUSB.USBC.USBTypeCCertifiedCables ........................................................................................... 188


System.Fundamentals.SystemUSB.USBC.USBTypeCUCM ................................................................................................................ 188
System.Fundamentals.SystemUSB.USBC.USBTypeCUCMTCPCI .................................................................................................... 189

System.Fundamentals.SystemUSB.USBC.USBTypeCUCSI.USBTypeCUCSI ................................................................................ 190


System.Fundamentals.SystemUSB.XhciBiosHandoffFollowsSpec ................................................................................................ 191
System.Fundamentals.SystemUSB.XHCIControllersMustHaveEmbeddedInfo ....................................................................... 191

System.Fundamentals.SystemUSB.XhciSupportsMinimum31Streams ....................................................................................... 199


System.Fundamentals.TPM20 .......................................................................................................................................................................... 200
System.Fundamentals.TPM20.TPM20 ...................................................................................................................................................... 200

System.Fundamentals.TPM20.PlatformSpecifications ....................................................................................................................... 201


System.Fundamentals.TPM20.PlatformConfiguration ...................................................................................................................... 201
System.Fundamentals.USBBoot ...................................................................................................................................................................... 203

System.Fundamentals.USBBoot.BootFromUSB .................................................................................................................................... 203


System.Fundamentals.USBBoot.SupportSecureStartUpInPreOS .................................................................................................. 203
Page 14 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.USBDevice .................................................................................................................................................................. 204
System.Fundamentals.USBDevice.SelectiveSuspend ......................................................................................................................... 204

System.Fundamentals.Video ............................................................................................................................................................................ 205


System.Fundamentals.Video.HDRStreamingDisplayCharacteristics ........................................................................................... 205
System.Fundamentals.WatchDogTimer ....................................................................................................................................................... 206

System.Fundamentals.WatchDogTimer.IfWatchDogTimerImplemented ................................................................................. 206


System.Networking.WLAN ................................................................................................................................................................................ 207
System.Networking.WLAN.PLDR................................................................................................................................................................ 207

Overview of Windows Hardware Compatibility Program

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:

• Signing device drivers.


• Publishing the product as qualified in various catalogs and on the compatibility center.
• Collecting and pre-analyzing telemetry on your product in the field to improve your quality assurance
efforts.
• Providing a free and extremely effective distribution channel for driver updates.
• Providing eligibility for various marketing incentives and a logo license.

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.

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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

Windows 11 Client ARM64

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).

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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.

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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.

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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.

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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.

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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.

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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.

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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.

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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:

Bit Position Link Layer Feature

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.

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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

Windows 11 Client ARM64

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

The following supported features are required:

Value Parameter description

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.

0x00000000 00000004 Controller supports the RSSI Monitoring of LE advertisements.

0x00000000 00000008 Controller supports Advertising Monitoring of LE advertisements.

0x00000000 00000020 Controller supports Continuous Advertising Monitoring of LE advertisements


performed concurrently with other radio activities.

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

Windows 11 Client ARM64

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.

The following supported features are required:

Value Parameter description

0x00000000 00000040 Controller diagnostic TLV

0x00000000 00000200 Enhanced controller diagnostic TLV

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.

Applies to Windows 11 Client x64


Windows 11 Client ARM64

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.

Applies to Windows 11 Client x64


Windows 11 Client ARM64

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.

Applies to Windows 11 Client x64


Windows 11 Client ARM64

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.

Applies to Windows 11 Client x64


Windows 11 Client ARM64

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

The following supported features are required:

Value Parameter description

0x00000000 00000400 Controller supports HCI_VS_MSFT_LE_Monitor_Advertisement [v2].

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.

Required if the LE Audio Unicast feature is to 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.

Required if the LE Audio Unicast feature is to be supported.

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.

Required if the LE Audio Unicast feature is to be supported.

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.

Required if the LE Audio Unicast feature is to 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.

Required if the LE Audio Unicast feature is to 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.

Required if the LE Audio Unicast feature is to 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.

Required if the LE Audio Unicast feature is to be supported.

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.

Applies to Windows 11 Client x64


Windows 11 Client ARM64

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.

Applies to Windows 11 Client x64


Windows 11 Client ARM64

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.

Applies to Windows 11 Client x64


Windows 11 Client ARM64

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.

Applies to Windows 11 Client x64


Windows 11 Client ARM64

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:

a. DxgkBacklightOptimizationDisable: Driver is required to completely disable all backlight


optimization.

b. DxgkBacklightOptimizationDesktop: Driver is required to enable backlight optimization at a lower


aggressiveness level. Driver must optimize for scenarios like photo viewing, browser, and Office
documents.

c. DxgkBacklightOptimizationDynamic: Driver is required to enable backlight optimization at a higher


aggressiveness level. Driver must optimize for scenarios like video playback and gaming.

d. DxgkBacklightOptimizationDimmed: Driver is required to enable backlight optimization at a higher


aggressiveness level. Driver must make sure that the content on the screen is visible but it need not
be easily readable.

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.

e. Driver is required to gradually transition between aggressiveness levels:

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.

f. WDDM driver is required to provide accurate information when Windows queries


DxgkDdiGetBacklightReduction.

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.

Applies to Windows 11 Client x64

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.

The following methods are required:

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.

The following methods are optional:

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.

Applies to Windows 11 Client x64


Windows 11 Client ARM64

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.

Percent represented to Windows User


Experience
0% Brightness
level such
that the
contents of
the screen
are barely
visible to
the user
100% Max
brightness
supported
by panel

System.Client.Buttons

System.Client.Buttons.HardwareButtons
Hardware buttons are implemented correctly

Applies to Windows 11 Client x64

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.

Applies to Windows 11 Client x64


Windows 11 Client ARM64

Description

System Memory:

System Memory must be supported.

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:

The default state for mirroring must be "not mirrored."

Camera Controls (If Implemented):

Each of the following camera controls are optional.

• Region of Interest (ROI)


• Focus
• Exposure
• White Balance
• Zoom
• Camera Flash
• Scene Mode
• Optimization Hints
• Optical Image Stabilization
• Backlight Compensation
• Brightness

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.

Driver Support for KSProperty_CameraControl_Extended_PhotoThumbnail is now disallowed.

Photo Sequence (If Implemented):

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.

Photo Sequence must be enabled by the device and driver to:

• Support the same resolutions that are exposed in Normal mode


• Report the current frame rates possible in Photo Sequence Mode based on the current light conditions.
Device must honor and not exceed the maximum frame rate set by the application.
• Support at minimum 4fps measured at lesser of the maximum resolution exposed by the image pin or 8MP.
• Provide at least 4 frames in the past at lesser of the maximum resolution exposed by the image pin or 8MP.
• Photo Sequence should be performed independently, regardless preview on/off.
• Provide frames continuously in Photo Sequence mode at lesser of the maximum resolution exposed by the
image pin or 8MP.
• If the driver outputs JPEG format for Photo Sequence it must also support thumbnails, upon request, at
1/2x, 1/4x, 1/8x, and 1/16x of the width and height of the original image resolution.
• The JPEG image generated by the camera may optionally have EXIF metadata indicating the “flash fired”
information. EXIF information shall not include personally identifiable information, such as location, unique
ids, among others.

Variable Photo Sequence (If Implemented):

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.

Applies to Windows 11 Client x64


Windows 11 Client ARM64

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.

Applies to Windows 11 Client x64


Windows 11 Client ARM64

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°).

All other fields in the _PLD are optional.

System.Client.Camera.SensorCapture.SensorCapture
Systems with integrated cameras meet the requirements of, and can support the Windows Capture Infrastructure.

Applies to Windows 11 Client x64


Windows 11 Client ARM64

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.

Applies to Windows 11 Client x64


Windows 11 Client ARM64

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

Applies to Windows 11 Client x64


Windows 11 Client ARM64

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

Applies to Windows 11 Client x64


Windows 11 Client ARM64

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

Applies to Windows 11 Client x64


Windows 11 Client ARM64

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.

All other systems must support a minimum of 5 simultaneous contact points

System.Client.Digitizer.SystemPrecisionTouchpad
Precision Touchpad

Applies to Windows 11 Client x64


Windows 11 Client ARM64

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:

• Microsoft Pen Protocol (MPP) 1.51 or greater


• Wacom Generic Protocol (WGP) 1.0 or greater
• Wacom AES 1.0 or greater

System.Client.Digitizer.Pen.Accuracy
System Pen Contact Accuracy

Applies to Windows 11 Client x64


Windows 11 Client ARM64

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

Applies to Windows 11 Client x64


Windows 11 Client ARM64

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

Applies to Windows 11 Client x64


Windows 11 Client ARM64

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

Applies to Windows 11 Client x64


Windows 11 Client ARM64

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

Applies to Windows 11 Client x64


Windows 11 Client ARM64

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

Applies to Windows 11 Client x64


Windows 11 Client ARM64

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

Applies to Windows 11 Client x64


Windows 11 Client ARM64
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.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

Applies to Windows 11 Client x64


Windows 11 Client ARM64

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

Applies to Windows 11 Client x64


Windows 11 Client ARM64

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

Applies to Windows 11 Client x64


Windows 11 Client ARM64

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

Applies to Windows 11 Client x64


Windows 11 Client ARM64

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

Applies to Windows 11 Client x64


Windows 11 Client ARM64

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

Applies to Windows 11 Client x64


Windows 11 Client ARM64

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

Applies to Windows 11 Client x64


Windows 11 Client ARM64

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

Applies to Windows 11 Client x64


Windows 11 Client ARM64

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

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.Accuracy requirement for full requirement details.

System.Client.Digitizer.PrecisionTouchpad.Buffering
System Precision Touchpad Buffering for Buses with High Resume Latency

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.Buffering requirement for full requirement details.

System.Client.Digitizer.PrecisionTouchpad.Buttons
System Precision Touchpad Physical Buttons and Button Reporting

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.Buttons requirement for full requirement details.

System.Client.Digitizer.PrecisionTouchpad.ContactTipSwitchHeight
System Precision Touchpad Contact Tip Switch Height

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.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

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.Dimensions requirement for full requirement details.

System.Client.Digitizer.PrecisionTouchpad.FingerSeparation
System Precision Touchpad Finger Separation

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.FingerSeparation requirement for full requirement
details.

System.Client.Digitizer.PrecisionTouchpad.HIDCompliant
System Precision Touchpad HID Compliant Device Firmware and/or HID Mini-port Driver

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.HIDCompliant requirement for full requirement
details.

System.Client.Digitizer.PrecisionTouchpad.HighResolutionTimeStamp
System Precision Touchpad Hardware Scan Time

Applies to Windows 11 Client x64


Windows 11 Client ARM64
Page 48 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.HighResolutionTimeStamp requirement for full
requirement details.

System.Client.Digitizer.PrecisionTouchpad.InputResolution
System Precision Touchpad Input Resolution

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.Input Resolution requirement for full requirement
details.

System.Client.Digitizer.PrecisionTouchpad.Jitter
System Precision Touchpad Jitter and Linearity

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.Jitter requirement for full requirement details.

System.Client.Digitizer.PrecisionTouchpad.MinMaxContacts
System Precision Touchpad Contact count

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.MinMaxContacts requirement for full requirement
details.

System.Client.Digitizer.PrecisionTouchpad.NoiseSuppression
System Precision Touchpad Digitizer Reliability

Applies to Windows 11 Client x64


Windows 11 Client ARM64

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

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.ReportRate requirements for full requirement details.

System.Client.Digitizer.PrecisionTouchpad.ResponseLatency
System Precision Touchpad Response latency

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.ResponseLatency requirement for full requirement
details.

System.Client.Digitizer.PrecisionTouchpad.SelectiveReporting
System Precision Touchpad Selective Reporting

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.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

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.ThirdPartyDrivers requirements for full requirement
details.

System.Client.Digitizer.PrecisionTouchpad.Reporting
Systems which have a touchpad must be PTP compliant.

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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.

Applies to Windows 11 Client x64

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)

Providing the EDID

• 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.

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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.

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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).

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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.

WDDMv1.3 is required by all systems shipped with Windows 10.

Table below explains the scenario usage for the Graphic driver types:

Client Server Client running in a Server Virtual


Virtual
Environment
Full Graphics Required as post Optional Optional Optional
device
Display Only Not allowed Optional Optional Optional
Render Only Optional as non Optional Optional Optional
primary adapter
Headless Not allowed Optional N/A N/A

System.Client.Graphics.WDDMSupportRotatedModes
If accelerometer is present, Windows Display Driver Model (WDDM) driver must support all rotated modes.

Applies to Windows 11 Client x64

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

Applies to Windows 11 Client x64

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

Applies to Windows 11 Client x64

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.

Applies to Windows 11 Client x64


Windows 11 Client ARM64

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:

Helpful links: Mobile Broadband Driver Model Specifications http://msdn.microsoft.com/en-


us/library/ff560543(v=VS.85).aspx Network Device Class Power Management Reference Specification
http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/netpmspc.rtf

ComplyWithBaseReq include following HLK test cases :

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 :

AccessString : Specifies the access string to use when making a connection

UserName : Specifies the user name to use when making a connection (optional)

Password : Specifies the password 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 :

AccessString : Specifies the access string to use when making a connection

UserName : Specifies the user name to use when making a connection (optional)

Password : Specifies the password 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

Description : The test queries for Home provider (OID_WWAN_HOME_PROVIDER -


Windows drivers | Microsoft Docs) and validates the response from modem

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

Description : This test attempts multiple SIM-PIN related operations :

a) The test attempts a pin list query with the radio on


b) The test attempts a pin list query with the radio off
c) The test verifes if the device supports PIN1
d) The test enables and disables PIN1 with a valid pin
e) The test attempts to enable PIN1 with incorrect pin with valid length
f) The test enables PUK1 by entering incorrect PIN1 multiple times and then disables PUK1
g) The test enables PIN1, imediately changes the PIN, and disables it
h) The test reboots device to make modem enter lock state and prompt for entering valid
PIN
i) The test validates device is in lock state to request for entering PIN code

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 :

PIN1 : Specifies the PIN1 to use on the device

PUK1 : Specifies the PUK1 to use on the device

Reference : OID_WWAN_PIN - Windows drivers | Microsoft Docs,


OID_WWAN_PIN_EX - Windows drivers | Microsoft Docs, OID_WWAN_PIN_EX2 -
Windows drivers | Microsoft Docs, OID_WWAN_PIN_LIST - Windows drivers |
Microsoft Docs

9. TestPowerStates

Description : This test validates multiple scenarios :

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 :

AccessString : Specifies the access string to use when making a connection

UserName : Specifies the user name to use when making a connection (optional)

Password : Specifies the password 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 :

a) The test queries preferred providers and verifies data members


b) The test adds and then removes a preferred provider and validates the response from
modem
c) The test adds and removes a forbidden provider and validates the responses from the
modem
d) The test adds and removes a provider that is both preferred and forbidden and validates
the responses from the modem

Reference : OID_WWAN_PREFERRED_PROVIDERS - 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

11. TestProvisionedContext

Description : The test validates multiple scenarios :

a) The test queries provision context and verifies data members


b) The test adds a provisioned context using the append feature
c) The test updates a provisioned context
d) The test factory resets provisioned contexts
e) The test Disables a provisioned context
f) The test deletes a provisioned context

Reference: OID_WWAN_PROVISIONED_CONTEXTS - 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

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

Description : This test validates the following scenarios:

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

Reference : OID_WWAN_RADIO_STATE - Windows drivers | Microsoft Docs

Test Setup : The test requires a test device and a data-capable SIM card of any operator

Test parameters :

AccessString : Specifies the access string to use when making a connection

UserName : Specifies the user name to use when making a connection (optional)

Password : Specifies the password to use when making a connection (optional)

13. TestRadioStateSoftware

Description : This test validates the following scenarios:

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

Reference : OID_WWAN_RADIO_STATE - Windows drivers | Microsoft Docs

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)

Password : Specifies the password 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.

Reference : OID_WWAN_READY_INFO - 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

15. TestRegisterState

Description : The test validates the following scenarios :

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

Reference : OID_WWAN_REGISTER_STATE - Windows drivers | Microsoft Docs

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 :

AccessString : Specifies the access string to use when making a connection

UserName : Specifies the user name to use when making a connection (optional)

Password : Specifies the password 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 :

AccessString : Specifies the access string to use when making a connection

UserName : Specifies the user name to use when making a connection

Password : Specifies the password to use when making a connection

21. TestVisibleProvider

Description : This test validates the following scenarios :

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 :

AccessString : Specifies the access string to use when making a connection

UserName : Specifies the user name to use when making a connection (optional)

Password : Specifies the password 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.

Applies to Windows 11 Client x64


Windows 11 Client ARM64

Description

GSM devices that support EAP-SIM must support EAP-SIM as defined in RFC 4186.

HLK test validating this requirement :

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.

AuthChallengeRand1 : Specifies Auth Rand1 in Hex (eg :


00112233445566778899aabbccddeeff)

AuthChallengeRand2 : Specifies Auth Rand2 in Hex (eg :


ffeeddccbbaa99887766554433221100)

AuthChallengeRand3 : Specifies Auth Rand3 in Hex (eg :


00112233445566778899aabbccddeeff)

AuthChallengeAutn : Specifies Auth Autn in Hex (eg :


010203040506FF08090a0b0c0d0e0f0f)

AuthChallengeNetworkName : Specifies Auth Network Name (eg : mbn.microsoft.com)

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.

Applies to Windows 11 Client x64


Windows 11 Client ARM64

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:

Mobile Broadband Interface Model Specification: http://www.usb.org/developers/devclass_docs/MBIM10.zip

Mobile Broadband Driver Model Specification:


http://msdn.microsoft.com/library/windows/hardware/ff560543(v=VS.85).aspx

HLK tests validating this requirement :

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

2. TestConnect : This test is already described in detail under section


System.Client.MobileBroadBand.ComplyWithBaseReq (test case 1)
3. TestDeviceServices :

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.

Applies to Windows 11 Client x64


Windows 11 Client ARM64

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:

Loopback implementation guide for device firmware: http://msdn.microsoft.com/en-


us/library/windows/hardware/hh975390.aspx

MB Miniport Driver Performance Requirements: http://msdn.microsoft.com/en-


us/library/windows/hardware/ff557193(v=vs.85).aspx

HLK Test validating this requirement:

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 :

NumberOfSocketsForDataTransfer : The number of threads/sockets for data send/receive (eg: 4 )

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)

DataSizeIncrement : Stepwise increment from MinDataPacketSize per send data (eg :1 )

System.Client.MobileBroadband.SupportUSBSelectiveSuspend
USB based Mobile Broadband devices must support Windows implementation of USB selective suspend.

Applies to Windows 11 Client x64


Windows 11 Client ARM64

Description

USB based Mobile Broadband devices must support Windows implementation of USB selective suspend (SS). No
alternate USB SS implementation is allowed.

HLK tests validating this requirement :

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 :

AccessString : Specifies the access string to use when making a connection

UserName : Specifies the user name to use when making a connection (optional)

Password : Specifies the password 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.

Applies to Windows 11 Client x64


Windows 11 Client ARM64

Description

Mobile broadband class of devices must support the following wake on mobile broadband capabilities when system
power state is ModernStandby

• Devices MUST support 32 bitmap wake patterns of 128 byte each.


• Devices MUST wake the system on register state change.
• Devices MUST wake the system on media connect.
• Devices MUST wake the system on media disconnect.
• GSM Devices MUST wake the system on receiving an incoming SMS message.
• Devices that support USSD MUST wake the system on receiving a USSD message.
• Devices MUST support wake packet indication. NIC should cache the packet causing the wake on hardware
and pass it up when the OS is ready for receives.

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

HLK tests validating the requirement :

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)

Password : Specifies the password 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.

Applies to Windows 11 Client x64


Windows 11 Client ARM64

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.

HLK tests validating this requirement :

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.

Applies to Windows 11 Client x64


Windows 11 Client ARM64

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.

HLK tests validating this feature :

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.

Applies to Windows 11 Client x64


Windows 11 Client ARM64

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.

HLK tests validating this requirement:

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)

LevelConfig : Intended level of modem logging (eg : 1)

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.

Applies to Windows 11 Client x64


Windows 11 Client ARM64

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).

HLKs validating this requirement :

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

Reference : OID_WWAN_LTE_ATTACH_CONFIG - Windows drivers | Microsoft Docs,


OID_WWAN_LTE_ATTACH_STATUS - Windows drivers | Microsoft Docs

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]

LteIpType0 : IP address type of the first LTE Attach context [default|v4|v6|v4v6]

LteIpType1 : IP address type of the second LTE Attach context [default|v4|v6|v4v6]

LteIpType2 : IP address type of the third LTE Attach context [default|v4|v6|v4v6]

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]

LteSource1 : Specified the creation source of the first context [admin|user|operator|modem|device]

LteSource2 : Specified the creation source of the second context [admin|user|operator|modem|device]

LteApn0 : APN of the first LTE Attach context

LteApn1 : APN of the second LTE Attach context

LteApn2 : APN of the third LTE Attach context

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.

Applies to Windows 11 Client x64


Windows 11 Client ARM64

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:

• Provide notification when PCO is received from the network


• Support Connected Standby by buffering received PCOs until OS exists Connected Standby

HLK tests validating this requirement :

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 :

AccessString : Specifies the access string to use when making a connection

UserName : Specifies the user name to use when making a connection (optional)

Password : Specifies the password 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.

Applies to Windows 11 Client x64


Windows 11 Client ARM64

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.

HLK tests validating this requirement :


1. TestResetPassthrough
Description : The test validates the following scenarios:
a) The test queries the UICC RESET info for active Slot from the modem and validates modem response
b) The test sets the UICC_RESET mode for active Slot to PassthroughEnable, and validates the response
from the modem, then the test sets the UICC RESET mode to PassthroughDisable and validates the
response from the modem
c) The test sets the UICC RESET mode for active Slot to PassthroughEnable and validates the response
from the modem. Then the test performs a device reset and query the UICC RESET mode and verifies
that it is passthroughDisable (the device reset should reset the passthrough mode back to “disabled”)
d) The test queries the UICC RESET info for in-active Slot from the modem and validates modem response
e) The test sets the UICC_RESET mode for in-active Slot to PassthroughEnable, and validates the response
from the modem, then the test sets the UICC RESET mode to PassthroughDisable and validates the
response from the modem

Reference : OID_WWAN_UICC_RESET - Windows drivers | Microsoft Docs

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.

Applies to Windows 11 Client x64


Windows 11 Client ARM64

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).

• DSSA: one physical interface, one active subscription


• DSDS: two physical interfaces, one active subscription
• DSDA: two physical interfaces, two active subscriptions

This requirement is for DSSA configuration.

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:

• Provide hardware capabilities (SIM slots, executors and concurrencies)


• Able to map different physical interfaces (executors) to different SIM slots in run time
• Provide SIM status on all SIM slots
• Provide modem hardware ID that uniquely identifies each modem

HLK Tests validating this requirement:

1. TestSlot

Description : This test verifies the following scenarios :

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.

Applies to Windows 11 Client x64

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:

• Universal Serial Bus (USB)


• Bluetooth
• IP connected devices using Plug and Play Extensions (PnP-X)
• 1394
• eSATA
• PCI Express (PCIe)

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.

Applies to Windows 11 Client x64

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:

• Toggle Button (Laptops and Tablets)


• Toggle Button with LED (Non-Modern standby supported laptops and tablets)
• A-B slider switch (Laptops and Tablets)
• A-B slider switch with LED (Non-Modern standby supported laptops and tablets)

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.

Applies to Windows 11 Client x64

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.

Applies to Windows 11 Client x64

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:

Usage ID Usage Name Usage Type


0x0C Wireless Radio Controls CA
0xC6 Wireless Radio Button OOC
0xC7 Wireless Radio LED OOC
0xC8 Wireless Radio Slider Switch OOC

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 (without LED) - 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 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
Page 89 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
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.

Applies to Windows 11 Client x64

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

Applies to Windows 11 Client x64


Page 91 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

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

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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

Applies to Windows 11 Client x64

Windows 11 Client ARM64

Description

The required enumeration properties for activity sensors is shown below:

Data Field Data Type Definition


PKEY_SensorData_SupportedActivityStates VT_UI4 The activity states that are supported by the
activity sensor. This is represented as a
bitmask of ACTIVITY_STATE.
PKEY_SensorData_MinimumDetectionIntervals_Ms VT_VECTOR | A vector of minimum detection intervals, in
VT_UI4 milliseconds. The value at each index maps to
the ordinal value of a state’s enum value. If
state is not supported, then 0 must be
reported for that state.
PKEY_Sensor_Power_Milliwatts VT_R4 The sensor power expressed in milliwatts

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

Applies to Windows 11 Client x64

Windows 11 Client ARM64


Description

If an ambient light sensor is intended to be used with the autobrightness feature, then the following enumeration
property is required to be reported:

Data Field Data Definition


Type
DEVPKEY_LightSensor_AutoBrightnessPreferred VT_BOOL Specifies if this light sensor should be the preferred
light sensor used for the Windows autobrightness
service.
There must only be up to one ambient light sensor reporting this property on a system.

System.Client.Sensor.AmbientLightSensor.ColorCalibration
Ambient light sensors that support color capable must be properly calibrated

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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.

Applies to Windows 11 Client x64

Windows 11 Client ARM64


Description

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:

The following data field must be reported:

Data Field Data Type Definition


PKEY_SensorData_IsValid VT_BOOL Indicates if the current data sample is valid.

If this value changes, a sample must be reported regardless of if the thresholds have been met. See below for
examples:

Assume the lux threshold is 1 lux:

• 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.

Applies to Windows 11 Client x64

Windows 11 Client ARM64


Description

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

Applies to Windows 11 Client x64

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.

Applies to Windows 11 Client x64

Windows 11 Client ARM64

Description

Custom sensors are required to report the following properties to PnP:

Data Field Data Type Definition


DEVPKEY_Sensor_Name VT_LPWSTR The name of the
sensor.
DEVPKEY_Sensor_VendorDefinedSubType VT_CLSID The GUID that
identifies the sensor
category subtype
defined by the
vendor. This must be
unique to the vender.
DEVPKEY_Sensor_Manufacturer VT_LPWSTR The manufacturer of
the sensor. This must
be unique to the
manufacturer.

System.Client.Sensor.General.EnumerationProperties
Sensors are required to report the expected properties via PnP

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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:

Data Field Data Type Definition


DEVPKEY_Sensor_Type VT_CLSID A GUID that identifies the type of sensor. For more
information about sensor types, see sensor type GUIDs.
DEVPKEY_Sensor_Category VT_CLSID The GUID that identifies the sensor category, this is
required for backwards compatibility with desktop V1.
For more information about sensor categories, see
sensor category GUIDs.
DEVPKEY_Sensor_ConnectionType VT_UI4 Required only for ambient light sensors and
accelerometers. The senor connection type (integrated,
attached, or external).
For more information, see the SensorConnectionType
enumeration.
DEVPKEY_Sensor_Name VT_LPWSTR Required only for custom sensors. The name of the
sensor.
DEVPKEY_Sensor_Manufacturer VT_LPWSTR The manufacturer of the sensor
DEVPKEY_Sensor_Model VT_LPWSTR The model for the sensor.
DEVPKEY_Sensor_PersistentUniqueId VT_CLSID The GUID that identifies the sensor. This value must be
unique for each sensor of the same model on the
device.
DEVPKEY_Sensor_VendorDefinedSubType VT_CLSID Required only for custom sensors. The GUID that
identifies the sensor category subtype defined by the
vendor.

System.Client.Sensor.General.OptionalEnumerationProperties
Sensors can optionally report some enumeration properties

Applies to Windows 11 Client x64

Windows 11 Client ARM64

Description

The optional enumeration properties for all sensors are shown below:

Data Field Data Definition


Type
DEVPKEY_Sensor_IsPrimary VT_BOOL Indicates if this is the primary sensor. This value defaults to false, if not
set.
PKEY_Sensor_WakeCapable VT_BOOL Indicates if the sensor is wake capable. This must be set to
VARIANT_TRUE if the sensor can wake the application processor when
the FIFO buffer is full, VARIANT_FALSE otherwise.

System.Client.Sensor.General.OptionalProperties
Sensors can optionally report some sensor properties

Applies to Windows 11 Client x64

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

Sensors can optionally report the following sensor properties:

Data Field Data Definition


Type
PKEY_Sensor_Power_Milliwatts VT_R4 The power the sensor uses in milliwatts.
PKEY_Sensor_FifoReservedSize_Samples VT_UI4 The number of events reserved for this sensor in the first-in-
first-out buffer for batches. This guarantees a minimum
number of events. If this value is zero, then there is no
guarantee that the sensor will perform batching.

System.Client.Sensor.General.Properties
Sensors are required to report the expected sensor properties

Applies to Windows 11 Client x64

Windows 11 Client ARM64

Description

The required sensor properties for all sensors are shown below:

Data Field Data Type Definition


PKEY_Sensor_Type VT_CLSID A GUID that identifies the type of sensor. For
more information about sensor types, see
sensor type GUIDs.
PKEY_Sensor_State VT_UI4 The state of the sensor. For more information
about sensor states, see SENSOR_STATE.
PKEY_Sensor_MinimumDataInterval_Ms1 VT_UI4 The minimum time interval in milliseconds that
the hardware supports for generating sensor
data.
PKEY_Sensor_MaximumDataFieldSize_Bytes VT_UI4 The maximum size returned in a ReadFile call.
A ReadFile call allows the native API to allocate
a buffer to hold data fields.
PKEY_Sensor_FifoMaxSize_Samples VT_UI4 Required only if the sensor supports batching.
The maximum number of events that can be
batched in the FIFO buffer. If this value is zero,
then batching is not supported by the sensor.
The actual number of events may be smaller
than this number since the buffer can be
shared by multiple sensors.
Notes:

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

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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:

typedef enum SENSOR_CONNECTION_TYPES


{

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

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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:

Sensor Type Maximum Measuring Latency on Warm Up Maximum Measuring Latency


Non-color capable 300 ms
250 ms
light sensor
Color capable light 450 ms
400 ms
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

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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

Applies to Windows 11 Client x64

Windows 11 Client ARM64

Page 100 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

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.

Applies to Windows 11 Client x64

Windows 11 Client ARM64

Description

Orientation sensors can optionally report the following property:

Sensor Property Data Type Definition


PKEY_OrientationSensor_GyroscopeUsed VT_BOOL Indicates if a gyroscope is used in the orientation sensor.

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

Applies to Windows 11 Client x64

Windows 11 Client ARM64

Description

Following sensor properties are required to be reported as enumeration properties by a Pedometer.

Data Field Data Type Definition


PKEY_SensorData_SupportedStepTypes VT_UI4 The step types that are supported by the pedometer.
This must be a bitmask of PEDOMETER_STEP_TYPE.

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.

Page 101 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

Proximity sensors must report the following enumeration property:

Data Field Data Definition


Type
DEVPKEY_Sensor_ProximityType VT_UI4 Proximity type supported by the sensor (Object Proximity or Human
Proximity). Human proximity must be reported if the proximity
sensor is a human presence sensor.

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

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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.

Page 102 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.SystemConfiguration
System.Client.SystemConfiguration.Windows10RequiredComponents
Windows 10 systems must include certain devices.

Applies to Windows 11 Client x64

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.

Storage type Meet minimum Microsoft Windows Storage requirements

System firmware UEFI as defined in System.Fundamentals.Firmware requirements

Networking Ethernet or Wi-Fi Must be either a certified Ethernet or Wi-Fi adapter

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.

Applies to Windows 11 Client x64

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

Page 103 of 208


Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
GPT_ATTRIBUTE_PLATFORM_REQUIRED and GPT_BASIC_DATA_ATTRIBUTE_NO_DRIVE_LETTER attributes, and contains
at least 50 megabytes (MB) of free space after the Windows Recovery Environment image file has been copied to it.

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.

Applies to Windows 11 Client x64

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.

Applies to Windows 11 Client x64

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.

Page 104 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 example:

• 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.

Applies to Windows 11 Client x64

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.

Applies to Windows 11 Client x64

Page 105 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

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

Windows 11 Client ARM64

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

Page 106 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.WLAN.HangDetectionAndRecovery
System.Client.WLAN.HangDetectionAndRecovery.WlanHangDetectionAndRecovery
(WDI Drivers Only)
Applies to Windows 11 Client x64

Windows 11 Client ARM64

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.

Requirement – Hardware / Firmware


System ACPI firmware: The System will provide the ACPI methods to PDLR the device either at a bus or at the device
level.
System hardware: The system will allow for a PDLR (full device level reset). All systems must support PDLR.
System: The System will indicate support for PDLR support.
Device: The Lower Edge driver will be able to gather dumps with 25 ms and 250 Kb size
System: The system must complete the reset within 10 seconds.

System.Client.WLAN.HostedNetwork
System.Client.WLAN.HostedNetwork.WlanHostedNetwork
Applies to Windows 11 Client x64

Windows 11 Client ARM64

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.

Page 107 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.WLAN.WiFiDirect
System.Client.WLAN.WiFiDirect.WlanWiFiDirect
Applies to Windows 11 Client x64

Windows 11 Client ARM64

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

Windows 11 Client ARM64

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.

Applies to Windows 11 Client x64

Windows 11 Client ARM64

Page 108 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

Windows 11 supports several different debug transports. They are listed below in the preferred order of
implementation.

Hardware Debugging Transports

• Ethernet Network Interface Card from the supported list: Supported Ethernet NICs for Network Kernel Debugging
in Windows 11 - Windows drivers | Microsoft Docs

• USB 3.0 – xHCI controller compliant to xHCI debug specification.

• Legacy Serial (16550 compatible programming interface).

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

• firmware during preboot, before transferring control to the boot block.

For additional information, see http://go.microsoft.com/fwlink/?LinkId=237141

System.Fundamentals.EnergyEstimation

Page 109 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.EnergyEstimation.Discretional

Applies to Windows 11 Client x64

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.

Page 110 of 208


Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
▪ Right click on it, select “New Simple Volume”. Follow the GUI to create a volume with 4GB space and
format it in NTFS.
▪ Remember the assigned drive letter of the new disk, and close disk manager.
▪ Set\storapp_set.exe /flag –reset
▪ Once finish the test, you can remove the fake drive by running
cscript Scripts\Install_Storhba.wsf /storhba:0
There could be some problem of removing the fake driver after reset it. To work around it, you can create
another fake drive first by running “Scripts\Install_Storhba.wsf /storhba:1 /TestParameter:6
/LogicalUnitDiskSizeInMB:4096 /PhysicalLuns:1” again, followed by “Scripts\Install_Storhba.wsf /storhba:0”.

System.Fundamentals.Firmware

System.Fundamentals.Firmware.ACPI
ACPI System Requirements

Applies to Windows 11 Client x64

Windows 11 Client ARM64

Description

All systems must meet the following ACPI table requirements.

ACPI Table Requirements


Root System Description Pointer (RSDP) Required
Root or Extended System Description Table (RSDT Required
or XSDT)

Page 111 of 208


Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
Fixed ACPI Description Table (FADT) Revision 5 is required for Hardware-reduced ACPI
platforms and systems that support modern
standby platforms
Multiple APIC Description Table (MADT) Required
Core System Resources Description (CSRT) Required for ARM systems if non-Standard timers or
any shared DMA controllers are exposed to the OS
Debug Port Table (DBGP) Required. DBG2 table is required instead for Hardware-
reduced ACPI platforms and systems that support
modern standby platforms.
Differentiated System Description Table (DSDT) Required

DSDT Requirements

As per ACPI 4.0a, all devices in the ACPI namespace must include:

• A vendor-assigned, ACPI-compliant Hardware ID (_HID object).


• A set of resources consumed (_CRS object).

In addition, the following conditional requirements apply:

• 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.

General-Purpose Input/Output (GPIO) on any System that Supports Modern Standby

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:

• Be able to cause the system to power-up when required.


• Generate the Power Button Override Event (Section 4.7.2.2.1.3 of the ACPI 4.0a specification) when held down for
4 seconds.

Control Method Power Button

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.

Button Array-based Power Button

Touch-first (keyboard-less) systems must:

• Implement the Windows-compatible Button Array device.


• Connect the power button to a dedicated GPIO interrupt pin.
• Configure the power button's GPIO interrupt pin as a non-shared, wake-capable (ExclusiveAndWake), Edge-
triggered (Edge) GPIO interrupt connection resource, capable of interrupting on both edges (ActiveBoth).
• List the power button's GPIO Interrupt connection resource first in the Button Array device's _CRS object.

Page 113 of 208


Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
NOTE: For systems that require a separate driver to handle power button presses, it is acceptable to have that driver
call the 5-Button array driver's power button event interface instead of using the GPIO-based solution above.

Time and Alarm Device

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.

Page 114 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.Firmware.HardwareMemoryReservation
System.Fundamentals.Firmware.HardwareMemoryReservation

Applies to Windows 11 Client x64

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)

• 2-3GB systems – max of 3% of 3GB + 25MB (117.2MB)


• For all other systems, a max of 120MB
• If screen resolution exceeds 1366x768, an additional 8 bytes per pixel will be allowed. Note: The budgets above
are intended to cover 2 full screen video memory reservations for graphics drivers at 1366x768 at 32 bytes per
pixel – 8MB. The adjustment above takes into consideration machines with higher resolutions.

RAM Size Screen resolution Threshold


1GB 1366x768 86.5MB
2GB 1366x768 86.5MB
2GB 1920x1080 86.5MB + 8MB
3GB 1366x768 117.2MB
3GB 1920x1080 117.2MB + 8MB
4GB Any 120MB
Applies to Windows Client OS SKUs only

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

Applies to Windows 11 Client x64

Windows 11 Client ARM64

Page 115 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

HSTI is defined by a specification available publicly on MSDN (https://msdn.microsoft.com/en-


us/library/windows/hardware/mt712332). The current version of HSTI is 1.1a.

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).

Applies to Windows 11 Client x64

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).

Applies to Windows 11 Client x64

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.

Page 116 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.Firmware.UEFIBootEntries
UEFI firmware honors software control over load option variables.

Applies to Windows 11 Client x64

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.

Applies to Windows 11 Client x64

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,

Page 117 of 208


Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
27.1~27.8.

Additional guidance listed at https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-


uefi is also required.

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.

Applies to Windows 11 Client x64

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.

Applies to Windows 11 Client x64

Page 118 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

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.

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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.

Page 120 of 208


Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
14. Microsoft Key Encryption Key (KEK) is provisioned A valid Microsoft-provided KEK is included in the KEK database.
Microsoft provides the KEK in the form of either an EFI_CERT_X509_GUID or EFI_CERT_RSA2048_GUID type signature.
The Microsoft KEK signature uses the following SignatureOwner GUID: {77fa9abd-0359-4d32-bd60-28f4e78f784b}.
15. PKpub verification. The PKpub key is owned by the OEM and stored in firmware flash. The private-key counterpart to
PKpub is PKpriv, which controls Secure Boot policy on all OEM-manufactured devices, and its protection and use must
be secured against un-authorized use or disclosure. PKpub must exist and the operating system must be able to read
the value and verify that it exists with proper key length.
16. No in-line mechanism is provided whereby a user can bypass Secure Boot failures and boot anyway. Signature
verification override during boot when Secure Boot is enabled is not allowed. A physically present user override is not
permitted for UEFI images that fail signature verification during boot. If a user wants to boot an image that does not
pass signature verification, they must explicitly disable Secure Boot on the target system.
17. UEFI Shells and related applications. UEFI Modules that are not required to boot the platform must not be signed by
any production certificate stored in "db", as UEFI applications can weaken the security of Secure Boot. For example, this
includes and is not limited to UEFI Shells as well as manufacturing, test, debug, RMA, & decommissioning tools. Running
these tools and shells must require that a platform administrator disables Secure Boot.
18. Secure Boot Variable. The firmware shall implement the SecureBoot variable as documented in Section 3.2 "Globally
Defined Variables' of UEFI Specification Version 2.3.1 Errata C"
19. For devices which are designed to always boot with a specific Secure Boot configuration, the two requirements below
to support Custom Mode and the ability to disable Secure Boot are optional.
20. (Optional for systems intended to be locked down) The platform MUST implement the ability for a physically present
user to select between two Secure Boot modes in firmware setup: "Custom" and "Standard". Custom Mode allows for
more flexibility as specified in the following:
A. It shall be possible for a physically present user to use the Custom Mode firmware setup option to modify the
contents of the Secure Boot signature databases and the PK. This may be implemented by simply providing
the option to clear all Secure Boot databases (PK, KEK, db, dbx), which puts the system into setup mode.
B. If the user ends up deleting the PK then, upon exiting the Custom Mode firmware setup, the system is
operating in Setup Mode with SecureBoot turned off.
C. The firmware setup shall indicate if Secure Boot is turned on, and if it is operated in Standard or Custom Mode.
The firmware setup must provide an option to return from Custom to Standard Mode which restores the
factory defaults.
21. (Optional for systems intended to be locked down) Enable/Disable Secure Boot. A physically present user must be
allowed to disable Secure Boot via firmware setup without possession of PKpriv. A Windows Server may also disable
Secure Boot remotely using a strongly authenticated (preferably public-key based) out-of-band management
connection, such as to a baseboard management controller or service processor. Programmatic disabling of Secure
Boot either during Boot Services or after exiting EFI Boot Services MUST NOT be possible.
22. If the firmware is reset to factory defaults, then any customized Secure Boot variables are also factory reset. If the
firmware settings are reset to factory defaults, all custom-set variables shall be erased and the OEM PKpub shall be re-
established along with the original, manufacturer-provisioned signature databases.
23. OEM mechanism exists to remediate failed EFI boot components up to and including the Windows OS loader
(bootmgr.efi). Images in the EFI boot path that fail Secure Boot signature verification MUST not be executed, and the
EFI_IMAGE_EXECUTION_INFO_TABLE entry for that component shall be updated with the reason for the failure. The
UEFI boot manager shall initiate recovery according to an OEM-specific strategy for all components up to and including
Windows bootmgr.efi.
24. A working Windows RE image must be present on all Windows client systems The Windows Recovery image must be
present in the factory image on every Secure Boot capable system. To support automated recovery and provide a
positive user experience on Secure Boot systems, the Windows RE image must be present and enabled by default. As
part of the Windows Trusted Boot work enhancements have been made to Windows RE to allow optimized recovery

Page 121 of 208


Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
from signature verification failures in Secure Boot. OEMs must include Windows RE as part of their factory image on all
Windows client systems.
25. Firmware-based backup and restore. If the OEM provides a mechanism to backup boot critical files (for example: EFI
drivers and boot applications), it must be in a secure location only accessible and serviceable by firmware. The OEM
may provide the capacity via firmware or other backup store to store backup copies of boot critical files and recovery
tools. If such a store is implemented, the solution must also have the capability to restore the target files onto the
system without the need for external media or user intervention. This is a differentiator for the OEM in failover
protection, used if the Windows OS loader (bootmgr.efi) or other boot critical components fail, preventing Windows
native recovery solutions to execute.
26. Firmware-based backup synchronization. Backup copies of boot critical components (for example: EFI drivers and boot
applications) stored in firmware must be serviced in sync with updates to same files on the system If the system has the
capability to store a backup copy of the Windows OS loader (bootmgr.efi), and potentially other critical boot
components, then the files must be serviced on the same schedule as their counterparts in use on the live system. If the
Windows OS loader is updated by Windows Update, then the backup copy of bootmgr.efi stored in firmware must be
updated on the next boot.
27. All Windows client systems must support a secondary boot path. For all Windows systems configured for Secure Boot,
there must be an alternate boot path option that is followed by the firmware in the event that the primary Windows OS
loader fails. The second boot path may point either to the default shadow copy installed by Windows to the system
backup store (<EFI System Volume>\EFI\Boot\boot<platform>.efi ), or to a copy stored by the OEM firmware-based
mechanism. This alternate path could be a file in executable memory, or point to a firmware-based remediation process
that rolls a copy out of the OEM predetermined backup store.
28. All Windows client systems must support a USB boot path for recovery purposes. For all Windows systems configured
for Secure Boot, there is a last resort of booting from USB.
29. Supporting GetVariable() for the EFI_IMAGE_SECURITY_DATABASE (both authorized and forbidden signature database)
and the SecureBoot variable.
30. Supporting SetVariable() for the EFI_IMAGE_SECURITY_DATABASE (both authorized and forbidden signature database),
using an authorized KEK for authentication.
31. Reserved Memory for Windows Secure Boot UEFI Variables. A total of at least 128 KB of non-volatile NVRAM storage
memory must be available for NV UEFI variables (authenticated and unauthenticated, BS and RT) used by UEFI Secure
Boot and Windows, and the maximum supported variable size must be at least 64 KB. There is no maximum NVRAM
storage limit. Note that this is an increase from Windows 10, version 1703 requirements of 64 KB total and 32 KB variable
size.
32. Device 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.
33. During normal firmware updates the following must be preserved:
• The Secure Boot state & configuration (PK, KEK, db, dbx, SetupMode, SecureBoot)
• All UEFI variables with VendorGuid {77fa9abd-0359-4d32-bd60-28f4e78f784b}
• A physically-present user who authenticates to the firmware may change, reset, or delete these values
34. The platform shall support EFI variables that are:
a. accessible only during the boot services or also accessible in the runtime phase;
b. non-volatile; and
c. Possible to update only after proper authorization, for example, being properly signed.
35. The platform must support EFI variables with any valid combination of the following UEFI 2.3.1 variable attributes set:

Copy

EFI_VARIABLE_NON_VOLATILE

EFI_VARIABLE_BOOTSERVICE_ACCESS

Page 122 of 208


Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
EFI_VARIABLE_RUNTIME_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.

Effective October 1, 2020: This requirement is Optional

System.Fundamentals.Firmware.UEFITimingClass
System firmware must expose timing and class information.

Applies to Windows 11 Client x64

Description

Page 123 of 208


Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
• During POST, the firmware shall measure its own timing and record the duration of post, rounded to the nearest
mSec.

• 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.

Applies to Windows 11 Client x64

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

Applies to Windows 11 Client x64

Page 124 of 208


Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
Enhancement scenarios: User can acquire and launch cloud recovery environment from baremetal state

Terms: If device elects to support Cloud-based OS Baremetal Recovery feature

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:

UEFI Protocol Name Notes

• UEFI Spec V2.7 Section 13.9


• CBMR leverages this protocol to read and write storage
EFI_BLOCK_IO_PROTOCOL devices at block level. Consumed by
EFI_RAM_DISK_PROTOCOL.

EFI_HASH2_PROTOCOL • UEFI Spec V2.7 Section 36.2


• CBMR leverages this protocol to validate data coming
EFI_HASH2_SERVICE_BINDING_PROTOCOL from unsecure network locations.

• UEFI Spec V2.7 Section 13.17


EFI_RAM_DISK_PROTOCOL
• CBMR leverages this protocol to define a standard
interface for UEFI applications, drivers, and OS loaders to
register/ unregister a RAM disk

• UEFI Spec V2.7 Section 10.2


EFI_DEVICE_PATH_PROTOCOL • CBMR leverages this protocol to identify the RAM disk for
interacting with the recovery environment

• UEFI Spec V2.7 Section 10.5


EFI_DEVICE_PATH_UTILITIES_PROTOCOL
• CBMR leverages this protocol to provide common utilities
for creating and manipulating device paths and device
nodes

• UEFI Spec V2.7 Section 9.1


EFI_LOADED_IMAGE_PROTOCOL • CBMR leverages this protocol to load and start updated
CBMR image versions into memory

• UEFI Spec V2.7 Section 13.4


EFI_SIMPLE_FILE_SYSTEM_PROTOCOL • CBMR leverages this protocol to have file-based access to
a device

• UEFI Spec V2.7 Section 12.9


EFI_GRAPHICS_OUTPUT_PROTOCOL • CBMR leverages this protocol to get graphical support for
displaying logos, text, and other graphics on the screen

EFI_SIMPLE_TEXT_INPUT_PROTOCOL • UEFI Spec V2.7 Section 12.3

Page 125 of 208


Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
• CBMR leverages this protocol to obtain user input for
validation purposes

• UEFI Platform Initialization (PI) Spec V1.7, Volume 5,


Chapter 6
EFI_SMBIOS_PROTOCOL
• CBMR leverages this protocol to construct a platform id
for the device

• UEFI Spec V2.7 Section 3.2


EFI_BOOT_MANAGER_POLICY_PROTOCOL • Used to request the UEFI boot manager to connect
devices using platform policy.

• UEFI Spec V2.7 Section 29.6


EFI_HTTP_PROTOCOL • Used to communicate with remote end points over Wi-Fi
EFI_HTTP_SERVICE_BINDING_PROTOCOL or ethernet connection and to establish secured HTTP
connection (Requires TLS implementation).

• UEFI Spec V2.7 Section 29.2


EFI_DHCP4_PROTOCOL
• CBMR leverages this protocol to acquire and manage IP
EFI_DHCP4_SERVICE_BINDING_PROTOCOL
addresses.

• UEFI Spec V2.7 Section 28.5

EFI_IP4_CONFIG2_PROTOCOL • The EFI_IP4_CONFIG2_PROTOCOL provides the


mechanism to set and get various types of configurations
for the EFI IPv4 network stack.

• UEFI Spec V2.7 Section 26.3


EFI_WIRELESS_MAC_CONNECTION_II_PROTOCOL
• Used to enumerate and connect to Wi-Fi networks.

• UEFI Spec V2.7 Section 26.5


EFI_SUPPLICANT_PROTOCOL • Provides a unified place for Wi-Fi and EAP security
management.
• Used to set Wifi credentials (PSK password).

• UEFI Spec V2.7 Section 34.1


EFI_HII_FONT_PROTOCOL • Used for rendering the font glyphs on to the screen. This
is used for Wifi connection manager UX

• UEFI Spec V2.7 Section 13.18


EFI_PARTITION_INFO_PROTOCOL
• Used for inspecting the partition info

EFI_TLS_PROTOCOL • UEFI Spec V2.7 Section 28.10


• Used for configuring TLS certificate list via its exposed
EFI_TLS_SERVICE_BINDING_PROTOCOL ‘TlsCaCertificate’ UEFI variable

Page 126 of 208


Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
3. The cbmr_driver.efi UEFI driver, distributed by Microsoft, must be integrated into the device as part of the
device’s UEFI firmware.
4. The device’s UEFI BIOS shall have the following User Interface to launch cbmr_driver.efi UEFI driver:
a. The User Interface shall have the following elements
i. Title: “Reinstall Windows from the cloud”
ii. Subtitle: “Reinstall Windows from the internet.”
iii. A button with text “Recover this device”.
b. When the user presses the button “Recover this device”, the UEFI BIOS shall present a dialog box
with
i. Privacy Notice: “Microsoft collects Windows diagnostic data to solve problems and to keep
Windows up to date, secure, and operating properly. To learn more about our diagnostic
data, please visit the Microsoft Privacy Statement page at
https://privacy.microsoft.com/privacystatement. “
ii. Data Wipe Warning: Using connected system recovery will permanently delete your data
from this device. Please proceed with caution. Please click the “Agree” button below to
continue with the recovery.
iii. A button with text “Cancel” which when pressed will exit the dialog and go back to the
UEFI BIOS menu
iv. A button with “Agree”, which when pressed will launch an OEM-authored UEFI application
that
a. hosts the Wifi Connection Manager UX (as described in Connection Type
Screen section above), and
b. orchestrates the recovery flow via the public EFI_MS_CBMR_PROTOCOL
found in a previously loaded cbmr_driver.efi (when this driver is loaded is up
to the OEM/IBV). The protocol can be leveraged to execute the various
recovery functions, including initiating collateral download and executing
progress callbacks (more details on how to completely leverage the
EFI_MS_CBMR_PROTOCOL will be available at a later date).
c. The user interface elements shall be localized to the target market for the given device.
5. The firmware must be able to allocate a minimum of 1 GB of contiguous memory to boot the recovery
environment from RAM. EFI_RUNTIME_SERVICES' AllocatePages() is used to allocate such memory.
6. The EDKII TlsDxe implementation shall be adopted so secure HTTP connections can be established:
a. The gEfiTlsCaCertificateGuid:EFI_TLS_CA_CERTIFICATE_VARIABLE must be utilized by TLS
implementation to look up client TLS CA certificate list. This variable will be provisioned by the
CBMR driver unless otherwise stated.
7. The firmware is required to add UI/UX covering the steps for Wi-Fi connection and for downloading
collaterals. Please refer to the section “UI/UX Guidance and Requirements” in the Connected System
Recovery (CBMR) OEM requirements documentation for detail

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.

Page 127 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

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.

Applies to Windows 11 Client x64

Windows 11 Client ARM64

Description

Systems with a boot device with a capacity greater than 2.2 terabytes must comply with the following requirements:

• The system must be 64-bit.


• The system must comply with the UEFI requirements in the section system.fundamentals.firmware.
• The system must comply with Advanced Configuration and Power Interface (ACPI) Specification version 4.0.
Specifically, the system must be able to support legacy or Operating System-directed configuration and Power
Management (OSPM)/ACPI mode.

Page 128 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.Firmware.CS
System.Fundamentals.Firmware.CS.CryptoCapabilities
System that support Modern Standby must include cryptographic capabilities to meet customer expectations on platform
speed and performance.

Applies to Windows 11 Client x64

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.

Page 129 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 cryptographic capabilities in accordance with Table 1 shall be accessible from the runtime OS in kernel mode,
through the interface specified in Microsoft Corporation, "BCrypt Profile for SoC Acceleration," 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.

Algorithm Category Modes Mandatory Remarks


Supported Key
Size(s)
3-DES O ECB, CBC, CFB8 112, 168
AES M ECB, CBC, CFB8, 128, 192, 256 Performance >= 60
CFB128, CCM, MBytes/s for AES-128-
CMAC, GCM, CBC and AES-128-ECB
GMAC encryption and
decryption as measured
at the CNG kernel-mode
BCrypt interface when
processing 32 kByte
blocks.
O CTR, XTS, IAPM 128, 192, 256
RSA O PKCS #1 v1.5, 512 to 16384 in 8- Public key performance
PSS, OAEP byte increments for 2048-bit keys (and
public exponent F4
(0x10001)) when
verifying PKCS#1v1.5
padded signatures,
measured at the kernel
mode BCrypt interface
<=0.6 ms/verification.
ECC O ECDSA, ECDH 256 If implemented, must
support Elliptic curve P-

Page 130 of 208


Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
256 defined in National
Institute for Standards
and Technology, "Digital
Signature Standard,"
FIPS 186-3, June 2009.
SHA-1 O Performance
>60 Mbytes/s as
measured at the CNG
kernel-mode BCrypt
interface when
processing 4kByte
blocks.
HMAC-SHA1 O
SHA-256 O Performance
>60 Mbytes/s as
measured at the CNG
kernel-mode BCrypt
interface when
processing 4kByte
blocks.
HMAC SHA-256 O
RNG M Entropy source Security strength must
with optional be at least 256 bits1.
FIPS 800-90- Note that exposing this
based DRBG functionality through the
UEFI Entropy-Gathering
Protocol is required (see
Req 3) and exposing it
as an OS entropy source
is recommended (see
Req 7).

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.

Applies to Windows 11 Client x64

Page 131 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

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.

Page 132 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. Platforms shall be UEFI Class three (see UEFI Industry Group, Evaluating UEFI using Commercially Available Platforms
and Solutions, version 0.3, for a definition) with no Compatibility Support Module installed or installable. BIOS
emulation and legacy PC/AT boot must be disabled.
13. Each device is required to leave manufacturing provisioned with all cryptographic seeds and keys that are necessary
to prevent attacks against the device’s Secure Boot, TPM and secure persistent storage implementations. Seeds and
symmetric keys shall be immutable, per-device-unique, and non- predictable (random with sufficient length to resist
exhaustive search; see NIST 800-31A for acceptable key sizes).
14. The platform is required to implement the Hardware Security Testability Interface and share documentation and tools
as specified in System.Fundamentals.Firmware.HSTI.
15. All Security Features marked as Implemented in HSTI must report as Successfully Verified.

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.

Applies to Client x64

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

• PCIe Native Control must be enabled in system firmware


• System firmware must opt-into Kernel DMA Protection using appropriate ACPI flags (See Collaborate
package 4142 which has two whitepapers, "Windows 10 - Memory Access Protection - INTEL Platforms
without Thunderbolt 3 - 19H2 v2 .pdf", and "Kernel DMA Protection for Thunderbolt_OEM Whitepaper-
Sept2018EEAP.pdf". After release of the operating system, the above will be replaced with a public Universal
Resource Locator.

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.

Applies to Windows 11 Client x64

Page 133 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

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

Standard v2.3 + errata Bv2 www.uefi.org

Mantis Change Number 616 www.uefi.org (This is not part of v2.3)

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.

Applies to Windows 11 Client x64

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.

Page 134 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 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.

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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

Applies to Windows 11 Client x64

Page 135 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

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

Power Management Requirements


Following are the power management requirements for the discrete GPU participating in a hybrid configuration:

• The driver is required to register for runtime power management.


• The driver needs to register certain power components based on the following scenarios.

Device does not require D3 DXGK_POWER_COMPONENT_ENGINE component for each GPU


transitions engine (node)
A DXGK_POWER_COMPONENT_D3_TRANSITION component with one
F state
Device requires D3 transitions and A DXGK_POWER_COMPONENT_D3_TRANSITION component with two F
has no self-refresh memory states
DXGK_POWER_COMPONENT_ENGINE component for each GPU engine
(node)
A DXGK_POWER_COMPONENT_MEMORY component for each memory
segment.

Page 136 of 208


Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
If TransitionalLatency of this component is > 200us, component must
also have
DXGK_POWER_COMPONENT_FLAGS::DriverCompletesFStateTransition
flag set

Device requires D3 transitions and A DXGK_POWER_COMPONENT_D3_TRANSITION component with two F


has self-refresh memory states
DXGK_POWER_COMPONENT_ENGINE component for each GPU engine
(node)
A DXGK_POWER_COMPONENT_MEMORY component for every memory
segment and with the
DXGK_POWER_COMPONENT_FLAGS::ActiveInD3 flag set.
This component must report 2 F States and TransitionalLatency of F1
state must be 0
One DXGK_POWER_COMPONENT_MEMORY_REFRESH component for the
adapter. Also, the driver must leave space in dependency array for all
device engines
• Transitional Latency reported for each component must not be greater than max. Latency tolerance for that
component is specified in the table below.

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.

Page 137 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

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.

Windows is designed to work best in native resolution.


This requirement applies to systems that use UEFI or BIOS.

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.

Applies to Windows 11 Client x64

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:

• Enable/Disable any adapters:


o The firmware must offer the user the ability to select which adapter is enabled or disabled
o At any given time at least one adapter, that supports POST, must be enabled
o If the user enables an adapter, and the system only supports one active adapter at a time, then all other
adapters must be disabled
o If the only enabled adapter is not detected, the firmware will, fallback to the integrated adapter. If there
is no integrated adapter, then fallback to the first adapter found on the first bus

Page 138 of 208


Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
• Select the adapter to be used as POST device
o Firmware must only allow the user to select one adapter as the POST device.
o A System with an integrated adapter is allowed to POST only on an adapter that cannot be physically
removed from the system
o At any given time at least one adapter, that supports POST, must be enabled
o If multiple adapters that support POST are enabled, the firmware must provide the user an option to
select which one will be used for POST

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.

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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

Page 139 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 platforms that don't implement the ARM defined Generic Interval Timer (GIT), the platform should have CSRT
table with resource groups that describe the timer resources. In addition, The OS image on the platform must contain
Microsoft signed HAL extensions that are properly linked to the entries in the CSRT, and these HAL extensions must
register the following minimum timer resources required by Windows:

• a timer (minimum resolution of one millisecond),


• a counter (Minimum resolution 1 usec),
• an always on timer (must also be registered with a resolution of at least one millisecond), and
• an always on counter (registered with a resolution of a least 1 millisecond)

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.

Page 140 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.Input
Requirements in this section apply to HID devices that are integrated in the system.

System.Fundamentals.Input.I2CDeviceUniqueHWID
I2C connected HID devices must have a Unique HWID along with a HID compatible ID.

Applies to Windows 11 Client x64

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:

See Microsoft published HID I2C protocol specification.

System.Fundamentals.Input.PS2UniqueHWID
All PS/2 connected devices (such as internal keyboards) must have a unique hardware ID.

Applies to Windows 11 Client x64

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:

See Microsoft unique hardware ID whitepaper http://www.microsoft.com/whdc/device/input/mobileHW-IDs.mspx.

Page 141 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.MarkerFile
A marker file is used to help associate WER data with specific computer models. Requirements in this section describe
the syntax for the "marker file.

System.Fundamentals.MarkerFile.SystemIncludesMarkerFile
System includes marker file

Applies to Windows 11 Client x64

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

For companies without a PCI Vendor ID


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.

Page 142 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.Network

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.

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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.

Applies to Windows 11 Client x64

Page 143 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
Support of this feature is required. All physical network devices included in a system (inclusive of docking stations)
must meet the device-level power management requirements for that specific device type. Example: If an Ethernet
device is included in a Modern Standby capable system or associated dock, that Ethernet device must meet the power
management requirements for Modern Standby regardless of whether the individual device certification was achieved
when tested on a Modern Standby capable system or not.

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.

Applies to Windows 11 Client x64

Description

Page 144 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 systems which ship with a dock, the system must be able to hibernate and resume when changing from the
docked to undocked state or the undocked to the docked state. This is not limited to, but should include that the
memory map should not change when docking or undocking the system.

System.Fundamentals.PowerManagement.Lid
If a system has a physical lid, then lid state (open/close) is validated.

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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:

• Basic Lid Requirement Test

Prerequisites:

This requirement only applies to systems with a lid.

System.Fundamentals.PowerManagement.MultiPhaseResume
Storage subsystem supports multi-phase resume from Hibernate

Applies to Windows 11 Client x64

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:

• Any crashdump filters/minifilters that must support read


• No WHEA pshed plugins are installed

Page 145 of 208


Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
• Hypervisor is not enabled

System.Fundamentals.PowerManagement.PCSupportsLowPowerStates
Systems support S4 and S5 and either S0 low power idle or S3, states.

Applies to Windows 11 Client x64

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.

FACP - Field Bit Len. Bit Offset Description


LOW_POWER_S0_IDLE_CAPABLE 1 21 This flag indicates if the system supports low power
idle states in the ACPI S0 state.
A value of one (1) indicates that the platform
supports sufficiently low S0 idle power such that
transitions to the S3 state are not required. OSPM
may interpret a one in a manner that it favors
leaving the platform in the S0 state with many
devices powered off over the S3 state when the
user is no longer interacting with the platform.
Reserved 10 22 Reserved for future use.

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

Page 146 of 208


Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
devices to put into a sleep state when not being used. All devices must comply with the request from the system to
go into a sleep state and not veto the request thereby putting an additional drain on the power source.

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.

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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:

• MS exit latency of < 1 second*


• Software DRIPS achieved >= 80%
• Divergence between Software and Hardware DRIPS <= 10%

*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.

This test will verify that:

• 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

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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.

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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

Page 148 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 help ensure proper enumeration of capabilities, the system will be subjected to the following test:

• Processor Power Management

System.Fundamentals.PowerManagement.ModernStandby.DirectedFx.Reliability
Drivers for devices in DRIPS constraint device hierarchies on Modern Standby systems must support Directed PoFx (DFx)

Applies to Windows 11 Client x64

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.

Modern Standby DFx Tests – Optional

WDK single device test / HLK device level test.


These are intended for testing DFx on one or more devices; they will verify the following for each device:

• The device supports DFx


• All its children devices that must be powered down before it can be powered down support DFx
• The device successfully completes at least one directed power-down/up cycle
• Optionally verifies that the device enters the correct D-state after completing a directed power-down

HLK device level test: Device.Power.DirectedFx

WDK single device test: pwrtest under the switch ‘\directedfx’

More details about these tests can be found in the DFx Partner Implementation Guide.

Prerequisites

• System must support Modern Standby

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.

Page 149 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

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:

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:

• MS exit latency of < 1 second*


• Software DRIPS achieved >= 80%
• Divergence between Software and Hardware DRIPS <= 10%

*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.

Page 150 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.Reliability
System.Fundamentals.Reliability.SystemReliability
Drivers in a system must be reliable.

Applies to Windows 11 Client x64

Windows 11 Client ARM64

Description

All drivers in a system must pass all requirements under Device.DevFund.Reliability. All systems will need to pass
Common Scenario stress:

• Enable/Disable with IO before and after


• Sleep stress with IO before and after

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

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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)

Page 151 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.Security.FIDO
Systems must ensure that a FIDO authenticator (U2F / CTAP) is NOT built in chassis

Applies to Windows 11 Client x64

Windows 11 Client ARM64

Description:

In enterprise setting we see two types of workers:

1. Workers with dedicated PCs


2. Workers in a shared PC deployment

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.

Applies to Windows 11 Client x64

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.

Applies to Windows 11 Client x64

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

Applies to Windows 11 Client x64

Page 153 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:

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:

USB Camera requirements:

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.

MIPI Camera requirements:

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.

Page 154 of 208


Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
8. Components running in the normal OS are not allowed to modify IR frames. If a vendor DMFT is provided, it will
be blocked from modifying the contents of the IR frames.
9. Camera must support camera DDI definitions and interfaces to operate in secure mode.
10. Camera must not support any means to replay a previously captured frame.
11. Camera firmware must be updateable using a hardened mechanism or sensor must not support in field firmware
updates.

Fingerprint requirements:

1. Fingerprint module must meet all criteria described under Device.FingerPrintReader.Base.


2. Fingerprint module must be built into the system. External, pluggable sensors are not supported.
3. Fingerprint sensor must support capability for the secure connection protocol and encryption capability.
4. Fingerprint sensor must support all WBDI IOCTLS required for the secure connection protocol.
5. Engine adapter must support all methods for enrolling and identifying securely.
6. Fingerprint sensor must contain a Microsoft issued certificate with an ECDSA-capable public key. The certificate is
issued to an IHV after it has gone through a certification process to show that its sensor meets all security
requirements.
7. Fingerprint sensor must support a form of secure boot. The sensor must have a non-updateable bootloader
capable of hashing the executable firmware on the device.
8. Fingerprint sensor must have a private key that is unique per device. This key must only be accessible to the non-
updateable bootloader.
9. The bootloader must generate an ephemeral ECDH key pair on every boot, which must be made available to the
device firmware.
10. Third party fingerprint management applications (FMA) are not supported for this configuration of fingerprint.

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.

Applies to Windows 11 Client x64

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.

Page 156 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 feature is described here: https://techcommunity.microsoft.com/t5/windows-kernel-internals/understanding-
hardware-enforced-stack-protection/ba-p/1247815

Details on how it is implemented in Windows here: https://techcommunity.microsoft.com/t5/windows-kernel-


internals/developer-guidance-for-hardware-enforced-stack-protection/ba-p/2163340

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

Applies to Windows 11 Client x64


Windows 11 ARM x64

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:

Page 157 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 table shows the hardware, firmware and software requirements for Credential Guard.

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.

1. MUST meet all HVCI Compatible Driver requirements as described in


“Filter.Driver.DeviceGuard.DriverCompatibility”.
2. MUST meet the additional requirements as described in the table below:

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

Page 158 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 firmware UEFI Secure Boot ensures that the device boots only authorized code. Additionally, Boot
version 2.3.1.c or Integrity (aka Platform Secure Boot) must be supported following the requirement in
higher with UEFI Hardware Compatibility Specification for Systems for Windows 10:
Secure Boot and
System.Fundamentals.Firmware.UEFISecureBoot
Platform Secure Boot
System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby (this includes
Hardware Security Test Interface)

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.

Virtualization The following virtualization extensions are required to support virtualization-based


extensions security:

1. Intel VT-X or AMD-V


2. Second Level Address Translation (Intel Extended Page Tables, AMD Rapid
Virtualization Indexing)

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.

UEFI runtime services must meet these requirements:

• Implement the UEFI 2.6 EFI_MEMORY_ATTRIBUTES_TABLE. All UEFI runtime service


memory (code and data) must be described by this table.
• PE sections need to be page-aligned in memory (not required in non-volatile storage).
• The Memory Attributes Table needs to correctly mark code and data as RO/NX for
configuration by the OS:
o All entries must include attributes EFI_MEMORY_RO, EFI_MEMORY_XP, or both.
o No entries may be left with neither of the above attributes, indicating memory that
is both executable and writable. Memory must be either readable and executable
or writeable and non-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.

Please also note the following:

• Do not use sections that are both writable and executable

Page 159 of 208


Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
• Do not attempt to directly modify executable system memory
• Do not use dynamic code

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

Applies to Windows 11 Client x64


Windows 11 Client ARM64

Term: if-implemented

Description

The platform must meet all baseline requirements for


System.Fundamentals.Security.VirtualizationBasedSecurity.VirtualizationSupport.

• 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

o Platforms must configure SMM access to the MMIO pages as follows:


Page 160 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
• Write access must be denied to any MMIO or other system registers which allow configuration
of any of the system IOMMUs
o Platforms must configure access to the PCI related IO ports as follows:
• Write access must be denied to the configuration space address (0xCF8) I/O port
• Write access must be denied to the configuration space data (0xCFC) I/O port
• BIOS SMI handler should be implemented such that PCIe configuration space access happens
only via memory-mapped IO
o Platforms must ensure that SMM does NOT contain any mappings to the following Model Specific
Registers:
• X86X_IA32_PMG_IO_CAPTURE_BASE
• X86X_IA32_MSR_DS_AREA
• X86X_IA32_MSR_PKG_HDC_CONFIG
• X86X_IA32_MSR_PKG_HDC_RESIDENCY
• X86X_IA32_MSR_PKG_HDC_SHALLOW_RESIDENCY
• X86X_IA32_MSR_PKG_HDC_DEEP_RESIDENCY
• X86X_IA32_MSR_WEIGHTED_CORE_CO
• X86X_IA32_MSR_UNC_CBO_0_PERF_EVT_SEL0
• X86X_IA32_MSR_UNC_CBO_0_PERF_EVT_SEL1
• X86X_IA32_MSR_UNC_CBO_0_PERF_CTR0
• X86X_IA32_MSR_UNC_CBO_0_PERF_CTR1
• X86X_IA32_MSR_UNC_CBO_1_PERF_EVT_SEL0
• X86X_IA32_MSR_UNC_CBO_1_PERF_EVT_SEL1
• X86X_IA32_MSR_UNC_CBO_1_PERF_CTR0
• X86X_IA32_MSR_UNC_CBO_1_PERF_CTR1
• X86X_IA32_MSR_UNC_CBO_2_PERF_EVT_SEL0
• X86X_IA32_MSR_UNC_CBO_2_PERF_EVT_SEL1
• X86X_IA32_MSR_UNC_CBO_2_PERF_CTR0
• X86X_IA32_MSR_UNC_CBO_2_PERF_CTR1
• X86X_IA32_MSR_UNC_CBO_3_PERF_EVT_SEL0
• X86X_IA32_MSR_UNC_CBO_3_PERF_EVT_SEL1
• X86X_IA32_MSR_UNC_CBO_3_PERF_CTR0
• X86X_IA32_MSR_UNC_CBO_3_PERF_CTR1
• For Intel vPro® processors starting with Intel® Whiskey Lake 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)

Page 161 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 Platform must set up an AUX index with index, attributes, and policy that exactly corresponds to the AUX
index specified in the TXT DG with a data size of exactly 104 bytes (for SHA256 AUX data). (NameAlg =
SHA256)
• Required AUX policy must be as follows:
• A = TPM2_PolicyLocality (Locality 3 & Locality 4)
• B = TPM2_PolicyCommandCode (TPM_CC_NV_UndefineSpecial)
• authPolicy = {A} OR {{A} AND {B}}
• authPolicy digest = 0xef, 0x9a, 0x26, 0xfc, 0x22, 0xd1, 0xae, 0x8c, 0xec, 0xff, 0x59, 0xe9,
0x48, 0x1a, 0xc1, 0xec, 0x53, 0x3d, 0xbe, 0x22, 0x8b, 0xec, 0x6d, 0x17, 0x93, 0x0f, 0x4c,
0xb2, 0xcc, 0x5b, 0x97, 0x24
o On Platform without converged BtG/TXT the platform must set up a PS (Platform Supplier) index with:
• Exactly the “TXT PS2” style Attributes on creation as follows:
o AuthWrite |
o PolicyDelete |
o WriteLocked |
o WriteDefine |
o AuthRead |
o NoDa |
o Written |
o PlatformCreate
• A policy of exactly PolicyCommandCode(CC = TPM2_CC_UndefineSpaceSpecial) (using SHA256 to
compute policy digest)
• Size of exactly 70 bytes
• NameAlg = SHA256
• In addition, it must have been initialized and locked (TPMA_NV_WRITTEN = 1,
TPMA_NV_WRITELOCKED = 1) at time of OS launch.
• PS index data DataRevocationCounters, SINITMinVersion, and PolicyControl must all be
0x00

• This index is no longer required for Ice Lake platforms or newer.

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}}.

Page 162 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 exact policy hash digest value (a sha-256 digest) will be pre-computed for the latest
MSFT_DRTM_AUTH_BLOB_SigningKey and will be made available alongside the
corresponding HLK test.

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 Recommended: System firmware should be updated via UpdateCapsule in Windows Update

• For Intel Server platform supports Converged BtG/TXT (CBnT)


o Platforms must meet the boot DMA protection requirement described in
System.Fundamentals.Firmware.NoExternalDMAOnBoot.
o Platforms must support discrete TPM 2.0 or integrated TPM 2.0 (Intel PTT)
o Platforms will have S3 disabled when SystemGuard is enabled
o Platform must set up a AUX index with index, attributes, and policy that exactly corresponds to the
AUX index specified in the TXT DG with a data size of exactly 104 bytes (for SHA256 AUX data).
(NameAlg = SHA256)
• Required AUX policy must be as follows:
o A = TPM2_PolicyLocality (Locality 3 & Locality 4)
o B = TPM2_PolicyCommandCode (TPM_CC_NV_UndefineSpecial)
o authPolicy = {A} OR {{A} AND {B}}
o authPolicy digest = 0xef, 0x9a, 0x26, 0xfc, 0x22, 0xd1, 0xae, 0x8c, 0xec, 0xff, 0x59,
0xe9, 0x48, 0x1a, 0xc1, 0xec, 0x53, 0x3d, 0xbe, 0x22, 0x8b, 0xec, 0x6d, 0x17, 0x93,
0x0f, 0x4c, 0xb2, 0xcc, 0x5b, 0x97, 0x24

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)

Page 163 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 authPolicy = {A} OR {{A} AND {B}}.
o The exact policy hash digest value (a sha-256 digest) will be pre-computed for
the latest MSFT_DRTM_AUTH_BLOB_SigningKey and will be made available
alongside the corresponding HLK test.

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® processors Zen2® and beyond

o Platforms must have Transparent Secure Memory Encryption (TSME) enabled.


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 have AMD Secure Processor Firmware anti-rollback protection enabled.
o Platforms must provide mechanism to protect the SMM page tables from unauthorized modification:
o Platforms must support Modern/Connected Standby (S3 will not be in scope in the future for this
feature)
o Platforms must support a TPM 2.0 device
• Supported TPM 2.0 devices are discrete TPM 2.0 and Pluton-based firmware TPM 2.0
o
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}}.

Page 164 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 exact policy hash digest value (a sha-256 digest) will be pre-computed for the
latest MSFT_DRTM_AUTH_BLOB_SigningKey and will be made available alongside the
corresponding HLK test.
o The shipping OEM Windows system image MUST be built to include a corresponding AMDSL
package with all code required to execute an AMD® SKINIT secure launch.
o Recommended: System firmware should be updated via UpdateCapsule in Windows Update

• For AMD® Ryzen® PRO® processors starting with Zen3® and beyond

o Platforms must configure SMM access to the MMIO pages as follows:


• Write access must be denied to any MMIO or other system registers which allow configuration of any of
the system IOMMUs
o Platforms must configure access to the PCI related IO ports as follows:
• Write access must be denied to the configuration space address (0xCF8) I/O port
• Write access must be denied to the configuration space data (0xCFC) I/O port
o BIOS SMI handler should be implemented such that PCIe configuration space access happens only via
memory-mapped IO.
o Platforms must ensure that SMM does NOT contain any mappings to the following Model Specific Registers:
• MSR0000_01D9 (Core::X86::Msr::DBG_CTL_MSR)
• MSRC000_0080 (Core::X86::Msr::EFER)
• MSRC001_0010 (Core::X86::Msr::SYS_CFG)
• MSRC000_0081 (Core::X86::Msr::STAR)
• MSRC000_0082 (Core::X86::Msr::STAR64)
• MSRC000_0083 (Core::X86::Msr::STARCOMPAT)
• MSRC000_0084 (Core::X86::Msr::SYSCALL_FLAG_MASK)
• MSRC001_0111 ((Core::X86::Msr::SMM_BASE)
• MSR0000_0DA0 (Core::X86::Msr::XSS)
• MSR0000_06A0 (Core::X86::Msr::U_CET)
• MSR0000_06A2 (Core::X86::Msr::S_CET)
• MSR0000_06A4 (Core::X86::Msr::PL0Ssp)
• MSR0000_06A5 (Core::X86::Msr::PL1Ssp)
• MSR0000_06A6 (Core::X86::Msr::PL2Ssp)
• MSR0000_06A7 (Core::X86::Msr::PL3Ssp)
• MSR0000_06A8 (Core::X86::Msr::IstSspAddr)

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)

o Recommended: Platforms should configure access to SMM Save State as follows:


o Read/write access from/to State Save registers should be denied, except:
• Read access to Core::X86::Smm::TrapOffset – always allowed.
• Read access to AL/AX/EAX on trapped IO port write (size derived from
Core::X86::Smm::TrapOffset)
• Write access to AL/AX/EAX on trapped IO port read (size derived from
Core::X86::Smm::TrapOffset)
• Note: No support for INS or OUTS trapping

Page 165 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 AMD® EPYC Server processors support SKINIT
o Platforms must have Transparent Secure Memory Encryption (TSME) enabled.
o Platforms must meet the boot DMA protection requirement described in
System.Fundamentals.Firmware.NoExternalDMAOnBoot.
o Platforms must have AMD Secure Processor Firmware anti-rollback protection enabled.
o Platforms will have S3 disabled when SystemGuard is enabled
o Platforms must support a discrete TPM 2.0. Integrated/firmware TPMs are not supported.
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 The exact policy hash digest value (a sha-256 digest) will be pre-computed for the latest
MSFT_DRTM_AUTH_BLOB_SigningKey and will be made available alongside the corresponding HLK
test.
• The shipping OEM Windows system image MUST be built to include a corresponding AMDSL package with
all code required to execute an AMD® SKINIT secure launch.

• For Qualcomm processors with SD850 or later chipsets:


o All Monitor Mode communication buffers must be implemented in either EfiRuntimeServicesData
(recommended), data sections of EfiRuntimeServicesCode as described by the Memory Attributes
Table, EfiACPIMemoryNVS, or EfiReservedMemoryType memory types
o All Monitor Mode page tables must:
▪ Do NOT contain any mappings to EfiConventionalMemory (e.g. no OS/VMM owned
memory)
▪ They must NOT have execute and write permissions for the same page
▪ Platforms must only allow Monitor Mode pages marked as executable
▪ The memory map must report Monitor Mode as EfiReservedMemoryType
▪ Platforms must provide mechanism to protect the Monitor Mode page tables from
modification
o Platforms must support Modern/Connected Standby (S3 will not be in scope in the future for this
feature)
o Platform firmware must carry all code required to perform a launch
o Platform firmware must be updated via UpdateCapsule and deliverable via Windows Update
o Platform firmware must set up a TPM NV index for use by the OS with:
▪ Handle: 0x01C101C0
Page 166 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
▪ 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:
• TPMA_NV_POLICYWRITE
• TPMA_NV_PPREAD
• TPMA_NV_OWNERREAD
• TPMA_NV_AUTHREAD
• TPMA_NV_POLICYREAD
• TPMA_NV_NO_DA
• TPMA_NV_PLATFORMCREATE
• TPMA_NV_POLICY_DELETE.
▪ Policy:
• A = TPM2_PolicyAuthorize(MSFT_DRTM_AUTH_BLOB_SigningKey)
• B = TPM2_PolicyCommandCode(TPM_CC_NV_UndefineSpaceSpecial)
• authPolicy = {A} OR {{A} AND {B}}.
• The exact policy hash digest value (a sha-256 digest) will be pre-computed for
the latest MSFT_DRTM_AUTH_BLOB_SigningKey and will be made available
alongside the corresponding HLK test.

System.Fundamentals.SignedDrivers
This feature checks for signed drivers.

System.Fundamentals.SignedDrivers.BootDriverEmbeddedSignature
Boot drivers must be self-signed with an embedded signature.

Applies to Windows 11 Client x64

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

Page 167 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 verify the signature. Check the results to verify that the root of the SPC's certificate chain for kernel policy is
"Microsoft Code Verification Root." The following command line verifies the signature on the toaster.sys file:
Signtool verify /kp
/v amd64\toaster.sys

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.

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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.

Systems must meet the following dependent device-level requirements.

▪ 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.

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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:

• (Table 0, offset 04h) BIOS Vendor


• (Table 0, offset 08h) BIOS Release Date
• (Table 0, offset 14h) BIOS Major Release Version1
• (Table 0, offset 15h) BIOS Minor Release Version1
• (Table 1, offset 04h) System Manufacturer2
• (Table 1, offset 05h) System Product Name2
• (Table 1, offset 07h) Serial Number4
• (Table 1, offset 08h) Universal Unique ID number
• (Table 1, offset 19h) System SKU Number2

Page 169 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 1, offset 1Ah) Family2
• (Table 2, offset 05h) Base Board Product2
• (Table 3, offset 05h) Type2

Microsoft recommends that the following fields have non-Null values that accurately describe the computer system or
computer system component:

• (Table 0, offset 05h) BIOS Version


• (Table 0, offset 16h)Embedded Controller Major Release Version3
• (Table 0, offset 17h) Embedded Controller Minor Release Version3
• (Table 1, offset 06h) System Version
• (Table 1, offset 1Bh) System Family2
• (Table 2, offset 04h) Base Board Manufacturer
• (Table 2, offset 05h) Base Board Product
• (Table 2, offset 06h) Base Board Version

1These fields must not have values equal to 0FFh.

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.

4 For Windows Server, this field is optional, i.e., If Implemented.

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.

Page 170 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.StorageAndBoot.BootPerformance
Boot Devices in systems that support Modern Standby must meet these requirements.

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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.

Storage Type Boot Data Disk


SATA Yes Yes
USB No Yes
NVMe Yes Yes
eMMC 4.5+ Yes Yes
SD 2.0+ No Yes
UFS 2.0+ Yes Yes

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

Support GPIO card detection on SD/eMMC Storage Controller.

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.

Feature Span Size Specification


Power
Page 171 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
Max Idle Power - <= 5 mW
Random Performance
4KB Write IOPs 1 GB >= 200
*5 GB >= 50
†10 GB >= 50
64KB Write IOPs 1 GB >= 25
4KB Read IOPs *5 GB >= 2000
†10 GB >= 2000
4KB 2:1 read/write mix IOPs 1 GB >= 500
* 5GB >= 140
†10 GB >= 140
Sequential Performance
Write speed (64KB I/Os) *5 GB >= 40 MB/s
†10 GB >= 40 MB/s
Write speed (1MB I/Os) *5 GB >= 40 MB/s
†10 GB >= 40 MB/s
Read speed (64KB I/Os) *5 GB >= 60 MB/s
‡>= (120 MB/s)
†10GB >= 60 MB/s
‡>= (120 MB/s)
Device I/O Latency
Max Latency - < 500 milliseconds

*Applies only to devices with 16 GB of internal storage or lower.

†Applies only to devices with greater than 16 GB of internal storage.

‡Applies only if the device is HS200 capable.

Additional I/O Latency requirement:

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.

Applies to Windows 11 Client x64

Page 172 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 requirements apply if Encrypted Drive (System.Fundamentals.StorageAndBoot.EncryptedDrive)


support is implemented for a UEFI based client system or server systems:

a. The system MUST have a TPM 2.0.

b. The system MUST implement the EFI_STORAGE_SECURITY_COMMAND_PROTOCOL from either:

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.

d. The EFI_STORAGE_SECURITY_COMMAND_PROTOCOL and the TPer Reset command MUST be included in


the base UEFI image (not in a separate image of a UEFI driver).

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.

Applies to Windows 11 Client x64

Description

AHCI Host Controllers using Windows for boot support must be compliant with the AHCI specification.

Host Controller Interface Revision

AHCI 1.1, 1.2, 1.3

System with SATA controller must enable AHCI mode support.


Externally connected SATA devices (eSATA) are not supported for boot storage.
Page 173 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
When SATA is used as the primary boot device, to ensure reliability and prevent inadvertent erasure of the firmware
that may cause the device to become inoperable, the boot critical portion of the UEFI firmware must reside on a
separate storage device that is not accessible by the host Operating System. The CPU Vendor and/or Firmware
Provider must furnish the software tools needed to maintain and update the firmware.

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.

Page 175 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.StorageClassMemory.NVDIMMN.Label
System.Fundamentals.StorageClassMemory.NVDIMMN.Label (if implemented)

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.

Applies to Windows 11 Client x64

Windows 11 Client ARM64

Description

Systems need to conform to all Device.Audio requirements.

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:

• MS exit latency of < 1 second*


• Software DRIPS achieved >= 80%
• Divergence between Software and Hardware DRIPS <= 10%

*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

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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

Windows 11 Client ARM64

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

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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.

Page 178 of 208


Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
Reverse bridge implementations as defined in Appendix A of the PCI Express to PCI/PCI-X Bridge
Specification are not supported in Windows
A reverse bridge will not be supported if it adheres to the guidelines and recommendations as defined in
Appendix A of the PCI Express to PCI/PCI-X Bridge Specification, Revision 1.0.

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.

PCI-to-PCI bridges comply with PCI-to-PCI Bridge Architecture Specification


All PCI-to-PCI bridges must comply with PCI-to-PCI Bridge Architecture Specification, Revision 1.2.

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

Applies to Windows 11 Client x64


Windows 11 Client ARM64

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.

USB Host Controller Interface Recommendation


UHCI/OHCI Companion Controllers Not-supported
EHCI Supported
XHCI (including debug capability) Supported and Recommended

System.Fundamentals.SystemUSB.SuperSpeedCapableConnectorRequirements
Each exposed SuperSpeed capable connector supports SuperSpeed, high, full and low speed USB devices routed through
its xHCI controller.

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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.

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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.

External USB Ports Recommendation


Standard USB A Port(s) Recommended
USB Type-C Port(s) Recommended
Standard USB A Port(s) + USB Type-C Port(s) Recommended
Micro-USB A/B Port + 1 or more Standard USB A Supported
Port
Micro-USB A/B (Host + Function debug) Port Supported
Micro-USB B Port + 1 or more Standard USB A Port Supported
Proprietary Docking Port with USB Host and/or Supported
debug Functionality
Mini-USB A, A/B or B Port Not Supported
Proprietary USB Host Port Not Supported

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

Page 181 of 208


Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
occur if the USB port is connected to another host when it is not properly configured in debug mode. Type-C ports
that expose XHCI host debug can use the same mechanism as Standard-A ports by connecting a C-to-A-receptacle
adapter to the Type-C port first.

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.

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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.

Applies to Windows 11 Client x64

Windows 11 Client ARM64

Description

Page 182 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 USB devices and host controllers work properly upon resume from sleep, hibernation or restart without a forced
reset of the USB host controller.

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

Windows 11 Client ARM64

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.

Applies to Windows 11 Client x64


Windows 11 Client ARM64

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.

Applies to Windows 11 Client x64


Windows 11 Client ARM64

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.

Applies to Windows 11 Client x64


Windows 11 Client ARM64

Description

Page 184 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
interoperability with Thunderbolt® 3 (TBT3) peripherals according to chapter 13 of the USB4 specification.
Specifically, the USB4 Host Router must be interoperable with TBT3 Device Routers and cables; it is not required to be
compatible with a TBT3 Connection Manager. Please also note that TBT3 certification and branding are also not
required for this requirement.

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.

Applies to Windows 11 Client x64


Windows 11 Client ARM64

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.

Applies to Windows 11 Client x64


Windows 11 Client ARM64

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

Applies to Windows 11 Client x64

Page 185 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
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

Applies to Windows 11 Client x64


Windows 11 Client ARM64

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.

USB Capabilities must remain unchanged for a boot session.

System.Fundamentals.SystemUSB.USB4.GraphicsDriverMustSupportUSB4
Systems that support USB4 must support a USB4 capable graphics driver

Applies to Windows 11 Client x64

Windows 11 Client ARM64

Description

Below is an overview of the graphics driver requirements :

1) WDDM 3.0 or above driver


2) Driver exposes a new adapter cap to indicate USB4 support
Page 186 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
3) All static VidPn targets exposed by driver need to be reported as power components
4) Driver needs to report when a DisplayPort monitor is connected via a USB4 hub

System.Fundamentals.SystemUSB.USB4.TunneledUSB3PortMapping
Systems with USB4 Host Routers must support _DSD to report USB3 – USB4 port mapping to Windows.

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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.

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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.

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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.

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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

Page 188 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

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

The UcmCx client driver is required to implement the following APIs:

• 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

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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:

▪ Supported Provider Capabilities Change

▪ Negotiated Power Level Change

▪ Supported CAM Change

• 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:

▪ Supported Provider Capabilities Change

▪ Negotiated Power Level Change

▪ The system or controller must support the following fields in


GET_CONNECTOR_STATUS Status structureProvider Capabilities Limited Reason
▪ Request Data Object

System.Fundamentals.SystemUSB.XhciBiosHandoffFollowsSpec
xHCI BIOS handoff follows specification

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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.

Applies to Windows 11 Client x64

Windows 11 Client ARM64

Description

Please reference ACPI specification version 6.1.

Page 191 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 ACPI namespace hierarchy for USB devices should exactly match the devices hierarchy enumerated by Windows
operating system.

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 motherboard presents 5 user visible connectors C1 - C5:

• Motherboard connectors C1 and C2 support USB2 (LS/FS/HS) devices.


• Motherboard connectors C3, C4 and C5 support USB3 (LS/FS/HS/SS) devices.

• 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):

• External Port 1 (P1) is HS only and is not visible or connectable.


• External Ports 2 - 5 (P2 - P5) support LS/FS/HS devices:

• P2 is attached to motherboard USB2 connector C1.


• P3 is attached to motherboard USB2 connector C2.
• P4 is attached to the USB 2.0 logical hub of the Embedded USB3 Hub on the motherboard. The
USB 2.0 logical hub supports the LS/FS/HS connections for 2 ports (EP1 - EP2)

Page 192 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 USB 2.0 connections of motherboard hub ports EP1 and EP2 are attached to motherboard
connectors C3 and C4 respectively, providing the LS/FS/HS support for the USB3 connectors.

• 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:

• Internal Port 1 (HCP1) maps directly to External Port 1 (P1).


• Internal Port 2 (HCP2) is attached to a HS Integrated Hub. The Integrated Hub supports 4 ports (IP1 -
IP4):

• 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 ) {

// Host controller ( xHCI )


Device( USB0 ) {
// PCI device#/Function# for this HC. Encoded as specified in the ACPI
// specification
Name( _ADR, 0xyyyyzzzz )
// Root hub device for this HC #1.
Device( RHUB ) {
Name( _ADR, 0x00000000 ) // must be zero for USB root hub
// Root Hub port 1 ( HCP1 )
Device( HCP1 ) {// USB0.RHUB.HCP1
Name( _ADR, 0x00000001 )
// USB port configuration object. This object returns the system
// specific USB port configuration information for port number 1
Name( _UPC, Package() {
0x01,// Port is connectable but not visible
0xFF,// Connector type (N/A for non-visible ports)
0x00000000,// Reserved 0 - must be zero
Page 193 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} )// Reserved 1 - must be zero
} // Device( HCP1 )
// Root Hub port 2 ( HCP2 )
Device( HCP2 ) {// USB0.RHUB.HCP2
Name( _ADR, 0x00000002 )
Name( _UPC, Package() {
0xFF,// Port is connectable
0x00,// Connector type - (N/A for non-visible ports)
0x00000000,// Reserved 0 - must be zero
0x00000000} )// Reserved 1 - must be zero
// Even an internal connection point should have a _PLD and
// provide a valid Group Token and Position
Name( _PLD, Buffer( 0x10) {
0x00000081,// Revision 1,
// color width height ignored for non-visible connector
0x00000000,// connector type ignored for non-visible connector
0x00808000,// Not User visible, Panel, position shape ignored,
// Group Token = 1, Group Position = 1
// This is the group of all internal connectors.
// Each connector should have a unique position in this
// group
0x00000000} )// Ignored for non-visible connectors
//
// There is no separate node for the integrated hub itself
//
// Integrated hub port 1 ( IP1 )
Device( IP1 ) {// USB0.RHUB.HCP2.IP1
// Address object for the port. Because the port is
// implemented on integrated hub port #1, this value must be 1
Name( _ADR, 0x00000001 )
Name( _UPC, Package() {
0xFF,// Port is connectable
0x00,// Connector type - Type 'A'
0x00000000,// Reserved 0 - must be zero
0x00000000} )// Reserved 1 - must be zero
// provide physical connector location info
Name( _PLD, Buffer( 0x10) {
0x00000081,// Revision 1, Ignore color
// Color (ignored), width and height not
0x00000000,// required as this is a standard USB 'A' type
// connector
0x00800c69,// User visible, Back panel, Center, left,
// shape = vert. rect, Group Token = 0,
// Group Position 1 (i.e. Connector C1)
0x00000003} )// ejectable, requires OPSM eject assistance
} // Device( IP1 )
// Integrated Hub port 2 ( IP2 )
Device( IP2 ) {// USB0.RHUB.HCP2.IP2
Page 194 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
// Address object for the port. Because the port is
// implemented on integrated hub port #2, this value must be 2
Name( _ADR, 0x00000002 )
Name( _UPC, Package() {
0xFF,// Port is connectable
0x00,// Connector type - Type 'A'
0x00000000,// Reserved 0 - must be zero
0x00000000} )// Reserved 1 - must be zero
// provide physical connector location info
Name( _PLD, Buffer( 0x10) {
0x00000081,// Revision 1, Ignore color
// Color (ignored), width and height not
0x00000000,// required as this is a standard USB 'A' type
// connector
0x01000c69,// User visible, Back panel, Center, Left,
// Shape = vert. rect, Group Token = 0,
// Group Position 2 (i.e. Connector C2)
0x00000003} )// ejectable, requires OPSM eject assistance
} // Device( IP2 )
// Integrated Hub port 3 ( IP3 )
Device( IP3 ) { // USB0.RHUB.HCP2.IP3
// Address object for the port. Because the port is implemented
// on integrated hub port #3, this value must be 3
Name( _ADR, 0x00000003 )
// Must match the _UPC declaration for USB0.RHUB.HCP3 as
// this port shares the connection point
Name( _UPC, Package() {
0xFF,// Port is not connectable
0x00,// Connector type - (N/A for non-visible ports)
0x00000000,// Reserved 0 - must be zero
0x00000000} )// Reserved 1 - must be zero
// Even an internal connection point should have a _PLD and
// provide a valid Group Token and Position.
// Must match the _PLD declaration for USB0.RHUB.HCP3 as
// this port shares the connection point
Name( _PLD, Buffer( 0x10) {
0x00000081,// Revision 1,
// color width height ignored for non-visible connector
0x00000000,// connector type ignored for non-visible connector
0x01008000,// Not User visible, Panel, position shape ignored,
// Group Token = 1, Group Position = 2
// This is the group of all internal connectors.
// Each connector should have a unique position in this
// group
0x00000000} )// Ignored for non-visible connectors
//
// There is no separate node for the embedded hub itself
//
Page 195 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
// Motherboard Embedded Hub 2.0 Logical Hub port 1 ( EP1 )
Device( EP1 ) {// USB0.RHUB.HCP2.IP3.EP1
Name( _ADR, 0x00000001 )
// Must match the _UPC declaration for
// USB0.RHUB.HCP3.EP1 as this port provides
// the LS/FS/HS connection for C3
Name( _UPC, Package() {
0xFF,// Port is connectable
0x03,// Connector type - USB 3 Type 'A'
0x00000000,// Reserved 0 - must be zero
0x00000000} )// Reserved 1 - must be zero
// provide physical connector location info
Name( _PLD, Buffer( 0x10) {
0x0072C601,// Revision 1, Color valid
// Color (0072C6h), width and height not
0x00000000,// required as this is a standard USB
// 'A' type connector
0x01800c69,// User visible, Back panel, Center,
// Left, shape = vert.
// rect, Group Token = 0,
// Group Position 3
//(i.e. Connector C3)
0x00000003} )// ejectable, requires OPSM eject
// assistance
} // Device(EP1)
// Motherboard Embedded Hub 2.0 Logical Hub port 2 ( EP2 )
Device( EP2 ) {// USB0.RHUB.HCP2.IP3.EP2
Name( _ADR, 0x00000002 )
// Must match the _UPC declaration for
// USB0.RHUB.HCP3.EHUB.EP2 as this port provides
// the LS/FS/HS connection for C4
Name( _UPC, Package() {
0xFF,// Port is connectable
0x03,// Connector type - USB 3 Type 'A'
0x00000000,// Reserved 0 - must be zero
0x00000000} )// Reserved 1 - must be zero
// provide physical connector location info
Name( _PLD, Buffer( 0x10) {
0x0072C601,// Revision 1, Color valid
// Color (0072C6h), width and height not
0x00000000,// required as this is a standard USB
// 'A' type connector
0x02000c69,// User visible, Back panel, Center,
// Left, Shape = vert.
// rect, Group Token = 0,
// Group Position 4 (i.e. Connector C4)
0x00000003} )// ejectable, requires OPSM eject
Page 196 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
//assistance
} // Device( EP2 )
} // Device( IP3 )

// Integrated hub port 4 ( IP4 )


Device( IP4 ) { // USB0.RHUB.HCP2.IP4
Name(_ADR, 0x00000004)
// Must match the _UPC declaration for USB0.RHUB.HCP4 as
// this port provides the LS/FS/HS connection for C5
Name( _UPC, Package() {
0xFF,// Port is connectable
0x03,// Connector type - USB 3 Type 'A'
0x00000000,// Reserved 0 - must be zero
0x00000000} )// Reserved 1 - must be zero
// provide physical connector location info
Name( _PLD, Buffer(0x10) {
0x0072C601,// Revision 1, Color valid
// Color (0072C6h), width and height not
0x00000000,// required as this is a standard USB 'A' type
// connector
0x02800c69,// User visible, Back panel, Center, Left,
// Shape = vert. rectangle, Group Token = 0,
// Group Position 5 (i.e. Connector C5)
0x00000003} )// ejectable, requires OPSM eject assistance
} // Device( IP4 )
} // Device( HCP2 )

// Root Hub port 3 ( HCP3 )


Device( HCP3 ) {
Name( _ADR, 0x00000003 )
// Must match the _UPC declaration for USB0.RHUB.HCP2.IP3 as
// this port shares the connection point
Name( _UPC, Package() {
0xFF,// Port is connectable
0x00,// Connector type - (N/A for non-visible ports)
0x00000000,// Reserved 0 - must be zero
0x00000000} )// Reserved 1 - must be zero
// Even an internal connection point should have a _PLD and
// provide a valid Group Token and Position.
// Must match the _PLD declaration for USB0.RHUB.HCP2.IP3 as
// this port shares the connection point
Name( _PLD, Buffer( 0x10) {
0x00000081,// Revision 1,
// color width height ignored for non-visible connector
0x00000000,// connector type ignored for non-visible connector
0x01008000,// Not User visible, Panel, position shape ignored,
// Group Token = 1, Group Position = 2
// This is the group of all internal connectors.
// Each connector should have a unique position in this
Page 197 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
// group
0x00000000} )// Ignored for non-visible connectors
//
// There is no separate node for the embedded hub itself
//
// Motherboard Embedded Hub SS Logical Hub port 1 ( EP1 )
Device( EP1 ) {// USB0.RHUB.HCP3.EP1
Name( _ADR, 0x00000001 )
// Must match the _UPC declaration for
// USB0.RHUB.HCP2.IHUB.IP3.EHUB.EP1 as this port
// provides the SS connection for C3
Name( _UPC, Package() {
0xFF,// Port is connectable
0x03,// Connector type - USB 3 Type 'A'
0x00000000,// Reserved 0 - must be zero
0x00000000} )// Reserved 1 - must be zero
// provide physical connector location info
Name( _PLD, Buffer( 0x10) {
0x0072C601,// Revision 1, Color valid
// Color (0072C6h), width and height not
0x00000000,// required as this is a standard USB
// 'A' type connector
0x01800c69,// User visible, Back panel, Center,
// Left, shape = vert.
// rect, Group Token = 0,
// Group Position 3
//(i.e. Connector C3)
0x00000003} )// ejectable, requires OPSM eject
// assistance
} // Device(EP1)
// Motherboard Embedded Hub SS Logical Hub port 2 ( EP2 )
Device( EP2 ) {// USB0.RHUB.HCP2.EP2
Name( _ADR, 0x00000002 )
// Must match the _UPC declaration for
// USB0.RHUB.HCP3.IP3.EP2 as this port
// provides the SS connection for C4
Name( _UPC, Package() {
0xFF,// Port is connectable
0x03,// Connector type - USB 3 Type 'A'
0x00000000,// Reserved 0 - must be zero
0x00000000} )// Reserved 1 - must be zero
// provide physical connector location info
Name( _PLD, Buffer( 0x10) {
0x0072C601,// Revision 1, Color valid
// Color (0072C6h), width and height not
0x00000000,// required as this is a standard USB
// 'A' type connector
0x02000c69,// User visible, Back panel, Center,
Page 198 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
// Left, Shape = vert.
// rect, Group Token = 0,
// Group Position 4 (i.e. Connector C4)
0x00000003} )// ejectable, requires OPSM eject
// assistance
} // Device( EP2 )
} // Device( HCP3 )
// Root Hub port 4 ( HCP4 )
Device( HCP4 ) {// USB0.RHUB.HCP4
Name( _ADR, 0x00000004 )
// Must match the _UPC declaration for USB0.RHUB.HCP2.IP4 as
// this port provides the SS connection for C5
Name( _UPC, Package() {
0xFF,// Port is connectable
0x03,// Connector type - USB 3 Type 'A'
0x00000000,// Reserved 0 - must be zero
0x00000000} )// Reserved 1 - must be zero
// provide physical connector location info
Name( _PLD, Buffer( 0x10) {
0x0072C601,// Revision 1, Color valid
// Color (0072C6h), width and height not
0x00000000,// required as this is a standard USB 'A' type
// connector
0x02800c69,// User visible, Back panel, Center, Left,
// Shape = vert. rect, Group Token = 0,
// Group Position 5 (i.e. Connector C5)
0x00000003} )// ejectable, requires OPSM eject assistance
} // Device( HCP4 )
} // Device( RHUB )

} // 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.

Applies to Windows 11 Client x64

Windows 11 Client ARM64

Page 199 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

Refer to the eXtensible Host Controller Interface specification, section 4.12.2.

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

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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.

Page 200 of 208


Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
8. For Server Only: The exceptions to these requirements are as follows:
Hardware-level Fault Tolerant sets of Windows Server systems, as defined here:
https://www.windowsservercatalog.com/content.aspx?ctf=AQinfo-systems.htm, are not required to support
TPM as this is incompatible with the Hardware-level Fault Tolerant technology.

System.Fundamentals.TPM20.PlatformSpecifications
All platforms which contain a TPM 2.0 must meet these functionality requirements for proper operation of the TPM.

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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.

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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.

Page 201 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) To achieve this, the trusted execution environment must provide a mechanism of signing the values
of the registers used for Trusted Boot. See the “TCG PC Client Platform Firmware Profile”
specification referenced in System.Fundamentals.TPM20.PlatformSpecifications for details.
3. Mandatory: The UEFI firmware update process must protect against rolling back to insecure firmware 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. See NIST SP 800-147 for details.
4. Mandatory: Platform firmware must ensure invariance of PCRs 0, 2, and 4 across power cycles in the absence of
changes to the platform's static core root of trust for measurements (SRTM). Platform firmware must ensure
invariance of PCR[7] across power cycles in the absence of changes to the platform's static core SRTM.
Attaching a (non-bootable) USB to the platform or attaching the platform to an officially supported docking
station shall not cause changes to the SRTM measurements.
5. Mandatory: If the system is in any state, such as a “manufacturing mode”, “debug mode” or other state which
puts PCR[7] bound assets at risk, allows for memory dumps, is intended for debugging, manufacturing use,
or engineering device use, the platform shall extend PCR[7] to reflect such a state.
6. Mandatory: The platform must be configured to use SHA-256 boot log (PCR) measurements in the shipping
configuration.
a) A platform with a single PCR bank which can be switched between SHA-256 and SHA-384 modes is
acceptable.
b) Use of only SHA1 for PCR banks is not allowed.
c) To adhere to the “TCG PC Client Platform Firmware Profile Specification for TPM Family 2.0 Level 00
Revision 1.04”, Section 3.3.1 “Collection and Reporting of Measurements” a platform with multiple
active PCR banks needs to extend measurements into all active PCR banks.
7. Mandatory: Crypto agile event logs must be supported as specified in the “TCG EFI Protocol Specification”
referenced in System.Fundamentals.TPM20.PlatformSpecifications.
8. Recommended: PPRequiredForClear should be FALSE.
a) In earlier versions of PPI (prior to 1.3) this variable was called “NoPPIClear” and had opposite
polarity. The equivalent setting for NoPPIClear is True. The meaning of this requirement is that the
default configuration should not require the user to accept a prompt to clear the TPM when the
Clear command is sent from the OS using PPI.
b) A system may contain a UEFI option to allow end-users or admins to change this setting, and/or be
compatible with a tool to automate changing this setting.
9. Mandatory: PPRequiredForTurnOn must be FALSE.
10. Mandatory: PPRequiredForTurnOff must be TRUE.
11. Mandatory: PPRequiredForChangeEPS must be TRUE.
12. Mandatory: PPRequiredForChangePCRs must be FALSE.
13. Mandatory: If the memory for the TPM is a System rather than TPM component, the TPM must not lose access
to NV before ExitBootServices.
14. Mandatory: Windows should be able to set authorization values for storage hierarchy and lockout authorization
and lockout policy. Windows expects to be able to create at least 20 NV indices.
15. Mandatory: Platform manufacturers must provide in-field firmware updates for security related TPM firmware
updates.
16. Recommended: Platform manufacturers should deliver security related TPM firmware updates to devices via
Windows Update in a timely fashion.
a) An enterprise device management solution for releasing updates is acceptable.
17. Recommended: Platform manufacturers should release all security related TPM firmware updates to certified
devices within 90 days of the date that the TPM manufacturer releases a fix.
a) If the TPM part is Common Criteria or FIPS certified and the firmware update must go through
recertification, the update should be made available within either 90 days of TPM manufacturer
release or 14 days of recertification, whichever is later.
18. Mandatory: The TPM ACPI Object must correctly report if Interrupt based communication is supported.
Page 202 of 208
Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.
19. Mandatory: This requirement is Mandatory for given below platforms:
• Intel platforms with an Intel PTT TPM firmware version of 600.* or higher.
• AMD platforms with an AMD Zen 2 processor (4000 series) or newer
• Qualcomm platforms with storage that supports RPMB (for instance Universal Flash Storage (UFS) or
embedded Multi Media Card (eMMC)).
Confidential & replay-protected storage: If a TPM uses external memory for non-volatile storage of TPM state
(including seeds, proof values, & dictionary attack variables), movement of the TPM state to and from the NV
memory should include protections of that data to ensure confidentiality and integrity of the data and to
mitigate against rollback attacks. This is generally accomplished by encrypting the data, applying a Message
Authentication Code, and storing the resulting record in replay-protected storage such as Replay Protected
Memory Block (RPMB) or Replay Protected Monotonic Counter (RPMC)

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

Applies to Windows 11 Client x64

Description

System BIOS or UEFI firmware must by default:

• Support booting through USB 1.x on OHCI controllers


• Support booting through USB 2.x on EHCI controllers
• Support booting through USB 1.x, 2.x, and 3.x on XHCI controllers.
• Support these on all exposed USB ports up to a hub depth of 3.

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.

Applies to Windows 11 Client x64

Windows 11 Client ARM64

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.

Page 204 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 example, when selectively suspended, a USB touchpad must detect be able to detect a user's touch and signal
resume without requiring the user to press a button. Some devices can lose the ability to detect a wake event when
limited to the selective suspend current, 500 microamps per unit load, 2.5mA max. These devices, such as a USB
Bluetooth enabled module, must be self-powered, not relying solely on the USB bus for power. By drawing power
from another source, the device can detect wake events

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.

Applies to Windows 11 Client x64

Windows 11 Client ARM64

Description

Details of the requirement

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:

Page 205 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. EDID or DisplayID data blocks [least preferred] - The traditional method for describing a display’s color
characteristics is in the firmware/ROM. The sink sets the chromaticity and white point values in the EDID
color characteristics block (see A.2.7 Color Characteristics in CEA-861-F). In addition, the sink sets the HDR
MinCLL, MaxCLL, and MaxFALL luminance parameters (assuming 5-10% screen area) in the CEA 861.3
extension data block.
2. Driver override using the DxgkDdiQueryAdapterInfo DDI - WDDM 2.2 and above provide a mechanism for
the display driver to report display colorimetry data to the OS via the DxgkDdiQueryAdapterInfo DDI. OEMs
provide the display measurements to the display driver via IHV-specific mechanisms. OEMs should work with
their IHV for more information.
3. Advanced color ICC profile [most preferred] - International Color Consortium (ICC) profiles provide a
standardized way to store color information about a computer display; the latest version of the spec is
ICC.1:2010/ISO 15076-1:2010. ICC profiles are files with the .icm or .icc extension.
Some of the required color characteristics are defined in existing public ICC tags (data blocks). Windows RS3
defines a new vendor specific data block – named “MHC2” – to store the remaining characteristics. A
properly formatted ICC profile containing an MHC2 tag is referred to as an “advanced color ICC profile” to
distinguish it from other types of ICC profile which have been supported by Windows for many years.
The recommended method for installing an advanced color ICC profile is via a monitor INF which can
reference the profile as a resource in the INF package. Monitor INFs can be preinstalled in the OS image (for
an integrated display), automatically downloaded via Windows Update, or supplied via another software
delivery mechanism.

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.

Applies to Windows 11 Client x64

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.

Page 206 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.Networking.WLAN
System.Networking.WLAN.PLDR
OS Network Auto Healing Enablement for the OEM System

Applies to Windows 11 Client x64


Windows 11 Client ARM64
Description

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.

What needs to happen to enable OS PLDR?

Who Owns OS PLDR? Microsoft.

When is PLDR triggered? When OS detects that IHV driver or firmware is not responding and may be hung.

Software Support

1. OS Release OS > Windows 10, version 1607

• The registry key WLANPlatformLevelDeviceResetSupported is no


longer supported as a mechanism to enable PLDR.

2. IHV Driver Needs to use RS1 WDI Spec 1.0.21

• 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.

MSFT General guidance:

More info @ https://docs.microsoft.com/en-us/windows-


hardware/drivers/kernel/resetting-and-recovering-a-device

Hardware Support

Page 207 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 Spec OEM drives this. You have to make sure you have a working reset mechanism
defined in BIOS using the proper ACPI methods. Wi-Fi device can be reset using
HW (reset line) or it can be reset using SW (PCIe bus reset feature for example).
But this is something that the IHV has to specify and clarify to the OEM or BIOS
Vendor.

Page 208 of 208


Microsoft Confidential
© 2022 Microsoft. All rights reserved. By using or providing feedback on these materials, you agree to the attached
license agreement.

You might also like