Why Your Network Architecture Determines Your Compliance Cost
Before a C3PAO assessor evaluates a single control, they do one thing: determine the scope of your assessment environment. Scope is defined by your system boundary, which is the documented set of systems, components, and communication paths where CUI is processed, stored, or transmitted. Every system inside that boundary must satisfy all 110 NIST SP 800-171 requirements. Every system outside it does not.
For a small defense contractor with 40 employees, the practical difference between a well-segmented environment and a flat network is often the difference between 15 systems in scope and 150. The compliance cost, the remediation effort, and the ongoing maintenance burden scale with every system inside your boundary. Network segmentation is not an IT project. It is a cost-reduction strategy.
This is why contractors who begin compliance work without addressing network architecture first routinely discover that their actual scope is three to four times what they estimated. By the time they engage a C3PAO, they are either scrambling to redesign the network under time pressure or accepting an assessment scope that makes their SPRS score nearly impossible to achieve.
The NIST SP 800-171 Requirements That Drive This
NIST SP 800-171 does not use the phrase "network segmentation." What it requires is more fundamental: you must control and protect communications at external and internal boundaries, and you must enforce separation between different functional zones of your environment. The segmentation architecture is how you demonstrate those controls technically.
| Requirement | What It Requires | Segmentation Role |
|---|---|---|
| SC.L2-3.13.1 | Monitor, control, and protect organizational communications at external boundaries and key internal boundaries. | Defines the legal basis for your enclave boundary. "Key internal boundaries" is the operative phrase. Your CUI/non-CUI boundary qualifies. |
| SC.L2-3.13.2 | Employ architectural designs, software development techniques, and systems engineering principles that promote effective information security. | Requires that security be designed into the architecture, not bolted on afterward. A segmented enclave satisfies this by design. |
| SC.L2-3.13.3 | Separate user functionality from system management functionality. | Requires management plane isolation. Your admin consoles and jump hosts must not share the same access path as general user workstations. |
| SC.L2-3.13.5 | Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks. | Requires a DMZ or equivalent for any public-facing components. If you have a web server or VPN gateway, it cannot sit on the same subnet as your CUI systems. |
| AC.L2-3.1.3 | Control the flow of CUI in accordance with approved authorizations. | Information flow control. Your firewall rules and routing policy are the technical enforcement of this requirement. You must be able to demonstrate that CUI cannot flow to unauthorized systems. |
| AC.L2-3.1.20 | Verify and control all connections to external systems. | All traffic leaving the CUI enclave must pass through a controlled egress point. This is the basis for your outbound filtering and DNS policy. |
These requirements together describe an architecture, even if they do not specify one. A stateful firewall-enforced enclave with controlled ingress, controlled egress, management plane separation, and a DMZ for public-facing components is the practical implementation that satisfies all of them simultaneously.
Defining the Boundary Before Building Anything
The most common mistake is treating boundary definition as something that happens after the network is built. It is the opposite. Your boundary definition drives every architecture decision that follows. Get the boundary right first, then build the infrastructure to enforce it.
What Must Be Inside the Boundary
Your CUI enclave must include every system where CUI is processed, stored, or transmitted.
| System Type | Why It Is In Scope |
|---|---|
| Storage systems | File servers, NAS devices, SharePoint sites, and cloud storage where CUI files live are the core of the enclave. If CUI resides there, the system is in scope. |
| Workstations that access CUI | Any endpoint where a user opens, edits, or views CUI documents is in scope, including remote endpoints connecting via VPN. |
| Email systems handling CUI | If CUI arrives or is sent via email, the email platform is in scope. This is the most frequently overlooked inclusion in boundary scoping exercises. |
| Engineering and CAD systems | If the drawings and specifications your team works from are CUI (distribution-statement-marked or explicitly labeled), the systems running those tools are in scope. |
| Communication paths between in-scope systems | Switches, routers, and network segments that carry CUI traffic are within the boundary. The wire is part of the enclave. |
What Can Be Outside the Boundary
A system is out of scope only if it has no path to CUI: no access, no transit, no processing. In a properly segmented environment, this includes:
- HR and payroll systems with no connection to the CUI network segment.
- Shop floor production equipment that operates on an isolated OT network with no CUI data path.
- Guest Wi-Fi infrastructure physically and logically isolated from internal networks.
- Corporate marketing and website systems with no CUI exposure.
Implementation: Building the Enclave
There is no single required architecture. What matters is that the boundary is technically enforced, consistently documented, and provably maintained. The following describes a common reference architecture for a small defense contractor with an on-premises or hybrid environment.
Layer 1 — VLAN Separation
Create a dedicated VLAN for CUI systems. This VLAN should contain only the systems confirmed to be in scope. Do not put any system on the CUI VLAN speculatively. Every system on that VLAN inherits the full 110-requirement compliance obligation.
A VLAN alone is not a security boundary. It provides logical separation at Layer 2, but without a stateful enforcement point controlling inter-VLAN routing, traffic can still move between VLANs. The VLAN is the foundation, not the control.
Layer 2 — Stateful Firewall Enforcement
Deploy a stateful firewall (or use the stateful inspection capability of a managed switch/router) to control all traffic between the CUI VLAN and every other network segment. The rule set should implement a default-deny posture: no traffic crosses the boundary unless there is an explicit rule permitting it, and every rule has a documented business justification.
| Traffic Direction | Default Policy | Permitted Exceptions (examples) |
|---|---|---|
| Corporate network → CUI VLAN | Deny all | Jump host connection on designated port; IT admin access from management VLAN only |
| CUI VLAN → corporate network | Deny all | DNS resolution via internal DNS server; NTP time sync; patch management traffic to WSUS/update server |
| CUI VLAN → internet | Deny all | Approved update sources (Microsoft, antivirus vendor) via explicit allow-list; no general web browsing from CUI workstations |
| Internet → CUI VLAN | Deny all | Authenticated VPN only, with MFA enforced at the VPN gateway |
Layer 3 — Jump Host for Administrative Access
Administrative access to CUI systems should not come directly from general corporate workstations. A jump host (also called a bastion host or privileged access workstation) is a hardened, dedicated system that serves as the sole administrative access point into the CUI enclave. IT administrators connect to the jump host first, from the management VLAN with MFA enforced, and then access CUI systems from there.
This architecture satisfies SC.L2-3.13.3 (separation of user functionality from system management) and limits the blast radius of a compromised admin credential. If an admin account is stolen from a general corporate workstation, it cannot reach CUI systems directly without traversing the jump host, which has its own authentication requirements.
Layer 4 — DMZ for Public-Facing Components
If your environment includes public-facing components (a VPN gateway, a web portal, a customer-accessible system), those components must sit in a DMZ, not on the CUI network segment. SC.L2-3.13.5 is explicit: publicly accessible components must be physically or logically separated from internal networks.
A three-zone architecture (internet / DMZ / CUI internal) is the standard implementation. Your VPN concentrator lives in the DMZ and terminates there; authenticated VPN sessions then traverse a second firewall leg into the CUI VLAN. This means a compromised VPN gateway does not automatically compromise CUI systems.
Cloud Enclaves: GCC High, Azure Government, and the FedRAMP Requirement
A growing number of small defense contractors are moving their CUI environments to cloud-hosted enclaves rather than maintaining on-premises infrastructure. Cloud enclaves are a legitimate approach for CMMC Level 2, but only when the cloud platform itself meets the baseline authorization requirement.
NIST SP 800-171 requirement 3.13.6 and the broader CMMC framework require that cloud services handling CUI be FedRAMP Moderate authorized at minimum, or offer equivalent security posture as agreed to with the DoD. Standard commercial cloud platforms (Microsoft 365 commercial, Google Workspace, and standard AWS) are not authorized for CUI without additional controls and configuration that most small contractors are not implementing.
| Cloud Platform | CUI Authorized? | Notes |
|---|---|---|
| Microsoft 365 GCC High | Yes | The most commonly used cloud enclave for DIB contractors. Includes Teams, SharePoint, Exchange, and OneDrive in a DoD IL2/IL4 boundary. Requires qualifying organization (US persons only). |
| Azure Government | Yes (with configuration) | FedRAMP High authorized infrastructure. Used for custom workloads, VMs, and storage. Requires proper tenant configuration. The authorization covers the platform, not your workload by default. |
| Microsoft 365 GCC (standard) | Conditionally | FedRAMP Moderate authorized, but not at the IL4/IL5 level. Acceptable for some CUI categories under specific DoD guidance, but carry-over risk from non-US data residency provisions. Verify with your contracting officer. |
| Microsoft 365 Commercial | No | Not authorized for CUI. The most common compliance error in the DIB. Contractors running standard M365 with CUI in SharePoint Online or Exchange are out of compliance regardless of other controls implemented. |
| AWS GovCloud | Yes (with configuration) | FedRAMP High authorized. Viable for workloads, storage, and custom applications. Same caveat as Azure Government: platform authorization does not extend to improperly configured workloads. |
| Standard AWS / GCP | No | Commercial regions are not authorized for CUI, regardless of encryption or access controls applied at the application layer. |
Hybrid Environments
Many small contractors end up with hybrid environments: on-premises systems for engineering workstations and CAD tools, cloud-hosted collaboration tools for document management and email. A hybrid approach is workable, but the boundary documentation becomes more complex. Your SSP must clearly describe where CUI lives in each environment, how the two environments connect (typically a site-to-site VPN), and how the boundary controls apply to each leg.
What Your SSP Must Document About the Network
A well-built enclave that is not documented is equivalent to no enclave from an assessment perspective. C3PAO assessors evaluate your implementation against your SSP. If the SSP does not describe it, it effectively does not exist as a control. The following documentation is the minimum required for a defensible boundary in your System Security Plan.
| Document | What It Must Contain |
|---|---|
| System boundary narrative | A written description of what is in scope, what is out of scope, and the rationale for each determination. Reference specific technical controls (firewall rules, VLAN assignments) that enforce the boundary, not just describe it in general terms. |
| Network diagram | A current, accurate diagram showing the CUI enclave, adjacent network segments, boundary enforcement points (firewalls, ACLs), and all external connections. Assessors will compare this diagram against your actual infrastructure during the on-site review. |
| Component inventory | Every system inside the boundary listed with hardware identifier, operating system, function, and CUI handling role. This inventory is required for multiple NIST SP 800-171 controls and will be spot-checked against discovered devices during the assessment. |
| Firewall rule documentation | A current export or summary of the rules governing inter-segment traffic, with a documented justification for each rule. Rules without justification are a finding. Rules permitting broader access than necessary are a finding. |
| Data flow diagrams | Document where CUI enters your environment, where it transits, and where it terminates. Assessors evaluate information flow controls (AC.L2-3.1.3) against these diagrams. |
| External connection inventory | Every connection from the CUI enclave to an external system or service, including cloud services, contractor partner connections, and internet egress points, with access authorization documented for each. |
The quality of this documentation is not an aesthetic preference. It directly determines how smoothly your C3PAO assessment proceeds. Assessors who arrive to find a current, accurate SSP with a precise network diagram and a clean component inventory can complete their work methodically. Assessors who arrive to find a vague narrative with an outdated diagram spend their time chasing discrepancies, and every discrepancy they document is a potential finding.
What Assessors Actually Look For
Understanding what a C3PAO assessor is evaluating during the boundary and network review helps you anticipate findings before they occur. The CMMC Assessment Guide for Level 2 defines the examination methods: review of documentation, interview of responsible personnel, and testing of implemented controls. For network segmentation, all three apply.
Documentation Review
Assessors will review your network diagram for accuracy and completeness, your firewall rule set for alignment with the stated boundary, your component inventory for completeness, and your SSP's system boundary section for a coherent and technically defensible description. Diagrams that are clearly outdated (wrong IP ranges, missing components, systems decommissioned years ago) signal that the SSP is not being maintained and will prompt deeper examination.
Interviews
Expect to be asked: Who is responsible for maintaining the firewall rule set? What is your process for adding a new system to the CUI environment? How do you ensure that systems added to the corporate network cannot access CUI systems? What is your change control process for network modifications? If the person answering cannot describe a real, repeatable process, the control is likely documented but not implemented.
Technical Testing
Assessors may request a firewall rule export and compare it against the documented rule set. They may attempt to route traffic across a boundary that should be blocked to verify enforcement. They may conduct network discovery scans to identify systems not listed in your component inventory. The technical testing component is not exhaustive, but it is enough to surface obvious mismatches between documentation and reality.
Frequently Asked Questions
CMMC Level 2 does not use the word "segmentation," but NIST SP 800-171 requirement 3.13.1 requires you to monitor, control, and protect communications at your system boundary, and 3.13.3 requires you to separate user functionality from system management functionality. In practice, separating CUI systems from the rest of your network is the most reliable way to satisfy these requirements and limit the scope of your assessment environment. A flat network is not prohibited, but it means every system on that network is potentially in scope.
A VLAN creates logical separation at Layer 2, but it is not a security boundary without a stateful enforcement point controlling inter-VLAN traffic. If your VLAN relies only on Layer 2 separation with no enforced routing policy between it and your general corporate network, a C3PAO assessor will find the boundary insufficient. You need a stateful firewall or equivalent enforcement mechanism between the CUI VLAN and everything else. The VLAN is a useful tool; the firewall is the control.
Yes, but only if the cloud service is FedRAMP Moderate authorized at minimum, and only if the boundary between your CUI cloud environment and other systems is clearly defined, enforced, and documented. GCC High and Azure Government are the most commonly used options. Standard commercial M365 or AWS is not sufficient regardless of the additional security configurations you apply on top of it.
Yes, especially in that scenario. If you have three systems that handle CUI and they sit on a flat network with 80 other systems, your assessment scope is potentially 83 systems. If you segment those three systems into a clearly defined enclave, your scope is three systems plus the boundary enforcement infrastructure. The segmentation project is a one-time effort; the reduced assessment scope benefits you at every assessment going forward. The smaller your actual CUI footprint, the higher the return on properly segmenting it.
Remote endpoints that access CUI are inside your boundary. A laptop connecting via VPN to your CUI file server is in scope. The NIST SP 800-171 requirements apply to that endpoint. This means remote workstations used for CUI work must meet the same hardening requirements as on-site workstations: endpoint detection and response, full disk encryption, MFA, and a consistent patching cadence. Split-tunnel VPN configurations that route only CUI-bound traffic through the tunnel require careful review to ensure that no CUI can leak through the non-tunneled traffic path.
If CUI is printed on it, yes. A network printer that receives print jobs containing CUI is processing that information and is within your boundary. This is one of the most commonly overlooked scope inclusions. Options for handling it include placing the printer on the CUI VLAN with appropriate access controls, using a dedicated CUI printer physically isolated from general corporate printing, or restricting CUI printing to a single workstation with a locally attached printer not accessible from the network.