System and Communications Protection 3.13.5 (3.13.5)
Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks.
Get Full GuidanceWhat Is This CMMC Control?
This control requires organizations to create isolated network zones (DMZs) for systems that face the internet or public networks. These zones must be separated from internal networks where sensitive data resides, using firewalls, routers, or other boundary controls. The goal is to prevent attackers who compromise public-facing systems from directly accessing internal CUI environments.
Control Intent
Prevent unauthorized access to internal networks and CUI by isolating publicly accessible systems in separate network segments with controlled access points.
Who This Control Applies To
- •Organizations with web servers, email gateways, or other internet-facing systems
- •Environments where public users or external parties access organizational services
- •Networks hosting both publicly accessible services and internal CUI systems
- •Cloud-hosted applications that serve public users while processing CUI
- •Remote access infrastructure including VPNs and jump servers
Not Applicable When
- •The organization has no publicly accessible systems or services
- •All systems are air-gapped with no internet connectivity
- •The organization operates entirely within a service provider's environment with no direct public exposure
- •Systems process only public information with no CUI present in the environment
Key Objectives
- 1Establish physical or logical separation between publicly accessible systems and internal networks containing CUI
- 2Implement boundary controls that restrict traffic flow between public-facing zones and internal networks
- 3Reduce the attack surface by limiting direct connectivity from internet-facing systems to CUI environments
Sample Self-Assessment Questions (Partial)
Do you operate any websites, web applications, or online services accessible from the internet?
Do you have email servers, file transfer systems, or remote access portals that external users can reach?
Implementation Approaches (High-Level)
Physical DMZ with Dedicated Firewall
Separate physical network segment with dedicated firewall appliances controlling traffic between internet, DMZ, and internal zones
Virtual DMZ with Network Segmentation
Logically separated network zones using VLANs, virtual firewalls, or software-defined networking
Cloud-Based DMZ with Security Groups
Cloud-native network segmentation using VPCs, subnets, security groups, and network ACLs
Reverse Proxy DMZ Architecture
Public-facing reverse proxies or API gateways in DMZ that terminate external connections and proxy to internal services
Jump Server / Bastion Host DMZ
Dedicated jump servers in DMZ for administrative access to internal networks, with no direct remote access to internal systems
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 no DMZ exists, create a phased implementation plan starting with identifying all publicly accessible systems For flat networks, prioritize implementing at minimum a virtual DMZ using VLANs and firewall rules If cloud-based, leverage native cloud segmentation features (VPCs, security groups) as interim solution Document current network architecture as baseline, then create target architecture showing proper DMZ For organizations with limited resources, focus first on isolating the most critical public-facing systems Consider managed firewall or cloud security services if internal expertise is limited Ensure POA&M includes both technical implementation and documentation of DMZ architecture Plan for ongoing firewall rule review process as part of remediation If using service providers, document how provider implements DMZ on your behalf
Frequently Asked Questions
What qualifies as a 'publicly accessible system' that needs to be in a DMZ?
Any system with a public IP address or that accepts connections from the internet qualifies. This includes web servers, email gateways, VPN endpoints, remote access portals, public-facing APIs, and any service that external users or partners can reach. If a system can be accessed without first connecting to your internal network, it should be in a DMZ.
Can we use cloud security groups instead of a traditional firewall for DMZ implementation?
Yes, cloud-native controls like security groups, network ACLs, and VPC segmentation are acceptable DMZ implementations. The key requirement is logical separation and traffic control between public-facing and internal systems. Cloud architectures using separate subnets or VPCs with properly configured security groups meet this control's intent.
Do we need a DMZ if we only use SaaS applications and have no on-premises infrastructure?
If you have no systems with public IP addresses or internet-facing services that you control, this control may not be applicable. However, if you operate any web applications, APIs, or services accessible from the internet—even if cloud-hosted—you need to ensure they are segmented from internal CUI systems. Consult with your assessor about applicability to your specific environment.
What firewall rules are required between the DMZ and internal network?
Firewall rules must follow the principle of least privilege, allowing only specific, documented traffic from DMZ to internal networks. Default-deny rules should block all DMZ-to-internal traffic except explicitly approved services. For example, a web server in the DMZ might be allowed to query a specific internal database server on port 3306, but no other access. All rules should be documented with business justification.
How often do DMZ firewall rules need to be reviewed?
While this control does not specify a review frequency, best practice and related controls suggest at least annual review of firewall rules. Many organizations review quarterly or whenever changes are made. The review should verify that rules are still necessary, properly documented, and follow least privilege principles. Excessive or outdated rules should be removed.
Can remote access VPNs terminate directly on the internal network, or must they go through a DMZ?
Best practice is to terminate VPN connections in a DMZ, then require a second authentication or access control before reaching internal CUI systems. However, if the VPN server itself is properly hardened and enforces strong authentication, some assessors may accept direct termination to internal networks. The key is ensuring external connections do not provide unrestricted access to CUI environments. Document your architecture and rationale clearly.
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.