NIST 800-171 3.4.8 (CM.L2-3.4.8): Application Execution

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.

NIST SP 800-171 Rev. 2, requirement 3.4.8

CMMC Level 2 practice CM.L2-3.4.8Published 2026-11-11

What 3.4.8 means in practice

Choose an approach and apply it: either block known unauthorized software (deny by exception) or let only approved software run (deny all, permit by exception). NIST's discussion of the requirement calls the second the stronger of the two. Either way the list of allowed or blocked software is written down and enforced by a tool, not by policy alone.

SPRS points and the CMMC POA&M

CMMC Level 2 practice: CM.L2-3.4.8
SPRS points: 5 points. When it is not met, the DoD Assessment Methodology subtracts 5 from the score of 110.
CMMC POA&M: Not allowed. It is worth 5 points, and 32 CFR 170.21(a)(2)(ii) admits only requirements worth 1 point, with one exception: 3.13.11 when encryption is used but not FIPS validated.

Sources: NIST SP 800-171 DoD Assessment Methodology, version 1.2.1 (June 24, 2020), Annex A; 32 CFR 170.21, Plan of Action and Milestones requirements.

What an assessor checks for 3.4.8

NIST SP 800-171A gives 3 determination statements for 3.4.8, each found satisfied or other than satisfied. Determine if:

3.4.8[a] a policy specifying whether whitelisting or blacklisting is to be implemented is specified.
3.4.8[b] the software allowed to execute under whitelisting or denied use under blacklisting is specified.
3.4.8[c] whitelisting to allow the execution of authorized software or blacklisting to prevent the use of unauthorized software is implemented as specified.

NIST SP 800-171A (June 2018), assessment objectives for 3.4.8

Evidence that shows 3.4.8 is met

The policy stating which approach is used.
The list of allowed or blocked software.
Configuration of the enforcement tool, such as Windows Defender Application Control, AppLocker or an endpoint protection allowlist.
Logs of blocked execution attempts.

How PolicyCortex gathers the evidence

No PolicyCortex collector reads the evidence for 3.4.8. Your team provides the evidence listed above.

Related pages

Calculator: SPRS score calculator: mark 3.4.8 and the other 109 requirements and see the score.
Sample package: Sample package: an SSP, a POA&M and an evidence chain the product generated from demonstration data.
Family: All 9 Configuration Management requirements (3.4).
Previous: 3.4.7: Nonessential Services
Next: 3.4.9: User-Installed Software
All requirements: All 110 NIST SP 800-171 requirements, by family.

Related records

Guides and articles describe the work. The evidence that work produces is described in three proof pages, the architecture page, and the two pages on authorization.

proof.state: Proof of State. What the environment was, as of a date someone else picks: point-in-time records, content hashed and chained.
proof.change: Proof of Change. Who or what altered the environment, under what authority, with before and after state hashes.
proof.agency: Proof of Agency. What a machine was permitted to do before it acted, what it did, and what would have stopped it.
architecture: Architecture. How the chain is built and where the evidence is stored in each delivery mode.
authorization: Continuous ATO. How an authorizing official's decision is recorded with its package, and how the authorized system is checked against it every hour.
baseline: NIST SP 800-53. The Low, Moderate and High baselines as evidence, with the SSP, SAR and POA&M generated from one record.