Application whitelisting is one of the most effective technical controls you can deploy to meet NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 Control CM.L2-3.4.7: restrict the execution of nonessential programs on organizational systems; this post gives a practical, step-by-step approach tailored to small- and medium-sized organizations trying to achieve compliance with a focus on policy, tooling choices, deployment, and ongoing operations.
What CM.L2-3.4.7 requires and the key objectives
This control requires organizations to prevent unauthorized or nonessential software from running on systems that process Controlled Unclassified Information (CUI). The key objectives are: (1) allow only approved code to execute on endpoints and servers, (2) make exception handling auditable and temporary, and (3) maintain mechanisms to update the allowed set as software is authorized or patched. For a compliance framework implementation, treat whitelisting as both a technical control and a documented process (policy, approvals, testing, rollback).
Plan: inventory, policy, and scope
Start with a thorough software inventory and an inventory of hosts that process or can access CUI. Use existing tools (SCCM/ConfigMgr, Intune, JAMF, Lansweeper, or open-source tools like osquery) to produce an initial baseline of executable files, installed applications, services, and scheduled tasks. Draft a concise Application Whitelisting Policy that defines: scope (endpoints, servers, build machines), allowed application logic (publisher-based vs hash-based rules), exception process and maximum exception durations, emergency bypass procedures, and roles (who approves, who deploys).
Technical implementation: tooling and rule design
Choose a tool appropriate to your platform and environment. For Windows, common choices are Microsoft Defender Application Control (MDAC) / Windows Code Integrity, AppLocker, or third-party EDR solutions that include application control. For Linux, use AppArmor or SELinux in enforcing mode or third-party products like CrowdStrike/Carbon Black that include execution control. Use publisher/signature-based rules where possible (e.g., AppLocker: allow by publisher with a minimum signer and product version range) rather than path rules; hash rules are useful for one-off binaries but fragile for updates. Example PowerShell commands you will use in Windows for hashes: Get-FileHash C:\Tools\myapp.exe -Algorithm SHA256; for AppLocker you can create a policy from an audit baseline with New-AppLockerPolicy -AuditOnly and then convert to enforce after test runs.
Example rule design (real-world)
On a small manufacturing subcontractor with 50 endpoints: allow all signed Microsoft and Adobe executables from Program Files (publisher rules), allow company-signed apps from C:\Program Files\CompanyApp\, and create hash rules for a legacy onsite control executable that's updated infrequently. Avoid blanket path rules like allowing anything in C:\Temp. For Linux servers running bespoke build scripts, create AppArmor profiles that permit only the specific binaries and network sockets required by the service and put developer workstations into a less-restrictive mode with monitoring until workflows are stabilized.
Deploy: phased rollout, exceptions, and automation
Deploy in phasesâaudit mode first. Configure policies to log denied executions without blocking for 2â4 weeks to discover false positives. Use automation (Intune/SCCM/GPO/MDM APIs) to roll policies out by device groups: start with a pilot group of 5â10 users, expand to engineering/devices, then to production. Formalize an exception workflow: all exceptions require a ticket that includes business justification, risk acceptance, duration (max 30 days default), and compensating controls (network segmentation, restricted account). Automate revocation and periodic reviewâexceptions should expire and require re-approval; track them in your change control system and link to the asset inventory.
Monitor, maintain, and integrate with patch/change management
Whitelisting is not âset-and-forget.â Log all execution denials and integrate these logs into your SIEM or at minimum central log collection (Windows Event IDs for AppLocker/CodeIntegrity, Linux auditd logs). Create alerts for spikes in denied executions and for attempts to run unsigned code in high-risk groups. Tie whitelisting updates to your patch/change pipeline: when a vendor patch changes an executable, update the allow-list via publisher rules or signed update process rather than using ad-hoc hash updates. Maintain versioned allow-lists in source control and include automated tests in your deployment pipeline that verify critical business apps will still launch under the new policy.
Risks of not implementing and compliance tips
Without application whitelisting you expose CUI systems to malware, lateral movement, fileless attacks, and unauthorized utility use that can lead to data exfiltration or integrity compromisesârisks that auditors and prime contractors take seriously. Practical compliance tips: (1) prefer publisher-based rules to reduce administrative overhead, (2) keep an up-to-date software bill of materials to speed approvals, (3) train helpdesk on how to capture blocked execution artifacts (file hash, path, event log snippet), and (4) document decision rationale for exceptions to survive audits. For small businesses, consider managed services or bundled solutions (e.g., Microsoft 365 Defender + Intune) to reduce operational burden while still meeting CM.L2-3.4.7 requirements.
Implementing application whitelisting to meet NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 Control CM.L2-3.4.7 is a combination of policy, inventory, staged technical controls, and ongoing operations: inventory systems, choose the right platform (AppLocker/MDAC/AppArmor), deploy in audit mode, automate exception lifecycles, integrate logs into monitoring, and tie updates to change managementâdoing so substantially reduces attack surface, supports compliance reporting, and provides a defensible security posture for organizations handling CUI.
