App Control for Business — Complete Reference: Notes, Tips & Advanced Considerations#

Key Points#

• The PowerShell cmdlets, XML schema, event log sources, and .cip binary format did not change with the rebrand. You will still see WDAC everywhere in cmdlet names, log source names (Microsoft-Windows-CodeIntegrity), and documentation.
• App Control for Business is not the same as AppLocker. AppLocker is a legacy technology; App Control operates at the kernel level and is significantly more secure.
• App Control is not antivirus. It is a whitelisting (allowlisting) enforcement engine — only explicitly trusted code runs. Anything not trusted is blocked.
• The SiPolicy.p7 / .cip binary is the compiled enforcement artefact deployed to the OS.

Primary Use Cases#

Allow All Rules#

Microsoft’s recommended block rules ship with two special “Allow All” rules. These make the block rules function as a deny-list overlay — safe only because they are combined with existing allow-list base policies:

1
<Allow ID="ID_ALLOW_A_1" FriendlyName="Allow Kernel Drivers" FileName="*" />
2
<Allow ID="ID_ALLOW_A_2" FriendlyName="Allow User mode components" FileName="*" />

WARNING: If you merge block rules into an allow-list policy, you must remove ID_ALLOW_A_1 and ID_ALLOW_A_2 first. Keeping them turns your allow-list policy into an “allow everything except blocked items” policy.

Multiple Base Policies Interaction#

When multiple base policies are deployed simultaneously:

• A file must be ALLOWED by ALL base policies to run.
• One base policy blocking a file = the file is blocked, regardless of other policies.
• This is additive restriction, not additive permission.

Checking Policy Type#

Open the XML and inspect the SiPolicy root element:

1
<SiPolicy xmlns="urn:schemas-microsoft-com:sipolicy" PolicyType="Supplemental Policy">

Or use PowerShell:

1
[xml]$policy = Get-Content .\Policy.xml
2
$policy.SiPolicy.PolicyType
3
# Returns: "Base Policy" or "Supplemental Policy"

Converting Base → Supplemental#

1
Set-CiPolicyIdInfo `
2
    -FilePath .\Policy.xml `
3
    -SupplementsBasePolicyID "{GUID-OF-BASE-POLICY}" `
4
    -ResetPolicyId

This command:

1. Sets PolicyType="Supplemental Policy" on the SiPolicy element
2. Adds/updates <BasePolicyID> to the base policy’s GUID
3. Resets the supplemental’s own <PolicyID> to a new GUID (so it is unique)

4.1 Stripping Invalid Policy Options#

Supplemental policies only support a subset of policy rule options. You must remove all non-supplemental-valid options before deploying:

1
[System.String]$SupplementalPolicyPath = "<Path to SupplementalPolicy.xml>"
2

3
# Remove all options that are NOT valid in supplemental policies
4
@(0, 1, 2, 3, 4, 8, 9, 10, 11, 12, 15, 16, 17, 19, 20) | ForEach-Object -Process {
5
    Set-RuleOption -FilePath $SupplementalPolicyPath -Option $_ -Delete
6
}

4.2 Valid Options in Supplemental Policies#

All other options (0–4, 8–12, 15–17, 19–20) are base-policy-only and will be rejected or cause unexpected behavior in supplemental policies.

4.3 Decision Tree: Is This Option Valid in a Supplemental?#

1
%%{init: {'theme': 'dark', 'themeVariables': {'primaryColor': '#1a1a2e', 'primaryTextColor': '#e0e0e0', 'primaryBorderColor': '#ffd700', 'lineColor': '#ffd700'}}}%%
2
flowchart TD
3
    Start([Policy Rule Option Number]) --> Check{Is option\nnumber in\n5,6,7,13,14,18?}
4
    Check -->|Yes| Valid["✅ VALID in Supplemental\nKeep it"]
5
    Check -->|No| Invalid["❌ INVALID in Supplemental\nRemove with Set-RuleOption -Delete"]
6
    Invalid --> RemoveCmd["Set-RuleOption\n-FilePath \$path\n-Option N\n-Delete"]
7
    Valid --> Deploy["Deploy supplemental policy"]
8
    RemoveCmd --> Deploy

4.4 Deny Rules in Supplemental Policies Are Silently Ignored#

This is one of the most common mistakes:

Supplemental policies can only ADD trust — they cannot RESTRICT it.

• Any <Deny> file rules in a supplemental policy XML are parsed without error but never enforced.
• Any <DeniedSigners> in a supplemental policy are silently ignored.
• You do NOT need to include Microsoft recommended block rules in supplemental policies — they have zero effect.

4.5 Signing a Supplemental Policy#

When using signed App Control policies, the signer rules for supplemental policies must be added to the BASE policy, not the supplemental itself:

1
# Add supplemental signer to the BASE policy (correct)
2
Add-SignerRule `
3
    -FilePath .\BasePolicy.xml `
4
    -CertificatePath .\MyCert.cer `
5
    -Supplemental
6

7
# Do NOT do this on the supplemental policy itself (causes BOOT FAILURE)
8
# Add-SignerRule -FilePath .\SupplementalPolicy.xml -CertificatePath .\MyCert.cer -Supplemental

WARNING: Using -Supplemental switch when calling Add-SignerRule on a supplemental policy (instead of the base) is a known gotcha that can result in boot failure on the endpoint. Always apply -Supplemental signer rules to the BASE policy.

4.6 Removing Supplemental Policies#

1
# Get current policies and their IDs
2
CITool --list-policies
3

4
# Remove a supplemental policy by its Policy ID
5
CITool --remove-policy "{PolicyID-GUID}"

Important behavior notes:

• This works for both signed and unsigned supplemental policies.
• Removing a supplemental policy does NOT immediately block applications that are already running.
• Apps that were launched under the supplemental’s trust continue running until a reboot.
• Reboot is required for the removal to take full effect.

4.7 Unsigned Supplemental for a Signed Base#

If all other policies on the system are signed, an unsigned supplemental policy will be silently ignored.

The signing status of all deployed policies must match:

• Signed base + unsigned supplemental = supplemental ignored
• Signed base + signed supplemental = both enforced
• Unsigned base + unsigned supplemental = both enforced

5.1 File Deny Rules — XML Anatomy#

A file deny rule requires two parts in the XML:

Part 1 — Define the rule in <FileRules>:

1
<FileRules>
2
    <Deny
3
        ID="ID_DENY_MALWARE_HASH_1"
4
        FriendlyName="Deny known malware by hash"
5
        Hash="E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855" />
6

7
    <Deny
8
        ID="ID_DENY_MIMIKATZ"
9
        FriendlyName="Deny mimikatz by filename"
10
        FileName="mimikatz.exe"
11
        MinimumFileVersion="0.0.0.0" />
12
</FileRules>

Part 2 — Reference the rule from a <SigningScenario>:

1
<SigningScenarios>
2
    <SigningScenario Value="12" ID="ID_SIGNINGSCENARIO_WINDOWS" FriendlyName="User Mode">
3
        <ProductSigners>
4
            <FileRulesRef>
5
                <FileRuleRef RuleID="ID_DENY_MALWARE_HASH_1" />
6
                <FileRuleRef RuleID="ID_DENY_MIMIKATZ" />
7
            </FileRulesRef>
8
        </ProductSigners>
9
    </SigningScenario>
10
</SigningScenarios>

Gotcha: A <Deny> rule in <FileRules> with NO corresponding <FileRuleRef> in a <SigningScenario> is never enforced. Both parts are required.

5.2 Denied Certificates/Signers — XML Anatomy#

Denying by certificate/signer is different from file deny rules:

1
<Signers>
2
    <Signer ID="ID_SIGNER_DENY_VULN_CERT" Name="Vulnerable Driver Publisher">
3
        <CertRoot Type="TBS" Value="AABBCCDDEEFF..." />
4
        <CertPublisher Value="Vulnerable Corp" />
5
    </Signer>
6
</Signers>
7

8
<SigningScenarios>
9
    <SigningScenario Value="131" ID="ID_SIGNINGSCENARIO_DRIVERS_1" FriendlyName="Kernel Mode">
10
        <ProductSigners>
11
            <DeniedSigners>
12
                <DeniedSigner SignerId="ID_SIGNER_DENY_VULN_CERT" />
13
            </DeniedSigners>
14
        </ProductSigners>
15
    </SigningScenario>
16
</SigningScenarios>

Key Insight: The <Signer> element in <Signers> does not specify allow or deny on its own. Placement in <AllowedSigners> or <DeniedSigners> within a <SigningScenario> determines the action.

Key Precedence Rules#

1. Explicit DENY beats EVERYTHING — even if a supplemental policy explicitly allows the same file, a deny rule in any base policy wins.
2. Base policy allow is evaluated before supplemental allows.
3. Supplemental allows only extend trust, never override denies.
4. Managed Installer (MI) and ISG trust are evaluated last among allow mechanisms.
5. Implicit deny is the fallback — no matching allow rule = blocked.

Critical Facts#

• The Value attribute must be exactly 131 (kernel) or 12 (user) — these are fixed constants defined by the Windows CI driver.
• The ID attribute is customizable — you can name it anything (e.g., ID_SIGNINGSCENARIO_KERNEL, MY_KERNEL_SCENARIO).
• The FriendlyName attribute is also fully customizable.
• If you use the wrong Value number (e.g., Value="130" instead of 131), your kernel-mode rules will not be evaluated by the kernel Code Integrity driver, and drivers that should be blocked will load.

What Happens with Wrong Value?#

If a kernel driver signer is placed only in Value="12" (user mode scenario):

• The kernel Code Integrity check runs against Value="131" only.
• The driver is evaluated against the kernel scenario and finds no matching allow rule.
• Result: driver blocked by implicit deny even if you have a matching signer rule.

Conversely, if you put a user-mode .exe allow rule only in Value="131":

• User mode CI checks Value="12" only.
• The exe is blocked by implicit deny.

8.1 PowerShell — CIM Query#

1
Get-CimInstance `
2
    -ClassName Win32_DeviceGuard `
3
    -Namespace root\Microsoft\Windows\DeviceGuard |
4
    Select-Object -Property *codeintegrity* |
5
    Format-List

Key properties returned:

8.2 System Information (msinfo32)#

Run msinfo32.exe → navigate to System Summary:

• App Control for Business Policy (Kernel Mode): On / Audit Mode / Off
• App Control for Business User Mode Policy (User Mode): On / Audit Mode / Off

8.3 Status Meanings and Actions#

1
%%{init: {'theme': 'dark', 'themeVariables': {'primaryColor': '#1a1a2e', 'primaryTextColor': '#e0e0e0', 'primaryBorderColor': '#ffd700', 'lineColor': '#ffd700'}}}%%
2
flowchart TD
3
    Query["Query CodeIntegrityPolicyEnforcementStatus"] --> V2{Value = 2?}
4
    V2 -->|Yes| Enforced["✅ Enforced\nBlocking active\nCheck event log 3076/3077 for blocks"]
5
    V2 -->|No| V1{Value = 1?}
6
    V1 -->|Yes| Audit["⚠️ Audit Mode\nBlocks are logged only, not enforced\nEvent ID 3076 in CodeIntegrity log"]
7
    V1 -->|No| V0{Value = 0?}
8
    V0 -->|Yes| Disabled["❌ Disabled\nNo CI policy active\nCheck policy deployment"]
9
    V0 -->|No| Unknown["❓ Unknown value\nCheck Windows build / WDAC support"]
10

11
    style Enforced fill:#006400,stroke:#44ff44,color:#ffffff
12
    style Audit fill:#8b6914,stroke:#ffd700,color:#ffffff
13
    style Disabled fill:#8b0000,stroke:#ff4444,color:#ffffff

8.4 Relevant Event IDs#

9.1 Modern Method — CITool (Windows 11 22H2+)#

1
# Refresh all deployed policies
2
CITool --refresh
3

4
# List all currently deployed policies
5
CITool --list-policies
6

7
# Update a specific policy from a .cip file
8
CITool --update-policy "C:\Policies\MyPolicy.cip"
9

10
# Remove a policy by GUID
11
CITool --remove-policy "{PolicyID-GUID}"

9.2 Legacy Method — RefreshPolicy.exe#

For Windows 10 and earlier Windows 11 builds, use the RefreshPolicy(AMD64).exe tool downloaded from Microsoft:

1
# Download from Microsoft, then run:
2
.\RefreshPolicy.exe

Note: CITool is available in Windows 11 22H2 (build 22621) and later. For anything older, you need RefreshPolicy.exe. The refresh tool should no longer be needed on modern endpoints.

9.3 Policy Refresh Flow#

1
%%{init: {'theme': 'dark', 'themeVariables': {'primaryColor': '#1a1a2e', 'primaryTextColor': '#e0e0e0', 'primaryBorderColor': '#ffd700', 'lineColor': '#ffd700'}}}%%
2
sequenceDiagram
3
    participant Admin as Administrator
4
    participant FS as File System\n(C:\Windows\System32\CodeIntegrity\CiPolicies\Active)
5
    participant CITool as CITool.exe
6
    participant Kernel as Windows Kernel\n(ci.dll)
7
    participant EventLog as Code Integrity\nEvent Log
8

9
    Admin->>FS: Copy .cip file to Active folder
10
    Admin->>CITool: CITool --refresh
11
    CITool->>Kernel: Signal policy reload
12
    Kernel->>FS: Read all .cip files from Active folder
13
    Kernel->>Kernel: Validate & load policies
14
    Kernel->>EventLog: Event 3099 (policy loaded)
15
    CITool->>Admin: Refresh complete
16
    Note over Kernel,EventLog: Running processes are NOT affected<br/>New policy applies to NEW process launches
17
    Note over Admin,Kernel: Removing supplemental requires REBOOT<br/>to stop already-running processes

9.4 Important Refresh Behavior#

• Policy refresh applies to new process launches only.
• Processes already running under a now-removed supplemental’s trust continue running until they exit or the system reboots.
• For kernel drivers: a refresh may immediately affect new driver loads, but loaded drivers stay loaded until reboot.
• Signed policies can be updated without reboot (if the new version is signed by the same signer).
• Unsigned policies in /EFI/Microsoft/Boot/ still require reboot.

10.1 Basic Merge#

1
# Merge two policies into one output file
2
Merge-CIPolicy `
3
    -PolicyPaths .\Policy1.xml, .\Policy2.xml `
4
    -OutputFilePath .\MergedPolicy.xml
5

6
# Merge a policy with itself (useful for cleanup — removes duplicate EKUs)
7
Merge-CIPolicy `
8
    -PolicyPaths .\Policy.xml `
9
    -OutputFilePath .\PolicyCleaned.xml

10.2 Merge Behavior Details#

10.3 Self-Merge Cleanup#

Merging a policy with itself is a useful maintenance operation:

1
# Clean up duplicate/redundant EKUs
2
Merge-CIPolicy -PolicyPaths .\Policy.xml -OutputFilePath .\Policy_clean.xml

This:

• Removes duplicate EKU entries
• Adds _0 suffix to IDs (note: IDs change, so update any references)
• Normalizes the XML structure

10.4 Pre-Merge Checklist#

Before merging block rules or supplemental rules into an allow-list base policy:

• Remove ID_ALLOW_A_1 (“Allow Kernel Drivers” wildcard) from block rules
• Remove ID_ALLOW_A_2 (“Allow User mode components” wildcard) from block rules
• Verify the resulting merged policy still allows Windows OS files
• Test in Audit mode before enforcing

11.1 Obtaining and Using Block Rules#

1
# Download the latest block rules (check Microsoft docs for current URL)
2
# Then:
3
# 1. Copy the XML into a new file
4
# 2. Remove the Allow All rules (ID_ALLOW_A_1, ID_ALLOW_A_2)
5
# 3. Set a new unique Policy ID
6
Set-CiPolicyIdInfo -FilePath .\BlockRules.xml -ResetPolicyId
7

8
# 4. If merging into your allow-list policy:
9
Merge-CIPolicy `
10
    -PolicyPaths .\AllowListPolicy.xml, .\BlockRules_NoAllowAll.xml `
11
    -OutputFilePath .\MergedPolicy.xml

11.2 The Allow All Rules Problem (Detailed)#

The shipped block rules XML contains:

1
<Allow ID="ID_ALLOW_A_1" FriendlyName="Allow Kernel Drivers" FileName="*" />
2
<Allow ID="ID_ALLOW_A_2" FriendlyName="Allow User mode components" FileName="*" />

These exist because block rules are designed to be deployed alongside existing policies (on systems that already have no App Control policy = allow all). In a multi-policy environment:

• System with no policy (default Windows): allow all. Adding block rules = deny-list on top of allow-all.
• System with allow-list policy: if you merge block rules including Allow All, the merged policy allows everything (wildcard * wins).

Always remove these two rules before merging into any allow-list policy.

11.3 Multiple Policy Format Requirement#

Block rules must be in multiple policy format to coexist with other policies:

1
Set-CiPolicyIdInfo -FilePath .\BlockRules.xml -ResetPolicyId
2
# This sets a new GUID-based PolicyID, enabling multiple policy support

11.4 How Allow All + Multiple Base Policies Work#

1
Base Policy A: Allow Windows + Allow signed by "Publisher X"
2
Base Policy B: (Block rules) Allow * (wildcard) + Deny mimikatz.exe
3

4
Result: A file must be allowed by BOTH A and B.
5
- Windows files: allowed by A (specific rule) AND allowed by B (wildcard) → RUNS
6
- Publisher X file: allowed by A AND allowed by B (wildcard) → RUNS
7
- mimikatz.exe: allowed by A? No specific rule... implicit deny from A → BLOCKED
8
  (Even though B has Allow *, A doesn't allow it → blocked by A)

12.1 Overview#

Microsoft maintains a separate list of vulnerable and malicious kernel drivers that should be blocked via WDAC. This protects against Bring-Your-Own-Vulnerable-Driver (BYOVD) attacks.

Key facts:

• Windows 11 22H2 and later already enforce the Microsoft recommended driver block list by default, even without deploying a custom policy.
• Event ID 3099 in the Code Integrity operational log shows the version of the deployed block list.
• The driver block list is updated via Windows Update, independent of your custom policies.
• ISG does NOT include the recommended driver blocklists — ISG cloud reputation does not substitute for the driver block rules.

12.2 Windows 11 22H2+ Behavior#

On Windows 11 22H2+:

1
# Check what driver block list version is deployed
2
Get-WinEvent -LogName "Microsoft-Windows-CodeIntegrity/Operational" |
3
    Where-Object Id -eq 3099 |
4
    Select-Object -First 5 -Property TimeCreated, Message

Because the OS enforces the Microsoft driver block list automatically, you generally do not need to include it in your own policy on 22H2+ systems. Including it is harmless but redundant.

12.3 Updating Driver Block Rules#

For older Windows versions without automatic enforcement:

1
# Deploy the driver block rules as a separate policy
2
# Download from: https://learn.microsoft.com/en-us/windows/security/application-security/application-control/app-control-for-business/design/microsoft-recommended-driver-block-rules
3

4
Set-CiPolicyIdInfo -FilePath .\DriverBlockRules.xml -ResetPolicyId
5
ConvertFrom-CIPolicy -XmlFilePath .\DriverBlockRules.xml -BinaryFilePath .\DriverBlockRules.cip
6
# Copy to C:\Windows\System32\CodeIntegrity\CiPolicies\Active\
7
CITool --refresh

13.1 Why Sign a Policy?#

• Unsigned policies can be removed/modified by local admins or attackers with admin rights.
• A signed policy stored in the EFI partition is enforced by UEFI Secure Boot — extremely difficult to bypass.
• Required for Maximum protection level in Windows 11 Security Baseline.

13.2 Signing Workflow#

1
# Step 1: Add signer rules to the policy (do HVCI AFTER this step)
2
Add-SignerRule `
3
    -FilePath .\BasePolicy.xml `
4
    -CertificatePath .\PolicySigningCert.cer `
5
    -Update `
6
    -Supplemental   # Add this if you want supplemental policies supported
7

8
# Step 2: Set HVCI AFTER Add-SignerRule (important — Add-SignerRule resets HvciOptions to 0)
9
Set-HVCIOptions -Strict -FilePath .\BasePolicy.xml
10

11
# Step 3: Compile to binary
12
ConvertFrom-CIPolicy `
13
    -XmlFilePath .\BasePolicy.xml `
14
    -BinaryFilePath .\BasePolicy.cip
15

16
# Step 4: Sign the binary
17
# Note: -fd certHash defaults to the algorithm of the signing certificate
18
signtool sign `
19
    -v `
20
    -n "PolicySigningCert" `
21
    -p7 . `
22
    -p7co 1.3.6.1.4.1.311.79.1 `
23
    -fd sha256 `
24
    .\BasePolicy.cip

Critical HVCI Ordering: Add-SignerRule resets HvciOptions to 0 every time it runs. Always run Set-HVCIOptions after all Add-SignerRule calls are complete, never before.

13.3 EFI Partition Behavior#

When a signed policy is placed in the EFI partition:

• The policy is enforced before the OS fully loads.
• Even Safe Mode respects the signed policy.
• Bypassing requires physical access and disabling Secure Boot.
• Cannot be removed by Windows Reset (see Section 24).

13.4 CMS v1 Workaround#

App Control policy signing requires CMS (Cryptographic Message Syntax) version 1 format. Some signing tools default to CMS v2. The SignTool parameters shown above (-p7co 1.3.6.1.4.1.311.79.1) ensure CMS v1 output.

14.1 Safety#

• Safe to remove on Stable, Release Preview, and Beta channels.
• Do NOT remove on Canary or Dev channels if you need to stay on those channels.
• Removing flight certs causes Settings to show the Insider enrollment as unavailable (see Section 27 for more details).

14.2 Full Removal Commands#

1
# Remove all flight signing certificate rules from a policy
2
Remove-CIPolicyRule -FilePath .\Policy.xml -Id "ID_SIGNER_STORE_FLIGHT_ROOT"
3
Remove-CIPolicyRule -FilePath .\Policy.xml -Id "ID_SIGNER_WINDOWS_FLIGHT_ROOT"
4
Remove-CIPolicyRule -FilePath .\Policy.xml -Id "ID_SIGNER_ELAM_FLIGHT"
5
Remove-CIPolicyRule -FilePath .\Policy.xml -Id "ID_SIGNER_HAL_FLIGHT"
6
Remove-CIPolicyRule -FilePath .\Policy.xml -Id "ID_SIGNER_WHQL_FLIGHT_SHA2"
7
Remove-CIPolicyRule -FilePath .\Policy.xml -Id "ID_SIGNER_WINDOWS_FLIGHT_ROOT_USER"
8
Remove-CIPolicyRule -FilePath .\Policy.xml -Id "ID_SIGNER_FLIGHT_ROOT_USER_SHA256"
9
Remove-CIPolicyRule -FilePath .\Policy.xml -Id "ID_SIGNER_STORE_FLIGHT"
10
Remove-CIPolicyRule -FilePath .\Policy.xml -Id "ID_SIGNER_TEST_ROOT_USER"
11
Remove-CIPolicyRule -FilePath .\Policy.xml -Id "ID_SIGNER_DRM_FLIGHT_ROOT"

These 10 Remove-CIPolicyRule calls cover all known flight signing certificate signers in the default Windows policy templates.

15.1 Why Remove?#

• Reduces trusted signing authorities in your policy.
• CITool is built into Windows 11 22H2+ and replaces all functionality.
• Removing the refresh tool certificates closes a potential trust path.

15.2 ORDER MATTERS#

Important: Remove the FileAttrib rule before removing the Signer rule. Removing the Signer first may leave an orphaned FileAttrib reference that causes XML validation errors.

1
# Step 1: Remove FileAttrib rule FIRST
2
Remove-CIPolicyRule -FilePath .\Policy.xml -Id "ID_FILEATTRIB_REFRESH_POLICY"
3

4
# Step 2: Remove Signer rule SECOND
5
Remove-CIPolicyRule -FilePath .\Policy.xml -Id "ID_SIGNER_MICROSOFT_REFRESH_POLICY"

Chain Rules#

WDAC Rule Levels from Chain#

17.1 What Generates Double-Signed Rules#

When New-CIPolicy or New-CIPolicyRule processes a double-signed file:

1
%%{init: {'theme': 'dark', 'themeVariables': {'primaryColor': '#1a1a2e', 'primaryTextColor': '#e0e0e0', 'primaryBorderColor': '#ffd700', 'lineColor': '#ffd700'}}}%%
2
flowchart TD
3
    File["Double-Signed .sys file\n(Signer A + Signer B)"] --> ConfigCI["ConfigCI processes file"]
4
    ConfigCI --> S1["Signer A chain:\nIntermediate cert TBS → Signer rule A1\nLeaf cert CN → FileAttrib A"]
5
    ConfigCI --> S2["Signer B chain:\nIntermediate cert TBS → Signer rule B1\nLeaf cert CN → FileAttrib B"]
6
    S1 --> UMCI["User Mode Scenario (Value=12):\n• AllowedSigner ref: A1 (with FileAttribRef)\n• AllowedSigner ref: B1 (with FileAttribRef)"]
7
    S2 --> UMCI
8
    S1 --> KMCI["Kernel Mode Scenario (Value=131):\n• AllowedSigner ref: A1 (with FileAttribRef)\n• AllowedSigner ref: B1 (with FileAttribRef)"]
9
    S2 --> KMCI
10

11
    UMCI --> Count["= 4 AllowedSigner entries total\n(2 in UMCI + 2 in KMCI)"]
12
    KMCI --> Count

17.2 Double-Signed Rule XML Example#

1
<Signers>
2
    <Signer ID="ID_SIGNER_DOUBLE_A" Name="Microsoft SHA256 PCA">
3
        <CertRoot Type="TBS" Value="ABC123..." />
4
        <CertPublisher Value="Microsoft Windows" />
5
        <FileAttribRef RuleID="ID_FILEATTRIB_DRIVER_1" />
6
    </Signer>
7
    <Signer ID="ID_SIGNER_DOUBLE_B" Name="Microsoft WHQL PCA">
8
        <CertRoot Type="TBS" Value="DEF456..." />
9
        <CertPublisher Value="Microsoft Windows Hardware Compatibility" />
10
        <FileAttribRef RuleID="ID_FILEATTRIB_DRIVER_1" />
11
    </Signer>
12
</Signers>
13

14
<SigningScenarios>
15
    <SigningScenario Value="131" ID="ID_SIGNINGSCENARIO_DRIVERS_1">
16
        <ProductSigners>
17
            <AllowedSigners>
18
                <AllowedSigner SignerId="ID_SIGNER_DOUBLE_A" />
19
                <AllowedSigner SignerId="ID_SIGNER_DOUBLE_B" />
20
            </AllowedSigners>
21
        </ProductSigners>
22
    </SigningScenario>
23
    <SigningScenario Value="12" ID="ID_SIGNINGSCENARIO_WINDOWS">
24
        <ProductSigners>
25
            <AllowedSigners>
26
                <AllowedSigner SignerId="ID_SIGNER_DOUBLE_A" />
27
                <AllowedSigner SignerId="ID_SIGNER_DOUBLE_B" />
28
            </AllowedSigners>
29
        </ProductSigners>
30
    </SigningScenario>
31
</SigningScenarios>

17.3 CertRoot TBS vs. CertPublisher CN#

Using Type="TBS" (To-Be-Signed hash) is more secure than Type="CN" because TBS includes the full cert content, not just the name.

Rule Level Security Spectrum#

File Extensions Supported#

App Control rule levels only create rules for PE file types:

• .exe, .dll, .sys, .ocx, .scr, .com
• .msi (limited — no FilePublisher)
• .ps1, .vbs, .js, .wsf (scripts, when script enforcement is enabled)
• .appx/.msix (packaged apps)

Non-PE files (.txt, .jpg, .pdf, etc.) are not subject to App Control rules.

The Core Limitation#

MSI files do not contain a PE VERSIONINFO resource. This means:

• OriginalFileName — not available
• FileDescription — not available
• ProductName — not available
• FileVersion / ProductVersion — not available (in the PE sense)

As a result, FilePublisher level CANNOT be used for MSI files. Trying to generate FilePublisher rules for MSIs will fall back to Publisher level silently.

Valid Options for MSI Rules#

PowerShell Example for MSI Publisher Rule#

1
# Generate Publisher-level rule for an MSI file
2
$Rules = New-CIPolicyRule `
3
    -DriverFilePath .\Setup.msi `
4
    -Level Publisher `
5
    -Fallback Hash
6

7
New-CIPolicy `
8
    -FilePath .\MsiPolicy.xml `
9
    -Rules $Rules

Blocking by Folder (Package Family Name)#

1
# Deny an entire folder of applications
2
$FolderRules = New-CIPolicyRule `
3
    -FilePathRule "C:\ProgramData\Unwanted\*" `
4
    -Deny
5

6
New-CIPolicy -FilePath ".\DenyFolder.xml" -Rules $FolderRules

Notes on Blocking Windows Components#

• Be careful blocking core Windows components — you can break functionality.
• Test in Audit mode first.
• Some components cannot be fully blocked without also blocking dependencies.
• Windows Updates may re-enable blocked packages — re-enforce after major updates.

Behavior When Option 8 is Enabled#

• Every .sys kernel driver must have an EV signer certificate in its chain.
• Non-EV signed drivers are blocked even in Audit mode — this is one of the few rules that applies in Audit mode.
• Cannot be overridden by supplemental policies (Option 8 is base-policy-only, and EV enforcement is at the kernel level).
• Applies to all base policy types: DefaultWindows, AllowMicrosoft, custom policies.

EV vs. Standard Code Signing#

Setting Option 8#

1
Set-RuleOption -FilePath .\Policy.xml -Option 8
2
# Enables: Required:EV Signers

When to Use Option 8#

• High-security environments where only EV-certified drivers are acceptable.
• Enterprise environments that can vet all installed driver software.
• Do not use in general enterprise without extensive driver auditing — many legitimate drivers use standard code signing.

Options Specific to User Mode#

Kernel-Only Policy Construction#

If you remove the Value="12" (user mode) SigningScenario AND remove all user-mode signer references, the resulting policy only enforces kernel-mode driver control.

When this happens, Merge-CIPolicy automatically removes EKUs that are only relevant to user mode.

Required EKUs for Kernel-Only Policy#

Only four EKUs are needed for a kernel-mode-only policy:

All other EKUs (store apps, scripts, etc.) can be removed from a pure kernel-mode policy, reducing the attack surface.

The Technical Reality#

Pirated/cracked software typically has been modified — executables are patched to remove license checks or to inject additional code. This modification invalidates the file’s Authenticode signature.

When Windows verifies a signed PE file:

1. The Authenticode hash is computed over the file content (excluding the signature blob).
2. This computed hash is compared against the hash stored in the embedded signature.
3. If they don’t match → HashMismatch status.

What This Means for App Control#

• A file with HashMismatch cannot be allowed by any publisher/signer rule — the certificate chain is valid, but the file was tampered with.
• Only a Hash rule could allow it (by its actual PE hash), which means you’re explicitly trusting a tampered file. This is a security violation.
• App Control correctly blocks pirated software even when it appears “signed” — the cracked signature is always invalid.

Detecting HashMismatch Files#

1
# Scan a folder for files with tampered signatures
2
foreach ($File in (Get-ChildItem -Path 'C:\Path\To\Folder' -File -Recurse)) {
3
    $Signature = Get-AuthenticodeSignature -FilePath $File.FullName
4
    if ($Signature.Status -eq 'HashMismatch') {
5
        Write-Output -InputObject $File.FullName
6
    }
7
}

Signature Status Values#

Key Takeaways#

Pre-Reset Procedure for Signed Policy#

1
# Step 1: List all deployed policies
2
CITool --list-policies
3

4
# Step 2: Remove the signed base policy
5
# Note: You must have the signing certificate available
6
# Re-sign and deploy an updated policy with the policy set to "no enforcement"
7
# OR boot from external media to remove from EFI partition manually
8

9
# Step 3: Verify removal
10
CITool --list-policies
11
# Verify your signed policy is no longer listed
12

13
# Step 4: Reboot to confirm
14
# Step 5: Proceed with Reset

Windows 11 22621+ (22H2+)#

On Windows 11 22621 and later:

• .cip files can have any name — even no specific naming convention.
• Random-named .cip files deploy and are enforced correctly.
• GUIDs are no longer required in filenames.

1
# All of these work on 22621+
2
ConvertFrom-CIPolicy -XmlFilePath .\Policy.xml -BinaryFilePath ".\MyPolicy.cip"
3
ConvertFrom-CIPolicy -XmlFilePath .\Policy.xml -BinaryFilePath ".\EnforcedPolicy_v2.cip"
4
ConvertFrom-CIPolicy -XmlFilePath .\Policy.xml -BinaryFilePath ".\{PolicyGUID}.cip"

Legacy Convention (Pre-22621)#

On older builds, the .cip file must be named using the policy’s GUID:

1
# Get the Policy ID from the XML
2
[xml]$policy = Get-Content .\Policy.xml
3
$policyId = $policy.SiPolicy.PolicyID.Trim("{}")
4

5
# Name the cip file with the GUID
6
ConvertFrom-CIPolicy `
7
    -XmlFilePath .\Policy.xml `
8
    -BinaryFilePath ".\{$policyId}.cip"

Deployment Path#

On both legacy and modern systems, the active policy directory is:

1
C:\Windows\System32\CodeIntegrity\CiPolicies\Active\

For EFI-based signed policies (highest security):

1
\EFI\Microsoft\Boot\

The Facts#

• XML IDs (like ID_ALLOW_A_1 or {550ac00d-e432-4b04-a3ba-77826a5ed33f}) are string labels used only in the XML source file.
• When compiled to a .cip binary via ConvertFrom-CIPolicy, IDs are not stored as strings — they are resolved to numeric indices or hashes.
• Therefore: longer IDs in XML = same .cip binary size.
• Using full GUIDs as IDs is completely fine and keeps IDs globally unique.

1
# These produce identical .cip binaries:
2

3
# Short ID style
4
$rule1 = New-CIPolicyRule -DriverFilePath .\App.exe -Level Hash
5
# Generates: ID_ALLOW_A_1, etc.
6

7
# Long GUID ID style (equally valid)
8
# Manual XML edit to use: ID="{550ac00d-e432-4b04-a3ba-77826a5ed33f}"
9
# The .cip output will be byte-for-byte identical to the short ID version
10
# (assuming identical rules)

Practical Implication#

• Use verbose, descriptive IDs in manually authored XML for readability.
• Use GUIDs as IDs for programmatically generated policies to guarantee uniqueness across merged policies.
• Never worry about ID length causing performance issues or larger binaries.

What Disabled Signing Does#

Policy option Disabled:Flight Signing (option 3) removes trust for certificates used to sign Windows Insider / Flight builds.

When this option is enabled in your deployed policy:

• Switching to an Insider channel (Canary, Dev, Beta, Release Preview) is blocked in Settings.
• The option to enroll or switch channels becomes greyed out / unavailable.
• This happens because Insider builds are signed with flight certificates that are no longer trusted.

Restoring Insider Channel Access#

1
# Step 1: Remove the Disabled:Flight Signing option from your policy
2
Set-RuleOption -FilePath .\Policy.xml -Option 3 -Delete
3

4
# Step 2: Recompile and deploy
5
ConvertFrom-CIPolicy -XmlFilePath .\Policy.xml -BinaryFilePath .\Policy.cip
6
CITool --update-policy .\Policy.cip
7

8
# Step 3: Reboot
9
# After reboot, Insider channel options reappear in Settings

Boot Failure Risk from Insider + Flight Cert Removal#

If you:

1. Deploy a policy with flight certs removed (Section 14), AND
2. Switch the device to an Insider channel

The Insider build files are signed with flight certificates. Your policy no longer trusts them. On next reboot, critical OS components may be blocked → boot failure.

1
%%{init: {'theme': 'dark', 'themeVariables': {'primaryColor': '#1a1a2e', 'primaryTextColor': '#e0e0e0', 'primaryBorderColor': '#ffd700', 'lineColor': '#ffd700'}}}%%
2
flowchart TD
3
    A["Policy deployed with\nflight certs removed"] --> B{Device on\nInsider channel?}
4
    B -->|No - Stable| C["✅ Safe\nAll OS files trusted"]
5
    B -->|Yes - Insider| D["⚠️ DANGER\nInsider files signed with flight certs"]
6
    D --> E["Boot: App Control checks\nOS loader and drivers"]
7
    E --> F["Flight cert signer not in\ntrusted signers list"]
8
    F --> G["🚫 BOOT FAILURE\nSystem will not start"]
9
    C --> H["Remove flight certs safely"]

Best Practice: Use Disabled:Flight Signing (Option 3) instead of removing flight cert rules. This disables Insider switching without leaving the system in a risky state — if the option is later removed, certs are still in the policy.

XML Setting#

1
<Settings>
2
    <Setting Provider="PolicyInfo" Key="Information" ValueName="Id">
3
        <Value>
4
            <String>MyEnterprisePolicy-v3</String>
5
        </Value>
6
    </Setting>
7
    <Setting Provider="PolicyInfo" Key="Information" ValueName="Name">
8
        <Value>
9
            <String>Enterprise Allow-List Policy</String>
10
        </Value>
11
    </Setting>
12
</Settings>

Why This Matters#

Without this setting:

• Event 3077 (block): “File blocked by policy [NO POLICY NAME]”
• Troubleshooting requires correlating Policy ID GUIDs from CITool output

With this setting:

• Event 3077: “File blocked by policy: MyEnterprisePolicy-v3”
• Instant identification in production — no GUID lookup required

PowerShell to Add PolicyInfo Settings#

1
# There's no built-in cmdlet for this — use direct XML manipulation
2
[xml]$policy = Get-Content .\Policy.xml
3
$ns = "urn:schemas-microsoft-com:sipolicy"
4

5
# Create Settings element if it doesn't exist
6
if (-not $policy.SiPolicy.Settings) {
7
    $settings = $policy.CreateElement("Settings", $ns)
8
    $policy.SiPolicy.AppendChild($settings) | Out-Null
9
}
10

11
# Save modified policy
12
$policy.Save(".\Policy.xml")

Always add PolicyInfo settings to every policy before production deployment. It costs nothing and is invaluable for incident response and audit trail clarity.

ISG Limitations and Gotchas#

1. ISG requires internet connectivity. Air-gapped systems cannot use ISG.
2. ISG does NOT replace the Microsoft recommended driver block list. ISG cloud queries are separate from HVCI driver blocklist enforcement.
3. Unknown files are denied, not allowed. ISG only grants trust for known-good reputation files.
4. ISG + Managed Installer = over-authorization. Using both dramatically increases the trusted software surface. Avoid in high-security environments.
5. ISG is not suitable for signed policy scenarios. Signed policies should use explicit certificate-based rules.
6. EA caching: Once a file is verified by ISG, subsequent launches use a local Extended Authorization cache (time-limited), avoiding repeated cloud queries.

How MI Works#

1
%%{init: {'theme': 'dark', 'themeVariables': {'primaryColor': '#1a1a2e', 'primaryTextColor': '#e0e0e0', 'primaryBorderColor': '#ffd700', 'lineColor': '#ffd700'}}}%%
2
flowchart TD
3
    MDM["MDM / SCCM / Intune\ndeployment process"] --> MITag{Process tagged\nas Managed Installer?}
4
    MITag -->|Yes| Install["Software installation\nfiles written to disk"]
5
    Install --> ExtAttr["Windows sets Extended Attribute\n(NTFS EA: $KERNEL.SMARTLOCKER.ORIGINCLAIM)\non installed files"]
6
    ExtAttr --> Launch["User launches installed app"]
7
    Launch --> CICheck{Code Integrity\nevaluation}
8
    CICheck --> ExplicitAllow{Explicit allow\nrule matches?}
9
    ExplicitAllow -->|Yes| Allow["✅ Allow"]
10
    ExplicitAllow -->|No| MIEACheck{MI EA\npresent on file?}
11
    MIEACheck -->|Yes| MIAllow["✅ Allow (MI trust)"]
12
    MIEACheck -->|No| ImplicitDeny["🚫 Implicit Deny"]
13

14
    MITag -->|No| NoTag["Files installed WITHOUT\nManaged Installer EA tag"]
15
    NoTag --> Launch2["User launches app"] --> ExplicitAllow

MI Caveats#

1. MI tag is on the file, not the process. If you copy a MI-installed file to a new location, the EA tag may or may not follow (depends on copy method).
2. MI does NOT cover files modified after install. If an installed binary is patched, the EA tag is invalidated.
3. Intune as MI requires specific AppLocker policy to designate Intune as a trusted installer process.
4. Attackers can potentially abuse MI if they can run code under a MI-tagged process. Use alongside strict installer policies.
5. MI is not valid in supplemental policies for all scenarios — use with care.

31.1 FilePath or FileName Rules in Signed Policies#

Using FilePath or FileName rules in a signed policy undermines the security model:

• FilePath rules trust files based on their location, not their content or identity.
• An attacker who can write to that path can place malicious code there and have it trusted.
• FileName rules match on OriginalFileName from VERSIONINFO — can be spoofed by embedding the same filename in a malicious binary.

Rule: Signed policies should ONLY use Hash or certificate-based (Publisher, FilePublisher) rules. Never FilePath or FileName rules.

31.2 FilePath Rules with UNC Paths#

If you must use FilePath rules for network shares (UNC paths like \\server\share\*.exe):

• By default, these are spoofable via DNS/ARP poisoning or share redirection.
• Require UNC Hardening to be enabled (RequireIntegrityAndAuthentication AppLocker setting).
• Without UNC hardening, a FilePath rule for a UNC path is essentially an “allow everything from any server claiming that name.”

1
# Enable UNC path hardening (via AppLocker policy)
2
# This is a Group Policy setting: Computer Configuration\Windows Settings\Security Settings\
3
# Application Control Policies\AppLocker\Properties

31.3 Managed Installer + ISG in High-Security Environments#

Using both MI and ISG together:

• MI trusts anything installed by your deployment tool.
• ISG trusts anything with good cloud reputation.
• Together: vastly expands the trusted software surface.
• Not appropriate for:
  • Signed policy deployments
  • High-security / air-gapped environments
  • Any environment requiring strict application control

31.4 Signer-Only Rules Without FileAttrib (Overly Broad)#

A Signer rule without a FileAttribRef trusts all files signed by that publisher:

1
<Signer ID="ID_SIGNER_BROAD" Name="Microsoft Windows">
2
    <CertRoot Type="TBS" Value="..." />
3
</Signer>

Use FilePublisher level rules (with FileAttribRef) for granular control:

1
<Signer ID="ID_SIGNER_NARROW" Name="Microsoft Windows Notepad">
2
    <CertRoot Type="TBS" Value="..." />
3
    <CertPublisher Value="Microsoft Windows" />
4
    <FileAttribRef RuleID="ID_FILEATTRIB_NOTEPAD" />
5
</Signer>

32.1 HVCI Must Be Set AFTER Add-SignerRule#

1
# WRONG ORDER — HvciOptions gets reset to 0 by Add-SignerRule
2
Set-HVCIOptions -Strict -FilePath .\Policy.xml      # Set first
3
Add-SignerRule -FilePath .\Policy.xml ...             # Resets HvciOptions!
4

5
# CORRECT ORDER
6
Add-SignerRule -FilePath .\Policy.xml -CertificatePath .\Cert.cer -Update
7
Set-HVCIOptions -Strict -FilePath .\Policy.xml      # Set last — stays set

32.2 signtool -fd certHash Behavior#

The -fd (file digest algorithm) parameter in signtool:

• certHash — uses the same hash algorithm as the signing certificate.
• If your cert is SHA-256, -fd certHash = -fd sha256.
• For App Control, always use SHA-256 or stronger.
• Using SHA-1 produces a policy binary that Windows 10 1903+ will reject.

32.3 New-CIPolicy Double Rule for .sys Files#

When New-CIPolicy scans a .sys kernel driver file, it sometimes creates two file rules:

1. One rule in SigningScenario Value="131" (kernel mode) — for driver loading.
2. One rule in SigningScenario Value="12" (user mode) — because .sys files can also be loaded as DLLs in user mode (rare, but Windows checks both).

This is not a bug — it is correct behavior. Both rules are needed for complete coverage.

32.4 Strict BYOVD Kernel-Only Policy#

For a Bring-Your-Own-Vulnerable-Driver prevention policy (kernel-only):

Remove from the DefaultWindows template:

• All user-mode signing scenarios (Value="12")
• Script enforcement options (Options 11, 16)
• Store app enforcement (Option 12)
• All user-mode EKUs except the 4 kernel ones listed in Section 22

Keep:

• Value="131" signing scenario
• Driver block signer rules
• HVCI Strict option
• Option 8 (EV Signers) if desired

32.5 Policy Versioning#

Include a version number in your policy and increment it on every update:

1
<VersionEx>1.0.0.5</VersionEx>

This helps with:

• Event log correlation (Event 3099 shows version)
• Rollback identification
• Audit trail

32.6 Testing Policy Before Enforcement#

Always use Audit mode first:

1
# Enable Audit mode (Option 3 = Enabled:Audit Mode)
2
Set-RuleOption -FilePath .\Policy.xml -Option 3
3

4
# After testing, switch to Enforce by removing Audit option
5
Set-RuleOption -FilePath .\Policy.xml -Option 3 -Delete

Monitor audit events during the testing period:

1
# Watch for blocks in Audit mode
2
Get-WinEvent -LogName "Microsoft-Windows-CodeIntegrity/Operational" |
3
    Where-Object { $_.Id -in @(3076, 3089) } |
4
    Select-Object TimeCreated, Message |
5
    Format-List

32.7 Policy Deployment via Intune (MEM/MDM)#

For MDM-managed deployments:

1. Compile policy: ConvertFrom-CIPolicy -XmlFilePath .\Policy.xml -BinaryFilePath .\Policy.bin
2. Base64 encode: [Convert]::ToBase64String([IO.File]::ReadAllBytes(".\Policy.bin"))
3. Create Intune Custom OMA-URI profile:
   • OMA-URI: ./Vendor/MSFT/ApplicationControl/Policies/{PolicyGUID}/Policy
   • Data type: Base64
   • Value: (paste base64 string)

32.8 Script Enforcement Considerations#

When Enabled:Script Enforcement (Option 11) is active:

• PowerShell runs in Constrained Language Mode for untrusted scripts.
• Only scripts with trusted signatures run in Full Language Mode.
• .ps1, .psm1, .psd1, .vbs, .js, .wsf — all subject to enforcement.
• PowerShell Core (pwsh.exe) is also enforced when the policy covers it.

Constrained Language Mode restrictions:

• No Add-Type (no C# compilation)
• No COM objects
• No direct .NET type access
• No [System.IO.File]:: style calls
• Allowed: basic cmdlets, variables, simple scripts