- Built-in OS tooling (Windows App Control/AppLocker, MDM restrictions on macOS) does the enforcement; the work is inventorying what legitimately runs first, then staging in audit mode before enforcement mode.
- Decide the list-update path — who approves additions, how fast — before enforcement, or the help desk becomes the exception process.
- Publisher- and path-based rules trade precision for maintainability; document which trade the organization chose and why.
03.04.08OFFICIAL TITLEPENDING NIST SME REVIEW
03.04.08 — Authorized Software — Allow by Exception
03.04 Configuration Management · NIST SP 800-171 Rev. 3
Independent summary of the official requirement
Requires identifying the software programs authorized to execute on the system, implementing a deny-all, allow-by-exception policy for the execution of authorized software, and reviewing and updating the authorized-software list at an organization-defined frequency.
Rev. 3 requirement text is multi-part and parameterized with organization-defined values, so this site summarizes rather than reproduces it. The summary is independent — read the official publication for the binding wording.
NIST SP 800-171 Rev. 3 — Protecting CUI in Nonfederal Systems ↗NIST SP 800-171A Rev. 3 — Assessing Security Requirements for CUI ↗Independent interpretation
What this requirement is after
Rev. 3 picks a side: only software on the authorized list runs, and everything else is denied by default. For a small estate this is less frightening than it sounds — the application population is small; the real discipline is maintaining the list and the exception path.
Across revisions
Merges 3.4.8 and 3.4.9 and drops Rev. 2's deny-by-exception (blacklisting) alternative: allow-by-exception is now the stated policy, with user-installed software governed by the same list.
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 authorized-software list with review dates
- Enforcement policy exports and a sample of blocked-execution events
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 came from in Rev. 2
Provenance
Sources and review status
| Primary sources | NIST SP 800-171 Rev. 3 — Protecting CUI in Nonfederal Systems · NIST SP 800-171A Rev. 3 — Assessing Security Requirements for CUI |
|---|---|
| Review status | Pending NIST SME review |
| Content version | 1.0 |
| Updated |