Mastering App Control for Business#

Implications#

• Reduces the attack surface by preventing unauthorized code execution
• Blocks malicious software before it can run — not after
• Requires careful planning; misconfiguration can disrupt legitimate workloads

Implementation Recommendations#

flowchart LR
    A[Application Executes] -->|Traditional| B[Antivirus Scans]
    B --> C{Known Threat?}
    C -->|Yes| D[Block / Quarantine]
    C -->|No| E[Allow — GAP EXPLOITED]
    A -->|App Control for Business| F{Trust Verified?}
    F -->|Approved & Trusted| G[Allow Execution]
    F -->|Unknown / Untrusted| H[Block — Zero Gap]
    style E fill:#7f1d1d,color:#fca5a5
    style H fill:#14532d,color:#86efac
    style G fill:#14532d,color:#86efac

Smart App Control (SAC) — Built-in, Unmanaged#

Windows 11 (22H2+) ships with Smart App Control (SAC), an automatic, unmanaged enforcement layer that evaluates application reputation using Microsoft’s Intelligent Security Graph (AI/ML-backed).

Important: SAC is disabled on systems upgraded from Windows 10 in-place. It is only active on clean installs of Windows 11.

SAC is powered by Code Integrity (CI), a Windows core component that enforces policy checks beginning at system boot — covering the kernel, drivers, and signed binaries.

Managed Deployment Options#

Rule Criteria Supported#

• Code-signing certificate attributes
• Binary metadata: filename, file version, file hash
• Application reputation (Microsoft Intelligent Security Graph)
• Managed installer trust (e.g., Intune, SCCM)
• Execution path (Windows 10 1903+)
• Initiating/parent process

flowchart TD
    A[App Control for Business] --> B{Deployment Method}
    B --> C[Microsoft Intune\nRECOMMENDED]
    B --> D[PowerShell\nCmdlets]
    B --> E[Group Policy\nNot Recommended]
    B --> F[MECM\nLimited Support]
    C --> G[XML Policy Upload\nor Binary .cip]
    D --> H[CiTool / Scripts]
    E --> I[SiPolicy.p7b]
    style C fill:#1e3a5f,color:#93c5fd
    style E fill:#3b1515,color:#fca5a5

Supported Windows Editions#

License Entitlements#

Supported Device Configurations (via Intune)#

An additional Intune license is required to deploy ACfB policies via Intune.

flowchart LR
    A[Windows Device] --> B{Edition?}
    B --> C[Pro / Pro Edu / SE]
    B --> D[Enterprise E3/E5]
    B --> E[Education A3/A5]
    C & D & E --> F{Enrolled in Intune?}
    F -->|Yes| G[Full ACfB Support]
    F -->|No| H[GPO / Script Only]
    G --> I{OS Version?}
    I -->|Win 10 1903+| J[Multi-Policy Format]
    I -->|Win 11| K[Full Feature Set]
    style G fill:#14532d,color:#86efac
    style J fill:#1e3a5f,color:#93c5fd
    style K fill:#1e3a5f,color:#93c5fd

Execution Control#

Prevents unauthorized applications, scripts, and drivers from running. Only approved and trusted code executes. This eliminates the majority of initial attack vectors that rely on malicious file or script execution.

Virtualization-Based Security (VBS) Integration#

ACfB leverages VBS to create a protected isolation layer — Virtual Secure Mode (VSM) — within Windows. Security-critical operations occur inside VSM:

• LSASS Protection — prevents credential dumping via code injection
• Code Integrity Checks — validates applications before execution in hardware-isolated context

This makes it significantly harder for attackers to bypass Windows security controls even with elevated privileges.

Defense Against Advanced Threats and Zero-Days#

By blocking unapproved applications and scripts, ACfB reduces exposure to:

• Unknown zero-day exploits
• Fileless malware
• Living-off-the-land (LotL) attack techniques

Regulatory Compliance Support#

ACfB helps organizations demonstrate compliance with frameworks including:

Single Policy Format#

One policy file containing all rules.

• Most compatible — works on all Windows 10 versions including Server 2016/2019+
• Simpler to manage but less flexible
• Analogous to a Local GPO

Storage locations:

1
EFI System Partition:  \Microsoft\Boot\SiPolicy.p7b
2
OS Volume:             \Windows\System32\CodeIntegrity\SiPolicy.p7b

Multiple Policy Format#

Combines a Base Policy with one or more Supplemental Policies.

• Requires Windows 10 1903+ or Windows Server 2025
• Supports up to 32 supplemental policies (April 2024 update removes this limit)
• Analogous to Domain GPOs — layered, scoped control
• Base Policy = trunk; Supplemental Policies = branches

Storage locations:

1
OS Volume:             \Windows\System32\CodeIntegrity\CiPolicies\Active\{PolicyId GUID}.cip
2
EFI System Partition:  \Microsoft\Boot\CiPolicies\Active\{PolicyId GUID}.cip

Signed Policies#

Policies can be cryptographically signed to prevent tampering or unauthorized removal. This is the most secure configuration but requires careful key management.

Signing details and management procedures will be covered in a future part of this series.

flowchart TD
    subgraph Single["Single Policy Format"]
        direction TB
        SP[SiPolicy.p7b\nOne file — all rules]
    end
    subgraph Multiple["Multiple Policy Format"]
        direction TB
        BP[Base Policy\nCore Rules + Deny List]
        SUP1[Supplemental Policy A\nVendor Apps]
        SUP2[Supplemental Policy B\nDev Tools]
        SUP3[Supplemental Policy N\n...]
        BP --> SUP1
        BP --> SUP2
        BP --> SUP3
    end
    Single -.->|Less flexible\nMax compatibility| RESULT[Policy Deployed\nto Endpoint]
    Multiple -.->|Flexible\nWin 10 1903+ only| RESULT
    style SP fill:#1c2330,color:#e6edf3
    style BP fill:#162032,color:#58a6ff
    style SUP1 fill:#1c2330,color:#e6edf3
    style SUP2 fill:#1c2330,color:#e6edf3
    style SUP3 fill:#1c2330,color:#e6edf3

Base Policy#

• Standalone — operates independently
• Can contain both allow and deny rules
• Multiple base policies can coexist on a single system

Supplemental Policy#

• Cannot operate independently — extends a Base Policy
• Can only add allow rules (no deny rules)
• Deny rules in a base policy cannot be overridden by supplemental allow rules
• Useful for scoping application exceptions without modifying the core base policy

AppID Tagging Policy#

• Does not allow or block execution
• Applies custom labels/tags to applications based on defined rules
• Tags enable other systems (firewalls, compliance tools) to treat tagged apps differently
• User-mode only; does not apply to kernel-mode files

Comparison Matrix#

flowchart TD
    BASE[Base Policy\nAllows + Denies\nStandalone] -->|extends| SUP[Supplemental Policy\nAllow rules only\nCannot standalone]
    BASE -.->|independent of| TAG[AppID Tagging Policy\nLabels only\nNo Allow/Deny]
    TAG --> FW[Windows Firewall\nProcess-scoped rules]
    TAG --> CM[Compliance Tools\nIdentity-aware policy]
    SUP --> BASE
    style BASE fill:#162032,color:#58a6ff,stroke:#2563eb
    style SUP fill:#1c2330,color:#a5b4fc
    style TAG fill:#1a1f0a,color:#86efac
    style FW fill:#1c2330,color:#e6edf3
    style CM fill:#1c2330,color:#e6edf3