SC.L2-3.13.1 Boundary protection: requirements and evidence

What SC.L2-3.13.1 boundary protection requires and why it is hard to pass

If you are preparing a Level 2 assessment, treat SC.L2-3.13.1 as a requirement you must fully meet, not one you can carry on a plan of action. It is worth 5 points under the CMMC scoring methodology, and a requirement scored above 1 point cannot go on a POA&M, so it has to be MET before your organization can reach Conditional or Final Level 2 status. The requirement asks you to monitor, control and protect communications at the external boundary of your system and at its key internal boundaries. NIST SP 800-171A breaks this into 8 assessment objectives: you must define the external boundary and the key internal boundaries, then show that communications are monitored, controlled and protected at each one. Firewalls and web proxies are the usual enforcement points, and the CMMC Assessment Guide also points to internal boundaries, such as one around a software development environment, as places where you decide what data may flow.

The hard part is rarely buying a firewall. Most organizations already have one. Assessors will test whether the boundaries you drew match your actual system boundary in the System Security Plan, whether every path into and out of the CUI environment crosses a monitored and controlled point, and whether the rules at those points are documented and working. Expect requests for the list of key internal boundaries, the boundary protection hardware and software inventory, the enterprise security architecture documentation and audit records showing that the controls operate. Open-source options such as OPNsense for stateful filtering, Coraza for web application filtering, and Suricata or Zeek for traffic visibility can supply parts of this evidence, but the organization still owns the design decisions and the proof that they work.

The Level 1 counterpart, SC.L1-b.1.x, applies the same objectives to federal contract information rather than CUI, so a team that cannot pass the Level 1 boundary check will not pass Level 2. The Phase II certification requirement was suspended on 13 July 2026, but Phase I self-assessments, SPRS postings and DFARS 252.204-7012 obligations remain in place, and the requirement is still part of the Level 2 standard that applicable contracts reference. Ask your contracting officer which assessment and reporting obligations apply to your contracts now, and confirm the current status of the implementation schedule in the official sources before you plan the work.

Which systems, boundaries and third parties fall under SC.L2-3.13.1

Before any firewall rule or proxy is configured, the organization has to decide what counts as the system, where its boundaries sit and which outside parties touch CUI. Each decision below changes how many boundaries must be monitored, controlled and protected, and therefore how much evidence an assessor will expect to see.

Define the CUI system boundary

Start by listing every system, enclave, account and device that stores, processes or transmits CUI, then draw one line around them. SC.L2-3.13.1 applies at the edge of that defined system, so a vague or undocumented boundary makes the requirement impossible to test. A narrow, well-documented enclave usually means fewer boundary devices and fewer log sources to review. Ask whether the boundary is described in the system security plan and matches the network diagrams an assessor will be given.

Map the external boundary

The external boundary is where the CUI system meets the internet or other untrusted networks, usually through firewalls, VPN concentrators and web proxies. Every connection that crosses it must be monitored and controlled, so each internet path needs a documented device and rule set. Confirm that no forgotten direct connection, test server or vendor tunnel bypasses the firewall, because one unmanaged path can fail the whole objective set.

Identify key internal boundaries

Key internal boundaries separate parts of the CUI system from each other, such as a software development environment, a database tier or a management network. The CMMC Assessment Guide Level 2 notes that internal boundaries decide where data can flow inside the network. Each boundary you identify adds monitoring and control points, so keep the list short and justified by data flow, and document why each one exists.

Bring the development environment inside scope

Source code, build pipelines and test data for CUI systems often live in a development environment that the team treats as an engineering tool rather than part of the system. If CUI can reach it, that environment sits inside the boundary and needs its own internal boundary controls and logs. Decide early whether developers may copy production data into it, since that decision determines whether the environment must be scoped in or the data must be kept out.

Scope cloud and hosted enclaves

A cloud tenant or hosted enclave that stores CUI is part of the system, even when the provider runs the hardware. Your team must define which boundary controls you own, such as security groups, network firewalls and cloud logs, and which the provider documents as its own. Ask the provider for its responsibility matrix and for evidence covering its side of the boundary, because gaps between the two sides are where assessors find problems.

Include remote access and third-party services

Remote access paths, including VPN endpoints, jump hosts and vendor support sessions, are boundary crossings and must be monitored like any other external path. Third-party services that receive, store or process CUI, such as email, collaboration or ticketing platforms, extend the system and need their boundary described in the assessment. Make a written inventory of each remote path and each service that carries CUI, and confirm the contract terms and evidence the provider can supply before assuming it sits outside scope.

How an assessor tests boundary protection at Level 2

This table maps the assessment areas for SC.L2-3.13.1 to what an assessor does, the evidence they request and the findings that most often stop a requirement from being MET. Read it as a preparation checklist: each row shows what the organization should have ready before the assessor arrives, and assessors may also test the firewall and proxy mechanisms directly.

Assessment area	What the assessor does	Evidence requested	Common findings
Boundary definition	Confirms the external boundary and each key internal boundary are named and match the system scope	Boundary diagram, system security plan scope statement, list of key internal boundaries such as a development enclave	Internal boundaries omitted, or CUI flows crossing a boundary that is not documented
Architecture review	Traces how traffic enters and leaves each boundary and checks the design against the documented architecture	Enterprise security architecture documentation, network topology, data flow diagrams	Diagrams that are out of date with live cabling, cloud routes or VPN paths
Firewall rule set testing	Reviews rule base for purpose, source, destination, port and protocol, and tests whether traffic is actually blocked or allowed	Exported firewall configuration, rule owner and justification records, change tickets for recent rules	Overly broad any-to-any rules, unused rules left active, rules with no business justification
Web proxy and inspection testing	Checks that web traffic passes through the proxy and that filtering and monitoring apply to it	Proxy policy export, category or allow lists, sample test results from a client outside the proxy path	Direct outbound paths that bypass the proxy, or proxy logging turned off
Log and monitoring review	Samples boundary logs to confirm they show permitted and denied traffic and that someone reviews them	Firewall and proxy logs over a sample period, alert configuration, evidence of review such as tickets or sign-off	Logs collected but never reviewed, or logs that do not cover internal boundary devices
Administrator interviews	Asks administrators how boundary devices are managed, changed and monitored, and compares answers to the documents	Procedure documents, change approval records, names of rule owners	Answers that differ from the written procedure or from the configuration on the device
Direct mechanism testing	May test the boundary mechanisms directly, for example by attempting connections that the rules should block	Test plan, scope agreement, test results and screenshots taken in the assessed environment	Mechanisms that cannot be shown to work in the live environment, even when documents describe them

Steps to implement boundary protection in a CUI environment

This sequence takes a CUI environment from an undefined perimeter to documented, tested boundary controls with evidence an assessor can follow. Each step closes with a named artifact that feeds the next, so the system security plan reflects what is actually deployed.

Define the CUI boundary and key internal boundaries
Start by mapping where CUI is stored, processed and transmitted, then draw the external boundary of the system and the key internal boundaries inside it, such as the edge between corporate IT and a software development environment. The organization owns this decision, and an implementation partner can facilitate the workshop and draft the diagram. Done means a signed boundary diagram that names every boundary, the systems on each side and the data flows that cross them, which SP 800-171A treats as the basis for objective 1 of 3.13.1.
Inventory boundary devices and their roles
List every device and software component that sits on a boundary, including firewalls, web proxies, VPN concentrators, cloud security groups and any web application firewall in front of a published service. For each one, record its owner, its management interface, the boundaries it protects and the configuration source. Done means a boundary device inventory that an assessor can reconcile against the diagram, with no boundary left without a named control point.
Write deny-by-default rule sets with documented purposes
At each boundary device, start from a rule set that blocks all traffic, then add permit rules only for documented business purposes, specifying source, destination, port and protocol. Use address aliases so groups stay readable and review each rule against its stated purpose before it goes live. Done means exported rule sets stored under configuration control, with a purpose field for every permit rule and an owner who approved it. Requirement 3.13.6 adds the deny-all detail on top of this step.
Enable logging and monitoring at each boundary
Turn on rule-match logging on every boundary device, then forward those logs, along with proxy and intrusion detection output, to a central store that the organization reviews. Open-source sensors such as Suricata's EVE JSON output or Zeek's connection and protocol logs can produce records of who talked to whom, over which protocol and how much data moved. Done means a sample of logs from each boundary, retrieved from the central store, that shows the blocked and permitted events with timestamps and rule identifiers.
Protect boundary management and configuration
Restrict administrative access to boundary devices to named administrators, place management interfaces on a separate network segment, and keep backups of configurations in a protected location. Confirm that changes to rules go through the same change control as other system changes. Done means an access list for each device, a record of recent configuration changes and proof that the management interface is not reachable from general user networks.
Test each boundary control
Test every boundary against its documented rules: attempt traffic that should be blocked, confirm that permitted flows work, and check that the logs record both outcomes. Include a test of the internal boundary around sensitive development or CUI enclaves, and record the tester, date, method and result. Assessors may test the mechanisms directly, so a test plan with repeatable steps is more useful than a single screenshot. Done means signed test records with failures either fixed and retested or documented in a plan of action.
Record the results in the system security plan
Update the system security plan so that the boundary diagram, device inventory, rule set references, logging design and test results all describe the same system. Map each of the eight SP 800-171A objectives for 3.13.1 to the artifact that proves it, and note any gap. Done means a system security plan section for 3.13.1 that points to current evidence, reviewed by the control owner. Only an independent assessor can rate the requirement MET, so this record is the input to that assessment rather than the assessment itself.

Evidence that shows boundary protection is working

An assessor testing SC.L2-3.13.1 looks for a chain of evidence: the documented boundary, the rules that implement it, and the records that show it is monitored. Each artifact below supports the others, so a gap in one usually shows up in another.

Enterprise security architecture and boundary diagram

This document shows where the external boundary and each key internal boundary sit, which systems sit on each side, and which controls enforce them. Assessors compare the diagram against the live network, so a diagram that omits a cloud tenant, a VPN concentrator or a development enclave will fail on its own. Update it whenever a network segment, provider or connection changes, and record the approval date and owner on the diagram itself.

Documented list of key internal boundaries

SP 800-171A treats the key internal boundaries as a named set, not an implied one. Typical entries include the boundary around a software development environment, the boundary between corporate IT and the CUI enclave, and the boundary around administrative networks. For each entry, state what data may cross it, who approves exceptions and which control monitors it. Review the list at each change to the system security plan.

Boundary hardware and software configurations

Export the running configuration of each firewall, web proxy and inspection engine, and keep the exports with the version and date they were taken. Assessors check that the configuration matches the documented boundary and that management interfaces are not reachable from general user networks. Confirm with your platform's documentation which settings export cleanly and which require a backup routine, rather than assuming a screenshot will serve.

Rule set exports with change history

A rule set is evidence only when it shows what changed, when and who approved it. Keep dated exports of the firewall rule base, including aliases for address groups, and tie each change to a ticket that records the business reason and the review. Rules that allow broad source ranges or any destination port are the ones assessors ask about first, so document why each one exists and when it will be removed.

Audit records showing boundary monitoring

Logs from the boundary show that communications are monitored, not just filtered. Firewall rule-match logs, Zeek connection logs and Suricata EVE alerts are the typical sources, and they should be retained and reviewed according to your audit policy. Show a sample of alerts and the follow-up for each, so an assessor can see monitoring that leads to action. Confirm retention periods against your own policy and the assessment scope.

Keeping artifacts current and final

A draft diagram, an unreviewed rule export or a log sample with no review record does not satisfy the objectives, because a requirement is MET only when evidence is in final form. Set a review calendar tied to changes in the system security plan, store each artifact under version control with an approver, and retire superseded versions rather than overwriting them. Before an assessment, confirm that every artifact matches the live environment on the same date.

Self-hosted open-source tools that produce boundary evidence

OPNsense is a firewall platform licensed under BSD-2-Clause that can enforce the external boundary and selected internal boundaries. Its stateful packet filter passes, blocks or rejects traffic by source, destination, port and protocol, so the rule base itself becomes a boundary artifact that an assessor can read and test. Aliases group addresses such as enclave subnets or approved update servers, which keeps rules readable as the environment grows.

Rule export and review: The rule set can be exported and version controlled, so the boundary definition in the system security plan can be compared with the configuration actually running.
Rule-match logging: Enabling logging on a rule records each match, which gives evidence that traffic is being controlled at the boundary rather than assumed to be.
Aliases for boundary definitions: Named address groups for CUI enclaves, management networks and outbound destinations make the internal boundaries you define easy to trace back to specific rules.
Change history: Configuration changes are a point where boundary drift starts, so record who changed a rule, when, and why, and tie it to your change control process.
Interface separation: Assign the external, internal and any DMZ interfaces explicitly so the boundary points described in your documentation match the hardware or virtual interfaces.

Before relying on OPNsense for an assessment, confirm the current release, its license terms for your deployment, and whether its logging and export features meet your retention and review requirements.

What meeting SC.L2-3.13.1 costs in money and effort

This table breaks down the cost components of meeting SC.L2-3.13.1 Boundary protection, showing who is paid for each, whether it is one-time or recurring, what drives it up or down, and what to request in a quote. Costs here are qualitative because no researched dollar or duration figures apply to this requirement. Read it as a checklist for scoping conversations rather than a budget.

Cost component	Who is paid	One-time or recurring	What drives it, and what to request in a quote
Boundary hardware or virtual appliances	Hardware vendor or cloud provider, or the organization's own staff if built in-house	Mostly one-time purchase or setup, with recurring hosting or support fees	Number of external and internal boundaries defined in the System Security Plan. Request a line-item list of appliances, licenses and hosting.
Open-source software licensing	Usually no license fee for named tools such as OPNsense, Suricata, Zeek and Coraza, to be confirmed for each version and use	Recurring if paid support or subscriptions are chosen	Whether the organization buys vendor support or runs community releases. Confirm the license terms for each component with its maintainer.
Engineering time for boundary design and rule sets	Internal engineers or an implementation partner under a fixed-scope written agreement	One-time for initial design, with recurring rule changes	Complexity of the network, number of boundaries and rule review cycles. Request a written scope listing deliverables, boundary diagrams and rule documentation.
Monitoring and log storage	Cloud or data center provider, or the organization's storage team	Recurring	Log volume from firewall, proxy and sensor logs, and retention periods set by the organization. Request the expected log sources and retention settings in the quote.
Evidence upkeep	Internal compliance staff, or a consultant preparing evidence	Recurring	How often rule sets, diagrams and review records change. Keep evidence in final form with dated approvals so each review produces a clean record.
External testing or review of boundary controls	Independent security testing firm or consultant	Recurring, often tied to annual or change-driven testing	Scope of firewall and proxy testing and the number of boundaries tested. Confirm whether testing is separate from the assessor's work.
Assessor sampling and assessment time	Independent assessor (C3PAO for Level 2 certification, or the organization for self-assessment)	One-time per assessment cycle	How many boundary devices, rule sets and logs the assessor samples, and how well evidence is organized. Ask the assessor for its evidence request list before fieldwork.

Who owns boundary protection, who can help, and where the auditor stops

Your organization owns SC.L2-3.13.1 in full. Leadership and the security team decide where the external boundary and key internal boundaries sit, which communications cross each one, and which flows are allowed. Those decisions must be written down, because the assessment objectives ask you to define the boundaries before you can monitor, control and protect them. Your team also approves each firewall and proxy rule, records who approved it and why, and keeps the system security plan current so it describes the boundary as it actually runs.

Boundary definition: Document the external boundary and each key internal boundary, such as the edge of a development environment that holds CUI.
Rule ownership: Name the person who approves each allow rule and retains the change record.
System security plan: Describe the boundary devices, their placement and the monitoring in place, and keep the plan aligned with the network diagram.
Operational monitoring: Staff the review of boundary logs and alerts, and define what happens when a control fails.
Vendor accountability: Keep responsibility for any managed service that operates boundary devices, even when a partner configures them.

Before any outside work starts, confirm that a named internal owner can explain each boundary and each rule without reading the vendor documentation.

Common gaps that cause 3.13.1 to fail

Most SC.L2-3.13.1 findings do not come from missing firewalls. They come from boundaries nobody wrote down, rules nobody can justify, and diagrams that no longer match the running system. Because this requirement is worth 5 points and cannot go on a POA&M, each gap below should be closed before an assessor arrives.

No written boundary definition

Assessors start by checking whether the organization has defined its external boundary and key internal boundaries. If the answer lives only in an engineer's head, the remaining objectives cannot be met. Write down each boundary, the systems on either side, and the devices that monitor and control traffic across it. To close the gap, tie the definition to the system security plan and the scope of CUI, then have the owner sign off on it.

Rules without documented purpose

Firewall and proxy rule sets often grow through change requests that never explain why a rule exists. An assessor testing whether communications are controlled will ask what each permitted flow is for. Record a business justification, an owner, and a review date for every rule that crosses the boundary. Remove any rule that cannot be justified, and use aliases in OPNsense so that address groups are named by purpose rather than by raw IP lists.

Allow-any rules left from testing

Temporary permit-all rules added during integration or troubleshooting are a common finding. They remain active long after the test ends and quietly bypass the controls the assessor is trying to verify. Search the rule base for broad source, destination, or port ranges and for rules created during past maintenance windows. Close the gap by requiring an expiry date on any exception and by reviewing the rule base against the approved boundary after each change.

Logs enabled but never reviewed

Boundary devices often generate detailed logs that nobody reads. Assessors check whether monitoring is real, which means someone looks at denied traffic, unusual protocols, and sessions to unexpected destinations. Assign a named reviewer, define what they look for, and keep records of reviews. Suricata EVE output and Zeek connection logs can feed a log management tool, but the review procedure and its evidence are what the assessor tests.

Cloud and SaaS outside the boundary

Collaboration suites, hosted ticketing tools, and cloud storage that handle CUI are sometimes left off the boundary diagram because they are managed by someone else. If CUI flows to those services, they sit inside the assessed scope and their connections must be monitored and controlled. List every external service that receives or stores CUI, document how traffic reaches it, and confirm the provider's responsibilities in writing.

Diagrams that drift from configuration

A boundary diagram drawn during the initial build is often out of date after a year of changes. Assessors compare the diagram with the running configuration, and any mismatch undermines the whole boundary story. Export the active rule set, interface list, and proxy settings, then reconcile them with the diagram on a fixed schedule and after significant changes. Keep the reconciled diagram and the export together as evidence.

Questions buyers ask about SC.L2-3.13.1 cost, effort and outside help

Does a firewall alone satisfy SC.L2-3.13.1 boundary protection?

No. A firewall is usually one part of the answer, but SC.L2-3.13.1 asks you to define the external boundary and key internal boundaries and to monitor, control and protect communications at each one. NIST SP 800-171A breaks this into 8 assessment objectives. An assessor will ask where your boundaries are documented, which devices enforce them, and whether monitoring records show the rules working. Web proxies, segmentation around sensitive internal environments such as development systems, boundary logs and enterprise security architecture documentation typically appear alongside the firewall. The CMMC Assessment Guide Level 2 describes these common boundary controls. Because the requirement is worth 5 points and cannot go on a POA&M, one missing objective leaves it NOT MET.

How long does SC.L2-3.13.1 work take, and what drives the schedule?

No researched duration applies to every environment, so the schedule depends on your system. The main drivers are the number of boundaries to define, how current your network diagrams and rule sets are, how many devices enforce policy, whether logs already reach a central point, and how mature your change control records are. Evidence must also be in final form, not drafts, before a requirement can be scored as MET, so documentation often sets the pace. Most DeployOpen engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts. Ask for milestones covering boundary definition, rule review, monitoring deployment, evidence collection and handoff, and confirm which of these depend on your staff's availability.

Can open-source tools cover the boundary monitoring part of SC.L2-3.13.1?

Open-source tools can cover parts of the requirement, but they do not make a system compliant by themselves. OPNsense is a stateful packet filter with aliases and per-rule logging, Coraza is a web application firewall compatible with the OWASP Core Rule Set and ModSecurity SecLang rulesets, Suricata writes EVE JSON alert and protocol records, and Zeek writes conn.log and other protocol logs linked by connection identifiers. Confirm the license terms for your exact deployment and any redistribution, since OPNsense is BSD-2-Clause, Coraza is Apache-2.0, Suricata is GPL-2.0-only and Zeek is BSD-3-Clause. Also confirm whether any commercial support, add-ons or hosted services carry separate terms. Your boundary definitions and retained evidence still have to satisfy the assessment objectives.

What does the SC.L2-3.13.1 work need from our internal team?

Your team keeps ownership of the controls, so the work depends on people who know the network and can make decisions about it. Network and security owners need to name the external and key internal boundaries and approve the rule sets that enforce them. System owners must provide device configurations, change tickets, log access and access to the environments being protected. A named authority should accept the system security plan and the self-assessment results. Staff also need time for walkthroughs and interviews, where they explain how boundaries are monitored and how alerts are handled. Plan for these hours before the work starts, because delays in approvals often extend the timeline more than technical setup does.

Can a partner prepare boundary evidence without assessing our system?

Yes. DeployOpen plans, implements, hardens and documents self-hosted open-source platforms, and it prepares systems, controls and evidence for compliance assessments. It does not issue assessment reports, attestations or certifications. Those come only from independent parties. For Level 2 certification assessments, the CMMC rule places the work with C3PAOs authorized or accredited by the CMMC Accreditation Body, currently The Cyber AB. Your organization can also run its own self-assessment against the NIST SP 800-171A objectives. Keep the preparing partner separate from the assessor so the assessment remains independent, and ask the partner to deliver an evidence list mapped to each boundary objective.

Does the Phase II suspension mean we can delay SC.L2-3.13.1?

No. On 13 July 2026 the Department of War suspended CMMC Phase II, which had been scheduled to start on 10 November 2026 and would have required Level 2 C3PAO certification for applicable contracts. It also started a 60-day review by a CMMC Reform Task Force. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place. The Level 2 requirements still come from NIST SP 800-171 Rev. 2, and the Department of War said it will enforce Rev. 2 in the interim. Read the Department of War release and confirm current status with your contracting officer, since the review may change dates and requirements.

What does SC.L2-3.13.1 cost, and what should a quote include?

No researched figure applies to this requirement, so ask for a quote built from a written scope. The main cost components are internal staff time, software and any commercial support for the tools, hosting or hardware for monitoring and logs, and implementation services for the agreed scope. Some costs are one-time, such as boundary definition and initial deployment. Others recur, including log review, rule reviews after changes and periodic evidence refreshes. If your contract later requires a certification assessment, that fee is paid to the assessor, not to the preparing partner. A useful quote lists the boundaries in scope, deliverables, the evidence set, assumptions, exclusions, and any ongoing support retainer.

How DeployOpen scopes and prepares boundary protection evidence

DeployOpen plans, implements and documents the boundary controls that SC.L2-3.13.1 examines, inside your own infrastructure. Your organization owns the requirement and the boundary decisions, and an independent assessor is the only party that judges whether the requirement is MET.

How we scope

Engagements are fixed-scope, with the boundaries, systems and interfaces to be covered agreed in writing before work starts.
The written scope names each external and key internal boundary you want defined, including the firewalls, proxies and monitoring points that enforce them.
Scope also states what is excluded, such as boundaries owned by a cloud provider or a managed service, so responsibilities are clear.

How we build

We deploy and configure open-source boundary tooling, such as OPNsense for stateful filtering and Coraza for web application filtering, inside your environment.
We set up Suricata and Zeek to record traffic at boundary points, so communications can be monitored and reviewed.
We test that each boundary control blocks and logs the traffic it is meant to, and document the results for your assessor.

How we hand over

Deliverables include the boundary architecture documentation, rule and configuration baselines, and a record of the tests performed.
Log outputs are configured so an assessor can trace a monitored connection from the boundary through to the record that shows it.
Your staff receive a handover covering how to review boundary logs, change rules under change control and keep evidence current.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, so boundary rules and tooling stay maintained after handover.
Before any assessment, ask us to confirm which evidence is in final form, since draft documents do not count toward MET.
Your organization decides the final status of the requirement, and an independent assessor or certification body issues any report or certificate.