03.13.01 Boundary protection: requirements and evidence

What 03.13.01 boundary protection asks for and why assessors check it hard

If a contract requires NIST SP 800-171, your network boundary has to show that CUI traffic is monitored and controlled at every point where it can enter or leave your environment. 03.13.01 asks for three things in plain terms. First, communications must be monitored and controlled at the system's external managed interfaces and at the key internal managed interfaces, meaning the points where one trust zone meets another. Second, publicly accessible components such as a web portal or a mail relay must sit in physically or logically separated subnetworks, so that a compromise of a public-facing host does not give direct reach into the systems that hold CUI. Third, connections to external systems must pass only through managed boundary protection devices, and those devices must be arranged under a documented organizational security architecture. The requirement does not name products. It expects you to show how the pieces fit together and who decided that they should.

Rev. 3 folded Rev. 2's 3.13.5 (public-facing subnetworks) into this requirement, so an assessor who knew the older numbering will now find the subnetwork expectation under 03.13.01. NIST classifies the change from 3.13.1 as significant, meaning the Rev. 3 wording asks for more detail and more foundational tasks, not just a renumbering. The source control NIST maps to this requirement is SC-7 in SP 800-53 Rev. 5, which is a useful starting point for your own control narrative, but it is a map and not a checklist: an assessor will test your environment against the SP 800-171A determination statements. Confirm the exact mapping and wording against the NIST pages before you cite them in a system security plan.

Assessors check this requirement hard for two reasons that show up repeatedly. The first is undocumented internal boundaries. Most organizations can draw the internet edge, but few have a current list of the internal boundaries that separate enclaves, management networks, development segments and cloud VPCs. SP 800-171A Rev. 3 expects an examiner to see a list of key internal boundaries, so the list must exist, match the running configuration and be reviewed when the network changes. The second is unclear ownership of the architecture. When the firewall team, the cloud team and the application team each believe another group owns a rule, the security architecture exists only in people's heads. Assign one accountable owner for the architecture, record the boundary devices and their rule sets, and make sure interviews with those owners give the same answer as the documents.

Which boundaries, systems and third parties are in scope for boundary protection

Boundary protection under 03.13.01 applies wherever CUI crosses a managed interface, so the first job is listing those interfaces. The scope is set by your organization and confirmed with the contracting agency, and the choices below determine how much of the environment must be monitored, filtered and documented.

External interfaces to the internet

Every connection between your systems and external networks is an external managed interface, including internet egress, partner links and vendor connections. Inventory each one, name the boundary device that controls it, and confirm that traffic leaves or enters only through that device. Unmanaged paths such as a spare firewall rule, a direct line from a laptop or an unlisted VPN tunnel are the gaps assessors look for first.

Key internal boundaries and enclave edges

A key internal boundary is a point where traffic moves between segments that hold CUI and segments that do not, such as an engineering network reaching an enclave. The assessment method expects you to maintain a written list of these boundaries. Decide early which internal edges are key, because each one needs monitoring and controlled traffic, and omitting one leaves a documented gap.

Publicly accessible components

Web servers, mail gateways, remote access gateways and any service reachable from the internet belong in their own subnetwork, separated from systems that store or process CUI. Check that these components cannot reach CUI hosts directly and that they pass traffic through the boundary devices. A public component placed on the same segment as a CUI database is a common finding, and moving it changes the boundary diagram and the system security plan.

Isolated CUI enclave or shared network

If CUI lives in a dedicated enclave with its own segmentation, the boundary work concentrates on that perimeter and its edges. If CUI shares a network with general business systems, nearly every interface becomes in scope and the monitoring footprint grows. Document the choice, the reasons for it and the people who approved it, because the scope decision shapes the cost and effort of everything else in this requirement.

Cloud VPCs and SaaS connections

Cloud accounts, virtual private clouds and SaaS integrations that store, process or transmit CUI are part of the boundary. Confirm which provider controls sit at the edge, which boundary functions you own, and how the connection to the enclave is routed. Hosted or cloud providers also raise separate questions under the supply chain and external service requirements, so ask the agency how it expects shared responsibility to be documented.

Third-party and remote connections

Managed service providers, maintenance vendors and remote administrators often hold tunnels or accounts into the environment. Each such connection is an interface that must be listed, monitored and limited to permitted traffic. Ask each third party for its access path and whether it can reach CUI hosts, and record the agreed controls. Undocumented vendor tunnels are among the most frequent reasons boundary scope expands during assessment.

Confirm scope with the agency

The organization sets its boundary, but the contracting agency or its assessor confirms whether the scope is acceptable, and disputes are easier to avoid before the assessment. Bring the boundary diagram, the list of key internal boundaries and the interface inventory to that conversation. Ask the agency which of its own requirements it expects you to cover and which it will assign, since NIST places responsibility for application and compliance issues with the federal agency.

How an assessor tests 03.13.01 under SP 800-171A Rev. 3

This table maps the assessment approach for 03.13.01 to the evidence an assessor typically requests and the gaps that commonly appear. Read each row as one part of the examine, interview and test work that SP 800-171A Rev. 3 describes for the six determination statements. The main takeaway is that boundary protection is judged on documented design, real configuration and staff who can explain how the boundary works.

Assessment approach	Evidence requested	Common findings
Examine: boundary protection procedures and policy	System and communications protection policy, written boundary protection procedures, and the security architecture that places boundary devices	Procedures describe firewalls generically without naming the managed interfaces or the owner of each rule set
Examine: list of key internal boundaries	Current inventory of internal boundaries such as segments holding CUI, administrative networks and enclave edges, with the reason each is key	Internal boundaries are missing from the list, or the list predates a network change
Examine: boundary hardware, software and configuration settings	Firewall and boundary device configuration exports, rule sets, and logging settings for the external and key internal interfaces	Rules allow broad source or destination ranges, or logging is disabled on the rules that matter most
Interview: personnel with boundary protection responsibilities	Named owners of firewall and segmentation changes, and walkthrough of how a rule change is approved and reviewed	Staff describe the design from memory, and the rule change record does not match the running configuration
Interview: system developers and information security personnel	Explanation of how publicly accessible components such as web or API tiers are placed in separate subnetworks	Developers add public services to the same subnetwork as CUI systems without updating the architecture
Test: boundary protection mechanisms	Results of controlled tests showing that traffic crossing the managed interfaces is monitored and filtered as documented	Test results cover only the perimeter, leaving internal boundaries and cloud routes unverified

How to implement boundary protection in the order an assessor expects

This sequence moves from defining what the boundary is to proving that traffic crossing it is controlled, monitored and tested. Each step produces an artifact an assessor can examine, interview against and test, which is how SP 800-171A Rev. 3 assesses 03.13.01.

Document the system boundary and internal interfaces
Start by drawing the boundary of the system that processes, stores or transmits CUI, including every external connection such as cloud tenancies, vendor links, remote access paths and email gateways. Then list the key internal managed interfaces, such as links between enclaves, segments that hold CUI and management networks. The organization owns this step and should review it with the people who run the network. Keep the boundary diagram and the internal boundary list as dated, versioned artifacts, because the examine method expects a list of key internal boundaries and assessors will compare it against the live network.
Define the security architecture and boundary device roles
Write the security architecture that explains how boundary protection devices are arranged, which device enforces which boundary, and what each one is responsible for. Typical roles include a perimeter firewall, a web application firewall in front of public services, and intrusion detection at key internal points. Assign an owner to each device role and record which ones are managed interfaces. The output is the architecture document plus a device role table that links each boundary to its enforcing device. Confirm with your assessor how they expect the architecture to be referenced in your system security plan.
Separate publicly accessible components into subnetworks
Place every publicly accessible component, such as a web server, mail relay or public API, in a physically or logically separate subnetwork. Components that hold or process CUI should not share that subnetwork and should sit behind a boundary device that governs traffic into them. Build the segmentation with firewall zones, VLANs or separate cloud subnets, and document the address ranges in the configuration baseline. Verify the result by reviewing the network configuration and by checking that a host in the public subnetwork cannot reach CUI segments directly. The artifact is the subnet inventory with its purpose and its controlling device.
Restrict external connections to managed boundary devices
Route all connections to external systems through the managed boundary devices defined in the architecture, and remove or block any path that bypasses them, including direct internet egress from workstations, unmanaged modems and undocumented vendor tunnels. For open-source platforms, this usually means a stateful packet filter such as OPNsense with rules that pass, block or reject traffic by source, destination, port and protocol, plus a documented exception process for each allowed flow. Export the rule set and the list of permitted external destinations. The check is that a test from a workstation to an external address succeeds only through the managed path.
Deploy application-layer inspection for public services
For web applications and APIs published through the boundary, add inspection at the application layer. Coraza, an Apache-2.0 web application firewall compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set, can be integrated with Caddy, HAProxy, Traefik or Nginx to inspect requests for attacks such as SQL injection, cross-site scripting and code injection. Confirm the integration and ruleset versions in your own environment before you commit to a design. Record the rule set version, the paranoia or sensitivity setting you chose, and the tuning decisions made for false positives, because assessors will ask how the inspection is maintained.
Enable monitoring and logging at each boundary
Turn on logging at every boundary device and at each internal managed interface so that the boundary produces evidence. Enable per-rule logging on the packet filter, send Suricata EVE JSON output to a log management tool, and use Zeek to record connection logs such as conn.log, protocol logs such as dns.log and http.log, and weird.log for anomalous events. Forward the logs to a central store with restricted access and a documented retention period set by the organization. The artifact is a log source inventory showing each boundary, the logs it produces, where they go and who reviews them, which supports the monitoring and control expectations of the requirement.
Test the configuration and retain the results
Test that the boundary works as documented. Run connectivity tests that confirm the public subnetwork cannot reach CUI segments, attempt unauthorized outbound flows and confirm they are blocked and logged, and send known-bad test requests through the application firewall to confirm it alerts or blocks. Repeat the tests after every rule or topology change. Record each test with its date, the tester, the expected result, the actual result and any remediation. Keep these records with the system security plan so an assessor can interview the people who ran the tests and examine the results.

Which evidence passes a 03.13.01 assessment and how to keep it current

An assessor testing 03.13.01 looks for proof that the boundary exists, that it is documented, and that it still matches the system today. The cards below cover the artifacts that carry that proof and the routine that keeps each one accurate between assessments, since a stale diagram or an unreviewed rule set fails the same test as a missing one.

Architecture diagrams with boundaries marked

The diagram shows every external connection, each managed boundary device, and the subnetworks that separate publicly accessible components from internal systems that hold CUI. An assessor will compare it against the live environment, so each boundary on the drawing should map to a device or rule an assessor can name. Tie diagram revisions to change tickets so the drawing is updated whenever a boundary moves, rather than on a fixed annual cycle.

List of key internal boundaries

This is the register of internal interfaces that the organization has chosen to monitor, such as the edge between a CUI enclave and corporate users, or between a development network and production. The 03.13.01 test method expects the list to exist and to match the diagram. Record the owner, the control device and the reason each boundary was selected, and review the list whenever a segment is added, merged or retired.

Boundary device configuration exports

Configuration exports from firewalls, proxies, web application firewalls and intrusion detection sensors show the settings that enforce the boundary in practice. Schedule exports at a fixed cadence and store them in a versioned repository so an assessor can see both the current state and the history. Compare each export with the approved baseline and investigate any drift before the next assessment window.

Firewall rule reviews

Rule reviews show that each permitted flow still has a business reason, an owner and an expiry where one applies. Reviewers should look for broad source or destination aliases, rules that no longer match traffic, and rules that allow public access to internal subnetworks. Record the reviewer, the date and the rules removed or narrowed, and keep those records with the configuration exports they reviewed.

Network segmentation test results

Segmentation tests try to reach CUI systems from networks that should not be able to reach them, and they confirm that publicly accessible components cannot initiate connections into internal subnetworks. Run these tests after any firewall or routing change and after major changes to the enclave, then keep the scope, the method and the pass or fail result. Failed tests should link to a remediation record that an assessor can follow to closure.

Change records for boundary rules

Each change to a boundary rule, route or device should have a request, an approval, an implementation record and a post-change check. Assessors use these records to confirm that boundary changes are controlled and that the architecture diagrams were updated when the change was made. Keep the link between the change ticket and the configuration export that followed it, so the history can be reconstructed without interviews.

Monitoring logs that show the control working

Logs from boundary devices and network sensors show that traffic is actually being monitored and that denied or anomalous traffic is recorded. Firewall rule-match logs, intrusion detection alerts and connection logs all help demonstrate the control, provided they are retained, time-synchronized and reviewed. Confirm retention periods with the organization's contractual and policy requirements, and sample log extracts for the assessor during the review period.

How firewalls, IDS and flow logs fit together at the boundary

The boundary stack for 03.13.01 works in layers, and an assessor will expect to see each layer doing a different job. A stateful packet filter sits at the edge and enforces which connections may pass at all. In an OPNsense deployment, for example, rules pass, block or reject traffic by source, destination, port and protocol, and aliases group addresses so the rule set stays readable. The filter answers the question "is this traffic permitted to cross the boundary?" and it is the component that should be configured deny by default, with the rule log turned on for the rules that matter. Confirm with your own change records that the rule set matches the approved boundary design, because the filter is only as good as the rules someone wrote and approved.

Traffic that is allowed through still needs inspection, especially for publicly accessible components placed in their own subnetworks. A web application firewall such as Coraza, which is compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set, inspects HTTP requests for application-layer attacks like SQL injection, cross-site scripting and code injection. It answers a different question than the packet filter: not whether a connection may open, but whether the content of an allowed request is hostile. Your team should decide which rule sets run in detection mode and which block, record that decision, and confirm which front-end proxy (Caddy, HAProxy, Traefik or Nginx) hosts the integration in your environment before writing it into the system security plan.

The third layer is monitoring, and here the evidence purpose changes. Suricata's EVE JSON output records rule match alerts, protocol transactions and engine statistics, and Zeek's conn.log records who talked to whom, for how long and over which protocol, with dns.log, http.log and weird.log adding context. These logs show that the boundary was watched and that anomalies were recorded. A rule log from the packet filter proves a rule existed and fired; a monitoring log from IDS or flow analysis proves that the organization observed traffic crossing the boundary and can reconstruct it. Keep both, store them where administrators cannot quietly alter them, and confirm with your assessor how long they must be retained and who reviews them.

Which self-hosted open-source tools produce boundary evidence

This table compares four self-hosted open-source tools by the boundary evidence each can produce for 03.13.01, along with their licenses. Read it as a list of evidence sources, not as a set of tools that satisfy the requirement on their own. The main takeaway is that the architecture, rule decisions and record retention remain the organization's responsibility.

Tool and license	Boundary evidence it produces	What the organization still owns
OPNsense (BSD-2-Clause)	Stateful packet filter rules that pass, block or reject traffic by source, destination, port and protocol, with aliases for address groups and per-rule match logging viewable in the live log view	Defining the rule set, the deny-by-default posture, the subnet design and exporting or retaining rule logs
Coraza (Apache-2.0)	Web application firewall inspection compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set, with integrations for Caddy, HAProxy, Traefik and Nginx	Choosing and tuning the rulesets, deciding which publicly accessible components sit behind it, and reviewing blocked events
Suricata (GPL-2.0-only)	EVE JSON records for rule match alerts, anomalies, flows and protocol transactions such as HTTP, DNS, TLS, SSH and SMB, which can be split into separate files	Placing sensors at the managed interfaces, setting alert handling procedures and retaining EVE output
Zeek (BSD-3-Clause)	conn.log with who communicated, duration, volume and protocol for TCP and UDP, protocol logs such as dns.log and http.log, and weird.log for anomalies, linked by a connection identifier	Deploying sensors at boundary and key internal points, defining what traffic is reviewed, and retaining logs for assessment

Who owns boundary protection work, what partners do, and what the auditor will not do

Your organization owns 03.13.01 in full. The requirement asks you to monitor and control communications at external and key internal managed interfaces, separate publicly accessible components into their own subnetworks, and connect to external systems only through managed boundary devices arranged under your security architecture. Those decisions belong to you, and so does the accountability when the boundary fails. Your team decides where the boundaries sit, which rules are allowed, and who approves changes.

Architecture decisions: Define the system's external and key internal boundaries, the public-facing subnetworks and the trust zones that separate them.
Rule ownership: Approve the allow and deny rules on boundary devices, with a named owner and a documented reason for each exception.
Change approval: Route firewall, proxy and sensor changes through your change control process, with impact analysis before deployment.
Monitoring and response: Review alerts and logs from boundary devices, and decide how findings feed your incident response process.
Policy and plan: Maintain the system and communications protection policy, the boundary protection procedures and the system security plan entries that describe the boundary.

Check that each of these duties has a named individual, not only a team name, before any partner starts work.

Common gaps that fail boundary protection reviews

Boundary protection reviews rarely fail on the presence of a firewall. They fail when the documented boundary, the running configuration and the monitoring output disagree. The gaps below are the ones that most often separate a clean 03.13.01 assessment from a finding.

Undocumented internal boundaries

03.13.01 covers key internal managed interfaces as well as the external edge. Assessors look for a current list of those internal boundaries, such as the line between a CUI enclave and corporate user networks or between development and production. If the list does not exist, the organization cannot show which interfaces it monitors and controls. Action: build the list from the network inventory, name each boundary device that enforces it, and review the list whenever a subnet or VLAN changes.

Public components sharing a subnet

The requirement calls for publicly accessible components to sit in physically or logically separated subnetworks. A web server, mail relay or VPN concentrator placed on the same segment as systems that store or process CUI breaks that separation even when a firewall sits in front of it. Action: move every internet-facing component into a dedicated DMZ or subnet, then test from that segment to confirm it cannot reach CUI hosts except through the approved path.

Broad allow rules without a business reason

Rules such as any source to any destination on a common port, or a permit kept after a project ended, widen the boundary without anyone deciding to. Firewall platforms such as OPNsense let administrators attach descriptions and aliases to rules, and an assessor will ask who approved each one and why it still exists. Action: require a documented owner and business purpose for every allow rule, group addresses with aliases, and remove rules that no longer match an active need.

Monitoring enabled but never reviewed

Intrusion detection and network metadata logs are often turned on during deployment and then left unread. Suricata's EVE output and Zeek's conn.log can record alerts and connection metadata at the boundary, but a log that nobody reviews shows the assessor that the control exists on paper only. Action: assign an owner to review boundary alerts on a stated schedule, route high-severity alerts into a ticket queue, and keep records of each review.

Diagrams that do not match the running configuration

The network diagram in the system security plan often shows a clean architecture while the live firewall, routing and VLAN settings differ. Assessors compare the diagram with exported configurations and interview the people who administer them. Any mismatch becomes a finding about the accuracy of the boundary documentation. Action: export the running configuration on a fixed cadence, reconcile it with the diagram after every approved change, and record the reconciliation as evidence.

Questions buyers ask about 03.13.01 cost, effort and scope

What drives the cost of meeting 03.13.01 boundary protection?

The main cost drivers are how many external and key internal boundaries the system has, how many publicly accessible components need their own separated subnetworks, and how much of the boundary already runs on managed devices with logging. Each boundary needs a documented architecture, a rule set that denies by default, and monitoring that produces records an assessor can examine. Costs split into the time of your own network and security staff, any partner fees for a fixed-scope engagement, and any new hardware or licensing. Ask any quote to list each boundary, each device or platform involved, and which items are one-time (design, configuration, documentation) versus recurring (rule review, log retention, upgrades).

Can an in-house team implement 03.13.01 without outside help?

Yes, an in-house team can implement 03.13.01 if it has staff who understand network segmentation, firewall rule design and log analysis, and if it can document the result for an assessor. The requirement is outcome-based: the organization must show that it monitors and controls communications at its boundaries, separates public-facing components, and connects to external systems only through managed boundary devices. Teams that lack that depth in-house often bring in a partner to design the architecture, configure the platforms and prepare the evidence, while keeping ownership of the controls. Only an independent assessor can judge whether the implementation meets the requirement.

How long does boundary protection work usually take?

Duration depends on the number of boundaries, the age and complexity of the existing network, and whether the environment is cloud, on-premises or air-gapped. Work that involves redesigning subnetworks or replacing devices takes longer than work that adds monitoring and documentation to a clean design. No duration is given here, because the answer changes with the environment. Request a written, fixed-scope plan that lists the boundaries in scope, the deliverables and the timeline, and confirm which change windows and approvals the schedule depends on.

Can a partner own the boundary protection evidence for us?

A partner can prepare the evidence, but it cannot own the control or attest to it. Under the NIST framework, the organization and the federal agency that holds the contract remain responsible for implementation and compliance. A partner can produce architecture diagrams, the list of key internal boundaries, configuration exports, rule documentation, log samples and records of monitoring, then keep them current. The organization should name an internal owner who reviews and signs off on that evidence, and should confirm with its assessor which artifacts they expect to examine and interview.

What does boundary protection need from our network and change teams?

The work needs network and change teams to supply accurate topology, current firewall and routing configurations, and access to the devices that control each boundary. It also needs them to approve changes through their normal process, because rule changes at external and key internal boundaries can interrupt production traffic. Expect requests for interviews with personnel who run boundary protection, information security staff and the people who build the system. Plan for maintenance windows, rollback procedures and a test period before cutover, and agree in advance who can authorize emergency rule changes.

How do Rev. 2 and CMMC treat boundary protection differently?

Rev. 3 folded the Rev. 2 requirement 3.13.5, which covered public-facing subnetworks, into 03.13.01, so the subnetwork separation now sits inside the broader boundary requirement. NIST's change analysis classifies the Rev. 2 3.13.1 to 03.13.01 change as significant, with more detail and foundational tasks. CMMC Level 2 still uses Rev. 2, so it assesses the requirement as SC.L2-3.13.1 and SC.L2-3.13.5, and in the CMMC scoring methodology SC.L2-3.13.1 carries 5 points, which means it cannot be placed on a plan of action and milestones for Conditional status. Confirm the current contract version with the contracting officer before you choose which requirement set to build against.

Which open-source tools can produce boundary protection evidence?

Several self-hosted open-source platforms can produce evidence for this requirement. OPNsense is a stateful packet filter whose rules pass, block or reject traffic by source, destination, port and protocol, and it can log each rule match. Suricata writes EVE JSON records of alerts, flows and protocol transactions, and Zeek writes connection logs such as conn.log linked by a unique connection identifier. Coraza can defend web applications at the boundary. Each tool produces evidence only when its configuration is documented, its logs are retained and reviewed, and your team confirms that it covers each boundary in scope.

How DeployOpen works on this

DeployOpen plans, implements and documents the boundary protection that 03.13.01 expects, inside your own cloud accounts, data centers or air-gapped networks. The organization owns its controls and decides its own boundary design, while DeployOpen prepares the systems and evidence that an independent assessor will examine, interview and test.

How we scope

Engagements are fixed-scope, with the systems, boundaries and deliverables for 03.13.01 agreed in writing before work starts.
We inventory external managed interfaces and key internal boundaries so the written scope names each one that the assessor will ask about.
The scope identifies which publicly accessible components need separate subnetworks and which external connections must pass through managed boundary devices.
Ongoing support and continuous testing are available as a retainer after the fixed-scope work is complete.

How we build

We configure deny-by-default boundary devices, such as stateful packet filters, under the security architecture your organization defines.
We deploy a web application firewall in front of publicly accessible applications and tune its rulesets to the applications it protects.
We separate publicly accessible components into their own subnetworks and document the routing and access rules between zones.
We enable intrusion detection and network metadata logging at key boundaries so that boundary events can be reviewed and traced.

How we hand over

We deliver configuration exports, rule documentation and network diagrams that show each managed boundary and its purpose.
We prepare evidence packs that map each determination statement for 03.13.01 to the artifact that answers it, for your assessor to examine.
We document the boundary procedures and list the personnel responsibilities that an assessor will ask staff to describe in interviews.
We identify any values your organization must assign, such as organization-defined parameters, and record who approved them.

How we support

Retainers cover rule reviews, upgrades and changes to boundary devices after the initial handover, under a separate written scope.
We can run security testing against the boundary, including applications, APIs and infrastructure, to test whether the controls behave as documented.
Confirm with DeployOpen during scoping which platforms, versions and log retention settings your environment requires, since these shape the evidence.
Assessment reports and certification decisions come only from your independent assessor, and DeployOpen does not issue either.