If you’re building a CMMC enclave to contain your CUI environment, you need to understand a January 2026 DoD FAQ clarification that directly affects where your assessment boundary lands. The short version: encrypted CUI is still CUI, encryption alone doesn’t create logical separation, but a properly separated enclave can keep your enterprise network out of scope, even when encrypted CUI crosses it.

This matters because scoping decisions drive cost. Every component inside your assessment boundary needs to meet all 110 NIST 800-171 practices. Getting this wrong in either direction, too broad and you’re remediating systems that didn’t need it, too narrow and your C3PAO flags a scoping deficiency, is expensive.

What the FAQ Actually Says

The DoD clarified three things that work together:

Encrypted CUI is still CUI. Encrypting a file or packet doesn’t change its classification. If the underlying data is controlled, the encrypted version is controlled. This shouldn’t surprise anyone, but it needed to be stated plainly because some OSCs were treating encryption as a de-scoping mechanism on its own.

Encryption alone does not create logical separation. The FAQ is explicit: logical separation requires non-physical controls that prevent data transfer between connected assets, firewalls, VLANs, VPNs, or similar network segmentation. Encryption protects confidentiality, but it doesn’t enforce a security boundary. You can’t just turn on TLS and call your network segmented.

Enterprise networking components carrying encrypted CUI can remain out of scope, if the enclave is otherwise logically separated from the enterprise network. This is the practical win. When your CUI enclave has proper boundary controls in place and encrypted CUI transits shared infrastructure (switches, routers, ISP links), those transit components don’t get pulled into your CMMC assessment boundary.

What This Means for Your Environment

For OSCs pursuing an enclave strategy, which is most of the small-to-medium DIB contractors we work with, this is good news with conditions. You can architect an enclave that shares physical network infrastructure with your broader enterprise without dragging everything into scope. But only if:

• Your enclave has real logical separation, documented, implemented, and testable. Think firewall rules, VLAN segmentation, or a dedicated VPN tunnel. Not just “we encrypt everything.”
• Your encryption meets the bar, FIPS-validated cryptography per SC.L2-3.13.8 (encryption of CUI in transit) and SC.L2-3.13.11 (encryption at rest). Self-signed certs and default TLS configurations may not cut it.
• Your SSP reflects the architecture, the scoping narrative needs to clearly describe the boundary, what’s in, what’s out, and why each out-of-scope component qualifies. A C3PAO will probe this.

What You Should Do Now

If you’ve already scoped your environment, revisit your boundary documentation with this clarification in mind. Specifically:

1. Audit your network diagram for components currently marked in-scope that only carry encrypted CUI traffic and sit outside your logical boundary. These may be candidates for re-categorization.
2. Verify your segmentation controls are actual logical separation, not just encryption. Document the mechanism.
3. Update your SSP to articulate why enterprise transit components are out of scope, referencing your encryption implementation and boundary controls.
4. Don’t over-correct. If a networking component does more than passively carry encrypted traffic, if it terminates a VPN, inspects packets, or routes based on CUI content, it’s likely still in scope.

This is the kind of scoping nuance that shows up during assessments. If your SSP doesn’t reflect it yet, now is the time to fix it, not when your C3PAO is asking questions. If you need help translating this into your scoping documentation or POA&M, that’s what a scoping conversation is for.