Deploying WDAC on Stand‑Alone Windows PCs: methodology, internals, and a real‑world access‑control case

Windows Defender Application Control (WDAC) enforces a positive security model on Windows: only binaries that meet explicit rules are allowed to run. Although most guidance targets enterprise environments (Intune, SCCM, GPO), the same mechanism works on an isolated workstation. This article walks through the full life cycle of a WDAC policy on a non‑managed PC, explains how Windows Code Integrity consumes that policy, and covers operational, cryptographic, and recovery considerations. A practical scenario is included where a local Windows mini‑PC controls physical assets (for example, a gate or garage door), showing why deterministic allow‑listing matters outside classic IT.

1. Threat model and rationale

Unmanaged endpoints are frequently exposed to:

• Opportunistic malware delivered via removable media or phishing
• “Helpful” technician utilities that bypass change control
• Persistence attempts that load unsigned kernel drivers
• Lateral movement from nearby hosts on the same flat network

Such systems often perform a single critical task (HMI stations, CNC controllers, small access‑control PCs). If the host runs arbitrary code, the controlled physical asset becomes vulnerable. Allow‑listing, not signature‑based AV, is the primary mitigation in this context.

2. WDAC architecture in brief

At boot, Windows Code Integrity (CI) reads a binary policy (SIPolicy.p7b) from %SystemRoot%\System32\CodeIntegrity\.

The policy contains:

• Rule options (for example, enable audit, allow supplemental policies)
• File rules (hash, file path, signer rules with version ranges)
• Kernel‑mode rules (drivers) and script enforcement
• Policy ID and policy version (schema)

CI enforces the policy at image‑load time for both user‑mode and kernel‑mode binaries. Scripting languages (PowerShell, WSH) can be restricted via script enforcement options.

3. Policy creation workflow on a lone PC

3.1 Baseline capture

Use New-CIPolicy to snapshot what is currently trusted.

New-CIPolicy -Level SignedVersion -FilePath C:\WDAC\Base.xml -UserPEs 3

Key parameters:

• Level SignedVersion prefers signer‑based rules (publisher cert + version). This keeps the XML smaller and survives program updates from the same vendor.
• UserPEs 3 scans common install paths so that user applications get whitelisted.

3.2 Identification and metadata

Set-CIPolicyIdInfo -FilePath C:\WDAC\Base.xml -PolicyName "Standalone WDAC Audit"

The name and GUID help when adding supplemental policies.

3.3 Binary conversion

ConvertFrom-CIPolicy -XmlFilePath C:\WDAC\Base.xml -BinaryFilePath C:\WDAC\SIPolicy.p7b -UserPEs

The .p7b is a PKCS#7 wrapper for the policy blob, not necessarily signed yet.

3.4 Placement and first reboot

Copy SIPolicy.p7b into C:\Windows\System32\CodeIntegrity\ and reboot. With Audit mode enabled (default rule option 3 present), CI logs but does not block.

4. Instrumentation and log mining

Navigate to Event Viewer → Applications and Services Logs → Microsoft → Windows → CodeIntegrity → Operational.

Relevant IDs:

• 3076 Policy applied successfully
• 3077 Audit: executable would have been blocked
• 3089 Audit: script would have been blocked
• 3099 Audit: driver would have been blocked

Collect several days of activity. Export logs to CSV and parse for unique file paths. PowerShell snippet:

Get-WinEvent -LogName "Microsoft-Windows-CodeIntegrity/Operational" `
  | where {$_.Id -in 3077,3089,3099} `
  | select -Unique @{n="Path";e={$_.Properties[6].Value}} `
  | Export-Csv C:\WDAC\audit_hits.csv -NoTypeInformation

5. Policy refinement

For each legitimate binary in the audit hits, add a rule. Typical commands:

• Add-SignerRule for software signed by a known publisher
• Add-FileRule for unsigned, static binaries (hash rule)
• Add-FilePathRule sparingly, because path rules are weaker

Regenerate the policy or merge rules into Base.xml with Merge-CIPolicy.

6. Enforcement mode

Switch the XML to enforcement:

Set-RuleOption -FilePath C:\WDAC\Base.xml -Option 3 -Delete

Option 3 is “Enabled: Audit Mode”. Deleting it enforces.

Re‑run ConvertFrom-CIPolicy, replace SIPolicy.p7b, reboot. All non‑whitelisted code is now denied.

7. Cryptographic considerations

Production guidance: sign the policy so tampering is detectable and supplemental policies require trusted signatures. On a stand‑alone PC you have options:

7.1 Self‑signed certificate

$cert = New-SelfSignedCertificate -Type CodeSigningCert -Subject "CN=LocalWDAC" `
        -CertStoreLocation Cert:\LocalMachine\My

Export and import this cert to Trusted Root and Trusted Publishers on the same machine. Use SignTool or Sign-CIPolicy (Windows 11 22H2+) to attach the signature.

7.2 Test mode

Rule option 10 (Allow Unsigned Supplemental Policies) or test‑signing boot mode can be used while iterating. Accept the risk: an attacker with admin rights could swap the policy.

7.3 No signature, audit only

Remain in audit if enforcement is not yet acceptable. CI still logs all attempts.

8. Updating and versioning

Only one base policy is loaded. Supplemental policies can extend it (same schema version). On a single PC, replacing the base file is usually simpler. Always increment PolicyID to avoid caching issues.

9. Recovery strategy

• Maintain a local admin account with a secure password
• Know how to boot to WinRE and rename the policy if lockout occurs:

ren C:\Windows\System32\CodeIntegrity\SIPolicy.p7b SIPolicy.bak

• Document every change (store the XML in version control)

10. Comparison with other controls

AppLocker is Group Policy driven and user‑mode only; WDAC enforces kernel drivers, early boot, and user mode. Software Restriction Policies (SRP) lack kernel coverage and are deprecated. WDAC plus Attack Surface Reduction (ASR) rules provides layered protection.

11. Extended rule sources

• Managed Installer model allows software deployed by a designated installer
• Intelligent Security Graph (ISG) option relies on Microsoft cloud reputation to permit known good binaries—useful but less deterministic for isolated PCs
• FilePublisher and MinimumFileVersion tolerate minor updates

12. Physical access systems: a concrete application

Consider a logistics bay where a Windows mini‑PC operates a relay that lifts a gate or garage door. This PC logs each open/close event, integrates with cameras, and receives remote service sessions. Without allow‑listing, a ransomware dropper from a USB stick can launch, disable logging, and script the door to remain open overnight. WDAC blocks any unapproved executable, script host, or unsigned driver, so only the vendor’s control software and signed updates run. If you are modernizing or installing such systems and need the physical side handled professionally, visit doorpro.com.

13. Operational pitfalls and mitigations

Pitfall: forgetting kernel drivers
Mitigation: run Device Guard Signing scenario or include DefaultWindows entry to allow Microsoft inbox drivers plus explicit vendor drivers.

Pitfall: policy drift after Windows feature upgrades
Mitigation: retest in audit after each major build, regenerate if necessary.

Pitfall: technician utilities
Mitigation: maintain a supplemental policy template for approved tools; temporarily layer it, then remove.

Pitfall: mixing policy schema versions
Mitigation: check the SchemaVersion attribute; use Update-CIPolicyVersion when merging old fragments.

14. Metrics and validation

Success criteria: zero unexpected blocks in enforcement over a defined observation window, minimal audit noise, clear change‑control logs. Instrumentation can be exported to a SIEM, but on a single PC even periodic CSV exports suffice. Monitor a checksum of SIPolicy.p7b to detect tampering.

15. Legal and human factors

On isolated systems, be explicit about the process to introduce new software. Provide technicians with a pre‑approved toolset or a request channel. WDAC is effective but unforgiving; communicating the policy with stakeholders reduces emergency overrides that weaken the model.

16. Conclusion

WDAC on a stand‑alone Windows machine is a controllable, well‑documented process: capture, audit, refine, enforce, sign. The mechanism operates below typical user‑privilege attacks and closes an entire class of execution vectors. In environments where a single PC mediates access to physical property or critical processes, the effort is justified by a measurable reduction in risk.

Appendix A. Minimal command sequence

# 1. Baseline
New-CIPolicy -Level SignedVersion -FilePath C:\WDAC\Base.xml -UserPEs 3
Set-CIPolicyIdInfo -FilePath C:\WDAC\Base.xml -PolicyName "Standalone WDAC Audit"
ConvertFrom-CIPolicy -XmlFilePath C:\WDAC\Base.xml -BinaryFilePath C:\WDAC\SIPolicy.p7b -UserPEs
Copy C:\WDAC\SIPolicy.p7b C:\Windows\System32\CodeIntegrity\

# 2. After auditing, enforce
Set-RuleOption -FilePath C:\WDAC\Base.xml -Option 3 -Delete
ConvertFrom-CIPolicy -XmlFilePath C:\WDAC\Base.xml -BinaryFilePath C:\WDAC\SIPolicy.p7b
Copy /Y C:\WDAC\SIPolicy.p7b C:\Windows\System32\CodeIntegrity\

Appendix B. Common Event IDs

• 3075 Policy file was found and parsed
• 3076 Policy successfully activated
• 3077 Audit: blocked executable (user mode)
• 3088 Enforced: blocked executable
• 3099 Audit: blocked driver
• 3100 Enforced: blocked driver

This expanded treatment aims to satisfy readers who expect more than a quick how‑to and positions the content as a technically credible reference while remaining accessible.