This post provides a practical, step-by-step guide to configuring Windows AppLocker so you can implement a deny-all, permit-by-exception (whitelist) policy that supports meeting NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 control CM.L2-3.4.8 — including planning, testing, deployment, and ongoing governance advice tuned for small businesses that handle Controlled Unclassified Information (CUI).
Why deny-all, permit-by-exception is required and what AppLocker provides
NIST / CMMC require limiting executable programs to authorized software only; a deny-all, permit-by-exception approach is the strongest practical way to meet that objective because it prevents unknown or malicious binaries and scripts from running by default. AppLocker is Microsoft’s supported application control technology on modern Windows Enterprise and Education editions (and Windows Server) that provides rule collections for Executables, Windows Installer, Scripts, Packaged apps, and (on supported OS builds) DLLs — all of which you can set to audit or enforce.
High-level planning and inventory (Compliance Framework specific)
Start with a scoping exercise: identify endpoints in-scope for CUI handling and map business-critical applications. For Compliance Framework purposes, document your scope, risk acceptance, and baseline. Run AppLocker in Audit mode for at least 7–14 days in a representative pilot OU to collect real execution inventory. Use built-in AppLocker logging (Applications and Services Logs → Microsoft → Windows → AppLocker) to capture what is actually running, and supplement with software inventory tools (SCCM/ConfigMgr, Intune inventory, or third-party asset inventory) to build a whitelist candidate list. Document the inventory and tie each app to a business justification and owner — this evidence will be needed for assessments against CM.L2-3.4.8.
Implementation steps — configuring AppLocker via Group Policy
1) Ensure AppLocker prerequisites: AppLocker requires the Application Identity service (AppIDSvc) to be running on target hosts. Set it to Automatic and start it (e.g., Start-Service AppIDSvc in PowerShell) before enforcement. 2) Create a new GPO in Group Policy Management Console (gpmc.msc) scoped to a pilot OU. Navigate to Computer Configuration → Policies → Windows Settings → Security Settings → Application Control Policies → AppLocker. 3) In the AppLocker console, use the “Create Default Rules” button as a starting point (these create default allow rules for Windows and Program Files). 4) Switch each rule collection (Executable, Windows Installer, Script, Packaged app, DLL if available) to Audit mode first (right-click → Properties → Configure rule enforcement → set to “Audit only”). This lets you gather data without blocking. 5) After auditing, convert the allowed application list into explicit Allow rules — prefer Publisher rules for signed installers and vendor-signed binaries (e.g., Microsoft, Adobe) with wide version ranges to permit updates; use File hash rules only when publisher or path rules are not viable; avoid path rules that point to user-writable directories (e.g., Downloads, Desktop) unless you control those paths.
Practical GPO rule choices and technical details
For a deny-all permit-by-exception posture, your GPO should contain only Allow rules for explicitly approved binaries; do not rely on implicit allowances. Once you have a vetted rule set from audit data, change enforcement to “Enforce rules” for the rule collections you are ready to lock down. Export the policy as XML (AppLocker console → Export Policy) for review and for deployment to other OUs. You can also obtain the local policy using Get-AppLockerPolicy -Local and deploy with Set-AppLockerPolicy/Import from PowerShell when automating distribution — but always test these scripts in a lab first and keep the exported XML under version control.
Deployment strategy and small-business example
Small business example: a 30-seat engineering firm subcontracting for a DoD prime. Phase a rollout: pilot 5 users in a pilot OU (developers and engineers) for 2–4 weeks in Audit mode, produce a whitelist from logs, create Allow rules for Office (use Microsoft publisher rules), Adobe Reader (publisher), company-signed engineering tools (publisher rules tied to internal code-signing cert), and a limited set of utility tools using hash rules. Move to enforcement for Executable and Script collections first, leaving DLL rules in Audit until you stabilize. Have a documented exception process: a user requests an application by filing a ticket including business justification; the SOC/IT reviews, tests, and adds a rule (or routes to build team for signing). Run the pilot, then expand to the rest of the fleet in waves, using GPO link order and security filtering to target groups.
Compliance tips, operational best practices, and risks if you don’t implement
Best practices: run AppLocker in Audit mode before enforcement; keep a change-control workflow for rule changes; use publisher rules for vendors where possible (they handle updates); sign your own internal tools with an enterprise code signing cert and build publisher rules; periodically review AppLocker event logs and integrate with your SIEM; maintain a documented emergency bypass procedure that requires documented approvals. Note that AppLocker requires Enterprise/Education SKUs — if you only have Pro, plan for an upgrade or consider Software Restriction Policies as an interim measure.
Risk of non-implementation: without deny-by-default whitelisting you are significantly more exposed to ransomware, unauthorized or unsigned tools, living-off-the-land binaries (LOLbins) misuse, and software supply chain attacks. For organizations handling CUI, this exposure increases the likelihood of a compliance finding during NIST or CMMC assessment, potential contract impacts, and loss of trust with government customers.
Monitoring, maintenance, and evidence for assessors
Once enforced, collect and retain evidence: exported AppLocker XML policies, GPO change records, audit logs from Applications and Services Logs → Microsoft → Windows → AppLocker (showing audit → enforcement transition and rule hits), and the exception request ticketing history. Automate periodic review (quarterly) of rules and re-run audits after major software rollouts or OS upgrades. Keep a rollback plan (GPO versioning, emergency GPO that reverts to Audit if necessary) and test restore procedures so you can recover quickly from unintended blocks.
Summary: Implementing a deny-all, permit-by-exception AppLocker policy to satisfy NIST SP 800-171 Rev.2 / CMMC 2.0 CM.L2-3.4.8 is a multi-step process: scope and inventory your environment, run AppLocker in Audit mode to build an allowlist, favor publisher rules and code signing, pilot and phase enforcement via GPO or automated deployment, and maintain governance with documented change control and monitoring. For small businesses, a measured pilot, strong exception workflow, and thorough logging will minimize business disruption while meeting compliance objectives and materially reducing the risk of unauthorized code execution.
