HVCI Blocks Custom Kernel Signer (CKS)

Question

HVCI Blocks Custom Kernel Signer (CKS)

CommandX 20

Hello, I was following the Tutorial for the CKS Documented here https://learn.microsoft.com/en-us/windows/security/application-security/application-control/app-control-for-business/design/custom-kernel-signers This feature is Officially Documented in early March 2026 I have followed what the Documentation said and was able to load my Custom Signed Driver as showed here

C:\Windows\System32>sc query drvtest

SERVICE_NAME: drvtest

    TYPE               : 1  KERNEL_DRIVER

    STATE              : 4  RUNNING

                            (STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)

    WIN32_EXIT_CODE    : 0  (0x0)

    SERVICE_EXIT_CODE  : 0  (0x0)

    CHECKPOINT         : 0x0

    WAIT_HINT          : 0x0

but this exact same policy and driver does NOT work with HVCI Enabled (via Memory Integrity) if tried to load it the system report

PS C:\Users\CommandX> sc.exe start drvtest

[SC] StartService FAILED 577: Windows cannot verify the digital signature for this file. A recent hardware or software change might have installed a file that is signed incorrectly or damaged, or that might be malicious software from an unknown source.

CodeIntegrity Events show this

PS C:\Users\CommandX> Get-WinEvent -LogName "Microsoft-Windows-CodeIntegrity/Verbose" -Oldest | >> Where-Object { >> $.TimeCreated -gt $before -and >> $.Id -in 3023,3033,3034,3077,3091,3038,3039,3015,3016,3004 >> } | >> Format-List TimeCreated, Id, Message

TimeCreated : 6/8/2026 7:48:49 AM Id : 3038 Message : Code Integrity started validating image header of \drvtest\test.sys file.

TimeCreated : 6/8/2026 7:48:49 AM Id : 3015 Message : Code Integrity started validating file hash of \Device\HarddiskVolume3\drvtest\test.sys file.

TimeCreated : 6/8/2026 7:48:49 AM Id : 3016 Message : Code Integrity completed validating file hash. Status 0xC0000428. TimeCreated : 6/8/2026 7:48:49 AM Id : 3015 Message : Code Integrity started validating file hash of \Device\HarddiskVolume3\drvtest\test.sys file.

TimeCreated : 6/8/2026 7:48:49 AM Id : 3016 Message : Code Integrity completed validating file hash. Status 0xC0000428.

TimeCreated : 6/8/2026 7:48:49 AM Id : 3039 Message : Code Integrity completed validating image header. Status 0xC0000428.

I confirmed my Signature is Trusted in the Policy, so any idea why this is not working ? or HVCI might have some Policies that Override my Signature ? Thank you

0 comments

2 answers

Your answer

Answer 1

Jason Nguyen Tran 19,545 Independent Advisor

Hello,

You are correct that Custom Kernel Signers (CKS) can load drivers when HVCI (Memory Integrity) is disabled, but enabling HVCI enforces stricter validation rules. Specifically, HVCI requires that kernel drivers be signed with certificates that meet Hypervisor-protected Code Integrity requirements. Even if your signature is trusted in the policy, HVCI may override it if the certificate chain does not meet these stricter standards.

The error code 0xC0000428 indicates that Code Integrity could not validate the driver’s signature under HVCI. This often happens if:

The signer certificate is not cross-signed by Microsoft’s kernel-mode code signing program.
The driver catalog file is missing or not properly associated.
The policy does not include the correct GUID for the signer in the HVCI context.

To troubleshoot, I recommend:

Verifying that your certificate is enrolled in the Microsoft Kernel Mode Code Signing program.
Ensuring the driver has a valid catalog (.cat) file and that it is signed consistently with the .sys file.
Using Get-CIPolicy and Get-CIPolicyInfo PowerShell commands to confirm the signer is listed correctly in the applied CI policy.
Testing with a fresh CI policy generated with New-CIPolicy that explicitly includes your signer under HVCI rules.

I hope this guidance helps you move forward with your testing. If you find this answer useful, please hit “accept answer” so I know it addressed your concern.

Jason

CommandX 20 Reputation points

2026-06-08T02:49:27.26+00:00

Is there any Guide for me to follow to Authorize my Custom Signed driver within HVCI ? I mean how can I add my Signer rule to the Policy so it met that HVCI Context ? I still couldn't get it...
Jason Nguyen Tran 19,545 Reputation points Independent Advisor

2026-06-08T05:05:44.6166667+00:00
To authorize your Custom Kernel Signer (CKS) driver under HVCI, you need to explicitly add your signer into a Code Integrity (CI) policy that is HVCI‑aware. Simply trusting the certificate in a standard CI policy is not enough, HVCI enforces stricter rules and requires the signer to be listed in the policy with the correct GUID.

Here are the recommended steps:

Use PowerShell to generate a new CI policy with New-CIPolicy -Level Publisher -FilePath <path> -UserPEs -Fallback Hash. This will capture your signer information.

Run ConvertFrom-CIPolicy to create the binary form of the policy, then deploy it via Group Policy or Intune.

Use Get-CIPolicyInfo to confirm that your signer’s GUID is present in the policy and marked as authorized.

Ensure the driver has a valid catalog (.cat) file signed with the same certificate, as HVCI validates both the .sys and its catalog.

Reboot with Memory Integrity enabled and check Code Integrity logs again to confirm the driver is validated.

The key difference is that HVCI requires the signer to be explicitly included in the CI policy, not just trusted by the OS. Once your signer is added correctly, the driver should load under HVCI without error.

I hope this guidance helps you move forward. If you find this answer useful, please hit “accept answer” so I know it addressed your concern.

Jason.
CommandX 20 Reputation points

2026-06-08T13:44:19.5733333+00:00

Unfortunately Jason, it didn't work as it seem to report same error even after regenerating Policy containing the Certificate... any other idea ?
Jason Nguyen Tran 19,545 Reputation points Independent Advisor

2026-06-09T04:45:46.4966667+00:00
At this stage, the most likely cause is that the certificate chain itself does not meet Hypervisor-protected Code Integrity (HVCI) requirements, even if the policy includes the certificate. HVCI enforces stricter rules than standard Code Integrity, and it will reject drivers unless the signer certificate is part of Microsoft’s Kernel Mode Code Signing (KMCS) program or chained to a Microsoft-approved cross-certificate.

Here are a few additional steps you can try:

Verify that your certificate is KMCS-approved and not just a local CA or self-signed certificate.

Confirm that the driver has a properly signed catalog (.cat) file, as HVCI validates both the .sys and its catalog.

Use Get-CIPolicyInfo to ensure the signer GUID is present and authorized in the deployed policy.

Test with a fresh CI policy that includes both publisher and hash rules (New-CIPolicy -Level Publisher -UserPEs -Fallback Hash).

If the certificate chain does not meet KMCS requirements, the only reliable solution is to re-sign the driver with a KMCS-approved certificate.
CommandX 20 Reputation points

2026-06-10T04:28:21.5266667+00:00

I'm Sorry Jason but isn't that this Documented CKS feature Goal is to make All Custom Signed driver is authorized and can be loaded by App Control for Business ? If you're saying I need KMCS Approved Certificate then, this Feature is useless as we speak.

Answer 2

HVCI (memory integrity) enforces additional kernel-mode code integrity requirements beyond what a standard App Control for Business policy enforces. A custom kernel signer that works when HVCI is disabled can still be blocked when HVCI is enabled if the driver or its signing chain does not meet HVCI’s stricter rules.

From the provided information:

The driver loads successfully with the App Control for Business custom kernel signer policy when HVCI is off.
With HVCI on, Code Integrity returns status 0xC0000428 (invalid or untrusted signature) for the same driver.

This indicates that:

The App Control custom kernel signer policy is functioning as expected in the non‑HVCI path.
Under HVCI, the driver’s signature or its trust chain is not accepted by the HVCI code integrity runtime, so the load is blocked before the App Control policy can allow it.

Key points from the documentation relevant to this behavior:

Memory integrity (HVCI) runs kernel-mode code integrity checks inside a VBS-isolated environment and “protects the kernel mode code integrity process that ensures that other trusted kernel processes have a valid certificate.” It restricts kernel memory and enforces that executable kernel pages are only created after passing code integrity validation inside that secure environment.
HVCI is explicitly described as a stronger protection model that can introduce compatibility issues with some drivers. The guidance notes that “some applications and hardware device drivers may be incompatible with memory integrity,” and that such incompatibilities can cause failures when memory integrity is turned on.
Driver compatibility with memory integrity and VBS is treated as a separate requirement. There is a dedicated “HyperVisor Code Integrity Readiness Test” and a “Driver compatibility with memory integrity and VBS” test area in HLK, which are used to verify that drivers are compatible with HVCI. These tests focus on both signing and how the driver uses kernel memory (for example, avoiding executable pool allocations, executable mappings, or executable‑and‑writable sections).

Putting this together for the scenario:

Custom kernel signers extend App Control for Business so that an organization can trust kernel drivers signed with its own PKI instead of WHCP signatures. This is about defining which signing certificates are authorized for kernel mode code.
HVCI, however, is a VBS-based enforcement layer that validates kernel code in an isolated environment and has its own compatibility and integrity requirements. Even if App Control’s custom kernel signer policy trusts the certificate, HVCI can still reject the driver if:
- The signing chain is not considered valid in the HVCI context, or
- The driver fails HVCI compatibility rules (for example, uses disallowed executable memory patterns or has executable‑and‑writable sections).

The error pattern in the Code Integrity log (repeated hash validation ending with 0xC0000428) is consistent with “signature not trusted in this enforcement mode,” not with a simple App Control policy mismatch.

Actionable direction based on the documentation:

Treat HVCI compatibility as a separate requirement from App Control custom kernel signer trust.
Use the HVCI/Device Guard compatibility tests in HLK (for example, “HyperVisor Code Integrity Readiness Test” and the “Driver compatibility with memory integrity and VBS” tests) to validate the driver and identify any HVCI‑specific issues.
Review and fix any HVCI incompatibilities reported by those tests (for example, executable pool types, page protections, MDL mappings, or executable‑and‑writable sections) as described in the driver compatibility guidance.

In short: yes, HVCI can effectively override what the custom kernel signer policy allows. The driver must be both trusted by the custom kernel signer policy and fully compatible with HVCI’s stricter code integrity and memory usage rules to load successfully when memory integrity is enabled.

References:

Share via

HVCI Blocks Custom Kernel Signer (CKS)

2 answers

Your answer