DKDavid Koran& Associates
Home The CMMC Guide Part III · System and Communications Protection SC.L2-3.13.6
The CMMC Guide · System and Communications Protection Family

SC.L2-3.13.6  Deny by Default

Deny network communications traffic by default and allow network communications traffic by exception (i.e., deny all, permit by exception).

Family
System and Communications ProtectionSC, 16 requirements
Point Value
5Highest weight in the methodology
POA&M Eligible
NoCannot remain open at assessment
Objectives
TwoPer NIST SP 800-171A

1Overview

SC.L2-3.13.6 sets the default posture for network traffic. It requires that network communications traffic be denied by default and allowed by exception, the deny-all, permit-by-exception rule, so that only explicitly permitted traffic flows and everything else is blocked. It is a five-point requirement that cannot be deferred on a plan of action.

A network can default to allowing traffic unless something blocks it, or to blocking traffic unless something allows it. The first default lets any unanticipated or malicious flow through until noticed; the second blocks everything not explicitly permitted. This control requires the second: deny by default, allow by exception. Only traffic that has been deliberately permitted flows, which means new or unexpected traffic is blocked rather than allowed. Its five-point weight reflects that the default posture determines whether the network fails open or closed.

The requirement · NIST SP 800-171 Rev 2, 3.13.6

Deny network communications traffic by default and allow network communications traffic by exception (i.e., deny all, permit by exception).

The requirement has two matched parts the assessment objectives make explicit: traffic is denied by default, and traffic is allowed by exception. The default is denial, so anything not explicitly permitted is blocked; the exceptions are the deliberately allowed flows. Together they produce a network that permits only known, intended traffic. This is typically enforced through firewall and access control list rules whose baseline is deny.

2The Assessment Objectives

NIST SP 800-171A decomposes 3.13.6 into two objectives: deny by default and allow by exception.

[a]

Network communications traffic is denied by default. The baseline blocks all traffic.

MeetsTraffic is denied by default, so anything not permitted is blocked.
FailsTraffic is allowed by default, so anything not blocked passes.
[b]

Network communications traffic is allowed by exception. Only deliberately permitted traffic flows.

MeetsTraffic is allowed only by explicit exception to the default deny.
FailsTraffic is permitted broadly rather than by specific exception.

The two objectives are the deny default and the permit exceptions. The common failure is at objective [a], where the effective default is allow, with only specific things blocked, so unanticipated traffic passes. The assessor looks for a deny-by-default baseline with traffic allowed only by exception.

3Failure Patterns

The failures are about networks that default to allow.

Default-allow with blocklist

A network that permits traffic unless a rule blocks it lets any unanticipated flow through. Denying by default and permitting by exception inverts this to fail closed.

Overly broad exceptions

Exceptions written so broadly that they permit most traffic undo the deny default in practice. Exceptions have to be specific to the intended flows.

Deny default not enforced everywhere

A deny baseline on some boundaries but allow on others leaves the allow paths open. The default deny has to hold across the relevant boundaries.

The common root
This control fails on the difference between failing open and failing closed. A default-allow network passes anything no one thought to block, which favors the attacker who sends what no one anticipated. Denying by default makes the unanticipated the blocked case, so only known, intended traffic flows.

4Ownership

This is a network and IT-owned control.

RoleResponsibility for this control
Network and ITConfigures firewall and access control baselines to deny by default and allow by exception. Owns the rule configuration.
Security or compliance leadConfirms the default is deny and exceptions are specific.
Program leadReviews exceptions to keep them minimal and intended.
See also: This control works with the boundary protection of SC.L2-3.13.1 and the public-access separation of SC.L2-3.13.5.

5Tooling

The control is delivered by firewall and access control baselines set to deny.

ObjectivesToolingWhat it provides
[a]Default-deny firewall and ACL baselineAll traffic blocked unless permitted.
[b]Specific allow rulesOnly intended traffic permitted by exception.

The caveat is that the deny default has to be the real baseline and the exceptions specific. A ruleset that ends in allow, or exceptions broad enough to permit most traffic, does not meet the objectives. The assessor examines the default posture and the specificity of exceptions, so both objectives have to hold.

6Evidence

The satisfied version of 3.13.6 shows a deny-by-default baseline with specific exceptions.

EvidenceWhat it demonstrates
Firewall and ACL rulesetsObjective [a]. Traffic denied by default.
Allow rule setObjective [b]. Traffic allowed only by specific exception.

The evidence should show a default-deny baseline with traffic allowed only through specific exceptions. The firewall and access control rulesets are the clearest demonstration, and because this control cannot sit on a plan of action, the deny default has to be real at the time of assessment.

A network should fail closed, not open

A default-allow network passes anything no one thought to block, which favors the attacker, so this five-point control asks that traffic be denied by default and allowed only by exception. Setting that posture is part of the onsite readiness work this practice does, and it is one of the controls that must be met rather than deferred.

Start CMMC Readiness or call 802-335-2662

7Sources

  1. NIST Special Publication 800-171 Rev 2, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations, requirement 3.13.6. csrc.nist.gov
  2. NIST Special Publication 800-171A, Assessing Security Requirements for Controlled Unclassified Information, assessment objectives 3.13.6[a] and 3.13.6[b]. csrc.nist.gov
  3. 32 CFR 170.24, CMMC Scoring Methodology, listing SC.L2-3.13.6 among the five-point derived security requirements. ecfr.gov
← Previous in System and Communications Protection
SC.L2-3.13.5 · Public-Access Subnetworks
Next in System and Communications Protection →
SC.L2-3.13.7 · Prevent Split Tunneling
About the Author
David W. Koran is a CyberAB Registered Practitioner Advanced and the author of The CMMC Decision, now in its second edition. He works onsite with defense contractors and their counsel, from the first leadership briefing through the pre-assessment review. Reach him at 802-335-2662 or dkoran@davidkoran.com.
Entry SC.L2-3.13.6 · Edition 2026.1 · Last reviewed July 12, 2026