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.01OFFICIAL TITLEPENDING NIST SME REVIEW

03.13.01 — Boundary Protection

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

Independent summary of the official requirement

Requires monitoring and controlling communications at the system's external managed interfaces and at key internal managed interfaces, implementing subnetworks that physically or logically separate publicly accessible components from internal networks, and connecting to external systems only through managed interfaces consisting of boundary protection devices arranged in accordance with an organizational security architecture.

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 network needs deliberate edges: a guarded external boundary, guarded seams between the internal zones that matter, public-facing components kept in their own subnetwork, and every path to an external system passing through an interface you manage. Traffic that crosses an edge gets watched and constrained; a path you cannot watch should not exist.

Across revisions

Rev. 3 consolidates four Rev. 2 requirements into this one: boundary protection (3.13.1) absorbs the separation of user and system-management functionality (3.13.3), public-access subnetworks (3.13.5), and split-tunneling prevention (3.13.7). Their substance survives as facets of the single boundary requirement rather than as standalone items.

Mapped practices

Brilliant at the Basics practices that support this requirement

Direct implementation supportHigh confidence

Why: Zone design with default-deny boundaries, reviewed inter-zone rules, and a separated management plane is monitored-and-constrained communication at key internal boundaries — the core of this requirement — and Rev. 3's consolidated scope (public-access subnetworks, separation of management functionality) matches the practice's zone model closely.

What this does not claim: Supports implementation of the requirement; it does not satisfy it on its own. The requirement also governs the external boundary — managed interfaces to the internet and to external systems arranged per an organizational security architecture — which internal segmentation work touches only partly, and its monitoring half means watching what crosses the boundaries, not merely permitting or denying it. Split-tunneling prevention, now folded into this requirement, is remote-access configuration the zone model does not reach.

Practice-side activities
  • Design and enforce zones with default-deny boundaries between them
  • Place publicly accessible components in a separated subnetwork
  • Separate the management plane from user-facing networks
  • Log and review inter-zone traffic rather than assuming the rules hold
Evidence this produces
  • The zone design with boundaries and permitted flows
  • Firewall and ACL exports showing inter-zone default-deny
  • Inter-zone traffic logs and periodic segmentation test results

Where this holds: Holds for the internal-boundary portion of the requirement wherever the zone model is enforced; the external boundary and remote-access facets need their own treatment.

Review status: Technical review complete · Reviewed by inDirectIT practitioner review — CUI security and NIST SP 800-171 engineering · updated 2026-08-06

Partial implementation supportModerate confidence

Why: The IT/OT boundary the practice enforces is exactly a key internal boundary in this requirement's terms: zones and conduits between business and production networks, brokered crossings, and a DMZ for the data that must flow up — boundary protection applied where compromise costs physical downtime.

What this does not claim: May partially address the requirement within the OT enclave; the enterprise external boundary and the rest of the internal architecture sit outside the practice. Tightening OT boundary enforcement can interrupt safety-relevant or production-critical traffic, so changes are staged behind observation and safety review — which means the boundary's effectiveness must be demonstrated with monitoring and test evidence rather than inferred from the plant still running.

Practice-side activities
  • Define zones and conduits between business and production networks
  • Broker all IT-to-OT crossings through a DMZ with no direct paths
  • Stage enforcement changes behind traffic observation and safety review
Evidence this produces
  • The zone-and-conduit design for the OT environment
  • DMZ and firewall configurations at the IT/OT boundary
  • Boundary traffic monitoring records and staged-change reviews

Where this holds: Holds at the IT/OT seam and within the production enclave; it says nothing about the enterprise network's other boundaries.

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
  • Choose the key internal boundaries deliberately — where CUI systems border the general network, where the management plane touches user space, where OT joins IT — and put enforcement and visibility there, not only at the internet edge.
  • Keep publicly accessible components (web servers, transfer points) in a separated subnetwork with no direct path inward.
  • Route every external connection through a managed interface you can enumerate; the unmanaged path — a direct SaaS tunnel, a vendor modem, a split tunnel — is the classic finding.
  • Monitor what crosses the boundaries, not only what is blocked; permitting and denying without observation is half the requirement.
What operating evidence looks likeRecords worth retaining, not a submission checklist
  • A network architecture diagram showing external and key internal boundaries and their enforcement points
  • Boundary device configurations with dated rule reviews
  • Monitoring records for traffic crossing the boundaries

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

Artifacts

Templates and worksheets with a mapped relationship

WORKSHEET · REVIEW SEMIANNUALSystem Boundary Definition WorksheetPLAN · 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