Windows Driver Policy: Cross-Signed Kernel Drivers Are No Longer Trusted — Find Yours Before Enforcement Turns On

Microsoft's IT pro guide to Windows 11, version 26H2 mentions this in a single sentence: default trust for cross-signed drivers is removed, WHCP-signed drivers and an allow list of trusted legacy drivers remain. That sentence is doing an enormous amount of work. It is describing a change to the rules about what can run in the Windows kernel — the first one of this scale in years — and if you read it as a 26H2 feature you will draw exactly the wrong conclusion about your timeline. The policy did not arrive with 26H2. It has been running on your Windows 11 24H2, 25H2 and 26H1 devices, and on Windows Server 2025, since the April 2026 update.

Who needs to do something about this

The problem: a driver that worked for months stops loading, on a day nothing was installed

The symptom does not look like a policy change. It looks like a hardware fault.

A device that has been working for months suddenly behaves as though a piece of hardware has been unplugged. Microsoft lists three shapes it takes: a hardware device stops functioning correctly; a peripheral or component such as a printer, network adapter or GPU is no longer recognised; or an application that depends on a kernel driver refuses to start.

What makes it genuinely difficult to diagnose is the absence of a trigger. No update was installed that day. Nobody changed a setting. The driver file is still on disk, still has a valid-looking signature, and Device Manager may simply show the device as having a problem. The user's account of events — "it just stopped working" — is completely accurate, which is unusual and, in this case, unhelpful.

The second thing that makes it hard: the policy deliberately goes quiet on the machines that need it most. A device that loads an affected driver every day never reaches enforcement at all — it sits in audit mode indefinitely, working perfectly, reporting nothing. It only becomes a problem once that driver stops being loaded often enough, at which point the counter finally runs to completion and enforcement arrives on a machine you had every reason to believe was fine.

What this looks like as an actual ticket

A worked example, because the shape of this is the part that is hard to recognise the first time.

Three tells to recognise, none of which require you to understand code signing:

1. "It worked on Friday" with no change on Monday. No update, no install, no policy edit — and genuinely so, because the trigger was a counter, not a change.
2. An identical machine is unaffected. Same model, same image, same software, different outcome. That rules out most of what you would normally suspect, and it is exactly what a per-device clock produces.
3. A rebuild fixes it, temporarily. This is the most misleading tell of all, because it looks like proof the problem was local corruption. It is not — reimaging resets the evaluation period, so the fault is guaranteed to return.

Why it happens: an expired signing programme, and a countdown that runs per device

What the cross-signed root program was

To load a driver into the Windows kernel, the driver has to be signed by an authority the kernel trusts. Windows has had two routes to that signature.

The cross-signed root program was the old route, introduced in the early 2000s. Commercial certificate authorities issued code-signing certificates that chained up to a Microsoft-trusted root, and the driver author held the private key and signed their own driver. Microsoft's role was limited: the vetting varied by CA, and crucially the program made no assessment whatsoever of whether the driver code was safe or even compatible. A signature proved someone had bought a certificate. It did not prove anyone had looked at the driver.

It also put the private keys in thousands of separate hands. Those keys leaked and were stolen, and signed-but-malicious kernel drivers became a reliable attack technique — a signature stolen from a legitimate vendor grants ring-0 access on every Windows machine that trusts it.

The Windows Hardware Compatibility Program is the modern route, and the difference is what happens before the signature exists. Submissions are scanned for malware. The publisher's identity is vetted. Hardware Lab Kit test results have to be supplied and pass. Only then does Microsoft sign the driver, with a certificate Microsoft itself owns and controls — the driver author never holds a key that can mint kernel trust.

Microsoft deprecated the cross-signed program in 2021 and every certificate issued under it has since expired. But expiry is not the same as distrust: the kernel carried on honouring drivers that had already been signed, because withdrawing that trust would have broken working hardware. That is the gap the Windows Driver Policy closes.

Why Microsoft says it is safe to do this now

The obvious risk in removing trust from an entire signing programme is breaking hardware that people depend on. Microsoft's mitigation has two parts.

First, an explicit allow list. Microsoft maintains a curated list of reputable, widely-used cross-signed drivers that continue to be trusted even though they are not WHCP-certified. The list was built from driver load telemetry gathered across Windows 11 and Windows Server 2025 over the preceding two years, so the drivers most likely to be in use are the most likely to be on it.

Second, and more important operationally, the two-phase rollout — which is where the per-device timing comes from.

Evaluation mode, and the counter that resets

When the policy activates on a device it starts in evaluation mode, which is an audit mode. Drivers that would be blocked are logged, and then allowed to load anyway. The device keeps working. Meanwhile Windows counts.

Only when all three hold does the device transition to enforcement mode, at which point untrusted cross-signed drivers stop loading, block events are written to the event log, and diagnostic data goes back to Microsoft. Enforcement persists across reboots. There is no drift back to audit.

How long is 250 hours, really?

This is worth doing as actual arithmetic, because "250 hours" sounds like a long time and for some of your devices it is about a week and a half. It counts hours the device is switched on and running, not days on the calendar — so the same threshold produces wildly different wall-clock dates across an estate.

Two practical conclusions from that table. First, your servers are not the safe group — they are among the first to enforce, because being on all the time is what the counter rewards. Second, the devices that enforce last are the ones you will have stopped worrying about: the occasionally-used laptop in a drawer, the spare, the part-time user's machine. Those produce incidents in month four, long after the project felt finished.

Read that reset rule carefully, because it inverts the intuition. The device most at risk of a surprise is not the one with a non-compliant driver — that one is pinned in audit mode and stays working. The risk lands when the blocking driver goes away: someone retires the old scanner, uninstalls the legacy agent, or the vendor ships a WHCP-signed update. The counter starts cleanly, runs for 250 hours, and enforcement engages on whatever other cross-signed drivers are still present but load rarely enough that they were never the thing resetting the clock.

How to verify: which mode this device is in, and which drivers are on the list

Everything in this section is read-only. None of it changes the policy state, and all of it works today on any in-scope device.

Step 1: is the policy present, and which mode is it in?

The Windows Driver Policy is implemented as a pair of Code Integrity policies, identified by fixed GUIDs — one for audit, one for enforcement. CiTool lists the Code Integrity policies active on the device, so asking which of the two GUIDs is present tells you the mode. Run this in an elevated PowerShell session.

$p = (citool -lp -json | ConvertFrom-Json).Policies
$audit   = $p | Where-Object { $_.PolicyID -eq '784c4414-79f4-4c32-a6a5-f0fb42a51d0d' }
$enforce = $p | Where-Object { $_.PolicyID -eq '8f9cb695-5d48-48d6-a329-7202b44607e3' }

if     ($enforce.IsEnforced -and $enforce.IsAuthorized) { 'ENFORCEMENT mode' }
elseif ($audit.IsEnforced   -and $audit.IsAuthorized)   { 'EVALUATION (audit) mode' }
else                                                    { 'Not present on this system' }

# ---------------- output ----------------
EVALUATION (audit) mode

Three outcomes, and each one means something different for your planning:

Step 2: which drivers would be blocked?

This is the query that matters, and the reason to act while you are still in audit mode. Every driver that would be blocked is already being written to the event log, with its filename and the process that tried to load it. Two event IDs, in the CodeIntegrity operational log:

The script below collects the audit events, extracts the driver name, product name and loading process from each event's XML, and de-duplicates. Point it at 3077 instead of 3076 on a device already in enforcement. It reads the event log and writes a CSV; it changes nothing.

# Pick ONE of the two lines below. The event ID and the policy GUID are a
# matched pair - 3076 only ever carries the audit GUID, 3077 only ever carries
# the enforce GUID. Changing one without the other returns zero rows, which
# looks exactly like "no problems found". That false all-clear is the mistake
# to avoid here.

$EventId = 3076; $PolicyId = '784C4414-79F4-4C32-A6A5-F0FB42A51D0D'   # audited (audit mode)
# $EventId = 3077; $PolicyId = '8F9CB695-5D48-48D6-A329-7202B44607E3' # blocked (enforcement)

$events = Get-WinEvent -LogName 'Microsoft-Windows-CodeIntegrity/Operational' `
                       -FilterXPath "*[System[EventID=$EventId]]" -ErrorAction SilentlyContinue |
          Where-Object { $_.Message -like "*$PolicyId*" }

$results = $events | ForEach-Object {
    $data = ([xml]$_.ToXml()).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'
    }
}

$unique = $results | Select-Object DriverName, ProductName, ParentProcess -Unique |
                     Sort-Object DriverName

$unique | Format-Table -AutoSize -Wrap
$results | Export-Csv "$env:TEMP\untrusted-kernel-drivers.csv" -NoTypeInformation

# Print the number LAST, so a device with nothing wrong says so out loud
# instead of just printing nothing and leaving you unsure it ran.
"Affected drivers on this device: {0}" -f @($unique).Count

A device with something to worry about produces output like this. The ProductName column is usually what identifies the culprit to a human — the driver filename on its own is frequently meaningless.

DriverName        ProductName                        ParentProcess
----------        -----------                        -------------
dongle-lm.sys     Vendor Licence Manager               \Device\HarddiskVolume3\Windows\System32\services.exe
legacyscan.sys    Vendor Document Capture Suite        \Device\HarddiskVolume3\Program Files\Vendor\scan.exe
oldvirt.sys       Vendor Virtualisation Platform       \Device\HarddiskVolume3\Windows\System32\services.exe

Affected drivers on this device: 3
CSV written to C:\Users\admin\AppData\Local\Temp\untrusted-kernel-drivers.csv

What a block looks like when it does happen

On a device that has reached enforcement, the refusal is recorded as Event ID 3077 with the enforcement policy's GUID in the Policy ID field, naming both the driver and the process that tried to load it.

The fix: get WHCP-signed drivers, and the two escape hatches

There is one correct answer and two escape hatches, and it is worth being blunt about the order of preference. The correct answer is a WHCP-signed driver. Both escape hatches trade security away, and one of them cannot be applied to a device that is already deployed.

The supported path: replace the driver

1. Identify the driver from the Event 3076 or 3077 output above. You need the ProductName, not just the .sys filename, to work out which vendor to approach.
2. Check Windows Update for a driver update. Many vendors have already WHCP-certified newer versions and shipped them through Windows Update, where they sit as optional driver updates rather than installing automatically.
3. Check the vendor's own support page. A newer release is substantially more likely to be WHCP-signed, and this is often faster than the support-ticket route.
4. Ask the vendor directly whether a WHCP-certified build exists and where to get it. Most vendors do certify; the problem is usually that your estate is pinned to an old version, not that no signed version exists.
5. Deploy it through your normal driver channel and re-run the 3076 query to confirm the driver has dropped off the list.

The manual route to the optional driver updates, for a one-off check on a single device:

Escape hatch 1: turn the policy off (and what you give up)

Microsoft documents this and simultaneously recommends against it, which is the right framing: it lowers the security posture of the device, and the supported fix is a signed driver. If you do need it as a temporary measure while a vendor catches up, the procedure depends on patch level.

Devices with the July 2026 update or later — an administrator can remove the enforcement policy without touching Secure Boot. The current session stays protected; the change takes effect after a restart.

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

# then restart the device to complete the change

Devices without the July 2026 update carry extra startup protection on the policy, and removal is considerably more invasive: you have to disable Secure Boot in UEFI, mount the EFI System Partition, delete the policy file from both the EFI partition and the Windows Code Integrity store, unmount, restart, and then go back into UEFI to re-enable Secure Boot.

mountvol S: /s

Remove-Item "S:\EFI\Microsoft\Boot\CiPolicies\Active\{8F9CB695-5D48-48D6-A329-7202B44607E3}.cip" -Force
Remove-Item "$env:windir\System32\CodeIntegrity\CiPolicies\Active\{8F9CB695-5D48-48D6-A329-7202B44607E3}.cip" -Force

mountvol S: /d

# restart, then re-enable Secure Boot in UEFI

If either Remove-Item reports that the file does not exist, that is expected on some devices — carry on with the remaining steps. Use a different drive letter if S: is already taken, and substitute it throughout.

Escape hatch 2: App Control custom kernel signers, for drivers that cannot be certified

There is a legitimate case the WHCP route does not serve: organisations running classified, sensitive or air-gapped environments that cannot submit driver binaries to Microsoft, and organisations writing drivers purely for internal use that have no reason to certify for the public Windows ecosystem.

For these, Windows supports custom kernel signers — an App Control for Business policy, signed by an authority in the device's Secure Boot hierarchy, that extends kernel trust to your own PKI without WHCP signatures. The trust chain runs in layers:

Availability and prerequisites, which are restrictive by design — the friction exists to keep the feature away from consumer devices:

• AMD64: Windows 11 24H2 or later, with the April 2026 non-security update or later.
• ARM64: Windows 11 24H2 or later with the July 2026 non-security update or later, and System Guard Secure Launch.
• Available on all Windows editions except Home.
• UEFI firmware 2.3 or later, with Secure Boot enabled (the feature only works with Secure Boot on).
• Your own PKI, with HSM-backed key storage recommended for production, plus administrative access to the UEFI PK, KEK and DB variables and SignTool.exe from the Windows SDK.

Where Intune and Group Policy fit — and where they do not

This is worth stating plainly, because it is the first question most endpoint engineers ask and the answer is unusual.

Practically, that means your visibility into this has to be built rather than configured: the Event ID 3076 query as a fleet-wide script, with the results collected somewhere you can read them. That is the gap this post exists to fill.

Proof it worked: what a clean device looks like

Two checks confirm a device is in good shape, and you want both — they answer different questions.

Check one: no drivers being audited or blocked. Re-run the query from Step 2. On a device with nothing at risk it returns nothing at all, which is the result you want and initially looks like the script failed.

.\Get-UntrustedKernelDrivers.ps1

# ---------------- output ----------------
Affected drivers on this device: 0

# No 3076 events carrying the Windows Driver Policy audit GUID.
# Nothing on this device would be blocked by enforcement.

Check two: the device has reached enforcement. An empty audit list on a device still in evaluation mode is good but provisional — it tells you nothing is at risk right now. A device in enforcement mode with an empty block list is the finished state: the policy is live, and nothing on the machine is affected by it.

# mode check from Step 1
ENFORCEMENT mode

# count of 3077 block events carrying {8F9CB695-...}
0

# Policy enforced, zero drivers blocked. Nothing further to do on this device.

Quick reference: every GUID, event ID and path in one place

Glossary: the seven terms this topic depends on

Frequently asked questions

References

• The Windows Driver Policy — Microsoft Support. The operational reference: evaluation criteria, event IDs, policy GUIDs, the mode-check script and the removal procedures.
• Advancing Windows driver security: removing trust for the cross-signed driver program — Windows IT Pro Blog, 26 March 2026, updated 9 June 2026. The original announcement, and the source of the 100 → 250 hour correction.
• Custom kernel signers for App Control for Business — Microsoft Learn. The trust chain, prerequisites, the clean-install requirement and the full signing walkthrough.
• An IT pro's guide to Windows 11, version 26H2 — Windows IT Pro Blog. Where most admins will first encounter this, in one sentence.
• What's new in Windows 11, version 26H2 — Microsoft Learn. Note the stale 100-hour figure discussed above.
• Get started with Hardware Dev Center submissions — Microsoft Learn. The WHCP submission and signing route, for driver publishers who need a certified build.
• Kernel-mode code signing requirements — Microsoft Learn. Background on how kernel driver signature validation works, if the mechanism itself is new to you.

Related reading on EndpointWeekly

• Memory Integrity will not turn on: finding the incompatible driver — a different mechanism that produces a similar-looking symptom. That one is about the vulnerable driver blocklist, which blocks drivers Microsoft knows to be dangerous. This post is about withdrawing trust from an entire signing programme regardless of whether any individual driver is known to be bad.
• Smart App Control versus App Control for Business — App Control deployment in general, which is the engine behind the custom kernel signers escape hatch.
• The inpoutx64 driver block in KB5121003 — a single named driver blocked by Microsoft for a specific compatibility fault, and a useful contrast in scope.