1Overview
CM.L2-3.4.8 governs which software may run. It requires a policy that either denies unauthorized software by exception (blacklisting) or, more strongly, permits only authorized software by exception (whitelisting), so that what executes on systems is controlled rather than open. It is a five-point requirement that cannot be deferred on a plan of action.
Controlling what software can execute is one of the strongest defenses against malware, because malware is, at bottom, unauthorized software running. The control offers two approaches: deny-by-exception blocks known-bad software while allowing the rest, and deny-all-permit-by-exception allows only explicitly approved software and blocks everything else. The second, allowlisting, is far stronger, because it does not depend on knowing every bad thing in advance. The organization chooses an approach, specifies the software accordingly, and implements it, so that execution is governed by policy. Its five-point weight reflects how much this control does to prevent unauthorized code from running.
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.
The requirement offers a choice between two models. Blacklisting blocks specified unauthorized software and permits the rest, which is easier to run but weaker, since it cannot block what it does not already know is bad. Allowlisting permits only specified authorized software and blocks everything else, which is stronger but demands more effort to define and maintain. The control is met by implementing either as specified, though allowlisting provides materially better protection against novel malware.
2The Assessment Objectives
NIST SP 800-171A decomposes 3.4.8 into three objectives: specify the policy, specify the software, and implement it.
A policy specifying whether allowlisting or denylisting is to be implemented is specified. The organization has chosen an approach.
The software allowed to execute under allowlisting or denied use under denylisting is specified. The organization has defined the specific software.
Allowlisting to allow the execution of authorized software or denylisting to prevent the use of unauthorized software is implemented as specified. The chosen approach is actually enforced.
The three objectives are choosing the approach, specifying the software, and implementing it. The common gap is at objective [c], where a policy is chosen and software specified but the enforcement is never implemented, so execution remains uncontrolled. The assessor looks for the chosen approach actually enforced on systems.
3Failure Patterns
The failures are about uncontrolled execution and policy without enforcement.
Any software can run
Where nothing controls execution, any software a user or attacker introduces can run, which is precisely how much malware operates. Choosing and enforcing an approach is what the control requires.
Policy without implementation
A policy choosing allowlisting or denylisting, with software specified, but never enforced leaves objective [c] unmet. The enforcement mechanism has to actually govern execution.
Denylisting treated as sufficient against novel threats
Denylisting blocks only known-bad software, so novel malware not on the list runs freely. Where the risk warrants, allowlisting provides materially stronger protection because it blocks everything not explicitly approved.
Allowlist that is not maintained
An allowlist that is never updated blocks legitimate new software and pressures users to seek workarounds, which can undermine the control. Maintaining the allowlist keeps it both effective and workable.
4Ownership
This is an IT-owned technical control, and its work is choosing an approach and enforcing it across systems.
| Role | Responsibility for this control |
|---|---|
| IT and system administrator | Chooses the approach, specifies the software, and implements the enforcement. Owns the technical evidence. |
| Security or compliance lead | Confirms the chosen approach fits the risk and is actually enforced, and weighs allowlisting where warranted. |
| Program lead | Ensures the software list is maintained so the control stays both effective and usable, and retains the evidence. |
5Tooling
The control is delivered by application control that enforces the chosen allow or deny policy.
| Objectives | Tooling | What it provides |
|---|---|---|
| [a] | Application control policy | The chosen allowlisting or denylisting approach. |
| [b] | Specified software set | The authorized or unauthorized software the policy governs. |
| [c] | Application allowlisting tools, such as WDAC or AppLocker | Enforcement that permits only authorized software or blocks specified unauthorized software. |
| Maintenance | Allowlist update process | Keeping the list current so legitimate software runs and the control stays workable. |
The caveat is that the policy must be enforced, and allowlisting, though stronger, requires maintenance to stay workable. A chosen approach with specified software still fails the control if nothing enforces execution, and an allowlist that is not maintained frustrates users into workarounds. The assessor examines whether the chosen approach actually governs what runs, so enforcement is central.
6Evidence
The satisfied version of 3.4.8 shows a chosen, specified, and enforced execution policy.
| Evidence | What it demonstrates |
|---|---|
| Execution control policy | Objectives [a], [b]. The chosen approach and the specified software. |
| Application control configuration | Objective [c]. Enforcement of the chosen approach on systems. |
| Maintenance records | Objective [c]. Evidence the software list is kept current. |
The evidence should show a chosen approach with specified software actually enforced on systems. The policy paired with enforced application control is the clearest demonstration, and because this control cannot sit on a plan of action, the enforcement has to be real at the time of assessment.
Malware is just unauthorized software running
A system that will run anything has no defense against malicious code, and this five-point control asks for a policy, ideally allowlisting, that governs execution. Choosing an approach and enforcing it across systems, while keeping the software list workable, is part of the onsite readiness work this practice does, and it is one of the controls that must be met rather than deferred.
Start CMMC Readiness or call 802-335-26627Sources
- NIST Special Publication 800-171 Rev 2, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations, requirement 3.4.8. csrc.nist.gov
- NIST Special Publication 800-171A, Assessing Security Requirements for Controlled Unclassified Information, assessment objectives 3.4.8[a] through 3.4.8[c]. csrc.nist.gov
- 32 CFR 170.24, CMMC Scoring Methodology, listing CM.L2-3.4.8 among the five-point derived security requirements. ecfr.gov