CM.L2-3.4.8 Allowlisting: What C3PAO Assessors Look For

CM.L2-3.4.8, titled Application Execution Policy in the CMMC Assessment Guide, is the CMMC Level 2 practice that decides which software is allowed to run on systems in your CUI environment. It maps to requirement 3.4.8 in NIST SP 800-171 Rev 2, which says to apply a deny-by-exception (blacklisting) policy to prevent the use of unauthorized software, or a deny-all, permit-by-exception (whitelisting) policy to allow the execution of authorized software. Most contractors call the second option allowlisting.

This guide explains what the practice asks for, how assessors can test it, and what evidence makes an allowlist defensible. It is general information, not legal advice and not an assessment result.

What CM.L2-3.4.8 requires

The requirement offers a choice. You can block known-bad or unapproved software and allow everything else, or you can block everything and allow only approved software. The first model needs a list that is always complete, which is impossible when new software appears daily. The second model needs a list that is finite and owned by someone, which is why allowlisting is the usual choice for environments that handle controlled unclassified information. NIST SP 800-171 Rev 2 and the CMMC Assessment Guide both describe whitelisting as the stronger of the two policies. They also say organizations should consider verifying the integrity of allowed software with cryptographic checksums, digital signatures or hash functions, before execution or at system startup.

NIST SP 800-171A breaks the requirement into three assessment objectives. First, a policy is specified that states whether allowlisting or blocklisting is implemented. Second, the software allowed to run, or prohibited from running, is specified. Third, the allowlisting or blocklisting is implemented as specified. The full wording is in NIST SP 800-171A, and the requirement itself is in NIST SP 800-171 Rev 2, which remains the baseline for CMMC Level 2 under 32 CFR Part 170. NIST's own pages now label both documents as withdrawn in favor of Revision 3, but the CMMC rule still states in 170.14(c)(3) that Level 2 requirements are identical to NIST SP 800-171 R2, and in 170.14(d) that assessment is prescribed by NIST SP 800-171A of June 2018. The CMMC Assessment Guide Level 2 reproduces these objectives and the 800-171A assessment methods for each practice.

How an assessment can test it

NIST assessment procedures use three methods: examine, interview and test. For this practice that usually means reading the configuration management policy and the software list, talking to the people who maintain the allowlist, and watching the enforcement mechanism work. A simple test is to attempt to run an executable that is not on the list and confirm that it is blocked.

Each objective needs its own evidence. The policy covers the first, the list covers the second, and the enforcement configuration plus a test result covers the third. A strong tool configuration with no written policy, or a written policy with a list nobody maintains, leaves an objective open.

The part most programs underinvest in: deciding what goes on the list

Enforcement tools such as App Control for Business, AppLocker or third-party products answer the third objective. The second objective is about the list, and the list is only as credible as the decision behind each entry. When an assessor asks why a particular application is allowed, "someone asked for it" is a weak answer. A documented review is a strong one.

That review should cover who makes the software, whether the vendor passes a sanctions and ownership check, whether the installer is signed and by whom, what the software does when it runs, and what its vulnerability and patch history looks like. The process is described in more detail in our CMMC software approval workflow.

What to record for every allowlisted application

A consistent record per application turns the list into evidence. At a minimum, keep the following.

Field	Why it matters
Application name and approved version	Shows exactly what was approved, not just a product family
Publisher and signature status	Supports publisher-based rules and explains exceptions
SHA-256 hash of the installer and key binaries	Allows hash-based rules and proves the reviewed file is the deployed file
Business justification and owner	Shows the software has a named owner and a reason to exist
Approver and approval date	Shows the decision was made by someone with authority
Review outcome and conditions	Records restrictions such as permitted network destinations
Next review trigger	Version change, vendor change, end of support or a fixed interval

Weak points that make an allowlist hard to defend

Several patterns undermine an otherwise good program. Rules that trust an entire publisher without limiting the product let any software from that publisher run. Exceptions with no expiry date accumulate until the list no longer matches the policy. Tools left in audit mode report what would be blocked but do not block it, which does not meet the third objective. Administrator accounts that bypass the policy make the control hard to test. Each of these is avoidable with a written exception process and periodic review.

How it connects to neighboring controls

CM.L2-3.4.8 defines which software may run. CM.L2-3.4.9 governs who may install software and how installation is monitored, and the Assessment Guide describes CM.L2-3.4.8 as extending it. The same guide says CM.L2-3.4.8 leverages CM.L2-3.4.1, which requires software inventories, so the inventory in your baseline configuration should agree with the allowlist. Protection from malicious code under SI.L2-3.14.2 is the safety net for software that passes the list but misbehaves.

Where DigVel fits

DigVel produces the evidence behind individual allowlist entries: an OSINT screening of the vendor, a sandboxed analysis of the actual installer, and an audit-ready report with the hashes and conditions you need to add the application to your list. See how the service works and which controls the reports support. A report supports your evidence for CM.L2-3.4.8. It is not an assessment of your organization. Depending on the contract, CMMC Level 2 status comes from a self-assessment or from an assessment by an accredited C3PAO.