- Prefer allow-by-exception where feasible: application control features already in the operating system (WDAC, AppLocker, or the MDM equivalent) make it reachable without new purchases.
- Run in audit mode first to learn what the business actually executes, then enforce; going straight to blocking is how allowlisting projects die.
- Keep the approved-software list owned and current — an allowlist nobody maintains becomes either a blocker of legitimate work or a rubber stamp.
3.4.8OFFICIAL STATEMENT BELOWDERIVED REQUIREMENTPENDING NIST SME REVIEW
3.4.8 — Software execution policy
3.4 Configuration Management · NIST SP 800-171 Rev. 2 · The heading label is this site's navigational shorthand; the official language is the statement below.
Official requirement statement (verbatim)
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 — Protecting CUI in Nonfederal Systems ↗NIST SP 800-171A — Assessing Security Requirements for CUI ↗Independent interpretation
What this requirement is after
Decide what software may run, by policy: either block known-bad software and allow the rest, or — far stronger — allow only approved software and deny everything else. Rev. 2 accepts either; unsigned ransomware does not care about your blacklist.
Across revisions
Rev. 3 drops the deny-by-exception option: Authorized Software — Allow by Exception (03.04.08) requires the allowlisting approach, which Rev. 2 merely permitted.
Mapped practices
Brilliant at the Basics practices that support this requirement
No practice maps to this requirement — deliberately.
The campaign’s twenty practices are a priority list, not a control catalog, and none of them works this requirement’s substance directly. It still applies to you if it is in your contract’s scope: address it through your own implementation and the related artifacts below, and treat the absence of a mapping here as honesty, not permission to skip it.
Doing the work
Implementation considerations and evidence
- The execution policy configuration, with its mode (audit or enforce)
- The approved-software list with owners and review dates
- Block or audit events showing the policy operating
Artifacts
Templates and worksheets with a mapped relationship
No artifact in the library names this requirement yet. The library index groups everything by category and practice.
The other revision
Where this lands in Rev. 3
Provenance
Sources and review status
| Primary sources | NIST SP 800-171 Rev. 2 — Protecting CUI in Nonfederal Systems · NIST SP 800-171A — Assessing Security Requirements for CUI |
|---|---|
| Review status | Pending NIST SME review |
| Content version | 1.0 |
| Updated |