CMMC Level 2 Practice 3.4.8: Apply deny-by-exception (blacklisting) policy to prevent the use of unauthorized software or

CMMC Level 2 Practice 3.4.8 requires you to enforce a deny-by-exception (blacklisting) approach so endpoints cannot run software unless it is explicitly allowed by policy, with controlled exceptions. Operationalize it by defining “authorized software,” deploying technical controls that block unapproved executables, and retaining repeatable evidence that blocking works across the CUI environment. (NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance; 32 CFR Part 170)

Key takeaways:

• You need both policy and technical enforcement that actually prevents unauthorized software execution, not just a written standard. (NIST SP 800-171 Rev. 2)
• Scope matters: apply controls to the systems and endpoints that store, process, or transmit CUI (your CUI environment). (DoD CMMC Program Guidance; 32 CFR Part 170)
• Evidence wins assessments: keep allow/deny configuration, exception records, and proof of blocked execution attempts. (NIST SP 800-171 Rev. 2)

“Deny-by-exception” for software is the opposite of the default most IT environments drift into. Instead of letting anything run unless it is known-bad, you block software by default and only allow what you have approved. CMMC Level 2 Practice 3.4.8 maps directly to NIST SP 800-171 Rev. 2 control 3.4.8 and is assessed as part of demonstrating that your organization can protect CUI within the defined CUI environment. (NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance)

For a Compliance Officer, CCO, or GRC lead, the operational challenge is rarely “Do we agree with the control?” It’s “How do I turn this into an enforceable standard without breaking engineering, manufacturing, or program delivery?” The answer is to treat software authorization as a governed lifecycle: define what “authorized” means, implement a consistent approval and exception process, deploy endpoint enforcement (allow/deny rules), and continuously capture evidence that the control is operating. (NIST SP 800-171 Rev. 2)

This page gives you requirement-level implementation guidance you can hand to IT/SecOps, and a documentation package you can defend during a CMMC Level 2 assessment. (DoD CMMC Program Guidance; 32 CFR Part 170)

Requirement: cmmc level 2 practice 3.4.8: apply deny-by-exception (blacklisting) policy to prevent the use of unauthorized software or requirement

CMMC Level 2 Practice 3.4.8 expects you to prevent use of unauthorized software by applying a deny-by-exception (blacklisting) policy. In practice, assessors look for: (1) a clear definition of “authorized software,” (2) a technical mechanism that blocks unauthorized execution, and (3) repeatable evidence that the mechanism is deployed and effective in the CUI environment. (NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance)

Plain-English interpretation

• You maintain an approved set of software that is allowed to run.
• Anything not approved is blocked by policy and by technical control.
• Exceptions exist, but they are documented, time-bounded where feasible, and reviewed.

This is about execution control, not just procurement. A company can “buy” only approved tools and still fail 3.4.8 if users can download and run portable apps, unsigned binaries, scripts, or unapproved browser extensions on in-scope endpoints. (NIST SP 800-171 Rev. 2)

Regulatory text

Regulatory excerpt (provided): “CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.4.8 (Apply deny-by-exception (blacklisting) policy to prevent the use of unauthorized software or).” (NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance; 32 CFR Part 170)

What the operator must do: implement a deny-by-exception software execution policy and enforce it with technical controls across the CUI environment, then retain evidence that the control blocks unauthorized software and that exceptions are governed. (NIST SP 800-171 Rev. 2)

Who it applies to

Entity scope

Applies to defense contractors and other federal contractors that handle CUI and must meet CMMC Level 2 requirements for contract eligibility where applicable. (32 CFR Part 170; DoD CMMC Program Guidance)

Operational scope (what systems)

Apply to the CUI environment: endpoints, servers, and supporting services where CUI is stored, processed, or transmitted, plus the admin workflows that manage those assets. If you have segmented CUI enclaves, the deny-by-exception control must be consistently enforced inside that boundary and for privileged access paths into it. (DoD CMMC Program Guidance; NIST SP 800-171 Rev. 2)

Common in-scope assets

• User workstations used for CUI work (engineering, program management, finance tied to CUI deliverables).
• Jump boxes and admin workstations used to manage CUI systems.
• Application servers and VDI images that host CUI workloads.
• Build systems or tooling endpoints if they touch CUI artifacts.

What you actually need to do (step-by-step)

1) Define “authorized software” in a way IT can enforce

Produce a written standard that answers:

• What categories are in scope (installed apps, portable executables, scripts, macros, browser extensions, container images if executed on endpoints).
• What attributes qualify as “authorized” (publisher, file hash, signing certificate, managed app catalog entry, version constraints).
• Who can approve software and under what conditions.
• How emergency exceptions work and how they are reviewed. (NIST SP 800-171 Rev. 2)

Operator tip: avoid a vague “software must be approved by IT” statement. Your standard should map to enforceable rule types (publisher allow rules, hash allow rules, path rules, certificate rules) so SecOps can implement without re-interpreting intent.

2) Build and maintain an allowlist baseline (the “exception list”)

Even though the practice mentions blacklisting language, operationally you need a concrete list of allowed software (your exceptions to the deny default). Create:

• A baseline list for standard user endpoints in the CUI environment.
• Separate baselines for privileged admin workstations and servers.
• Ownership for the baseline (Security or IT), plus a change control process. (NIST SP 800-171 Rev. 2)

3) Choose an enforcement mechanism and make it hard to bypass

Implement technical controls that prevent execution of unauthorized software. Acceptable implementations vary, but assessors will expect centralized, consistent enforcement across in-scope endpoints. (NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance)

Practical control options (examples, not an exhaustive list):

• OS-native application control (policy-based execution restriction).
• Endpoint security tooling with application control features.
• Mobile/MDM controls for managed devices when applicable.

Key enforcement requirements to design for:

• Coverage: applies to the asset classes in your CUI environment (workstations, admin boxes, relevant servers).
• Tamper resistance: standard users cannot disable the agent/policy.
• Offline behavior: local policy still blocks unauthorized execution if the endpoint is disconnected.
• Logging: block events are recorded centrally or can be produced on request. (NIST SP 800-171 Rev. 2)

4) Implement a controlled exception process that doesn’t become the default

Define an exception workflow that is fast enough for operations but strict enough to preserve “deny by default.” Minimum fields for exceptions:

• Requestor, business justification, system(s) affected, software identifier (publisher/hash/version), risk review notes, approver, start date, end/review date, and rollback plan. Tie exceptions to tickets so you can prove governance during assessment. (NIST SP 800-171 Rev. 2)

5) Integrate with change management and onboarding/offboarding

Operationalize it in existing processes:

• New software request process routes through security review and packaging/deployment.
• Golden image/VDI build includes only the authorized baseline.
• Deprovisioning removes local admin rights and ensures control agents/policies remain intact.
• M&A or new program onboarding includes a “CUI enclave build sheet” with application control requirements. (NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance)

6) Validate effectiveness with repeatable tests

Run and document practical tests:

• Attempt to execute a known unapproved binary on an in-scope endpoint and capture the block event.
• Confirm an approved application runs successfully.
• Confirm exception behavior: add an exception, validate it works, then remove it and validate re-blocking. These tests become high-value assessor evidence because they prove operational outcomes. (NIST SP 800-171 Rev. 2)

Required evidence and artifacts to retain

Keep artifacts that show design, deployment, operation, and governance:

Policy and governance

• Software authorization / application control policy (deny-by-exception statement, scope, roles, approvals). (NIST SP 800-171 Rev. 2)
• Approved software baseline list(s) for CUI endpoints and admin endpoints (versioned). (NIST SP 800-171 Rev. 2)
• Exception procedure and sample completed exception tickets. (NIST SP 800-171 Rev. 2)

Technical configuration evidence

• Screenshots or exports of application control rules (publisher/hash/path rules), showing deny default and allowed exceptions. (NIST SP 800-171 Rev. 2)
• Deployment coverage reports: which in-scope endpoints have the policy/agent applied. (NIST SP 800-171 Rev. 2)
• Central logging configuration for block/allow events (SIEM connector configuration or event forwarding proof). (NIST SP 800-171 Rev. 2)

Operational records

• Change records for baseline updates (who approved, what changed, why). (NIST SP 800-171 Rev. 2)
• Periodic review evidence for exceptions (export of current exceptions with review notes). (NIST SP 800-171 Rev. 2)
• Test results showing unauthorized software was blocked on representative in-scope assets. (NIST SP 800-171 Rev. 2)

Daydream fit: Daydream is useful here as a control-to-evidence operating layer. You map 3.4.8 to a documented control, define the evidence you will collect, and schedule recurring collection so you are not assembling proof at the last minute. (DoD CMMC Program Guidance; NIST SP 800-171 Rev. 2)

Common exam/audit questions and hangups

Assessors commonly probe these areas:

1. “Show me the deny-by-exception policy and where it applies.” Expect a scope discussion tied to the CUI environment boundary. (DoD CMMC Program Guidance; NIST SP 800-171 Rev. 2)

2. “Demonstrate the technical control.” Be ready to show the actual rule set and a block event. A written policy without enforcement is a frequent failure mode. (NIST SP 800-171 Rev. 2)

3. “How do exceptions work, and who approves them?” If exceptions are ad hoc, you will struggle to show governance. (NIST SP 800-171 Rev. 2)

4. “What about scripts, macros, and portable apps?” If your control only covers MSI-installed apps but allows user-space executables to run, expect scrutiny. (NIST SP 800-171 Rev. 2)

5. “How do you know coverage is complete?” You need a defensible inventory of in-scope endpoints and a coverage report for application control deployment. (NIST SP 800-171 Rev. 2)

Frequent implementation mistakes (and how to avoid them)

Mistake 1: Confusing blacklisting with AV signatures

Antivirus “known bad” blocking does not satisfy deny-by-exception intent. Fix: implement application control that blocks unknown/unapproved execution, not just malware detection. (NIST SP 800-171 Rev. 2)

Mistake 2: Leaving local admin rights in place on CUI endpoints

Users with local admin can often bypass controls. Fix: remove local admin, protect policy with tamper controls, and tightly control privileged access paths. (NIST SP 800-171 Rev. 2)

Mistake 3: Exceptions become permanent

If exceptions never expire or get reviewed, you effectively shift to allow-by-default over time. Fix: require documented review of exceptions and remove those no longer needed. (NIST SP 800-171 Rev. 2)

Mistake 4: No evidence of actual blocking

Teams often keep policy and configuration but no proof of outcomes. Fix: run a simple, repeatable “blocked execution” test and keep the logs and screenshots. (NIST SP 800-171 Rev. 2)

Mistake 5: Inconsistent scope across endpoints and VDI

VDI pools, jump boxes, and privileged workstations are frequently missed. Fix: include them in the CUI environment asset register and in deployment reporting. (DoD CMMC Program Guidance; NIST SP 800-171 Rev. 2)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific practice, so this page does not cite enforcement examples.

Operationally, failure of 3.4.8 increases the likelihood that unapproved tools (including remote access utilities, password dumpers, or data exfiltration clients) can execute inside the CUI environment. That expands both incident risk and assessment risk because assessors can validate this control by direct inspection and simple execution tests. (NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance)

Practical 30/60/90-day execution plan

You asked for speed and operational clarity; use this as a delivery plan you can assign across GRC, IT, and SecOps.

First 30 days (Immediate)

• Confirm and document the CUI environment boundary and the in-scope endpoint/server inventory you will enforce against. (DoD CMMC Program Guidance)
• Publish the deny-by-exception software execution policy and define “authorized software” criteria. (NIST SP 800-171 Rev. 2)
• Select the enforcement mechanism and design the rule approach (publisher vs hash vs path, admin workstation baseline, server baseline). (NIST SP 800-171 Rev. 2)
• Stand up the exception workflow in your ticketing system with required fields and approval roles. (NIST SP 800-171 Rev. 2)

Days 31–60 (Near-term rollout)

• Deploy application control to a pilot group of in-scope endpoints and at least one privileged admin workstation group.
• Build the initial approved software baseline(s) from existing managed software catalogs and validated business needs. (NIST SP 800-171 Rev. 2)
• Enable central logging for block events and create a standard report or dashboard for blocked execution attempts. (NIST SP 800-171 Rev. 2)
• Run your first effectiveness tests and retain the evidence package. (NIST SP 800-171 Rev. 2)

Days 61–90 (Operationalize and harden)

• Expand deployment to full in-scope coverage and document coverage reporting.
• Tighten bypass paths: remove local admin rights where feasible and document compensating controls where not feasible. (NIST SP 800-171 Rev. 2)
• Start recurring exception reviews and baseline change control cadence, then retain the outputs as recurring evidence. (NIST SP 800-171 Rev. 2)
• In Daydream (or your GRC system), map 3.4.8 to the control owner, evidence checklist, and recurring collection schedule so you can stay assessment-ready. (NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance)

Frequently Asked Questions

Does 3.4.8 require allowlisting, or is traditional blacklisting enough?

The control language is “deny-by-exception,” which expects you to block unauthorized software by default and allow only approved exceptions. Traditional “known bad” blacklisting alone usually won’t demonstrate that outcome. (NIST SP 800-171 Rev. 2)

What counts as “unauthorized software”?

Anything not explicitly approved under your software authorization standard for the CUI environment is unauthorized. Your policy should define how approval is determined (publisher, hash, signing cert, catalog entry) and who can grant it. (NIST SP 800-171 Rev. 2)

Do I need to apply this to every corporate laptop?

Apply it at minimum to the CUI environment endpoints and systems that store, process, or transmit CUI, plus the admin pathways into that environment. If your CUI environment is not well-defined, your scoping conversation will be harder during assessment. (DoD CMMC Program Guidance; NIST SP 800-171 Rev. 2)

How should we handle engineering tools that change frequently (plugins, toolchains, scripting)?

Create a controlled workflow for rapid approvals and pre-approved publishers where appropriate, then require exceptions for one-off tools. Keep the exception tickets and the resulting rule changes as evidence. (NIST SP 800-171 Rev. 2)

What evidence is most persuasive to an assessor?

A clear deny-by-exception policy, exported rule configurations, coverage reporting for in-scope endpoints, and log evidence showing an unauthorized executable was blocked during a test. Package those artifacts so they can be reproduced on request. (NIST SP 800-171 Rev. 2)

We can’t fully block all unapproved software without disrupting operations. Can we still pass?

You need to show that the policy is enforced and that exceptions are governed; widespread permanent exceptions weaken the control. If you must permit certain categories, document the rationale, restrict scope, and apply compensating controls while you reduce exceptions over time. (NIST SP 800-171 Rev. 2)