Independent DIB implementation resource — not affiliated with or endorsed by the U.S. Department of WarView the official DoW campaign ↗
Brilliant at the BasicsDIB Resource Center
03.13.06OFFICIAL TITLEPENDING NIST SME REVIEW

03.13.06 — Network Communications — Deny by Default, Allow by Exception

03.13 System and Communications Protection · NIST SP 800-171 Rev. 3

Independent summary of the official requirement

Requires denying network communications traffic by default and allowing network communications traffic by exception.

Rev. 3 requirement text is multi-part and parameterized with organization-defined values, so this site summarizes rather than reproduces it. The summary is independent — read the official publication for the binding wording.

NIST SP 800-171 Rev. 3 — Protecting CUI in Nonfederal Systems ↗NIST SP 800-171A Rev. 3 — Assessing Security Requirements for CUI ↗
Independent interpretation

What this requirement is after

The last rule is deny, and everything above it is an exception someone can explain. Deny-by-default inverts the burden of proof: instead of naming what is forbidden, the network permits only what is affirmatively needed — the only posture that fails safe when nobody remembered to update a rule.

Mapped practices

Brilliant at the Basics practices that support this requirement

Partial implementation supportHigh confidence

Why: The practice's deployed state is inter-zone default-deny: traffic between zones is refused unless a reviewed rule permits it, which is precisely the deny-all, permit-by-exception posture this requirement names.

What this does not claim: The requirement applies to network communications traffic generally — including the external perimeter and egress — while the practice enforces the posture between internal zones. Hosts within a single zone still communicate freely unless host-level policy extends the model, and every permit rule needs a recorded justification for the by-exception framing to survive an assessor's sampling.

Practice-side activities
  • Convert discovered traffic into explicit allow rules with owners, then flip the inter-zone default to deny
  • Review the rulebase on a cadence and expire broad allows
Evidence this produces
  • Rule exports showing default-deny between zones
  • Rule review records with per-exception justifications

Review status: Pending NIST SME review · Reviewed by Brilliant at the Basics editorial — practitioner-authored; NIST SME review pending · updated 2026-08-06

Partial implementation supportModerate confidence

Why: Deny-by-default with permit-by-exception is the traffic policy strict OT segmentation enforces at the IT/OT boundary and between zones — the practice's mature state is this requirement's posture, applied to the plant. Mirrors the corrected Rev. 2 relationship (3.13.6).

What this does not claim: May partially address the requirement, and only for OT components within the assessed CUI boundary — organizational scoping determines applicability. The requirement spans the whole system's network communications including the IT estate, and deny-by-default on a live control network is reached incrementally through permit-and-log observation and planned windows, because a missed permit rule can stop production or sever a safety-relevant flow.

Practice-side activities
  • Move boundary and conduit rules to default-deny with a documented, dated exception list
  • Learn legitimate plant traffic in permit-and-log mode before enforcing
  • Tighten in planned maintenance windows with process-owner sign-off and rollback
Evidence this produces
  • Rule exports showing deny-by-default with justified exceptions
  • The exception list with owners and expiry dates
  • Staged-enforcement change records with safety review

Where this holds: Holds for OT zones and conduits inside the assessed boundary; the requirement's enterprise scope needs separate treatment.

Review status: Pending NIST SME review · Reviewed by Brilliant at the Basics editorial — practitioner-authored; NIST SME review pending · updated 2026-08-06

Doing the work

Implementation considerations and evidence

Implementation considerationsIndependent guidance — tailor to your environment
  • Apply the posture at every enforcement point that carries CUI traffic — perimeter, inter-zone boundaries, host firewalls, cloud security groups — not just the internet edge.
  • Discover before enforcing: log in permit mode to find the real traffic, convert it to explicit allows with owners, then flip the default.
  • Treat every broad allow (any-any, wide port ranges) as a dated exception with an owner and an expiry, and review the rulebase on a cadence.
What operating evidence looks likeRecords worth retaining, not a submission checklist
  • Rule exports showing an explicit default-deny at each enforcement point
  • Rule review records with a justification per exception

Suggested owners, derived from the mapped practices and artifacts: Network administrator · OT / network administrator · Network admin. Ownership is a named person in your organization, not a role on a website.

Artifacts

Templates and worksheets with a mapped relationship

PLAN · REVIEW SEMIANNUALNetwork Segmentation Plan Worksheet
The other revision

Where this came from in Rev. 2

Provenance

Sources and review status

Primary sourcesNIST SP 800-171 Rev. 3 — Protecting CUI in Nonfederal Systems · NIST SP 800-171A Rev. 3 — Assessing Security Requirements for CUI
Review statusPending NIST SME review
Content version1.0
Updated