Boundary protection is more than 'we have a firewall.' The first five 3.13 requirements cover communications at external and key internal boundaries, secure architecture, separation of user and system-management functions, prevention of unintended transfer through shared resources, and isolation of publicly accessible components.
For a small defense contractor, the useful test is whether the organization can show how the requirement applies inside the defined FCI/CUI boundary, who operates it, and what current evidence proves it is working.
The rule in plain English
3.13.1 focuses on monitoring, controlling, and protecting communications. 3.13.5 requires publicly accessible system components to be placed in separated subnetworks. The middle requirements shape how architecture reduces cross-use and unintended transfer.
Segmentation is especially important when a contractor narrows a CUI enclave. The control narrative, data-flow diagram, and live enforcement rules should tell the same story.
How to implement it without overbuilding
Document external edges, inter-segment firewalls or equivalent policy enforcement, public-facing services, management paths, and administrative separation.
Review rules for current business need instead of allowing years of accumulated exceptions. Where practical, default-deny approaches make the intended boundary easier to explain.
What evidence to keep
Keep network/data-flow diagrams, firewall rule exports, change tickets, segmentation tests, public-service architecture, and administrative-access design.
An assessor should be able to pick a path on the diagram and find the technical control that restricts it.
Where teams get into trouble
A common failure is a beautiful diagram that does not match live routing. Another is placing a public server on the same unrestricted network as CUI assets.
Small-contractor walkthrough
A contractor creates a CUI enclave but leaves a public web server, remote-management network, and shared DNS services on adjacent infrastructure. Boundary evidence should show which communications are permitted across each trust boundary and how public components are isolated.
A practical way to test the article's advice is to run one representative case through the process rather than reviewing documentation in the abstract.
The point of the exercise is traceability: a reviewer should be able to see the triggering fact, the decision made, the system or person affected, and the record that proves the action occurred.
- Map external/internal trust boundaries.
- Identify public components.
- Verify segmentation rules.
- Separate management functions.
Decisions to document before assessment
Before marking this topic ready, make four decisions explicit: map external/internal trust boundaries; identify public components; verify segmentation rules; and separate management functions. Assign an owner and an evidence location to each decision.
Manual deep review
3.13.1 through 3.13.5 form an architecture story: control communications at external and key internal boundaries, use secure architecture, separate user from system-management functions, prevent unintended transfer through shared resources, and separate public components from internal networks. A perimeter firewall cannot prove all five by itself.
Use the CUI data-flow diagram together with network and cloud architecture. External boundaries may include internet, vendor, partner, remote-user, and cloud connections. Key internal boundaries may include a CUI enclave, management plane, server segment, OT zone, backup network, or another trust transition. Record enforcement mechanism, allowed flows, logging source, rule owner, and change path.
A VLAN label is not proof of segmentation when routing is open. Conversely, cloud security groups, gateways, proxies, host policy, or application controls can provide effective logical segmentation when the enforcement and tests are clear. For important boundaries, retain one allowed-flow and one blocked-flow test.
For 3.13.3, trace a real administrator through the management path to a domain controller, network appliance, hypervisor, cloud tenant, backup console, or security platform. Show how daily user activity is separated from management functionality through accounts, workstations, jump hosts, networks, or privileged-access controls.
For 3.13.5 and 3.13.4, inspect public-facing components and shared-resource behavior. Test a public system's path toward internal CUI resources, and consider virtualization, temporary files, spoolers, shared storage, and other mechanisms that might expose residual information. Reconcile diagrams to live firewall/security-group rules and remove forgotten temporary exceptions.
Review rule intent, not only rule count
A firewall review should identify why each material rule exists, which source and destination zones it connects, which protocol or application is permitted, who owns the business need, and whether the rule is temporary or permanent. Large rule sets often contain broad administrative exceptions that were created for troubleshooting and never removed. Those rules matter more to 3.13.1 than a screenshot showing that the firewall appliance is licensed and online.
Apply the same discipline in cloud environments. Security groups, network security groups, routing tables, private endpoints, identity-aware proxies, and application gateways can enforce boundaries even when there is no traditional DMZ appliance. The evidence should show the actual trust transition and the policy that limits communication across it.
Test boundary failure modes
Run one test from an unauthorized user segment toward a CUI resource, one test from a public-facing component toward an internal system, and one test from an ordinary workstation toward a management interface. The expected result should be denied or tightly constrained according to the architecture. Record the source, destination, test time, and enforcement point so the result can be tied to the diagram and rule set.
For manufacturing or OT, include the production boundary. If CAD/CAM data moves to shop-floor equipment, document the permitted path and prevent the shop-floor zone from becoming an unrestricted bridge back into the business network. Specialized equipment can require tailored architecture, but it should not create an unexplained trusted network.
Final operating detail
Include remote administration in the boundary test. A secure user VPN does not prove the firewall, hypervisor, cloud console, or backup appliance cannot be managed through a second direct path. Compare the approved management diagram with real listening services, cloud admin endpoints, and vendor-support configuration.
A short working check
- ✓Map external/internal trust boundaries.
- ✓Identify public components.
- ✓Verify segmentation rules.
- ✓Separate management functions.
- ✓Review stale firewall rules.
- ✓Test representative traffic paths.
Common questions
Does CMMC require a hardware firewall?
It requires boundary-protection outcomes, not one specific appliance form factor.
What is a key internal boundary?
A boundary inside the organization where different trust or security zones require controlled communications, such as a CUI enclave boundary.
Is a VLAN enough?
A VLAN can be part of the design, but effective policy enforcement between zones still has to be shown.
Why does a data-flow diagram matter?
It helps verify that documented CUI paths align with actual boundary controls.
Official sources used for this guide
Open the primary source before making a contract-specific decision. Regulations and program implementation can change.
