A CMMC enclave is a segmented, tightly controlled part of your environment built to hold Controlled Unclassified Information, and its purpose is practical: it keeps your CMMC Level 2 assessment focused on the systems that actually touch CUI instead of your entire network. For a defense contractor where only a fraction of the business handles CUI, that difference decides how large, expensive, and slow the assessment becomes. This guide explains what a CMMC enclave is, how to scope one correctly, how external providers fit inside it, and the situations where an enclave is the wrong choice.
The reason the enclave matters is scope, and scope is where CMMC cost is won or lost. CMMC Level 2 requires implementing all 110 security requirements of NIST SP 800-171 Revision 2 across every asset in scope. If your whole network is in scope, every system carries that weight. If a well-defined enclave contains CUI, only the enclave and the assets that protect it do. The enclave is not a product you buy; it is a boundary you design and document.
What a CMMC Enclave Is
A CMMC enclave is a set of system resources that operate within the same security domain and share a single, common security perimeter. In plain terms, it is a walled-off environment, on-premises or in the cloud, where CUI lives and is worked on, separated from the rest of your systems so those systems stay out of scope. The enclave concentrates the people, technology, and facilities that handle CUI into one defined boundary that an assessor can evaluate cleanly.
The value follows directly from CMMC’s scoping model. The CMMC Assessment Scope, defined in 32 CFR 170.19, is the set of all assets in your environment that will be assessed against the security requirements. Anything that processes, stores, or transmits CUI, or that protects the systems that do, falls inside that scope. An enclave shrinks the scope by ensuring that the systems handling CUI are a small, deliberate subset of your environment rather than the whole thing. The certification cost, timeline, and complexity all track the size of that scope.
When a CMMC Enclave Makes Sense
An enclave pays off when CUI touches only part of your operation. If a limited number of employees work with CUI on a defined set of systems, isolating them lets the rest of the business stay outside the assessment boundary. The contractor with a small government-facing team inside a larger commercial company is the clearest case: the commercial side, its people, and its systems remain out of scope as long as they cannot access the enclave.
The enclave is the wrong choice when CUI is woven through the whole organization. If most staff handle CUI, or if sensitive data flows through the majority of your systems, an enclave forces you to duplicate email, file storage, and collaboration tools to maintain separation, and the cost and friction of running two parallel environments can exceed the cost of bringing the broader environment into compliance. Before committing to an enclave, map where CUI actually goes. If it is concentrated, isolate it. If it is everywhere, an enclave adds complexity without reducing scope enough to justify it.
How to Scope a CMMC Enclave
Scoping an enclave is the same discipline as scoping any CMMC environment, applied to a deliberately narrow boundary. The work is to identify where CUI lives, draw the boundary around it, and categorize every asset inside and at the edge. The full method is covered in the CMMC environment scoping guide; what follows is how it applies to an enclave.
Follow the CUI, Then Draw the Boundary
Start by tracing CUI through its lifecycle: where it enters, where it is processed, where it is stored, and where it leaves. A data flow diagram makes this visible and becomes core assessment evidence. Once you can see the path, the enclave boundary is the smallest perimeter that contains all of it. Everything inside is in scope; everything genuinely separated from it is not. The boundary only holds if the separation is real, which is why documentation of that separation matters as much as the separation itself.
Categorize Every Asset
Inside and around the enclave, each asset falls into one of the categories CMMC uses to set assessment depth. Getting these right is what prevents both over-scoping, which wastes money, and under-scoping, which fails the assessment.
| Asset category | What it is | Assessment treatment |
|---|---|---|
| CUI Assets | Process, store, or transmit CUI | Assessed against all Level 2 requirements |
| Security Protection Assets | Provide security functions to the scope | Assessed against relevant requirements |
| Contractor Risk Managed Assets | Could handle CUI but are restricted from it | Documented; limited checks if policy is clear |
| Specialized Assets | IoT, OT, government equipment, test gear | Documented; assessed with their limits in mind |
| Out-of-Scope Assets | Cannot handle or protect CUI | Excluded, with justification |
The table sets the depth of scrutiny each asset receives, and the practical lesson is that categorization is a cost lever, not a formality. An asset placed in the wrong category either drags unnecessary controls onto systems that do not need them or leaves a gap an assessor will find. Every in-scope asset belongs in your asset inventory and your System Security Plan, and the out-of-scope ones need a documented reason they cannot reach CUI.
Separate Logically or Physically
Separation is what makes the enclave boundary real. Logical separation uses firewalls, network segmentation, and access controls to block data movement between connected systems while keeping them physically linked, and it is the more common and flexible approach. Physical separation removes the connections entirely, with data moving only through controlled manual transfer, and it offers the strongest isolation at the cost of operational convenience. NIST SP 800-171 permits limiting scope by isolating the systems that handle CUI into a separate security domain, which is exactly what an enclave does. The right choice depends on how much operational friction your team can absorb against how much isolation your CUI demands.
External Service Providers Inside the Enclave
Most enclaves rely on outside providers for at least part of the infrastructure, and those relationships extend your boundary. An External Service Provider that processes, stores, or transmits CUI, or that handles the data protecting your CUI, is part of your assessment scope and must be accounted for in your documentation.
Cloud providers carry a specific requirement. A Cloud Service Provider that handles CUI must meet the FedRAMP Moderate baseline, either through authorization or through a recognized equivalency, under DFARS 252.204-7012. The contractor, not the provider, is responsible for confirming and documenting that this requirement is met, so using a cloud environment inside your enclave does not transfer the obligation away from you. For how the FedRAMP side of that requirement works, see Elevate’s FedRAMP advisory services.
A Customer Responsibility Matrix is the document that keeps this straight. It records, for each requirement, whether responsibility sits with you, with the provider, or is shared. Without it, teams assume a provider covers a control it does not, and the gap surfaces during assessment. The matrix belongs in your System Security Plan alongside the description of the provider relationship. Using an authorized cloud provider never means inheriting compliance automatically; you still implement and evidence the controls that remain yours.
Enclave Documentation for Assessment
An enclave that is not documented is not defensible. The assessor works from three artifacts, and they must match reality. The asset inventory lists every in-scope asset by category. The network diagram shows the enclave boundary, all entry and exit points, the connections to external services, and how CUI flows, drawn clearly enough to read without zooming and with the authorization boundary marked. The System Security Plan ties it together, describing how each asset category is protected and how responsibilities are divided with any provider.
These documents also carry the scoping argument. When you claim a system is out of scope, the documentation is where you prove the separation that justifies the claim. Poor scoping documentation can undermine an assessment before it starts, because the assessor cannot verify a boundary they cannot see. Treat the diagram and the plan as the enclave’s evidence, not its paperwork.
Enclave Compliance Over Time
CMMC Level 2 certification runs on a three-year cycle, with annual affirmations of continued compliance in between and a reassessment triggered by significant architectural or boundary changes to the scope. For an enclave, that last point is the one to watch. A merger, an acquisition, or a network expansion that alters the enclave boundary can require a new assessment, and organizations are expected to report changes affecting their certificate status to their contracting officer promptly. The enclave that was scoped correctly at certification stays compliant only if its boundary is maintained and its documentation keeps pace with change.
Elevate helps defense contractors decide whether an enclave fits their environment, scope it so the boundary holds under assessment, and keep it defensible across the certification cycle. To map your CUI footprint and size the right enclave, book a readiness call with an Elevate advisor.
Conclusion
A CMMC enclave is a scoping decision before it is a technical one. By concentrating CUI into a defined, well-separated boundary, it keeps the Level 2 assessment focused on the systems that matter and keeps the rest of the business out of scope, which is where the cost savings come from. It fits organizations where CUI is contained and works against those where CUI is everywhere, so the first step is always to follow the data and see which situation you are in.
The enclave holds only if the separation is real and the documentation proves it: a clear boundary, correctly categorized assets, defensible separation, and provider responsibilities mapped in writing. Get those right and the enclave turns an overwhelming, whole-network assessment into a contained and manageable one. To decide whether an enclave is right for your environment and scope it correctly, book a readiness call with an Elevate advisor.
Key Takeaways
A CMMC enclave is a scope-reduction strategy that concentrates CUI into a controlled boundary, and it succeeds or fails on separation and documentation.
- The enclave exists to shrink scope: CMMC Level 2 applies all 110 NIST SP 800-171 requirements to every in-scope asset, so isolating CUI keeps the rest of the network out of the assessment.
- It fits contained CUI, not pervasive CUI: an enclave pays off when a limited team and system set handle CUI, and it adds cost when sensitive data runs through most of the business.
- Asset categorization sets the cost: classifying assets correctly across the five CMMC categories is what prevents both expensive over-scoping and assessment-failing under-scoping.
- Providers extend your boundary: a cloud provider handling CUI must meet the FedRAMP Moderate baseline, and the contractor remains responsible for confirming it and mapping responsibilities in a Customer Responsibility Matrix.
- Maintenance is part of the design: significant boundary changes can trigger reassessment within the three-year cycle, so the enclave stays compliant only if its boundary and documentation are maintained.
FAQs
Q1. What is a CMMC enclave? A CMMC enclave is a segmented environment, on-premises or in the cloud, that isolates the systems and people handling Controlled Unclassified Information behind a single security perimeter. It separates CUI from the rest of your network so that only the enclave and the assets protecting it fall within your CMMC Level 2 assessment scope. The goal is to keep the assessment focused and the cost proportional to the systems that actually handle CUI.
Q2. How does a CMMC enclave reduce assessment scope? CMMC Level 2 requires all 110 NIST SP 800-171 requirements to be met on every in-scope asset. By confining CUI to a defined enclave and genuinely separating it from other systems, you keep those other systems out of scope, so they do not have to meet the requirements or be assessed. The scope, and therefore the cost and timeline, tracks the size of the enclave rather than the size of your whole environment.
Q3. When should a company not use a CMMC enclave? An enclave is the wrong choice when CUI is spread across most of the organization. If the majority of staff and systems handle CUI, maintaining a separate enclave means duplicating tools like email and file storage, and that friction and cost can exceed simply bringing the broader environment into compliance. The test is to map where CUI flows: if it is concentrated, an enclave helps; if it is pervasive, it does not.
Q4. Do cloud providers used in a CMMC enclave need FedRAMP? A Cloud Service Provider that processes, stores, or transmits CUI within your enclave must meet the FedRAMP Moderate baseline through authorization or a recognized equivalency, under DFARS 252.204-7012. The responsibility to confirm and document this sits with the contractor, not the provider. Using an authorized cloud service does not automatically make you compliant, since you still implement and evidence the controls that remain your responsibility.
Q5. What documentation does a CMMC enclave require? An enclave needs three core artifacts that match your actual environment: an asset inventory categorizing every in-scope asset, a network diagram showing the enclave boundary and how CUI flows, and a System Security Plan describing how each asset is protected and how responsibilities are shared with any provider. These documents also justify your scoping decisions, because they are where you prove the separation that keeps out-of-scope systems out of scope.