Network Communications - Deny by Default - Allow by Exception is the requirement that sets the default posture for network traffic. It is part of the System and Communications Protection (03.13) family, and it works hand in hand with Boundary Protection (03.13.01) to decide what traffic is permitted. Network Communications - Deny by Default - Allow by Exception (03.13.06) requires denying network communications traffic by default and allowing it only by exception. Per the NIST discussion, this applies to inbound and outbound traffic at the system boundary and at identified points within the system, and a deny-all, allow-by-exception policy ensures that only essential and approved connections are allowed.
A common difficulty with this requirement is running firewall or access control rule sets that permit broad traffic and only block specific bad things, which is the opposite of the required posture. The requirement is a default-deny stance: traffic is blocked unless a rule explicitly allows it. Teams also forget that the posture applies to outbound traffic and to internal choke points, not just inbound traffic at the perimeter.
Where things stand for companies facing the transition from NIST 800-171 R2 to R3:
The following is reproduced verbatim from NIST 800-171 R3, requirement 03.13.06 Network Communications - Deny by Default - Allow by Exception. Only the formatting has been adjusted for readability. This is a single statement with no lettered parts:
The source control is SC-07(05) from NIST 800-53. There are no Organization-Defined Parameters (ODPs). Per the NIST discussion, this requirement applies to inbound and outbound network communications traffic at the system boundary and at identified points within the system, and the deny-all, allow-by-exception policy ensures only essential and approved connections are allowed. You can read the requirement directly at NIST 800-171 R3, 03.13.06 (p. 59).
None (0). Requirement 03.13.06 contains no bracketed assignment, so there is no organization-defined value to select and nothing for the DoD to specify. The requirement applies as written.
Your System Security Plan (SSP) narrative for 03.13.06 therefore records how the requirement is implemented rather than a parameter you chose.
NIST 800-171A R3 breaks 03.13.06 into two (2) determination statements, and it has no Organization-Defined Parameters (ODPs). These AOs are:
The two (2) objectives are the two halves of the posture: default deny (01) and allow only by exception (02). The full guidance on assessment methods and objects, is in NIST 800-171A R3, 03.13.06 (p. 77).
Examine: system and communications protection policy and procedures; procedures for boundary protection; system design documentation; system configuration settings; system audit records; system security plan.
Interview: personnel with boundary protection responsibilities; personnel with information security responsibilities; system developers; system administrators.
Test: mechanisms for implementing traffic management at managed interfaces.
03.13.06 maps from NIST 800-171 R2 requirement 3.13.6 (deny network communications traffic by default and allow network communications traffic by exception, that is, deny all, permit by exception):
Mapped against the two (2) AOs, both (2) are direct (minimal effort), with no net-new AOs and none with no mapping. This is a clean carry-forward with matching wording. If you satisfied R2 3.13.6, confirm the default-deny posture still holds across current firewalls, cloud security groups, and any internal segmentation points added since your last assessment.
Source Control in NIST 800-53 R5:
Secure Controls Framework (SCF) Crosswalk
Organizations running a single control set across multiple frameworks can satisfy 03.13.06 through the following SCF controls:
The crosswalks from NIST 800-171 R3 and NIST 800-171A R3 to the SCF are available at no cost through the SCF Set Theory Relationship Mapping (STRM): https://securecontrolsframework.com/start-here/set-theory-relationship-mapping-strm. The STRM also carries the relationship type for each mapping (Equal, Subset Of, Intersects With), which tells you whether an SCF control fully satisfies the requirement or only part of it. Mapping above taken from SCF 2026.3.
The following are issues teams may encounter rather than certainties. They are about the direction of the rule logic and its coverage, each of which needs documented evidence of due diligence and due care such as policies, standards, procedures, and configuration screenshots:
Reasonable objective evidence for an assessment is often subjective. The following examples of evidence to address NIST 800-171 R3 03.13.06 are sourced from the SCF Evidence Request List (ERL), available at https://securecontrolsframework.com/free-content/scf-download. These ERL artifacts are mapped to NIST 800-171 R3 03.13.06 through SCF controls. They establish a starting point for discussions on what an organization needs to have for evidence of due diligence and due care to withstand external scrutiny by an assessor or regulator.
Alongside these, keep the System Security Plan (SSP) narrative for 03.13.06.
With both AOs mapping directly, 03.13.06 is a light lift once the rule bases are confirmed. A realistic sequence:
How many assessment objectives does NIST 800-171 R3 03.13.06 have? NIST 800-171A R3 breaks 03.13.06 into two (2) assessment objectives. An assessor works through each one separately, so each needs its own evidence.
Which NIST 800-53 R5 control does NIST 800-171 R3 03.13.06 come from? SC-07(05).
How many Organization-Defined Parameters (ODPs) does NIST 800-171 R3 03.13.06 have? None (0). The requirement contains no bracketed assignment, so there is no organization-defined value and nothing for the DoD to specify.
Where does NIST 800-171 R3 03.13.06 sit in the NIST 800-171 R3 Kill Chain? Phase 9, Change Management (CM). The Kill Chain is a phased model for sequencing R3 implementation, and it assigns this requirement to that phase.
03.13.06 Network Communications - Deny by Default - Allow by Exception denies network traffic by default and allows it only by explicit exception, at the boundary and at internal points, for both inbound and outbound traffic. It maps directly from R2 3.13.6 with matching wording, so there is no net-new work. The recurring problem is a permissive rule base that blocks only known-bad traffic. Set the default to deny in both directions, allow only essential and approved connections by exception, and document the exception list.
Authoritative sources:
Authoritative sources:
This guide reproduces U.S. Government text from NIST 800-171 R3 and NIST 800-171A R3. It is educational, not legal or assessment advice. Last reviewed: 2026-09-22.
