How to Meet NIST SP 800-171 REV.2 / CMMC 2.0 Level 2 - Control - SC.L2-3.13.5

Requirement

NIST SP 800-171 REV.2 / CMMC 2.0 Level 2 - Control - SC.L2-3.13.5 – Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks.

Understanding the Requirement

This control in NIST SP 800-171 REV.2 / CMMC 2.0 Level 2 requires that any system components you expose to the internet (web servers, mail gateways, remote-access jump hosts, API endpoints, etc.) be moved off your internal network into subnetworks that are physically or logically separated—commonly called demilitarized zones (DMZs). The goal is twofold: first, identify which components are publicly accessible; second, ensure those components live in a segmented environment with boundary controls so a compromise of a public-facing system does not provide direct access to internal assets.

Technical Implementation

• Inventory and classification: Start by creating a simple inventory of publicly accessible components (web, mail, VPN endpoints, APIs). Label each item with owner, function, ports/protocols exposed, and risk level. This gives you the scope for segmentation work and a basis for firewall rules.
• Design a DMZ architecture: Choose physical separation (dedicated hardware) or logical separation (VLANs and subnets). For most SMBs, a logical DMZ implemented with VLANs, separate subnets, and a perimeter firewall is cost-effective. Define explicit ingress/egress rules: only allow necessary services (e.g., TCP 80/443 to a web server) and deny all else by default.
• Control traffic at boundaries: Implement a stateful firewall or next-generation firewall between the internet and the DMZ, and another between the DMZ and the internal network. Use access control lists (ACLs), NAT, and reverse proxying to limit direct connections. Require only specific, tightly scoped connections from the DMZ to internal systems (for example, a database connection from the web app to a DB server using specific IPs/ports).
• Harden public systems and separate management: Harden servers in the DMZ (minimal services, regular patching, host-based firewall). Do not allow administrative access (SSH/RDP) from the internet—use a separate management VLAN or a bastion/jump host accessible only from the internal network or via MFA-protected VPN. Log and monitor all administrative sessions.
• Use layered controls for web services: Consider a reverse proxy, web application firewall (WAF), TLS termination, and DDoS protection for internet-facing services. For cloud-hosted services, use provider VPC public subnets and security groups to enforce the same separation and boundary rules as an on-prem DMZ.
• Monitoring, testing, and maintenance: Enable centralized logging for DMZ devices and servers (syslog/SIEM). Perform regular vulnerability scans and penetration tests focused on DMZ assets. Maintain patching, backups, and incident response playbooks that assume a DMZ compromise scenario to validate containment controls.

Example in a Small or Medium Business

A 40-person marketing agency needs a public website and a client portal. The IT lead inventories the public components and decides not to place them on the internal LAN. They create a DMZ using a separate VLAN and subnet on their existing firewall appliance. The web servers run in that DMZ and the firewall allows only TCP 80/443 from the internet to the web servers and only a single, encrypted database port from the DMZ to a database server in a separate subnet. Administrative access to the web servers is only permitted through an internal jump host on a management VLAN, where access requires MFA. They configure a reverse proxy with a WAF to inspect incoming traffic and terminate TLS, and forward logs from the web servers and firewall to a cloud log collector for monitoring. Monthly vulnerability scans and weekly patching are scheduled, and the IT lead documents the DMZ architecture and runs a tabletop incident scenario to ensure a compromised web server cannot reach internal file shares or employee machines.

Summary

Separating publicly accessible components into a DMZ—physically or logically isolated from internal networks—reduces the blast radius of internet-facing compromises. For SMBs this is achievable with clear inventory and classification, a simple DMZ design implemented with VLANs/subnets and perimeter firewalls, hardened servers and restricted management paths, layered protections for web services, and ongoing monitoring and testing. Together, the policy (identify and require separation) plus the technical controls (firewalls, VLANs, ACLs, WAF, hardened hosts, logging) meet the intent of SC.L2-3.13.5 and keep internal networks protected from public-facing risks.