Kernel Driver virtualization is no longer allowed?

Question

Hi all,

I am looking for an official answer on protection practices for Windows kernel mode drivers used in anti cheat and anti tamper scenarios. Our protection vendor, Oreans Code Virtualizer, has told us that some customers were informed that virtualized drivers are no longer accepted for signing. Before we change our approach I would like to confirm what Microsoft actually allows today and where this is documented.

First, are kernel mode drivers that use code virtualization or packing currently disallowed for attestation signing or for Windows Hardware Lab Kit signing. If there has been a change, when did it take effect and where is the policy written so we can follow it exactly.

Second, what is the scope of any restriction. Does it apply to any virtual machine style control flow obfuscation, or only to packers that transform the portable executable image at load or at run time? Are techniques like symbol and string obfuscation, constant encryption, and removal of metadata treated differently from full code virtualization?

Third, because anti cheat and antivirus style products are frequent targets for reverse engineering, is there any exception process, or allow list for security vendors who need stronger protection than basic obfuscation. If such a process exists, how do we apply, what evidence or documentation is needed, and what review criteria are used.

If code virtualization is not allowed at all, what protection methods does Microsoft recommend for drivers that must resist static and dynamic analysis while remaining compliant. Guidance on acceptable alternatives would be very helpful, for example approved patterns for encryption at rest that do not involve run time code mutation, expectations for section permissions, and other design patterns that maintain integrity without violating policy.

Links to the relevant documentation or policy pages would be greatly appreciated. Thank you.