The Windows Driver Policy

If a driver is blocked by this policy, you may see:

• A hardware device is not functioning correctly.

• A peripheral or component (printer, network adapter, GPU, etc.) is not recognized.

• An application that depends on a kernel driver fails to start.

You can confirm whether the Windows Driver policy is responsible by checking the Code Integrity event logs using the following two methods.

Query Code Integrity events Manually    

1. Right click the Start button and select Event Viewer .

2. In the left pane, navigate to: Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational

3. Look, or filter the log, for events with these IDs:

• Event ID 3076 — A driver was audited (would have been blocked but was allowed because the policy is in audit mode).

• Event ID 3077 — A driver was blocked from loading because it violated the enforcement policy.

In the event details, look for the Policy ID field. Events caused by this feature will reference one of the following Policy GUIDs:

• Audit policy : {784C4414-79F4-4C32-A6A5-F0FB42A51D0D}

• Enforce policy : {8F9CB695-5D48-48D6-A329-7202B44607E3}

Query Code Integrity events with PowerShell

You can use PowerShell to quickly find events related to this feature:

# Find audit events (Event ID 3076) from the Windows Driver audit policy

$events = Get-WinEvent -LogName 'Microsoft-Windows-CodeIntegrity/Operational' -FilterXPath "*[System[EventID=3076]]" -ErrorAction SilentlyContinue |

Where-Object { $_.Message -like '*784C4414-79F4-4C32-A6A5-F0FB42A51D0D*' }

$results = $events | ForEach-Object {

$xml = [xml]$_.ToXml()

$data = $xml.Event.EventData.Data

[PSCustomObject]@{

TimeCreated = $_.TimeCreated

DriverName    = ($data | Where-Object { $_.Name -eq 'File Name' }).'#text'

ProductName = ($data | Where-Object { $_.Name -eq 'ProductName' }).'#text'

ParentProcess = ($data | Where-Object { $_.Name -eq 'Process Name' }).'#text'

}

}

$results | Select-Object DriverName, ProductName, ParentProcess -Unique | Format-Table -AutoSize -Wrap

# Find block events (Event ID 3077) from the Windows Driver enforced policy

$events = Get-WinEvent -LogName 'Microsoft-Windows-CodeIntegrity/Operational' -FilterXPath "*[System[EventID=3077]]" -ErrorAction SilentlyContinue |

Where-Object { $_.Message -like '*8F9CB695-5D48-48D6-A329-7202B44607E3*' }

$results = $events | ForEach-Object {

$xml = [xml]$_.ToXml()

$data = $xml.Event.EventData.Data

[PSCustomObject]@{

TimeCreated = $_.TimeCreated

DriverName    = ($data | Where-Object { $_.Name -eq 'File Name' }).'#text'

ProductName = ($data | Where-Object { $_.Name -eq 'ProductName' }).'#text'

ParentProcess = ($data | Where-Object { $_.Name -eq 'Process Name' }).'#text'

}

}

$results | Select-Object DriverName, ProductName, ParentProcess -Unique | Format-Table -AutoSize -Wrap

The event details will include the name of the driver that was audited or blocked and the name of the process that tried to load the driver, which can help you identify which driver or device is affected.

If you are the device user or IT administrator

1. Check the event logs using the steps above to identify which driver is being blocked.

2. Check Windows Update for updated drivers. WHCP-certified, signed drivers may already be available through Windows Update. Go to Settings > Windows Update > Advanced options > Optional updates > Driver updates to check for available driver updates.

3. Visit the manufacturer's website . Download the latest driver version from the vendor's official support page — newer versions are more likely to be WHCP-signed.

4. Contact the hardware or software vendor that publishes the driver. Ask them whether a WHCP-certified version of the driver is available and where to access it. Most vendors already WHCP certify their drivers.

If you are a driver publisher

If you develop and distribute kernel-mode drivers for Windows, you must ensure your drivers are signed through the WHCP process:

1. Join the Windows Hardware Dev Center . Register at Windows Hardware Dev Center with a valid EV (Extended Validation) code signing certificate.

2. Create a submission . In the Hardware Dashboard, create a new product and submit your driver package for certification.

3. Run the HLK tests . Use the Windows Hardware Lab Kit (HLK) to run the required tests for your driver type and device category.

4. Submit for signing . After tests pass, submit your HLK results along with the driver package. Microsoft will sign the driver with the WHCP certificate.

5. Distribute the signed driver . Once signed, publish the WHCP-certified driver through Windows Update and/or your website.

The Windows Driver policy is a signed Code Integrity policy stored on the EFI System Partition and protected by Windows early boot components. Turning off the feature requires the following manual steps so malicious software running as admin cannot tamper with the feature:

Step 1: Disable Secure Boot

1. Restart your computer and enter the UEFI firmware settings menu (BIOS). You can typically do this by pressing a key during boot (such as F2 , F10 , Del , or Esc — check your device manufacturer's documentation)

   1. Alternatively, in Windows: go to Settings > System > Recovery > Advanced startup > Restart now . Then choose Troubleshoot > Advanced options > UEFI Firmware Settings > Restart .

2. In your firmware settings, locate the Secure Boot option (usually under the Security or Boot tab).

3. Set Secure Boot to Disabled .

4. Save changes and exit the firmware settings.

Step 2: Delete the policy files from the EFI System Partition

1.   Open PowerShell as an administrator .

2.   Mount the EFI System Partition by running:

mountvol S: /s

You can use any available drive letter in place of `S:`.

3.   Delete the audit policy file:

del S:\EFI\Microsoft\Boot\CiPolicies\Active\{784C4414-79F4-4C32-A6A5-F0FB42A51D0D}.cip

4.    If the enforcement policy is also present, delete it:

del S:\EFI\Microsoft\Boot\CiPolicies\Active\{8F9CB695-5D48-48D6-A329-7202B44607E3}.cip

5.   Also check for and delete the policies from the Windows system directory:

del %windir%\System32\CodeIntegrity\CiPolicies\Active\{784C4414-79F4-4C32-A6A5-F0FB42A51D0D}.cip

del %windir%\System32\CodeIntegrity\CiPolicies\Active\{8F9CB695-5D48-48D6-A329-7202B44607E3}.cip

6.    Unmount the EFI partition:

mountvol S: /d

Step 3: Restart your computer

Restart your device for the changes to take effect. After restart, the policy will no longer be active and all signed drivers — including those without WHCP certification — will be allowed to load.

Step 4: Re-enable Secure Boot

After removing the policy files, re-enable Secure Boot in your UEFI firmware settings to maintain other Secure Boot protections.

The feature starts in evaluation mode , where it logs but does not block uncertified drivers. After your system meets the evaluation criteria (sufficient uptime and reboots with no policy violations), the policy automatically transitions to enforcement mode , and drivers that are not WHCP-signed will be blocked. This can cause drivers that were working previously to stop loading.

There is currently no way to bypass the policy for individual drivers. You can either disable the feature entirely (see above) or — preferably — contact the driver publisher and ask them to provide a WHCP-signed version of their driver.

This feature applies to kernel-mode drivers only . User-mode applications are not affected by this policy.

You can check by running the following commands as an admin in PowerShell:

$evalPolicy = (citool -lp -json | ConvertFrom-Json).Policies | Where-Object { $_.PolicyID -eq "784c4414-79f4-4c32-a6a5-f0fb42a51d0d" }

$enforcedPolicy = (citool -lp -json | ConvertFrom-Json).Policies | Where-Object { $_.PolicyID -eq "8F9CB695-5D48-48D6-A329-7202B44607E3" }

if ($enforcedPolicy.IsEnforced -and $enforcedPolicy.IsAuthorized) { Write-Host "✅ The feature is in enforcement mode" -ForegroundColor Green }

elseif($evalPolicy.IsEnforced -and $evalPolicy.IsAuthorized) { Write-Host "✅ The feature is in evaluation mode" -ForegroundColor Green }

else { Write-Host "❌ The feature is not available on this system" -ForegroundColor Red }

Yes - Windows Server 2025 and newer server platforms. However, on Windows Server, the boot session requirement is 2 reboots (compared to 3 on client editions). All other criteria are the same.

If you reset or reinstall Windows, the feature will start fresh in evaluation mode. The evaluation counters will be reset and the transition to enforcement will begin again from the start.