Requirement
NIST SP 800-171 REV.2 / CMMC 2.0 Level 2 - Control - CM.L2-3.4.8 – Apply deny-by-exception (blacklisting) policy to prevent the use of unauthorized software or deny-all, permit-by-exception (whitelisting) policy to allow the execution of authorized software.
Understanding the Requirement
This control requires your organization to decide and document whether you will use a deny-by-exception (blacklist) approach or a deny-all, permit-by-exception (whitelist) approach, to control what software can run on your systems. The policy must list which software is allowed (for whitelisting) or which software is prohibited (for blacklisting), and the specified approach must be enforced across the environment so only approved applications execute. Following the NIST SP 800-171 REV.2 / CMMC 2.0 Level 2 framework, the goal is to reduce risk from unauthorized or malicious software by restricting execution to known, approved programs.
Technical Implementation
- Choose and document your approach: Create a short policy that explicitly states whether you will use whitelisting or blacklisting. For most SMBs handling sensitive data, prefer whitelisting (deny-all, permit-by-exception) because it provides stronger protection and simpler ongoing maintenance.
- Inventory and classify software: Take an inventory of all installed and business-required software across endpoints and servers. Classify each item as "explicitly allowed", "explicitly denied", or "needs review" and store this in a simple spreadsheet or CMDB.
- Select enforcement tooling: Use tools that support application control — options include built-in OS features (Windows AppLocker or Microsoft Defender Application Control), your endpoint protection platform (EPP/EDR with application control), or a commercial application whitelisting solution. Ensure the chosen tool can centrally deploy policies and report blocks.
- Define an approval and exception process: Create a lightweight request workflow for new software: a requester submits a business justification, IT/security reviews and tests the software, and approved items are added to the whitelist (or denied items to the blacklist). Track approvals and periodic revalidation.
- Deploy in monitoring mode, then enforce: Pilot the policy in audit-only mode on a small group of systems to collect usage and false-positive data, refine rules, and then move to full enforcement. Maintain logging/alerting so incidents and blocked execution attempts are visible to IT/security.
- Maintain and review: Schedule regular reviews (quarterly or aligned to change windows) to update the allowed/denied lists, remove obsolete entries, and ensure software updates or patches are tested and allowed. Integrate this into change management.
Example in a Small or Medium Business
A 45-person engineering firm decides to implement a whitelist to protect its design data. The IT lead inventories standard workstations and produces a baseline whitelist that includes the OS, Microsoft Office, company-specific CAD tools, the endpoint agent, and approved browser extensions. They use the company’s existing EDR product to enforce application control and start with a 10-user pilot that is set to audit-only so they can capture blocked attempts without disrupting work. During the pilot they discover a lab tool the engineers use occasionally; engineers submit a short justification and IT validates it in a sandbox before adding it to the whitelist. After two weeks of pilot tuning, the IT lead moves enforcement to all endpoints and configures central logging so blocked execution attempts create tickets for review. The firm documents the software approval process in a one-page SOP and trains employees to request exceptions through the helpdesk. Quarterly reviews and an annual re-inventory ensure the whitelist remains current and that new business needs are captured before enforcement causes meaningful disruption.
Summary
By formally choosing and documenting a whitelist or blacklist approach, maintaining an accurate software inventory, using centrally managed enforcement tools, and establishing a simple approval and review process, SMBs can prevent unauthorized software execution and meet CM.L2-3.4.8. Whitelisting provides stronger protection for sensitive environments, but either strategy will reduce malware and policy drift when paired with logging, pilot testing, and routine maintenance.
