In my last blog post Mastering App Control for Business | Part 1: Introduction & Key Concept I introduced the key concept and terms from App Control for Business. In this post I will talk about the policy templates, which already exists in Windows 11, and how the policy XML files are structured and which rule options exist. I used the my preferred editor Visual Studio Code and ConfigCI PowerShell cmdlets to modify the files. However, if you prefer an easier way you should try the community-based tools like App Control Policy Wizard or AppControl Manager · HotCakeX/Harden-Windows-Security Wiki · GitHub which I will describe in a future post.

Most of the information is poorly documented by Microsoft. I gathered a lot of details through discussions with others who are already familiar with App Control for Business. Many things I could only understand by experimenting in my own lab environment.

Previous Blog Posts:

Mastering App Control for Business | Part 1: Introduction & Key Concept

Policy Templates

As I mentioned in my first blog post Mastering App Control for Business | Part 1: Introduction & Key Concept App Control for Business is already included on a Windows 11 22H2 and newer. A good starting point is it to use the existing policy templates that already on your system and modify or extend them with custom rules you needed.

The following Microsoft reference table describes the concerns of each policy templates and where you can find the policy files.

Example: AllowMicrosoft.xml

I will use this policy template to explain the structure and attributes of the policy file. You can find this policy template on your Windows 11 system at:

Block Header Information

This part of the XML file contains some basic information regarding to the policy type, version and unique identifier.

Attributes	Decription
xmlns	XML-Namespace used
PolicyType	Defines the policy type (Base Policy Supplemental Policy)
VersionEx	Is uses for the policy versioning
PolicyID	Unique policy identifier (GUID-Format).
BasePolicyID	If this policy is a base policy then the BasePolicyID is the same as the PolicyID. If the policy is a supplemental policy then the BasePolicyID contains the PolicyID of the base policy to which the supplemental policy rederences.
PlatformID	This attribute identifies the platform where the policy can be applied. At the time of writing this blog post, only one identifier was possible {2E07F7E4-194C-4D20-B7C9-6F44A6C5A234} which identifies the windows platform.

Rule (Security) Options

You can set various security options in base policy and supplemental policies to control the behavior of the policies. In the AllowMicrosoft.xml policy there are the following security options configured:

Before I will show you the possible rule option, let me explain some backgrounds to “User-Mode Code Integrity (UMCI)” in combination with “Kernel-Mode Code Integrity (KMCI)”.

What is user mode?

User Mode is an operating system state with limited access to the system`s hardware and firmware resources. User mode has a lower level of privileges than kernel mode and cannot run specific commands that have negative impact of the stability of the system. User applications, like word, excel, powerpoint, web browsers, and video players, run in user mode.

When you open one of these applications, windows starts a process that gives the app its own separate space in memory. This means that:

• Each app gets its own private memory space that other apps cannot access.
• Apps cannot change or interact with each other’s data in memory
• If one app crashes, it won’t crash the whole system

What is kernel mode?

Kernel mode is an operating system state with unlimited access to system`s hardware and firmware. It is a special privileged mode where the operating system core functions are running. You can say: The kernel mode ist the core part of the operating system that manages everything between software and hardware.

• Kernel mode ensures security by controlling system calls from user mode (apps etc.).
• Kernel mode has access to attached peripheral devices and acts as bride between operating system and hardware (Hardware Abstraction Layer HAL).
• Instead of the user mode, all processes in kernel mode shares the same memory spaces.
• Processes running in kernel modes included the operating system, system processes and some security components.

User Mode and Kernel Mode – Windows drivers | Microsoft Learn

Why kernel mode can be risky?

• If a process crashes in kernel mode, it can affect the entire system.
• For example: If a driver crashes in the kernel mode or cannot executed, it could cause the whole operating system to fail.

What differentiates App Control for Business from the App Locker?

The main functions of App Control for Business run in kernel mode, as I explained above. However you can do a opt-in to enable the user mode (Enabled:UMCI in the following table) support for applications etc. This approach gives us a broader and deeper protection for our systems – but this approach has also a greater impact on the systems stability, if you make mistakes in the configurations.

It is highly recommended to test your policies in audit mode before you enforce the policies.

This is one of the key advantages of App Control for Business over the deprecated App Locker. While App Locker only operates in user mode, App Control for Business provides deeper system-wide protection by working at the kernel mode in default. App Control for Business Policies must be scoped for devices while App Locker policies can be scoped to devices or users.

You can verify the status of user-mode and kernel-mode application control in the system by:

Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | select -Property codeintegrity | fl

• 0 = disabled | not running
• 1 = audit mode
• 2 = enforcement mode

or using msinfo32:

Back to the explanation of the rule option. In the following reference table from Microsoft shows you the possibilities and describes the rule options.

Rule Option	Rule Number	Description	Valid in Supplemental Policies?
Enabled:UMCI	0	Enables User Mode Code Integrity (UMCI), which enforces validation of user-mode executables and scripts. By default, WDAC policies only restrict kernel-mode binaries.	❌ No
Enabled:Boot Menu Protection	1	Currently not supported.	❌ No
Required:WHQL	2	Enforces that all executed drivers must be WHQL-signed (Windows Hardware Quality Labs). This removes support for legacy drivers. Kernel drivers built for Windows 10+ should be WHQL certified.	❌ No
Enabled:Audit Mode	3	Instead of blocking applications, this option logs attempts to run applications, binaries, and scripts that would have been blocked if the policy were enforced. Used for testing before enforcement. To enforce a policy, this option must be removed.	❌ No
Disabled:Flight Signing	4	Prevents execution of Windows Insider builds (binaries signed with flightroot certificates). Useful for organizations that only want to run officially released Windows versions.	❌ No
Enabled:Inherit Default Policy	5	Reserved for future use and has no effect currently.	✅ Yes
Enabled:Unsigned System Integrity Policy (default)	6	Allows the policy to remain unsigned. When removed, all policies must be signed, and trusted update signers must be specified in UpdatePolicySigners.	✅ Yes
Allowed:Debug Policy Augmented	7	Currently not supported.	✅ Yes
Required:EV Signers	8	Requires that all kernel drivers must be WHQL-certified and signed with an Extended Verification (EV) certificate. Ensures drivers originate from verified vendors.	❌ No
Enabled:Advanced Boot Options Menu	9	Enables access to the F8 boot menu, which is disabled by default. While useful for recovery, it can pose a security risk if attackers gain physical access to a device.	❌ No
Enabled:Boot Audit on Failure	10	If the WDAC policy is in enforcement mode and a boot-critical driver fails, WDAC switches to audit mode to allow Windows to load. Logs failures for later troubleshooting.	❌ No
Disabled:Script Enforcement	11	Disables enforcement of scripts, including PowerShell, Windows Script Host (wscript.exe, cscript.exe), HTA files (mshta.exe), and MSXML. Note: Some script hosts behave differently even in audit mode.	❌ No
Required:Enforce Store Applications	12	Ensures that WDAC policies also apply to Universal Windows Platform (UWP) applications from the Microsoft Store.	❌ No
Enabled:Managed Installer	13	Automatically allows applications installed by a managed installer (such as SCCM or Intune). For more details, see Authorize apps deployed with a WDAC managed installer.	✅ Yes
Enabled:Intelligent Security Graph Authorization	14	Automatically trusts applications classified as “known good” by Microsoft’s Intelligent Security Graph (ISG). Helps allow safe applications without explicit approval.	✅ Yes
Enabled:Invalidate EAs on Reboot	15	When Intelligent Security Graph (ISG) authorization is enabled, WDAC marks authorized files with an extended file attribute (EA). This option forces periodic revalidation of these file reputations.	❌ No
Enabled:Update Policy No Reboot	16	Allows future WDAC policy updates to be applied without requiring a system reboot. This option is only supported on Windows 10 1709+ and Windows Server 2019+.	❌ No
Enabled:Allow Supplemental Policies	17	Allows additional WDAC supplemental policies to extend a base policy, rather than requiring a full policy replacement. Supported from Windows 10 1903+ and Windows Server 2022+.	❌ No
Disabled:Runtime FilePath Rule Protection	18	Disables the default runtime check that ensures FilePath rules apply only to administrator-writable locations. (Windows 10 1903+ and Server 2022+ required).	✅ Yes
Enabled:Dynamic Code Security	19	Enforces WDAC policies on .NET applications and dynamically loaded libraries. This option is always enforced if any UMCI policy enables it. No audit mode available. (Windows 10 1803+ and Server 2019+ required.)	❌ No
Enabled:Revoked Expired As Unsigned	20	Treats binaries signed with revoked certificates or expired certificates (that used the Lifetime Signing EKU) as unsigned in enterprise signing scenarios.	❌ No
Enabled:Developer Mode Dynamic Code Trust	–	Allows UWP apps that are debugged in Visual Studio or deployed through Device Portal to be trusted when Developer Mode is enabled.	❌ No

More informations: Understand App Control for Business policy rules and file rules | Microsoft Learn

You can use the rule options by modifying the XML code of the policy file, or you can use the rule numbers to modify the file with powershell or other commandline tools. I will explain which PowerShell commands are useful and how to use them in a future blog post.

As I described above, you can edit the rule options with a PowerShell command:

Set options

Set-RuleOption –FilePath [path to the XML policy] –Option [enter the option number]

Set-RuleOption –FilePath policy.xml –Option 0,1,5

Remove options

Set-RuleOption –FilePath [path to the XML policy] –Option [enter the option number] -delete

Set-RuleOption –FilePath policy.xml –Option 0,1,5 -delete

EKU – Enhanced Key Usages

Extended Key Usage (EKU) is a feature in X.509 certificates that defines what a certificate can be used for. Each EKU is represented by an Object Identifier (OID), which helps identify the purpose of a certificate and who issued it.

The following table describes the possible attributes and their values:

Attributs	Description
ID	Internal ID for referencing in the policies. For example, possible values could be: ID_EKU_STORE ID_EKU_WHQL ID_EKU_WINDOW ID_EKU_ANYCUSTOMINFORMATION
FriendlyName	Friendly Display Name(Windows Store EKU).
Value	This is a internal Microsoft identification for the certificate. This attribute was builded of an encoded OID. The process for this Object Identifier (OID) encoding is detailed explained here: OBJECT IDENTIFIER – Win32 apps | Microsoft Learn

In App Control for Business policies, EKUs act like a whitelist that specifies which functions a certificate is allowed to perform and EKUs are almost linked to a signer rule. If a signer rule contains an EKU that does not exist, the signer rule will be rejected.

In this example above, the signers rule

• Signer ID="ID_SIGNER_STORE"

defines a trusted certification authority named "Microsoft MarketPlace PCA 2011". This CA and their issued certificates are trusted as long as it meet two conditions.

It must be issued by the specified root certificate authority, identified by the following certificate hash (thumbprint):

• <CertRoot Type="TBS" Value="FC9EDE3DCCA09186B2D3BF9B738A2050CB1A554DA2DCADB55F3F72EE17721378" />

Type="TBS" indicates that this is a Thumbprint-based Signature (TBS).

That means that all certificates that have been issued by this CA must have contain the EKU

• <EKU ID="ID_EKU_STORE" FriendlyName="Windows Store EKU - 1.3.6.1.4.1.311.76.3.1 Windows Store" Value="010a2b0601040182374c0301" />

to be valid.

EKUs restrict a certificate’s usage to specific functions. Another example is:

• A certificate issued for code signing cannot be used for Early Launch AntiMalware (ELAM) driver signing, unless it specifically includes the ELAM EKU.
• To be allowed for ELAM driver signing, the certificate must meet specific requirements set by Microsoft.

The object identifier that starts with 1.3.6.1.4.311 is from Microsoft

OID 1.3.6.1.4.1.311 microsoft reference info

Process of encoding the OID

The process of encoding the value attribute in the following line:

EKU ID="ID_EKU_STORE" FriendlyName="Windows Store EKU - 1.3.6.1.4.1.311.76.3.1 Windows Store" Value="010a2b0601040182374c0301" />

isn’t very easy. You can find a detailed explanation for this process in the image bellow.

OBJECT IDENTIFIER – Win32 apps | Microsoft Learn

There are good news: Someone has already created a PowerShell Script to encode this values. Have a look at the GitHub Repository from Matt Greaber.

I will explain, how we can all values with this script an use our example value for this: Value="010a2b0601040182374c0301". Matt Greaber describes in his script that we need to replace the first two digits with ’06’. I’m not exactly sure why but it works :-).

The script from GitHub Repository from Matt Greaber work very well but you have to manually convert the hex code into the byte array. To make this easier, I have created my own PowerShell script which automatically converts the hex code into the byte array.

You can download the scripts from my azure dev ops repo:

• Decode-OID.ps1 – Repos
• Encode-OID.ps1 – Repos

Check digital signature certificate

To demonstrate how to validate a trusted certificate, I chose the Microsoft Store App “Enpass Password Manager” as an example.

You find the relevant files under: “C:\Program Files\WindowsApps\SinewSoftwareSystems.EnpassPasswordManager_6.117.1856.0_neutral_~_fwdy0m65qb6h2\”

File Rules & Signer Rules

You can define file attributes that must be valid so that the files are trusted. This is not recommended but sometime it is needed, if there are not any other possibilities.

Attributes	Description
ID	Internal unique id
FriendlyName	Display Name
FileName	File Name( RefreshPolicy.exe).
MinimumFileVersion	Mminmum file version that is accepted

When applicable, minimum and maximum version numbers in a file rule are referenced as MinimumFileVersion and MaximumFileVersion.

• Both MinimumFileVersion and MaximumFileVersion specified: For Allow rules, file with version greater than or equal to MinimumFileVersion and less than or equal to MaximumFileVersion are allowed. For Deny rules, file with version greater than or equal to MinimumFileVersion and less than or equal to MaximumFileVersion are denied.
• MinimumFileVersion specified without MaximumFileVersion: For Allow rules, file with version greater than or equal to the specified version are allowed to run. For Deny rules, file with version less than or equal to the specified version are blocked.
• MaximumFileVersion specified without MinimumFileVersion: For Allow rules, file with version less than or equal to the specified version are allowed to run. For Deny rules, file with version greater than or equal to the specified version are blocked.

In the following Microsoft reference table for file rules, you can find all possible file rule options:

Rule level	Description
Hash	Specifies individual Authenticode/PE image hash values for each discovered binary. This level is the most specific level, and requires more effort to maintain the current product versions’ hash values. Each time a binary is updated, the hash value changes, therefore requiring a policy update.
FileName	Specifies the original filename for each binary. Although the hash values for an application are modified when updated, the file names are typically not. This level offers less specific security than the hash level, but it doesn’t typically require a policy update when any binary is modified. By default, this level uses the OriginalFileName attribute of the file’s resource header. Use -SpecificFileNameLevel to choose an alternative attribute, such as ProductName.
FilePath	Beginning with Windows 10 version 1903, this level allows binaries to run from specific file path locations. FilePath rules only apply to user mode binaries and can’t be used to allow kernel mode drivers. More information about FilePath level rules can be found later in this article.
SignedVersion	This level combines the publisher rule with a version number. It allows anything to run from the specified publisher with a version at or above the specified version number.
Publisher	This level combines the PcaCertificate level (typically one certificate below the root) and the common name (CN) of the leaf certificate. You can use this rule level to trust a certificate issued by a particular CA and issued to a specific company you trust (such as Intel, for device drivers).
FilePublisher	This level combines the “FileName” attribute of the signed file, plus “Publisher” (PCA certificate with CN of leaf), plus a minimum version number. This option trusts specific files from the specified publisher, with a version at or above the specified version number. By default, this level uses the OriginalFileName attribute of the file’s resource header. Use -SpecificFileNameLevel to choose an alternative attribute, such as ProductName.
LeafCertificate	Adds trusted signers at the individual signing certificate level. The benefit of using this level versus the individual hash level is that new versions of the product have different hash values but typically the same signing certificate. When this level is used, no policy update would be needed to run the new version of the application. However, leaf certificates typically have shorter validity periods than other certificate levels, so the App Control policy must be updated whenever these certificates change.
PcaCertificate	Adds the highest available certificate in the provided certificate chain to signers. This level is typically one certificate below the root because the scan doesn’t resolve the complete certificate chain via the local root stores or with an online check.
RootCertificate	Not supported.
WHQL	Only trusts binaries that were submitted to Microsoft and signed by the Windows Hardware Qualification Lab (WHQL). This level is primarily for kernel binaries.
WHQLPublisher	This level combines the WHQL level and the CN on the leaf certificate, and is primarily for kernel binaries.
WHQLFilePublisher	This level combines the “FileName” attribute of the signed file, plus “WHQLPublisher”, plus a minimum version number. This level is primarily for kernel binaries. By default, this level uses the OriginalFileName attribute of the file’s resource header. Use -SpecificFileNameLevel to choose an alternative attribute, such as ProductName.

File Rules

Hash-Based Rule

This rule allows a specific file hash to be trusted.
It is the most secure method but requires frequent updates since file hashes change with updates.

Allow rule:

<FileRules>
    <FileAttrib ID="ID_FILE_HASH_EXAMPLE" FriendlyName="ExampleApplication.exe HashRule" FileName="ExampleApplication.exe" MinimumFileVersion="1.0.0.0">
        <Hash Type="SHA256" Value="A3F5E9D3C2B1A4E5F6D7A8C9B0E1F2D3A4B5C6D7E8F9A0B1C2D3E4F5A6B7C8D9" />
    </FileAttrib>
</FileRules>

Deny rule:

<FileRules>
    <Deny ID="ID_DENY_FILE_HASH" FriendlyName="Deny ExampleApplication.exe HashRule">
        <Hash Type="SHA256" Value="B3C5D7E9F2A4C6B8D1E3F5A7C9B0E2D4A6F8C1B2D3E5F7A9C0D1E2F3A4B5C6" />
    </Deny>
</FileRules>

Usage:

✔ Best for high-security applications
✔ Useful for ensuring specific binaries are used
❌ Requires frequent policy updates when the application is updated

File Name-Based Rule

This rule allows files by their original file name, making it more flexible than a hash-based rule but also less secure.

Allow rule:

<FileRules>
    <FileAttrib ID="ID_FILE_NAME_ALLOW" FriendlyName="Allow ExampleApplication.exe" FileName="ExampleApplication.exe" />
</FileRules>

Deny rule:

<FileRules>
    <Deny ID="ID_DENY_FILE_NAME" FriendlyName="Deny ExampleApplication.exe" FileName="ExampleApplication.exe" />
</FileRules>

Usage:

✔ Less strict than a hash rule
✔ No need to update policy when the file is updated with the same name
❌ Less security – files with the same name but different content could be allowed

File Path-Based Rule

This rule allows binaries from specific directories. It is useful when restricting apps to secure locations.

Allow rule:

<FileRules>
    <FileAttrib ID="ID_FILE_PATH_EXAMPLE" FriendlyName="ExampleApp FilePathRule" FilePath="C:\Program Files\ExampleApp\" />
</FileRules>

Deny rule:

<FileRules>
    <Deny ID="ID_DENY_FILE_PATH" FriendlyName="Deny Execution from Downloads" FilePath="C:\Users\Public\Downloads\" />
</Deny>
</FileRules>

Usage:

✔ Allows all files within a specific folder
✔ Useful for organizationally managed applications
❌ Less control – allows any file in the specified directory

Signer Rules

Signed Version-Based Rule

Allows execution only if the software publisher and version match the defined parameters.

Allow rule:

<Signers>
    <Signer ID="ID_SIGNER_EXAMPLE" Name="Example Corp">
        <CertRoot Type="PcaCertificate" Value="A1B2C3D4E5F6G7H8I9J0K1L2M3N4O5P6" />
    </Signer>
</Signers>

<FileRules>
    <FileAttrib ID="ID_SIGNED_VERSION_ALLOW" FriendlyName="Allow ExampleApplication.exe Signed Version Rule" 
        FileName="ExampleApplication.exe" MinimumFileVersion="2.0.0.0">
        <SignerRef SignerID="ID_SIGNER_EXAMPLE" />
    </FileAttrib>
</FileRules>

Deny rule:

<Signers>
    <Signer ID="ID_SIGNER_EXAMPLE" Name="Example Corp">
        <CertRoot Type="PcaCertificate" Value="A1B2C3D4E5F6G7H8I9J0K1L2M3N4O5P6" />
    </Signer>
</Signers>

<FileRules>
    <Deny ID="ID_SIGNED_VERSION_DENY" FriendlyName="Deny ExampleApplication.exe Signed Version Rule" 
        FileName="ExampleApplication.exe" MinimumFileVersion="2.0.0.0">
        <SignerRef SignerID="ID_SIGNER_EXAMPLE" />
    </Deny>
</FileRules>

Usage:

✔ Ensures only newer signed versions run
✔ Reduces need for frequent policy updates
✔ Requires valid signing certificate

Publisher-Based Rule

Allows software signed by a specific vendor.

Allow rule:

<Signers>
    <Signer ID="ID_SIGNER_TRUSTED_PUBLISHER" Name="Trusted Publisher">
        <CertRoot Type="PcaCertificate" Value="ABCDEF1234567890ABCDEF1234567890ABCDEF12" />
    </Signer>
</Signers>

<SigningScenarios>
    <SigningScenario Value="12" ID="ID_SIGNINGSCENARIO_ALLOW_TRUSTED_PUBLISHER" FriendlyName="Allow Trusted Publisher">
        <ProductSigners>
            <AllowedSigners>
                <AllowedSigner SignerId="ID_SIGNER_TRUSTED_PUBLISHER" />
            </AllowedSigners>
        </ProductSigners>
    </SigningScenario>
</SigningScenarios>

Deny rule:

<Signers>
    <Signer ID="ID_SIGNER_UNTRUSTED_PUBLISHER" Name="Untrusted Publisher">
        <CertRoot Type="PcaCertificate" Value="1234567890ABCDEF1234567890ABCDEF12345678" />
    </Signer>
</Signers>

<SigningScenarios>
    <SigningScenario Value="12" ID="ID_SIGNINGSCENARIO_DENY_UNTRUSTED_PUBLISHER" FriendlyName="Deny Untrusted Publisher">
        <ProductSigners>
            <DeniedSigners>
                <DeniedSigner SignerId="ID_SIGNER_UNTRUSTED_PUBLISHER" />
            </DeniedSigners>
        </ProductSigners>
    </SigningScenario>
</SigningScenarios>

Usage:

✔ Useful for trusting a vendor (e.g., Microsoft, Adobe)
✔ Ensures only legitimate signed software is executed
❌ If the vendor revokes or updates certificates, the policy needs updating

File Publisher Rule

This rule trusts specific files from a trusted signer with a minimum version.

Allow rule:

<Signers>
    <Signer ID="ID_SIGNER_TRUSTED_PUBLISHER" Name="Trusted Publisher">
        <CertRoot Type="PcaCertificate" Value="ABCDEF1234567890ABCDEF1234567890ABCDEF12" />
    </Signer>
</Signers>

<FileRules>
    <FileAttrib ID="ID_FILE_PUBLISHER_ALLOW" FriendlyName="Allow ExampleApp.exe from Trusted Publisher" 
        FileName="ExampleApp.exe" MinimumFileVersion="1.0.0.0">
        <SignerRef SignerId="ID_SIGNER_TRUSTED_PUBLISHER" />
    </FileAttrib>
</FileRules>

<SigningScenarios>
    <SigningScenario Value="12" ID="ID_SIGNINGSCENARIO_ALLOW_TRUSTED_PUBLISHER" FriendlyName="Allow Trusted Publisher Applications">
        <ProductSigners>
            <AllowedSigners>
                <AllowedSigner SignerId="ID_SIGNER_TRUSTED_PUBLISHER" />
            </AllowedSigners>
            <FileRulesRef>
                <FileRuleRef RuleID="ID_FILE_PUBLISHER_ALLOW" />
            </FileRulesRef>
        </ProductSigners>
    </SigningScenario>
</SigningScenarios>

Deny rule:

<Signers>
    <Signer ID="ID_SIGNER_UNTRUSTED_PUBLISHER" Name="Untrusted Publisher">
        <CertRoot Type="PcaCertificate" Value="FEDCBA0987654321FEDCBA0987654321FEDCBA09" />
    </Signer>
</Signers>

<FileRules>
    <Deny ID="ID_FILE_PUBLISHER_DENY" FriendlyName="Deny MaliciousApp.exe from Untrusted Publisher" 
        FileName="MaliciousApp.exe">
        <SignerRef SignerId="ID_SIGNER_UNTRUSTED_PUBLISHER" />
    </Deny>
</FileRules>

<SigningScenarios>
    <SigningScenario Value="12" ID="ID_SIGNINGSCENARIO_DENY_UNTRUSTED_PUBLISHER" FriendlyName="Deny Untrusted Publisher Applications">
        <ProductSigners>
            <DeniedSigners>
                <DeniedSigner SignerId="ID_SIGNER_UNTRUSTED_PUBLISHER" />
            </DeniedSigners>
            <FileRulesRef>
                <FileRuleRef RuleID="ID_FILE_PUBLISHER_DENY" />
            </FileRulesRef>
        </ProductSigners>
    </SigningScenario>
</SigningScenarios>

Usage:

✔ More specific than a publisher rule
✔ Ensures only the right version of software runs

Leaf Certificate-Based Rule

Allows any software signed with a specific signing certificate.

Allow rule:

<Signers>
    <Signer ID="ID_SIGNER_LEAF_CERT_ALLOW" Name="Trusted Software Certificate">
        <CertRoot Type="LeafCertificate" Value="E1F2D3C4B5A6D7E8F9C0A1B2C3D4E5F6" />
    </Signer>
</Signers>

<SigningScenarios>
    <SigningScenario Value="12" ID="ID_SIGNINGSCENARIO_ALLOW_LEAF_CERT" FriendlyName="Allow Specific Leaf Certificate">
        <ProductSigners>
            <AllowedSigners>
                <AllowedSigner SignerId="ID_SIGNER_LEAF_CERT_ALLOW" />
            </AllowedSigners>
        </ProductSigners>
    </SigningScenario>
</SigningScenarios>

Deny rule:

<Signers>
    <Signer ID="ID_SIGNER_LEAF_CERT_DENY" Name="Untrusted Software Certificate">
        <CertRoot Type="LeafCertificate" Value="F6E5D4C3B2A1D0E9F8C7B6A5D4C3B2A1" />
    </Signer>
</Signers>

<SigningScenarios>
    <SigningScenario Value="12" ID="ID_SIGNINGSCENARIO_DENY_LEAF_CERT" FriendlyName="Block Specific Leaf Certificate">
        <ProductSigners>
            <DeniedSigners>
                <DeniedSigner SignerId="ID_SIGNER_LEAF_CERT_DENY" />
            </DeniedSigners>
        </ProductSigners>
    </SigningScenario>
</SigningScenarios>

Usage:

✔ Allows all versions of software signed with this certificate
❌ You must be up to date. If the certificate expires, the policy must be updated

PCA Certificate-Based Rule

Allows software signed by a specific CA, one level below the root.

Allow rule:

<Signers>
    <Signer ID="ID_SIGNER_PCA_ALLOW" Name="Trusted CA">
        <CertRoot Type="PcaCertificate" Value="B1C2D3E4F5A6B7C8D9E0F1G2H3I4J5K6" />
    </Signer>
</Signers>

<SigningScenarios>
    <SigningScenario Value="12" ID="ID_SIGNINGSCENARIO_ALLOW_PCA_CERT" FriendlyName="Allow Applications Signed by Trusted CA">
        <ProductSigners>
            <AllowedSigners>
                <AllowedSigner SignerId="ID_SIGNER_PCA_ALLOW" />
            </AllowedSigners>
        </ProductSigners>
    </SigningScenario>
</SigningScenarios>

Deny rule:

<Signers>
    <Signer ID="ID_SIGNER_PCA_DENY" Name="Untrusted CA">
        <CertRoot Type="PcaCertificate" Value="Z9Y8X7W6V5U4T3S2R1Q0P9O8N7M6L5K4" />
    </Signer>
</Signers>

<SigningScenarios>
    <SigningScenario Value="12" ID="ID_SIGNINGSCENARIO_DENY_PCA_CERT" FriendlyName="Block Applications Signed by Untrusted CA">
        <ProductSigners>
            <DeniedSigners>
                <DeniedSigner SignerId="ID_SIGNER_PCA_DENY" />
            </DeniedSigners>
        </ProductSigners>
    </SigningScenario>
</SigningScenarios>

Usage:

✔ Ensures only software signed by a particular CA runs
✔ Provides broad trust for corporate-issued certificates

WHQL-Signed Rule

Windows Hardware Quality Labs (WHQL) certification is Microsoft’s validation process for drivers. A WHQL-signed driver means Microsoft has tested and certified it as safe and stable. This rule ensures that only WHQL-certified drivers can load on the system, preventing untrusted or malicious drivers.

Allow rule:

<FileRules>
    <FileAttrib ID="ID_WHQL_EXAMPLE" FriendlyName="WHQL Only Drivers">
        <WHQL />
    </FileAttrib>
</FileRules>

Usage

✔ Enforced in enterprises where only Microsoft-validated drivers should be installed.
✔ Prevents malware-infected drivers from loading at the kernel level.
✔ Reduces risk of crashes due to untrusted or incompatible drivers.

WHQL Publisher Rule

WHQL Publisher Rule allows only WHQL-certified drivers that match a specific publisher’s Common Name (CN). It is more restrictive than the WHQL rule because it ensures that only drivers from a specific vendor are trusted. Example: You might want to allow only Intel-signed WHQL-certified drivers, but not drivers from any other vendor, even if they are WHQL-certified.

✔ Used when only specific vendors’ drivers should be allowed.
✔ Common in large enterprises that standardize hardware vendors (e.g., allowing only Intel-certified drivers for laptops).
✔ Helps prevent unauthorized driver installations from third parties.
✔ Useful in regulated industries where only trusted vendor drivers are allowed.

Allow rule:

<Signers>
    <Signer ID="ID_SIGNER_WHQL_PUBLISHER" Name="WHQL Certified Publisher">
        <CertRoot Type="WHQLPublisher" Value="ZERTIFIKAT_HASH_WERT" />
    </Signer>
</Signers>

<SigningScenarios>
    <SigningScenario Value="12" ID="ID_SIGNINGSCENARIO_ALLOW_WHQL_PUBLISHER" FriendlyName="Allow WHQL Certified Publisher">
        <ProductSigners>
            <AllowedSigners>
                <AllowedSigner SignerId="ID_SIGNER_WHQL_PUBLISHER" />
            </AllowedSigners>
        </ProductSigners>
    </SigningScenario>
</SigningScenarios>

Deny rule:

<Signers>
    <Signer ID="ID_SIGNER_NON_WHQL_PUBLISHER" Name="Non-WHQL Certified Publisher">
        <CertRoot Type="WHQLPublisher" Value="ZERTIFIKAT_HASH_WERT" />
    </Signer>
</Signers>

<SigningScenarios>
    <SigningScenario Value="12" ID="ID_SIGNINGSCENARIO_DENY_NON_WHQL_PUBLISHER" FriendlyName="Deny Non-WHQL Certified Publisher">
        <ProductSigners>
            <DeniedSigners>
                <DeniedSigner SignerId="ID_SIGNER_NON_WHQL_PUBLISHER" />
            </DeniedSigners>
        </ProductSigners>
    </SigningScenario>
</SigningScenarios>

Example Use Cases

Use Case	Example
Restricting GPU drivers	Allow only NVIDIA WHQL-certified drivers, preventing unapproved GPU drivers from running.
Standardizing network drivers	Ensure only Intel-certified NIC drivers are installed across all devices.
Restricting peripheral drivers	Allow only approved keyboard/mouse manufacturers’ WHQL-certified drivers.

Signing Scenarios

Kernel Mode Code Integrity (KMCI)

Kernel-Mode Code Integrity (KMCI) prevents the loading of unsigned, modified, or untrusted kernel-mode drivers. This is crucial because the kernel operates at the highest privilege level, and a compromised driver can allow full system takeover.

In App Control for Business, KMCI is enforced using a signing scenario with Value="131". This means that only pre-approved, signed kernel drivers can be loaded.

For example, the following policy ensures that only Microsoft-certified kernel-mode drivers can load:

<!-- Lernel Mode Signing Scenario -->
  <SigningScenarios>
    <!-- Kernel Mode Signing Scenario -->
    <SigningScenario Value="131" ID="ID_SIGNINGSCENARIO_KMCI" FriendlyName="Kernel Mode Signing Scenario">
      <ProductSigners>
        <AllowedSigners>
          <AllowedSigner SignerId="ID_SIGNER_MICROSOFT_PRODUCT_1997" />
          <AllowedSigner SignerId="ID_SIGNER_MICROSOFT_PRODUCT_2001" />
        </AllowedSigners>
      </ProductSigners>
    </SigningScenario>

User Mode Code Integrity (UMCI)

While KMCI secures the kernel, UMCI Value="12"enforces security at the application and script execution level.

UMCI ensures that:

• Only signed, approved executables can run.
• PowerShell, JavaScript, and VBScript execution is restricted to trusted sources.
• Scripting attacks and unsigned applications are blocked.

<!-- User Mode Signing Scenario -->
    <SigningScenario Value="12" ID="ID_SIGNINGSCENARIO_UMCI" FriendlyName="User Mode Signing Scenario">
      <ProductSigners>
        <AllowedSigners>
          <AllowedSigner SignerId="ID_SIGNER_MICROSOFT_PRODUCT_1997_UMCI" />
          <AllowedSigner SignerId="ID_SIGNER_MICROSOFT_PRODUCT_2001_UMCI" />
        </AllowedSigners>
      </ProductSigners>
    </SigningScenario>
  </SigningScenarios>

This ensures that only applications from trusted sources (e.g., Microsoft Store, signed vendors) can run.

Update Policy Signers

​In Application Control for Business, the Enabled:Unsigned System Integrity Policy rule option (Option 6) (have a look under: Rule (Security) Options) determines whether a policy must be signed. When this option is enabled, the policy can remain unsigned, allowing for easier testing and deployment during initial configurations. However, keeping policies unsigned may expose them to tampering.

To enhance security, it’s recommended to disable the Enabled:Unsigned System Integrity Policy option. This action enforces that the policy must be signed with a trusted code-signing certificate. When transitioning to signed policies, it’s crucial to specify which certificates are authorized to update the policy in the future. This is achieved by populating the <UpdatePolicySigners> s

<UpdatePolicySigners>
    <Signer ID="ID_SIGNER_IT_ADMIN" Name="Corporate IT Security Administrator">
        <CertRoot Type="CustomCodeCertificate" Value="ABCDEF1234567890ABCDEF1234567890ABCDEF12" />
    </Signer>
</UpdatePolicySigners>

Allow vs. deny rules

App Control has a built-in rule processing order to handle file rule conflicts. It first checks all deny rules and applies them. Then, it processes any allow rules. If no deny or allow rule exists, App Control looks for a Managed Installer approval, if the policy allows it. If none is found, it falls back to the Intelligent Security Graph (ISG), if permitted by the policy.

Note:
To keep your App Control policies clear and easy to manage, I recommend using separate ALLOW and DENY policies on Windows versions that support multiple App Control policies.

Policy with example values

<?xml version="1.0" encoding="utf-8"?>
<SiPolicy xmlns="urn:schemas-microsoft-com:sipolicy" PolicyType="Base Policy">

    <!-- Policy Metadata -->
    <VersionEx>1.0</VersionEx>  <!-- Policy version -->
    <PolicyID>{12345678-90AB-CDEF-1234-567890ABCDEF}</PolicyID>  <!-- Unique Policy Identifier -->
    <BasePolicyID>{12345678-90AB-CDEF-1234-567890ABCDEF}</BasePolicyID>  <!-- If inheriting from another policy -->
    <PlatformID>{2E07F7E4-194C-4D20-BDF9-6F44A6C5A234}</PlatformID>  <!-- Target platform (Windows) -->

    <!-- Enabled Rules (Security Options) -->
    <Rules>
        <Rule><Option>Enabled:Unsigned System Integrity Policy</Option></Rule>  <!-- Allows unsigned policies -->
        <Rule><Option>Enabled:Advanced Boot Options Menu</Option></Rule>  <!-- Enables F8 Boot Menu -->
        <Rule><Option>Enabled:UMCI</Option></Rule>  <!-- Enables User Mode Code Integrity (UMCI) -->
        <Rule><Option>Enabled:Inherit Default Policy</Option></Rule>  <!-- Inherits from a base policy -->
        <Rule><Option>Enabled:Update Policy No Reboot</Option></Rule>  <!-- Allows policy updates without reboot -->
        <Rule><Option>Enabled:Dynamic Code Security</Option></Rule>  <!-- Blocks unsigned, dynamically loaded code -->
        <Rule><Option>Enabled:Revoked Expired As Unsigned</Option></Rule>  <!-- Treats revoked/expired certs as unsigned -->
        <Rule><Option>Enabled:Allow Supplemental Policies</Option></Rule>  <!-- Allows additional policies to extend this one -->
    </Rules>

    <!-- Extended Key Usages (EKUs) for certificate verification -->
    <EKUs>
        <EKU ID="ID_EKU_WHQL" Value="010A2B0601040182370A0305" />  <!-- WHQL (Windows Hardware Quality Labs) EKU -->
        <EKU ID="ID_EKU_WINDOWS" Value="010A2B0601040182370A0306" />  <!-- Microsoft Windows EKU -->
    </EKUs>

    <!-- File-Based Rules -->
    <FileRules>
        <!-- 1. Hash-Based Rule: Allows execution based on a specific file hash -->
        <FileAttrib ID="ID_FILE_HASH_ALLOW" FriendlyName="Allow ExampleApplication.exe HashRule">
            <Hash Type="SHA256" Value="A3F5E9D3C2B1A4E5F6D7A8C9B0E1F2D3A4B5C6D7E8F9A0B1C2D3E4F5A6B7C8D9" />
        </FileAttrib>

        <!-- 2. File Name-Based Rule: Allows execution of a file based on its name -->
        <FileAttrib ID="ID_FILE_NAME_ALLOW" FriendlyName="Allow ExampleApplication.exe" FileName="ExampleApplication.exe" />

        <!-- 3. File Path-Based Rule: Allows execution of any file within a specific directory -->
        <FileAttrib ID="ID_FILE_PATH_ALLOW" FriendlyName="Allow files in ExampleApp folder" FilePath="C:\Program Files\ExampleApp\" />

        <!-- 4. Signed Version-Based Rule: Allows only signed versions equal to or higher than a specific version -->
        <FileAttrib ID="ID_SIGNED_VERSION_ALLOW" FriendlyName="Allow ExampleApp Signed Version"
            FileName="ExampleApplication.exe" MinimumFileVersion="2.0.0.0">
            <SignerRef SignerID="ID_SIGNER_TRUSTED" />
        </FileAttrib>

        <!-- 6. File Publisher-Based Rule: Allows execution of a specific file from a specific trusted publisher -->
        <FileAttrib ID="ID_FILE_PUBLISHER_ALLOW" FriendlyName="Allow ExampleApp from Trusted Publisher"
            FileName="ExampleApplication.exe" MinimumFileVersion="3.0.0.0">
            <SignerRef SignerID="ID_SIGNER_TRUSTED" />
        </FileAttrib>
    </FileRules>

    <!-- Signer-Based Rules -->
    <Signers>
        <!-- 5. Publisher-Based Rule: Allows all software signed by a trusted publisher -->
        <Signer ID="ID_SIGNER_ALLOW" Name="Trusted Corp">
            <CertRoot Type="PcaCertificate" Value="A1B2C3D4E5F6G7H8I9J0K1L2M3N4O5P6" />
        </Signer>

        <!-- 7. Leaf Certificate-Based Rule: Allows software signed with a specific certificate -->
        <Signer ID="ID_SIGNER_LEAF_ALLOW" Name="Trusted Software Certificate">
            <CertRoot Type="LeafCertificate" Value="E1F2D3C4B5A6D7E8F9C0A1B2C3D4E5F6" />
        </Signer>

        <!-- 8. PCA Certificate-Based Rule: Allows software signed by a specific Certificate Authority -->
        <Signer ID="ID_SIGNER_PCA_ALLOW" Name="Trusted CA">
            <CertRoot Type="PcaCertificate" Value="B1C2D3E4F5A6B7C8D9E0F1G2H3I4J5K6" />
        </Signer>

        <!-- 9. WHQL-Signed Rule: Allows only WHQL-certified drivers -->
        <Signer ID="ID_SIGNER_WHQL_ALLOW" Name="WHQL Certified Drivers">
            <CertRoot Type="WHQLPublisher" Value="C1D2E3F4G5A6B7C8D9E0F1H2I3J4K5L6" />
        </Signer>

        <!-- 10. WHQL Publisher-Based Rule: Allows WHQL-certified drivers from a specific vendor -->
        <Signer ID="ID_SIGNER_WHQL_VENDOR_ALLOW" Name="Intel WHQL Publisher">
            <CertRoot Type="WHQLPublisher" Value="D1E2F3G4H5A6B7C8D9E0F1J2K3L4M5N6" />
        </Signer>
    </Signers>

    <!-- Signing Scenarios -->
    <SigningScenarios>
        <!-- Scenario to allow execution of applications from trusted publishers -->
        <SigningScenario Value="12" ID="ID_SIGNINGSCENARIO_TRUSTED_PUBLISHER" FriendlyName="Allow Trusted Publishers">
            <ProductSigners>
                <AllowedSigners>
                    <AllowedSigner SignerId="ID_SIGNER_ALLOW" />
                    <AllowedSigner SignerId="ID_SIGNER_LEAF_ALLOW" />
                    <AllowedSigner SignerId="ID_SIGNER_PCA_ALLOW" />
                    <AllowedSigner SignerId="ID_SIGNER_WHQL_ALLOW" />
                    <AllowedSigner SignerId="ID_SIGNER_WHQL_VENDOR_ALLOW" />
                </AllowedSigners>
            </ProductSigners>
        </SigningScenario>

        <!-- Scenario enforcing file-based rules -->
        <SigningScenario Value="12" ID="ID_SIGNINGSCENARIO_TRUSTED_FILES" FriendlyName="Trusted Files">
            <ProductSigners>
                <FileRulesRef>
                    <FileRuleRef RuleID="ID_FILE_HASH_ALLOW" />
                    <FileRuleRef RuleID="ID_FILE_NAME_ALLOW" />
                    <FileRuleRef RuleID="ID_FILE_PATH_ALLOW" />
                    <FileRuleRef RuleID="ID_SIGNED_VERSION_ALLOW" />
                    <FileRuleRef RuleID="ID_FILE_PUBLISHER_ALLOW" />
                </FileRulesRef>
            </ProductSigners>
        </SigningScenario>
    </SigningScenarios>

</SiPolicy>