Frequently Asked Questions (FAQs)

This topic lists frequently asked questions for Application Control 2.0.

Customer scenario: In Application Control 2.0, a customer needs to block a single application. How can this use case be implemented?
In Application Control 2.0, first, the base policy needs to be deployed, which is a Default Deny (also known as Zero Trust) policy. Next, you can deploy supplementary policies to allow specific applications. This may appear to need more steps, but it is more secure, as it does not allow the application process to start by itself. For convenience, though, Application Control 1.0 is available to customers who would like to continue using that version.
  • Step 1: Base Policy - Deny All (except for necessary Microsoft processes, BigFix agent, etc.)
  • Step 2: Supplementary Policy - Allow (Application)
So, in Application Control 2.0, only the approved software runs; everything else is blocked by default. The working mechanism of Application Control 2.0 is based on Windows Defender Application Control (WDAC), which has this limitation. In WDAC, you first deploy the policy in audit mode, then check which applications run in your environment, and add those apps to your allowlist. Once you have confirmed the allowlisted applications, you deploy the policy in enforced mode.

So, it is not possible to block a single application directly. You have to follow the above 2-step process to implement this use case. Hence, in this scenario, first deploy the Default Deny base policy, then deploy the supplementary policy allowing all the applications you need. Do not include the application you want to block in the supplementary policy, and you will fulfill the scenario above.

Customer scenario: Supplementary policy action fails if only the application name is specified in Application Control 2.0.
Problem statement: A customer needs to apply the following 2 scenarios using only the name of the application in Application Control 2.0:
  • Apply Default Microsoft™ Base Enforced Policy and then allow only specific applications for users.
  • Apply Default Microsoft™ Base AllowAll Policy and then block only specific applications for users.
The Supplementary policy has to be applied using the application name so as not to depend on the application's installation path. The supplementary policy is successfully applied using the file path name, but when specifying the application name (such as chrome.exe), the action fails with exit code 30. In the supplementary policy log file, there is the warning [WARN] Path not found: chrome.exe.
Note: The customer was using Application Control 1.0 with no issues.
Additional question: Since Application Control 2.0 executes PowerShell scripts, what happens if the PowerShell application is blocked by a policy?
Solution: Refer to the following points for a solution to this scenario:
  • Application Control 2.0 does not support using only application names when creating supplementary policies; one has to provide the entire path of the executable/application to create the supplementary policies.
  • Application Control 2.0 relies entirely on PowerShell scripts. PowerShell execution should be allowed for deployment, management, and configuration of Application Control 2.0 on the endpoints. The answer to this additional question is to allow PowerShell execution from the BESClient folder or, more specifically, from the site folder under __BESData.
  • Lastly, Supplemental Policies only work to extend the allowlist of the base policy. They do not facilitate extending the block list.
Customer scenario: Deployment failures of the "Deploy Default Microsoft Base Policy v2.0" task on a Windows 11 machine

Problem statement: Deployment failures of the "Deploy Default Microsoft Base Policy v2.0" task on a Windows 11 machine were caused by existing WDAC policies and security enforcement mode. The machine was already in Enforcement Mode with HVCI active, which likely conflicted with the deployment. The issue was identified as being caused by existing WDAC policies on the endpoint that conflicted with the deployment.

Solution: This issue is caused by existing WDAC policies on endpoints that conflict with the deployment. Application Control 2.0 will introduce a sanitization step as a prerequisite in the initial deployment phase to ensure that any existing WDAC policies on the machine do not interfere with the new deployment.
Note: This scenario is still under technical review. When a solution is provided, the solution in this FAQ will be updated.

Common Allowlisting Use Cases for Rule Levels in WDAC / Application Control 2.0

Publisher Rule Level
  • Recommended Use Case

    Publisher-based rules are the preferred and most scalable approach when:

    • The application binaries are digitally signed.
    • The certificate chain is trusted by the Windows kernel.
    • Future application updates are expected.
  • Advantages
    • Automatically trusts newer versions signed by the same publisher.
    • Reduces operational overhead.
    • Avoids frequent policy updates after application upgrades.
  • Example

    Applications such as: Microsoft Office, Google Chrome, and Adobe Acrobat can usually be trusted using publisher rules because their signing certificates are recognized and trusted by the operating system.

  • Limitations

    Publisher rules may fail when:

    • The application is unsigned.
    • The certificate chain is incomplete or untrusted.
    • Kernel-mode trust validation rejects the signer.
  • Typical Scenarios

    Some applications may require multiple supporting binaries and DLLs that are blocked under restrictive WDAC base policies such as DefaultWindows_Enforced. In such scenarios, Publisher rules may fail because the application certificate chain is not fully trusted by the Windows kernel during policy evaluation. For example:

    • firefox.exe
    • notepad++.exe
Hash Rule Level
  • Recommended Use Case

    Hash-based rules should be used when:

    • Publisher rules are not working.
    • The application signer is not trusted.
    • Specific binaries must be tightly controlled.
    • Security requirements demand exact file integrity validation.
  • Advantages
    • Most secure rule type.
    • Trusts only the exact approved binary.
    • Prevents unauthorized file replacement.
  • Example

    Applications with multiple dependent binaries and DLLs may require Hash-based allowlisting to ensure all required components are individually trusted. For example, the installation path: C:\Program Files\Mozilla Firefox\*

  • Limitations
    • Any file modification or upgrade changes the hash.
    • Policies must be updated after every application update.
  • Typical Scenarios


    Applications containing the following often require Hash-based allowlisting:

    • Multiple DLL dependencies.
    • Embedded runtime components.
    • Non-standard signing chains.
Path Rule Level
  • Recommended Use Case

    Path-based rules are useful when:

    • Applications are installed in controlled directories.
    • Frequent updates occur.
    • Managing individual hashes is operationally difficult.
  • Advantages
    • Simplifies management.
    • Automatically allows updated binaries within the approved directory.
    • Suitable for enterprise-managed application folders.
  • Example

    A Path rule can be used when the installation directory is protected and writable only by administrators. For example, the path: C:\Program Files\Mozilla Firefox\*.

  • Limitations
    • Less secure compared to Hash or Publisher rules.
    • Any executable copied into the approved path may also run.
    • Requires strict NTFS permission controls.
  • Typical Scenarios

    Commonly used for:

    • Enterprise application installations.
    • Vendor-managed software directories.
    • Internal packaged applications.
File Name Rule Level
  • Recommended Use Case

    File Name rules are suitable when:

    • Specific executable names must be allowed regardless of location.
    • Legacy applications have inconsistent installation paths.
    • Operational simplicity is prioritized.
  • Advantages
    • Simple implementation.
    • Useful for legacy environments.
  • Example

    Allowing executables solely based on file name may unintentionally trust malicious files renamed to approved names. For example:

    • firefox.exe
    • notepad++.exe
  • Limitations
    • Weak security model.
    • Malicious binaries can be renamed to approved file names.
    • Not recommended for high-security environments.
  • Typical Scenarios

    Used primarily for:

    • Testing environments.
    • Temporary exceptions.
    • Legacy operational compatibility.
Recommended Enterprise Approach
Table 1. Rule Level Summary
Rule Level Security Level Recommended Usage
Publisher High to Low Preferred for trusted signed applications.
Hash Very High to High Best for untrusted or sensitive binaries.
Path Medium to Low Suitable for controlled installation directories.
File Name Low to Low Only for temporary or legacy scenarios.
Recommended Enterprise Approach
Table 2. Rule Level Summary
Rule Level Security Level Recommended Usage
Publisher High to Low Preferred for trusted signed applications.
Hash Very High to High Best for untrusted or sensitive binaries.
Path Medium to Low Suitable for controlled installation directories.
File Name Low to Low Only for temporary or legacy scenarios.
General Recommendation

When applications require multiple supporting binaries and DLLs that are blocked under restrictive WDAC base policies, and the application signing chain is not fully trusted by the Windows kernel:

  • Publisher rules may not be reliable.
  • Hash-based allowlisting is generally the most secure approach.
  • Path-based rules may be considered if the installation directory is tightly controlled.
  • File Name rules should be avoided in production environments wherever possible.