Windows Cross-Signed Driver Trust Removal: Enterprise Readiness and Rollout Plan

Microsoft is removing trust for kernel-mode drivers signed under the deprecated cross-signed root certificate program. The change arrives with the April 2026 Windows cumulative update on Windows 11 24H2, 25H2, 26H1, and Windows Server 2025. The policy starts in evaluation mode, then can enforce automatically on each device when its evaluation criteria are met; it does not wait for a separate future enforcement update.

That evaluation window is your only useful lead time. This guide explains what to audit, how to find affected drivers before enforcement, how to sequence rollout across Intune rings, and when to escalate to vendors.

Pair this with the May 2026 Patch Tuesday readiness notes, Secure Boot CA 2023 enterprise readiness guide, and the patch management hub.

Who This Affects

Prioritise review for fleets with:

Legacy hardware with OEM drivers outside WHCP
Security products installing kernel drivers
Line-of-business apps with embedded kernel components
Virtual machines using older driver packages
Imaging environments that inject third-party storage or network drivers

If your estate is standard Microsoft Surface or recent enterprise OEM builds on current driver packs, risk is lower — but still verify. Evaluation mode exists because Microsoft expects surprises.

What Is Changing

The cross-signed driver program predates current WHCP requirements for EV code signing and WHQL certification. Drivers signed only under the older cross-signed root no longer meet Microsoft's kernel trust bar.

Phase	Behaviour
April 2026 update applied	Evaluation mode begins — affected drivers logged, not blocked
Device passes evaluation	Policy activates automatically; untrusted drivers outside the allowed set can be blocked

Affected platforms per Microsoft:

Windows 11 24H2, 25H2, 26H1
Windows Server 2025

Microsoft’s updated announcement specifies 250 system hours plus three restarts for Windows 11, or two for Server 2025. If audited drivers would fail the policy, evaluation resets instead of activating. Microsoft also maintains an allow list of selected cross-signed drivers. Test less-frequent peripheral and recovery workflows during evaluation; elapsed time alone is not an administrator sign-off.

Operational Impact

When a device activates enforcement, a blocked driver can cause:

Boot failure or STOP error on critical systems
Loss of storage, network, or security agent functionality
Silent failure of a kernel filter driver with no obvious user message
Recovery time lost to Safe Mode, WinPE, or bare-metal rebuild

Evaluation mode is the period to find these outcomes in logs — not after enforcement.

Pre-Flight Checks Before Broad Deployment

1. Confirm update ring order

Deploy the current applicable cumulative security update through normal rings; April introduced the change, but it is not the current patch target:

IT pilot devices with varied hardware vendors
Security operations workstations
Broad production

Do not skip the update to avoid driver evaluation. Delaying security updates trades one risk for another.

2. Baseline Secure Boot readiness

Cross-signed driver trust sits inside the wider Secure Boot trust story. If you have not completed CA 2023 readiness, run that programme in parallel:

Secure Boot CA 2023 rollout enterprise readiness

3. Identify high-risk device groups

Export hardware diversity before rollout:

Group	Why
Legacy laptops (5+ years)	Older OEM drivers
Custom kiosk builds	Non-standard driver stacks
VMs with legacy integration services	Synthetic driver packages
Servers with hardware monitoring agents	Kernel filter drivers
Devices with third-party disk encryption	Lower-level storage drivers

Finding Affected Drivers In Evaluation Mode

Event Viewer

After the April 2026 update installs on a pilot device:

Open Event Viewer
Review System and Microsoft-Windows-CodeIntegrity/Operational logs
Look for events indicating a driver would fail trust under the new policy during evaluation

Record for each hit:

Driver file name
Device name and serial
Hardware model
Business owner
Vendor contact

PowerShell driver inventory

Collect PnP driver inventory on an authorised pilot device using an elevated PowerShell session. This includes Microsoft and third-party entries and does not enumerate every non-PnP kernel driver:

PowerShell

New-Item -ItemType Directory -Path C:\Temp -Force | Out-Null
Get-CimInstance Win32_PnPSignedDriver |
    Where-Object { $_.DeviceClass -ne $null } |
    Select-Object DeviceName, DriverVersion, DriverProviderName, DriverDate, IsSigned |
    Sort-Object DriverProviderName, DeviceName |
    Export-Csv -Path "C:\Temp\driver-inventory.csv" -NoTypeInformation

The CSV contains PnP driver records with provider, version and signature status. IsSigned does not establish acceptance by the new kernel trust policy; correlate actual Code Integrity events. Keep exports restricted.

Intune reporting angle

For managed devices, combine:

Hardware manufacturer and model from Devices > Windows devices
Last logged-on user and group membership for ring targeting
Patch compliance state from Windows Update for Business deferral troubleshooting patterns

There is no single Intune blade that lists kernel driver trust failures yet — local Event Viewer on pilot hardware remains the fastest signal.

Vendor Escalation Template

When evaluation logs surface a driver, open a vendor ticket with:

Device model and OS build
Driver name, version, and signing publisher
Event log excerpt with timestamp
Ask explicitly: "Is a WHCP-compliant replacement available before enforcement?"

Track responses in the same register as your patch exceptions.

Rollout Sequence For Intune-Managed Fleets

Ring	Action
Ring 0 — IT engineering	Apply current applicable update; exercise boot/runtime scenarios and monitor actual evaluation state
Ring 1 — Representative hardware sample	One device per OEM family minimum
Ring 2 — Department pilot	Monitor helpdesk tickets for boot or agent failures
Ring 3 — Production	Proceed only when Ring 2 shows no unresolved driver hits

Pause ring progression when evaluation logs show an unresolved kernel driver from a business-critical app. Fix or exception the driver first.

Rollback And Recovery Considerations

Scenario	Response
Evaluation log shows non-critical optional driver	Plan vendor upgrade; do not block rollout for entire ring
Evaluation log shows boot-critical storage driver	Stop ring expansion; test replacement driver on lab hardware
Enforcement arrives before vendor fix	Document risk acceptance per device group; isolate vulnerable systems

Keep recovery media and BitLocker recovery keys accessible before touching server or kiosk rings.

Prevention Checks

After rollout:

Add driver evaluation log review to your Patch Tuesday pilot checklist for two months
Require WHCP-signed drivers in imaging standards for new hardware purchases
Block ad-hoc driver installs without change control on servers
Keep Secure Boot and TPM baselines aligned with CIS hardening guidance

Source

This operational plan is based on the official Windows IT Pro Blog post published by Microsoft on March 26, 2026, extended with enterprise rollout and evidence collection steps for Windows administrators.

Correction record

10 September 2026 — Reviewed against documentation: Corrected automatic per-device enforcement and current 250-hour criteria; distinguished PnP inventory and signature presence from kernel-policy trust.