BigFix Application Control: WDAC Rule Types, Selection Criteria, and Use Cases

BigFix Application Control supports six WDAC rule types — Publisher, Hash, File Path, File Attributes, Package/PFN, and COM — each suited to a different application identification method and control objective. This topic describes when to use each rule type, the benefits it provides, and illustrative example scenarios to guide rule selection in enterprise environments.

BigFix Application Control supports multiple WDAC rule types for identifying and controlling applications and application components. The appropriate rule type depends on how the application or component should be identified and the level of control required.

Table 1. WDAC Rule Types: Identification Method, Selection Criteria, and Benefits
Rule Type When to Use Benefit / Why Use It
Publisher Use when trust is based on the software publisher/signer, especially for applications that receive signed updates. Reduces the need to create new rules for applicable signed updates when the publisher/signing information remains trusted.
Hash Use when you need to control a specific executable, DLL, or file version. Simplifies control of applications and their files within a controlled location.
File Path Use when an application runs from a known and controlled local directory or network share, and the location is part of the trust decision.
Note:
If a user-writable location must be allowed, Option 18 – Disabled: Runtime FilePath Rule Protection may be required, which reduces the protection provided by the default runtime check and has security implications.
 Simplifies control of applications and their files within a controlled location.
File Attributes Use when an application can be reliably identified using its file metadata, such as OriginalFilename, ProductName, or FileVersion. The required metadata, particularly OriginalFilename, must be present in the file for the rule to match. Provides an alternative to hash- or path-based identification by using reliable file metadata, and can be used to target a specific application version when the relevant version information is available.
Package / PFN Use for applications distributed as AppX/MSIX packages that have package identity information, such as a PFN and also the executable is physically located inside the package. While creating rule, AC v2.x does not require binary to create rule. Controls the packaged application using its package identity rather than individual executables.
COM Use when a specific COM component/class (CLSID) needs to be separately controlled when another application or process attempts to activate it. Provides separate control over COM activation, independent of the calling application's normal execution authorization.
Example Scenarios

The following software examples are illustrative only. Other applications can use the same rule type when the corresponding criteria apply.

  • Publisher: Applications such as Google Chrome, Mozilla Firefox, or Adobe applications can use Publisher rules when trust is based on the publisher/signer and applicable signed updates should continue to be trusted.
  • Hash: Applications such as Notepad++, Postman, or AnyDesk can use Hash rules when only a specific tested executable or version should be authorized.
  • File Path: An internal business application, WDAC Manager, or other application can use a File Path rule when it runs from a known and controlled directory.
  • File Attributes: Applications such as Notepad++ or Chrome can use File Attributes rules when file name, product name, version, or other supported metadata provides a suitable identification method.
  • Package / PFN: Applications such as Spotify, Microsoft Photos, or Calculator, when installed as AppX/MSIX packages, can be identified by their package identity/PFN and the executable must be physically located inside the package.

    Traditional Win32 applications installed as standalone .exe/.msi applications, such as a conventional Notepad++ or Chrome installation, generally do not have AppX/MSIX package identity and therefore require another applicable rule type.

  • COM: An application such as Notepad++ may have a COM-based component. If another application or process attempts to activate that component using its CLSID, a COM rule can be used to explicitly allow or block that activation.
Note:
The applications listed above are illustrative examples only. An application may be controlled using different rule types depending on its signing information, installation method, file characteristics, package identity, COM dependencies, and the organization's security requirements. The selected rule type should therefore be based on the application control objective and the characteristics of the application or component, rather than on the application name alone.