BigFix Application Control: WDAC and App Control for Business Known Limitations

The following limitations are documented by Microsoft for WDAC / App Control for Business. Each limitation includes its impact on deployment and, where applicable, the minimum Windows version or configuration required. These limitations must be considered when designing, deploying, and managing Application Control policies in BigFix-managed environments.

Platform and Version Limitations

1. Multiple Policy Support

Limitation: Multiple App Control policies can be deployed side-by-side only on the following versions:

• Windows 10, version 1903 and later
• Windows 11
• Windows Server 2022 and later

Impact: Supplemental policy and other multiple-policy scenarios require a supported Windows version. Deployments targeting older versions cannot use supplemental policies.

Microsoft reference: Use multiple App Control for Business policies — Microsoft Learn

2. Maximum Active Policy Count

Limitation:

• Systems without the applicable April 9, 2024 or later security update are limited to 32 active policies.
• The 32-policy limit was removed by the applicable security update released April 9, 2024 or later.
• Windows 11 version 21H2 remains limited to 32 active policies regardless of security update status.

Microsoft reference: Use multiple App Control for Business policies — Microsoft Learn

3. App Control Feature Availability Varies by Windows Version

Limitation: Not every App Control capability is available on every supported Windows version. The following table summarizes capability availability:

App Control Capability	Supported Starting Point
Multiple policies	Windows 10 1903+, Windows 11, Server 2022+
Path-based rules	Windows 10 1903+, Windows 11, Server 2022+
Managed Installer	Windows 10, Windows 11, Server 2019+
COM object allowlisting	Windows 10, Windows 11, Server 2019+
Application ID tagging	Windows 10 20H1+, Windows 11
Custom Kernel Signers	Windows 11 24H2+

Microsoft reference: App Control for Business feature availability — Microsoft Learn

4. Device-Wide Policy Scope

Limitation: App Control policies operate at the device level. App Control does not provide per-user or per-user-group policy scoping, unlike AppLocker.

Impact: Organizations that require per-user application control policies must use AppLocker or a hybrid approach, as WDAC cannot restrict or allow applications differently for different users on the same device.

Microsoft reference: App Control for Business feature availability — Microsoft Learn

5. Supported Enforceable File Types

Limitation: App Control enforcement applies only to specific file types. File types not in the supported list are not subject to App Control enforcement. Microsoft documents the following supported file types:

• .sys
• .exe
• .com
• .dll
• .rll
• .ocx
• .msi
• .mst
• .msp
• .ps1
• .vbs
• .js
• .appx

Microsoft reference: App Control for Business feature availability — Microsoft Learn

Policy Structure and Relationship Limitations

1. Supplemental Policy Relationship

Limitation: A supplemental policy can expand only one base policy. Multiple supplemental policies can expand the same base policy, but nesting of supplemental policies is not supported.

The supported relationship is:

Base Policy
├── Supplemental Policy 1
├── Supplemental Policy 2
└── Supplemental Policy 3

A supplemental policy cannot itself act as the base policy for another supplemental policy.

Microsoft reference: Creating a new Supplemental Policy — Microsoft Learn

2. Base Policy Must Allow Supplemental Policies

Limitation: The base policy must be explicitly configured to allow supplemental policies before any supplemental policy can be applied to it.

Impact: Deploying a supplemental policy against a base policy that has not been configured to permit supplemental policies will fail. The base policy must be authored or updated accordingly before supplemental policies can be used.

Microsoft reference: Create a base App Control policy — Microsoft Learn

3. Hash-Based Rules

Limitation: A hash rule identifies a specific file by its cryptographic hash. If the file is updated or modified, its hash changes and the existing hash rule no longer matches the modified file.

Impact: Hash rules require ongoing maintenance whenever approved applications are updated. Microsoft also documents performance considerations for policies that contain very large numbers of hash rules.

Microsoft reference: Understand App Control policy rules and file rules — Microsoft Learn

4. Path-Based Rule Restrictions

Limitation: Path-based rules are available only on:

• Windows 10 version 1903 and later
• Windows 11
• Windows Server 2022 and later

Microsoft documents that path exclusions are not supported, and runtime user-writeability checks are enforced by default. A path that is user-writable at runtime will not be trusted by a path-based rule.

Microsoft reference: App Control for Business feature availability — Microsoft Learn

5. Script Enforcement Version Restrictions

Limitation: The Disabled:Script Enforcement policy option is not supported on Windows Server 2016 or Windows 10 version 1607 LTSB.

Impact: Using this option on those platforms can result in unexpected script-enforcement behavior. Deployments targeting these operating systems must not use this policy option.

Microsoft reference: App Control for Business feature availability — Microsoft Learn

Signed Policy Limitations

1. Signed Base Policy Replacement

Limitation: A signed base policy cannot simply be deleted. To replace a signed base policy, the replacement policy must satisfy all of the following conditions:

• Use the same Policy ID as the policy being replaced.
• Have a version equal to or greater than the existing policy.
• Include the required policy configuration for removal/replacement.

Microsoft reference: Remove App Control for Business policies — Microsoft Learn

2. Signed Policy Version Requirement

Limitation: When replacing a signed policy, the replacement policy must have a version equal to or greater than the existing active policy. Deploying a lower-versioned signed policy is not permitted.

Microsoft reference: Remove App Control for Business policies — Microsoft Learn

3. Signed Policy Signing and Trust Requirements

Limitation: Signed App Control policies require appropriate signing and trust configuration. The signing certificate must be trusted by the policy itself, and signed supplemental policies must have the correct signing relationship with their base policy.

Impact: Signed-policy deployment requires proper certificate and signing configuration to be established in advance. A policy file cannot be treated as signed merely by converting or deploying it; the signing relationship must be explicitly configured.

Microsoft reference: Use signed policies to protect App Control for Business against tampering — Microsoft Learn

4. Signed Base Policy Requires Existing Supplemental Policies to be Signed

Limitation: When signing a base policy that already has supplemental policies, all existing supplemental policies must also be converted to signed policies. The base policy must authorize the certificates used to sign the supplemental policies through the <SupplementalPolicySigner> rule.

Impact: Existing unsigned supplemental policies cannot remain unchanged when the base policy is signed. A coordinated signing of both the base and all associated supplemental policies is required when transitioning to a signed base policy.

Microsoft reference: Use signed policies to protect App Control for Business against tampering — Microsoft Learn

5. Signed Policies Require Secure Boot for Anti-Tampering Protection

Limitation: Microsoft states that UEFI Secure Boot must be enabled on the endpoint for the anti-tampering protection provided by signed App Control policies to take effect. The protection takes effect after the first reboot following policy deployment.

Impact: A signed-policy implementation must not assume that signing alone provides the documented anti-tampering protection. Endpoints must also have Secure Boot enabled; otherwise the anti-tampering guarantee does not apply.

Microsoft reference: Use signed policies to protect App Control for Business against tampering — Microsoft Learn

6. Signing Algorithm and Key Restrictions

Limitation: Microsoft specifies the following requirements for signing App Control policies:

• RSA only — ECDSA is not supported.
• RSA key sizes: 2048, 3072, or 4096 bits.
• SHA-256, SHA-384, or SHA-512 can be used on Windows 11 and on Windows 10 / Server 2019+ with the November 2022 cumulative update.
• All other supported devices support SHA-256 only.
• Policies must be signed according to PKCS #7.

Impact: The signing implementation — including TPM-backed certificates — must generate certificates and signatures that comply with these algorithm and key-size requirements. Non-compliant certificates will result in policy rejection.

Microsoft reference: Use signed policies to protect App Control for Business against tampering — Microsoft Learn

Memory Integrity (HVCI) and Hardware Limitations

1. Memory Integrity (HVCI) and New Signed Base Policies

Memory Integrity is a Windows security feature based on Virtualization-Based Security (VBS), also known as Hypervisor-Protected Code Integrity (HVCI). It moves kernel-mode Code Integrity validation into an isolated environment protected by the Windows hypervisor.

Availability: Memory Integrity is available on Windows 10, Windows 11, and Windows Server 2016 and later. Whether it is enabled by default depends on the Windows version, hardware, installation type, and device configuration. Microsoft states that Memory Integrity is enabled by default on clean installations of Windows 11 on compatible hardware and on Secured-core PCs.

WDAC-specific limitation: Microsoft documents a known issue with deploying new signed App Control base policies on systems where Memory Integrity is enabled.

For Windows 11 updates earlier than 24H2, Microsoft recommends:

1. Deploy the new signed base policy through a script rather than Group Policy or MDM in the affected scenario.
2. Do not use CiTool, RefreshPolicy.exe, or WMI to initiate activation for this specific scenario.
3. Activate the policy by performing a system restart.

This issue does not affect:

• Updates to an already-active signed base policy.
• Unsigned policies.
• Supplemental policies, whether signed or unsigned.
• Systems where Memory Integrity is not enabled.

Microsoft references: Deploy App Control policies using script — Microsoft Learn; Deploy App Control policies via Group Policy — Microsoft Learn; Memory Integrity and VBS enablement — Microsoft Learn

2. Custom Kernel Signers

Limitation: Custom Kernel Signers are available only on:

• Windows 11 version 24H2 and later
• With the applicable April 2026 non-security update applied

The feature requires Secure Boot and has additional signing and platform requirements. It is not supported on ARM64 systems with System Guard Secure Launch.

Microsoft reference: Custom Kernel Signers for App Control for Business — Microsoft Learn

3. Secure Boot Requirements for Custom Kernel Signers

Limitation: Custom Kernel Signers require specific platform security configuration, including Secure Boot, and have additional firmware and signing requirements. This feature is supported only on applicable Windows 11 24H2+ systems.

Impact: Custom Kernel Signer scenarios cannot be treated as a standard WDAC policy deployment. Each target endpoint must meet the required Secure Boot, firmware, Windows-version, and signing prerequisites before this feature can be used.

Microsoft reference: Custom Kernel Signers for App Control for Business — Microsoft Learn

Smart App Control (SAC) Conflict

1. Smart App Control — Existing App Control Policy Conflict

Limitation: On supported Windows 11, version 22572 or later, Smart App Control (SAC) can be enabled only after a clean Windows installation. SAC may start in Evaluation mode and, in most cases, automatically activates after Windows determines that the device is suitable.

When SAC is active, it deploys its own App Control policy. The active SAC .cip policy file is located at:

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

Impact: SAC must be explicitly checked and handled before provisioning a custom WDAC/App Control base policy. The implementation must not assume that the endpoint is free of an existing App Control policy, nor that deploying a custom base policy will automatically replace or remove the SAC policy.

Microsoft references: Smart App Control overview — Microsoft Learn; Application Control for Windows — Microsoft Learn; Test App Signatures with Smart App Control — Microsoft Learn