BigFix Application Control v2.x: Frequently Asked Questions

This FAQ covers BigFix Application Control v2.x across six topic areas: product fundamentals and architecture, Base and Supplemental Policy design, WDAC policy signing and TPM key protection, Secure Boot and boot recovery, phased deployment and enforcement introduction, Code Integrity telemetry, rule level selection (Publisher, Hash, Path, and File Name), policy naming conventions, and deprecated v2.x distributed-model scenarios.

Application Control v2.x FAQs

What is BigFix Application Control 2.0?
BigFix Application Control 2.0 provides centralized management and deployment of Windows Defender Application Control (WDAC) policies through the BigFix platform. It enables administrators to create, validate, sign, publish, deploy, and monitor WDAC policies while Windows Code Integrity performs the actual application authorization and enforcement on Windows endpoints.
What does BigFix Application Control 2.0 control?
Application Control manages which applications are permitted or prevented from executing on managed Windows endpoints based on the configured WDAC policy. Policies can use supported WDAC rules such as:
  • Publisher
  • File hash
  • File path
  • Signer/certificate-based rules
The exact enforcement behavior depends on the rules and options configured in the Base and Supplemental Policies.
What is the difference between BigFix and Windows Code Integrity?
BigFix provides the management, deployment, and monitoring layer. Windows Code Integrity / WDAC provides the local enforcement layer. In other words: BigFix manages and deploys the policy → Windows Code Integrity enforces the policy.
What is a Base Policy?
The Base Policy establishes the foundational WDAC security posture for an endpoint. It defines the primary trust model, policy configuration, and core application authorization rules on which Supplemental Policies depend.
What is a Supplemental Policy?
A Supplemental Policy extends an existing Base Policy with additional application authorization rules. A Supplemental Policy does not replace the Base Policy.
Can multiple Supplemental Policies be deployed?
Yes. Multiple Supplemental Policies can extend a Base Policy, subject to the Windows WDAC policy architecture and applicable policy relationships.
Does deploying or updating a policy require a system restart?
The solution supports policy updates without a reboot where supported by the Windows platform and configured policy options. However, reboot requirements can vary depending on the Windows version/build, policy type, HVCI/Memory Integrity configuration, and policy-signing configuration.
How are WDAC policies protected from unauthorized modification?
Policies requiring signed updates are digitally signed before deployment. Where TPM-backed signing is configured, the private signing key is protected by the TPM and is not exported during the normal signing workflow.
Is the signing private key stored on the BigFix server?
No. Policy signing is performed within the designated WDAC Management environment. The BigFix publication and deployment infrastructure receives the signed policy artifact and does not require access to the private signing key.
What happens if the primary signing certificate becomes unavailable?
An emergency/recovery signing capability can be maintained as part of the policy trust configuration. The emergency signer can support approved recovery scenarios such as primary signing infrastructure failure, certificate expiration or rotation, or loss of the primary signing capability.
Should the emergency signer be configured in advance?
Yes. The emergency/recovery signer should be configured in advance as part of the Base Policy trust configuration. Preconfiguring the signer allows an authorized recovery signer to be trusted if the primary signing infrastructure becomes unavailable or a recovery operation is required.
Can the signing certificate be rotated?
Yes. Certificate rotation is supported as part of the signing certificate lifecycle. The replacement certificate must be incorporated into the appropriate policy trust configuration before it is required for policy updates.
Does the solution require a TPM?
TPM/vTPM is recommended for environments requiring hardware-backed protection of policy-signing keys. Where TPM-backed signing is configured, the signing private key is protected by the TPM on the designated management system.
Which Windows versions are currently supported?
The current architecture targets:
  • Windows 10 version 1903 and later
  • Windows 11
  • Windows Server 2022 and later
Specific WDAC capabilities and policy behavior can vary by Windows release and build.
Does Application Control require Secure Boot?
Secure Boot is an important part of the trust chain for signed WDAC policies, particularly for early-boot policy validation. Customers should maintain the supported Secure Boot configuration for production systems using signed Application Control policies.
What happens if a WDAC policy prevents Windows from starting?
A policy that blocks a boot-critical component can potentially result in a boot failure. Recovery may require Windows recovery mechanisms, policy replacement or removal, firmware-level recovery procedures, or manual intervention.
If the endpoint uses BitLocker, a boot or Secure Boot configuration change may also trigger BitLocker recovery. Customers should ensure that their established BitLocker recovery process is available for applicable recovery scenarios.
Does Boot Audit on Failure guarantee recovery?
No.
Boot Audit on Failure is a mitigation for applicable boot-critical driver blocking scenarios. It does not guarantee recovery from every type of boot failure or protect against all forms of policy tampering.
What happens if Secure Boot is disabled?
Disabling or changing Secure Boot configuration can affect the trusted boot state and may trigger BitLocker recovery on systems where BitLocker protection is enabled.
Customers using BitLocker should ensure that their established BitLocker recovery process is available before changing Secure Boot settings during testing or recovery.
Can a local administrator remove or modify a deployed policy?
The architecture does not provide complete protection against every form of local administrative tampering.
Organizations should therefore use appropriate operating-system administrative controls in addition to Application Control.
What happens if the BigFix Agent itself is blocked?
If the BigFix Agent is blocked by the Application Control policy, the endpoint may not be able to receive remediation actions through BigFix.
Manual recovery may therefore be required in such scenarios.
Which Code Integrity events can be used to track Application Control policy and enforcement status?
Windows provides multiple Code Integrity events in the Microsoft-Windows-CodeIntegrity/Operational log. The following events are particularly useful for Application Control troubleshooting and enforcement verification:
Table 1. Event - Use Table
Event Use
3076 Main App Control block event in Audit Mode. Indicates that the file would have been blocked if the policy were enforced.
3077 Main App Control block event in Enforcement Mode. Indicates that the file was blocked by the policy.
3089 Provides signature information associated with a blocked or audit-blocked file and can help investigate the reason for the policy decision.
3099 Indicates that an App Control policy was successfully loaded.
Additional Code Integrity events may be generated depending on the Windows version, policy configuration, and scenario.
How can the generated WDAC policy XML be reviewed before deployment?
The generated policy XML can be reviewed using the Submit a WDAC XML Policy for Review task provided by BigFix Application Control.
This task allows administrators to review the generated policy XML before publishing or deploying the policy and verify that the policy configuration and intended rules are correct.
How does BigFix determine whether a policy was successfully deployed?
BigFix deployment status can be used to verify whether the policy deployment action completed successfully on the endpoint.
The Windows Code Integrity event log should be used separately to verify policy loading and application enforcement behavior.
Does BigFix continuously collect Code Integrity events?
No. The current design uses an on-demand collection model. Telemetry is collected through explicit BigFix actions rather than continuously streaming all Code Integrity events from every endpoint.
How much historical Code Integrity data is collected?
The current reporting design limits collection to a maximum 14-day lookback window.
Does BigFix itself enforce application execution?
No.
BigFix manages, deploys, and monitors the policy. Windows Code Integrity performs the actual application authorization and enforcement.
Can policies be updated without modifying the Base Policy?
Yes, where the requirement can be addressed through a Supplemental Policy.
Supplemental Policies provide a mechanism for adding application authorization rules while keeping the foundational Base Policy unchanged.
What happens if a Supplemental Policy fails?
A Supplemental Policy does not replace the Base Policy. The Base Policy remains the foundational policy and continues to establish the endpoint's underlying security posture.
Is the Intelligent Security Graph (ISG) included?
ISG is not included in the current release.
Is Managed Installer supported?
Managed Installer is not included in the current release.
Is kernel/HVCI enforcement included?
No. The current release focuses on user-mode application control.
Deeper kernel-level scenarios, including comprehensive WHQL and HVCI validation, are outside the current validation scope.
Does the solution support Microsoft Active Directory Certificate Services (AD CS)?
Microsoft AD CS / Enterprise PKI integration is not available in the current release.
Can customers use their own certificate authority?
Customer-managed certificate infrastructure can be used where it meets the supported WDAC policy-signing requirements.
Is AppID Tagging supported?
AppID Tagging is not included in the current release.
How are policies distributed to endpoints?
The general deployment flow is:
Policy Creation → Validation → Review → Signing → BigFix Publication → Endpoint Deployment → Windows Code Integrity Activation → Enforcement and Reporting.
What happens when a policy is retired?
The active policy should not simply be deleted from an endpoint. The supported retirement workflow establishes an appropriate replacement or unblocking state before the retired policy is removed.
What should customers validate before enabling enforcement?
Customers should validate:
  • Business-critical applications
  • BigFix Agent functionality
  • Required network drivers and services
  • Boot-critical components
  • Security/EDR software
  • Application installers and updaters
  • Base and Supplemental Policy behavior
  • Generated policy XML using the Review Fixlet
  • Recovery procedures
  • Signing and recovery-signer configuration
Should Application Control be deployed to the entire environment at once?
No. A phased deployment is recommended:
Test/Audit → Review → Refine → Validate → Pilot Enforcement → Broader Enforcement
Microsoft recommends deploying App Control policy changes in Audit Mode before proceeding to Enforcement and using deployment rings to control the rollout.
What are the main limitations of the current release?
The current release has the following scope limitations:
  • ISG is not included.
  • Managed Installer is not included.
  • Advanced kernel/HVCI validation is outside the current validation scope.
  • AppID Tagging is not included.
  • AD CS / Enterprise PKI integration is not available.
  • Certain boot failures may require manual or offline recovery.
  • Complete protection against local administrative tampering is not provided.
  • Blocking the BigFix Agent may require manual recovery.
  • Code Integrity telemetry uses an on-demand collection model with a 14-day lookback limit.
  • Some WDAC behaviors vary by Windows version and build.
Where can administrators check why an application was blocked?
Administrators can review the Microsoft-Windows-CodeIntegrity/Operational event log for events related to the blocked application.
The applicable Base and Supplemental Policy configuration can also be reviewed to determine whether an explicit deny rule applies to the application.
How should Application Control enforcement be introduced?
Application Control enforcement should be introduced in a phased approach:
  1. Deploy the policy in Audit Mode to a test environment.
  2. Exercise normal application usage and review the Code Integrity events generated by applications that would be blocked under enforcement.
  3. Review and refine the policy based on the observed results.
  4. Review the generated policy XML using the Review Fixlet.
  5. Validate the updated policy in the test environment.
  6. Deploy the policy in Enforcement Mode to a controlled pilot group.
  7. Monitor the pilot environment and confirm expected application behavior.
  8. Gradually expand deployment to additional production groups.
Recommended approach:
  • Audit → Review → Refine → Validate → Pilot Enforcement → Broader Enforcement
Microsoft recommends deploying App Control policy changes in Audit Mode before proceeding to Enforcement, monitoring the resulting events, and using deployment rings for controlled rollout.
What is the recommended recovery strategy?
Customers should establish recovery procedures before enabling enforcement. The recovery plan should account for:
  • An authorized emergency signing capability.
  • Secure Boot recovery procedures.
  • Policy rollback/replacement procedures.
  • Offline/manual recovery capability.
  • Controlled pilot deployment.
  • Signing certificate lifecycle management.
  • For endpoints using BitLocker, the organization's established BitLocker recovery process should be available for applicable recovery scenarios.
What is the security boundary in the architecture?
The architecture separates:
  • Policy Management → Policy creation and validation
  • Policy Signing → Cryptographic trust and signing-key protection
  • BigFix Publication → Controlled policy distribution
  • BigFix Deployment → Endpoint targeting and deployment
  • Windows Code Integrity → Local policy validation and enforcement
This separation limits the need for deployment infrastructure to have access to policy-signing private keys.
What is the recommended deployment model?
The recommended approach is:
Establish signing and recovery trust → Create and validate the Base Policy → Review the generated XML → Test applications and recovery scenarios in Audit Mode → Refine and validate → Deploy to a pilot group in Enforcement Mode → Monitor → Expand deployment gradually.
Is there a naming convention for policies?
Yes. Policy names must follow the required naming convention:
  • Base Policy: The name must start with Base_.
  • Supplemental Policy: The name must start with Supp_.
  • The name may contain only alphanumeric characters (A–Z, a–z, 0–9) and underscores (_).
  • Spaces and special characters are not permitted, including -, ., /, \, @, #, %, &, (, ), and :.
Table 2. Policy Type Example Names
Policy Type Valid Example Invalid Example
Base Base_StandardPolicy Base-StandardPolicy
Supplemental Supp_ChromePolicy Supp Chrome Policy
Base Base_Windows11_01 Base.Windows11.01
Supplemental Supp_Chrome_01 Supp@Chrome#01
When can the Package rule type be used for an application?
The Package rule type can be used for an application installed as an AppX/MSIX packaged application, typically under C:\Program Files\WindowsApps.

Verify it using below PowerShell command:Get-AppxPackage *<application-name>* | Select Name, PackageFamilyName, InstallLocation

If the application has a Package Family Name (PFN) and is installed as an AppX/MSIX package, it can be considered for a Package rule.
When should I use the COM rule type?
COM (Component Object Model) is a Windows technology that allows applications to use functionality provided by other software components. Use the COM rule type when a specific COM object (identified by its CLSID) needs to be allowed or explicitly denied by the App Control policy. This can be useful when an application requires a COM object that is not allowed by the policy, or when a specific COM object needs to be blocked.
The CLSID can be identified from Event ID 8036 (COM object blocked) in Event Viewer or from the Windows Registry.
What should I do if the application binary cannot be installed, downloaded, or made available on the designated WDAC Management Node?
If the application binary cannot be made available on the designated WDAC Management Node, the required application rule can be created manually using the Microsoft App Control Policy Wizard as an alternative workflow.
  1. Open the App Control Policy Wizard: App Control Policy Wizard
  2. Create the required application rule using the appropriate rule type and application metadata.
  3. Generate the WDAC policy XML from the wizard.
  4. Copy the generated XML content and provide it to the Custom Policy XML Generation workflow in BigFix Application Control v2.x.
  5. Continue with the standard BigFix Application Control workflow for policy signing, publication, deployment, and enforcement through the applicable Fixlet/Task.

Deprecated Application Control v2.x FAQs

Important:
  • Tasks from Application Control v2.x that used the distributed model — including per-endpoint self-signed certificate creation, direct Base and Supplemental Policy deployment on individual endpoints, and related Fixlets — are deprecated.
  • Refer to the Deprecated Application Control v2.x Fixlets and Tasks chapter for reference documentation on those tasks.
  • The FAQs in this section are applicable to the deprecated Application Control v2.x only.
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 Deprecated WDAC / Deprecated 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 3. 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.