03.04.08 Authorized software: allow by exception explained

What 03.04.08 authorized software requires, and why allowlists are hard

When a contract or assessment asks for software control under 03.04.08, the compliance lead is being asked to prove that only approved programs can run on the system. The requirement has three parts: identify the software programs authorized to execute, implement a deny-all, allow-by-exception policy for running them, and review and update the authorized list at a defined frequency. The organization owns all three decisions. Its assessor checks the policy, the authorized list and the process that keeps them aligned with what actually runs. The single organization-defined parameter is the review frequency, and if the federal agency has not set it, the nonfederal organization must choose and document a value before the requirement can be met.

The hard part is keeping the list true. Inventories drift as teams install tools, update agents and retire applications, and an allowlist that was accurate at the last review quickly stops matching the endpoints. Exceptions accumulate when a business unit needs one program for a short project and nobody removes it afterward. Business software also changes often, so the review cycle has to absorb new versions and vendor updates without becoming a rubber stamp. Before committing to a schedule, confirm with the contracting agency or your assessor how they expect the review frequency to be defined and evidenced.

Rev. 3 folded the Rev. 2 requirement 3.4.7 into this requirement, so the least-functionality expectations for restricting software now sit inside 03.04.08 alongside the allowlist. The change analysis classifies the move from Rev. 2 requirement 3.4.8 as significant because it adds more detail and foundational tasks. Organizations still assessed under CMMC Level 2 should note that the Rev. 2 numbering (3.4.8 and 3.4.7) continues to govern that assessment, so the same control set must be mapped to both numberings in the system security plan.

Which systems and software 03.04.08 applies to

The allowlist is only as large as the systems and software it must cover. The decisions below determine which endpoints, servers, developer machines and vendor-managed components fall inside the requirement, and which categories of executable code have to appear on the authorized list.

CUI-processing endpoints and servers

Start with the system boundary in your system security plan and list every endpoint and server that processes, stores or transmits CUI. Each one needs its own authorized software list or a shared list that the boundary documentation covers. Systems outside the CUI boundary usually stay out of scope, so a tight boundary keeps the list short. Confirm that the boundary diagram and the inventory agree before you count programs.

Developer and administrator workstations

Workstations that build, deploy or administer CUI systems can run compilers, package managers, remote administration tools and scripting runtimes. Whether they are in scope depends on whether they can reach CUI or the systems that hold it. Bringing them in typically adds the largest share of programs to the list, so decide early whether they sit inside the enclave or are separated from it.

Shared and vendor-managed systems

Shared platforms, managed services and vendor-operated appliances may run software you do not install or fully control. Document which party maintains the authorized list for each system, and make sure the contract or responsibility matrix assigns the review. Ask vendors for their software inventory and change records, because an allowlist that omits vendor-installed programs will not satisfy an assessor.

Operating system components and business applications

Operating system components such as system services, kernel modules and bundled utilities are executable programs and must be accounted for, even when the default build installs them. Business applications, including office suites, database clients and line-of-business tools, form the bulk of the authorized list in most environments. Confirm that the list records versions where the risk of an unpatched binary matters.

Scripts, browser extensions and container images

Scripts, PowerShell modules, browser extensions and container images all execute code, and each category is easy to overlook. Browser extensions in particular change what runs inside a trusted application. Decide whether each category is authorized by name, by publisher, or by a rule that governs how new items are approved, and record that decision, because it determines how often the list changes.

Review frequency and ownership

The requirement leaves the review frequency to the organization, so you must define it as an organization-defined parameter and show that the review happens at that interval. A shorter interval means more reviews and more change records to keep. Name the owner of each system's list and confirm that the owner can produce the review history on request.

How an assessor tests 03.04.08 authorized software controls

This table compares the examine, interview and test methods SP 800-171A Rev. 3 applies to 03.04.08, along with the evidence each method calls for and the findings assessors commonly raise. Read each row as one assessment thread that your evidence package must support. The main takeaway is that a published allowlist alone does not pass: the assessor will check who owns it, how often it is reviewed, and whether enforcement matches the list.

Assessment method	What the assessor does	Evidence requested	Common findings
Examine: policy and procedures	Reads the configuration management policy and procedures and the least functionality procedures to confirm software authorization is defined and assigned.	Configuration management policy, least functionality procedures, and the configuration management plan showing software authorization roles.	Policy exists but names no owner, or the procedure never mentions the authorized software list.
Examine: review frequency parameter	Checks that the organization-defined review frequency for the authorized program list has a value, as the defined-parameter determination statement requires.	Written review frequency in the plan or procedure, with the date it was approved.	Frequency left blank, described as 'as needed', or stated in one document and contradicted in another.
Interview: list owners	Asks personnel with responsibility for identifying authorized software who maintains the list, how additions are approved and what triggers a review.	Named role assignments, approval records for recent additions, and a short walkthrough from the staff member.	Staff cannot name the owner, or each person assumes a different team holds the list.
Interview: security responsibilities	Asks information security personnel how they learn about unauthorized software and what they do when they find it.	Escalation records, incident tickets for blocked executables, and examples of exception requests.	Security staff describe monitoring that the deployed tooling does not perform.
Test: identification and review process	Walks through the process for identifying, reviewing and updating programs authorized to execute, and checks that it runs at the defined frequency.	Dated review records, change history of the authorized list, and sign-off by the named owner.	List is reviewed once at onboarding and never again, or review records have no approver.
Test: deny-all enforcement	Checks that execution on in-scope systems is restricted to listed programs, with exceptions approved and documented.	Allowlisting or endpoint policy settings, a sample of blocked and permitted execution events, and the exception register.	Settings are in audit mode only, or exceptions have no expiry and no approver.
Test: list-to-system match	Compares the authorized list with the software actually observed on sampled systems to confirm the two agree.	Inventory query output from sampled endpoints compared with the approved list, plus a record of any differences.	Installed software found that is absent from the list, with no ticket or exception behind it.
Assessor sampling note	Assessors choose systems and dates themselves, so evidence must cover the whole assessment period, not one snapshot.	Logs or query exports covering several review cycles, retained under the organization's records schedule.	Only a current screenshot is available, and the organization cannot show prior review cycles.

Evidence that proves 03.04.08 authorized software is enforced

An assessor testing 03.04.08 wants proof on three fronts: the list of authorized software, the enforcement that blocks everything else, and the records showing the list is reviewed. The cards below cover the artifacts that connect those fronts, and how to keep each one current between assessments rather than rebuilding it the week before a review.

Authorized software list

This is the baseline of programs approved to execute on the system, with the version, owner and approval reference for each entry. Assessors compare it against what is actually running, so every entry should name a specific version and a responsible owner. Export it on a schedule and store dated copies, so the list in force on any past date can be shown. Confirm that the list covers servers and endpoints inside the CUI boundary, not only the workstations people remember.

Enforcement policy and configuration export

This is the deny-all, allow-by-exception rule set as configured in the allowlisting tool, plus an export of that configuration. The export proves the policy the organization describes is the policy the endpoints apply. Export it on a schedule and after every change, and diff each export against the previous one. Any change that is not tied to an approved ticket should be treated as a finding before the assessor finds it.

Exception register with approvals and expiry

Some business needs will require software outside the list. Each exception should record the program, the justification, the approver, the systems affected and an expiry date after which the exception lapses unless renewed. An open-ended exception with no owner is the most common gap here. Ask whether the register is reviewed alongside the authorized list, and whether expired exceptions are actually removed from the enforcement policy.

Review records at the defined frequency

03.04.08 requires the authorized list to be reviewed and updated at a frequency the organization defines, which is the parameter an assessor will check first. Keep dated review records showing who reviewed the list, what changed and which systems were checked. The records should show the defined frequency was met across the assessment period, so a gap in the record is visible to the reader before it becomes a question.

Change tickets linked to list updates

Every addition or removal from the authorized list should trace to a change request under the configuration change control process (03.04.03). The ticket should show the security review, the approver and the implementation date. Linking the two lets an assessor follow one software change from request to enforcement without relying on memory. Check that changes made directly in the allowlisting console, outside the ticket flow, are caught and reconciled.

Logs of blocked execution attempts

Logs of denied execution attempts show the policy is operating and reveal programs users are trying to run. Review them on a defined cadence, route repeated or unexpected attempts into the exception process or incident handling, and retain the logs for the period the organization sets. Confirm that the logging tool itself is protected from change and that the log coverage matches the systems in the authorized list.

Building the authorized software list and enforcement in order

This sequence moves from defining the system boundary to a recorded first review of the authorized software list, so that each enforcement step rests on a documented scope, inventory and approval. Each step produces a record an assessor can examine, interview against and test.

Confirm the system boundary and in-scope components
Start by fixing the boundary of the system that stores, processes or transmits CUI, using the system security plan as the reference. Name the endpoints, servers and virtual machines inside that boundary and mark which ones are excluded and why. The owner of the requirement is the organization, and an implementation partner can help document the boundary. The output is a boundary statement attached to the system security plan, and the step is complete when every in-scope asset is listed or explicitly excluded.
Discover what actually runs on in-scope systems
Collect a current view of installed and running software on each in-scope asset before deciding what to authorize. Osquery can expose running processes and file hashes across hosts, and a Fleet policy or a scheduled query can record the results per device. Compare the discovered list with the component inventory from 03.04.10 so that unknown programs are flagged rather than silently accepted. The output is a discovery report with a timestamp for each host.
Approve and document the authorized software list
Review the discovered software with system owners and security staff, then decide which programs are authorized to execute on the system and why each one is needed for mission operations. Record the name, version, publisher, file hash or signature, owner and business purpose for each entry. Approval should follow the change control process from 03.04.03, so that additions have a traceable decision. The output is the authorized software register, signed off by the designated approver.
Set and document the review frequency
Assign a defined frequency for reviewing and updating the authorized list, because 03.04.08 includes this as an organization-defined parameter that an assessor will check is filled in. Write the value into the configuration management policy or procedures, name the role responsible for the review, and state what triggers an off-cycle review such as a major release or new system. Confirm the value with your assessor or contracting officer where a federal agency specifies it. The output is a documented frequency that matches the review records you later produce.
Switch to deny-all in monitoring mode before enforcement
Configure the allowlisting tool so that execution of programs not on the authorized list is denied by default, but first run it in a monitoring or audit mode that logs would-be blocks without stopping them. Review those logs to find legitimate software missing from the register, then add or document exceptions before enforcement begins. Wazuh configuration assessment policies or your application control product can supply the policy and logs, and you should confirm exact capabilities in your chosen tool's documentation. The output is a policy configuration and a log review record showing what was reconciled before enforcement.
Enforce deny-all with a written exception path
Move the policy from monitoring to enforcement and keep one documented route for exceptions. A request for an exception should state the software, the business need, the risk, the compensating measure and the approver, and it should be recorded in an exception register with an expiry or review date. Enforce the policy on all in-scope endpoints, and check that no exception bypasses the approval record. The output is an exception register and evidence that enforcement is active on the in-scope systems.
Run and record the first review of the list
Carry out the first formal review of the authorized list at the frequency you documented, comparing the register with current discovery data, the exception register and recent change records. Remove software that is no longer needed, update versions and hashes, and record each decision. Interview the personnel responsible for identifying authorized software to confirm the process matches the written procedure. The output is a dated review record with its findings, signed by the reviewer, which becomes the baseline for later reviews.

Which open-source tools produce allowlist and configuration evidence

No single open-source tool satisfies 03.04.08 on its own. The useful question is which tool produces which evidence: an inventory of what runs, a configuration check, a per-device pass or fail record, or a record of collected artifacts. The cards below cover the four supplied tools and what each contributes to the authorized software list and its review.

Wazuh configuration assessment

Wazuh's Security Configuration Assessment scans monitored endpoints against YAML policies, mostly based on CIS benchmarks, and recommends remediation. Its checks cover files, directories, registry keys and running processes, so it can show whether a prohibited program or service is present on a system. Custom policies let you add checks for the programs on your own authorized list. Confirm which policy checks your chosen Wazuh version ships and how it reports results before relying on them as assessment evidence. Scan results show deviation from policy, not whether a program is permitted to run.

Fleet policies as device checks

Fleet policies are yes or no questions asked of devices as osquery queries. A policy can ask whether an unapproved program is installed or whether a required agent is running, and the policies page shows which devices in each fleet pass or fail. For 03.04.08, this gives a dated, per-device record of whether the authorized software state holds. Confirm how Fleet handles failing policies (alerts, scripts or tickets) for your deployment, because a failing policy does not block execution by itself.

osquery process and hash tables

osquery exposes running processes, loaded kernel modules, open network connections and file hashes as SQL tables. The osqueryd daemon schedules these queries across an entire fleet of hosts. Process and hash queries let you compare what is actually executing against the authorized list, and they produce the time-stamped results an assessor can sample. The query schedule and retention of results are yours to define, so document the frequency you chose, since 03.04.08 requires a defined review frequency for the list.

Velociraptor hunts for software evidence

Velociraptor collects forensic artifacts defined in VQL from endpoints. Its hunts collect one or more artifacts across a group of systems, schedule offline machines to collect when they reconnect, and create a notebook per hunt for analyzing the combined results. This is useful when you need to answer which systems ran an unauthorized program during a period, or to verify the list after an incident. Hunts are investigative rather than continuous, so pair them with a recurring check for ongoing review. Confirm the artifacts available in your version.

What authorized software allowlisting costs to meet

This table breaks down the cost components of meeting 03.04.08 and shows who is paid for each, whether it is one-time or recurring, and what drives it up. Use it to build a written scope and to compare quotes on the same components. No prices or durations are stated because none are supplied for this requirement, so ask each provider for its own figures.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it and what to ask for in a quote
Enforcement tooling or licenses	Software vendor or open-source support provider	Recurring if commercial; one-time setup	Commercial application control licenses scale with endpoints. Self-hosted open-source collection removes license spend but not operating effort. Ask whether the quote includes licenses, hosting and support separately.
Software discovery and inventory build	Internal engineering or implementation partner	One-time, then recurring refresh	Driven by number of software categories and device types. Ask for the discovery method, the sources queried and the format of the initial authorized list.
Authorized list design and approval	Internal security, IT and business owners	One-time, then recurring review	Depends on how many owners must approve entries. Ask who signs off each software category and how the approval record is kept.
Exception handling and review	Internal IT and security staff	Recurring	Driven by exception volume and how often approved programs change. Ask how exceptions are requested, time-limited, documented and closed.
Review frequency upkeep	Internal governance and IT staff	Recurring	The organization must define the review frequency as its own parameter. Ask the provider to set up recurring reviews and reports that show each review was completed.
Evidence collection and upkeep	Internal staff or implementation partner	Recurring	Assessors look for records of policy, discovery results, blocked execution events and review decisions. Ask which evidence is generated automatically and which is manual.
Platform operations and updates	Internal platform team or retained support provider	Recurring	Affected by the number of endpoints, operating systems and rule changes. Ask for upgrade, monitoring and on-call coverage in writing.
External assessment support	Consultant or implementation partner	One-time for readiness, periodic for reassessment	Covers mock assessments and remediation of gaps. Ask for the written scope and whether the partner prepares evidence without issuing any assessment result.
Assessor or auditor time	Independent assessor or certification body	Per assessment cycle	Only independent assessors issue assessment results. Ask the assessor for its own fee basis and the sample size it expects for 03.04.08.

Who owns the list, who builds the enforcement, and who tests it

Your organization owns the requirement. Under 03.04.08 you must identify the software programs authorized to run on the system, enforce a deny-all, allow-by-exception policy, and review and update the list at a frequency you define. Those decisions are management decisions, and an assessor will ask who made them and whether the records show it.

The authorized list: Name who approves each program, what business purpose it serves, and which systems it applies to. The list must cover the CUI boundary, not only the corporate estate.
Exception decisions: Document who may request an exception, who approves it, how long it lasts and how it is removed when no longer needed.
Review frequency: Set the interval in your policy and record it, because this is the organization-defined parameter the assessment checks for. Confirm the value with your contracting authority if the contract specifies one.
CUI boundary: Decide which systems are in scope, including endpoints, servers and cloud workloads that process or store CUI.
Policy and training: Keep the configuration management policy, procedures and plan current so the people who approve software can explain their role.

Before engaging anyone, confirm that your approvers and reviewers can name the current list and the last date it was reviewed.

Where 03.04.08 authorized software gaps fail review

Assessors testing 03.04.08 look for an authorized software list, a deny-by-default execution policy and proof that both are reviewed on schedule. The gaps below are the ones that most often turn a plausible policy into a finding. Each card names the gap and the check that closes it.

List not tied to review frequency

The requirement has an organization-defined parameter: the frequency at which the authorized software list is reviewed and updated. Many organizations write a policy that says the list is reviewed regularly but never set a number, or set one and kept no dated review records. Assign a specific frequency in the system security plan, then keep signed review entries that show the list was checked on that cadence. Ask the assessor's likely interview questions of your list owner before the assessment.

Exceptions without expiry or approver

Allow-by-exception works only if every exception is visible. A common gap is a temporary install approved verbally that remains in place for years, with no record of who approved it or why. Require each exception to name an approver, a business reason, a security review and an expiry date, and remove the software when the date passes. An exception register that an assessor can sample is stronger evidence than a policy statement.

Enforcement limited to a few endpoints

Execution controls often cover the laptops in the IT team and miss the servers, virtual desktops, build hosts and kiosks that also handle CUI. The assessor will ask whether the deny-all, allow-by-exception policy applies to every system in the CUI boundary. Compare the enforcement scope against the system inventory and the system security plan boundary, then document any system where enforcement is technically not possible and the compensating measure in place.

Policy with no enforcement evidence

A written policy that prohibits unlisted software does not show that unlisted software is blocked. Assessors test the process as well as the document, so ask for output from the enforcement mechanism, such as blocked execution events or recent scans that compare running software to the approved list. Keep those records on a schedule and tie them to the review cycle. Without them, the 03.04.08 test objects have nothing to examine.

Developer and admin tools excluded silently

Engineers and administrators often run compilers, scripting runtimes, remote administration tools and package managers outside any list. These may be justified, but the exclusion needs a documented decision: which tools are exempt, who owns them, what compensating controls apply and when the exemption is reviewed. An undocumented carve-out is the first thing an assessor finds when reviewing process execution logs.

Open 3.4.8 gaps carry CMMC scoring weight

For CMMC Level 2 contractors, the 3.4.8 practice (CM.L2-3.4.8) is worth 5 points under the 32 CFR 170.24 scoring methodology. Under 32 CFR 170.21, it cannot be placed on a plan of action and milestones to reach Conditional status, so an unresolved gap here affects the score and the path to certification. Treat authorized software as a practice to close before the assessment, not one to defer.

Questions about cost, effort and doing allowlisting in-house

What drives the effort of building an application allowlist for NIST 800-171?

The size and variety of the software estate drives the effort most. An allowlist has to name every program permitted to execute on in-scope systems, so the work grows with the number of operating system images, server roles, engineering workstations and business applications that touch CUI. Other drivers include how much software is vendor-managed versus custom-built, how many teams can install software, how often the estate changes, and whether the CUI enclave is isolated or shares infrastructure with the rest of the business. Ask any provider to state which of these factors their quote assumes, and to list the systems and software categories inside the written scope.

Can our own team build and maintain the allowlist without a partner?

Often yes, if the team has the time, the access and the skills to inventory software, test it and write the policy. The allowlist is not a one-off file. It has to be reviewed at the frequency your organization defines, so someone must own that cycle after the first build. Teams that go it alone usually underestimate the discovery phase, the exception process and the evidence that an assessor will ask to see. A partner can prepare the tooling and the evidence, but the organization still owns the control and must be able to explain it to the assessor.

How long does it take to put application allowlisting in place?

The timeline depends on scope, and the answer should come from a written plan rather than a rule of thumb. The main variables are how many systems are in scope, how mature the existing configuration management is, whether a baseline inventory already exists, and how many exceptions the business needs to approve. Ask for a schedule that separates discovery, policy design, pilot deployment, enforcement and the first review cycle, and confirm which steps depend on your own change approvals or maintenance windows.

What do IT and security staff need to provide for the work?

The work needs named people from IT operations, security and the application owners. IT operations provides access to endpoints and servers, change windows and the current configuration baseline. Security defines the risk tolerance, reviews exception requests and agrees the review frequency. Application owners confirm which programs their users need and why. Expect the first weeks to require more time from these groups than later review cycles. Ask the provider which decisions they expect you to make and which artifacts, such as the configuration management plan or software inventory, must already exist.

Are self-hosted open-source tools enough to produce allowlisting evidence?

They can produce useful evidence, but they do not replace the policy, the approval records or the assessor's judgment. Open-source tools such as osquery, which exposes running processes and file hashes as queryable tables, and Fleet, which runs yes or no policy checks across devices, can show which software is present and whether devices pass a given policy. Wazuh's Security Configuration Assessment and Velociraptor's hunts can add configuration checks and collection across endpoints. Confirm with each vendor whether a capability fits your environment, and keep the authorized list, exception records and review history alongside the tool output.

What does a fixed-scope engagement with an implementation partner cover?

A fixed-scope engagement covers the deliverables and timelines written into the agreement before work starts. For allowlisting, that usually means agreed systems in scope, the discovery and inventory approach, the deployment of the chosen self-hosted tooling into your infrastructure, the policy and procedure documents you asked for, and the evidence package for the assessor. It does not include the organization's own approval decisions, nor an audit report or certification, which only an independent assessor can issue. Ask for the list of excluded items, the acceptance criteria and whether ongoing review or testing is priced separately as a retainer.

Which parts of allowlisting must stay our own responsibility?

Several parts stay with the organization regardless of who builds the system. You own the decision about which software is authorized, the exception approvals, the review frequency you set as an organization-defined parameter, and the ongoing operation of the list as software changes. You also own the system security plan entries that describe the control and the staff who respond when a blocked program is needed. Under NIST's approach, the federal agency holding the contract is responsible for how SP 800-171 is applied and for any compliance issues, so confirm how your contracting agency expects this control to be documented.

How DeployOpen scopes, implements and prepares allowlist evidence

DeployOpen plans and implements the software allowlisting that 03.04.08 expects, inside the client's own infrastructure, and prepares the configuration, procedures and evidence an assessor will examine and test. The organization owns the authorized software list and the policy decision, while an independent assessor decides whether the requirement is met.

How we scope

The written scope names the systems that process CUI and the endpoints or servers where execution control will apply.
Scope defines who approves additions to the authorized software list and the review frequency the organization assigns to its ODP.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts; ongoing support is available as a retainer.

How we build

We help build the initial inventory of programs that run on in-scope systems and sort them into authorized and exception lists.
We configure the deny-by-default execution policy on the chosen platform and test it on representative endpoints before rollout.
We wire osquery, Fleet and Wazuh checks into scheduled reports so the authorized list is compared against what actually runs.

How we hand over

We document the allowlisting policy, the approval workflow for new software and the procedures that tie changes to the configuration management plan.
We deliver a mapping of the 03.04.08 determination statements to the configuration, procedures and reports that show each one is met.
We walk the organization's staff through reviewing the list at the defined frequency, so the review produces dated, retained records.

How we support

Ongoing support can cover updates to the authorized list as software changes, and periodic checks that the policy still blocks unapproved programs.
Continuous testing and upgrades to the monitoring stack are available under a retainer, scoped in writing.
Before any assessment, confirm with your assessor which evidence formats and sampling they expect, since only an independent assessor or certification body issues findings.