Off-Topic: This is my first blog post in English. Writing in a different language and even more so speaking in one is a challenge. This blog post is taking me much longer to write but I accept the challenge :-)
In this blog post series, I will explain the requirements and concept behind App Control for Business (preview), also known as Microsoft Defender Application Control (WDAC), and how it can strengthen your security strategy. At the time of writing this blog post series, App Control for Business is in public preview.
Why Application Control is important
In today’s cybersecurity landscape, traditional security solutions react to threats after they occur. In my opinion, there is one problem: There is always a gap between detection and response, and attackers can use this gap to their advantage.
With App Control for Business (ACfB), a better replacement for Microsoft´s Applocker, organization shift from a “trust everything” model to a “trust must be earned” model. Every application, script, or driver must proved as safe before it can run. This approach reduces the attack surface and prevents malicious software from executing, making it much harder for attackers to gain control over your endpoints.
However, this strict security model requires careful planning. Otherwise, it could turn into a nightmare where critical business workloads stop functioning. While ACfB effectively blocks all unwanted and untrusted applications, it may also prevent some legitimate applications from running. My recommendations for implementing are:
- Establish clear processes for permitting applications.
- Standardize your endpoints and configurations across your organization.
- Understand the impact of deploying these policies before rolling them out company-wide.
- Take control of your endpoint – don’t let your employees decide whats runs on them!
Which use cases are interessting for App Control for Business (in my opinion)?
I think the following possible use cases best fit for implementing App Control for Business in environments:
- protecting privilege admin workstations (PAW) or administrative jump systems
- securing control systems for industrial production environments
- protecting other control systems such as ATMs, cash machines or entry systems
- protectiong all windows systems in your company, if you know your infrastrcuture and have controlled software rollout and strict endpoint management
- …
With App Control for Business, organizations can take full control over what runs on their endpoints, reduce attack surfaces, and enhance security.
How can you use App Control for Business?
Windows 11 has a builtin feature called Smart App Control (SAC), which is like an automatic guard on your Windows operating systems which can’t be configured manually but can be disabled. However, SAC is allways disabled if you have done a in-place upgrade from windows 10.
SAC was introduced with Windows 11 Version 22H2 and decides what applications and files are safe (good reputation) and allowed to run. SAC is only available on clean installation of Windows 11. To make the decisions, it uses the Microsoft Intelligent Security Graph which is powered by AI and Machine Learning technologies. This means, the unmanageable version of App Control is already inplace in Windows 11 22H2 and newer and is deeply integrated into Windows core and components known as Code Integrity (CI). Code Integrity is the main actor for enforcing ACfB policies. Code Integrity checks run very early during the system boot to protect the system from the very early beginning (kernel, drivers, signatures).
You can deploy the XML based ACfB policies with:
The policies and the rules can be based on many criteria:
- Attributes of the code-signing certificate(s) used to sign applications or code and their binaries
- Attributes of the applications or codes binaries that come from the signed metadata for files, such as:
- Filename
- Fileversion
- File hash values
- The reputation of the application as determined by Microsoft’s Intelligent Security Graph
- The initiating process used for the installation and deployment of the applications and their binaries (I will explain the concept managed installers in a future blog post.)
- The path from which an application or binary is executed (beginning with Windows 10 1903 and newer)
- The process that launched the application or binaries
Requirements for App Control for Business
The following table lists the Windows editions that support App Control for Business:
| Windows Pro | Windows Enterprise | Windows Pro Education/SE | Windows Education |
|---|---|---|---|
| Yes | Yes | Yes | Yes |
App Control license entitlements are granted by the following licenses
| Windows Pro/Pro Education/SE | Windows Enterprise E3 | Windows Enterprise E5 | Windows Education A3 | Windows Education A5 |
|---|---|---|---|---|
| Yes | Yes | Yes | Yes | Yes |
You can find additional Windows license informations here: Windows Commercial Licensing Overview | Microsoft Learn. The following devices are supported for App Control for Business policies when they are enrolled with Intune:
- Windows Enterprise or Education:
- Windows 10 version 1903 or later
- Windows 11
- Windows Professional:
- Windows 11 SE:
- Windows 11 SE is supported for Educational tenants only. For more information, see App Control for Business policies for Education.
- Azure Virtual Desktop (AVD):
- AVD devices are supported to use App Control for Business policies
- To target AVD multi session devices, use the App Control for Business node in Endpoint Security. However, App Control for Business is device scope only.
- Co-managed devices:
- To support Application Control for Business Policies on co-managed devices, set the slider for Endpoint Protection slider to Intune.
I fyou want to deploy App Control for Business Policies with Intune, what is recommended, you need a additional Intune license.
Differences between App Control for Business and App Locker
| Capability | App Control for Business | AppLocker |
|---|
| Platform support | Windows 10, Windows 11, and Windows Server 2016 or later | Windows 8 or later |
| Edition availability | Available on Windows 10, Windows 11, and Windows Server 2016 or later. | Windows 8 or later. Limited policy support on editions below Enterprise, depending on management method (GP vs. MDM). |
| Management solutions | – Intune (built-in integration) – Microsoft Configuration Manager (limited built-in or via custom deployment) – Group policy – Script (PowerShell) | – Group Policy (primary) – Intune (custom OMA-URI only) – Microsoft Configuration Manager (via OMA-URI or scripts) |
| Rule types supported | – Hash-based – Publisher-based – Path-based – File properties-based – Reputation-based intelligence – Managed Installer (Trusted installer-based) – COM object allowlisting | – Hash-based – Publisher-based – Path-based – File properties-based (limited) – Packaged Apps |
| Platform support | Windows 10, Windows 11, Windows Server 2016 and later | Windows 8, Windows 10, Windows 11, Windows Server 2012 or later |
| Kernel-mode enforcement | Yes, kernel-mode enforcement available. | No kernel-mode enforcement (user-mode only). |
| Per-rule auditing | Yes, detailed auditing and logging available per rule | Yes, basic event logging available per rule |
| Per-script enforcement disabling (Option 11) | Yes (All versions except Windows 10 1607 LTSB and Server 2016) | Not available |
| Multiple policies support | Yes, from Windows 10 (1903) onwards. Supplemental policies extend base policies. | Single active policy per system/user context (no multiple policies) |
| Managed installer support | Yes, available (trust apps installed by trusted software deployment systems, e.g., SCCM, Intune, etc.) | No managed installer support |
| Reputation-based intelligence (Cloud-driven decisions) | Yes, built-in reputation data from Microsoft Intelligent Security Graph. | No reputation-based intelligence support |
| Support for exclusions in path rules | No exclusions in path-based rules; instead, runtime user-writeability check enforced | Yes, supports exclusions in path-based rules (no user-writeability checks) |
| Complexity & deployment difficulty | High initial complexity, but centralized control and robust policy capabilities | Moderate complexity; simpler deployment, but fewer controls and less robust capabilities |
| Update & maintenance overhead | Moderate to high (requires periodic review of hash/publisher/path rules, policy updates) | Moderate (occasional updates of path/publisher rules) |
| Policy deployment speed | Rapid via Intune/MECM custom policies, scriptable | Quick deployment via GP or MDM (simpler policy definitions) |
| Integration with Defender for Endpoint (MDE) | Strong integration (ability to enforce based on Defender detections and reputation) | Limited integration (basic logs only, no reputation-driven enforcement) |
| Rule customization granularity | High granularity (can use multiple attributes including reputation, managed installers, COM objects, etc.) | Moderate granularity (limited to hash, publisher, and path attributes) |
| Support for packaged apps (UWP/AppX) | Yes | Yes (basic allow/block based on publisher/hash/path only) |
| Support for script enforcement | Yes, comprehensive script enforcement including PowerShell, VBScript, JavaScript (with exceptions as per editions) | Basic script control (.exe, .com, .bat, .cmd); limited capability for advanced scripting languages |
| Application tagging (AppID Tagging) | Yes, available on modern editions (for inventory and policy management) | Not available |
Key Features of App Control for Business
The core feature of ACfB is to prevent the execution of unauthorized applications and code and ensuring that only approved and trusted applications and code are allowed on endpoints. This provides broad protection aggainst attacks that starts through files or scripts. For this reason while only approved and trusted applications and code can be executed, ACfB is protecting your endpoints for most (initial) attack vectors.
ACFB is enhancing system integrity with Virtualization-Based Security (VBS). VBS uses special hardware features to create a protected and isolated area inside the Windows operating system, called Virtual Secure Mode (VSM). Important security tasks, such as prevention code injection that could compomise credentials (Local Security Authority Server Service (LSASS) Protection) or checking if applications and code are safe to run, happen in this protected area (Code Integrity Checks). VBS also supports additional important security operations. This combination makes it harder for attackers to bypass Windows security features.
What are the benefits of using App Control for Business?
Stronger security against advanced threats and 0-day exploits
ACfB adds an extra layer of protection against modern cyber threats, including unknown 0-day attacks and malware that doesn’t rely on files. By blocking unapproved apps and scripts, ACfB reduces the risk of attacks, making it harder for hackers to access endpoint. This helps protect sensitive data and keep business operations running.
Helping companies meet their compliance requirements
Many companies need to meet strict compliance rules and regulations, such as HIPAA, PCI DSS, and GDPR. ACfB helps with compliance by ensuring only approved software runs, reducing security risks, and keeping sensitive data safe. This makes it easier for companies to stay compliant.
Concept of App Control for Business
App Control for Business policies are part of the endpoint security in Intune and use the Windows ApplicationControl Configuration Service Provider (CSP) to manage allowed or disallowed applications and bianries in Windows systems.
App Control for Business policy vs Application control profiles: Intune App Control for Business policies use the ApplicationControl CSP. Intune's Attack surface reduction policies use the AppLocker CSP for their Application control profiles. Windows introduced the ApplicationControl CSP to replace the AppLocker CSP. Windows continues to support the AppLocker CSP but no longer adds new features to it. Instead, development continues through the ApplicationControl CSP.
Application Control for Bsuiness Policy formats
There are two ways to setup App Control for Business policies:
- Multiple Policy format consist of
- Base Policy – the main policy which definies the main security rules and definies the scope of protection
- Supplemental Policy – Additional policies that extend or modify the base policy
- Singe Policy format
- A single policy that conatins all rules in one file.
These formats are how ACfB implements its ruleset – throught compiled xml files.
What’s the difference – multiple policies vs. single policy?
Think of it like Group Policy Objects (GPOs):
- Single Policy Format is like Local GPO – you only get one policy for the entire system.
- Multiple Policy Format is like Domain GPOs – you can define multiple policies for more flexible and detailed control – one base policy for all your endpoints and multiple supplemental policies to fit your business workloads.
Single Policy Format
As the name suggests, Single Policy Format means you use one policy to define all rules. While this format offers less flexibility compared to multiple policy format, it is the moste compatible option. Single Policy Format works in all Windows 10 versions including Windows Server 2016 and 2019 and newer. Multiple Policy Format only works on Windows 10 (1903) and newer and also on Windows Server 2025.
Where are these policies stored?
The policies are stored as binary files in:
- EFI System Partition:
\Microsoft\Boot\SiPolicy.p7b - OS Volume:
\Windows\System32\CodeIntegrity\SiPolicy.p7b
This format is the simplest way to implement ACfB, especially for systems that need broad compatibility.
Multiple Policy Format
Instead of using just one policy, Multiple Policy Format lets you combine multiple policies to define WDAC rules. This allows for more detailed control compared to Single Policy Format.
However, it is less compatible:
- Your system must be running Windows 10 (1903) or newer.
- If you want to use more than 32 policies referenced to the base policy, you need the os April 2024 updates; otherwise, you may face issues.
How Does Multiple Policy Format Work?
Think of it like a tree growing from a strong trunk:
- Base Policy = The trunk of the tree, providing the main security rules and structure.
- Supplemental Policies = The branches and leaves, extending the base policy to cover specific needs.
The base policy is the foundation, ensuring stability, while supplemental policies allow you to grow and adapt security rules without changing the core structure. This gives flexibility to apply different rules to different areas without affecting everything at once.
Where Are These Policies Stored?
- OS Volume:
\Windows\System32\CodeIntegrity\CiPolicies\Active\{PolicyId GUID}.cip - EFI System Partition:
\Microsoft\Boot\CiPolicies\Active\{PolicyId GUID}.cip
Multiple Policy Format is ideal for organizations that need detailed security rules and across different endpoints and applications.
Signing Policies
The best ways to protect ACfB policies from being tampered with is by signing them. This provides the highest level of security in Windows, but it also makes them very difficult to remove once applied.
I will explain how to sign policies and manage theme in a future blog post.
Understanding App Control for Business Policy Types: Key Concepts & Terms
When working with App Control for Business, there are different policy formats as I explained above. In addition to different policy formats there are different policy types. Types of policies and their rules help to control which applications can run on a system. Here’s a simple breakdown of the main policy types:
Base Policy
A Base Policy is a standalone policy that works on its own. It can include both allow and deny rules to control which applications, scripts, or drivers can run. On a system their can coexists multiple base policies at the same time.
Supplemental Policy – Expanding the Rules
A Supplemental Policy is like an add-on for a Base Policy—it cannot work on its own. Its only purpose is to extend a Base Policy by adding more allow rules, making the policy more flexible without modifying the original base settings. With a supplemental policy, you cannot deploy deny rules. Explicit deny rules can only be added in the base policy.
By default, any application or binary that is not allowed by a base policy is blocked from execution on the system. Deny rules in a base policy cannot be overridden by allow rules in a supplemental policy.
AppID Tagging Policy – Labeling, Not Blocking
Unlike base or supplemental policies, an AppID Tagging Policy does not allow or block any application or binaries from execution. Instead, it tags applications or files based on predefined rules. These custom tags help other programs identify and handle specific applications differently, such as applying special security policies or firewall rules.
Compare the difference between the policy types:
| Features | Base Policy | Supplemental Policy | AppID Tagging Policy |
|---|---|---|---|
| Can be Standalone | Yes | No | Yes |
| Can Have Deny Rules | Yes | No | No |
| Applies to User and Kernel Mode Files | Yes | Yes | No (User Mode Only) |
| Can be Signed | Yes | Yes | Yes |
| Can the Signed Version be Removed Without Access to the Certificate? | No | Yes | No |
| Can be Used for Auditing | Yes | No | No |
| Supports Enforcement Mode | Yes | Yes | No (Tagging Only) |
| Typical Use Case | Core protection & enforcement of allowed/blocked apps | Extending/overriding Base Policies for specific scenarios | Identifying or categorizing applications without enforcement |
| Policy Merge Behavior | Base or standalone; not merged | Merges with Base Policy | Applied separately; tags apps |
| Complexity & Maintenance Effort | High (Centralized control) | Medium (Scoped changes) | Low (Tagging purposes only) |
| Recommended Audience | Security Admins/IT Operations | App Owners/Project Teams | Inventory Managers/Compliance Teams |
| Impact if Policy Removed or Corrupted | High (Critical Security Impact) | Medium (Scoped Impact) | Low (Minimal Security Impact) |
Policy ID – The Unique Identifier GUID
Every policy gets a unique ID (GUID format). No two policies can have the same ID on one system. If you try to deploy a policy with an existing ID, it will replace the old one.
Audit Mode – Testing Without Blocking
Audit Mode lets you test a policy before enforcing it. In this mode:
- Nothing is blocked, but logs are created for files that would have been blocked in enforced mode.
- This helps you review and adjust policies before applying restrictions.
Enforced Mode – Active Protection
If a policy is not in Audit Mode, it runs in Enforced Mode, meaning:
- Only approved files and programs can run.
- Everything else is blocked.
