Configuration Management 3.4.8 (3.4.8)
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.
Get Full GuidanceWhat Is This CMMC Control?
This control requires organizations to implement either a blacklist (deny-by-exception) or whitelist (permit-by-exception) policy to control which software can run on their systems. Whitelisting is the stronger approach, allowing only approved software to execute while blocking everything else. Organizations should verify the integrity of approved software using cryptographic methods like checksums or digital signatures. This control prevents unauthorized or malicious software from running on systems that process, store, or transmit CUI.
Control Intent
Prevent unauthorized software execution that could compromise CUI confidentiality, integrity, or availability by implementing systematic controls over what software is permitted to run on organizational systems.
Who This Control Applies To
- •All endpoints (workstations, laptops, servers) that process, store, or transmit CUI
- •Virtual machines and containers within the CUI environment
- •Mobile devices with access to CUI systems or data
- •Jump boxes, administrative workstations, and privileged access systems
- •Application servers and database servers handling CUI
- •Systems in the CUI boundary regardless of operating system
Not Applicable When
- •Systems that only route or transmit encrypted CUI without processing or storing it
- •Network infrastructure devices (routers, switches, firewalls) that do not execute general-purpose software
- •Hardware security modules or embedded systems with fixed firmware
- •Systems completely isolated from CUI with no network connectivity or data exchange
- •Read-only systems or kiosks with no ability to install or execute software
Key Objectives
- 1Establish and enforce policies that restrict software execution to only authorized programs
- 2Prevent malicious, unauthorized, or unapproved software from executing on systems containing or processing CUI
- 3Verify the integrity of authorized software before or during execution to detect tampering or corruption
- 4Maintain visibility and control over the software inventory running across the CUI environment
Sample Self-Assessment Questions (Partial)
Do you have a documented list of approved software applications for your organization?
Are users able to install software on their work computers without approval?
Implementation Approaches (High-Level)
Windows AppLocker or Windows Defender Application Control (WDAC)
Microsoft's built-in application control technologies that enforce whitelisting or blacklisting policies on Windows systems through Group Policy or MDM
Third-Party Application Whitelisting Solutions
Commercial or open-source application control platforms that provide centralized whitelisting, blacklisting, and integrity verification across multiple operating systems
Linux Application Control (SELinux, AppArmor, or similar)
Operating system-level mandatory access control frameworks that restrict application execution and behavior on Linux systems
macOS Gatekeeper and Application Notarization
Apple's built-in application control system that restricts execution to signed and notarized applications from identified developers
Container and Orchestration Platform Controls
Application control implemented through container image signing, admission controllers, and runtime security policies in containerized environments
Hybrid Approach with Centralized Management
Combination of whitelisting for critical systems and blacklisting for less critical systems, managed through a unified platform
Evidence & Assessment Notes
Expected Evidence
Organizations should maintain documentation and evidence demonstrating compliance with this control. This may include policy documentation, configuration records, audit logs, access reviews, and other relevant artifacts that show how the control is implemented and maintained.
Plan of Action & Milestones (POA&M)
If application control is not implemented, POA&M should include specific tool selection, pilot testing, and phased deployment timeline Typical implementation timeline: 3-6 months for whitelisting depending on environment complexity POA&M should address both technical implementation and policy/process development Consider starting with audit mode to build approved application list before enforcing Prioritize implementation on systems with direct CUI access or highest risk Include user training and change management in POA&M milestones If using hybrid approach, POA&M should include migration plan to full whitelisting with specific dates Address any technical limitations (legacy systems, unsupported OS) with compensating controls Include periodic review and maintenance of approved software list in ongoing milestones Ensure POA&M addresses integrity verification requirements, not just execution control Consider resource requirements for ongoing policy management and exception handling If application control causes business disruption, document lessons learned and policy adjustments in POA&M updates
Frequently Asked Questions
What is the difference between whitelisting and blacklisting, and which should we use?
Whitelisting (permit-by-exception) allows only approved software to run and blocks everything else, while blacklisting (deny-by-exception) blocks known bad software but allows everything else. Whitelisting is the stronger approach and preferred for CMMC because it provides better protection against unknown threats. However, blacklisting may be acceptable as a starting point or for less critical systems, with a plan to migrate to whitelisting.
Do we need to implement application control on every single computer in our organization?
You must implement application control on all systems within your CUI environment boundary—any system that processes, stores, or transmits CUI. This includes workstations, servers, and virtual machines with CUI access. Systems completely outside the CUI boundary may not require this control, but you must clearly document your boundary and justify exclusions.
Can we use antivirus software instead of application whitelisting or blacklisting?
No, antivirus alone does not satisfy this control. Antivirus is reactive and signature-based, while application control is proactive and policy-based. This control specifically requires either whitelisting or blacklisting to control what software can execute. Antivirus is complementary and addresses different requirements (like 3.14.1 for malicious code protection), but cannot substitute for application control.
What happens if we need to install new software quickly for business needs?
You must have a documented exception process that allows for timely software approval while maintaining security. This typically involves a request, risk assessment, approval by appropriate authority, and temporary or permanent addition to the approved list. The process should be efficient enough to support business needs while ensuring unauthorized software doesn't bypass controls. Emergency procedures should be documented for critical business situations.
How do we handle software updates and patches with application whitelisting in place?
Your whitelisting solution should accommodate software updates through publisher-based rules (trusting signed updates from approved vendors), integration with patch management systems, or automated hash updates. Many modern application control tools can automatically trust updated versions from the same publisher. You should test your approach to ensure patches don't get blocked while maintaining security. Document your update process as part of your application control policy.
Do we need to verify the integrity of every application using checksums or digital signatures?
The control states organizations should 'consider' verifying integrity of whitelisted software using cryptographic methods. While not absolutely mandatory, it is a best practice and strengthens your implementation. At minimum, you should verify integrity for critical applications, applications with CUI access, and applications from untrusted sources. Many whitelisting tools include built-in integrity verification through publisher certificate validation or hash checking.
How ConformatIQ Helps With CMMC Readiness
ConformatIQ is an AI-assisted CMMC readiness platform designed to help organizations prepare for assessments more efficiently. The platform supports document generation such as SSPs and POA&Ms, guided readiness workflows, centralized evidence tracking, and interview preparation for assessments.
Ready to Get Full Guidance?
Access complete implementation details, detailed assessment questions, evidence requirements, and expert guidance for this control.
Request Full GuidanceInformation sourced from NIST SP 800-171 Rev. 2. See full disclaimer.