Custom Kernel Signers for App Control for Business

Starting in April 2026, cross-signed certificate authorities (CAs) are no longer trusted by default for kernel mode driver signing. The standard path for kernel driver signing is through the Hardware Dev Center (HDC), which requires submitting driver binaries to Microsoft for Windows Hardware Compatibility Program (WHCP) certification. However, organizations with classified, sensitive, or air-gapped environments might not be able to submit drivers to Microsoft for certification. Additionally, organizations who write drivers for internal use only might not want to certify drivers for the Windows ecosystem.

Custom kernel signers solves this problem by extending App Control for Business to let organizations trust kernel drivers signed with their own public key infrastructure (PKI), without requiring WHCP signatures. The feature uses an App Control policy signed by a signing authority in the Secure Boot hierarchy to define which signing certificates are authorized for kernel mode code. This feature gives you granular, auditable control over your kernel trust boundary and removes the requirement to WHCP certify your drivers.

How Custom Kernel Signers works

The custom kernel signers feature uses a layered trust chain and an App Control policy to override the default signing requirements built into the Windows kernel. Here's how the trust chain works:

Only the platform holder (PK or KEK owner) can authorize the policy. This high-friction enrollment process is intentional. The process prevents misuse on consumer devices and ensures that only organizations with physical firmware access can enable the feature.

Security guarantees

Custom kernel signers provide the following security guarantees:

• Secure Boot integrity: Custom kernel signers only work when Secure Boot is enabled. The policy must be signed by the Secure Boot PK or KEK owner and can't be spoofed without physical firmware access.
• Tamper protection: Once deployed, the signed policy can't be removed without a replacement policy signed by the same authority.
• Granular trust: The App Control policy allows per-certificate and per-hash trust rules. You control exactly which drivers run in your kernel.
• Non-repudiation: All policy and driver signatures are cryptographically verifiable. Code integrity event logs capture all load and block decisions for audit.

Supported Platforms and Editions

The custom kernel signers feature is available on the following Windows platforms with the April 2026 non-security update:

• Windows 11 (version 24H2 and later)

The feature is available on all editions of Windows except Home.

Custom Kernel Signers Deployment

Before you begin, ensure the following requirements are met:

• Clean install of Windows on a supported edition. Custom kernel signers must be enabled during initial device setup. The feature won't enable on currently running systems.
• UEFI firmware (version 2.3 or later) with Secure Boot enabled.
• Customer-owned PKI infrastructure. An HSM-backed key storage solution is recommended for production environments.
• Administrative access to UEFI firmware variables (PK, KEK, DB).
• SignTool.exe from the Windows SDK.
• Familiarity with App Control for Business policy design, signed policy and policy rules.

Step 1: Generate the Secure Boot keys

Generate the PKI key pair that serves as your root of trust in Secure Boot and be used to sign your App Control policy. Either the PK or KEK can be used as the root of trust to sign the App Control policy. Microsoft's guidance is to add the PKI key to KEK so the PK owner can continue to service KEK in the future.

PK and KEK certificates must be root certificates or intermediate certificates (PCAs) issued directly from the root. The Windows Secure Boot Key Creation and Management Guidance document has more information and guidance on creating certificates compatible with Secure Boot. You can also use the Microsoft KEK key as a reference template for key properties and extensions.

Step 2: Configure the Secure Boot UEFI variables with access to the PK

If you own the PK on devices, you can sign the KEK enrollment to add your KEK public key to the UEFI firmware. If you don't own the PK, you can skip to Step 3.

Generate the KEK enrollment content

# Generate KEK content file
# Replace the SignatureOwner GUID with your organization's GUID
Format-SecureBootUEFI `
    -Name KEK `
    -SignatureOwner "55555555-5555-5555-5555-555555555555" `
    -ContentFilePath C:\KEK\KEK_SigList.bin `
    -FormatWithCert `
    -Certificate C:\KEK\policy_signer.cer `
    -SignableFilePath C:\KEK\KEK_Signable_SigList.bin `
    -Time 2025-01-01T00:00:00Z `
    -AppendWrite:$true

Sign the KEK enrollment file with your PK

signtool.exe sign /fd sha256 
    /p7 .\ 
    /p7co 1.2.840.113549.1.7.1 `
    /p7ce DetachedSignedData `
    /a `
    /f PK.pfx`
    C:\KEK\KEK_Signable_SigList.bin

Step 3. Configure the Secure Boot UEFI variables without access to the PK

To set the UEFI Secure Boot variables, first disable Secure Boot in the UEFI menu to put the firmware into Setup Mode. In Setup Mode, variables can be set without signed updates.

Set the variables in the following order:

1. DB - Add the OEM and Windows UEFI CA 2023 certificate.
2. KEK - Add the Microsoft KEK CA 2K 2023, and your organization's policy signer certificate.
3. PK - Set your organization's Platform Key (or leave the OEM PK in place if you're using KEK enrollment).

Step 4: Create the App Control policy

Start with the Default Enforced Windows Policy as the base template, then scan the device for other signers that need to be trusted.

Locate the default policy template

The default policy template is available at:

%WINDIR%\schemas\CodeIntegrity\ExamplePolicies\DefaultWindows_Enforced.xml

Scan the device for existing kernel signers

New-CIPolicy -ScanPath 'C:\' -UserPEs -NoScript `
    -FilePath '.\ScannedPolicy.xml' `
    -Level PCACertificate -Fallback Hash

Merge the default policy with the scan results

Merge-CIPolicy `
    -PolicyPaths 'C:\Windows\schemas\CodeIntegrity\ExamplePolicies\DefaultWindows_Enforced.xml', '.\ScannedPolicy.xml' `
    -OutputFilePath '.\CustomKernelSignersPolicy.xml'

Prepare your policy for signing

The custom kernel signers feature requires the policy to be signed and protected by Secure Boot and early Windows boot components. See more information on signed App Control policies. To enable signed policy, remove Option 6 (unsigned policy):

Set-RuleOption -Option 6 -FilePath .\CustomKernelSignersPolicy.xml -Delete

(Optional) Remove User Mode Code Integrity

If you want the policy to apply only to kernel mode drivers, remove Option 0 (UMCI):

Set-RuleOption -Option 0 -FilePath .\CustomKernelSignersPolicy.xml -Delete

Best practices for the base policy

• Customize the image first. Remove any unapproved software before scanning the device.
• Use -Level PCACertificate for the best balance of specificity and coverage.
• The scan captures all existing signers on the device, ensuring Windows components and hardware drivers remain trusted. Consider only scanning your confidential drivers instead.
• Test thoroughly in Audit mode before deploying in enforced mode.

Step 5: Add custom kernel signers to the policy

Add the TBS (To Be Signed) hash of each trusted certificate to the following sections of your policy XML. You need entries for:

# Policy signer certificate(s): 
Add-SignerRule -CertificatePath <path_to_cer> -FilePath .\CustomKernelSignersPolicy.xml -Update

# Custom kernel signer certificate(s): 
Add-SignerRule -CertificatePath <path_to_cer> -FilePath .\CustomKernelSignersPolicy.xml -Kernel

Step 6: Convert and sign the policy

Convert the XML policy to binary format

Set-CIPolicyIdInfo -ResetPolicyID -FilePath .\CustomKernelSignersPolicy.xml
$PolicyId = ([xml](Get-Content .\CustomKernelSignersPolicy.xml)).SiPolicy.PolicyId
ConvertFrom-CIPolicy .\CustomKernelSignersPolicy.xml -BinaryFilePath ("./" + $PolicyId + ".cip")

Sign the policy with your policy signing certificate

signtool.exe sign /fd sha256 `
    /p7 .\ `
    /p7co 1.3.6.1.4.1.311.79.1 `
    /p7ce Embedded`
    /a `
    /f policy_signer.pfx `
    ("./" + $PolicyId + ".cip")

Step 7: Deploy the policy

You can deploy the signed policy binary using any of the following methods:

• MDM solution such as Microsoft Intune
• CiTool (available on Windows 11)
• Group Policy (deploy via GPO)
• Script-based deployment (deploy via script)

Script-based deployment to the EFI System Partition

All above solutions, besides script-based deployment, deploy the policy binary to the EFI System Partition (ESP) automatically. If deploying via script, you must manually copy the signed policy binary to the EFI partition:

# Mount the EFI System Partition
mountvol s: /s

# Copy the signed policy to the active policies directory
copy ("./" + $PolicyId + ".cip") s:\EFI\Microsoft\Boot\CiPolicies\Active\

Step 8: Reset Windows

A reset of Windows is required to enable the feature. Once the policy is present on the EFI partition, you must reset the device using a reset method like Push-button reset. The policy will not be trusted by Windows if a reset is not performed.

Step 9: Disable the Windows Driver Policy

Starting with the April 2026 non-security update, Windows 11 (24H2 and later) and Windows Server 2025 enforces a kernel policy restricting trust for the cross-signed driver program. If the policy is active, you must disable it, otherwise the driver policy will block your custom PKI-signed drivers.

# Mount the EFI System Partition
mountvol s: /s

# Remove the default Windows kernel policy if present
del s:\EFI\Microsoft\Boot\CiPolicies\Active\{8F9CB695-5D48-48D6-A329-7202B44607E3}.cip

Step 10: Validate the deployment

Test in Audit mode first

Before enforcing the policy, deploy with Audit mode enabled to log policy violations without blocking drivers:

1. Ensure Enabled:Audit Mode is set in the policy <Rules> section.
2. Deploy the policy and restart the device.
3. Review Code Integrity event logs at Applications and Services Logs > Microsoft > Windows > CodeIntegrity.

Validation checklist

• Custom-signed drivers load successfully.
• Unsigned or unauthorized drivers are blocked (in Enforce mode).
• Windows Update and OS servicing flows continue to work.
• Code Integrity event logs show only expected block events.
• The policy is validated on all target hardware configurations before fleet-wide deployment.

Once validation is complete, remove the Enabled:Audit Mode rule option from the policy, re-sign, and deploy to production devices. A clean install of Windows isn't required for policy updates.

Related content

• App Control for Business design guide
• App Control policy rules and file rules
• Deploy App Control policies with script
• Use signed policies to protect App Control against tampering
• WHCP release signature
• Secure Boot overview