3.4.8Decide what software may run in Rev. 3

Reworded: 03.04.08 Authorized Software – Allow by Exception. Gains organization-defined parameters.

Status as of 2026-09-08

Rev. 2 is what a contract requires today. DFARS 252.204-7012 and the CMMC rule at 32 CFR 170 point at NIST SP 800-171 Rev. 2, and a standing DoD class deviation keeps it there. NIST has published Rev. 3, but publishing a revision does not change an obligation. A move to Rev. 3 would arrive through the Department's reform process and formal rulemaking, a change to that deviation or an amendment to the rule, not through publication. The Department has published its organization-defined parameter values for Rev. 3 in preparation; that is groundwork, not adoption.

Side by side

Rev. 2 · in force 3.4.8 Application Execution Policy

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.

Assessment objectives · 800-171A

[a] a policy specifying programs authorized or not authorized to execute on the system is defined
[b] the policy specifying programs authorized or not authorized to execute on the system is enforced

Rev. 3 · not adopted 03.04.08 Authorized Software – Allow by Exception

a. Identify software programs authorized to execute on the system.

b. Implement a deny-all, allow-by-exception policy for the execution of authorized software programs on the system.

c. Review and update the list of authorized software programs [Assignment: organization-defined frequency].

Determination statements · 800-171A Rev. 3

03.04.08.a software programs authorized to execute on the system are identified.
03.04.08.b a deny-all, allow-by-exception policy for the execution of authorized software programs on the system is implemented.
03.04.08.c the list of authorized software programs is reviewed and updated <A.03.04.08.ODP[01]: frequency>.

Organization-defined parameters

A.03.04.08.ODP[01] the frequency at which to review and update the list of authorized software programs is defined.

Draws on Rev. 2 3.4.7, 3.4.8, 3.4.9.

Left: NIST SP 800-171 Rev. 2 and 800-171A, verbatim. Right: NIST SP 800-171 Rev. 3 and 800-171A Rev. 3, verbatim, with organization-defined blanks highlighted.

Word by word

The Rev. 2 requirement compared with its Rev. 3 successor. A mechanical comparison of the two verbatim texts, not an interpretation.

~~removed in Rev. 3~~ added in Rev. 3

Rev. 2 3.4.8 → Rev. 3 03.04.08 Authorized Software – Allow by Exception

~~Apply deny-by-exception (blacklisting) policy~~ Identify software programs authorized to ~~prevent~~ execute on the ~~use of unauthorized software or~~ system. Implement a deny-all, ~~permit-by-exception (whitelisting)~~ allow-by-exception policy ~~to allow~~ for the execution of authorized software programs on the system. Review and update the list of authorized software programs [Assignment: organization-defined frequency].

9 words kept, 14 removed, 27 added. Rev. 3 statement labels omitted for the comparison.

What NIST says changed

New security requirement title
Aligned with SP 800-53, Rev 5 to provide more comprehensive detail on and foundational tasks for implementing allow by exception policy for authorized software
Added new ODP: frequency to review and update authorized software programs

NIST, SP 800-171 Rev. 2 to Rev. 3 change analysis, class “Significant change”. At adoption, Bedrock files this under “Rework”.

NIST's Rev. 3 discussion for 03.04.08

If provided with the necessary privileges, users can install software in organizational systems. To maintain control over the software installed, organizations identify permitted and prohibited actions regarding software installation. Permitted software installations include updates and security patches to existing software and downloading new applications from organization-approved “app stores.” The policies selected for governing user-installed software are organization-developed or provided by some external entity. Policy enforcement methods can include procedural methods and automated methods. Authorized software programs can be limited to specific versions or come from specific sources. To facilitate a comprehensive authorized software process and increase the strength of protection against attacks that bypass application-level authorized software, software programs may be decomposed into and monitored at different levels of detail. These levels include applications, application programming interfaces, application modules, scripts, system processes, system services, kernel functions, registries, drivers, and dynamic link libraries.

What this means for you now

Nothing changes in what you are assessed against until a class deviation or a published rule adopts Rev. 3. Keep meeting 3.4.8 as written in Rev. 2, and if you already choose a value for the parameters above in practice, write it down where your system security plan can find it.

Bedrock CMMC shows this same comparison against your own package, with your current status on the Rev. 2 side, so the day adoption lands the migration is a review, not a rewrite.

Back to the Rev. 2 vs Rev. 3 overview

Where this page's facts come from

Rev. 2 text and objectives: bedrock-cmmc-api@89b8e8e:migrations/004_reference_requirements.sql#Requirement.basicRequirement@rev2; bedrock-cmmc-api@89b8e8e:migrations/005_reference_objectives.sql#AssessmentObjective.description@rev2
Mapping and change class: bedrock-cmmc-api@89b8e8e:docs/reference/nist-800-171-rev3/normalized/r2_r3_transition_map.json#r2_to_r3
Rev. 3 03.04.08: bedrock-cmmc-api@89b8e8e:docs/reference/nist-800-171-rev3/normalized/rev3.json#requirements[]