NIST 800-171 R3 03.13.01 Boundary Protection at a Glance
- Family: 03.13 System and Communications Protection (SC)
- Requirement ID: 03.13.01 Boundary Protection
- Assessment Objectives (AOs): Six (6) determination statements
- Organization-Defined Parameters (ODPs): None (0). This requirement contains no organization-defined values
- Source NIST 800-53 R5 Control: SC-07
- NIST 800-171 R3 Kill Chain Phase: Phase 9, Change Management (CM)
Boundary Protection is the first requirement in the System and Communications Protection (03.13) family, and it is the control that watches and manages the edges of your system. It is what keeps traffic crossing into and out of your environment monitored, controlled, and funneled through managed interfaces. Boundary Protection (03.13.01) has three (3) parts: monitor and control communications at external and key internal managed interfaces, implement subnetworks for publicly accessible components that are separated from internal networks, and connect to external systems only through managed interfaces built to your security architecture. Per the NIST discussion, managed interfaces include gateways, routers, firewalls, network-based malicious code analysis, virtualization systems, and encrypted tunnels, and subnetworks physically or logically separated from internal networks are referred to as demilitarized zones (DMZs).
A common difficulty with this requirement is monitoring the outer edge of the network while ignoring the key internal boundaries, or standing up publicly accessible services without a demilitarized zone that separates them from the internal network. R3 also expects external connections to run only through managed interfaces arranged in line with your security architecture, which means the boundary design must be deliberate rather than incidental.
Where things stand for companies facing the transition from NIST 800-171 R2 to R3:
- The National Institute of Standards and Technology (NIST) withdrew R2 on May 14, 2024, the same day R3 was published. The withdrawal notice states that R2 "has been withdrawn (archived), and is provided solely for historical purposes," so it will never receive another correction or clarification from NIST.
- R2 remains the contractual standard for the Department of Defense (DoD) and the Defense Industrial Base (DIB). Cybersecurity Maturity Model Certification (CMMC) assessments reference it directly: per Title 32 of the Code of Federal Regulations (CFR), section 170.14(c)(3), "the security requirements in CMMC Level 2 are identical to the requirements in NIST SP 800-171 R2."
- The rulemaking points the other direction. The proposed Controlled Unclassified Information (CUI) rule for the Federal Acquisition Regulation (FAR), published June 23, 2026 as part of the Revolutionary FAR Overhaul, would apply CUI safeguarding requirements government wide rather than only to DoD contracts, and it sets the baseline at R3. That rule is not final, and DoD has separately signaled an interim rule to move CMMC to R3.
What Does NIST 800-171 R3 03.13.01 Actually Require?
The following is reproduced verbatim from NIST 800-171 R3, requirement 03.13.01 Boundary Protection. Only the formatting has been adjusted for readability. This requirement has three (3) lettered parts:
- a. Monitor and control communications at external managed interfaces to the system and key internal managed interfaces within the system.
- b. Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks.
- c. Connect to external systems only through managed interfaces that consist of boundary protection devices arranged in accordance with an organizational security architecture.
The source control is SC-07 from NIST 800-53. There are no Organization-Defined Parameters (ODPs). Per the NIST discussion, restricting or prohibiting interfaces within organizational systems includes restricting external web traffic to designated web servers within managed interfaces, prohibiting external traffic that appears to be spoofing internal addresses, and prohibiting internal traffic that appears to be spoofing external addresses. You can read the requirement directly at NIST 800-171 R3, 03.13.01 (p. 58).
What Are the Organization-Defined Parameters (ODPs) Associated with NIST 800-171 R3 03.13.01?
None (0). Requirement 03.13.01 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.01 therefore records how the requirement is implemented rather than a parameter you chose.
What Are the Assessment Objectives (AOs) For NIST 800-171 R3 03.13.01?
NIST 800-171A R3 breaks 03.13.01 into six (6) determination statements, and it has no Organization-Defined Parameters (ODPs). These AOs are:
- A.03.13.01.a[01]: communications at external managed interfaces to the system are monitored.
- A.03.13.01.a[02]: communications at external managed interfaces to the system are controlled.
- A.03.13.01.a[03]: communications at key internal managed interfaces within the system are monitored.
- A.03.13.01.a[04]: communications at key internal managed interfaces within the system are controlled.
- A.03.13.01.b: subnetworks are implemented for publicly accessible system components that are physically or logically separated from internal networks.
- A.03.13.01.c: external system connections are only made through managed interfaces that consist of boundary protection devices arranged in accordance with an organizational security architecture.
The objectives split monitoring and controlling into external and internal interfaces (a[01] through a[04]), require a separated subnetwork for public components (b), and require external connections to run through architecture-aligned managed interfaces (c). The full guidance on assessment methods and objects, is in NIST 800-171A R3, 03.13.01 (p. 75).
Assessment Methods and Objects for NIST 800-171 R3 03.13.01
Examine: system and communications protection policy and procedures; procedures for boundary protection; list of key internal boundaries within the system; boundary protection hardware and software; system configuration settings; security architecture; system audit records; system design documentation; system security plan.
Interview: personnel with boundary protection responsibilities; personnel with information security responsibilities; system developers; system administrators.
Test: mechanisms for implementing boundary protection capabilities.
How Does NIST 800-171 R3 03.13.01 Map From NIST 800-171 R2?
03.13.01 maps from NIST 800-171 R2 requirement 3.13.1 (monitor, control, and protect communications at the external boundaries and key internal boundaries of organizational systems), and it absorbs R2 requirement 3.13.5 (implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks), which R3 withdrew and incorporated here:
- A.03.13.01.a[01] through A.03.13.01.a[04] map directly to elements of R2 3.13.1 (monitoring and controlling communications at external and internal boundaries).
- A.03.13.01.b maps indirectly to elements of R2 3.13.5 (subnetworks for publicly accessible components separated from internal networks).
- A.03.13.01.c has no clear mapping to any R2 assessment objective.
Mapped against the six (6) AOs, four (4) are direct (minimal effort), one (1) is indirect (moderate effort), and one (1) has no clear mapping (significant effort). The monitoring and control of external and internal boundaries carries forward cleanly, the public-access separation now lives here rather than in its own requirement, and the requirement to arrange boundary protection devices in accordance with a security architecture (c) is the new work. Confirm your architecture documentation supports the c objective rather than assuming your firewalls satisfy it on their own.
How Does NIST 800-171 R3 03.13.01 Map to NIST 800-53 R5 and the SCF?
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.01 through the following SCF controls:
- MON-22 Inbound & Outbound Communications Traffic
- MON-23 Network Intrusion Detection & Prevention Systems (NIDS & NIPS) Monitoring
- MON-25 De-Militarized Zone (DMZ) Monitoring
- NET-02 Network Security Controls (NSC)
- NET-03 Boundary Protection
- NET-04 Data Flow Enforcement - Access Control Lists (ACLs)
- NET-04.1 Deny Traffic by Default & Allow Traffic by Exception
- NET-06 Network Segmentation (macrosegmentation)
- NET-08.1 Sensitive / Regulated Data Enclave (Secure Zone)
- NET-31 Network Intrusion Detection / Prevention Systems (NIDS / NIPS)
- NET-41.1 Separate Subnet for Connecting to Different Security Domains
- SEA-04 Alignment With Enterprise Architecture
- SEA-05 Secure Engineering Principles
- SEA-06 Defense-In-Depth (DiD) Architecture
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.
Common Pitfalls with NIST 800-171 R3 03.13.01
The following are issues teams may encounter rather than certainties. They are about internal boundaries and the security architecture, each of which needs documented evidence of due diligence and due care such as policies, standards, procedures, and configuration screenshots:
- Watch the internal boundaries too. A.03.13.01.a[03] and a[04] require monitoring and controlling key internal managed interfaces, not just the perimeter, so a flat internal network with no key internal boundaries leaves objectives open.
- Public components need a demilitarized zone. A.03.13.01.b requires publicly accessible components to sit in a subnetwork separated from internal networks, so hosting a public web server on the internal network is a gap.
- The architecture is assessable. A.03.13.01.c requires external connections through managed interfaces arranged per an organizational security architecture, so document the architecture the boundary devices implement.
- Tie it to deny-by-default. Network Communications - Deny by Default - Allow by Exception (03.13.06) sets the traffic policy those managed interfaces enforce, so keep the two aligned.
What Is Reasonable Evidence For NIST 800-171 R3 03.13.01?
Reasonable objective evidence for an assessment is often subjective. The following examples of evidence to address NIST 800-171 R3 03.13.01 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.01 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.
- E-DCH-04 Network Diagram - Low Level. A low-level network diagram that provides a detailed, logical depiction of assets on the network(s).
- E-NET-04 Network Security Controls (NSC). The organization's network security controls (e.g., boundary protections, content filtering, wireless infrastructure, etc.).
- E-NET-07 External System Accessibility. A list of technology assets, applications and/or services (taas) accessible from third-party entities.
- E-NET-08 Internal Boundaries. Key internal boundaries.
- E-NET-09 Network Access Control Points. Network access control points.
- E-NET-10 Information Flow Control. Information flow control mechanisms (e.g., access control lists, etc.).
- E-NET-11 Intrusion Detection / Prevention Deployment. Network and host intrusion detection / prevention systems (nids / nips, hids / hips) deployment and monitoring coverage.
- E-NET-13 Demilitarized Zone (DMZ) & Web Application Firewall (WAF) Configuration. Dmz architecture and web application firewall (waf) configuration for externally facing services.
- E-SEA-02 Security Architecture. Security architecture-related documentation.
- E-TDA-02 Secure Engineering & Data Privacy (SEDP). A secure engineering & data privacy (sedp) program. this is program-level documentation in the form of a runbook, playbook or a similar format provides guidance on organizational practices that support existing policies and standards.
- E-TDA-08 Secure Engineering Principles (SEP). Defined secure engineering principles used to ensure sensitivity, integrity, availability & safety (cias) concerns are properly addressed in the design and implementation of technology assets, applications and/or services (taas).
- E-TDA-09 Security Architecture View. Documented evidence that identifies security-relevant system elements and their interfaces: • define security context, domains, boundaries, and external interfaces of the system; • align the architecture with (a) the system security objectives and requirements, (b) security design characteristics; and • establish traceability of architecture elements to user and system security requirements.
Alongside these, keep the System Security Plan (SSP) narrative for 03.13.01.
Timeline Considerations for NIST 800-171 R3 03.13.01
With four (4) AOs mapping directly, one indirectly, and one with no clear mapping, 03.13.01 is a moderate lift centered on internal boundaries and architecture documentation. A realistic sequence:
- Confirm monitoring and control at external managed interfaces (A.03.13.01.a[01] and a[02]).
- Identify key internal boundaries and extend monitoring and control to them (A.03.13.01.a[03] and a[04]).
- Place publicly accessible components in a separated subnetwork, or demilitarized zone (A.03.13.01.b).
- Document the security architecture and confirm external connections run through architecture-aligned managed interfaces (A.03.13.01.c).
- Collect evidence for all six (6) AOs, including boundary device configurations, the network diagram, and the security architecture.
Frequently Asked Questions About NIST 800-171 R3 03.13.01
How many assessment objectives does NIST 800-171 R3 03.13.01 have? NIST 800-171A R3 breaks 03.13.01 into six (6) 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.01 come from? SC-07.
How many Organization-Defined Parameters (ODPs) does NIST 800-171 R3 03.13.01 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.01 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.
Bottom Line on NIST 800-171 R3 03.13.01
03.13.01 Boundary Protection monitors and controls communications at external and key internal managed interfaces, separates publicly accessible components into a demilitarized zone, and connects to external systems only through architecture-aligned managed interfaces. It maps from R2 3.13.1 and absorbs R2 3.13.5, with four (4) objectives transitioning directly, one indirectly, and one that is new. The recurring problem is watching only the perimeter and skipping the internal boundaries or the documented architecture. Monitor and control both edges, put public services in a demilitarized zone, and document the architecture your boundary devices implement.
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.
