Mastering App Control for Business#

Part 2: Policy Templates & Rule Options#

Table of Contents#

Policy Templates
Block Header Information
Rule (Security) Options
EKU — Enhanced Key Usages
File Rules & Signer Rules
Signing Scenarios
Update Policy Signers
Allow vs. Deny Rule Processing Order
Complete Example Policy XML

1. Policy Templates#

Microsoft ships a set of example base policies with Windows and the WDAC Wizard. These serve as starting points for creating custom policies rather than writing from scratch.

Base Policy Reference Table#

Policy File	Description	Primary Path(s)
*DefaultWindows_.xml**	Allows Windows components, third-party hardware/software kernel drivers, and Store apps. Basis for Intune deployments.	`%OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\DefaultWindows_.xml` and `%ProgramFiles%\WindowsApps\Microsoft.WDAC.WDACWizard\Templates\DefaultWindows_*.xml`
AllowMicrosoft.xml	Extends DefaultWindows with Microsoft product root certificate rules.	Same path pattern as DefaultWindows_*.xml
AllowAll.xml	Permits everything. Useful as the base for blocklist-only policies — all block policies include this file plus explicit DENY rules.	`ExamplePolicies\AllowAll.xml`
AllowAll_EnableHVCI.xml	Enables memory integrity (HVCI) enforcement via App Control.	`ExamplePolicies\AllowAll_EnableHVCI.xml`
DenyAllAudit.xml	WARNING: Causes boot issues on Windows Server 2019 and earlier. Use in audit mode only, for tracking binaries on critical systems.	`ExamplePolicies\DenyAllAudit.xml`
Microsoft Configuration Manager	Policy XML generated by MECM’s built-in App Control integration.	`%OSDrive%\Windows\CCM\DeviceGuard` on managed endpoint
SmartAppControl.xml	Based on Smart App Control; designed for lightly managed systems. Contains one unsupported rule that must be removed before enterprise use. See Use the Smart App Control policy in Microsoft docs.	`ExamplePolicies\SmartAppControl.xml` and `WDACWizard*\Templates\SignedReputable.xml`
DefaultWindows_Supplemental.xml	Example supplemental policy showing how to extend DefaultWindows_Audit.xml to allow a single Microsoft-signed file.	`ExamplePolicies\DefaultWindows_Supplemental.xml`
Microsoft Recommended Block List	Windows and Microsoft-signed code that Microsoft recommends blocking.	`WDACWizard*\Templates\Recommended_UserMode_Blocklist.xml`
Microsoft recommended driver blocklist	Blocks known vulnerable and malicious kernel drivers.	Microsoft recommended driver block rules docs, `ExamplePolicies\RecommendedDriverBlock_Enforced.xml`, and `WDACWizard*\Templates\Recommended_Driver_Blocklist.xml`
Windows S mode	Enforcement rules for Windows S mode.	`WDACWizard*\Templates\WinSiPolicy.xml.xml`
Windows 11 SE	Enforcement rules for Windows 11 SE (education/schools).	`WDACWizard*\Templates\WinSEPolicy.xml.xml`

Recommendation: Always start from a Microsoft-provided template rather than authoring a policy from scratch. The DefaultWindows or AllowMicrosoft templates are the recommended starting points for most enterprise deployments.

flowchart TD
    A[Start: Choose a Template] --> B{Use Case?}
    B -->|Lightly managed\nConsumer-like| C[SmartAppControl.xml\nSigned + Reputable]
    B -->|Standard enterprise| D[DefaultWindows.xml\nWindows + Store + HW drivers]
    B -->|Microsoft software trust| E[AllowMicrosoft.xml\nAll Microsoft signed]
    B -->|Build a blocklist| F[AllowAll.xml\nBlock specific bad code]
    B -->|Audit everything first| G[DenyAllAudit.xml\nAudit mode only — not Server 2019]
    C & D & E --> H[Extend with\nSupplemental Policies]
    F --> I[Add DENY rules\nfor specific threats]
    style C fill:#14532d,color:#86efac
    style D fill:#1e3a5f,color:#93c5fd
    style E fill:#1e3a5f,color:#93c5fd
    style G fill:#3b1515,color:#fca5a5

2. Block Header Information#

Every App Control policy XML begins with a <SiPolicy> root element whose attributes define the policy’s identity and behavior. The table below documents the key attributes using AllowMicrosoft.xml as the reference structure.

XML Header Attributes#

Attribute	Purpose
xmlns	XML namespace used by the policy schema
PolicyType	Defines the policy type: `Base Policy` or `Supplemental Policy`
VersionEx	Policy version string — used for tracking and update management
PolicyID	Unique policy identifier in GUID format. No two active policies on a system may share the same PolicyID
BasePolicyID	For base policies, this is identical to PolicyID. For supplemental policies, this contains the PolicyID of the parent base policy
PlatformID	Identifies the target platform. Currently only one valid identifier exists: `{2E07F7E4-194C-4D20-B7C9-6F44A6C5A234}` (Windows)

3. Rule (Security) Options#

User Mode vs. Kernel Mode#

Understanding execution modes is essential for configuring App Control policy rule options correctly.

User Mode#

Limited access to hardware and firmware
Lower privilege level than kernel mode
Runs standard user applications: Word, Excel, browsers, video players
Each application receives a private memory space
Applications cannot access each other’s data
A crash in one application does not crash the system

Kernel Mode#

Unlimited access to hardware and firmware
OS core functions execute here
Controls and mediates system calls from user-mode processes
Includes the Hardware Abstraction Layer (HAL) — the bridge between the OS and hardware
All kernel-mode processes share the same memory space
Includes the OS, system processes, and certain security components
A crash in a kernel-mode process can affect the entire system

Key Differentiator from AppLocker#

Characteristic	App Control for Business	AppLocker
Default enforcement level	Kernel mode	User mode only
Opt-in to user mode	Yes — via `Enabled:UMCI` rule option	N/A
Policy scope	Device-scoped only	Device or user scoped
Protection depth	Deeper — kernel-level by default	Shallower — user-level only

flowchart TD
    subgraph KM["Kernel Mode (Ring 0)"]
        direction LR
        OS[Operating System Core]
        DRV[Drivers]
        CI[Code Integrity CI]
        HAL[Hardware Abstraction Layer]
    end
    subgraph UM["User Mode (Ring 3)"]
        direction LR
        WORD[Word / Excel]
        BROWSER[Browsers]
        SCRIPTS[PowerShell / Scripts]
        APPS[User Applications]
    end
    HW[Hardware] <--> KM
    KM <-->|System Calls\nControlled Interface| UM
    CI -->|Enforces KMCI| DRV
    CI -->|Enforces UMCI\nopt-in via Option 0| APPS
    style KM fill:#1a0a2e,color:#c4b5fd,stroke:#7c3aed
    style UM fill:#0a1628,color:#93c5fd,stroke:#2563eb
    style CI fill:#162032,color:#58a6ff

Verify UMCI / KMCI Status#

Use the following PowerShell command to check the current code integrity enforcement status:

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

Returned values:

Value	Meaning
`0`	Disabled / not running
`1`	Audit mode
`2`	Enforcement mode

Rule Options Reference Table#

All 21 rule options available in App Control for Business policies are documented below.

Rule Option	Rule Number	Description	Valid in Supplemental Policies?
Enabled	0	Enables User Mode Code Integrity — validates user-mode executables and scripts. By default, ACfB only restricts kernel-mode binaries.	No
Enabled Menu Protection	1	Currently not supported.	No
Required	2	All drivers must be WHQL-signed. Removes legacy driver support. Kernel drivers for Windows 10+ should be WHQL certified.	No
Enabled Mode	3	Logs attempts to run applications, binaries, and scripts that would be blocked in enforced mode. Must be removed to enforce the policy.	No
Disabled Signing	4	Prevents execution of Windows Insider builds (flightroot-signed binaries). For organizations that want only released Windows versions in production.	No
Enabled Default Policy	5	Reserved for future use. No current effect.	Yes
Enabled System Integrity Policy (default)	6	Allows unsigned policies to be deployed. When removed, all policies must be signed and `UpdatePolicySigners` must be specified.	Yes
Allowed Policy Augmented	7	Currently not supported.	Yes
Required Signers	8	Requires kernel drivers to be WHQL-certified and signed with an Extended Verification (EV) certificate.	No
Enabled Boot Options Menu	9	Enables the F8 boot menu (disabled by default in enforced policies). Useful for recovery scenarios but introduces a physical-access security risk.	No
Enabled Audit on Failure	10	If an enforcement-mode policy causes a boot-critical driver failure, automatically switches to audit mode to allow Windows to load. Failures are logged.	No
Disabled Enforcement	11	Disables enforcement of scripts including PowerShell, wscript.exe, cscript.exe, mshta.exe, and MSXML. Note: some script hosts behave differently even in audit mode.	No
Required Store Applications	12	ACfB policies also apply to UWP applications from the Microsoft Store.	No
Enabled Installer	13	Automatically trusts applications installed by a configured managed installer (SCCM, Intune).	Yes
Enabled Security Graph Authorization	14	Automatically trusts applications classified as “known good” by the Microsoft Intelligent Security Graph (ISG).	Yes
Enabled EAs on Reboot	15	When ISG authorization is enabled, forces periodic revalidation of file reputations by clearing extended file attributes on reboot.	No
Enabled Policy No Reboot	16	Allows policy updates to apply without a system reboot. Requires Windows 10 1709+ or Server 2019+.	No
Enabled Supplemental Policies	17	Enables supplemental policies to extend the base policy without requiring a full policy replacement. Requires Windows 10 1903+ or Server 2022+.	No
Disabled FilePath Rule Protection	18	Disables the default runtime check that restricts FilePath rules to admin-writable locations only. Requires Windows 10 1903+ or Server 2022+.	Yes
Enabled Code Security	19	Enforces ACfB on .NET applications and dynamically loaded libraries. Always enforced if any UMCI policy enables it. No audit mode available. Requires Windows 10 1803+ or Server 2019+.	No
Enabled Expired As Unsigned	20	Treats binaries signed with revoked certificates or certificates with a Lifetime Signing EKU that have expired as unsigned — relevant in enterprise signing scenarios.	No
Enabled Mode Dynamic Code Trust	—	Allows UWP applications debugged in Visual Studio or deployed via Device Portal to be trusted when Developer Mode is active on the device.	No

flowchart LR
    O0[Option 0\nUMCI Enabled] --> FULL[Full User+Kernel\nProtection]
    O2[Option 2\nRequire WHQL] --> DRVR[Only Certified\nDrivers Load]
    O3[Option 3\nAudit Mode] -->|Remove before prod| ENF[Enforcement Mode]
    O6[Option 6\nUnsigned Policy] -->|Remove + sign| SIGNED[Signed Policy\nTamper-proof]
    O13[Option 13\nManaged Installer] --> MI[Intune-deployed Apps\nAuto-trusted]
    O14[Option 14\nISG] --> REP[Good-reputation Apps\nAuto-trusted]
    O17[Option 17\nAllow Supplemental] --> SUPP[Supplemental Policies\nCan extend base]
    style FULL fill:#14532d,color:#86efac
    style SIGNED fill:#14532d,color:#86efac
    style ENF fill:#14532d,color:#86efac

Setting and Removing Rule Options via PowerShell#

1
# Set options (add to policy)
2
Set-RuleOption -FilePath policy.xml -Option 0,1,5
3

4
# Remove options (delete from policy)
5
Set-RuleOption -FilePath policy.xml -Option 0,1,5 -delete

4. EKU — Enhanced Key Usages#

Enhanced Key Usage (EKU) is an X.509 certificate extension that defines what a certificate is authorized to do. Each EKU is identified by an Object Identifier (OID).

EKU Attributes#

Attribute	Description
ID	Internal ID for referencing the EKU within policies (e.g., `ID_EKU_STORE`, `ID_EKU_WHQL`, `ID_EKU_WINDOW`, `ID_EKU_ANYCUSTOMINFORMATION`)
FriendlyName	Human-readable display name (e.g., `Windows Store EKU`)
Value	Internal Microsoft identifier built from an encoded OID. Reference: OBJECT IDENTIFIER – Win32 apps \| Microsoft Learn

How EKUs Work with Signer Rules#

EKUs act as a whitelist defining the functions a certificate is permitted to perform. In ACfB policy XML:

EKUs are almost always linked to a signer rule
If a signer rule references an EKU that does not exist in the policy, the signer rule is rejected

Example: A signer rule for ID_SIGNER_STORE defines the trusted CA Microsoft MarketPlace PCA 2011. A certificate from this CA is trusted only if:

It is issued by a root CA with TBS hash: FC9EDE3DCCA09186B2D3BF9B738A2050CB1A554DA2DCADB55F3F72EE17721378
The certificate contains EKU ID_EKU_STORE with Value="010a2b0601040182374c0301"

OID Namespace#

OIDs beginning with 1.3.6.1.4.311 are from Microsoft. The authoritative Microsoft reference OID is 1.3.6.1.4.1.311.

OID Encoding Process#

The Value attribute (e.g., 010a2b0601040182374c0301) is derived from the encoded OID. The full encoding process is documented at: OBJECT IDENTIFIER – Win32 apps | Microsoft Learn.

When decoding with Matt Greaber’s script, replace the first two digits of the encoded value with 06 before processing.

PowerShell Encode / Decode Scripts#

The following scripts are available from the blog author’s Azure DevOps repository:

Decode-OID.ps1 — decodes an encoded OID value back to its dotted-decimal form
Encode-OID.ps1 — encodes a dotted-decimal OID to the ACfB policy value format

sequenceDiagram
    participant App as Application Binary
    participant CI as Code Integrity
    participant CHAIN as Certificate Chain
    participant EKU as EKU Validator
    participant POLICY as ACfB Policy

    App->>CI: Request to execute
    CI->>CHAIN: Extract signing certificate chain
    CHAIN-->>CI: Leaf → PCA → Root
    CI->>EKU: Check Extended Key Usage OIDs
    EKU->>POLICY: Does signer rule reference this EKU?
    POLICY-->>EKU: Match found (ID_EKU_STORE)
    EKU-->>CI: EKU valid
    CI->>POLICY: Check CertRoot TBS hash
    POLICY-->>CI: Hash matches trusted CA
    CI-->>App: ALLOW execution

5. File Rules & Signer Rules#

File Rules Overview#

File rules define the file attributes that must be valid for a file to be trusted by the policy.

File Rule Attributes#

Attribute	Description
ID	Internal unique identifier for the rule
FriendlyName	Human-readable display name
FileName	The file name to match (e.g., `RefreshPolicy.exe`)
MinimumFileVersion	Minimum accepted file version for the rule to apply

File Version Range Logic#

Condition	Behavior
Both Min and Max specified	Allow/Deny files where version >= Min AND <= Max
Min only	Allow files >= Min; Deny files <= Min
Max only	Allow files <= Max; Deny files >= Max

File Rule Levels#

Rule Level	Description
Hash	Authenticode/PE image hash per binary. Most specific, highest maintenance — hash changes on every application update.
FileName	Matches on original filename. Less specific than hash. Typically no policy update required when the binary updates. Uses `OriginalFileName` by default; use `-SpecificFileNameLevel` to match on alternatives such as `ProductName`.
FilePath	Allows binaries from specific paths. Requires Windows 10 1903+. User mode only — cannot allow kernel drivers via this level.
SignedVersion	Publisher rule combined with a minimum version number.
Publisher	PCA certificate + CN of leaf certificate. Trusts all files from a specific CA issued to a specific company.
FilePublisher	FileName + Publisher + minimum version. Trusts specific files from a specific publisher at or above a specified version. Uses `OriginalFileName` by default.
LeafCertificate	Matches on the individual signing certificate. No policy update needed for new app versions using the same cert; however, leaf certs have shorter validity periods.
PcaCertificate	Highest available certificate in the chain below the root. The scan does not resolve the full chain online.
RootCertificate	Not supported.
WHQL	Trusts only binaries submitted to and signed by the Windows Hardware Qualification Lab. Primarily used for kernel binaries.
WHQLPublisher	WHQL + CN on leaf certificate. Primarily for kernel binaries.
WHQLFilePublisher	FileName + WHQLPublisher + minimum version. Primarily for kernel binaries.

quadrantChart
    title File Rule Levels — Security vs Maintenance Effort
    x-axis Low Maintenance --> High Maintenance
    y-axis Low Security --> High Security
    quadrant-1 Ideal
    quadrant-2 Secure but costly
    quadrant-3 Avoid
    quadrant-4 Easy but risky
    Hash: [0.9, 0.95]
    FilePublisher: [0.55, 0.85]
    SignedVersion: [0.5, 0.7]
    LeafCertificate: [0.45, 0.65]
    Publisher: [0.2, 0.55]
    WHQL: [0.15, 0.8]
    FileName: [0.1, 0.2]
    FilePath: [0.1, 0.15]

Hash-Based Rule#

Use: Best for high-security environments where only exact, known-good binaries must run. Requires frequent policy updates whenever applications are updated, as the hash changes with every file modification.

1
<FileRules>
2
    <FileAttrib ID="ID_FILE_HASH_EXAMPLE" FriendlyName="ExampleApplication.exe HashRule"
3
        FileName="ExampleApplication.exe" MinimumFileVersion="1.0.0.0">
4
        <Hash Type="SHA256" Value="A3F5E9D3C2B1A4E5F6D7A8C9B0E1F2D3A4B5C6D7E8F9A0B1C2D3E4F5A6B7C8D9" />
5
    </FileAttrib>
6
</FileRules>
7

8
<FileRules>
9
    <Deny ID="ID_DENY_FILE_HASH" FriendlyName="Deny ExampleApplication.exe HashRule">
10
        <Hash Type="SHA256" Value="B3C5D7E9F2A4C6B8D1E3F5A7C9B0E2D4A6F8C1B2D3E5F7A9C0D1E2F3A4B5C6" />
11
    </Deny>
12
</FileRules>

File Name-Based Rule#

Use: Less strict than hash. No policy update needed when the file updates as long as the filename is unchanged. Less secure — a different binary with the same filename could be permitted.

1
<FileRules>
2
    <FileAttrib ID="ID_FILE_NAME_ALLOW" FriendlyName="Allow ExampleApplication.exe"
3
        FileName="ExampleApplication.exe" />
4
</FileRules>
5

6
<FileRules>
7
    <Deny ID="ID_DENY_FILE_NAME" FriendlyName="Deny ExampleApplication.exe"
8
        FileName="ExampleApplication.exe" />
9
</FileRules>

File Path-Based Rule#

Use: Permits all files within a specific folder path. Provides low administrative overhead but offers less control — any file placed in the allowed directory will be permitted to run.

1
<FileRules>
2
    <FileAttrib ID="ID_FILE_PATH_EXAMPLE" FriendlyName="ExampleApp FilePathRule"
3
        FilePath="C:\Program Files\ExampleApp\" />
4
</FileRules>
5

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

Signed Version-Based Rule#

Use: Ensures only newer, signed versions of an application can run. Reduces policy update frequency compared to hash rules. Requires a valid signing certificate throughout the software lifecycle.

1
<Signers>
2
    <Signer ID="ID_SIGNER_EXAMPLE" Name="Example Corp">
3
        <CertRoot Type="PcaCertificate" Value="A1B2C3D4E5F6G7H8I9J0K1L2M3N4O5P6" />
4
    </Signer>
5
</Signers>
6

7
<FileRules>
8
    <FileAttrib ID="ID_SIGNED_VERSION_ALLOW" FriendlyName="Allow ExampleApplication.exe Signed Version Rule"
9
        FileName="ExampleApplication.exe" MinimumFileVersion="2.0.0.0">
10
        <SignerRef SignerID="ID_SIGNER_EXAMPLE" />
11
    </FileAttrib>
12
</FileRules>

Publisher-Based Rule#

Use: Trusts all software signed by a specific vendor (e.g., Microsoft, Adobe). Broad trust for a known publisher. If the vendor rotates or updates their signing certificates, the policy requires updating.

1
<Signers>
2
    <Signer ID="ID_SIGNER_TRUSTED_PUBLISHER" Name="Trusted Publisher">
3
        <CertRoot Type="PcaCertificate" Value="ABCDEF1234567890ABCDEF1234567890ABCDEF12" />
4
    </Signer>
5
</Signers>
6

7
<SigningScenarios>
8
    <SigningScenario Value="12" ID="ID_SIGNINGSCENARIO_ALLOW_TRUSTED_PUBLISHER"
9
        FriendlyName="Allow Trusted Publisher">
10
        <ProductSigners>
11
            <AllowedSigners>
12
                <AllowedSigner SignerId="ID_SIGNER_TRUSTED_PUBLISHER" />
13
            </AllowedSigners>
14
        </ProductSigners>
15
    </SigningScenario>
16
</SigningScenarios>

File Publisher Rule#

Use: The most recommended rule level for precision. Combines FileName + Publisher + minimum version — trusts only a specific file from a specific publisher at or above a specific version.

1
<Signers>
2
    <Signer ID="ID_SIGNER_FILEPUBLISHER" Name="Example Corp Publisher">
3
        <CertRoot Type="PcaCertificate" Value="ABCDEF1234567890ABCDEF1234567890ABCDEF12" />
4
        <FileAttribRef RuleID="ID_FILE_FILEPUBLISHER_ALLOW" />
5
    </Signer>
6
</Signers>
7

8
<FileRules>
9
    <FileAttrib ID="ID_FILE_FILEPUBLISHER_ALLOW" FriendlyName="Allow ExampleApp.exe FilePublisher"
10
        FileName="ExampleApplication.exe" MinimumFileVersion="2.0.0.0" />
11
</FileRules>
12

13
<Signers>
14
    <Signer ID="ID_SIGNER_FILEPUBLISHER_DENY" Name="Denied Publisher">
15
        <CertRoot Type="PcaCertificate" Value="FEDCBA9876543210FEDCBA9876543210FEDCBA98" />
16
        <FileAttribRef RuleID="ID_FILE_FILEPUBLISHER_DENY" />
17
    </Signer>
18
</Signers>
19

20
<FileRules>
21
    <Deny ID="ID_FILE_FILEPUBLISHER_DENY" FriendlyName="Deny DeniedApp.exe FilePublisher"
22
        FileName="DeniedApplication.exe" MinimumFileVersion="0.0.0.0" />
23
</FileRules>

Leaf Certificate-Based Rule#

Use: Allows any software signed with a specific individual signing certificate. No policy update is required for new application versions as long as the same certificate is used. However, leaf certificates have shorter validity periods than CA certificates — the policy must be updated when the certificate expires.

1
<Signers>
2
    <Signer ID="ID_SIGNER_LEAF" Name="Example Leaf Certificate Signer">
3
        <CertRoot Type="LeafCertificate" Value="ABCDEF1234567890ABCDEF1234567890ABCDEF12" />
4
    </Signer>
5
</Signers>

PCA Certificate-Based Rule#

Use: Trusts all software signed by a specific Certificate Authority at the PCA level — one level below the root in the certificate chain. Provides broad trust for all certificates issued by a corporate or vendor CA. The policy scan does not resolve the full chain online.

1
<Signers>
2
    <Signer ID="ID_SIGNER_PCA" Name="Corporate CA Signer">
3
        <CertRoot Type="PcaCertificate" Value="ABCDEF1234567890ABCDEF1234567890ABCDEF12" />
4
    </Signer>
5
</Signers>

WHQL-Signed Rule#

Use: Restricts kernel-mode drivers to those validated and signed by the Windows Hardware Quality Labs. Prevents malware-infected or untrusted drivers from loading at the kernel level. Reduces system crash risk from incompatible or unvalidated drivers.

1
<FileRules>
2
    <FileAttrib ID="ID_WHQL_EXAMPLE" FriendlyName="WHQL Only Drivers">
3
        <WHQL />
4
    </FileAttrib>
5
</FileRules>

WHQL Publisher Rule#

Use: Restricts WHQL-certified drivers further to those from a specific vendor’s CN only. More restrictive than WHQL alone — suitable for environments with standardized hardware.

Use Case	Example
Restricting GPU drivers	Allow only NVIDIA WHQL-certified drivers
Standardizing network drivers	Ensure only Intel-certified NIC drivers are installed
Restricting peripheral drivers	Allow only approved keyboard/mouse manufacturer WHQL drivers

1
<Signers>
2
    <Signer ID="ID_SIGNER_WHQL_PUBLISHER" Name="NVIDIA WHQL Publisher">
3
        <CertRoot Type="Whql" Value="ABCDEF1234567890ABCDEF1234567890ABCDEF12" />
4
        <CertPublisher Value="NVIDIA Corporation" />
5
    </Signer>
6
</Signers>

6. Signing Scenarios#

Signing scenarios define whether a given set of signer rules applies to kernel-mode or user-mode code. Each signing scenario is identified by a numeric Value attribute.

Kernel Mode Code Integrity (KMCI) — Value=“131”#

Prevents the loading of unsigned, modified, or untrusted kernel-mode drivers. Because the kernel operates at the highest privilege level, a compromised kernel driver can result in complete system takeover.

1
<SigningScenarios>
2
    <SigningScenario Value="131" ID="ID_SIGNINGSCENARIO_KMCI"
3
        FriendlyName="Kernel Mode Signing Scenario">
4
        <ProductSigners>
5
            <AllowedSigners>
6
                <AllowedSigner SignerId="ID_SIGNER_MICROSOFT_PRODUCT_1997" />
7
                <AllowedSigner SignerId="ID_SIGNER_MICROSOFT_PRODUCT_2001" />
8
            </AllowedSigners>
9
        </ProductSigners>
10
    </SigningScenario>
11
</SigningScenarios>

User Mode Code Integrity (UMCI) — Value=“12”#

Enforces security at the application and script execution level. Ensures only signed, approved executables can run. Restricts PowerShell, JavaScript, and VBScript to trusted sources. Blocks scripting-based attacks and unsigned application execution.

Prerequisite: The Enabled:UMCI rule option (Option 0) must be present in the policy for UMCI signing scenarios to take effect.

1
<SigningScenarios>
2
    <SigningScenario Value="12" ID="ID_SIGNINGSCENARIO_UMCI"
3
        FriendlyName="User Mode Signing Scenario">
4
        <ProductSigners>
5
            <AllowedSigners>
6
                <AllowedSigner SignerId="ID_SIGNER_MICROSOFT_PRODUCT_1997_UMCI" />
7
                <AllowedSigner SignerId="ID_SIGNER_MICROSOFT_PRODUCT_2001_UMCI" />
8
            </AllowedSigners>
9
        </ProductSigners>
10
    </SigningScenario>
11
</SigningScenarios>

flowchart TD
    BOOT[System Boot] --> KMCI
    subgraph KMCI["Kernel Mode Code Integrity — Value=131"]
        K1[Driver Load Request]
        K2{WHQL Signed?\nIn Allowlist?}
        K3[Load Driver]
        K4[Block — BSOD possible]
        K1 --> K2
        K2 -->|Yes| K3
        K2 -->|No| K4
    end
    USER[User Logs In] --> UMCI
    subgraph UMCI["User Mode Code Integrity — Value=12 + Option 0"]
        U1[App / Script Execution]
        U2{Signed?\nTrusted?\nISG / MI?}
        U3[Allow]
        U4[Block — Event 3077]
        U1 --> U2
        U2 -->|Yes| U3
        U2 -->|No| U4
    end
    style KMCI fill:#1a0a2e,color:#c4b5fd,stroke:#7c3aed
    style UMCI fill:#0a1628,color:#93c5fd,stroke:#2563eb
    style K4 fill:#3b1515,color:#fca5a5
    style U4 fill:#3b1515,color:#fca5a5

7. Update Policy Signers#

When Option 6 (Enabled:Unsigned System Integrity Policy) is removed from the policy, all policies must be cryptographically signed. In this configuration, the <UpdatePolicySigners> section specifies which certificates are authorized to update the policy in the future.

Important: If Option 6 is removed without correctly configuring UpdatePolicySigners, the policy becomes unmodifiable and may permanently lock the system. Validate this configuration thoroughly in audit mode before enforcing.

1
<UpdatePolicySigners>
2
    <Signer ID="ID_SIGNER_IT_ADMIN" Name="Corporate IT Security Administrator">
3
        <CertRoot Type="CustomCodeCertificate" Value="ABCDEF1234567890ABCDEF1234567890ABCDEF12" />
4
    </Signer>
5
</UpdatePolicySigners>

8. Allow vs. Deny Rule Processing Order#

App Control for Business evaluates rules in a fixed order. Understanding this order is critical for writing correct policies and diagnosing unexpected allow or block behavior.

Processing Sequence#

Step	Action
1	Check all deny rules — deny rules are evaluated first
2	Process allow rules
3	If no deny or allow rule matches, check Managed Installer approval (if the policy enables it)
4	If still no match, fall back to ISG reputation check (if permitted by policy)

Note: A deny rule always wins. If a file matches both a deny rule and an allow rule, the file is blocked.

Operational Recommendation#

Use separate ALLOW and DENY policies on Windows versions that support multiple active App Control policies. Keeping allow and deny logic in distinct policy files makes policies easier to read, audit, and maintain over time.

flowchart TD
    REQ[File Execution Request] --> D1
    D1{Deny Rule Match?}
    D1 -->|Yes| DENY[BLOCK\nDeny rules always win]
    D1 -->|No| A1
    A1{Allow Rule Match?}
    A1 -->|Yes| ALLOW[ALLOW]
    A1 -->|No| MI1
    MI1{Managed Installer\nOption 13 enabled?}
    MI1 -->|Tagged by MI| ALLOW
    MI1 -->|Not tagged| ISG1
    ISG1{ISG Auth\nOption 14 enabled?}
    ISG1 -->|Good reputation| ALLOW
    ISG1 -->|Unknown / bad| DENY
    style DENY fill:#3b1515,color:#fca5a5
    style ALLOW fill:#14532d,color:#86efac

9. Complete Example Policy XML#

The following is a comprehensive example policy XML demonstrating all major rule types covered in this document. Each section is annotated with inline comments.

1
<?xml version="1.0" encoding="utf-8"?>
2
<SiPolicy xmlns="urn:schemas-microsoft-com:sipolicy"
3
          PolicyType="Base Policy"
4
          VersionEx="1.0.0.0"
5
          PolicyID="{A1B2C3D4-E5F6-7890-ABCD-EF1234567890}"
6
          BasePolicyID="{A1B2C3D4-E5F6-7890-ABCD-EF1234567890}"
7
          PlatformID="{2E07F7E4-194C-4D20-B7C9-6F44A6C5A234}">
8

9
    <!-- =====================================================================
10
         RULE OPTIONS
11
         Defines the behavioral options for this policy.
12
         Option 3  = Audit Mode (log-only; remove to enforce)
13
         Option 6  = Allow unsigned policies (default; remove to require signing)
14
         Option 13 = Trust Managed Installer (Intune / SCCM)
15
         Option 17 = Allow supplemental policies to extend this base policy
16
         ===================================================================== -->
17
    <Rules>
18
        <Rule>
19
            <Option>Enabled:Audit Mode</Option>         <!-- Option 3 -->
20
        </Rule>
21
        <Rule>
22
            <Option>Enabled:Unsigned System Integrity Policy</Option> <!-- Option 6 -->
23
        </Rule>
24
        <Rule>
25
            <Option>Enabled:Managed Installer</Option>  <!-- Option 13 -->
26
        </Rule>
27
        <Rule>
28
            <Option>Enabled:Allow Supplemental Policies</Option> <!-- Option 17 -->
29
        </Rule>
30
    </Rules>
31

32
    <!-- =====================================================================
33
         EKUs — ENHANCED KEY USAGES
34
         Defines the certificate usages that signer rules may reference.
35
         ===================================================================== -->
36
    <EKUs>
37
        <EKU ID="ID_EKU_WINDOWS_STORE"
38
             FriendlyName="Windows Store EKU"
39
             Value="010a2b0601040182374c0301" />
40
        <EKU ID="ID_EKU_WHQL"
41
             FriendlyName="Windows Hardware Quality Labs EKU"
42
             Value="010a2b0601040182370a030b" />
43
    </EKUs>
44

45
    <!-- =====================================================================
46
         FILE RULES
47
         Defines per-file trust conditions.
48
         ===================================================================== -->
49
    <FileRules>
50

51
        <FileAttrib ID="ID_FILE_HASH_EXAMPLE"
52
                    FriendlyName="ExampleApplication.exe HashRule"
53
                    FileName="ExampleApplication.exe"
54
                    MinimumFileVersion="1.0.0.0">
55
            <Hash Type="SHA256"
56
                  Value="A3F5E9D3C2B1A4E5F6D7A8C9B0E1F2D3A4B5C6D7E8F9A0B1C2D3E4F5A6B7C8D9" />
57
        </FileAttrib>
58

59
        <Deny ID="ID_DENY_FILE_HASH"
60
              FriendlyName="Deny ExampleApplication.exe HashRule">
61
            <Hash Type="SHA256"
62
                  Value="B3C5D7E9F2A4C6B8D1E3F5A7C9B0E2D4A6F8C1B2D3E5F7A9C0D1E2F3A4B5C6" />
63
        </Deny>
64

65
        <FileAttrib ID="ID_FILE_NAME_ALLOW"
66
                    FriendlyName="Allow ExampleApplication.exe by Name"
67
                    FileName="ExampleApplication.exe" />
68

69
        <Deny ID="ID_DENY_FILE_NAME"
70
              FriendlyName="Deny ExampleApplication.exe by Name"
71
              FileName="ExampleApplication.exe" />
72

73
        <FileAttrib ID="ID_FILE_PATH_ALLOW"
74
                    FriendlyName="Allow files in Program Files\ExampleApp"
75
                    FilePath="C:\Program Files\ExampleApp\" />
76

77
        <Deny ID="ID_DENY_FILE_PATH"
78
              FriendlyName="Deny Execution from Downloads"
79
              FilePath="C:\Users\Public\Downloads\" />
80

81
        <FileAttrib ID="ID_SIGNED_VERSION_ALLOW"
82
                    FriendlyName="Allow ExampleApplication.exe v2+ Signed"
83
                    FileName="ExampleApplication.exe"
84
                    MinimumFileVersion="2.0.0.0">
85
            <SignerRef SignerID="ID_SIGNER_EXAMPLE_CORP" />
86
        </FileAttrib>
87

88
        <FileAttrib ID="ID_FILE_FILEPUBLISHER_ALLOW"
89
                    FriendlyName="Allow ExampleApplication.exe FilePublisher"
90
                    FileName="ExampleApplication.exe"
91
                    MinimumFileVersion="2.0.0.0" />
92

93
        <FileAttrib ID="ID_WHQL_EXAMPLE"
94
                    FriendlyName="WHQL Only Drivers">
95
            <WHQL />
96
        </FileAttrib>
97

98
    </FileRules>
99

100
    <!-- =====================================================================
101
         SIGNERS
102
         Defines trusted signing identities referenced by signing scenarios
103
         and file publisher rules.
104
         ===================================================================== -->
105
    <Signers>
106

107
        <Signer ID="ID_SIGNER_EXAMPLE_CORP" Name="Example Corp">
108
            <CertRoot Type="PcaCertificate"
109
                      Value="A1B2C3D4E5F6G7H8I9J0K1L2M3N4O5P6" />
110
        </Signer>
111

112
        <Signer ID="ID_SIGNER_FILEPUBLISHER_ALLOW" Name="Example Corp Publisher">
113
            <CertRoot Type="PcaCertificate"
114
                      Value="ABCDEF1234567890ABCDEF1234567890ABCDEF12" />
115
            <FileAttribRef RuleID="ID_FILE_FILEPUBLISHER_ALLOW" />
116
        </Signer>
117

118
        <Signer ID="ID_SIGNER_LEAF" Name="Example Leaf Certificate Signer">
119
            <CertRoot Type="LeafCertificate"
120
                      Value="ABCDEF1234567890ABCDEF1234567890ABCDEF12" />
121
        </Signer>
122

123
        <Signer ID="ID_SIGNER_WHQL_PUBLISHER" Name="NVIDIA WHQL Publisher">
124
            <CertRoot Type="Whql"
125
                      Value="ABCDEF1234567890ABCDEF1234567890ABCDEF12" />
126
            <CertPublisher Value="NVIDIA Corporation" />
127
        </Signer>
128

129
        <Signer ID="ID_SIGNER_TRUSTED_PUBLISHER" Name="Trusted Publisher">
130
            <CertRoot Type="PcaCertificate"
131
                      Value="ABCDEF1234567890ABCDEF1234567890ABCDEF12" />
132
        </Signer>
133

134
        <Signer ID="ID_SIGNER_MICROSOFT_PRODUCT_1997" Name="Microsoft Product 1997">
135
            <CertRoot Type="PcaCertificate"
136
                      Value="1111111111111111111111111111111111111111" />
137
        </Signer>
138
        <Signer ID="ID_SIGNER_MICROSOFT_PRODUCT_2001" Name="Microsoft Product 2001">
139
            <CertRoot Type="PcaCertificate"
140
                      Value="2222222222222222222222222222222222222222" />
141
        </Signer>
142
        <Signer ID="ID_SIGNER_MICROSOFT_PRODUCT_1997_UMCI" Name="Microsoft Product 1997 (UMCI)">
143
            <CertRoot Type="PcaCertificate"
144
                      Value="1111111111111111111111111111111111111111" />
145
        </Signer>
146
        <Signer ID="ID_SIGNER_MICROSOFT_PRODUCT_2001_UMCI" Name="Microsoft Product 2001 (UMCI)">
147
            <CertRoot Type="PcaCertificate"
148
                      Value="2222222222222222222222222222222222222222" />
149
        </Signer>
150

151
    </Signers>
152

153
    <!-- =====================================================================
154
         SIGNING SCENARIOS
155
         Defines which signers are trusted for kernel-mode (131) and
156
         user-mode (12) code respectively.
157
         ===================================================================== -->
158
    <SigningScenarios>
159

160
        <!-- KMCI — Value="131": Kernel Mode Code Integrity
161
             Prevents loading unsigned/untrusted kernel-mode drivers.
162
             A compromised kernel driver = full system takeover. -->
163
        <SigningScenario Value="131" ID="ID_SIGNINGSCENARIO_KMCI"
164
                         FriendlyName="Kernel Mode Signing Scenario">
165
            <ProductSigners>
166
                <AllowedSigners>
167
                    <AllowedSigner SignerId="ID_SIGNER_MICROSOFT_PRODUCT_1997" />
168
                    <AllowedSigner SignerId="ID_SIGNER_MICROSOFT_PRODUCT_2001" />
169
                    <AllowedSigner SignerId="ID_SIGNER_WHQL_PUBLISHER" />
170
                </AllowedSigners>
171
            </ProductSigners>
172
        </SigningScenario>
173

174
        <!-- UMCI — Value="12": User Mode Code Integrity
175
             Enforces code signing for executables and scripts.
176
             Requires Enabled:UMCI (Option 0) in the Rules section. -->
177
        <SigningScenario Value="12" ID="ID_SIGNINGSCENARIO_UMCI"
178
                         FriendlyName="User Mode Signing Scenario">
179
            <ProductSigners>
180
                <AllowedSigners>
181
                    <AllowedSigner SignerId="ID_SIGNER_MICROSOFT_PRODUCT_1997_UMCI" />
182
                    <AllowedSigner SignerId="ID_SIGNER_MICROSOFT_PRODUCT_2001_UMCI" />
183
                    <AllowedSigner SignerId="ID_SIGNER_FILEPUBLISHER_ALLOW" />
184
                    <AllowedSigner SignerId="ID_SIGNER_TRUSTED_PUBLISHER" />
185
                    <AllowedSigner SignerId="ID_SIGNER_EXAMPLE_CORP" />
186
                    <AllowedSigner SignerId="ID_SIGNER_LEAF" />
187
                </AllowedSigners>
188
                <DeniedSigners>
189
                </DeniedSigners>
190
                <FileRulesRef>
191
                    <FileRuleRef RuleID="ID_FILE_HASH_EXAMPLE" />
192
                    <FileRuleRef RuleID="ID_DENY_FILE_HASH" />
193
                    <FileRuleRef RuleID="ID_FILE_NAME_ALLOW" />
194
                    <FileRuleRef RuleID="ID_DENY_FILE_NAME" />
195
                    <FileRuleRef RuleID="ID_FILE_PATH_ALLOW" />
196
                    <FileRuleRef RuleID="ID_DENY_FILE_PATH" />
197
                    <FileRuleRef RuleID="ID_SIGNED_VERSION_ALLOW" />
198
                    <FileRuleRef RuleID="ID_FILE_FILEPUBLISHER_ALLOW" />
199
                </FileRulesRef>
200
            </ProductSigners>
201
        </SigningScenario>
202

203
    </SigningScenarios>
204

205
    <!-- =====================================================================
206
         UPDATE POLICY SIGNERS
207
         Specifies which certificates are authorized to update this policy.
208
         Required when Option 6 (Unsigned System Integrity Policy) is removed.
209
         ===================================================================== -->
210
    <UpdatePolicySigners>
211
        <Signer ID="ID_SIGNER_IT_ADMIN" Name="Corporate IT Security Administrator">
212
            <CertRoot Type="CustomCodeCertificate"
213
                      Value="ABCDEF1234567890ABCDEF1234567890ABCDEF12" />
214
        </Signer>
215
    </UpdatePolicySigners>
216

217
</SiPolicy>

Note: All certificate Value attributes in this example are illustrative placeholders. Replace them with the actual TBS hash or certificate thumbprint values from your environment.

Part	Topic
Part 1	Introduction & Key Concepts
Part 2	Policy Templates & Rule Options (this document)
Part 3	Application ID Tagging Policies & Managed Installer
Part 4	(forthcoming)
Part 5	(forthcoming)
Part 6	Sign, Apply, and Remove Signed Policies
Part 7	Maintaining Policies with Azure DevOps (or PowerShell)

Document compiled by Anubhav Gain from source material published at ctrlshiftenter.cloud.
Original author: Patrick Seltmann. For organizational reference use.