SC.L2-3.13.6 is a commonly missed practice in CMMC Level 2 assessments. Not because organizations ignore it, but because they genuinely believe they’ve satisfied it when they haven’t.
3.13.6 Deny network communications traffic by default and allow network communications traffic by exception (i.e., deny all, permit by exception).
| ASSESSMENT OBJECTIVE | |
| 3.13.6[a] | network communications traffic is denied by default. |
| 3.13.6[b] | network communications traffic is allowed by exception. |
What this means: Both inbound AND outbound network traffic must be blocked by default, with only explicitly approved communications permitted.
Why this trips organizations up
Most Level 2 organizations have invested heavily in good controls: MFA, conditional access, endpoint protection, SIEM monitoring. All of that is good security. It just answers different questions.
Identity controls answer: Who can connect?
Threat protection answers: Is this connection dangerous?
3.13.6 asks: Is this destination explicitly approved?
Answer this question:
A user on a managed, compliant device with valid credentials and MFA tries to access Dropbox. It’s not malicious. It’s not a phishing site. It’s just not approved for your CUI environment. What happens?
If the answer is “the connection goes through and we’d see it in our logs”, you don’t meet 3.13.6.
If the answer is “it’s blocked”, keep reading to make sure you can prove it.
Common assessment conversations sound like:
“We use Microsoft GCC High / AWS GovCloud / [cloud provider], which has built-in security. Their Zero Trust architecture handles boundary protection, so we don’t need traditional deny-by-default network controls. We have:
- Strong identity controls (MFA, Conditional Access)
- Device compliance requirements
- Behavioral monitoring and threat detection
- Real-time malicious traffic blocking
This meets 3.13.6 through a modern security model.”
NOPE.
The practice wording is deceptively simple: “Deny network communications traffic by default and allow network communications traffic by exception.” Both inbound AND outbound traffic must be blocked by default. Only explicitly approved communications are permitted. No caveats for architecture. No exceptions for cloud environments.
This control is preventing data exfiltration and Command-and-Control activity. If a piece of malware bypasses your front door, its first move is to “call home” to a server for instructions or to begin shipping your sensitive Controlled Unclassified Information (CUI) to a foreign server.
The requirement draws a hard line between two models. Threat-based blocking allows all traffic and blocks what it recognizes as dangerous, like a bouncer checking IDs against a list of banned patrons. Deny-by-default blocks all traffic and only allows what’s been specifically approved, a locked door with a guest list. If you’re not on the list, you don’t get in, even if you’re perfectly harmless.
3.13.6 requires the guest list model.
Simply monitoring and logging unauthorized traffic is not enforcement. If a compliant user on a compliant device can reach a legitimate but unapproved external site, the control is NOT MET. Compliance requires that the connection is blocked at the enforcement layer—whether that is the network perimeter, a host-based firewall, or a DNS filter.
What meeting this actually looks like
Deny by default is implementable in every architecture. The mechanism can differ, but the logic is always the same: block everything, then create explicit exceptions for approved traffic.
Your enforcement point could be a perimeter firewall, host-based firewalls pushed through endpoint management, DNS filtering with an approved domain list, an authenticated proxy, application control, cloud security groups, or a service mesh. It doesn’t matter which layer you pick. What matters is that at some point, the default outbound action is deny and only documented, approved destinations are permitted.
For organizations worried about breaking operations, there’s a safe path. Place a “log all” rule at the bottom of your firewall stack and let it run for a few days. That gives you a complete picture of every outbound connection your environment makes. Build your allow-list from that data, document the business justification for each entry, then convert the log rule to a hard deny.
What 3.13.6 Requires for Inbound Traffic
The rule is exactly the same:
Inbound traffic must also be denied by default and only allowed by explicit exception.
In practice, this means:
• Nothing from the internet or external networks should reach your environment unless it is specifically required and approved.
• Every exposed service must exist for a documented business reason.
• All other inbound traffic is blocked automatically.
If your firewall or gateway is configured as “allow all inbound unless blocked,” you do not meet the control.
Most organizations actually get inbound right without realizing it because perimeter firewalls usually start with deny-by-default inbound rules.
But assessors still verify it.
What inbound services from the internet are allowed into the CUI boundary?
The acceptable answer should sound like:
- VPN access on specific ports
- Approved external file transfer service
- Approved web application in a DMZ
- Nothing else
And everything else should be blocked automatically.
If someone scans your gateway and finds random open ports or services nobody can explain, that’s a problem.
What your assessor will ask for
Assessors may ask for these things:
Configuration evidence. The actual technical implementation, so firewall rules, security group settings, host firewall policies, with a default deny action for both inbound and outbound.
Your approved exception list. Every allow rule mapped to a destination, port or protocol, business purpose, and approval. This should live in your SSP or a controlled document tied directly to your firewall configuration.
Enforcement proof. Logs showing unapproved but non-malicious traffic was blocked. Not flagged. Not logged and allowed. Blocked.
Your change management process. How do new destinations get added to the allow-list? Who approves them? How often the list is reviewed, and the change management trail behind it.
Before your assessment, run three quick tests: try reaching an unauthorized port from inside the CUI boundary and confirm it’s blocked. Scan your gateway externally and confirm only authorized ports respond. Pull 24 hours of deny logs, find a legitimate service that got caught, and walk through how you added it to the allow-list via your formal process. If you can do all three, you have your evidence package for this practice.