Authorized Software - Allow by Exception is application allowlisting made mandatory. Least Functionality (03.04.06) reduces what the system offers, and Authorized Software - Allow by Exception (03.04.08) controls what software is allowed to run at all. It has three (3) parts: identify the software programs authorized to execute on the system, implement a deny-all, allow-by-exception policy so only that authorized software runs, and review and update the authorized list on a defined frequency. Per the NIST discussion, authorized software can be limited to specific versions or sources, and software can be monitored at different levels of detail, from applications down to scripts, services, drivers, and libraries.
A common difficulty with this requirement is running an antivirus or blocklist and thinking it satisfies the requirement. It does not. R3 specifically requires the deny-all, allow-by-exception model, which is the opposite of a blocklist. Under R2 you could choose either approach, but R3 mandates allowlisting, so organizations that relied on blocking known-bad software have real work to do. For Department of Defense (DoD) contractors, the review frequency is specified.
Where things stand for companies facing the transition from NIST 800-171 R2 to R3:
The following is reproduced verbatim from NIST 800-171 R3, requirement 03.04.08 Authorized Software - Allow by Exception. Only the formatting has been adjusted for readability. This requirement has three (3) lettered parts:
The source control is CM-07(05) from NIST 800-53. The bracketed assignment in part c is the Organization-Defined Parameter (ODP): the review and update frequency. Per the NIST discussion, permitted software installations can include updates, security patches, and downloads from organization-approved app stores, and enforcement can use both procedural and automated methods. You can read the requirement directly at NIST 800-171 R3, 03.04.08 (p. 30).
One (1) value sits inside this requirement. Depending on your contract, your organization may be permitted to define it. Organizations in the DIB subject to CMMC are not, because the DoD has defined it as policy.
The value below comes from Attachment A of the DoD Chief Information Officer (CIO) memorandum dated 10 April 2025 (signed David W. McKeown). The memo identifies each parameter by requirement sub-part, while NIST 800-171A R3 identifies the same parameter by ODP number. Both identifiers appear below so you can match your System Security Plan (SSP) language to either document.
The memo states that its values "will be updated as necessary," so confirm against the current version before writing them into policy.
NIST 800-171A R3 breaks 03.04.08 into four (4) assessment objectives: one (1) Organization-Defined Parameter (ODP) and three (3) determination statements. These AOs are:
The three (3) determination statements are identify the authorized software (a), implement the deny-all model (b), and keep the list current (c). If you are a DoD contractor, the ODP is specified. Per the DoD-specified ODP value in ComplianceForge's NIST 800-171 R3 Transition Guide, the review and update frequency (ODP[01]) is at least quarterly. The full guidance on assessment methods and objects, is in NIST 800-171A R3, 03.04.08 (p. 38).
Examine: configuration management policy and procedures; procedures for least functionality in the system; configuration management plan; system design documentation; system configuration settings; list of software programs authorized to execute on the system; system component inventory; records associated with the review and update of the list of authorized software programs; common secure configuration checklists; change control records; system audit records; system security plan.
Interview: personnel with responsibilities for identifying software authorized to execute on the system; personnel with information security responsibilities; system administrators.
Test: processes for identifying, reviewing, and updating programs authorized to execute on the system; processes for implementing authorized software policy; mechanisms for supporting or implementing authorized software policy.
03.04.08 maps from NIST 800-171 R2 requirement 3.4.8 (apply a deny-by-exception policy to prevent unauthorized software, or a deny-all, permit-by-exception policy to allow authorized software), and it draws on R2 requirement 3.4.9 (control and monitor user-installed software):
Mapped against the four (4) AOs, two (2) are direct (minimal effort) and two (2) are indirect (moderate effort), with no net-new AOs and none with no mapping. The counts understate the real change. R2 3.4.8 let organizations choose blocklisting or allowlisting. R3 removes the choice and requires the deny-all, allow-by-exception model. If your R2 program relied on blocking known-bad software, satisfying 03.04.08 is a shift in approach, not a reinterpretation.
Source Control in NIST 800-53 R5:
Secure Controls Framework (SCF) Crosswalk
Organizations running a single control set across multiple frameworks can satisfy 03.04.08 through the following SCF controls:
The crosswalks from NIST 800-171 R3 and NIST 800-171A R3 to the SCF are available at no cost through the SCF Set Theory Relationship Mapping (STRM): https://securecontrolsframework.com/start-here/set-theory-relationship-mapping-strm. The STRM also carries the relationship type for each mapping (Equal, Subset Of, Intersects With), which tells you whether an SCF control fully satisfies the requirement or only part of it. Mapping above taken from SCF 2026.3.
The following are issues teams may encounter rather than certainties. They are about the mandated model and list maintenance, each of which needs documented evidence of due diligence and due care such as policies, standards, procedures, and configuration screenshots:
Reasonable objective evidence for an assessment is often subjective. The following examples of evidence to address NIST 800-171 R3 03.04.08 are sourced from the SCF Evidence Request List (ERL), available at https://securecontrolsframework.com/free-content/scf-download. These ERL artifacts are mapped to NIST 800-171 R3 03.04.08 through SCF controls. They establish a starting point for discussions on what an organization needs to have for evidence of due diligence and due care to withstand external scrutiny by an assessor or regulator.
Alongside these, keep the System Security Plan (SSP) narrative for 03.04.08 recording the ODP values you adopted.
With two (2) AOs mapping directly and two indirectly, 03.04.08 is a moderate lift, but the shift to mandatory allowlisting can be a larger project than the counts suggest. A realistic sequence:
What value does the DoD require for the organization-defined parameter in NIST 800-171 R3 03.04.08? R3 leaves the value to the organization. For the DIB, the DoD set it in the 10 April 2025 memorandum under ODP identifier 03.04.08.c: at least quarterly.
How many assessment objectives does NIST 800-171 R3 03.04.08 have? NIST 800-171A R3 breaks 03.04.08 into four (4) assessment objectives: one (1) Organization-Defined Parameters (ODPs) and three (3) determination statements. An assessor works through each one separately, so each needs its own evidence.
Which NIST 800-53 R5 control does NIST 800-171 R3 03.04.08 come from? CM-07(05).
Where does NIST 800-171 R3 03.04.08 sit in the NIST 800-171 R3 Kill Chain? Phase 12, Secure Baseline Configurations (SBC). The Kill Chain is a phased model for sequencing R3 implementation, and it assigns this requirement to that phase.
03.04.08 Authorized Software - Allow by Exception identifies authorized software, enforces a deny-all, allow-by-exception model, and keeps the authorized list current. It maps from R2 3.4.8 and draws on 3.4.9, with the identification and implementation objectives transitioning directly, but R3 removes the R2 option to use a blocklist. The recurring problem is treating antivirus or a blocklist as sufficient. Build the authorized list, enforce allowlisting, and review the list at least quarterly for DoD work.
Authoritative sources:
Authoritative sources:
This guide reproduces U.S. Government text from NIST 800-171 R3 and NIST 800-171A R3 and references the DoD ODP memorandum of 10 April 2025. It is educational, not legal or assessment advice. Last reviewed: 2026-09-22.
