Microsoft Advancing Windows Driver Security: Ending Cross-Signed Kernel Driver Trust

Key Annoucement mad by Microsoft

Microsoft is preparing a major change to Windows that could quietly reshape how security and compatibility are balanced across the entire ecosystem.

Starting April 2026, Windows will begin blocking kernel drivers signed through the legacy cross-signed root program by default, replacing a decades-old trust model with a stricter, policy-driven approach centred on the Windows Hardware Compatibility Program (WHCP).

This is more than a routine update. It marks a turning point in how Windows defines trust at its most critical layer—the kernel.

Why This Change Matters Now

For a long time, Windows has allowed third-party CAs (certificate authorities) to create trust chains into the kernel through cross-signing. At that time, this model was more acceptable because flexibility and broader hardware compatibility were critical to grow the platform.

However, over time, this created a long tail of implicit trust (drivers that were still valid, not because they were compliant with current standards, but because they had no explicit revocation).

In 2021, Microsoft would deprecate this model; however, remnants remain in production. With the launch of Windows 11 and Windows Server 2025, Microsoft will take the next step towards removing deprecated trust paths that no longer meet current security expectations.

The timing fits into a broader push, as enterprise customers have repeatedly cited reliability, fragmentation, and hidden dependencies as significant concerns; tightening kernel trust addresses all three at once.

From Implicit Trust to Explicit Control

The change at the centre of this change is a complete shift in philosophy:

• Driver Policy – Old way: All drivers are trusted unless they do not meet the general criteria
• Driver Policy – New way: No driver is trusted unless it is specifically defined to be trusted

New Policy:

• Drivers that are signed according to WHCP will be accepted by default.
• There will be an allow list for older yet trusted drivers.
• There will be an option for enterprises to use WDAC to generate exceptions from any policy.

Microsoft is moving from a passive trust-based system to an intentional trust-based system with built-in auditing and controls.

The Role of Evaluation Mode

Because of the risk of enforcing the rules too quickly, Microsoft will start the policy rollout in an evaluation mode to give IT departments the chance to:

• Identify which drivers will be blocked
• Collect logs of all events that are blocked from running
• Provide IT departments with the tools they need to determine how to phase in new policies.

This evaluation mode aligns with Microsoft’s constant security philosophy of observing first and enforcing later. With the complexities of enterprise hardware environments, staged deployments of the enforcement of policies will help to mitigate any service interruptions.

Why the Kernel Is Different

Kernels carry a greater risk because they have a broader impact on security, especially if you make changes at the kernel level.

Kernel drivers directly interact with the OS, being given elevation of privilege, should an attack compromise a kernel driver:

• The attacker could bypass security mechanisms put in place
• The attacker could create a method for maintaining access on a compromised machine
• The attacker could ultimately degrade the overall system’s operation and stability

By removing these untrustworthy pathways through the kernel, Microsoft is effectively decreasing a very high-risk area to attack in the Windows OS.

Also Read: Windows Baseline Security Mode (BSM) Raises the Bar for Application Trust and Code Signing

Enterprise Impact: Where the Real Work Begins

Most customers won’t experience much impact from this transition, but large businesses will immediately feel it.

For example, large businesses typically have many factors that will be affected by this change, including things such as:

• The use of legacy hardware in their industrial systems
• The use of older drivers in their point-of-sale equipment
• The use of custom-built internal drivers
• The use of vendor software (that hasn’t been updated in many years)

And many of these things won’t be known until something breaks.

What IT Teams Should Do Now?

To prepare for this deadline of April 2026, companies should:

• Review driver auditing for all endpoints
• Identify any dependencies on legacy cross-signed drivers
• Work with your vendors to obtain WHCP-compliant updates for their products
• Test using evaluation mode before enforcement
• Use WDAC overrides very sparingly for critical exceptions
• Prepare rollback and support plans for edge cases

The policy should not be the biggest challenge facing your organisation; the biggest challenge is all the hidden technical debt that will be revealed when this transition is made.

Consumer Impact: Mostly Invisible, Occasionally Frustrating

End users will most likely not see any impact from this switch since many devices today already use modern drivers compatible with Microsoft’s current requirements.

However, there are still some cases that are not standard:

• Older hardware
• Fibre optic audio or gaming peripherals
• Specific equipment that was manufactured with old driver designs

If you find yourself experiencing any of the following problems, it may be due to bad drivers on your PC:

• Devices do not operate correctly
• Features are disappearing without notice

Windows will most likely be blamed as the cause of these or other problems rather than the underlying driver.

WHCP as the New Trust Standard

The focus Microsoft has taken with the WHCP is intentional and part of the overall goal of creating a continuous validation ecosystem where drivers will be:

• Tested against the latest platforms
• Signed by Microsoft through official methods
• Supported through an ongoing lifecycle

By doing these three items, the overall ecosystem is more stable and secure, while also raising the bar on hardware vendors’ requirements to comply.

A Necessary Trade-Off

The changes to the Windows driver models highlight a long-standing challenge faced by Windows:

Backward compatibility vs forward security

For decades, Microsoft leaned to the side of providing backward compatibility; however, this resulted in many legacy issues, such as numerous exceptions, outdated trust levels, and increased security risks.

Now, Microsoft is attempting to bring balance to its decision-making process regarding this trade-off by:

• Default behaviour becomes more secure
• Exceptions become explicit and controlled

This will continue to present challenges with regard to backward compatibility; however, it provides a foundation for addressing these problems in a more proactive manner rather than relying on historical decisions.

Risks and Challenges Ahead

The transition to this model of trust and security is fraught with risk:

• There’s a possibility that legacy hardware and software will fail in an unpredictable manner
• Support from vendors may not keep pace with changes in policy
• IT teams may not have complete visibility into what assets they are responsible for managing
• Overuse of “allow” lists may mask more serious issues that need to be addressed
• Microsoft’s ability to effectively balance enforcement with flexibility will determine the success of this transitional plan.

The Bigger Picture

This change to kernel trust is part of a much larger shift underway at Microsoft. The company is systematically transforming Windows into a more mature model where:

• Trust is built by demonstrable criteria, not affirmative action
• Security is embedded in defaults
• Exceptions are visible and manageable

Microsoft is seeking to completely redefine the Windows platform—not as a burdened legacy platform, but as one that can continue to evolve by eliminating historical anomalies, without constantly burdening future generations with historical decisions.

Conclusion

Stay updated with the industry with our blog and secure your code with our trusted code signing certs.

Search