The Scoping Guide handles enclaves in two sections: Use of Enclaves and Separation Techniques. Both are worth reading verbatim.
What the guide actually says
From Use of Enclaves:
"Satisfaction of CMMC security requirements may be accomplished by people, processes, or technologies which apply to the entire OSA enterprise. This does not mean all assets across the entire OSA enterprise are automatically part of a CMMC Assessment Scope. For example, a centralized IT group may acquire, configure, deploy, and maintain a standard anti-malware tool. Systems within a defined assessment scope use that centrally deployed tool. The anti-malware tool and the people in the IT group who maintain it, the processes and policies to deploy and update it, and the supporting systems (e.g., management server) could be in the CMMC Assessment Scope but other functions performed by the enterprise IT and other enterprise assets would not be automatically part of the CMMC Assessment Scope."
"Within the enclave, the OSA determines which requirements are implemented and which requirements are inherited; all requirements must be MET. If a process, policy, tool, or technology within the enclave would invalidate an implementation at the Enterprise level, that requirement cannot be inherited and the OSA must demonstrate that it is MET by implementation in some other way."
"There is no established metric for inherited implementations from an enterprise to any defined enclaves. The OSA determines the architecture that best meets its business needs and complies with CMMC requirements."
What separation actually means
The Scoping Guide's Separation Techniques section defines what counts as separation for Out-of-Scope claims:
- Logical separation: Data transfer between physically connected assets is prevented by non-physical means such as software or network controls (firewalls, routers, VPNs, VLANs).
- Physical separation: Assets have no connection at all. Data can only be transferred manually (e.g., USB drive).
The guide references NIST SP 800-171 Rev 2: "If nonfederal organizations designate specific system components for the processing, storage, or transmission of CUI, those organizations may limit the scope of the security requirements by isolating the designated system components in a separate CUI security domain."
Common enclave patterns
- Cloud-based enclave: A separate tenant in a FedRAMP-authorized government cloud (the federal/government tier offered by the cloud provider), isolated from the enterprise commercial infrastructure. The enterprise commercial environment can stay out of scope if it provides no security functions to the enclave and CUI never traverses the commercial environment.
- Network-segmented enclave: A separate VLAN or VPC with firewall rules preventing data flow to the rest of the enterprise. Users access through jump hosts or VDI.
- Physically separate enclave: Standalone workstations, switches, and storage. Most expensive but most defensible.
Inheritance has to be substantive
The Scoping Guide is clear that inherited implementations work only when the inheriting enclave actually inherits the capability. If you claim to inherit anti-malware from the enterprise but the enterprise tool is not configured to scan the enclave systems, the requirement is not MET. Inheritance must be substantive, not declarative. Document, in your SSP, which capability is inherited from where, how the enclave actually consumes it, and where the evidence lives.
Data-sharing realities to plan for
The enclave's point is that CUI does not leave it. CUI inside the enclave cannot be sent to commercial email, commercial Microsoft 365, commercial file-sharing tools, or any other destination that is not FedRAMP-authorized (or FedRAMP Moderate Equivalent) per DFARS 252.204-7012. That fact reshapes how CUI moves between your enclave and everyone else. Contractors who adopt an enclave model frequently underestimate this until the first deliverable is due.
What this looks like in practice:
- The prime will send to your enclave, not your commercial email. A prime that is sharing CUI with you has a CUI-cleared way to share it (otherwise they could not be sharing CUI in the first place). They are not going to send CUI to a commercial address; they will want to send to your enclave mailbox. Make sure the email address the prime has on file is your enclave address, and make sure the people working the contract are checking that mailbox rather than forwarding to a commercial one out of habit.
- You deliver to the prime's CUI-cleared destination, not their commercial address. Primes that flow CUI typically have their own enclave, their own GCC High tenant, or an enterprise CMMC-certified environment of some kind. Confirm with the prime which destination they want deliverables sent to before the contract starts, and document it.
- Subcontractors and partners may not have CUI-cleared environments. This is where real downstream friction shows up. Sharing CUI to a subcontractor runs into whether the subcontractor has a destination that meets the same standard. If they do not, you cannot send CUI to them; restructure the data (a process traveler instead of the customer drawing) or do not flow CUI to that supplier at all.
- Internal administrative workflows (legal, finance, HR) often live outside the enclave. Crossings between the enclave and the commercial side of the OSA need a written procedure or the boundary leaks.
- Contracting officers and program managers have their own CUI-cleared paths through government systems. If a government contact asks you to send something to a commercial address, redirect to the documented CUI-cleared path rather than accommodating the convenience.
How to manage it:
- Establish CUI exchange procedures with each prime before the contract starts. Document the agreed CUI-cleared exchange path (their CMMC-certified environment to your enclave, and yours to theirs) in writing so the deliverable-day conversation is not the first time anyone thinks about it.
- Make sure the email address and any document-share path the prime has on file is the enclave path, not commercial. Update the contact information at award and again at any personnel change.
- Train the workforce that CUI does not leave the enclave. Make explicit that requests from a prime, partner, or government POC to "just send it to my Gmail" or "email it to my work address" must be redirected to the documented exchange procedure, not accommodated for convenience.
- Document the exchange procedure in your SSP as part of the boundary description. The assessor will ask how CUI flows in and out of the enclave.
Common errors with CUI exchange:
- Giving the prime your commercial email address out of habit at award, and discovering at first delivery that the contract requires the enclave path.
- Forwarding CUI from the enclave to commercial email for convenience.
- Using personal email or commercial M365 to send a CUI artifact to the prime, partner, or government POC.
- Treating the enclave as an internal-only design and only discovering the external CUI flow problem at first delivery.
- Forgetting that downstream subcontractors face the same boundary and need the same exchange procedure.
When enclaves make sense
The right enclave decision is a function of how much of your workforce and infrastructure touches CUI versus how much does not. If a small fraction of your operation handles CUI, an enclave concentrates compliance investment on a smaller surface. If most of the organization handles CUI, scoping the whole environment is usually cleaner. The Scoping Guide leaves this calculus to the OSA. There is no DoD-published cost ratio or threshold.