CMMC Level 2 Practice 3.13.6: Deny network communications traffic by default and allow network communications traffic by

CMMC Level 2 Practice 3.13.6 requires you to run your environment on a “default deny” network posture: block network traffic unless a documented, approved rule explicitly allows it. To operationalize it quickly, standardize firewall/ACL baselines, tightly control exceptions, and retain repeatable evidence that rules are reviewed, justified, and enforced across the CUI environment. ¹

Key takeaways:

• Default deny must be real, not a policy statement; your configurations must show implicit/explicit deny plus scoped allow rules. ²
• Assessors will test rule intent, rule scope, and rule governance (approvals, reviews, and exception handling) across boundary and internal enforcement points. ³
• Evidence wins: keep configs, change records, diagrams, and periodic review output mapped to 3.13.6 in a way you can reproduce on demand. ²

For a Compliance Officer, CCO, or GRC lead, the fastest way to “get 3.13.6 right” is to treat it as an engineering-and-governance control with a simple test: if a new subnet, host, service, or third-party connection appears tomorrow, does traffic stay blocked until someone authorizes and documents the minimum access required? That is the operational meaning of “deny by default.”

CMMC Level 2 aligns to NIST SP 800-171 Rev. 2 practices for protecting Controlled Unclassified Information (CUI) in nonfederal systems. Practice 3.13.6 sits in the System and Communications Protection family and drives a predictable network security posture: explicit allow rules, tight scoping, documented rationale, and controlled change. ⁴

This page translates the requirement into implementation steps you can hand to network/security teams, plus the evidence package you need for a CMMC assessment. The goal is execution: define your enforcement points, set default deny, govern exceptions, and prove ongoing operation without heroics.

Regulatory text

Requirement (as provided): “CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.13.6 (Deny network communications traffic by default and allow network communications traffic by).” ¹

Operator interpretation of what you must do:

• Configure network controls so that traffic is blocked unless explicitly permitted.
• Implement a consistent method to define, approve, and maintain allow rules (for example: ports, protocols, source/destination, direction, and purpose).
• Apply the posture across the CUI environment boundary and internal segmentation points, not just at the internet edge, where applicable to your architecture and risk. ²

Plain-English interpretation (what 3.13.6 means in practice)

“Deny by default” means you do not rely on “we don’t think anything is open” or ad hoc rules that grew over time. You start from blocked, then you deliberately open only what a business process needs, for a defined system-to-system path, and you can explain why each opening exists.

A clean way to say it to IT: Every inbound/outbound/east-west flow that touches CUI systems must have an owner, a ticket, and a rule with a narrow scope. If you cannot name the owner and purpose, it should not be allowed.

Who it applies to

Entities: Defense contractors and other federal contractors that handle CUI and are pursuing/required to meet CMMC Level 2. ⁵

Operational context (where this control lives):

• Network perimeters (internet edges, WAN, VPN, cloud security groups)
• Internal segmentation (between user networks and CUI enclaves; between tiers such as app and database)
• Remote access pathways (VPN concentrators, ZTNA brokers, bastions)
• Third-party connectivity (managed service providers, hosted platforms, B2B integrations)
  All of these are in scope when they enable network communications to or within the CUI environment. ²

What you actually need to do (step-by-step)

Use the steps below as an execution checklist. The output is a working “default deny + governed allow” posture and an evidence set you can reproduce.

1) Define the control boundary for CUI network flows

• Identify the CUI environment (systems, subnets, cloud accounts/projects, enclaves).
• List entry/exit points for that environment (firewalls, gateways, security groups, routers with ACLs).
• Document “in-scope” traffic types: inbound, outbound, and internal (east-west) flows that touch CUI systems. ²

Deliverable: Network boundary statement + current-state diagram (even if imperfect).

2) Inventory enforcement points and confirm capability

For each enforcement point (on-prem firewall, cloud security group, host firewall, NAC, microsegmentation tool), capture:

• Where rules are managed (console, IaC repo, MSP portal)
• Whether there is an implicit deny at the end of policy, or you must add an explicit “deny any any”
• Logging capabilities for allowed/denied traffic
  Your goal is to prove that “default deny” is implemented, not assumed. ²

Deliverable: Enforcement-point inventory with owners.

3) Establish the baseline: “deny all” then create a minimum allowlist

• Set baseline policy to block inbound to CUI networks by default.
• Set baseline policy to block inbound management interfaces by default; allow only from approved admin networks/bastions.
• For outbound, avoid “allow any” from CUI systems. Define allowed destinations by category (update servers, identity services, time services) and document exceptions where technical constraints exist.
  Keep rules narrowly scoped: source, destination, port/protocol, and direction. ²

Practical example (good allow rule):

• Source: App subnet
• Destination: DB subnet
• Protocol/port: TCP 1433
• Direction: App → DB only
• Rationale: Application database connectivity
• Owner: System owner + approver

4) Build an exception process that does not collapse into “allow all”

Create a lightweight workflow (ticket-based is fine) that requires:

• Business purpose and system owner
• Data sensitivity confirmation (does it touch CUI?)
• Exact flow definition (src/dst/port/protocol)
• Risk review for broad rules (any-to-any, 0.0.0.0/0, “all ports”)
• Approval and implementation record
  This is where many programs fail: the network team can configure default deny, but exceptions accumulate without governance. ⁶

5) Add recurring review and recertification of allow rules

Operationalize a cadence that fits your environment:

• Review rules tied to CUI boundaries and segmentation points.
• Remove stale rules (systems decommissioned, projects ended).
• Tighten overly broad scopes.
  The requirement is not “set once.” Assessors look for ongoing operation and evidence that rules stay current. ⁴

6) Ensure changes are controlled and traceable

• Require rule changes to go through change management (ticket + approval + implementation + validation).
• Keep before/after snapshots or config diffs.
• Validate that “deny by default” persists after changes (no emergency “temporary allow any” left behind). ²

7) Map to assessment-ready evidence (make it easy to prove)

Do not wait for the assessment to assemble proof. Build an evidence folder that includes:

• A short narrative of how default deny is implemented in your architecture.
• A pointer to configs and logs.
• A sample of rule reviews and exception approvals. ³

Daydream can help here by mapping 3.13.6 directly to your documented control operation and setting recurring evidence capture so you are not rebuilding artifacts under deadline pressure. ⁶

Required evidence and artifacts to retain

Keep evidence that proves: (1) default deny exists, (2) allow rules are intentional, (3) the control operates over time.

Core artifacts (recommended):

• Network architecture diagram(s) showing CUI boundary and enforcement points
• Firewall/ACL/security group policy exports showing default deny and specific allow rules
• Standards/baselines: “CUI network policy baseline” and “rule naming conventions”
• Rule change records: tickets, approvals, implementation notes, validation results
• Exception register: business justification, compensating controls if any, expiration/recertification
• Rule review output: annotated rule list showing keep/remove/tighten decisions
• Logging/monitoring evidence for blocked/denied traffic at key boundaries (as available) ²

Common exam/audit questions and hangups

Assessors and internal auditors tend to probe these areas:

1. “Show me default deny.”
   They will ask for a policy export or live view showing implicit/explicit deny and what is allowed above it. ²

2. “What about cloud?”
   They will expect default-deny principles to apply to cloud security groups/NACLs, not only on-prem firewalls, if CUI workloads exist in cloud. ²

3. “Do you control east-west traffic?”
   If you claim segmentation, they will ask you to demonstrate it with rules and diagrams. If you do not segment, be prepared to justify how default deny is implemented at the relevant boundary points. ²

4. “How do you prevent exceptions from becoming permanent?”
   They look for a review mechanism, not just a ticket trail. ³

Frequent implementation mistakes and how to avoid them

Mistake 1: Declaring “default deny” in policy while running broad allows in practice.
Fix: Require rule scope fields (src/dst/port/protocol) and flag “any” patterns for security approval.

Mistake 2: Treating the internet firewall as the only control point.
Fix: Document the CUI boundary and enforce deny-by-default at each ingress/egress path (including VPN, cloud, and third-party connections). ²

Mistake 3: No owner for rules.
Fix: Add a mandatory “rule owner” field and a recertification step in the rule review.

Mistake 4: No evidence package.
Fix: Store exports, screenshots, tickets, and review outputs in a single, indexed location mapped to 3.13.6. Daydream is a practical way to keep that mapping and recurring capture organized so evidence does not sprawl across tools. ³

Enforcement context and risk implications

The source catalog provided here does not include public enforcement cases specific to 3.13.6, so the right way to frame risk is assessment and contractual impact rather than citing penalty figures. CMMC is implemented through DoD program requirements and rulemaking, and your ability to demonstrate NIST SP 800-171 Rev. 2-aligned practices is central to meeting CMMC Level 2 expectations. ⁷

Operationally, weak network allowlisting increases the chance that an attacker can move laterally into CUI systems or exfiltrate data through unneeded outbound paths. Your best defense is a provable default-deny posture with disciplined exception handling and periodic rule hygiene. ²

A practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Confirm the CUI boundary and inventory enforcement points.
• Export current rulesets for perimeter, VPN/remote access, cloud security groups, and key internal segments.
• Write the minimum baseline standard: default deny expectation, required fields for allow rules, and exception workflow. ²

By 60 days (implement and govern)

• Remediate obvious “allow any” paths into CUI networks.
• Implement ticketed approvals for rule creation/changes tied to CUI flows.
• Create the exception register and begin capturing decision evidence. ³

By 90 days (prove operation and readiness)

• Complete a first rule review cycle for CUI boundary controls and document actions taken.
• Validate logging and retain samples showing denied traffic events at key points (where logging exists).
• Package your evidence set so you can answer assessor requests quickly: narrative, diagrams, rule exports, tickets, reviews. ⁶

Frequently Asked Questions

Does “deny by default” mean I must block all outbound internet access from CUI systems?

The requirement is default deny for network communications and explicit allow for what is required. Many teams restrict outbound from CUI systems to known services and destinations; document what you allow and why, and treat broad outbound as an exception with approvals. ²

Are cloud security groups and NACLs in scope for 3.13.6?

Yes, if they control network communications to or within the CUI environment. You should be able to show default-deny posture and explicit allow rules in the cloud control plane, with governance evidence. ²

What will an assessor ask me to “show” for this practice?

Expect to demonstrate rule configurations (exports or live views), how you approve and document allow rules, and proof of periodic review/recertification. A short, consistent evidence package mapped to 3.13.6 reduces back-and-forth. ⁶

If we use an MSP or third party to manage firewalls, can we still pass?

Yes, but you still own compliance. Make sure the third party follows your baseline, uses your approval workflow, and provides rule exports, change records, and review artifacts you can retain for assessment. ²

Do host-based firewalls count toward meeting 3.13.6?

They can support the control, especially for internal segmentation and restricting inbound management. Assessors typically expect you to address network communications at relevant enforcement points, so document how host controls complement network controls in your architecture. ²

How do we keep evidence current without turning this into a quarterly fire drill?

Standardize the artifacts (rule export format, exception register fields, review checklist) and schedule recurring captures tied to your change process. Tools like Daydream can track the requirement-to-evidence mapping and prompt recurring collection so your package stays assessment-ready. ³

Footnotes

1. NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance; 32 CFR Part 170

2. NIST SP 800-171 Rev. 2

3. DoD CMMC Program Guidance

4. NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance

5. 32 CFR Part 170; DoD CMMC Program Guidance

6. DoD CMMC Program Guidance; NIST SP 800-171 Rev. 2

7. 32 CFR Part 170; DoD CMMC Program Guidance; NIST SP 800-171 Rev. 2