This practice is closely related to CM.L2-3.4.6 (Least Functionality) but focuses more specifically on the identification and restriction of individual functions, ports, and protocols. Where CM.L2-3.4.6 is about overall system hardening, CM.L2-3.4.7 digs into specific capabilities that could be restricted without affecting system function. Restricting nonessential protocols and ports also ties to SC.L2-3.13.1, which requires you to monitor system monitoring and analysis. The fewer open ports and protocols, the less surface area you have to monitor for attacks.
What the assessor is actually evaluating
The assessor is looking for evidence that you’ve done the detailed work of identifying which specific capabilities can be disabled or restricted.
Do you know what ports your systems need? Not “our servers open some ports.” Can you list the exact ports required for each system type and justify them? Port 443 for HTTPS, yes. Port 3389 for Remote Desktop on a server that’s only accessed locally, no. The assessor wants that level of specificity.
Have you restricted unnecessary protocols? NetBIOS, SNMP, Telnet, IPv6 if you’re not using it. These protocols are often enabled by default but don’t need to be. Have you explicitly disabled them? Can you show firewall rules that block them?
Are unused ports actually blocked? It’s not enough to say they’re not being used. They should be explicitly blocked at the firewall or the application shouldn’t be listening on them. The assessor will run a port scan and expect to see only necessary ports responding.
Have you documented the reasoning? When the assessor sees a port open, you should be able to explain why it’s there. When they see a port closed, you should be able to explain why you restricted it. The assessment isn’t just about the configuration. It’s about showing you understand it.
What a realistic SSP definition looks like
[Organization Name] restricts or disables all nonessential functions, ports, protocols, and services on systems within the CUI boundary. Nonessential capabilities are identified through a combination of system documentation and vulnerability assessments. Services that are not required for system operation are disabled. Network ports that are not used are blocked at the firewall. Protocols such as NetBIOS, SNMP, and Telnet are disabled on all systems.
The network firewall is configured to restrict inbound traffic to only necessary ports and protocols. Outbound restrictions are applied where business function permits. The firewall rules are documented and reviewed quarterly to identify and remove rules that are no longer necessary.
Annually, the organization performs a port scan of systems within the CUI boundary to verify that only documented, necessary ports are responding to network traffic. Any unexpected open ports are investigated and either justified or closed.
Key details:
It specifically names protocols to disable. NetBIOS, SNMP, Telnet. These are real examples. The assessor knows these are common attack vectors and will recognize that you’ve thought about them.
It describes the identification process. System documentation and vulnerability assessments show that your approach is methodical. You’re identifying nonessential protocols through assessment, not making arbitrary decisions.
It includes firewall configuration. Both inbound and outbound. You’re controlling what can reach your systems and what they can reach.
It includes a verification step. Annual port scans to confirm that the configuration on paper matches reality. This is critical because drift happens. Services get reinstalled, patches enable something, configurations get missed. The annual scan catches it.
How to present your evidence
- Documentation of which ports and protocols are necessary for your systems
- Firewall rule documentation showing restriction of nonessential ports
- Service and protocol lists showing what's explicitly disabled
- Port scan results showing only documented ports open
- Firewall policy documentation with review dates
- Records of any unexpected ports found and the remediation taken
When the assessor reaches CM.L2-3.4.7:
A port and protocol matrix. For each system type or critical system, document which ports should be open and why. File server: 445 for SMB, 3389 for RDP is disabled, 123 for NTP. Web server: 80 and 443 only. Workstation: ephemeral ports for outbound, limited inbound. You need this to explain your firewall configuration.
Your firewall rules. Either the actual rules from your firewall or a summary of them. Inbound rules that show blocking of unnecessary ports. Outbound rules that restrict where systems can communicate. The rules should be tied to the port and protocol matrix.
A list of disabled services and protocols. Explicitly. “NetBIOS disabled,” “SNMP disabled,” “Telnet not installed,” etc. This demonstrates deliberate configuration work, not relying on system defaults.
Port scan results. Run an external scan and an internal scan. Include the most recent ones. Show that only expected ports are open. If there are unexpected ports, show that you’ve investigated and either justified them or closed them.
Firewall policy with review documentation. Your firewall rules shouldn’t be static. You should review them periodically and remove rules that are no longer needed. Provide evidence of that review.
Keep answers short. Show the evidence, don't describe it. Let the assessor drive. For more on how to present in the assessment room, see How to Present Evidence in the Assessment Room.
Common failures
No firewall rules at all.** Network traffic is completely open, or there's a firewall but no documented rules. The assessor can't see what you're blocking or why.
Overly permissive rules.** The firewall allows large ranges of ports "just in case." Or rules are so general that they allow unnecessary traffic. Rules should be specific and justified.
No verification.** You claim ports and protocols are restricted, but port scans show they're open. Or the firewall rules say something should be blocked but it's not actually blocked.
Services enabled with default configurations.** SNMP running with default community strings. Remote Desktop with default settings. Services that are technically unnecessary but running anyway with no documentation of why they're there.
No documentation of necessity.** The assessor asks why a port is open, and you don't have a clear answer. "It might be needed for something" is not sufficient.
Clear documentation of which ports and protocols are needed. Firewall rules that align with that documentation. Port scans showing only necessary ports open. Disabled services for anything nonessential. When the assessor can trace from your documented requirements to your firewall rules to actual network behavior and find them all aligned, they move on satisfied.
Short, practical breakdowns of what assessors actually ask and how to answer. No compliance jargon, no sales pitch. Subscribe free on Substack.
If you use an MSP/MSSP
If your MSP manages the network or firewalls, you should still understand and be able to explain the configuration.
What to ask your MSP for:
Firewall rule documentation. Not just “the firewall is configured.” Get a list or export of actual rules. Understanding what you’re allowing and what you’re blocking is part of compliance.
Port scan results. Your MSP should be running regular scans to verify that the configuration matches the intended state. Ask for the most recent results.
Baseline or standard configuration. Most MSSPs have a standard firewall baseline they apply to customer environments. Ask for it. Understand what it blocks and why. If it doesn’t match your specific needs, ask for modifications and documentation of those modifications.
Change records for firewall rules. If rules are added or modified, there should be a record. This ties to CM.L2-3.4.3 (change management). Firewall rule changes should be tracked the same way as system changes.
Many organizations focus on inbound firewalling and forget egress. Restricting outbound traffic to necessary destinations is increasingly important. If your network architecture allows systems to initiate outbound connections to anywhere on the internet, that's a risk. A good MSSP will have egress filtering policies. If yours doesn't, ask about it. At minimum, you should be able to show that systems can't reach unexpected destinations.
This page covers CM.L2-3.4.7 from NIST SP 800-171 Rev 2 (3.4.7). The guidance here is based on experience in real CMMC assessments and is intended to help you prepare. It is not legal or compliance advice. Your organization’s situation is unique, and you should work with qualified professionals for formal assessment preparation.