App control policy verification: WDAC beyond a GPO marker

What Is App Control Policy Verification?

App control policy verification establishes which App Control for Business policies a Windows device has, how they arrived, and whether their observed behavior matches the approved application rules. A Group Policy Object (GPO) containing a deployment path describes configuration intent. It does not establish that the target obtained the binary, loaded the intended version, or enforced it.

For an Active Directory team investigating a WDAC deployment finding, the useful outcome is a device-specific evidence record. Identify the policy and its distribution owner, test required workflows in audit mode, review proposed rules, and approve enforcement with a recovery route. Keep unreachable devices and missing measurements visible as unresolved cases.

This guide uses Microsoft Learn documentation checked on 4 October 2026 and the collector implementation identified below. Commands are documented examples for an authorized Windows administrator; they were not executed against a Windows estate for this article. No successful rollout, endpoint coverage, CVE exposure or ANSSI compliance is claimed.

Our HVCI memory integrity guide explains isolation of kernel code integrity in memory and driver compatibility. This procedure verifies application authorization policies, their format and their events. Record both protections when relevant, with separate evidence for each.

How It Works: Policy Format and Distribution Must Agree

Microsoft's GPO deployment procedure supports single-policy format only. Its setting is under Computer Configuration → Administrative Templates → System → Device Guard → Deploy App Control for Business. The enabled setting names a local or UNC deployment path; a share must be accessible to the computer accounts. The procedure ends with a test-computer restart.

The same page directs administrators deploying a new signed base policy with memory integrity enabled to use script deployment and activate it by restarting. Do not replace that instruction with a live refresh merely because a management tool offers one. Microsoft's script procedure identifies the affected pre-24H2 Windows 11 case and the required copy-to-system-and-EFI locations followed by restart. Check the target build and the relevant procedure before selecting an activation mechanism.

Microsoft's deployment overview distinguishes XML with a PolicyID for multiple-policy format from the single-policy case. It describes conversion to a binary and deployment through MDM, Configuration Manager, scripts or Group Policy. A missing GPO marker cannot exclude these other distribution methods.

Before changing anything, create a record for each pilot population:

These fields are a proposed investigation record, not measurements from a customer environment. Resolve missing ownership before issuing changes: an administrator should be able to explain which source will distribute the next version and which operator can withdraw it.

Detection: Inventory the Target and Correlate Events

Step 1: Identify policies on the pilot device

The CiTool technical reference documents --list-policies, with alias -lp, as listing policies whether active or inactive. CiTool is included from Windows 11 22H2 and Windows Server 2025. On a supported target, preserve the complete output:

CiTool --list-policies

The documented output includes Policy ID, Base Policy ID, friendly name, version, signature status, file presence and activation status. Compare identities and versions with the approved artifact. The reference defines Is Currently Enforced as whether the policy file is active; do not use that label alone to decide whether its rule options are in Audit or Enforcement mode.

For systems outside that tool's availability, use the corresponding OS-specific deployment procedure and retained policy artifacts. An unavailable command is an inventory limitation, not proof that App Control is absent. Separate a failed collection from a successful inventory with no expected policy.

Step 2: Read the correct logs

In Event Viewer, inspect Applications and Services Logs → Microsoft → Windows → CodeIntegrity → Operational and Applications and Services Logs → Microsoft → Windows → AppLocker → MSI and Script. Microsoft's event reference documents these signals:

The MSI and Script log is not available on Windows Server Core. App Control also does not ordinarily log each allowed binary. Consequently, quiet logs are not a complete execution inventory or proof that all applications are authorized.

Retain event details with device, time, policy identity where supplied, observed options and the workflow exercised. Compare the loaded-policy observation with the intended identity, version and mode. Investigate unexpected IDs and explain any version change before attributing later activity to the rollout.

Step 3: Exercise required work in audit mode

Run authorized installation, startup, update and administrative workflows on the pilot. Ask application owners to identify dependencies and expected results. Track what was actually exercised; an idle machine supplies little compatibility evidence. Preserve collection gaps and log-retention limits alongside the review.

Our Defender ASR rules via GPO guide compares behavior-rule GUIDs, actions and exclusions with endpoint configuration. Here the review concerns App Control policy identity, format and binary/script decisions. An ASR configuration observation cannot close this App Control investigation.

Remediation: Review Audit Evidence Before Enforcement

Step 1: Approve a recoverable pilot

Name the deployment owner, application-rule approver and recovery operator. Define which devices enter the pilot, which workflows must pass, and which failures stop expansion. Ask explicitly: which format and distribution method are in use, are new signed bases combined with memory integrity, and who approves exceptions and rollback?

Microsoft recommends deployment rings and audit evaluation before enforcement in its deployment overview. Choose the method from the OS/format/signature record above. Preserve the previous artifacts and a tested recovery runbook before distributing the candidate.

Step 2: Generate candidates, then review each rule

Microsoft's audit-event workflow requires an already deployed audit-mode policy. Run its documented command in an elevated PowerShell session to generate candidate rules from audit events:

$EventsPolicy=$env:userprofile+"\Desktop\EventsPolicy.xml"
$EventsPolicyWarnings=$env:userprofile+"\Desktop\EventsPolicyWarnings.txt"
New-CIPolicy -FilePath $EventsPolicy -Audit -Level FilePublisher -Fallback SignedVersion,FilePublisher,Hash -UserPEs -MultiplePolicyFormat 3> $EventsPolicyWarnings

This example produces multiple-policy format; it is not a binary to deploy through the single-policy GPO setting. Review the generated XML and warnings. Retain only rules for approved applications, binaries and scripts, then merge into the base or use a permitted supplemental policy. Files no longer on disk do not receive automatically generated rules through this process.

Run the required workflows again after the reviewed audit policy is deployed. Keep disallowed activity disallowed; an audit event is not an instruction to trust its source. Investigate unexplained events and unresolved warnings before progressing.

Step 3: Prepare the enforcement artifact

Microsoft's enforcement procedure begins from reviewed audit policies. It copies the audit XML into a separate enforcement file and optionally changes policy identity for side-by-side deployment. Decide deliberately whether to replace in place or use a new identity; supplemental-policy relationships must follow that choice.

With $EnforcedPolicyXML pointing to the prepared copy, the documented mode change is:

Set-RuleOption -FilePath $EnforcedPolicyXML -Option 3 -Delete

The same procedure recommends considering options 9 and 10 for the first enforcement ring: a pre-boot option to disable enforcement for one boot session and audit fallback when a boot-critical driver is blocked. Convert the reviewed XML to binary, apply the required signing process, and deploy using the selected supported method. Preserve the artifact identity and expected mode in the change record.

After activation, repeat inventory, loaded-policy review and functional tests. Examine enforcement events against approved expectations. Advance the next ring only after named reviewers accept the evidence, exceptions and recovery readiness; the GPO edit itself is not the closure criterion.

Step 4: Test withdrawal and recovery

Microsoft's policy removal procedure first requires disabling the distribution method so the policy is not redeployed. For a signed base, deploy a signed replacement with option 6, the same PolicyId, an equal-or-higher version and an UpdatePolicySigners section. Sign it with a certificate listed in the original policy's UpdatePolicySigners section, then restart before removal. Do not assume a local deletion safely withdraws a signed base.

On a supported system, after satisfying those prerequisites, run the documented removal example from an elevated command window:

CiTool.exe -rp "{PolicyId GUID}" -json

Replace the placeholder with the approved policy ID. Restart requirements vary by Windows version and policy signature; use the linked procedure for the target. The runbook must also cover an unbootable device, authorized firmware access and recovery-key availability. Test that route on recoverable equipment before enforcement.

How EtcSec Detects This

EtcSec's etc-collector includes BP039_CCI_NOT_DEPLOYED. At reviewed commit 6a04c34b5ce01d3abf747c1d1c2f671eaa1d5e85, its Detect() in bp039-cci-not-deployed.go iterates every collected GPOPolicies entry, skipping missing policy/settings objects. Any nonempty DeviceGuardConfigCIPolicyFilePath string returns nil, meaning no finding. Otherwise it returns Low severity, Count 1, including when no policies were collected.

That branch checks one marker. It validates neither the referenced file nor its binary format, signature, version, target scope or enforcement state. A positive value in an unrelated GPO is enough to suppress the finding; the code does not calculate resultant policy for each device. Count 1 is a finding count, not a count of unprotected computers.

The reviewed registrypol_parser.go requires a key containing codeintegrity to map ConfigCIPolicyFilePath. The real GPO setting uses the DeviceGuard branch, so this path does not populate the expected marker. Separately, CollectGPOPolicies in smb/client.go inserts a policy object even when its files were not successfully read. An object in the map is therefore not proof of a successful settings collection.

Attach the independent device inventory, approved policy artifacts, relevant events and rule-review decisions to the investigation. Resolve collection failures explicitly. Close the operational question from that evidence and the agreed acceptance criteria, rather than editing a GPO solely to silence a marker check.