WDAC File Rule Level: WHQL#

Windows Hardware Quality Lab signing — a Microsoft-operated certification program that tests and cryptographically endorses hardware drivers. The WHQL level in App Control for Business allows files that carry the WHQL Extended Key Usage (EKU) in their signing certificate chain.

Table of Contents#

Overview
What WHQL Is — Background
The WHQL Certification Process
How the WHQL Level Works Technically
The WHQL EKU — OID and Hex Encoding
Certificate Chain / Trust Anatomy
Where in the Evaluation Stack
XML Representation
PowerShell Examples
WHQL vs. Option 02 (Required)
Pros & Cons Table
Attack Resistance Analysis — BYOVD Context
When to Use vs. When to Avoid — Decision Flowchart
Real-World Scenario: End-to-End Sequence
OS Version & Compatibility
Common Mistakes & Gotchas
Summary Table

1. Overview#

The WHQL file rule level in App Control for Business allows the execution of files whose signing certificate chain contains the Windows Hardware Quality Lab EKU (Extended Key Usage). This EKU is placed in certificates issued by Microsoft specifically to drivers and hardware firmware that have passed the Hardware Lab Kit (HLK) test suite and received Microsoft’s certification.

Key characteristics of this level:

Primarily for kernel-mode binaries: Drivers (.sys files) and related kernel-mode components are the typical targets. User-mode binaries are rarely WHQL-signed.
EKU-based trust: Unlike most other WDAC levels that key off certificate subject names or thumbprints, WHQL trust is determined by the presence of a specific OID in the certificate’s Extended Key Usage extension.
Broad by design: Trusts any driver that Microsoft has certified, regardless of which hardware vendor submitted it.
Connected to but distinct from Option 02: The policy option Required:WHQL (Rule Option 02) mandates that all kernel drivers be WHQL-certified; the WHQL rule level is a different concept — it’s the trust grant for files that are WHQL-signed.

2. What WHQL Is — Background#

Windows Hardware Quality Lab#

The Windows Hardware Quality Lab (WHQL) program, now operationally known as the Windows Hardware Compatibility Program (WHCP), is Microsoft’s certification framework for hardware drivers and devices. The program:

Defines a test suite (the Hardware Lab Kit, HLK) that driver vendors must run against their hardware
Requires vendors to submit test results to Microsoft through the Windows Hardware Dev Center portal
Issues a WHQL-signed driver package after verifying the test results meet certification requirements

WHQL signing is distinct from standard Authenticode signing. A regular Authenticode certificate (from DigiCert, Sectigo, etc.) allows a vendor to self-sign their driver with their own identity. WHQL signing means Microsoft itself cryptographically endorses the driver using a certificate with the WHQL EKU embedded.

Why WHQL Matters to WDAC#

Before WDAC, the primary kernel-mode trust mechanism was the kernel-mode code signing policy introduced in Windows Vista 64-bit (which required all kernel drivers to be signed). WDAC extends this by allowing organizations to specify which signed drivers they permit.

The WHQL level is the most practical way to allow all properly-certified drivers without enumerating every driver vendor individually. It represents Microsoft’s explicit endorsement: “We tested this driver, it met our quality bar, and we signed it with our WHQL certificate.”

3. The WHQL Certification Process#

1
sequenceDiagram
2
    participant Vendor as Hardware Vendor
3
    participant HLK as HLK Test Lab (Vendor's)
4
    participant Portal as Windows Hardware Dev Center
5
    participant MSFT as Microsoft WHQL Team
6
    participant Sign as Microsoft Signing Service
7
    participant Driver as WHQL-Signed Driver Package
8

9
    Vendor->>HLK: Run Hardware Lab Kit test suite against device
10
    HLK-->>Vendor: HLK test results (.hlkx package)
11

12
    Vendor->>Portal: Submit HLK results via Dev Center portal
13
    Portal->>MSFT: Routes submission for review
14
    MSFT->>MSFT: Verify test results meet WHCP requirements
15
    MSFT->>MSFT: Review driver package integrity
16

17
    alt Tests Pass
18
        MSFT->>Sign: Approve driver for WHQL signing
19
        Sign->>Sign: Signs driver with Microsoft's WHQL certificate\n(contains WHQL EKU OID 1.3.6.1.4.1.311.10.3.5)
20
        Sign-->>Driver: Returns signed .sys + .inf + catalog file
21
        Driver-->>Vendor: Certified driver package available for download
22
        Note over Driver,Vendor: Driver is now WHQL-certified\nci.dll WHQL EKU check will pass
23
    else Tests Fail
24
        MSFT-->>Vendor: Rejection with failure details
25
        Vendor->>HLK: Fix driver issues, re-test
26
    end

The critical output of this process is a driver package where the .sys file (and associated catalog) carries a signature from Microsoft’s WHQL signing certificate — a certificate that includes the WHQL EKU OID. This is what WDAC’s WHQL level checks for.

4. How the WHQL Level Works Technically#

When ci.dll (the kernel’s Code Integrity component) evaluates a file against a WDAC policy containing WHQL rules, it performs the following checks:

Step 1: Is the file kernel-mode?#

WHQL rules are evaluated in the kernel-mode signing scenario. For user-mode binaries, different rule sets apply. The evaluation context is determined by how the binary is being loaded:

Kernel drivers loaded via IoLoadDriver → kernel-mode scenario
Executables and DLLs loaded via the process loader → user-mode scenario

Step 2: Does the certificate chain contain the WHQL EKU?#

ci.dll walks the certificate chain from the leaf certificate upward. At each level, it checks the Extended Key Usage extension for the presence of OID 1.3.6.1.4.1.311.10.3.5 (Windows Hardware Driver Verification).

The EKU can appear in:

The leaf certificate (most common for WHQL-signed drivers)
An intermediate CA certificate (for enterprise CA hierarchies, less common)

Step 3: Does the chain root in a trusted WHQL root?#

Microsoft uses two root CAs for WHQL signing:

Microsoft Product Root 2010 — for drivers signed after 2010
Microsoft Code Verification Root — for older drivers signed under the previous root

The chain must root in one of these Microsoft-operated roots. This prevents third-party CAs from issuing “WHQL-like” certificates.

Step 4: WDAC Policy Rule Match#

If a WHQL Signer rule exists in the policy and the above checks pass, the file is allowed. If no WHQL rule exists, the file evaluation continues to other applicable rules.

5. The WHQL EKU — OID and Hex Encoding#

The WHQL EKU has the following OID:

1
OID (dotted decimal): 1.3.6.1.4.1.311.10.3.5
2
OID meaning:         Microsoft → Products → OIDs → WHQL-related → Windows Hardware Driver Verification

In WDAC XML, EKUs are represented as hexadecimal DER-encoded OID values. The encoding process:

Start with the OID in dotted decimal: 1.3.6.1.4.1.311.10.3.5
Prepend the ASN.1 OID tag 06 (object identifier)
Encode the OID value per BER/DER OID encoding rules
Express as uppercase hex

The result:

1
DER-encoded WHQL EKU value: 010A2B0601040182370A0305

Breaking down the hex encoding:

01 — Length byte (context-dependent in WDAC’s encoding format)
0A — Length of the OID content (10 bytes)
2B — Encodes the first two OID components (1.3 → 40×1+3=43=0x2B)
06 01 04 01 82 37 0A 03 05 — Remaining OID components encoded per BER rules
- 06 = 6
- 01 = 1
- 04 = 4
- 01 = 1
- 82 37 = 311 (multi-byte encoding: 0x82=high byte flag, 0x37=55 → 311)
- 0A = 10
- 03 = 3
- 05 = 5

In WDAC XML, this appears as:

1
<EKU ID="ID_EKU_WHQL" Value="010A2B0601040182370A0305" />

6. Certificate Chain / Trust Anatomy#

1
graph TB
2
    subgraph "WHQL Certificate Chain"
3
        ROOT["Microsoft Product Root 2010\nOR\nMicrosoft Code Verification Root\n(Self-Signed, air-gapped HSM at Microsoft)"]:::root
4

5
        MSWHQL_CA["Microsoft Windows Hardware\nCompatibility PCA 2021\n(Intermediate CA — WHQL signing)"]:::pca
6

7
        LEAF["Microsoft Windows Hardware\nCompatibility Publisher\nEKU: 1.3.6.1.4.1.311.10.3.5\n(WHQL EKU present in leaf cert)"]:::pca
8

9
        DRIVER["nvlddmkm.sys\nNVIDIA Display Adapter Driver\nSigned by Microsoft's WHQL signing service\non behalf of NVIDIA's submission"]:::file
10

11
        subgraph "EKU Extension in Leaf Cert"
12
            EKU1["Code Signing (1.3.6.1.5.5.7.3.3)"]:::node
13
            EKU2["Windows Hardware Driver Verification\n(1.3.6.1.4.1.311.10.3.5) ← WHQL EKU"]:::allow
14
        end
15
    end
16

17
    ROOT --> MSWHQL_CA
18
    MSWHQL_CA --> LEAF
19
    LEAF --> DRIVER
20
    LEAF -.->|"contains"| EKU1
21
    LEAF -.->|"contains"| EKU2
22

23
    classDef root fill:#1a0d2e,stroke:#6b21a8,color:#d8b4fe
24
    classDef pca fill:#162032,stroke:#1e3a5f,color:#e2e8f0
25
    classDef leaf fill:#162032,stroke:#1e3a5f,color:#e2e8f0
26
    classDef file fill:#162032,stroke:#1e3a5f,color:#e2e8f0
27
    classDef allow fill:#0d1f12,stroke:#1a5c2a,color:#86efac
28
    classDef node fill:#162032,stroke:#1e3a5f,color:#e2e8f0

Important note on WHQL signing mechanics: Unlike standard Authenticode where the vendor signs their own binary with their own private key, WHQL-signed drivers are signed by Microsoft’s private key (on behalf of the vendor’s submission). The vendor submits the driver to Microsoft’s portal, and Microsoft signs it. This is why WHQL certs chain to Microsoft roots, not to vendor roots.

7. Where in the Evaluation Stack#

1
flowchart TD
2
    START(["Kernel Driver Load Requested\n(e.g., nvlddmkm.sys)"]):::node
3

4
    SCENARIO{"Kernel-mode or\nUser-mode context?"}:::node
5
    USER_PATH["User-mode rule evaluation\n(different rule set applies)"]:::node
6

7
    HASH_CHECK{"Hash rule\nexists for this .sys file?"}:::node
8
    HASH_ALLOW(["ALLOW — Hash match\n(most specific)"]):::allow
9

10
    FP_CHECK{"FilePublisher/WHQLFilePublisher rule\nexists? (EKU + CN + filename + version)"}:::node
11
    FP_ALLOW(["ALLOW — WHQLFilePublisher match"]):::allow
12

13
    PUB_CHECK{"Publisher/WHQLPublisher rule\nexists? (EKU + leaf CN)"}:::node
14
    PUB_ALLOW(["ALLOW — WHQLPublisher match"]):::allow
15

16
    WHQL_CHECK{"WHQL rule exists?\n(EKU OID 1.3.6.1.4.1.311.10.3.5\nin cert chain?)"}:::node
17
    WHQL_ALLOW(["ALLOW — WHQL EKU match\n(any WHQL-certified driver)"]):::allow
18

19
    PCA_CHECK{"PcaCertificate rule\nexists for signer chain?"}:::node
20
    PCA_ALLOW(["ALLOW — PcaCertificate match"]):::allow
21

22
    DEFAULT{"Default action?"}:::node
23
    BLOCK(["BLOCK — Kernel driver\nnot authorized"]):::block
24
    AUDIT(["AUDIT LOG — allowed in\naudit mode, blocked in enforce"]):::warn
25

26
    START --> SCENARIO
27
    SCENARIO -->|"Kernel-mode"| HASH_CHECK
28
    SCENARIO -->|"User-mode"| USER_PATH
29
    HASH_CHECK -->|"Yes"| HASH_ALLOW
30
    HASH_CHECK -->|"No"| FP_CHECK
31
    FP_CHECK -->|"Yes"| FP_ALLOW
32
    FP_CHECK -->|"No"| PUB_CHECK
33
    PUB_CHECK -->|"Yes"| PUB_ALLOW
34
    PUB_CHECK -->|"No"| WHQL_CHECK
35
    WHQL_CHECK -->|"Yes — EKU found in chain"| WHQL_ALLOW
36
    WHQL_CHECK -->|"No"| PCA_CHECK
37
    PCA_CHECK -->|"Yes"| PCA_ALLOW
38
    PCA_CHECK -->|"No"| DEFAULT
39
    DEFAULT -->|"DefaultDeny"| BLOCK
40
    DEFAULT -->|"Audit mode"| AUDIT
41

42
    classDef node fill:#162032,stroke:#1e3a5f,color:#e2e8f0
43
    classDef allow fill:#0d1f12,stroke:#1a5c2a,color:#86efac
44
    classDef block fill:#1f0d0d,stroke:#7f1d1d,color:#fca5a5
45
    classDef warn fill:#1a1a0d,stroke:#7a6a00,color:#fde68a

The WHQL level sits between WHQLPublisher/WHQLFilePublisher (more specific) and PcaCertificate (broader but different concept). More specific WHQL-based rules are checked first.

8. XML Representation#

A complete WHQL rule in App Control for Business XML consists of two parts:

An EKU element defining the WHQL OID
A Signer element referencing that EKU

Full XML Example#

1
<?xml version="1.0" encoding="utf-8"?>
2
<SiPolicy xmlns="urn:schemas-microsoft-com:sipolicy">
3

4
  <EKUs>
5
    <EKU ID="ID_EKU_WHQL" Value="010A2B0601040182370A0305" />
6
  </EKUs>
7

8
  <Signers>
9
    <!--
10
      WHQL Signer: Trusts any file whose cert chain:
11
      1. Contains the WHQL EKU (defined above)
12
      2. Chains to Microsoft's WHQL root
13
      This does NOT restrict to a specific vendor — any WHQL-certified driver matches.
14
    -->
15
    <Signer ID="ID_SIGNER_WHQL_KERNEL" Name="Windows Hardware Quality Lab (WHQL) - Kernel Mode">
16
      <CertRoot Type="TBS" Value="3085A90B03EE71B6B33F5EA8A07DBBD40B5B7A89" />
17
      <CertEKU ID="ID_EKU_WHQL" />
18
    </Signer>
19
  </Signers>
20

21
  <SigningScenarios>
22
    <SigningScenario Value="131" ID="ID_SIGNINGSCENARIO_DRIVERS" FriendlyName="Driver Signing Scenario">
23
      <ProductSigners>
24
        <AllowedSigner SignerID="ID_SIGNER_WHQL_KERNEL" />
25
      </ProductSigners>
26
    </SigningScenario>
27
  </SigningScenarios>
28

29
  <Rules>
30
    <Rule>
31
      <Option>Enabled:Unsigned System Integrity Policy</Option>
32
    </Rule>
33
  </Rules>
34

35
</SiPolicy>

Signing Scenario Values#

Value	Scenario	Applies To
`131`	Kernel Mode	Drivers, kernel components
`12`	User Mode	Executables, DLLs

WHQL rules are almost always placed in the kernel-mode signing scenario (131).

9. PowerShell Examples#

Generating a WHQL Policy#

1
# Generate a policy that allows all WHQL-certified kernel drivers
2
# New-CIPolicy with Level WHQL creates WHQL EKU-based Signer rules
3
New-CIPolicy `
4
    -ScanPath "C:\Windows\System32\drivers\" `
5
    -Level WHQL `
6
    -Fallback Hash `       # For any drivers that are NOT WHQL-signed
7
    -FilePath "C:\Policies\WHQL-Drivers-Policy.xml" `
8
    -Drivers               # Only scan drivers (kernel mode)
9

10
# Output: EKU element for WHQL OID + Signer elements for WHQL intermediate CAs
11
# Plus Hash rules for any non-WHQL-signed drivers found during scan

Checking If a Driver Is WHQL-Signed#

1
function Test-WHQLSigned {
2
    param([string]$DriverPath)
3

4
    # The WHQL EKU OID
5
    $whqlOid = "1.3.6.1.4.1.311.10.3.5"
6

7
    $sig = Get-AuthenticodeSignature -FilePath $DriverPath
8
    if ($sig.Status -ne "Valid") {
9
        Write-Warning "File is not validly signed: $DriverPath"
10
        return $false
11
    }
12

13
    $chain = New-Object System.Security.Cryptography.X509Certificates.X509Chain
14
    $chain.Build($sig.SignerCertificate) | Out-Null
15

16
    foreach ($element in $chain.ChainElements) {
17
        $cert = $element.Certificate
18
        foreach ($ext in $cert.Extensions) {
19
            if ($ext -is [System.Security.Cryptography.X509Certificates.X509EnhancedKeyUsageExtension]) {
20
                foreach ($oid in $ext.EnhancedKeyUsages) {
21
                    if ($oid.Value -eq $whqlOid) {
22
                        Write-Host "WHQL-signed: $DriverPath" -ForegroundColor Green
23
                        Write-Host "  WHQL EKU found in cert: $($cert.Subject)" -ForegroundColor Green
24
                        return $true
25
                    }
26
                }
27
            }
28
        }
29
    }
30

31
    Write-Host "Not WHQL-signed: $DriverPath" -ForegroundColor Yellow
32
    return $false
33
}
34

35
# Test a specific driver
36
Test-WHQLSigned -DriverPath "C:\Windows\System32\drivers\nvlddmkm.sys"

Scanning System32\drivers for WHQL Status#

1
# Audit all drivers on the system — identify which are WHQL-signed
2
$whqlOid = "1.3.6.1.4.1.311.10.3.5"
3

4
Get-ChildItem "C:\Windows\System32\drivers\*.sys" | ForEach-Object {
5
    $driver = $_
6
    $sig = Get-AuthenticodeSignature -FilePath $driver.FullName -ErrorAction SilentlyContinue
7

8
    if ($sig -and $sig.Status -eq "Valid") {
9
        $chain = New-Object System.Security.Cryptography.X509Certificates.X509Chain
10
        $chain.Build($sig.SignerCertificate) | Out-Null
11

12
        $isWhql = $false
13
        foreach ($el in $chain.ChainElements) {
14
            foreach ($ext in $el.Certificate.Extensions) {
15
                if ($ext -is [System.Security.Cryptography.X509Certificates.X509EnhancedKeyUsageExtension]) {
16
                    if ($ext.EnhancedKeyUsages | Where-Object { $_.Value -eq $whqlOid }) {
17
                        $isWhql = $true
18
                    }
19
                }
20
            }
21
        }
22

23
        [PSCustomObject]@{
24
            Driver    = $driver.Name
25
            Signer    = $sig.SignerCertificate.Subject -replace "CN=",""
26
            WHQLSigned = $isWhql
27
            Status    = $sig.Status
28
        }
29
    }
30
} | Sort-Object WHQLSigned, Driver | Format-Table -AutoSize

Creating a Combined WHQL + Recommended Block Rules Policy#

1
# Microsoft-recommended approach: allow WHQL drivers BUT apply the vulnerable driver block rules
2

3
# Step 1: Generate base WHQL policy
4
New-CIPolicy `
5
    -Level WHQL `
6
    -Fallback Hash `
7
    -FilePath "C:\Policies\WHQL-Base.xml" `
8
    -Drivers
9

10
# Step 2: Download Microsoft's recommended block rules (driver blocklist)
11
# Source: https://aka.ms/VulnerableDriverBlockList
12
# These block known vulnerable drivers that ARE WHQL-signed but have CVEs
13
Invoke-WebRequest `
14
    -Uri "https://aka.ms/VulnerableDriverBlockList" `
15
    -OutFile "C:\Policies\VulnerableDriverBlockList.xml"
16

17
# Step 3: Merge base policy with block rules
18
Merge-CIPolicy `
19
    -PolicyPaths "C:\Policies\WHQL-Base.xml", "C:\Policies\VulnerableDriverBlockList.xml" `
20
    -OutputFilePath "C:\Policies\WHQL-WithBlockList.xml"
21

22
# Step 4: Compile to binary
23
ConvertFrom-CIPolicy `
24
    -XmlFilePath "C:\Policies\WHQL-WithBlockList.xml" `
25
    -BinaryFilePath "C:\Policies\WHQL-WithBlockList.p7b"

10. WHQL vs. Option 02 (Required)#

This is one of the most common sources of confusion regarding WHQL in WDAC. These are two completely different concepts:

Concept	What It Is	Effect
WHQL level (file rule level)	A trust grant — “allow files that are WHQL-signed”	Files with WHQL EKU are allowed to run
Option 02: Required	A policy mandate — “all kernel drivers MUST be WHQL”	Drivers without WHQL EKU are BLOCKED, regardless of other rules

Option 02 Explained#

Adding <Option>Required:WHQL</Option> to a WDAC policy’s <Rules> section activates a global kernel-mode policy that requires every kernel driver to be WHQL-certified. This is enforced by ci.dll before any signer rules are evaluated:

1
<Rules>
2
  <Rule>
3
    <Option>Required:WHQL</Option>
4
  </Rule>
5
</Rules>

When you combine both:

1
graph TD
2
    DRIVER_LOAD(["Kernel Driver Load Request"]):::node
3

4
    OPT02{"Option 02\nRequired:WHQL\nin policy?"}:::node
5

6
    WHQL_CHECK_OPT{"Does driver have\nWHQL EKU?"}:::node
7
    OPT02_BLOCK(["BLOCKED — Option 02 mandate\ndriver lacks WHQL EKU\nNo signer rules evaluated"]):::block
8

9
    RULE_EVAL["Evaluate WDAC Signer Rules\n(WHQL level, Publisher, Hash, etc.)"]:::node
10

11
    WHQL_RULE{"WHQL signer rule\nexists AND EKU present?"}:::node
12
    WHQL_RULE_ALLOW(["ALLOWED — WHQL rule matches"]):::allow
13

14
    OTHER_RULE{"Other signer rules\nmatch?"}:::node
15
    OTHER_ALLOW(["ALLOWED — Other rule matches"]):::allow
16

17
    DEFAULT_BLOCK(["BLOCKED — Default deny"]):::block
18

19
    DRIVER_LOAD --> OPT02
20
    OPT02 -->|"Yes — Option 02 active"| WHQL_CHECK_OPT
21
    OPT02 -->|"No — Option 02 absent"| RULE_EVAL
22
    WHQL_CHECK_OPT -->|"No WHQL EKU"| OPT02_BLOCK
23
    WHQL_CHECK_OPT -->|"Has WHQL EKU"| RULE_EVAL
24
    RULE_EVAL --> WHQL_RULE
25
    WHQL_RULE -->|"Yes"| WHQL_RULE_ALLOW
26
    WHQL_RULE -->|"No"| OTHER_RULE
27
    OTHER_RULE -->|"Yes"| OTHER_ALLOW
28
    OTHER_RULE -->|"No"| DEFAULT_BLOCK
29

30
    classDef node fill:#162032,stroke:#1e3a5f,color:#e2e8f0
31
    classDef allow fill:#0d1f12,stroke:#1a5c2a,color:#86efac
32
    classDef block fill:#1f0d0d,stroke:#7f1d1d,color:#fca5a5
33
    classDef warn fill:#1a1a0d,stroke:#7a6a00,color:#fde68a

Practical guidance:

Use WHQL level when you want to allow WHQL-certified drivers as a category
Use Option 02 when you want to mandate that all drivers must be WHQL (and block non-WHQL drivers even if they have other valid signatures)
For maximum security, use both: Option 02 mandates WHQL, and WHQL level rules allow them

11. Pros & Cons Table#

Attribute	Assessment
Trust scope	All WHQL-certified drivers — broad but bounded by Microsoft’s certification process
Maintenance burden	Very low — new WHQL drivers automatically match existing rules
Security validation	High — Microsoft tested and signed each driver through HLK
False positive risk	Low for kernel mode; WHQL is specific to hardware drivers
BYOVD vulnerability	Present — legitimate old WHQL drivers with CVEs still match
Specificity	Low — cannot distinguish NVIDIA driver from Intel driver at this level
Ease of use	High — single EKU rule covers all certified drivers
User-mode applicability	Limited — few user-mode binaries are WHQL-signed
Compatibility	Excellent — works on all WDAC-capable Windows versions
Kernel stability	High — WHQL drivers have passed quality testing

12. Attack Resistance Analysis — BYOVD Context#

Bring Your Own Vulnerable Driver (BYOVD)#

The WHQL level’s most significant limitation is its vulnerability to BYOVD attacks. In a BYOVD attack, a threat actor loads a legitimately-signed, WHQL-certified driver that contains a known vulnerability (typically a kernel read/write primitive) and exploits it to escalate privileges or disable security software.

The key insight: WHQL certification tests whether a driver works correctly for its intended purpose on certified hardware. It does NOT:

Test for security vulnerabilities in the driver code
Expire or invalidate a signature when a CVE is discovered
Prevent old, vulnerable drivers from matching WDAC WHQL rules

1
graph TD
2
    subgraph "BYOVD Attack Chain"
3
        ATK1["Attacker runs with admin privileges\n(e.g., post-initial-access)"]:::warn
4

5
        ATK2["Downloads vulnerable WHQL driver:\nkevp64.sys (Gigabyte driver, CVE-XXXX)\ndbutil_2_3.sys (Dell driver, CVE-2021-21551)\nnvflash.sys (NVIDIA tool, has kernel R/W)"]:::warn
6

7
        ATK3["Loads driver via sc.exe or\nLoadDriver privilege"]:::warn
8

9
        WDAC_CHECK{"WDAC WHQL check"}:::node
10

11
        WHQL_PASS(["ALLOWED — Driver IS WHQL-signed\nWDAC WHQL rule matches\nDriver loads successfully"]):::block
12

13
        ATK4["Exploits kernel vulnerability\nin loaded driver\n(arbitrary kernel R/W, process token\nmanipulation, PPL bypass, etc.)"]:::block
14

15
        ATK5["Disables EDR/AV,\nescalates to SYSTEM,\nor installs kernel rootkit"]:::block
16
    end
17

18
    subgraph "Mitigation: Microsoft Vulnerable Driver Blocklist"
19
        BLOCK_LIST["Microsoft-maintained deny list:\n/windows/security/application-security/\napplication-control/windows-defender-\napplication-control/design/\nrecommended-driver-block-rules"]:::allow
20

21
        BLOCK_CHECK{"Driver hash/signer\nin block list?"}:::node
22

23
        BLOCKED(["BLOCKED — Even though WHQL-signed\nDeny rule takes precedence\nover WHQL allow rule"]):::allow
24
    end
25

26
    ATK1 --> ATK2
27
    ATK2 --> ATK3
28
    ATK3 --> WDAC_CHECK
29
    WDAC_CHECK -->|"WHQL rule exists, EKU found"| WHQL_PASS
30
    WHQL_PASS --> ATK4
31
    ATK4 --> ATK5
32

33
    ATK3 -.->|"With block list enabled"| BLOCK_CHECK
34
    BLOCK_CHECK -->|"Yes — in block list"| BLOCKED
35

36
    classDef node fill:#162032,stroke:#1e3a5f,color:#e2e8f0
37
    classDef allow fill:#0d1f12,stroke:#1a5c2a,color:#86efac
38
    classDef block fill:#1f0d0d,stroke:#7f1d1d,color:#fca5a5
39
    classDef warn fill:#1a1a0d,stroke:#7a6a00,color:#fde68a

Mitigating BYOVD When Using WHQL Level#

The WHQL level should always be combined with Microsoft’s recommended driver block rules (the vulnerable driver blocklist). This list contains hashes and signer rules for known-vulnerable WHQL-certified drivers. Since deny rules take precedence over allow rules in WDAC, drivers on the block list are blocked even if they would otherwise match the WHQL allow rule.

Key point: WHQL level alone is insufficient for BYOVD protection. Always combine with:

Microsoft’s vulnerable driver block rules (updated regularly)
WHQLFilePublisher level rules for specific known-good drivers (more restrictive)
Required:WHQL option (Option 02) to block unsigned kernel drivers

13. When to Use vs. When to Avoid — Decision Flowchart#

1
flowchart TD
2
    Q1["Goal: Control which kernel drivers\ncan load on my systems"]:::node
3

4
    Q2{"Do you need to control\nwhich VENDORS' drivers run?"}:::node
5

6
    Q3{"Are ALL drivers from a\nsingle known set of vendors?"}:::node
7

8
    USE_WHQL(["Consider WHQL level\n+ Microsoft block rules\n+ Option 02 (Required:WHQL)\nBest for: broad enterprise\ndriver allowlisting where\nyou trust all WHQL-certified vendors"]):::allow
9

10
    USE_WHQL_PUB(["Use WHQLPublisher level\nTrust WHQL drivers from\nspecific vendors only\nBest for: OEM-specific\ndriver allowlisting"]):::allow
11

12
    USE_WHQL_FP(["Use WHQLFilePublisher level\nTrust specific WHQL drivers\nby filename + version + vendor\nBest for: production policy\nwith known driver inventory"]):::allow
13

14
    Q4{"Security requirement\nlevel?"}:::node
15

16
    HIGH_SEC(["High security environment\n→ WHQLFilePublisher preferred\n→ Enumerate specific drivers\n→ Add Microsoft block rules\n→ Enable Option 02"]):::warn
17

18
    STD_SEC(["Standard enterprise\n→ WHQL level is acceptable\n→ Must add Microsoft block rules\n→ Recommended: enable Option 02\n→ Monitor for CVE advisories"]):::allow
19

20
    Q1 --> Q2
21
    Q2 -->|"Any WHQL vendor is fine"| Q4
22
    Q2 -->|"Specific vendors only"| Q3
23
    Q3 -->|"Yes, one or few vendors"| USE_WHQL_PUB
24
    Q3 -->|"Specific files known"| USE_WHQL_FP
25
    Q4 -->|"High security / strict"| HIGH_SEC
26
    Q4 -->|"Standard enterprise"| STD_SEC
27
    STD_SEC --> USE_WHQL
28
    HIGH_SEC --> USE_WHQL_FP
29

30
    classDef node fill:#162032,stroke:#1e3a5f,color:#e2e8f0
31
    classDef allow fill:#0d1f12,stroke:#1a5c2a,color:#86efac
32
    classDef block fill:#1f0d0d,stroke:#7f1d1d,color:#fca5a5
33
    classDef warn fill:#1a1a0d,stroke:#7a6a00,color:#fde68a

14. Real-World Scenario: End-to-End Sequence#

Scenario: A manufacturing company deploys WDAC to their workstations. They have various hardware with drivers from Intel, NVIDIA, Realtek, and other vendors. They want to allow all properly-certified drivers without enumerating each vendor.

1
sequenceDiagram
2
    participant Admin as IT Admin
3
    participant PS as PowerShell (ConfigCI)
4
    participant MSBlock as Microsoft Block Rules Feed
5
    participant MDM as Intune/MDM
6
    participant WS as Workstation (ci.dll)
7
    participant Driver as Vendor Driver (nvlddmkm.sys)
8

9
    Note over Admin,Driver: Phase 1 — Policy Creation
10

11
    Admin->>PS: New-CIPolicy -Level WHQL -Fallback Hash -Drivers -FilePath base.xml
12
    PS-->>Admin: base.xml — contains WHQL EKU rule + Hash rules for any non-WHQL drivers
13

14
    Admin->>MSBlock: Download recommended driver block rules (aka.ms/VulnerableDriverBlockList)
15
    MSBlock-->>Admin: blocklist.xml — deny rules for known-vulnerable WHQL drivers
16

17
    Admin->>PS: Merge-CIPolicy -PolicyPaths base.xml, blocklist.xml -OutputFilePath merged.xml
18
    Admin->>PS: Add Option 02 (Required:WHQL) to merged.xml
19
    Admin->>PS: ConvertFrom-CIPolicy -XmlFilePath merged.xml -BinaryFilePath policy.p7b
20

21
    Note over Admin,Driver: Phase 2 — Deployment
22

23
    Admin->>MDM: Upload policy.p7b, deploy via OMA-URI to workstations
24
    MDM-->>WS: Policy deployed and activated
25

26
    Note over Admin,Driver: Phase 3 — Normal Operation (WHQL driver allowed)
27

28
    Driver->>WS: NVIDIA driver update: nvlddmkm.sys v560.94 loads
29
    WS->>WS: ci.dll — kernel mode evaluation
30
    WS->>WS: Check Option 02: nvlddmkm.sys has WHQL EKU? Yes → proceed
31
    WS->>WS: Evaluate WHQL signer rule: EKU OID 1.3.6.1.4.1.311.10.3.5 found in chain? Yes
32
    WS->>WS: Check Microsoft block list: v560.94 hash in deny list? No
33
    WS-->>Driver: ALLOWED — WHQL-certified, not on block list
34

35
    Note over Admin,Driver: Phase 4 — BYOVD Attempt (blocked by deny list)
36

37
    Driver->>WS: Attacker tries to load kevp64.sys (Gigabyte, known vulnerable, WHQL-signed)
38
    WS->>WS: ci.dll — kernel mode evaluation
39
    WS->>WS: Check Option 02: kevp64.sys has WHQL EKU? Yes → proceed to rules
40
    WS->>WS: Check Microsoft block list: kevp64.sys hash in deny list? YES
41
    WS-->>Driver: BLOCKED — Deny rule (block list) takes precedence over WHQL allow rule
42
    WS->>WS: Event ID 3077 logged (CI block event)

15. OS Version & Compatibility#

OS Version	WHQL Level Support	Notes
Windows 10 1507+	Full support	WDAC kernel-mode signing scenarios
Windows 10 1709+	Full support + Audit Mode	Separate audit/enforce policy support
Windows 11 21H2+	Full support	Enhanced kernel security, HVCI
Windows Server 2016+	Full support	Server supports WDAC kernel driver control
Windows Server 2019+	Full support	Recommended for server deployments
Windows Server 2022+	Full support	Strong WDAC integration with Secured-Core
ARM64	Full support	WHQL covers ARM64 drivers as well

Note on HVCI (Hypervisor-Protected Code Integrity): When HVCI (Memory Integrity) is enabled, kernel driver loading is validated by the hypervisor using WDAC policies. WHQL rules work identically in HVCI mode. The additional protection HVCI provides is that even if ci.dll were compromised, the hypervisor enforces the policy independently.

16. Common Mistakes & Gotchas#

Mistake 1: Believing WHQL Means the Driver Is Secure#

Wrong assumption: “WHQL drivers are Microsoft-approved, so they’re safe to run.”

Reality: WHQL certification tests hardware compatibility and quality, not security. A driver can be WHQL-certified and still contain exploitable vulnerabilities (as demonstrated by dozens of CVEs in WHQL-signed drivers). Always combine WHQL rules with Microsoft’s vulnerable driver block list.

Mistake 2: Forgetting the Fallback#

Wrong approach: Using WHQL level without a fallback for legacy or internal drivers that are not WHQL-certified.

Reality: Many legitimate enterprise drivers (especially legacy hardware or internal development drivers) are not WHQL-signed. Without a fallback (-Fallback Hash or -Fallback Publisher), these drivers will be blocked.

Fix: Always specify -Fallback Hash or another appropriate fallback level when generating WHQL policies.

Mistake 3: Confusing WHQL Level with Option 02#

As described in Section 10, these are different. Confusing them leads to policies that either:

Allow non-WHQL drivers when you intended to block them (forgot Option 02)
Block valid driver loads that only have PcaCertificate rules (added Option 02 without WHQL allow rules)

Mistake 4: Not Updating the Block List#

Wrong assumption: “Once I add the Microsoft block list to my policy, I’m protected forever.”

Reality: New vulnerable WHQL-signed drivers are discovered regularly. Microsoft updates the block list. Your deployed policy does not auto-update. Schedule regular policy reviews to incorporate updated block rules.

Mistake 5: Applying WHQL Rules to User-Mode Scenario#

WHQL rules are meaningful only in the kernel-mode signing scenario (value 131). Adding WHQL EKU rules to user-mode scenario (value 12) rules has no meaningful effect because user-mode binaries are almost never WHQL-signed. If you see WHQL rules in a user-mode policy section, they are likely the result of an overly broad scan and can be removed.

Mistake 6: The EKU Hex Value Encoding#

The WHQL EKU value in WDAC XML (010A2B0601040182370A0305) is not the raw OID in hex. It is a specific encoding format used by WDAC. Using the wrong encoding (e.g., raw ASN.1 OID bytes without the WDAC-specific prefix) will cause the EKU rule to never match, silently failing to allow WHQL drivers.

Always use the canonical value 010A2B0601040182370A0305 for the WHQL EKU in WDAC XML.

17. Summary Table#

Property	Value
Level Name	WHQL
Trust Mechanism	EKU OID `1.3.6.1.4.1.311.10.3.5` in cert chain
EKU Hex (WDAC XML)	`010A2B0601040182370A0305`
Primary Use Case	Kernel-mode driver allowlisting
Trust Scope	All Microsoft-certified WHQL drivers
Vendor Specificity	None — any WHQL driver from any vendor matches
BYOVD Risk	Present — old vulnerable WHQL drivers still match
BYOVD Mitigation	Microsoft vulnerable driver block rules
Related Option	Option 02 `Required:WHQL` (mandate, not grant)
More Specific Alternatives	WHQLPublisher (adds vendor CN), WHQLFilePublisher (adds filename+version)
Signing Scenario	Kernel mode (131) — rarely user mode (12)
PowerShell Level Name	`WHQL`
Kernel Component	ci.dll (Code Integrity)
OS Support	Windows 10 1507+ / Server 2016+
HVCI Compatible	Yes — evaluated by hypervisor in HVCI mode
Block List URL	`https://aka.ms/VulnerableDriverBlockList`