BigFix Application Control v2.0.0: WDAC Use Cases and Enforcement Model

WDAC Enforcement Model

The OS kernel validates the policy at boot and at runtime. Only code that is explicitly allowed by the active policy is permitted to execute.

If the Base Policy is tampered with or becomes invalid (for example, deleted, modified, replaced, or signed by an untrusted certificate), the Code Integrity engine may take one or more of the following actions:

• Block policy loading.
• Prevent execution of unsigned code.
• Enter a recovery state.

In the worst case, a tampered or invalid Base Policy results in a system boot failure (Blue Screen of Death, BSOD), which may require secure physical intervention to recover.

Kernel-Level Policy Verification

The kernel verifies the following conditions before applying a WDAC policy:

• Digital Signature Validity: The policy must be correctly signed.
• Trusted Signer: The signing certificate must chain to a trusted root.
• Version Monotonicity: The incoming Base Policy version must be greater than or equal to the currently active version (prevents rollback attacks).
• Policy Structure and GUID Integrity: A Supplemental Policy must correctly reference the Base Policy GUID.
• Enforcement State Consistency: The enforcement mode must be valid and intact.

BigFix–WDAC Integration Overview

BigFix orchestrates the full WDAC policy lifecycle for application control across managed endpoints. The integration covers policy generation, deployment, health monitoring, and on-demand telemetry collection.

Policy Generation and Deployment

Base and Supplemental WDAC policies are generated locally on each endpoint using TPM-backed self-signed keys. The Custom Site hosts the approved application inventory file (apps.csv), while the External Site hosts the Default Policy XML template used as the starting point for Base Policy generation.

BigFix Analysis

Three types of BigFix Analysis support the integration:

• Health Analysis

  Detects missing or tampered WDAC policies and classifies each endpoint into one of three states: Healthy, Drift, or Recovery Eligible.

• Reporting Analysis

  Collects active policy GUIDs and version numbers, along with Code Integrity event logs. This analysis is globally activated to provide immediate forensic visibility following on-demand telemetry collection.

• On-Demand Telemetry

  Blocked execution event data is collected via BigFix Tasks and stored in ACL-hardened folders. The collection process automatically self-heals to ensure performance, data integrity, and a centralized audit trail.

Known Limitations and Risks

• Local administrators can remove self-signed certificates from an endpoint. This disrupts policy update orchestration; however, the existing EFI-resident policy remains enforced until the next successful policy update.
• EFI path misconfiguration can result in a BSOD across affected endpoints at scale.
• Covers policy deployment and enforcement using self-signed certificates only. Emergency policy procedures and recovery scenarios are out of scope for the MVP.

Use Case 1: Foundational Infrastructure Provisioning

Objective: Enable trusted, decentralized application control using endpoint-based certificates.

In this use case, each managed endpoint generates and uses its own self-signed certificate for local WDAC policy validation. Policy governance is handled centrally through Custom Site orchestration, while policy artifacts are hosted centrally and enforced locally on each endpoint.

Governance Site Components

The Custom Site provides the following artifacts used for policy governance:

• apps.csv

  The approved application inventory. This file defines which applications are permitted to execute across managed endpoints.

• {custom}_policy.xml

  The application control enforcement rules. This XML file defines the allowlist and blocklist rules that form the basis of the generated WDAC policy.

Outcomes

• Decentralized trust model — each endpoint maintains its own signing certificate.
• Simplified infrastructure provisioning — no centralized certificate authority is required.
• Scalable endpoint-level enforcement — policies are generated and enforced independently on each managed endpoint.

The infrastructure setup workflow is initiated by the Master Operator, who uploads apps.csv to the Custom Site. This single action makes the approved application inventory available to all subscribed endpoints for subsequent policy generation tasks.

Use Case 2: Policy Enforcement – Base and Supplemental Policies

Objective: Establish a hardware-bound, integrity-enforced WDAC foundation operating in a fail-closed model, enabling controlled and governed application management.

Base Policy Execution

The Base Policy task executes the following steps on each managed endpoint:

1. Purges unauthorized .cip files from <EFI System Partition>\EFI\Microsoft\Boot\CiPolicies\Active\ to establish a clean and consistent baseline before deployment.
2. Retrieves the WDAC Default Template XML from the External Site, scans currently installed applications, and merges the results using PowerShell (New-CIPolicy and Merge-CIPolicy) to build the Base Policy.
3. Generates a unique self-signed signing key — TPM-backed if a TPM is available, otherwise software-stored. Signs the compiled policy, deploys the .cip file to the EFI partition, and triggers RefreshPolicy to activate enforcement.

Supplemental Policy Updates

Supplemental Policy updates follow this process on each endpoint:

1. Retrieve apps.csv from the Custom Site.
2. Generate the Supplemental Policy XML, referencing the active Base Policy GUID.
3. Apply the update only if the incoming version number is greater than the currently active version (anti-rollback enforcement).
4. Sign the Supplemental Policy using the TPM-backed key if available, otherwise using the software-stored key.
5. Apply the signed policy and trigger RefreshPolicy. The WDAC kernel enforces the updated rules immediately.

Security Highlights

• Hardware-pinned enforcement: TPM-backed key generation ensures that each endpoint's signing key is unique and hardware-bound, preventing key reuse or transfer across machines.
• Anti-rollback: Monotonic version enforcement prevents older, potentially less secure policy versions from being reinstated.
• In-memory policy management: Policies are managed in memory during generation and signing; no plaintext policy content is written to disk during the process.

Base Policy Generation Workflow

The following steps describe the end-to-end Base Policy generation workflow initiated from the BigFix Console:

1. The Master Operator triggers the Base Policy Task from the BigFix Console, either by selecting a pre-defined Base Policy or by providing a custom policy XML.
2. The BigFix Root Server dispatches the task/fixlet to the target Endpoint Device.
3. The Endpoint Device executes the Base Policy task:
   1. Initiates Base Policy generation using the custom XML or the default WDAC Policy XML.
   2. Purges unauthorized policy files from the EFI partition.
   3. Validates the policy version (anti-rollback check).
   4. Signs the compiled policy.
   5. Applies the signed policy and calls RefreshPolicy.
4. WDAC enforces the Base Policy on the endpoint.
5. The Supplemental Policy is enforced in conjunction with the Base Policy.

Supplemental Policy Generation Workflow

The following steps describe the end-to-end Supplemental Policy generation workflow:

1. The Master Operator triggers the Supplemental Policy Task from the BigFix Console, either by passing a parameter directly or by pointing to apps.csv.
2. The BigFix Root Server dispatches the task/fixlet to the target Endpoint Device.
3. The Endpoint Device executes the Supplemental Policy task:
   1. Initiates Supplemental Policy generation using the current Base Policy and the contents of apps.csv.
   2. Validates the incoming policy version against the active version (anti-rollback check).
   3. Signs the compiled Supplemental Policy.
   4. Applies the signed policy and calls RefreshPolicy.
4. WDAC enforces the updated Supplemental Policy rules on the endpoint.
5. The Supplemental Policy operates in conjunction with the Base Policy to determine the final set of allowed and blocked applications.