Network Segmentation Inside a CMMC Enclave

You cut scope when you design a tight enclave boundary and control every path across it. You help an assessor when you can show that design, the controls that enforce it, and the evidence that those controls run as you claim.

CMMC enclave definition

DoD uses CMMC to assess whether you implemented required safeguards on systems that process, store, or transmit CUI or FCI. DoD aligns Level 2 with NIST SP 800-171. That mapping anchors your technical controls and your assessment discussion.

An enclave is an in-scope environment where you handle CUI. You decide the boundary and you own the documentation. DoD’s Level 2 Assessment Guide directs you to define the system boundary, identify in-scope assets, and show how you separated those assets from out-of-scope assets for assessment purposes. Your system security plan (SSP) carries that definition and the supporting design. If this is your first pass at scoping, start with CMMC scoping the CUI boundary. That post covers boundary choices and their tradeoffs.

NIST SP 800-171 names boundary protection in SC.L2-3.13.1 and subnetworks for publicly accessible components in SC.L2-3.13.5. Your enclave design needs to implement both ideas, then prove them with enforceable controls and monitoring.

Boundary-driven segmentation

You segment to reduce blast radius and to remove uninvolved systems from scope. You accomplish that by placing CUI systems and dependent services in defined zones, then filtering every flow across zone lines. You implement administrative separation so that teams cannot short-circuit those filters.

Two patterns dominate inside a CUI enclave.

You place CUI workloads in private zones and route north-south flows through a controlled choke point.
You separate public-facing services, then route only required flows into private zones.

NIST SP 800-171 expects you to protect and monitor the boundary with technical controls, then show evidence. SC.L2-3.13.1 speaks to boundary protection and monitoring. SC.L2-3.13.5 points you to DMZ-style subnetworks for public components. Access controls from the AC family will touch the same design. You control remote access in AC.L2-3.1.3 and you verify and control connections to external systems in AC.L2-3.1.20. Configuration management in CM.L2-3.4.6 supports the principle of least functionality, which you apply to enclave hosts and services.

Physical and logical isolation

DoD distinguishes physical isolation from logical separation in its published FAQ. If you claim physical isolation, you either remove network connections, or you run separate networking hardware such as routers and switches that do not mix traffic with the rest of the enterprise. If you claim logical separation, you place CUI systems in a discrete logical computing zone, you gate traffic with access controls, and you enforce strong identity boundaries. You cannot claim enclave status with a VLAN alone. You need policy enforcement points, routing boundaries, and filtering that you can demonstrate.

Many contractors blend the two. You might run separate switching infrastructure inside a plant, then enforce firewall policies and identity-aware proxies at the boundary with the corporate network. You might run point-to-point circuits to a cloud tenant that only exposes specific endpoints, then force all other paths through a broker that you manage.

Evidence assessors expect

Assessors cannot read your intent. You need to show design artifacts and operating evidence that prove your enclave boundary and the segmentation inside it.

Start with design-level material that names the actors and the enforcement points.

You provide a current network diagram that shows zones, boundary devices, trust relationships, and external connections.
You include a data flow view that traces CUI across the boundary and through the enclave.

Then produce implementation evidence that maps to that design.

You show firewall and router rule sets, ACLs, and NAT rules that match the diagram and only permit documented flows.
You provide switch and virtualization configs that bind ports, VLANs, and routing instances to the zones you named.

Finally, prove operation over time.

You present logs and alerts that show blocked and permitted flows at the boundary, along with monitoring of management access to enforcement devices.
You walk through a change record where your team introduced a new flow and updated rules, approvals, and documentation.

DoD’s Level 2 Assessment Guide and the Cyber AB assessment process both direct assessors to look for clear boundary definition, control implementation, and objective evidence. You save time when you anchor every claim in the SSP with a control owner, a system that enforces the control, and verifiable records. If your enclave lives in Microsoft 365 or a hybrid that touches Microsoft cloud, coordinate identity and device gating with network controls. Our post on System Security Plan for NIST 800-171 outlines how to tie these elements together in the SSP.

Microsoft cloud patterns for CUI segmentation

Microsoft does not offer a compliance guarantee. You can, however, apply specific Microsoft capabilities to support an enclave boundary and reduce egress paths for CUI.

Identity gates

You use Microsoft Entra ID Conditional Access to restrict access based on user risk, device state, location, and application.
You pair Conditional Access with device compliance so only healthy, managed endpoints reach enclave apps.

Device health and configuration

You define Microsoft Intune compliance policies that enforce encryption, OS version, and security configuration for enclave devices.
You feed Intune device state into Conditional Access so enforcement happens before any data path opens.

Content controls

You apply Microsoft Purview Information Protection sensitivity labels to documents and email that contain CUI, then require encryption and usage restrictions that follow the data.
You enforce Microsoft Purview DLP policies to detect and block CUI patterns in Exchange Online, SharePoint, OneDrive, and supported endpoints.

These tools do not replace network segmentation. You still need a routed boundary with enforced flows between enclave zones and external networks. Identity and content controls close common exfil paths that live above the network layer. If you need a refresher on identity gating in defense contracts, see Conditional Access for DFARS 7012.

Practical patterns that work in assessments

You improve your position when you design for enforcement and proof. The following patterns show up in assessments that go well.

Perimeter and egress

You terminate all inbound access for enclave services in a single fronting tier, then proxy or publish only required services deeper inside.
You restrict egress to named destinations, protocols, and ports, and you log every exception request with a duration and an owner.

Administrative separation

You run separate admin accounts, MFA, and management jump paths for enclave infrastructure, and you restrict management plane exposure to a dedicated network.
You forbid direct management from corporate devices and require enclave-admin devices that meet higher configuration standards.

Remote access

You broker remote access through a controlled entry point that authenticates in Entra ID, checks device compliance, and logs session details.
You block split tunneling for enclave sessions and force all traffic through the enclave boundary devices for monitoring.

Public services

You place public-facing systems like supplier portals or web apps in a DMZ subnet, then route only the app’s required calls into the enclave.
You terminate TLS at a controlled point, then re-encrypt to the internal service with inspected traffic where policy allows.

Service reduction

You strip unused services and ports from enclave hosts and containers to meet CM.L2-3.4.6, then document the baseline in configuration management.
You remove shared services that bleed identity or data across the boundary and replace them with enclave-local equivalents.

Evidence routines

You schedule boundary rule reviews and archive diffs, approvals, and post-implementation checks so you can show continuous control.
You test a narrow set of kill-switches that you can activate during an incident to cut risky flows without taking down the enclave.

Common pitfalls that keep scope large

Teams often shrink the enclave on a diagram while flows and dependencies keep the practical scope wide. Two patterns stand out.

You keep shared services like enterprise file shares, identity sync paths, or unmanaged DNS resolvers in the data path. Assessors then treat those services as in-scope systems.
You rely on VLAN tags without routing separation or policy enforcement. Assessors then ask for proof of isolation that a VLAN design alone cannot support.

You can fix both by moving those services inside the enclave or by building controlled, inspectable proxies that sit at the boundary.

Closing guidance

Scoping and segmentation take ownership and proof. You define the enclave boundary in the SSP, you implement the controls that enforce it, and you collect evidence as you operate. DoD’s program evaluates that work against NIST SP 800-171 at Level 2. The tighter your design and records, the less time you spend arguing scope and the more time you spend showing substance.