CMMC 3.13.5 (Public Subnetwork Separation): Evidence & What Assessors Actually Check

Control: NIST SP 800-171 Rev. 2 §3.13.5 · CMMC Practice: SC.L2-3.13.5 · Updated June 2026

Plain-English answer

3.13.5 requires you to put publicly accessible system components in subnetworks physically or logically separated from your internal networks — a DMZ. Two steps: identify what's internet-facing, then make sure it doesn't share a network segment with your internal systems and CUI.

Who this applies to

Every organization seeking CMMC Level 2 for a CUI environment — most directly anyone hosting internet-facing services (web, mail relay, VPN, remote-access gateways).

Why it matters

Public-facing systems get attacked first. Separating them means a compromised web server can't pivot straight onto the network holding your CUI. It carries a weighted SPRS deduction if unmet (verify the exact value against the DoD Assessment Methodology).

Control lineage

  • CMMC Practice: SC.L2-3.13.5
  • NIST 800-171 Rev. 2: §3.13.5 — implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks.
  • NIST 800-171A objectives: [a] publicly accessible system components are identified; [b] subnetworks for publicly accessible system components are physically or logically separated from internal networks.

What the assessor will EXAMINE

  • A list of publicly accessible system components (or a documented "none").
  • Network diagram showing those components in a separated subnetwork / DMZ.
  • Firewall/VLAN configuration enforcing the separation between the DMZ and internal networks.
  • SSP narrative for 3.13.5.

What the assessor will INTERVIEW & TEST

  • Interview: "What's publicly accessible, and how is it separated from your internal network?" — point to the inventory + diagram + segmentation rules.
  • Test: Confirm the DMZ segment can't freely initiate connections into the internal network.
  • Test: Reconcile the public-component list against what's actually internet-reachable (no surprise exposed hosts).

Evidence examples (produce these)

  • Inventory of publicly accessible components (or documented "none applicable" with rationale).
  • Network diagram showing DMZ separation from internal networks.
  • Firewall/VLAN/ACL config enforcing DMZ-to-internal restrictions.
  • SSP section 3.13.5 referencing the above.

Common failure patterns

  • A public web/mail server on the same flat LAN as internal systems — objective [b] fails.
  • Public components never inventoried, so exposure is unknown — objective [a] fails.
  • A "DMZ" that can still reach internal hosts at will — separation in name only.
  • Shadow internet-facing services (a forgotten port-forward) not in the inventory.

SPRS impact & POA&M

SPRS: 3.13.5 carries a weighted deduction (verify the exact value). POA&M: confirm 3.13.5's POA&M eligibility against current CMMC rules before assuming it can be deferred.

Assessor-ready summary

You're good on 3.13.5 when every publicly accessible component is identified and sits in a subnetwork physically or logically separated from internal networks, the separation is enforced by configuration (not just drawn on a diagram), and the SSP matches reality.

Is anything internet-facing sharing a segment with your CUI? Get a segmentation evidence map →

Related: 3.13.1 Boundary Protection · 3.1.20 External Systems · All control pages

Athena prepares organizations for CMMC Level 2; certification rests with C3PAOs/DIBCAC. Verify all control facts against NIST SP 800-171 Rev. 2, NIST SP 800-171A, and current CMMC rules.