System and Communications Protection 3.13.6 (3.13.6)
Deny network communications traffic by default and allow network communications traffic by exception (i.e., deny all, permit by exception).
Get Full GuidanceWhat Is This CMMC Control?
This control requires organizations to block all network traffic by default and only allow specific, approved connections. Think of it as a 'closed door' policy where nothing gets through unless explicitly permitted. This applies to traffic coming into your systems, going out of your systems, and moving between different parts of your network. The goal is to minimize your attack surface by ensuring only necessary and authorized network communications can occur.
Control Intent
Prevent unauthorized network access and data exfiltration by implementing a default-deny network security posture that minimizes the attack surface and ensures only explicitly approved network communications are permitted.
Who This Control Applies To
- •Organizations processing, storing, or transmitting CUI
- •All network boundaries where CUI systems connect to external networks
- •Internal network segments that separate CUI systems from non-CUI systems
- •Firewalls, routers, and network security appliances controlling traffic to/from CUI systems
- •Cloud-hosted systems and services processing CUI
- •Remote access solutions providing connectivity to CUI environments
- •Network connections between organizational systems and third-party service providers
Not Applicable When
- •The organization has no networked systems (standalone, air-gapped systems only)
- •The system has no network boundary or connection to other networks
- •The organization does not process, store, or transmit CUI
Key Objectives
- 1Implement default-deny network policies at system boundaries to block unauthorized inbound and outbound traffic
- 2Establish and maintain an explicit allow-list of approved network communications based on business necessity
- 3Enforce network segmentation controls at identified internal points to limit lateral movement and contain potential breaches
- 4Ensure network security controls are consistently applied across all system boundaries and internal network segments
Sample Self-Assessment Questions (Partial)
Do you have firewalls or network security devices controlling traffic to and from your systems?
Are your firewall rules configured to block all traffic by default and only allow specific approved connections?
Implementation Approaches (High-Level)
Perimeter Firewall with Default-Deny Policy
Network firewall appliance or software positioned at the system boundary with explicit default-deny rules and documented exceptions for required communications.
Cloud Security Groups and Network ACLs
Cloud-native network security controls (AWS Security Groups, Azure NSGs, GCP Firewall Rules) configured with default-deny and explicit allow rules for cloud-hosted CUI systems.
Network Segmentation with Internal Firewalls
Internal network segmentation using VLANs, firewalls, or software-defined networking to enforce deny-by-default between network zones, not just at the perimeter.
Host-Based Firewall with Application Control
Firewall software running on individual systems (Windows Firewall, iptables, host-based firewalls) configured to deny all traffic except approved applications and services.
Next-Generation Firewall with Deep Packet Inspection
Advanced firewall appliance providing application-aware filtering, intrusion prevention, and content inspection while maintaining deny-by-default posture.
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 deny-by-default is not currently implemented, prioritize perimeter firewall configuration as the first milestone, followed by internal segmentation For organizations with overly permissive firewall rules, create a phased approach to tighten rules incrementally while monitoring for operational impact If cloud security groups allow all outbound traffic, document a timeline for implementing outbound restrictions with business unit coordination For environments lacking network segmentation, develop a segmentation architecture plan before attempting to implement deny-by-default at internal points If firewall rule documentation is missing, conduct a business impact analysis to identify and document required communications before enforcing stricter policies For organizations where users can bypass network controls, implement endpoint security solutions as an interim control while addressing network architecture gaps If deny-by-default cannot be fully implemented immediately due to operational constraints, document compensating controls such as enhanced monitoring and intrusion detection Include specific milestones for firewall rule reviews and removal of obsolete exceptions in the POA&M timeline For complex environments, consider engaging a network security consultant to design the deny-by-default architecture before implementation Ensure POA&M includes both technical implementation tasks and procedural elements like change management and approval processes
Frequently Asked Questions
Does deny-by-default mean we have to block all outbound traffic from our systems?
Yes, a true deny-by-default policy applies to both inbound and outbound traffic. However, you can create explicit allow rules for necessary outbound connections such as software updates, cloud services, and business applications. The key is that outbound traffic must be restricted to approved destinations rather than allowing all outbound connections by default.
Do we need to implement deny-by-default inside our network or just at the perimeter firewall?
The control requires deny-by-default at the system boundary AND at identified points within the system. This means you need both perimeter protection and internal network segmentation. At minimum, you should segment CUI systems from non-CUI systems with deny-by-default enforcement between segments to limit lateral movement.
How do we handle cloud-based systems where we don't control the physical firewall?
For cloud-hosted systems, you implement deny-by-default using cloud-native controls like security groups, network ACLs, or cloud firewall services. These function equivalently to traditional firewalls. You must configure them to deny all traffic by default and explicitly allow only required communications, including restricting outbound traffic to approved destinations.
What happens if we need emergency network access that isn't in our approved list?
You should have a documented emergency change process that allows temporary exceptions while maintaining security. The emergency access should be logged, reviewed afterward, and either formalized as a permanent exception with proper justification or removed once the emergency is resolved. The key is that even emergency changes must be documented and not bypass the deny-by-default principle permanently.
Can we use application-layer controls instead of network-layer deny-by-default?
Application-layer controls (like web application firewalls) complement but do not replace network-layer deny-by-default requirements. You must implement deny-by-default at the network layer (blocking IP addresses, ports, and protocols) as the foundation. Application-layer controls can provide additional security but cannot substitute for the required network-level enforcement.
How often do we need to review our firewall rules and approved exceptions?
While the control doesn't specify a frequency, industry best practice and assessor expectations typically require at least annual reviews of firewall rules. More frequent reviews (quarterly or semi-annually) are recommended for environments with frequent changes. Each review should verify that exceptions are still necessary, properly documented, and aligned with current business needs.
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.