CMMC Level 2 Practice 3.4.7: Restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and

CMMC Level 2 Practice 3.4.7 requires you to identify what software, services, ports, protocols, and device functions are not necessary for business on systems that process, store, or transmit CUI, then restrict or disable them and keep evidence that the restrictions are enforced. Operationalize it by creating “allow lists” (approved apps/services and approved network flows) plus hardening baselines, change control, and recurring verification. ¹

Key takeaways:

• Build an explicit “what’s allowed” standard (apps, services, ports/protocols) for your CUI boundary, then block everything else.
• Implement with technical controls (host firewall, EDR/app control, GPO/MDM baselines, network ACLs) and back it with change management.
• Evidence wins assessments: retain baselines, approved lists, scan results, and change tickets that show restrictions stay in place.

CMMC Level 2 aligns to NIST SP 800-171 Rev. 2, and Practice 3.4.7 is one of the most operational controls in the configuration management family: reduce attack surface by shutting off “stuff you don’t need.” The assessment risk is rarely that an organization has no controls; it’s that the organization cannot prove a repeatable method for deciding what is “nonessential,” enforcing that decision consistently across the CUI environment, and detecting drift over time. ²

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat 3.4.7 as an allowlisting and hardening requirement with three deliverables: (1) a documented standard for approved programs, services/functions, ports, and protocols for the CUI boundary; (2) technical enforcement (endpoint and network) that matches the standard; and (3) recurring evidence capture that shows the standard is applied, exceptions are approved, and deviations are corrected. This page gives you requirement-level interpretation, a step-by-step build plan, and the artifacts assessors typically ask for. ¹

Regulatory text

Practice statement (mapped): “CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.4.7 (Restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and).” ¹

What the operator must do: On in-scope systems (your CUI environment and supporting infrastructure), you must (a) determine what is essential for mission and operations, (b) restrict/disable everything else at the host and network layers, and (c) maintain proof that controls are implemented and remain effective through ongoing configuration management. ²

Plain-English interpretation (what 3.4.7 really means)

3.4.7 is “attack surface management by policy + enforcement.” If a program, feature, service, port, or protocol does not directly support an approved business need in the CUI boundary, you turn it off or block it. If you can’t disable it (legacy dependencies happen), you must restrict it tightly and document the exception.

Think of four categories you must control:

1. Programs: installed applications and agents (including admin tools and remote access tools).
2. Functions/services: OS roles, background services, optional components (e.g., file sharing services, print spooler where not needed).
3. Ports/protocols: inbound and outbound network paths (e.g., SMB, RDP, SSH, SNMP, legacy protocols).
4. “Nonessential” definition: a business-driven allowlist with an explicit exception path.

Assessors tend to look for two things: a rational method to define “nonessential” and objective technical enforcement. ²

Who it applies to (entity and operational context)

Applies to organizations seeking CMMC Level 2 that handle CUI for the DoD, including defense contractors and other federal contractors handling CUI. ³

Operationally, it applies to:

• Endpoints and servers inside your CUI boundary (workstations, VDI, on-prem servers, cloud VMs).
• Network/security devices that mediate CUI flows (firewalls, VPN, ZTNA, proxies).
• Managed SaaS configurations where “functions” and “protocols” map to tenant settings, app integrations, and enabled features (admin consoles, external sharing, legacy auth options).
• Third-party-provided systems if they are inside your CUI boundary or provide security functions for it (e.g., MSP-managed endpoints, SOC tooling). You remain accountable for the control outcome. ⁴

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

Step 1 — Set scope: define the CUI boundary and asset inventory

• Confirm the system boundary that stores, processes, or transmits CUI and the supporting components.
• Produce/refresh an inventory of endpoints, servers, network segments, and key applications in scope. Output: “CUI Boundary + Asset Inventory” used by IT and Security for enforcement and evidence. ²

Step 2 — Define “essential” via allowlists (do this before blocking)

Create three allowlists, each with an owner and change process:

• Approved software list (by device role): required apps, approved admin tools, security agents.
• Approved services/functions list (by OS baseline): enabled roles/services; everything else disabled.
• Approved ports/protocols/flows list: documented inbound/outbound rules by source, destination, port, protocol, and purpose.

Practical approach: build baselines by role (user workstation, developer workstation, server role types, DMZ jump host). Your allowlist should state “default deny; allow by exception.” ⁵

Step 3 — Implement technical enforcement (endpoint)

Pick controls that match your environment:

• GPO/MDM baselines to disable nonessential OS features and services, enforce local firewall, and remove optional components.
• Application control (allowlisting/denylisting) through OS-native controls or EDR where available; at minimum, block known risky tools not required for business in the CUI boundary.
• Local admin governance so users cannot install arbitrary programs that bypass your list. Evidence hint: screenshots and exported baseline policies are not enough by themselves; keep proof of deployment coverage and device compliance status. ⁵

Step 4 — Implement technical enforcement (network)

• Enforce host-based firewall rules for endpoints and servers, aligned to approved flows.
• Enforce network firewalls/ACLs/security groups between segments so only required ports/protocols traverse the CUI boundary.
• Control remote administration: restrict management ports to jump hosts and admin subnets; block from user networks by default. Evidence hint: capture firewall rule exports plus change tickets that show approvals and periodic review. ⁵

Step 5 — Establish an exception and change-control workflow

You need a repeatable way to handle “we need to open a port” or “this legacy app needs a service enabled.” Minimum fields for an exception:

• business justification tied to CUI processing
• scope (assets/users)
• compensating controls (segmentation, MFA, monitoring)
• expiration/review trigger
• approval by system owner and security This is where many teams fail: they make changes in tickets, but they don’t tie them back to the allowlist standard. ²

Step 6 — Verify continuously and capture recurring evidence

Establish drift detection:

• configuration compliance reports (MDM/GPO)
• vulnerability scans that also report open ports/services
• EDR/software inventory reports
• firewall rule review outputs Then define your operational cadence: review exceptions, compare actuals vs. allowlists, remediate deviations, and store evidence in an assessment-ready folder. ⁴

Required evidence and artifacts to retain (assessment-ready)

Use this as an evidence checklist:

Governance / documentation

• CUI boundary definition and in-scope asset list (or CMDB export)
• “Nonessential services/programs/ports/protocols” standard with allowlists by role
• Configuration baseline documents (secure build standards) for key platforms
• Exception process and samples of approved exceptions (with expiry/review)

Technical proof (implementation + operation)

• MDM/GPO policy exports showing disabled services and firewall posture
• Application control/EDR policy exports and blocked app events (where applicable)
• Endpoint software inventory reports showing installed apps align to approved list
• Firewall/ACL/security group exports mapped to approved flows list
• Scan results or host/network discovery showing only required ports are exposed
• Change tickets tied to allowlist updates (not just device fixes)

Operational proof

• Recurring review records (meeting notes, review sign-offs, or ticket batches)
• Remediation tickets for drift and closure evidence
• Metrics are optional; proof of action is not. ⁶

Common exam/audit questions and hangups

Expect questions like:

• “Show me how you decide a program/port is essential versus nonessential.”
• “Which ports are allowed from user subnets to servers in the CUI boundary, and why?”
• “How do you prevent users from installing tools that create unmanaged remote access?”
• “Show evidence that the baseline is deployed to all in-scope assets.”
• “How do you detect drift and how quickly do you correct it?” Hangup: teams show a hardening guide, but not the live enforcement output. Bring both. ⁴

Frequent implementation mistakes (and how to avoid them)

1. No explicit allowlist. “We block bad stuff” is not the requirement. Write what’s allowed by role, then enforce it. ⁵
2. Relying on a perimeter firewall only. Lateral movement risk remains. Add host firewall and segmentation controls inside the boundary. ⁵
3. Exceptions with no expiry. Every “temporary” opening becomes permanent. Add a review trigger and track it. ⁵
4. Shadow IT inside the CUI boundary. If teams can self-provision tools, you will lose control of programs and protocols. Gate installs and integrations. ⁵
5. Evidence gaps. Screenshots don’t scale. Prefer exported policies, system-generated compliance reports, and change-control records. ⁷

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. In practice, your immediate risk is assessment failure due to weak demonstration of control operation: if you cannot show documented allowlists, technical restrictions, and ongoing verification, assessors can reasonably conclude the practice is not met. CMMC Level 2 requirements are tied to eligibility to handle DoD CUI under the CMMC Program framework. ³

Practical 30/60/90-day execution plan

Use this as an operator’s rollout sequence; adjust based on your environment size and change windows.

Days 0–30: Baseline and decide “what’s essential”

• Confirm CUI boundary and in-scope asset inventory.
• Draft allowlists for (1) software, (2) services/functions, (3) ports/protocols/flows.
• Identify quick wins: remove unused software, disable obvious unused services, close obvious unused inbound ports.
• Stand up an exception workflow and name approvers.

Days 31–60: Enforce on endpoints and servers

• Deploy updated MDM/GPO baselines to in-scope endpoints and servers.
• Implement application control where feasible; otherwise tighten installation rights and EDR policies.
• Turn on host firewall rules aligned to approved flows.
• Start recurring evidence capture: compliance reports, inventories, and drift tickets.

Days 61–90: Enforce on the network and prove durability

• Align network firewall/ACL rules to the approved flows list; remove stale rules.
• Restrict admin protocols to jump hosts and admin subnets; validate with scans.
• Run a formal exception review and expire or remediate anything unjustified.
• Package evidence into an assessor-ready binder: standards, baselines, exports, and a sample trail from request → approval → implementation → verification. ⁴

Tooling note (where Daydream fits)

Daydream is useful when you need a single place to map 3.4.7 to control language, assign owners, and keep recurring evidence (policy exports, scan results, exception tickets) tied to the practice so assessment prep becomes routine rather than a scramble. ⁴

Frequently Asked Questions

Does 3.4.7 require application allowlisting on every endpoint?

The requirement is to restrict or prevent nonessential programs and functions. Application allowlisting is a strong way to meet the intent, but you can also meet it through a combination of controlled installation rights, managed baselines, and monitoring, as long as you can prove enforcement and drift handling. ⁵

How do we define “nonessential” without over-blocking the business?

Define “essential” by device role and documented business purpose, then treat everything else as nonessential by default. Start with a monitored “report-only” posture where possible, then enforce with an exception path for genuine business needs. ⁵

Are outbound ports and protocols in scope, or only inbound?

The practice covers ports and protocols generally, so assess both inbound exposure and outbound egress paths from the CUI boundary. Document approved outbound destinations and protocols for CUI workflows and block the rest where feasible. ⁵

What evidence is strongest for a CMMC assessment for 3.4.7?

Assessors respond well to system-generated exports and reports: enforced baseline policies, firewall rule exports, software inventory, scan outputs showing closed ports, plus a small set of change tickets that demonstrate governance and exceptions. ⁴

How do we handle legacy systems that require insecure protocols or open ports?

Treat it as an approved exception with tight scope, segmentation, restricted admin access, and documented compensating controls. Record the business justification and a plan to remove the dependency, then review the exception on a recurring basis. ⁵

Does this apply to cloud and SaaS, or only on-prem?

It applies to any in-scope environment that processes, stores, or transmits CUI. In cloud/SaaS, “functions” and “protocols” often map to tenant features, integrations, and identity/auth settings, and you should disable nonessential features the same way you would on endpoints. ²

Footnotes

1. NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance; 32 CFR Part 170

2. NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance

3. 32 CFR Part 170; DoD CMMC Program Guidance

4. DoD CMMC Program Guidance; NIST SP 800-171 Rev. 2

5. NIST SP 800-171 Rev. 2

6. DoD CMMC Program Guidance; NIST SP 800-171 Rev. 2; 32 CFR Part 170

7. DoD CMMC Program Guidance