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
3.13.6OFFICIAL STATEMENT BELOWDERIVED REQUIREMENTPENDING NIST SME REVIEW

3.13.6 — Deny-by-default network traffic

3.13 System and Communications Protection · NIST SP 800-171 Rev. 2 · The heading label is this site's navigational shorthand; the official language is the statement below.

Official requirement statement (verbatim)

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

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

What this requirement is after

Network traffic is denied unless a rule explicitly allows it. Deny-all, permit-by-exception inverts the default most networks grow up with — and it forces the organization to learn what its traffic actually is, because every legitimate flow now needs a written reason.

Mapped practices

Brilliant at the Basics practices that support this requirement

Partial implementation supportModerate confidence

Why: Default-deny 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 exactly this requirement's posture, applied to the plant.

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 covers the whole system's network communications, including the IT estate the practice never touches, and deny-by-default on a live control network is reached incrementally: learn the real traffic in permit-and-log mode first, then tighten in planned windows with the process owner, because a missed permit rule can stop production or sever a safety-relevant flow.

Practice-side activities
  • Move the IT/OT boundary and inter-zone conduits to default-deny with a documented exception list
  • Learn legitimate traffic in permit-and-log mode before enforcing
  • Review every broad permit rule on a cadence, with expiry dates on exceptions
Evidence this produces
  • Boundary and conduit rule exports showing deny-by-default with justified exceptions
  • The dated exception list with owners and expiry dates
  • Change records for tightening steps, with process-owner sign-off

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

Review status: Technical review complete · Reviewed by External source-validation review, 2026-08-06 — directed remapping of OT segmentation from 3.13.5 to 3.13.1/3.13.6 · updated 2026-08-06

Partial implementation supportModerate confidence

Why: Deny-by-default is the traffic policy segmentation zones are meant to run on: the practice's enforcement points between zones are where a default-deny stance gets implemented, and drawing the zones forces the traffic analysis that makes permit-by-exception writable at all.

What this does not claim: May partially address the requirement — deny-by-default is a design decision the segmentation effort enables, not one it settles. Zone boundaries deployed with broad allow rules advance the practice while leaving this requirement untouched, and the requirement also reaches the external boundary and host-level filtering beyond the internal zone map.

Practice-side activities
  • Configure inter-zone enforcement points with a final deny rule
  • Document a specific need for every allow rule
  • Prune stale exceptions during periodic rule review
Evidence this produces
  • Rulebase exports showing default-deny posture at enforcement points
  • Exception register with per-rule justifications

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 at boundary enforcement points first, then work inward; a deny-by-default posture over a rulebase full of any-any exceptions is the old default wearing a new name.
  • Expect an archaeology phase: discovering what breaks under default-deny is how undocumented dependencies surface. Stage the cutover, run log-only first, and keep a rollback path.
What operating evidence looks likeRecords worth retaining, not a submission checklist
  • Rulebase exports showing a final deny rule and scoped exceptions
  • An exception register tying each allow rule to a documented need

Suggested owners, derived from the mapped practices and artifacts: OT / network administrator · 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 lands in Rev. 3

Provenance

Sources and review status

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