Skip to Content

Checking a single device for cross-signed driver blocks

7 October 2026 by
Ben Cole
| No comments yet

Why this script

The Windows Driver Policy, which removes default trust for kernel drivers signed under the legacy cross-signed program, isn't new to 26H2. It shipped in the April 2026 update for Windows 11 24H2, 25H2 and 26H1, and 26H2 is the first feature update with it built in. On every version it starts in evaluation mode and enforces per device once that device clocks enough uptime and reboots without a violation, so devices moving to 26H2 will enforce in the same way.

Devices in evaluation mode log every driver that would fail the new kernel trust policy, but nothing tells the user. The first sign is usually hardware that stops working once the device enforces. Lab PCs, shop-floor machines and anything with occasionally used kit are most at risk.

This script reads that evidence straight from the device's CodeIntegrity Operational log. It finds event 3076 (driver audited, would be blocked) and 3077 (driver blocked), filtered to the two Windows Driver Policy GUIDs so other App Control policies don't add noise. Anything it finds goes to a CSV you can hand to the customer or the hardware vendor.


How to use it

  1. Use every piece of hardware on the device first: connect it, open its software, do a real task. A driver is only evaluated when it loads.
  2. Copy Get-DriverPolicyStatus.ps1 to a local folder on the device.
  3. Open PowerShell as administrator and run:
powershell.exe -ExecutionPolicy Bypass -File .\Get-DriverPolicyStatus.ps1

If events are found, the script exports DriverPolicy_<computername>.csv to the folder it was run from. If not, it reports No audit or block events found in green.

The script

# Finds Windows Driver Policy audit (3076) and block (3077) events and exports them to CSV.
# Run as administrator. The CSV is saved in the folder the script is run from.

$folder = if ($PSScriptRoot) { $PSScriptRoot } else { (Get-Location).Path }
$csv    = Join-Path $folder "DriverPolicy_$env:COMPUTERNAME.csv"
$guids  = '784C4414-79F4-4C32-A6A5-F0FB42A51D0D|8F9CB695-5D48-48D6-A329-7202B44607E3'

$results = Get-WinEvent -LogName 'Microsoft-Windows-CodeIntegrity/Operational' -FilterXPath '*[System[(EventID=3076 or EventID=3077)]]' -ErrorAction SilentlyContinue |
    Where-Object { $_.Message -match $guids } |
    ForEach-Object {
        $d = ([xml]$_.ToXml()).Event.EventData.Data
        [pscustomobject]@{
            Time    = $_.TimeCreated
            Result  = if ($_.Id -eq 3077) { 'Blocked' } else { 'Audited' }
            Driver  = ($d | Where-Object Name -eq 'File Name').'#text'
            Product = ($d | Where-Object Name -eq 'ProductName').'#text'
            Process = ($d | Where-Object Name -eq 'Process Name').'#text'
        }
    }

if ($results) {
    $results | Export-Csv -Path $csv -NoTypeInformation
    "Found $(@($results).Count) event(s). Exported to $csv"
}
else {
    Write-Host 'No audit or block events found.' -ForegroundColor Green
}

Reading the results

  • Audited: the driver will be blocked once the device leaves evaluation mode. Ask the vendor for a WHCP-signed version now. Or don't upgrade to 26H2
  • Blocked: the device is already enforcing and the hardware is likely broken. Treat as urgent.
  • Nothing found: clean only for hardware that was actually used before the run, and only if the device has the April 2026 update or later.

The CodeIntegrity log is small and rolls over, so run the script soon after the hardware has been used. Microsoft's Windows Driver Policy page has the full evaluation criteria and the event reference.

What if we cant update the driver and must move to 26H2

Another way to fix it for a machine is to disable the policy entirely, but this is likely a last resort. 

You cant turn it off on a per driver basis it is all or nothing. 

CiTool.exe --remove-policy"{8F9CB695-5D48-48D6-A329-7202B44607E3}"

For organisations with their own internal kernel drivers, Microsoft points to App Control for Business, which can approve privately signed drivers through policies tied to Secure Boot trust anchors such as the Platform Key or Key Exchange Key. That's heavy lifting and not really aimed at third-party lab kit.

Ben Cole 7 October 2026
Share this post
Archive
Sign in to leave a comment
Finding cross-signed driver activity with Advanced Hunting in Defender For Endpoint